Tema 5: Protocolos de establecimiento y control de sesiones

(1)

Dpto. de Ingeniería de Telecomunicación Área de Ingeniería Telemática

Universidad de Jaén E. P. S. de Linares 5.1 Introducción y problemática

5.2 Descripción de sesiones con SDP

5.3 Anuncio de sesiones mediante el protocolo SAP

5.4 El protocolo SIP para establecimiento de sesiones

Contenido

Tema 5 Protocolos de establecimiento y control de sesiones 2

Bibliografía

Ref

Weinstein, Stephen. “The Multimedia Internet", 2005, Springer. Gibson, Jerry D. “Multimedia Communications”, 2001, Academic Press.

Perkins, Colin. “RTP. Audio and Video for the Internet”. 2003. Pearson Education. Bibliografía básica

(2)

Universidad de Jaén E. P. S. de Linares [RFC 4566] SDP: Session Description Protocol.

M. Handley, V. Jacobson, C. Perkins Obsoletes: 2327, 3266. July 2006

[RFC 2974] Session Announcement Protocol C. Perkins E. Whelan

October 2000

[RFC 3261] SIP: Session Initiation Protocol

J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley y E. Schooler

June 2002

Bibliografía básica

Bibliografía

Ref

[RFC 2776 ] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone announcement protocol (MZAP)", February 2000.

[RFC 2630] Housley, R., "Cryptographic message syntax", June 1999. [RFC 2365] Mayer, D., "Administratively scoped IP multicast",July 1998.

(3)

Universidad de Jaén E. P. S. de Linares Sin duda, el concepto de sesión es uno de los que más importancia a adquirido en estos últimos tiempos dentro del entorno de Internet.

Aunque el enfoque de comunicaciones basadas en sesiones parezca que no ha estado presente en Internet hasta ahora, éstas siempre han estado presentes, aunque enmascaradas dentro de protocolos de aplicación destinados a otras tareas (SMTP, HTTP, FTP, etc.)

En la actualidad, debido a la gran variedad de servicios, aplicaciones, protocolos, tipos de contenidos y formas de transmisión, se hace necesario un tratamiento más pormenorizado de esta capa de la torre OSI, antes desestimada.

Introducción.

Tema 5 Protocolos de establecimiento y control de sesiones 6 Introducción y problemática

Una sesión, dentro del marco de las telecomunicaciones podría definirse como: una serie de interacciones entre dos o varios extremos de una conferencia, durante las cuales se negocian diferentes parámetros de la comunicación.

Normalmente una sesión no implica que se tengan que usar protocolos orientados a conexión, sino que todos los intercambios de información, ya sean a través de una o varias conexiones o por datagramas, seguirán las pautas y características negociadas en el establecimiento de la sesión.

Ejemplo:Una Sesión multimedia de RTP puede implicar el establecimiento de varias sesiones RTP para cada tipo de contenido.

5.1 Definición.

(4)

Universidad de Jaén E. P. S. de Linares Según el IETF, aparece una definición de Sesión Multimedia en la RFC del protocolo SDP:

Una sesión es un conjunto de transmisores y receptores de contenidos multimedia y los flujos de datos que fluyen desde los transmisores a los receptores. Una conferencia multimedia es un ejemplo de una sesión multimedia. (RFC 2327) Definición.

El uso de sesiones no es algo fortuito. Como ya se ha visto, la complejidad de las actuales comunicaciones por Internet requieren un proceso más cuidadoso y detallado que una simple conexión TCP.

Una sesión consta de varias fases como ya se vio en el tema pasado (establecimiento, transferencia de datos y liberación).

Sin duda es en la negociación durante el establecimiento donde se pone más énfasis, si bien, el control durante el periodo en el que se transmiten los datos es importante, sin un adecuado establecimiento, se puede realizar un derroche de recursos o incluso el no poder establecerla siquiera.

5.1

(5)

Universidad de Jaén E. P. S. de Linares Algunos de los aspectos más importantes que se acuerdan en el establecimiento de una sesión son:

Tipos de contenido (audio, video, …) Protocolos de transporte

Tipo de codificadores y calidad de los contenidos Calidad de Servicio

