Protocolo de descripción de sesión

El Protocolo de Descripción de Sesión ( SDP ) es un formato para describir sesiones de comunicación multimedia con fines de anuncio e invitación. ^{[ 1 ]} Su uso predominante es en el soporte de aplicaciones de transmisión de medios , como voz sobre IP (VoIP) y videoconferencia . SDP no transmite ningún flujo de medios por sí mismo, sino que se utiliza entre puntos finales para la negociación de métricas de red, tipos de medios y otras propiedades asociadas. El conjunto de propiedades y parámetros se denomina perfil de sesión .

SDP es extensible para admitir nuevos tipos y formatos de medios. SDP fue originalmente un componente del Protocolo de Anuncio de Sesión (SAP), ^{[ 2 ]} pero encontró otros usos en conjunto con el Protocolo de Transporte en Tiempo Real (RTP), el Protocolo de Transmisión en Tiempo Real (RTSP), el Protocolo de Inicio de Sesión (SIP) y como un protocolo independiente para describir sesiones de multidifusión .

El IETF publicó la especificación original como una Norma Propuesta en abril de 1998 (RFC 2327). ^{[ 3 ]} Se publicaron especificaciones revisadas en 2006 (RFC 4566), ^{[ 1 ]} y en 2021 (RFC 8866). ^{[ 4 ]}

El Protocolo de Descripción de Sesión describe una sesión como un grupo de campos en un formato basado en texto, un campo por línea. ^{[ nota 1 ]} La forma de cada campo es la siguiente.

<carácter>=<valor><CR><LF>

Donde <character>es un único carácter sensible a mayúsculas y minúsculas y <value>es texto estructurado en un formato que depende del carácter. Los valores suelen estar codificados en UTF-8 . ^{[ nota 2 ]} No se permiten espacios en blanco inmediatamente a ninguno de los lados del signo igual. ^{[ 1 ] : Sección 5}

Las descripciones de sesión constan de tres secciones: descripción de la sesión, de la duración y de los medios. Cada descripción puede contener varias descripciones de duración y de medios. Los nombres solo son únicos dentro de la construcción sintáctica asociada. ^{[ 5 ]}

Los campos deben aparecer en el orden indicado; los campos opcionales están marcados con un asterisco:

• Descripción de la sesión

 v = (número de versión del protocolo, actualmente solo 0) o= (originador e identificador de sesión: nombre de usuario, ID, número de versión, dirección de red) s= (nombre de la sesión: obligatorio con al menos un carácter codificado en UTF-8) i=* (título de la sesión o información breve) u=* (URI de la descripción) e=* (cero o más direcciones de correo electrónico con nombre de contacto opcional) p=* (cero o más números de teléfono con nombre de contacto opcional) c=* (información de conexión; no es necesaria si se incluye en todos los medios) b=* (cero o más líneas de información de ancho de banda) Una o más descripciones de tiempo (líneas "t=" y "r="; ver más abajo ) z=* (ajustes de zona horaria) k=* (clave de cifrado) a=* (cero o más líneas de atributos de sesión) Cero o más descripciones de medios (cada una comenzando con una línea "m="; ver más abajo )

• Descripción del tiempo (obligatorio)

 t = (tiempo que la sesión está activa) r=* (cero o más repeticiones)

• Descripción del archivo multimedia (opcional)

 m = (nombre del medio y dirección de transporte) i=* (título del medio o campo de información) c=* (información de conexión — opcional si se incluye a nivel de sesión) b=* (cero o más líneas de información de ancho de banda) k=* (clave de cifrado) a=* (cero o más líneas de atributos de medios: anulando las líneas de atributos de sesión)

