Resumen

  • RFC 3524 definió SRF para pedir que varias líneas de medios compartieran un solo flujo de reserva.
  • La línea coordinaba el mapeo; no ejecutaba admisión, política, instalación de QoS, refresco de estado ni entrega al usuario.

Con a=group:SRF 1 2, una oferta SDP podía identificar mediante mid una línea de audio y otra de vídeo y declarar que ambas debían entrar en un Single Reservation Flow. Era una solución pequeña a una decisión real: una sesión multimedia no siempre quería una reserva independiente por cada medio.

El RFC contemplaba tres opciones. Todos los medios podían compartir una reserva, cada uno podía usar la suya o algunos podían agruparse mientras otros quedaban separados. SRF expresaba cuál de esas relaciones se solicitaba. No asignaba recursos.

Por eso las palabras normativas importan. Las líneas del grupo SHOULD mapearse al mismo flujo; las externas SHOULD NOT incorporarse a él. Un grupo incluso podía contener una sola línea. El receptor obtenía una regla para construir su petición, no un certificado de que la red ya hubiera actuado.

El marco de agrupación aportaba referencias comprobables. Cada mid era único dentro de la sesión y la línea group enumeraba esos identificadores bajo una semántica concreta. Una referencia que no apuntaba a ningún medio debía ignorarse. RFC 5888 mantuvo luego el patrón. Además, SDP permite que un receptor ignore atributos desconocidos: recibir sintaxis no equivale a soportarla.

SRF resultaba necesario cuando la parte remota intervenía en la reserva. Si el generador del SDP podía asignar ambas direcciones por sí mismo, escogía el mapeo localmente. Sin la línea de grupo, el receptor del ejemplo podía crear dos sesiones RSVP diferentes.

SIP y RSVP eran sólo el ejemplo. Otros protocolos podían transportar la descripción o establecer los recursos sin cambiar la sintaxis. Esa independencia colocaba a SRF en el plano de intención, no en el de ejecución.

RSVP tenía todavía que transportar un flowspec con la QoS deseada y un filter spec para reconocer paquetes. En cada nodo, el control de admisión comprobaba recursos y el control de política comprobaba permiso. El fracaso de cualquiera impedía instalar el estado pedido. Sólo después se programaban clasificador y planificador.

El estado tampoco era permanente. Path y Resv lo refrescaban; un cambio de ruta trasladaba la construcción y dejaba que lo antiguo caducara. La oferta SDP podía seguir siendo auténtica mientras la reserva ya no existía.

Incluso ResvConf tenía un límite expreso: RFC 2205 decía que su recepción no daba garantías. Una confirmación podía ir seguida de un error cuando otra solicitud alteraba la disponibilidad o la fusión. El grupo SRF estaba varios pasos antes de esa confirmación limitada.

RFC 3312 separó estado QoS actual y deseado. Si la descripción produjera realidad por sí misma, no haría falta esa distinción. SRF contestaba qué medios debían compartir el intento, no si la precondición se había cumplido.

La amenaza era concreta. Un atacante que añadiera líneas SRF podía obligar al terminal a crear más o menos flujos de los necesarios. El exceso consumía recursos; el defecto degradaba la sesión. Por eso se recomendaba con fuerza proteger la integridad del SDP y usar S/MIME cuando SIP lo transportara.

La integridad prueba quién emitió la instrucción y que no fue alterada. No prueba capacidad, permiso, soporte, persistencia ni reproducción. IANA tampoco: registrar SRF coordina un nombre común, no observa una reserva viva.

La historia útil consiste en conservar las capas. SDP válido, mid resueltos, intención autenticada, mapeo elegido, petición enviada, admisión por nodo, estado instalado, refresco, clasificación, paquetes y medio presentado son recibos diferentes. Confundirlos permite declarar QoS donde sólo había una línea bien formada.

Fuentes