Nivel de acceso Seguridad

Tipo de difusión (unicast, multicast,…) Direcciones de red y transporte.

Datos de usuario (cuentas, permisos, movilidad,…) y metadatos. Problemática.

Además de las características anteriores para el control del establecimiento de una sesión, son necesarias también funciones que permitan el control de la sesión durante la transferencia de información, tales como:

Cambio de los parámetros negociados. Control sobre la movilidad de los usuarios. Control de nuevas incorporaciones a la sesión. Control de tarificación.

Finalización de sesiones. 5.1

(6)

Universidad de Jaén E. P. S. de Linares Actualmente existen diversos protocolos y normas que permiten realizar este control de sesiones de forma explícita y funcional.

En este tema estudiaremos aquellos que se encuentran dentro del ámbito de Internet. Protocolo de Descripción de Sesiones (Session Description Protocol, SDP). Protocolo de Anuncio de Sesión (Session Announcement Protocol, SAP). Protocolo de Inicio de Sesión (Session Initiation Protocol).

Problemática.

Tema 5 Protocolos de establecimiento y control de sesiones 12 Session Description Protocol (SDP)

Cuando se inician tele-conferencias multimedia, llamadas VoIP, streaming de video o cualquier otro tipo de sesiones, existen ciertos requerimientos para acordar los detalles de los medios, direcciones de transporte y otros meta-datos de las sesiones o los participantes.

SDP proporciona una representación estándar para tal información, sin importar como esa información es transportada. SDP es puramente un formato para la descripción de sesiones, no incorpora protocolos de transporte, pudiendo ser usado sobre diferentes protocolos de transporte como sea apropiado, incluyendo SAP, SIP, RTSP, e-mail usando extensiones MIME y HTTP.

SDP está descrito en la RFC 4566. 5.2

(7)

Universidad de Jaén E. P. S. de Linares SDP está pensado para ser de propósito general y puede ser usado por una amplia gama de entornos de red y aplicaciones.

Sin embargo no aportan ningún mecanismo para la negociación del contenido de sesiones o codificación de medios. Esto queda fuera de la descripción de la sesión. Según la RFC 4566, una “descripción de sesión” se define como sigue:

Un formato bien definido para contener información suficiente para descubrir y participar en una sesión multimedia.

Introducción.

Extraído de la RFC 2327: v=0

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar

i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (Mark Handley)

c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait 5.2

(8)

Universidad de Jaén E. P. S. de Linares Debido al carácter genérico de SDP permite su uso dentro de la información de sesiones multimedia en una amplia variedad de situaciones, las más usuales aparecen comentadas a continuación:

Inicio de Sesiones. Streaming Media.

E-mail y World Wide Web Anuncio de Sesiones Multicast. Ejemplo de uso de SDP

Inicio de Sesiones

El Protocolo SIP (Session Initiation Protocol), es un protocolo de control a nivel de aplicación para la creación, modificación y terminación de sesiones tales como conferencias multimedia por Internet, llamadas telefónicas por Internet y distribución multimedia.

Los Mensajes SIP usados para crear las sesiones portan descripciones de las sesiones que permiten a los participantes acordar que tipo de medio usar entre los que son compatibles.

Estas descripción de sesiones están comúnmente formateadas usando SDP. 5.2

(9)

Universidad de Jaén E. P. S. de Linares Streaming Media

El protocolo RTSP (Real Time Streaming Protocol) es un protocolo de aplicación para el control de la transmisión de datos con propiedades de tiempo real.

RTSP proporciona un marco extensible para permitir la descarga controlada de datos en tiempo real bajo demanda, tales como audio y video.

Un cliente y un servidor RTSP negocian un juego apropiado de parámetros para la distribución de medios, usando parcialmente la sintaxis SDP para describir tales parámetros.

Ejemplo de uso de SDP

E-mail y World Wide Web

Una manera alternativa de portar descripciones de sesiones se incluye en el correo electrónico y en la WWW. Para ambos, existe un tipo especial “application/sdp”.

Esto permite el lanzamiento automático de aplicaciones para participar en las sesiones WWW o de e-mail en una manera estándar.