A continuación se muestra una descripción de sesión de ejemplo de RFC 4566. Esta sesión es originada por el usuario "jdoe", en la dirección IPv4 10.47.16.5. Su nombre es "SDP Seminar" y se incluye información de sesión extendida ("Un seminario sobre el protocolo de descripción de sesión") junto con un enlace para obtener información adicional y una dirección de correo electrónico para contactar a la persona responsable, Jane Doe. Esta sesión está especificada para durar dos horas utilizando marcas de tiempo NTP, con una dirección de conexión (que indica la dirección a la que los clientes deben conectarse o, cuando se proporciona una dirección de multidifusión, como en este caso, suscribirse) especificada como IPv4 224.2.17.12 con un TTL de 127. Se instruye a los destinatarios de esta descripción de sesión para que solo reciban contenido multimedia. Se proporcionan dos descripciones de contenido multimedia, ambas utilizando el perfil de audio y video RTP. La primera es una transmisión de audio en el puerto 49170 que utiliza el tipo de carga útil RTP/AVP 0 (definido por RFC 3551 como PCMU ), y la segunda es una transmisión de video en el puerto 51372 que utiliza el tipo de carga útil RTP/AVP 99 (definido como "dinámico"). Finalmente, se incluye un atributo que asigna el tipo de carga útil RTP/AVP 99 al formato h263-1998 con una  frecuencia de reloj de 90 kHz. Se sobreentienden los puertos RTCP para las transmisiones de audio y video de 49171 y 51373, respectivamente.

 v=0 o=jdoe 2890844526 2890842807 EN IP4 10.47.16.5 Seminario SDP i=Un seminario sobre el protocolo de descripción de sesiones u= http://www.example.com/seminars/sdp.pdf e=j.doe@ejemplo.com (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000

La especificación SDP es simplemente un formato para la descripción de sesiones. Está diseñada para distribuirse a través de diferentes protocolos de transporte según sea necesario, incluidos SAP , SIP y RTSP . SDP incluso podría transmitirse por correo electrónico o como carga útil HTTP.

SDP utiliza atributos para extender el protocolo principal. Los atributos pueden aparecer en las secciones de Sesión o Medios y se clasifican según corresponda como de nivel de sesión o de nivel de medios . Ocasionalmente se añaden nuevos atributos al estándar mediante el registro en IANA. ^{[ 6 ]}

Los atributos son propiedades o valores:

• Propiedad: a= El indicador transmite una propiedad booleana del medio o sesión.
• Valor: a= atributo : el valor proporciona un parámetro con nombre.

Dos de estos atributos están definidos de forma especial:

• a=charset: encoding se utiliza en las secciones de sesión o medios para especificar una codificación de caracteres diferente (tal como está registrada en el registro IANA ^{[ 7 ]} ) al valor predeterminado recomendado ( UTF-8 ) para las claves de protocolo estándar. Estos valores contienen un texto que se mostrará al usuario.
• a=sdplang: este código se utiliza para especificar el idioma del texto. En la sesión se puede almacenar texto alternativo en varios idiomas, que el agente de usuario seleccionará automáticamente según las preferencias del usuario.

En ambos casos, los campos de texto destinados a ser mostrados a un usuario se interpretan como cadenas opacas, pero se muestran al usuario o a la aplicación con los valores indicados en la última aparición de los campos charset y sdplang en la sección de medios actual, o bien con su último valor en la sección de sesión.

Los parámetros v , s y o son obligatorios, no deben estar vacíos y deben estar codificados en UTF-8. Se utilizan como identificadores y no se mostrarán a los usuarios.

En el ejemplo también están presentes otros atributos, ya sea como un atributo de nivel de sesión (como el atributo en forma de propiedad a=recvonly ), ^{[ nota 3 ]} o como un atributo de nivel de medio (como el atributo en forma de valor a=rtpmap:99 h263-1998/90000 para el vídeo del ejemplo).

Las horas absolutas se representan en formato NTP ( Network Time Protocol ) (el número de segundos transcurridos desde 1900). Si la hora de finalización es 0, la sesión es ilimitada . Si la hora de inicio también es cero, la sesión se considera permanente . Las sesiones ilimitadas y permanentes no se recomiendan, pero no están prohibidas. Los intervalos se pueden representar con horas NTP o mediante una secuencia de valores de tiempo (días: d , horas: h , minutos: m y segundos: s ).

