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 apoyo de aplicaciones de transmisión de medios , como voz sobre IP (VoIP) y videoconferencia . SDP no entrega ningún flujo de medios en sí, pero 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 .
El protocolo SDP es extensible para admitir nuevos tipos y formatos de medios. Originalmente, el protocolo SDP era un componente del protocolo de anuncio de sesión (SAP), [2] pero encontró otros usos junto 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 protocolo independiente para describir sesiones de multidifusión .
La IETF publicó la especificación original como propuesta de estándar 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 que distingue entre mayúsculas y minúsculas<value> y es un 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 ambos lados del signo igual. [1] : Sección 5
Las descripciones de las sesiones constan de tres secciones: descripción de la sesión, del tiempo y de los medios. Cada descripción puede contener varias descripciones del tiempo y de los medios. Los nombres son únicos únicamente dentro de la construcción sintáctica asociada. [5]
Los campos deben aparecer en el orden que se muestran; los campos opcionales están marcados con un asterisco:
v= (número de versión del protocolo, actualmente solo 0) o= (identificador de originador y de sesión: nombre de usuario, id, número de versión, dirección de red) s= (nombre de 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 opcional de contactos) p=* (cero o más números de teléfono con nombre opcional de contactos) 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 comienza con una línea "m="; ver más abajo)
t= (tiempo que la sesión está activa) r=* (cero o más repeticiones)
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 en el 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 muestra de RFC 4566. Esta sesión la origina 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 ampliada ("A Seminar on the session description protocol") junto con un enlace para obtener información adicional y una dirección de correo electrónico para ponerse en contacto con la parte 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. A los destinatarios de esta descripción de sesión se les indica que solo reciban contenido multimedia. Se proporcionan dos descripciones de contenido multimedia, ambas utilizando el perfil de audio y vídeo RTP. El primero es un flujo de audio en el puerto 49170 que utiliza el tipo de carga útil RTP/AVP 0 (definido por RFC 3551 como PCMU ), y el segundo es un flujo 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 implican los puertos RTCP para los flujos de audio y video de 49171 y 51373, respectivamente.
v=0 o=jdoe 2890844526 2890842807 EN IP4 10.47.16.5 Seminario s=SDP i=A Seminario sobre el protocolo de descripción de sesiones u=http://www.ejemplo.com/seminarios/sdp.pdf [email protected] (Jane Doe) c=EN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=vídeo 51372 RTP/AVP 99 a=rtpmap:99h263-1998/90000
La especificación SDP es puramente un formato para la descripción de sesiones. Su objetivo es distribuirla a través de diferentes protocolos de transporte según sea necesario, incluidos SAP , SIP y RTSP . SDP podría incluso transmitirse por correo electrónico o como una carga útil HTTP.
El SDP utiliza atributos para ampliar el protocolo central. Los atributos pueden aparecer en las secciones Session o Media y su alcance se establece en consecuencia como session-level o media-level . Ocasionalmente, se agregan nuevos atributos al estándar mediante el registro con IANA. [6]
Los atributos son propiedades o valores:
Dos de estos atributos están especialmente definidos:
En ambos casos, los campos de texto destinados a ser mostrados a un usuario se interpretan como cadenas opacas, pero se representan para el usuario o 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 de lo contrario, 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 están destinados a mostrarse a los usuarios.
También hay algunos otros atributos presentes en el ejemplo, ya sea como un atributo de nivel de sesión (como el atributo en formato de propiedad a=recvonly ), [nota 3] o como un atributo de nivel de medio (como el atributo en formato de valor a=rtpmap:99 h263-1998/90000 para el video en el ejemplo).
Los tiempos absolutos se representan en formato de Protocolo de tiempo de red (NTP) (la cantidad de segundos desde 1900). Si el tiempo de finalización es 0, la sesión no tiene límites . Si el tiempo de inicio también es cero, la sesión se considera permanente . Las sesiones ilimitadas y permanentes no se recomiendan, pero no se prohíben. Los intervalos se pueden representar con tiempos NTP o en tiempo escrito: un valor y una secuencia de unidades de tiempo (días: d , horas: h , minutos: m y segundos: s ).
De esta manera, 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 de la siguiente manera:
t=1280656800 1281265200 r=604800 3600 0
O usando el tiempo escrito:
t=1280656800 1281265200 r=7d 1h 0
Cuando se especifican horas de repetición, puede ser necesario ajustar la hora de inicio de cada repetición para compensar los cambios en el horario de verano , de modo que ocurra a la misma hora local en una zona horaria específica durante todo el período entre la hora de inicio y la hora de finalización.
En lugar de especificar esta zona horaria y tener que soportar una base de datos de zonas horarias para saber cuándo y dónde serán necesarios los ajustes de luz diurna, se supone que las horas de repetición están todas definidas dentro de la misma zona horaria, y SDP admite la indicación de horas absolutas NTP cuando será necesario aplicar un desfase de luz diurna (expresado en segundos o utilizando un tipo de hora) a la hora de inicio o de finalización repetida que cae en o después de cada ajuste de luz diurna. Todas estas desfases son relativas a la hora de inicio, no son acumulativas. NTP admite esto con el campo z , que indica una serie de pares cuyo primer elemento es la hora absoluta NTP cuando se producirá un ajuste de luz diurna, 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 luz diurna restará 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 el domingo 1 de agosto de 2010 a las 10 am UTC), y este será el único ajuste de luz diurna que se aplicará en el período programado que ocurriría entre el 1 de agosto de 2010 hasta 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, lo 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 regreso al horario de verano el domingo 27 de marzo de 2011 a las 2 am (se agrega 1 hora nuevamente a la hora local de modo que la segunda transición de luz diurna ocurriría 209 días después de la primera hora de inicio):
t=1280656800 1290938400 r=7d 1h 0 z=1288494000-1h1269655200 0
Como los anuncios SDP para sesiones repetidas no deben realizarse para cubrir períodos muy largos que excedan unos pocos años, el número de ajustes de luz diurna a incluir en el parámetro z= debe seguir siendo pequeño.
Las sesiones pueden repetirse de forma irregular durante una semana, pero programarse 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 utilizaría:
t=1280656800 1290938400 r=7d 1h 0 6d z=1288494000-1h1269655200 0
El protocolo SDP no admite la repetición de sesiones mensuales y anuales con tiempos de repetición tan simples, porque están espaciados irregularmente en el tiempo; en su lugar, se pueden suministrar tuplas t / r adicionales para cada mes o año.