Se debe recordar que los anuncios de sesiones multicast lanzados por vía e-mail o WWW, no tienen la propiedad de que el receptor del anuncio de la sesión pueda necesariamente recibir dicha sesión, ya que ésta puede estar limitada a un entorno concreto, limitación que puede no afectar al e-mail o la web.

5.2

(10)

Universidad de Jaén E. P. S. de Linares Anuncio de Sesiones Multicast.

Con la intención de poder asistir al anuncio de conferencias multimedia multicast o cualquier otro tipo de sesiones multicast, y para poder comunicar la información de configuración de la sesión más importante a los participantes, se debe usar un directorio distribuido de sesiones.

Una instancia de ese directorio distribuido periódicamente envía paquetes conteniendo la información de la sesión a un grupo multicast bien-conocido (well-known)

Estos anuncios son recibidos por otros directorios de sesión de tal forma que participantes remotos potenciales pueden usar la información de descripción de sesión para arrancar la aplicaciones necesarias para participar en la sesión. Un protocolo que implementa tal directorio distribuido es SAP (Session Announcemente Protocol). SDP proporciona el formato adecuado para tales anuncios de sesión.

Ejemplo de uso de SDP

El propósito de SDP es comunicar la información acerca de los streams de medios en las sesiones multimedia para permitir a los receptores de la descripción de una sesión participar en la misma.

SDP está pensado primordialmente para ser usado en un entorno inter-redes, sin embargo es suficientemente general para describir sesiones en cualquier otro entorno de red.

Los flujos multimedia pueden ser muchos a muchos y además, las sesiones no tienen por qué estar continuamente activas.

5.2

(11)

Universidad de Jaén E. P. S. de Linares Teniendo en cuenta la gran variedad de conferencias multimedia multicast que puede existir, y el hecho de que cualquiera dentro de Internet puede ver el contenido uniéndose a dicha sesiones (salvo que fuera encriptado), SDP solventa esto sirviendo a dos propósitos principales:

Comunicar la existencia de una sesión

Comunicar información suficiente para permitir que un participante nuevo se una a la sesión adecuadamente.

En entornos unicast tan sólo el segundo aspecto es relevante. Requisitos y Recomendaciones de SDP

Una descripción SDP incluye lo siguiente: Nombre de sesión y propósito de la misma.

Tiempo (o tiempos) en los que la sesión estará activa. Los tipos de contenido que comprenden la sesión

Información necesaria para recibir esos contenidos (direcciones, puertos, formatos, etc.) Como los recursos necesarios para participar en una sesión pueden ser limitados, puede ser deseable alguna información adicional.

Información acerca del ancho de banda que va a ser usado durante la sesión. Información de contacto de la persona responsable de la sesión.

En general SDP deber portar suficiente información para permitir a las aplicaciones unirse a una sesión (con la posible excepción de las claves de encriptado) y anunciar los recursos necesarios a los usuarios no participantes.

5.2

(12)

Universidad de Jaén E. P. S. de Linares Una descripción de sesión SDP se denota por el tipo de contenido “application/sdp”. Una descripción de sesión SDP es enteramente textual usando el juego de caracteres ISO 10646 con codificación UTF-8. Los nombres de campo usan el subconjunto US-ASCII, pero los campos textuales y atributos pueden usar el conjunto de caracteres completo de la ISO 10646.

Los valores de los campos y de los atributos que usan el juego de caracteres completo UTF-8

Especificación de SDP

Una descripción de sesión SDP consiste en un número de líneas de texto en el siguiente formato:

Donde < tipo > debe ser exactamente uno de los caracteres (importan las mayúsculas) y <valor> es texto estructurado cuyo formato depende del < tipo >. En general, <valor> es cualquier número de campos delimitados por un simple carácter espacio o una cadena de formato libre y es sensible a mayúsculas, salvo que el <tipo> especifique otra cosa. Los espacios no deben ser usados a cualquier lado del signo “=”.

5.2

(13)

Universidad de Jaén E. P. S. de Linares Una descripción de sesión SDP consiste en una sección de nivel de sesión seguida de ninguna o más secciones de nivel de contenidos.

