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 los 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), 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 Norma propuesta en abril de 1998. [3] Las especificaciones revisadas se publicaron en 2006 (RFC 4566), [1] y en 2021 (RFC 8866). [4] .
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 de texto, un campo por línea. [nota 1] El formulario de cada campo es el siguiente.
= ácter>
Donde
es un carácter que distingue entre mayúsculas y minúsculas y
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, tiempo y descripciones de los medios. Cada descripción puede contener múltiples descripciones de tiempos y medios. Los nombres solo son únicos 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:
- 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 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 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 se requiere 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 )
- Descripción de la hora (obligatorio)
t = (tiempo que la sesión está activa) r = * (cero o más veces repetidas)
- Descripción de los medios (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 la 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 "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. 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 está aquí, 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 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"). 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 EN IP4 10.47.16.5 s = Seminario SDP i = Un seminario sobre el protocolo de descripción de la sesión u = http://www.example.com/seminars/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 = 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á diseñado 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 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 a nivel de sesión o nivel de medio . Ocasionalmente se agregan nuevos atributos al estándar mediante el registro en IANA. [6]
Los atributos son propiedades o valores:
- Propiedad: a = flag transmite una propiedad booleana del medio o de la sesión.
- Valor: a = atributo : valor proporciona un parámetro con nombre.
Dos de estos atributos están especialmente definidos:
- a = juego de caracteres: la codificación se utiliza en las secciones de sesión o medios para especificar una codificación de caracteres diferente (como se registró en el registro de IANA [7] ) del valor predeterminado recomendado ( UTF-8 ) para las claves de protocolo estándar. Estos valores contienen un texto que está destinado a mostrarse a un usuario.
- a = sdplang: el código se usa para especificar el idioma del texto. En la sesión se puede llevar texto alternativo en varios idiomas, y el agente de usuario puede seleccionarlo automáticamente de acuerdo con las preferencias del usuario. [ aclaración necesaria ]
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 sdplang en la sección de medios actual, o de lo contrario su última valor en la sección de sesión.
Los parámetros v , s , y O son obligatorios, no debe estar vacío, y deben ser 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 forma de propiedad a = recvonly ), [nota 3] o como un atributo de nivel de medios (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) (el número de segundos desde 1900). Si el tiempo 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". 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 ('s')) secuencia.
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, 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 que ocurra a la misma hora local en una zona horaria específica durante el período entre la hora de inicio y la hora de finalización (que aún se especifican en NTP). formato en UTC).
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 las horas de repetición están todas definidas dentro de la misma zona horaria, y SDP admite la indicación de tiempos absolutos NTP. cuando una compensación de luz diurna (expresada en segundos o usando un tipo de hora) deberá aplicarse 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 el tiempo absoluto de NTP cuando ocurrirá un ajuste de luz diurna, y el segundo elemento indica el desplazamiento a 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 del 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 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, que ocurre 88 días después), esto puede ser especificado 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 al 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 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 1 hora nuevamente a la hora local para que la segunda transición de luz diurna 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 de SDP para sesiones repetidas no deben hacerse para cubrir períodos muy largos que excedan algunos años, el número de ajustes de luz diurna para incluir en el parámetro z = debe permanecer pequeño.
Las sesiones pueden repetirse irregularmente durante una semana, pero programadas 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 la repetición de sesiones mensuales y horarios 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.
Notas
- ^ Las líneas terminan con un retorno de carro y uncarácter de salto de línea , pero las implementaciones pueden relajar esto omitiendo el retorno de carro.
- ^ La información de la sesión y los valores del nombre de la sesión están sujetos a la codificación especificada en cualquieratributo de juego de caracteres de la sección.
- ^ Este atributo de nivel de sesión también se aplica a los medios descritos a menos que el valor sea anulado por un atributo de nivel de medio.
Referencias
- ^ a b c Handley, Mark; Van Jacobson; Colin Perkins (julio de 2006). SDP: Protocolo de descripción de sesión . IETF . doi : 10.17487 / RFC4566 . RFC 4566 .
- ^ Salkintzis, Apostolis K. (2004). Internet móvil: tecnologías y servicios propicios . Prensa CRC. pag. 11: 24-25. ISBN 0849316316. Consultado el 11 de julio de 2019 .
- ^ Handley, Mark; Van Jacobson (abril de 1998). SDP: Protocolo de descripción de sesión . IETF . doi : 10.17487 / RFC2327 . RFC 2327 .
- ^ Begen, Ali; Mark Handley; P. Kyvizat; Colin Perkins (enero de 2021). SDP: Protocolo de descripción de sesión . IETF . doi : 10.17487 / RFC8866 . RFC 8866 .
- ^ Una descripción detallada de SDP Archivado el 13 de julio de 2011 en la Wayback Machine.
- ^ "Registro de los parámetros del SDP" . Autoridad de Números Asignados de Internet . Consultado el 15 de enero de 2021 .
- ^ Registro de codificaciones de juegos de caracteres, en el sitio de la Autoridad de números asignados de Internet
enlaces externos
- Rosenberg, J .; Schulzrinne, H. (junio de 2002). "Un modelo de oferta / respuesta con el protocolo de descripción de sesión (RFC 3264)" . IETF . Consultado el 25 de julio de 2010 .