Así, una reunión de una hora a partir de las 10 am UTC del 1 de agosto de 2010, con una única repetición una semana después a la misma hora, se puede representar como:

 t= 1280656800 1281265200 r=604800 3600 0

O utilizando la hora escrita:

 t= 1280656800 1281265200 r=7d 1h 0

Cuando se especifican intervalos de repetición, puede ser necesario ajustar la hora de inicio de cada repetición para compensar los cambios del horario de verano, de modo que se produzca a la misma hora local en una zona horaria específica durante todo el período comprendido entre la hora de inicio y la hora de finalización.

En lugar de especificar esta zona horaria y tener que mantener una base de datos de zonas horarias para saber cuándo y dónde se necesitarán ajustes de verano, se asume que las horas repetidas están definidas dentro de la misma zona horaria, y SDP admite la indicación de las horas absolutas NTP cuando se deberá aplicar un desfase de verano (expresado en segundos o usando un tipo de hora) a la hora de inicio o de finalización repetida que caiga en o después de cada ajuste de verano. Todos estos desfases son relativos a la hora de inicio, no son acumulativos. NTP admite esto con el campo z , que indica una serie de pares cuyo primer elemento es la hora absoluta NTP en la que ocurrirá un ajuste de verano, y el segundo elemento indica el desfase que se aplicará en relación con las horas absolutas calculadas con el campo r .

Por ejemplo, si un ajuste de horario de verano resta 1 hora el 31 de octubre de 2010 a las 3  am UTC (es decir, 60 días menos 7 horas después de la hora de inicio del domingo 1 de agosto de 2010 a las 10 am UTC), y este será el único ajuste de horario de verano que se aplicará en el período programado que ocurriría entre el 1 de agosto de 2010 y el 28 de noviembre de 2010 a las 10  am UTC (la hora de finalización de la sesión repetida de 1 hora que se repite cada semana a la misma hora local, que ocurre 88 días después), esto se puede especificar como:

 t = 1280656800 1290938400 r=7d 1h 0 z = 1288494000 -1h

Si la sesión semanal de 1 hora se repitiera todos los domingos durante un año completo, es decir, desde el domingo 1 de agosto de 2010 a las 3 am UTC hasta el domingo 26 de junio de 2011 a las 4 am UTC (hora de finalización de la última repetición, es decir, 360 días más 1 hora después, o 31107600 segundos después), de modo que incluyera la transición de vuelta al horario de verano el domingo 27 de marzo de 2011 a las 2  am (se añade otra hora a la hora local para que la segunda transición al horario de verano se produzca 209 días después de la primera hora de inicio):

 t = 1280656800 1290938400 r=7d 1h 0 z= 1288494000 -1h 1269655200 0

Dado que los anuncios del SDP para sesiones repetidas no deben hacerse para cubrir períodos muy largos que superen unos pocos años, el número de ajustes de luz diurna que se incluyan en el parámetro z= debe seguir siendo pequeño.

Las sesiones pueden repetirse de forma irregular a lo largo de una semana, pero se programarán de la misma manera para todas las semanas del período, agregando más tuplas en el parámetro r . Por ejemplo, para programar el mismo evento también el sábado (a la misma hora del día) se usaría:

 t = 1280656800 1290938400 r=7d 1h 0 6d z= 1288494000 -1h 1269655200 0

El protocolo SDP no admite la repetición de sesiones mensuales y anuales con intervalos de tiempo tan simples, ya que están espaciados de forma irregular en el tiempo; en su lugar, se pueden proporcionar tuplas t / r adicionales para cada mes o año.

• Rosenberg, J.; Schulzrinne, H. (junio de 2002). Un modelo de oferta/respuesta con el protocolo de descripción de sesión . IETF . doi : 10.17487/RFC3264 . RFC 3264 .