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 el soporte de aplicaciones de transmisión de medios , como voz sobre IP (VoIP) y videoconferencia . SDP no entrega ningún flujo de medios por sí mismo, 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 .
SDP es extensible para admitir nuevos tipos y formatos de medios. SDP era originalmente 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) y el Protocolo de inicio de sesión (SIP). y como protocolo independiente para describir sesiones de multidifusión .
El IETF publicó la especificación original como estándar propuesto en abril de 1998 (RFC 2327). [3] Las especificaciones revisadas se publicaron 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 carácter único que distingue entre 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 las sesiones constan de tres secciones: sesión, horario y descripciones de los medios. Cada descripción puede contener múltiples descripciones de tiempos y medios. Los nombres sólo son únicos dentro de la construcción sintáctica asociada. [5]
Los campos deben aparecer en el orden en que se muestran; Los campos opcionales están marcados con un asterisco:
v= (número de versión del protocolo, actualmente solo 0) o= (creador e identificador de sesión: nombre de usuario, identificación, 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 descripción) e=* (cero o más direcciones de correo electrónico con nombre de contactos opcional) p=* (cero o más números de teléfono con nombre de contactos 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 comienza con una línea "m="; ver más abajo)t= (tiempo que la sesión está activa) r=* (cero o más veces de repetición)
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 ejemplo de RFC 4566. Esta sesión la origina el usuario "jdoe", en la dirección IPv4 10.47.16.5. Su nombre es "Seminario SDP" y se incluye información ampliada de la sesión ("Un seminario sobre el protocolo de descripción de la sesión") junto con un enlace para obtener información adicional y una dirección de correo electrónico para contactar a la parte responsable, Jane Doe. Se especifica que esta sesión 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 está aquí, suscribirse) especificada como IPv4 224.2.17.12 con un TTL de 127. Los destinatarios de esta descripción de sesión deben recibir únicamente medios. Se proporcionan dos descripciones de medios, ambas utilizando el perfil de audio y vídeo RTP. El primero es un flujo de audio en el puerto 49170 que usa 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 usa 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 velocidad de reloj de 90 kHz. Están implícitos 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 s=Seminario SDP i=Un Seminario sobre el protocolo de descripción de sesiones u=http://www.example.com/seminars/sdp.pdf [email protected] (Jane Doe) c=EN IP4 224.2.17.12/127 t=2873397496 2873404696 a=solo recvo 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 la sesión. Está pensado para distribuirse 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 carga útil HTTP.
SDP utiliza atributos para ampliar el protocolo central. Los atributos pueden aparecer dentro de las secciones Sesión o Medios y tienen su alcance en consecuencia como nivel de sesión o nivel de medios . Ocasionalmente se agregan nuevos atributos al estándar mediante el registro en la 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 mostrarse a un usuario se interpretan como cadenas opacas, pero se muestran al 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 última aparición. 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 ser mostrados a los usuarios.
Algunos otros atributos también están presentes en el ejemplo, ya sea como un atributo a nivel de sesión (como el atributo en formato de propiedad a=recvonly ), [nota 3] o como un atributo a nivel de medios (como el atributo en formato de valor a=rtpmap:99 h263-1998/90000 para el vídeo del ejemplo).
Los tiempos absolutos se representan en formato Network Time Protocol (NTP) (el número de segundos desde 1900). Si el tiempo de parada es 0, entonces la sesión es ilimitada . Si la hora de inicio también es cero entonces la sesión se considera permanente . Se desaconsejan, pero no se prohíben, las sesiones ilimitadas y permanentes. 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: my segundos: s ).
Por lo tanto, 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 usando el tiempo escrito:
t=1280656800 1281265200 r=7d 1h 0
Cuando se especifican tiempos de repetición, es posible que sea 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 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 admitir 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 todos los tiempos de repetición están definidos dentro de la misma zona horaria, y SDP admite la indicación de horas absolutas NTP. cuando será necesario aplicar una compensación de luz diurna (expresada en segundos o usando un tipo de hora) a la hora de inicio repetida o la hora de finalización que cae en o después de cada ajuste de luz diurna. Todas estas compensaciones 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 desplazamiento que se aplicará en relación con los tiempos absolutos calculados con el campo r .
Por ejemplo, si un ajuste de luz diurna restará 1 hora el 31 de octubre de 2010 a las 3 a. m. 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 a. m. UTC), este será el único ajuste de luz diurna que se aplicará en el período programado que se producirí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 repitió 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 más tarde), de modo que incluiría la transición de regreso al horario de verano el domingo 27 de marzo de 2011 a las 2 am (se agrega nuevamente 1 hora a la hora local para que la segunda transición de horario de verano ocurra 209 días después de la primera hora de inicio):
t=1280656800 1290938400 r=7d 1h 0 z=1288494000 -1h 1269655200 0
Como los anuncios del SDP para sesiones repetidas no deben cubrir períodos muy largos que excedan unos pocos años, el número de ajustes de luz natural 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) usarías:
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 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.