Las partes de nivel de sesión comienzan con una línea “v=” y continúan hasta la primera sección de nivel de contenidos.

Cada sección de nivel de contenido comienza con una línea “m=” y continua hasta la próxima sección de contenidos o hasta el final de la descripción de la sesión completa.

Algunas líneas en cada descripción son obligatorias y otras opcionales pero todas deben aparecer en el orden exacto dado en la RFC. Esto se ha hecho así para facilitar la detección de errores y el procesado de la información. Los campos opcionales están marcados con un asterisco “*”. Especificación de SDP

v= (versión de protocolo)

o= (Creador e Identificador de sesión) s= (Nombre de la sesión)

i=* (Información de la sesión) u=* (URI de la descripción) e=* (Dirección de e-mail) p=* (Número de teléfono)

c=* (Información de conexión, no se requiere si se incluye en todos los contenidos) b=* (Ninguna o más líneas de información de ancho de banda)

Una o más descripciones de tiempo (Líneas "t=" y "r=“) z=* (Ajustes de zona horaria)

k=* (Clave de encriptado)

a=* (ninguna o más líneas de atributos de sesión) Ninguna o alguna descripción de contenidos 5.2

(14)

Universidad de Jaén E. P. S. de Linares Descripción de tiempo

t= (Tiempo en el que la sesión está activa) r=* (Ninguno o más tiempos de repetición) Descripción de Contenidos (si ésta presente) m= (Nombre del medio y dirección de transporte) i=* (Título del contenido)

c=* (Información de conexión – Opcional si se incluye a nivel de descripción de sesión) b=* (ninguno o varias líneas de información de ancho de banda)

k=* (clave de encriptación)

a=* (ninguno o varias líneas de atributos de contenidos)

Especificación de SDP. Descripción de tiempo y contenidos (media) de una sesión

El conjunto de letras de tipo es deliberadamente pequeño y no está pensado para ser extensible. Un analizador SDP debe ignorar completamente cualquier descripción de sesión que contenga una letra que no entienda.

El mecanismo de atributos (“a=”) es la forma de extender SDP y ajustarlo para aplicaciones o contenidos particulares. Además un analizador SDP debe ignorar cualquier atributo que no entienda.

Una descripción de sesión SDP puede contener URIs que referencien contenido externo, haciendo que la propia descripción no sea auto contenida ("u=", "k=", y "a=")

La información de conexión (“c=“) y de atributos (“a=“) en la sección de nivel de sesión se aplica a todo el contenido de esa sesión a menos que sea sobre escrito por los mismos campos en la especificación de cada contenido.

5.2

(15)

Universidad de Jaén E. P. S. de Linares

v=0

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.example.com/seminars/sdp.pdf

e=[email protected] (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 Especificación de SDP. Ejemplo

SDP no ejerce ningún mecanismo de seguridad o autenticación, relegando esto a los protocolos que lo usen.

Además, como las descripciones especifican que tipo de contenido va, las aplicaciones que se puedan iniciar a partir de fuentes SDP no confiables, no serán nada peligrosas.

Protocolos como SAP que tienen autenticación y cifrado son recomendables para el intercambio seguro de información SDP.

De esta manera los campos “k=“ no deben ser usados salvo que las descripciones SDP vayan por un canal seguro.

5.2

(16)

Universidad de Jaén E. P. S. de Linares El protocolo Session Announcement Protocol (SAP) es un protocolo de aviso usado para asistir a la publicación de anuncios de conferencias multimedia y cualquier tipo de sesiones multicast, y para comunicar información importante de configuración de la sesión a los posibles participantes.

Para llevar esta tarea a cabo se puede usar un directorio distribuido de sesiones. Una instancia de tal directorio periódicamente enviaría paquetes multicast que contendrían la descripción de la sesión, y al ser recibidos esos avisos por otros directorios distribuidos permitiría que participantes potenciales iniciasen las herramientas necesarias para adscribirse a la sesión.

El protocolo SAP en su segunda versión aparece descrito en la RFC 2974. Introducción

Tema 5 Protocolos de establecimiento y control de sesiones 32 Session Announcement Protocol (SAP)

A continuación se enumeran algunos términos recogidos en la RFC que servirán para un mejor seguimiento de la misma:

Anunciador SAP (SAP announcer): Equipo/host de la red que envía paquetes multicast a direcciones y puertos bien conocidos para comunicar la existencia y configuración de una sesión multicast.

Espectador SAP (SAP listener): Cualquier equipo/host que escucha en las direcciones y puertos que usa SAP para anunciar las sesiones multimedia.

5.3

(17)

Universidad de Jaén E. P. S. de Linares Un anunciador SAP periódicamente envía por multicasting un paquete de anuncio a una dirección y puertos multicast bien conocidos.

Este anuncio es enviado dentro del mismo ámbito para el cual se ha creado la sesión, asegurando así que todos los participantes potenciales puedan unirse a la sesión (salvo restricciones de acceso o permiso).

Esto es importante además para la escalabilidad del protocolo, haciendo que sesiones locales se mantengan locales.

El proceso normal para un espectador SAP es escuchar en una dirección multicast y puerto concreto para detectar si hay sesiones a las que podría unirse.

Introducción

Como se ha comentado anteriormente, un Anunciador SAP envía periódicamente paquetes de anuncio a una dirección multicast y puerto bien conocidos.

Sin embargo, esto no es un mecanismo de citación, el anunciador SAP no es advertido en ningún momento de la presencia de ningún Espectador SAP y además no se proporciona ningún mecanismo que asegure la transferencia de estos paquetes más allá del best-effort de UDP/IP.

Dichos anuncios contienen una descripción de la sesión y debería contener una cabecera de autenticación. La descripción de sesión puede estar encriptada, a pesar de todo, no se recomienda.

5.3

(18)

Universidad de Jaén E. P. S. de Linares Los anuncio multicast, como se ha visto se envían dentro del ámbito de la sesión, existiendo varias posibilidades:

IPv4.

Sesiones de ámbito global usan las direcciones multicast en el rango 224.2.128.0 -224.2.255.255 y los anuncios SAP son enviados a la dirección 224.2.127.254 (se debe recordar que la dirección 224.2.127.255 es usada por la versión SAPv0 y no se debe usar)

Sesiones con el ámbito administrativousando el ámbito administrativo de IP multicast, rango 239.0.0.0 to 239.255.255.255 (ver RFC 2776). En este caso la dirección multicast usada para los avisos es la más alta dentro del rango de una zona administrativa. Por ejemplo en un rango 239.16.32.0 - 239.16.33.255, se usaría para SAP la 239.16.33.255.

Anuncio de Sesiones. Direcciones

IPv6.

Las sesiones IPv6 son anunciadas en la dirección FF0X:0:0:0:0:0:2:7FFE, donde X es el valor de 4 bits que marca el ámbito de la sesión.

Por ejemplo un anuncio para una sesión de un enlace local en la dirección FF02:0:0:0:0:0:1234:5678, debería ser anunciado en la dirección SAP FF02:0:0:0:0:0:2:7FFE.

Tanto en IPv4 como IPv6, SAP no asegura que una descripción de sesión no pueda ser usada por un participante fuera del ámbito de la sesión.

5.3

(19)

Universidad de Jaén E. P. S. de Linares Los anuncios SAP deben ser siempre enviados al puerto 9875 y deberían ser enviados con un tiempo de vida IP 255 (en este caso la limitación de ámbito de IP multicast se desaconseja)

Si una sesión usa direcciones en varios rangos de ámbitos administrativos, es necesario que un Anunciador SAP envíe copias idénticas de los anuncios a cada uno de los ámbitos administrativos. El intervalo de anuncio de cada ámbito administrativo debe ser siempre calculado separadamente.

Para proporcionar mayor robustez ante la pérdida de paquetes varios anunciantes pueden anunciar la misma sesión. El intervalo de repetición debe ser escalado entre todos para que resulte igual que si sólo hubiera un anunciante SAP.

Anuncio de Sesiones

Si se hacen múltiples anuncios para una misma sesión, entonces cada unos de ellos debe llevar una cabecera idéntica y firmada por la misma clave, o serán tratados como anuncios completamente diferentes.

Un Espectador SAP IPv4 debería escuchar en las direcciones SAP de ámbito global y de cada ámbito administrativo del que formara parte.

El descubrimiento de las zonas administrativas queda fuera de la especificación de SAP. Un espectador SAP IPv6 debería escuchar también en el rango de direcciones SAP de IPv6.

5.3

(20)

Universidad de Jaén E. P. S. de Linares Intervalo de anuncio.

El período de tiempo entre las repeticiones de los anuncios SAP se elige de tal manera que el ancho de banda consumido por todos los anuncios de un solo grupo SAP permanece por debajo de un límite dado, que por defecto es 4000 bits/s.

Se espera que cada anunciante escuche otros anuncios para determinar el número total de sesiones que están siendo anunciadas dentro de un grupo en particular. Estas sesiones son identificadas únicamente por la combinación del hash del identificador de mensaje y los campos de la fuente originaria de la cabecera SAP.

Anuncio de Sesiones.

Las sesiones pueden ser eliminadas en los siguientes casos:

Expiración explícita por temporización: Debido a que las descripciones de sesión puede llevar información concreta con los tiempos de comienzo y final, si la hora del sistema es posterior al tiempo de finalización a la hora de hacer al anuncio, esta sesión debería ser eliminada de la caché de sesiones del anunciante.

Expiración implícita de temporización:Si un Espectador lleva sin recibir 10 avisos (en el intervalo estimado) o ha pasado una hora sin recibir ninguno la sesión se elimina de la caché del receptor.

Borrado explícito:Cuando se recibe un paquete de borrado válido y autenticado. 5.3

(21)

Universidad de Jaén E. P. S. de Linares Una sesión puede ser modificada simplemente cambiando la descripción de la sesión que porta el anuncio.

En este caso, el hash de la versión de la sesión debe ser cambiado en la cabecera SAP para indicar a los Espectadores SAP que deben chequearlo de nuevo.

Modificación de sesiones.

5.3

(22)

Universidad de Jaén E. P. S. de Linares V (3 bits): Campo de número de versión. Debe establecerse a 1.

A (1 bit): Tipo de dirección.

0: El campo de fuente originaria contiene una dirección de 32-bits IPv4. 1: El campo de fuente originaria contiene una dirección de 128-bits IPv6 R (1 bit): Reservado. Los anunciantes SAP lo establecen a 0 y los espectadores SAP lo ignoran.

T (1 bit): Tipo de mensaje. 0: Paquete de anuncio de sesión. 1: Paquete de borrado de sesión. Formato de los paquetes.

E (1 bit): Bit de encriptación.

1: El payload del paquete SAP está encriptado y el campo de expiración (timeout) debe ser añadido a la cabecera del paquete.

0: El paquete no está encriptado y el timeout no debe estar presente. C (1 bit): Bit de compresión. Si es 1 el payload está comprimido.

Longitud de autenticación (8 bits): Un valor entero sin signo que da el número de palabras de 32 bits que siguen a la cabecera principal SAP que contienen datos de autentificación. Si es 0, es que no hay cabecera de autenticación.

Hash Identificador de Mensaje: Se usa en combinación con la fuente originaria y provee un identificador único global que indica la versión precisa de un anuncio. 5.3

(23)

Universidad de Jaén E. P. S. de Linares Fuente originaria: Este campo contiene la dirección IP de la fuente original del anuncio. Es una dirección IPv4 si el campo A=0 o IPv6 si A=1. La dirección se almacena en el orden de red.

Expiración (Timeout): Cuando el payload está encriptado, los espectadores SAP que no pueden descifrar el contenido al no poseer la clave pueden mirar este campo para saber cuando expirará la sesión. El formato de este campo es un entero sin signo que marca los segundos NTP.

Tipo de Payload: Contiene un tipo de contenido MIME, describiendo el tipo de payload. Es un campo de texto ASCII, seguido de un byte a cero (ASCII NUL).

Payload: El campo payload incluye varios sub-campos. Formato de los paquetes.

Tema 5 Protocolos de establecimiento y control de sesiones 46 Session Initiation Protocol (SIP)

SIP es un protocolo simple de señalización para crear, modificar y terminar llamadas de teléfono y sesiones multimedia.

SIP es la alternativa al ITU-T H.323 y fue desarrollado dentro del grupo de trabajo del IETF Multiparty Multimedia Session Control (MMUSIC).

Es un protocolo ligero (light-weight) basado en un esquema cliente-servidor que usa el direccionamiento de Internet y el protocolo HTTP.

Las peticiones y respuestas SIP están codificadas como texto y usan para su transferencia diferentes protocolos de transporte, como por ejemplo RTP.

5.4

(24)

Universidad de Jaén E. P. S. de Linares SIP hace uso de servidores proxy para ayudar a enrutar las peticiones de localización actual del usuario, autenticación y autorización de usuarios para acceso a servicios, implementar políticas de enrutado de llamadas de los proveedores de servicio y proporcionar un juego de características y capacidades al usuario.

SIP también proporciona una función de registro que permite a los usuarios informar al servidor proxy de su localización actual.

SIP funciona igualmente sobre IPv4 e IPv6. Introducción.

SIP es un protocolo de control de la capa de aplicación con las siguientes capacidades: Establecer, modificar y terminan sesiones multimedia (por ejemplo llamadas VoIP) Invitar participantes a sesiones ya existentes, tales como conferencias multicast. Contenidos y medios pueden ser añadidos o eliminados de una sesión existente. Mapeo de nombre y servicios de redirección transparentes, lo cual proporciona movilidad personal (los usuario tienen un identificador visible independiente de su posición en la red)

5.4

(25)

Universidad de Jaén E. P. S. de Linares SIP aporta cinco aspectos del establecimiento y terminación de comunicaciones multimedia:

Ubicación de Usuario: Determinación del sistema final que va a ser usado para la comunicación.

Disponibilidad de usuario: Determinación del deseo de la parte llamada de establecer la comunicación.

Capacidades de usuario: Determinación de los contenidos y los parámetros de los mismos a ser usados.

Establecimiento de sesión: llamada, establecimiento de los parámetros de la sesión tanto para la parte llamante como la llamada.

Gestión de sesión: Incluye la transferencia y terminación de sesiones, modificación de parámetros e invocación de servicios.

Funcionalidad de SIP.

SIP no está integrado verticalmente en los sistemas de comunicación.

SIP es más un componente a ser usado por otros protocolos IETF para construir una arquitectura multimedia completa. Normalmente estas arquitecturas incluyen protocolos tales como:

RTP para transmitir los datos de tiempo real y dar información de QoS. RTSP para proporcionar control del contenido enviado.

El Media Gateway Control Protocol (MEGACO) (RFC 3015) para controlar las pasarelas a las Redes Públicas Telefonía.

SDP para describir las sesiones multimedia.

A pesar de todo la funcionalidad de SIP no dependen de estos protocolos. 5.4

(26)

Universidad de Jaén E. P. S. de Linares SIP no proporciona servicios, aunque si proporciona primitivas que pueden ser usadas para implementar diferentes servicios.

Ejemplo:

SIP puede localizar un usuario y enviarle un objeto opaco a su posición actual. Si esa primitiva se usa para enviar una descripción de sesión usará SDP y de esta manera los extremos podrían acordar los parámetros de una sesión. Si la misma primitiva se usa para enviar una foto del llamante así como se envió una descripción SDP se podrían implementar fácilmente un sistema de reconocimiento de la identidad del llamante. Así puede verse como la misma primitiva puede usarse para varios servicios. Funcionalidad de SIP.

SIP no ofrece servicios de control de conferencias tales como moderación, permiso para hablar o voto, y no prescribe como debe ser gestionada una conferencia. SIP puede ser usado para iniciar una sesión que use cualquier otro protocolo de control de conferencias.

Además, debido a que SIP puede pasar por innumerables tipos de redes, no proporciona ningún mecanismo de reserva de recursos.

Debido a la naturaleza de los servicios prestados por SIP, hace que la seguridad sea un aspecto muy importante. Así, SIP proporciona un paquete de servicios de seguridad, entre los cuales están la prevención del ataque de denegación de servicio, autenticación (tanto de usuario-usuario como proxy-usuario), protección de integridad, cifrado y servicios de privacidad.

5.4

(27)

Universidad de Jaén E. P. S. de Linares SIP usa direcciones con el formato de las de correo electrónico:

Ejemplo: [email protected], [email protected]

Normalmente estas direcciones coincidirán con las de correo electrónico. El formato de la URL será el siguiente: sip:[email protected]

Y para teléfonos o faxes: tel:+34555123123, fax:+34555123123

Y se pueden añadir parámetros tales como user=“phone” o el protocolo de transporte usado.

Direccionamiento SIP.

A continuación se va a ver la forma en que SIP opera para un ejemplo concreto: Localización de un punto final.

Señal de que existe un deseo de comunicar.

Negociación de los parámetros de la sesión para establecer la misma. Terminación de la sesión una vez establecida.

5.4

(28)

Universidad de Jaén E. P. S. de Linares En la figura siguiente se ve un ejemplo típico de un intercambio típico de mensajes SIP entre dos usuarios (Alice y Bob).

Cada mensaje se ha numerado con la letra F y el número de referencia para poder referenciarlos en la explicación.

En el ejemplo Alice usa una aplicación SIP en su PC (softphone) para llamar a Bob a su teléfono SIP a través de Internet.También se muestran los dos servidores proxy que actúan en representación de ambos.

Este esquema típico se denomina a menudo como el “Trapezoide SIP” por la figura que forman las líneas de puntos.

Modo de operación de SIP.

Sessi on In it ia ti on Pr o tocol (S IP) atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . Bob's

softphone SIP Phone

| | | | | INVITE F1 | | | |--->| INVITE F2 | | | 100 Trying F3 |--->| INVITE F4 | |<---| 100 Trying F5 |--->| | |<--- | 180 Ringing F6 | | | 180 Ringing F7 |<---| | 180 Ringing F8 |<---| 200 OK F9 | |<---| 200 OK F10 |<---| | 200 OK F11 |<---| | |<---| | | | ACK F12 | |--->| | Media Session | |<================================================>| | BYE F13 | |<---| | 200 OK F14 | |--->| 5.4 Modo de oper aci ó n d e S IP.

(29)

Universidad de Jaén E. P. S. de Linares Mensaje de Invitación.

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]> Content-Type: application/sdp

Content-Length: 142

(No se muestra la información SDP de Alice)

MÉTODO SIP

PARÁMETROS DE CABECERA

Mensaje de Invitación (descripción). INVITE: Método SIP

Via: Especifica el lugar donde se pretenden recibir las respuestas y un identificador de la transacción.

To: Muestra un nombre para mostrar y un URI SIP del destinatario

From: Muestra un nombre para mostrar y un URI SIP del llamante (la etiqueta la añade el software por motivos de identificación)

5.4

(30)

Universidad de Jaén E. P. S. de Linares Mensaje de Invitación (descripción).

Call-ID: Contiene un identificador único global para esta llamada generado por una cadena aleatoria el nombre de host del softphone o la dirección IP. La combinación de la etiqueta de To: y el Call-ID define completamente una relación SIP entre Alice y Bob y se denomina DIÁLOGO. Cseq (Command Sequence): Contiene un número entero y el método. Es un número de secuencia tradicional que se incrementa para cada nueva petición dentro de un diálogo.

Contact: Contiene un URI SIP o SIPS que representa una ruta directa para contactar con Alice, normalmente un nombre de usuario y un nombre de dominio cualificado completo (FQDN). También se permiten direcciones IP

Mensaje de Invitación (descripción).

Max-Forwards: Se utiliza como un límite para el número de saltos que la petición puede dar en su camino a su destino. Es un entero qeu se decrementa en uno para cada salto. Content-Type: Contiene la descripción del tipo de contenido del cuerpo del mensaje. Content-Length: Longitud en octetos del cuerpo del mensaje.

5.4

(31)

Universidad de Jaén E. P. S. de Linares Respuestas a los mensajes SIP.

Las respuestas en SIP usan un código de tres dígitos seguido por una frase de descripción.

Las respuestas contienen los mismos To, From, Call-ID, Csep and branch del parámetro Via del método INVITE.