Sesión Descripción Protocolo

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. Su uso predominante es el soporte de aplicaciones de transmisión de medios, como voz sobre IP (VoIP) y videoconferencia. SDP no entrega flujos de medios por sí mismo, pero se usa 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), 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 un protocolo independiente para describir sesiones de multidifusión.

El IETF publicó la especificación original como estándar propuesto en abril de 1998. Las especificaciones revisadas se publicaron en 2006 (RFC 4566) y en 2021 (RFC 8866).

Descripción de la sesión

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. La forma de cada campo es la siguiente.

нерентреними = >

Donde <character> es un solo carácter 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. No se permiten espacios en blanco inmediatamente a ambos lados del signo igual.

Las descripciones de las sesiones constan de tres secciones: descripciones de la sesión, del tiempo y de los medios. Cada descripción puede contener múltiples descripciones de tiempo y medios. Los nombres solo son únicos dentro de la construcción sintáctica asociada.

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

• Descripción del período de sesiones

 v= (número de versión del protocolo, actualmente sólo 0)
o= (originador y identificador 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 personaje con código UTF-8)
i=* (título de sesión o información corta)
u=* (URI of description)
e=* (dirección de correo electrónico cero o más con nombre opcional de contactos)
p=* (cero o más número de teléfono con nombre opcional de contactos)
c=* (información de conexión no requerida si se incluye en todos los medios)
b=* (líneas de información de ancho de banda o más)
 Uno o más descripciones del tiempo ("t=" y "r=" líneas; ver abajo)z=* (ajustes de la zona horaria)
k=* (clave de cifrado)
a=* (líneas de atributos de cero o más sesiones)
 Cero o más Descripción de medios (Cada uno comienza por una línea "m="; vea abajo)

• Descripción del tiempo (mandatorio)

 t= (hora la sesión está activa)
r=* (horas de repetición cero o más)

• Descripción de medios (opcional)

 m= (nombre multimedia y dirección de transporte)
i=* (campo de información o título multimedia)
c=* (información de conexión - opcional si se incluye a nivel de sesión)
b=* (líneas de información de ancho de banda o más)
k=* (clave de cifrado)
a=* (cero o más líneas de atributo mediático – sobreriding the Session attribute lines)

A continuación se muestra una descripción de sesión de muestra de RFC 4566. Esta sesión la originó el usuario "jdoe", en la dirección IPv4 10.47.16.5. Su nombre es "Seminario SDP" e información ampliada de la sesión ("Un seminario sobre el protocolo de descripción de la sesión") se incluye 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 dure 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. Se indica a los destinatarios de esta descripción de sesión que solo reciban medios. Se proporcionan dos descripciones de medios, ambas utilizando el perfil de audio y video 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& #34;). 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. Los puertos RTCP para las transmisiones de audio y video de 49171 y 51373, respectivamente, están implícitos.

 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminario sobre el protocolo de descripción del período de sesiones
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.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 puramente un formato para la descripción de la sesión. Está destinado a 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 una carga útil HTTP.

Atributos

SDP usa atributos para extender el protocolo central. Los atributos pueden aparecer dentro de las secciones Sesión o Medios y tienen el alcance correspondiente como nivel de sesión o nivel de medios. Ocasionalmente, se agregan nuevos atributos al estándar a través del registro con IANA.

Los atributos son propiedades o valores:

• Propiedad: a=bandera transmite una propiedad booleana de los medios de comunicación o sesión.
• Valor: a=atributo:valor proporciona un parámetro llamado.

Dos de estos atributos están especialmente definidos:

• a=charset:codificación se utiliza en las secciones de sesión o medios de comunicación para especificar una codificación de caracteres diferente (como se registra en el registro IANA) del valor predeterminado recomendado (UTF-8) para las claves de protocolo estándar. Estos valores contienen un texto que se pretende mostrar al usuario.
• a=sdplang:código se utiliza para especificar el idioma del texto. El texto alternativo en varios idiomas puede ser llevado en la sesión, y seleccionado automáticamente por el agente del usuario según las preferencias del usuario.

En ambos casos, los campos de texto destinados a mostrarse 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 < i>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.

Algunos otros atributos también están presentes en el ejemplo, ya sea como un atributo de nivel de sesión (como el atributo en el formulario de propiedad a=recvonly), o como un atributo de nivel de medios (como como el atributo en forma de valor a=rtpmap:99 h263-1998/90000 para el video del ejemplo).

Formatos de tiempo y repeticiones

Los tiempos absolutos se representan en formato Network Time Protocol (NTP) (la cantidad 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, 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 unidades de tiempo (días: d, horas: h, minutos: m y segundos: secuencia s).

Por lo tanto, una reunión de una hora a partir de las 10 a. m. UTC del 1 de agosto de 2010, con una única repetición una semana después a la misma hora, puede representarse como:

 t=1280656800 1281265200
r=604800 3600 0

O usando el tiempo escrito:

 t=1280656800 1281265200
r=7d 1h 0

Cuando se especifican las horas 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 para que ocurra a la misma hora local en una zona horaria específica durante el período entre la hora de inicio y el tiempo de parada.

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 se necesitarán ajustes de luz diurna, se supone que los tiempos de repetición están todos definidos dentro de la misma zona horaria, y SDP admite la indicación de Horas absolutas de NTP en las que será necesario aplicar una compensación de luz diurna (expresada en segundos o usando un tipo de tiempo) a la hora de inicio repetida o a la hora final que cae en o después de cada ajuste de luz diurna. Todos estos desplazamientos 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 de NTP cuando se producirá un ajuste de luz diurna, y el segundo elemento indica la compensación que se aplicará en relación con las horas absolutas calculadas con el campo r.

Por ejemplo, si un ajuste de luz diurna resta 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. ajuste para 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 a. más adelante), 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 a. m. UTC hasta el domingo 26 de junio de 2011 a las 4 a. m. UTC (hora de finalización de la última repetición, es decir, 360 días más 1 hora más tarde, o 31107600 segundos más tarde), de modo que incluiría la transición al horario de verano el domingo 27 de marzo de 2011 a las 2 a. hora):

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

Como los anuncios de SDP para sesiones repetidas no deben hacerse para cubrir períodos muy largos que excedan algunos años, la cantidad de ajustes de luz diurna que se incluirán en el parámetro z= debe ser pequeña.

Las sesiones pueden repetirse irregularmente 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ía:

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

El protocolo SDP no admite sesiones repetitivas de programaciones mensuales y anuales con tiempos de repetición tan simples, porque están espaciadas irregularmente en el tiempo; en su lugar, se pueden proporcionar tuplas t/r adicionales para cada mes o año.