ndice de contenidos

Introduccin

Por qu SIP? Qu es SIP?

Direccionamiento en SIP Entidades funcionales Mensajes en SIP Registro de usuarios Control de sesin

Establecimiento de sesin Modificacin de sesin Liberacin de sesin

Descripcin de sesiones multimedia Extensiones a SIP

1

Introduccin

Las redes basadas en IP proliferan hoy en da:

Internet, obviamente Redes privadas (corporativas, en centros educativos, en organismos de todo tipo, instalaciones particulares) Utilizando todo tipo de protocolos de enlace: Ethernet, ADSL, WiFi... Habr nuevas en el futuro prximo: IMS de 3GPP

Sobre todas estas redes, cada vez es ms importante/ interesante desarrollar aplicaciones/servicios multimedia:

Voz, msica, vdeo, datos asociados

El desarrollo de estas aplicaciones se basa en el Modelo de Servicio IP

Separacin del nivel de transporte y aplicacin

Cualquiera con conectividad IP puede ser un proveedor de servicios

Ej: instalar un servidor WEB

Diseo multimedia: protocolos necesarios

Protocolos de Transporte de Medios:

Protocolos de Transporte para la transmisin de datos en tiempo real (ej. audio/video)

Protocolos de Sealizacin:

Protocolos para indicar presencia, localizar usuarios, iniciar, modificar y terminar sesiones multimedia

Protocolos de Ayuda:

Protocolos que realizan las funciones de localizacin de servicios, calidad de servicio, autenticacin, autorizacin y accounting, traduccin de direcciones, etc.

Ejemplos de protocolos

Transporte de Medios:

RTP (datos con propiedades en tiempo real) Otros protocolos de Transporte: UDP y TCP. SIP/SDP (IETF) H.323 (ITU-T) Nota: SIP ha sido adoptado por el 3GPP y ETSI, como protocolo de sealizacin para redes 3G/4G DNS RSVP - Resource Reservation Setup Protocol COPS - Common Open Policy Service protocolo para ayudar al control de la QoS Diameter - Authentication, Accounting, Authorization
4

Sealizacin:

Protocolos de Ayuda:

Conjunto de Protocolos

Historia de SIP

Versin 1.0 publicada en 1997 como borrador de RFC de IETF:

Desarrollado inicialmente por el grupo de trabajo MMUSIC (Multi-Party Multimedia Session Control).

Versin 2.0 publicada en 1998. Alcanz status de RFC (2543) en Abril 1999. En Septiembre 1999 se cre el grupo SIP en IETF. En Julio 2000 se public una versin revisada y mejorada del estndar (RFC 2543 bis), finalmente denominada RFC 3261 (completada luego con muchos otros RFCs). Principales gurs de SIP: Henning Schulzrinne (Universidad de Columbia) y Gonzalo Camarillo (Ericsson SE).

Qu es SIP

SIP es un protocolo del IETF (RFC 3261) que

Proporciona funciones parecidas a las de los protocolos de sealizacin clsicos, pero sobre redes de datos Permite establecer, modificar y terminar sesiones multimedia entre dos o ms participantes, e invitar a participantes en dichas sesiones Funciona al nivel de aplicacin del modelo TCP/IP Es independiente del protocolo de transporte sobre el que se transmite SIP (TCP, UDP u otros) Utiliza mensajes de texto, siguiendo un modelo peticinrespuesta similar al de HTTP o al de SMTP Utiliza un conjunto reducido de entidades que interactan (User Agents y varios tipos de Servers) El encaminamiento de los mensajes de SIP es completamente independiente del de los datos de las sesiones que establece
7

Funciones de SIP

SIP lleva a cabo 5 funciones bsicas:

Determinar la localizacin de puntos finales de comunicacin (usuarios) Contactar puntos finales para determinar su disponibilidad para establecer una sesin de comunicacin multimedia Permitir intercambiar las capacidades de comunicacin multimedia de los puntos finales para determinar los parmetros a utilizar en una sesin Establecer sesiones de comunicacin multimedia Modificar sesiones de comunicacin multimedia, incluyendo la transferencia y finalizacin de sesiones, as como la modificacin de los parmetros de la sesin
8

Qu no es SIP

SIP no es un protocolo que proporciona de forma integrada comunicaciones multimedia, y por ello se utiliza en conjuncin con otros protocolos:

SIP no permite la descripcin de sesiones multimedia (qu direcciones IP y puertos utilizar, qu codificadores usar, etc.)

Para ello, se puede usar SDP (Session Description Protocol)

SIP no proporciona la reserva de recursos para sesiones multimedia

Para ello se pueden usar otros protocolos como RSVP (Reservation Protocol) y extensiones sobre SIP;

SIP no participa de ningn modo en la transmisin de la informacin multimedia

Para ello: RTP (Real-time Transport Protocol), RTCP (RTP Control Protocol)o directamente UDP

Grupos de Trabajo del IETF

SIP: Session Initiation Protocol

SIPPING: Session Initiation Proposal Investigation MMUSIC: Multiparty Multimedia Session Control IPTEL: Internet Telephony AVT: Audio Video Transport MIDCOM: Firewall/NAT Traversal SIMPLE: SIP for Instant Messaging and PresenceLeveraging

10

Ejemplo de operacin: llamada voz

Telfono Alice
Alice llama a Bob usando su identificador SIP

Proxy atlanta.com INVITE TRYING TRYING INVITE

Proxy biloxi.com

Telfono Bob
El telfono de Bob recibe la indicacin de llamada entrante, comienza a sonar y enva una indicacin al telfono de Alice

INVITE

Alice recibe una indicacin de que la llamada est en progreso Alice recibe una indicacin de que la llamada se ha establecido

RINGING

RINGING OK

RINGING OK

OK

Bob acepta la llamada

ACK

Sesin de audio RTP

11

Identificacin de usuarios

SIP identifica usuarios mediante URIs SIP

URI = Uniform Resource Identifier Formato URI SIP: sip: [userinfo] hostport [parameters]
userinfo:

contiene informacion sobre el usuario, seguida de una letra @ contiene un nombre de dominio o una direccin IP. Adicionalmente, puede incluir un numero de puerto contiene parmetros adicionales. Se indican tras el carcter ;

hostport:

Parameters:

Ejemplos:
sip:Alice.Smith@domain.com sip:carol@ws1234.domain2.com;transport=tcp sip:bob@163.117.139.101:5060
12

Elementos de SIP Esquema general

En cada interaccin utilizando SIP participan dos entidades:

Aunque lo ms habitual es que los usuarios se comuniquen a travs de un servidor (de los que hay varios tipos): Servidor SIP

13

Elementos de SIP User Agents

En realidad, un usuario de SIP utiliza un User Agent para enviar y recibir mensajes SIP:

Muchos dispositivos pueden proporcionar un User Agent: telfonos (fijos o mviles), ordenadores, televisores, sistemas automatizados tipo ACD/VRU, etc. En el User Agent se pueden distinguir un User Agent Client (UAC) y un User Agent Server (UAS):

Un UAC es una aplicacin cliente que crea peticiones SIP (requests) Un UAS es una aplicacin servidor que interacta con el usuario cuando se recibe una peticin SIP, y que contesta a las mismas (genera respuestas)

14

Elementos de SIP User Agents

Ejemplos de Agentes de Usuario en el mercado:

Teldat Di-Voz 50

Thomson ST 2022

Linksys WIP330

15

Elementos de SIP Servidores (1)

Un tipo de servidor SIP es el denominado Registradores (Registrar Server):

Un Registrar gestiona la informacin de localizacin de usuarios en un determinado dominio En SIP, los usuarios pueden indicar la asociacin entre su URI SIP pblica y las direcciones en las que desean ser contactados en un momento dado;

Se realiza mediante una solicitud de SIP de tipo REGISTER Los usuarios pueden modificar dichas asociaciones mediante solicitudes de tipo REGISTER

As, un Registrar es un servidor especializado en aceptar y procesar Requests de tipo REGISTER Un Registrar utiliza un servicio de almacenamiento y gestin de la informacin de localizacin, que puede residir en el propio servidor o ser completamente externo (por ejemplo, usando LDAP); aspecto no estandarizado
16

Elementos de SIP Servidores (2)

Un segundo tipo de servidor SIP es el denominado Redirectores (Redirect Server):

Un Redirect recibe solicitudes de clientes o servidores SIP, obtiene la asociacin entre la URI SIP del usuario al que se intenta contactar y sus direcciones de contacto actualizadas, y devuelve dichas direcciones de contacto al peticionario Los Redirect pueden requerir autentificacin a los peticionarios El funcionamiento de los servidores de tipo Redirect es sencillo, lo que les permite presentar altos rendimientos.

El servidor proporciona informacin sobre la localizacin del destino de la solicitud El servidor no necesita participar en el encaminamiento de la solicitud

17

Elementos de SIP Servidores (3)

El tipo de servidor SIP ms habitual es el denominado Proxy:

Un servidor proxy acta siempre encaminando solicitudes hacia UASs, o encaminando respuestas hacia UACs Pueden existir varios proxies a travs de los que una determinada solicitud deba pasar para ir del UAC origen al UAS destino Cualquier proxy puede tomar decisiones sobre el encaminamiento de una solicitud, o incluso puede llegar a modificarla antes de reenviarla al siguiente paso La respuesta a una solicitud determinada sigue exactamente el mismo camino (a la inversa) que sigui la solicitud original; es decir, que atraviesa los mismos proxies; Por lo tanto, la manera ms sencilla de interpretar un proxy es como un router para mensajes SIP, pero adems con capacidad para interpretar, validar, redirigir, duplicar o eliminar dichos mensajes, as como autentificar usuarios y otras funcionalidades avanzadas.

18

Elementos de SIP Servidores (4)

Sin embargo, los proxies estn diseados para ser relativamente transparentes a los usuarios, y no pueden actuar de forma arbitraria sobre los mensajes SIP:

Un proxy no puede modificar la parte SDP de un mensaje INVITE (ver ms adelante) En general, los proxies no pueden iniciar solicitudes por si mismos Un proxy no puede terminar una sesin mediante un mensaje BYE

19

Elementos de SIP Servidores (5)

Ejemplos de aplicaciones de los servidores proxy:

Servidores proxy del operador de la red:

Servidores

de acceso (edge proxies); Servidores centrales (core proxies);

Servidores proxy para grandes clientes (enterprise proxies); Servidores para autentificacin de usuarios; Servidores para el control de acceso a la red basados, por ejemplo, en el saldo de los usuarios o en la hora de acceso; Servidores de interfaz con usuarios; Servidores de interfaz con otras redes; Servidores de acceso a otros servicios de la red (como por ejemplo, localizacin); Etc.

20

Elementos de SIP Servidores (6)

En la RFC 3261 se definen otros nuevos tipos de servidores SIP, adicionales a los tradicionales examinados hasta el momento; Back-to-back User Agent (B2BUA):

Se comporta simultneamente como un UAS y un UAC;

Un B2BUA recibe solicitudes y las procesa como si fuera un UAS Puede generar solicitudes hacia otros servidores o UAs, como un UAC

En muchos aspectos su comportamiento es muy similar al de un proxy (de tipo stateful, como es obvio), pero tienen mayor libertad:

Pueden desconectar un lado de la sesin, y reconectarlo de nuevo con otro usuario, con otros, con el mismo en otra localizacin, etc. Pueden iniciar sesiones por su cuenta, terminarlas sin intervencin de usuarios (prepago), modificar la estructura de la sesin, etc.

21

Mensajes de SIP Generalidades

SIP est basado en HTTP

Es un protocolo solicitud-respuesta (request-response) Todos los mensajes de SIP son legibles (se codifican como texto, al estilo de HTTP SMTP)

Formato de un mensaje SIP

<start-line> Campos de cabecera Lnea en blanco <Cuerpo de mensaje> (body)

Los campos de cabecera tienen el formato <nombre>:<valor> El cuerpo del mensaje es opcional
22

Mensajes de SIP Respuestas (1)

Start-line en una respuesta se denomina Status-Line Cuando un servidor SIP (servidor UAS) recibe una solicitud, siempre debe contestar con una o ms respuestas Formato de la status-line:

<SIP-Version> <Status-Code> <Reason-Phrase>

SIP-Version:

Versin del protocolo (siempre es SIP/2.0) Es un cdigo de resultado entero de 3 dgitos Indica el resultado de comprender y satisfacer una solicitud Descripcin textual corta del Status-Code (normalmente para los usuarios)

Status Code:

La Reason-Phrase:

Ejemplos:

SIP/2.0 100 Trying SIP/2.0 200 OK

SIP/2.0 302 Moved Temporarily SIP/2.0 404 Not Found

23

Mensajes de SIP Respuestas (2)

Los Status-Code de SIP son muy similares a los de HTTP (los cinco primeros grupos son los mismos; el sexto es especfico de SIP): Tipo respuesta
Informativa xito Redireccin Error de cliente Error de servidor Fallo global

Rango
100-199 200-299 300-399 400-499 500-599 600-699

Comentarios
De carcter provisional; indica el estado de la sesin antes de completarse; se interpreta como Request recibido y en proceso Definitiva; se interpreta como Request recibido y procesado con xito Definitiva; utilizada para redirigir los Requests a otra direccin Definitiva; el Request ha fallado por error en el cliente; se puede reintentar si se modifica como indica el Response Definitiva; el Request ha fallado por error en el servidor; se puede reintentar en otro servidor Definitiva; el Request no es valido para ningn servidor

24

Mensajes de SIP Solicitudes

Start-Line en solicitudes se denomina Request-Line Formato de la Request-Line:

<Method> <Request-URI> <SIP-Version>

Method:

Indica el propsito de la solicitud Ej: El mtodo INVITE permite establecer sesiones Es una URI (ej: una URI SIP o URI SIPS) Indica el usuario o servicio destinatario de la solicitud Indica la versin de SIP (SIP/2.0)

Request-URI:

SIPVersion

Ejemplos: INVITE sip:Alice.Smith@domain.com SIP/2.0 ACK sip:alice@192.0.0.1 SIP/2.0

25

Mensajes de SIP Methods originales

INVITE, se utiliza para solicitar a un usuario el establecimiento de una sesin ACK, utilizado por el cliente que origin un INVITE para confirmar al servidor que le respondi que ha recibido la respuesta final al mismo CANCEL, utilizado por los clientes para cancelar sesiones que an estn pendientes de establecerse (el servidor an no ha enviado una respuesta final); la recepcin de un CANCEL por parte de un servidor aborta el intento de establecimiento de la sesin, pero no impide que se lleve a cabo el three-way handshake (el servidor enva un 487 Transaction Cancelled) BYE, utilizado por los usuarios para abandonar una sesin en curso; si la sesin estaba integrada por dos usuarios, utilizar BYE equivale a terminar la sesin REGISTER, utilizado por los UAs para informar a un Registrar de la localizacin actual del usuario OPTIONS, utilizado para solicitar las capacidades de un servidor: methods, protocolos y codecs soportados, etc.

26

Mensajes de SIP Methods en extensiones (1)

REFER, utilizado para que un UA pida a otro UA que establezca una sesin con un tercero (otro UA, un servicio HTTP, etc.); el ejemplo de uso ms comn es el de transferencia de llamadas entre usuarios SUBSCRIBE, utilizado por los usuarios para solicitar la recepcin de avisos cuando ocurran determinados eventos; un campo en el cuerpo del mensaje acta como temporizador para la subscripcin (0 indica borrar la subscripcin); ejemplo: subscripcin a informacin de presencia de usuarios NOTIFY, utilizado para notificar la ocurrencia de eventos (por ejemplo, el solicitado por un SUBSCRIBE) MESSAGE, utilizado para transportar mensajes (codificados en MIME) utilizando SIP, por ejemplo para servicios de IM
27

Mensajes de SIP Methods en extensiones (2)

UPDATE, utilizado para modificar el estado de una sesin an pendiente de establecer (sesiones en curso se modifican mediante un nuevo INVITE); por ejemplo, silenciar el sonido de una sesin an pendiente de establecerse INFO, utilizado para enviar informacin extremo a extremo entre usuarios que participan en una sesin; al ser extremo a extremo, ningn servidor SIP interpreta o acta ante methods de tipo INFO; un ejemplo de uso es el envo de informacin de sealizacin entre usuarios (como mensajes tipo USR de ISUP) PRACK, utilizado para confirmar la recepcin de responses provisionales (tipo 1XX), cuando se requiere dicha confirmacin; un ejemplo del uso de PRACK es en el soporte para la reserva de recursos (ver ms adelante).

28

Mensajes de SIP Campos de cabecera obligatorios

To: especifica el receptor lgico de la solicitud

Siempre incluye una URI Ejemplos:

To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 To: sip:alice@company.com

From: Indica el iniciador de una solicitud

Siempre incluye una URI Ejemplos:

From: A. G. Bell <sip:agb@bell-telephone.com>;tag=a48s From: sip:bob@domain.com

CSeq: contiene un nmero de secuencia decimal y un nombre de mtodo. Permite ordenar e identificar transacciones de SIP, as como diferenciar entre nuevas solicitudes y retransmisiones

Ejemplo Cseq: 4711 INVITE

29

Mensajes de SIP Campos de cabecera obligatorios

Call-ID: identifica de forma nica una solicitud INVITE, as como todos los registros realizados por un cliente particular

Ejemplo Call-ID: f81d4fae-7dec-11d0a765-00a0c91e6bf6@biloxi.com

Max-Forwards: se usa para evitar bucles de encaminamiento. Cada proxy que gestiona una solicitud decrementa su valor en uno, y si llega a cero la solicitud es descartada

Ejemplo Max-Forwards: 6

Via: la cabecera Via mantiene un registro de los proxies atravesados por una solicitud. La respuesta atraviesa los mismos proxies que la solicitud, slo que en orden inverso

Ejemplo Via: SIP/2.0/UDP erlang.bell-telephone.com: 5060;branch=z9hG4bK87asdks7

30

Mensaje SIP Cuerpo de los mensajes

SIP usa el formato MIME para codificar el cuerpo de los mensajes

MIME = Multipurpose Internet Mail Extensions (RFC 2045) Content-Disposition, describe como el cuerpo del mensaje debe ser interpretado
El

Campos de cabecera adicionales:

valor session indica que el cuerpo describe una sesin indica formato SDP

Content-Type, indica el tipo de cuerpo enviado

Application/SDP

Content-Length, indica la longitud del cuerpo del mensaje en octetos

El cuerpo de los mensajes se transmite extremo a extremo.

31

Mensajes de SIP Ejemplos

32

Registro (I)

El registro crea asociaciones en un servicio de localizacin de un dominio Cada asociacin enlaza una URI SIP pblica con una o ms direcciones de contacto El registro supone enviar una solicitud REGISTER a un Registrar El Registrar acta como Front-end para el servicio de localizacin El servicio de localizacin es tpicamente consultado por un servidor proxy o redirect

33

Registro (2)

2. Almacenar

Servicio de localizaci n

4. Solicitud

3. INVITE sip:carol@chicago.com

5. Respuesta

1. REGISTER sip:carol@chicago.com sip:cube2214a.chicago.com

4. INVITE sip:cube2214a.chicago.com

34

Registro (3)

Contenido de la solicitud REGISTER:

Request-URI, incluye el nombre de dominio del servicio de localizacin en el que se desea hacer el registro To, contiene la URI SIP pblica From, contiene la URI SIP pblica de la persona responsable del registro Call-ID, todos los registros realizados por un cliente en un registrar deben tener el mismo Call-ID Cseq, se incrementa en 1 por cada solicitud REGISTER enviada con el mismo Call-ID Contact (opcional), incluye cero o ms direcciones de contacto

35

Registro (4)
REGISTER sip:biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0

Registrar biloxi.com

Telfono Bob

REGISTER OK
SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob <sip:bob@biloxi.com>;tag=2493k59kd From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0

36

Establecimiento de sesin -Generalidades

Un UAC que desea establecer una sesin genera una solicitud INVITE LA solicitud es generalmente encaminada a travs de uno o ms proxies hasta alcanzar un UAS El UAS:

Puede aceptar el establecimiento de la sesin, mediante una respuesta 2xx Puede rechazar el establecimiento de la sesin, mediante una respuesta 3xx, 4xx, 5xx o 6xx Puede enviar respuestas provisionales 1xx para informar al UAC sobre el progreso de contactar al usuario llamado

La primera respuesta (101-199 o 2xx) generada por el UAS resulta en el establecimiento de un dilogo entre el UAC y el UAS

El dilogo facilita la secuenciacin de los mensajes y el apropiado encaminamiento de las solicitudes

37

Establecimiento de sesin -- Campos de cabecera en INVITE

To:

Incluye la URI SIP pblica del usuario o recurso receptor de la solicitud Habitualmente, el valor lo indica el usuario, introducindolo manualmente o seleccionndolo de una libreta de direcciones El campo Request-URI del la solicitud inicialmente se establece al valor de la URI en el campo de cabecera To Tpicamente incluye la URI SIP pblica del usuario iniciador de la solicitud Habitualmente, el valor es preconfigurado en el UA por el usuario o por el administrador del dominio local del usuario Debe contener un parmetro tag elegido por el UAC (el tag debe ser globalmente nico y criptogrficamente aleatorio) Identificador globalmente nico generado por el UAC Debe ser el mismo para todas las solicitudes y respuestas enviadas por cualquier UA en el dilogo
38

From:

Call-ID:

Establecimiento de sesin -- Campos de cabecera en INVITE

Cseq:

El nombre de mtodo es INVITE El valor del nmero de secuencia es arbitrario:

Debe

ser expresable como un entero sin signo de 32 bits Debe ser menor que 231

Max-Forwards:

Valor recomendado: 70 El UAC aade su direccin en un campo de cabecera Via, indicando la localizacin donde las respuestas a la solicitud deben ser enviadas Provee una URI SIP que puede ser utilizada para contactar al UA en solicitudes posteriores
39

Via:

Contact:

Establecimiento de sesin Generacin de respuestas en el UAS

Los campos From, Call-ID, CSeq y Via de la respuesta coinciden con los correspondientes campos de la solicitud LA URI en el campo de cabecera To de la respuesta es igual a la URI en el campo de cabecera To de la solicitud El UAS debe aadir un parmetro tag en el campo de cabecera To de la respuesta

El tag debe ser globalmente nico y criptogrficamente aleatorio El mismo tag se aade a todas las respuestas a la solicitud INVITE El tag no es obligatorio en respuestas TRYING (100)

El UAS incluye una cabecera Contact, en la que indica la direccin en la que el UAS desea recibir futuras solicitudes en el dilogo (ej: el ACK)
40

Establecimiento de sesin Procesamiento en proxies

El proxy realiza, entre otras, las siguientes funciones para cada solicitud recibida:

Validar la solicitud Determinar el destino o destinos de la solicitud Reenviar la solicitud a cada destino
Cambia

la Request-URI de la solicitud Actualiza el campo de cabecera Max-Forwards Determina la direccin IP, puerto y protocolo de transporte para el siguiente salto Aade un valor al campo de cabecera Via con su propia direccin

Procesar las respuestas a la solicitud

Elimina

el primer valor del campo de cabecera Via

41

Ejemplo de operacin: llamada voz

Telfono Alice
Alice llama a Bob usando su identificador SIP

Proxy atlanta.com 1. INVITE 3. INVITE

Proxy biloxi.com

Telfono Bob
El telfono de Bob recibe la indicacin de llamada entrante, comienza a sonar y enva una indicacin al telfono de Alice

2. TRYING 4. TRYING

5. INVITE

Alice recibe una indicacin de que la llamada est en progreso Alice recibe una indicacin de que la llamada se ha establecido

8. RINGING

7. RINGING 10. OK

6. RINGING 9. OK

11. OK

Bob acepta la llamada

12. ACK

Sesin de audio RTP

42

Ejemplo -- INVITE (1)

INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 <Carga SDP>

43

Ejemplo TRYING (2)

SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0

44

Ejemplo INVITE (3)

INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 69 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 <Carga SDP>
45

Ejemplo INVITE (5)

INVITE sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 <Carga SDP>
46

Ejemplo RINGING (6)

SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0
47

Ejemplo-- RINGING (7)

SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0

48

Ejempl-- RINGING (8)

SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0
49

Ejemplo-- OK (9)
SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 <Carga SDP>
50

Futuras solicitudes y respuestas

Generacin de futuras solicitudes:

From, incluye la URI y el tag correspondientes al lado local To, incluye la URI y el tag correspondientes al lado remoto Call-ID, incluye el valor previamente especificado en la solicitud INVITE Cseq, incluye:
El

nombre del mtodo de la solicitud El nmero de secuencia se incrementa en 1 para cada solicitud Excepcin: ACK. La solicitud ACK utiliza el mismo valor de nmero de secuencia que el INVITE

Request URI, incluye la URI del campo de cabecera Contact recibido del UA remoto El resto de campos se generan segn se ha comentado previamente para la solicitud INVITE
51

Futuras solicitudes y respuestas

Generacin de la respuesta:

Se aplican las mismas reglas previamente presentadas en la generacin de la respuesta al INVITE

El

campo de cabecera To (URI + tag) en la respuesta es el mismo que el de la solicitud

El campo de cabecera CSeq de la solicitud permite saber si la solicitud est o no en orden.

En

caso negativo, se responde con 500 (Server Internal Error)

52

Ejemplo de operacin: llamada voz

Telfono Alice
Alice llama a Bob usando su identificador SIP

Proxy atlanta.com 1. INVITE 2. INVITE

Proxy biloxi.com

Telfono Bob
El telfono de Bob recibe la indicacin de llamada entrante, comienza a sonar y enva una indicacin al telfono de Alice

3. TRYING 5. TRYING

4. INVITE

Alice recibe una indicacin de que la llamada est en progreso Alice recibe una indicacin de que la llamada se ha establecido

8. RINGING

7. RINGING 10. OK

6. RINGING 9. OK

11. OK

Bob acepta la llamada

12. ACK

Sesin de audio RTP

53

Ejemplo ACK (12)

ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0
54

Liberacin de sesin -- Generalidades

El mtodo BYE permite terminar sesiones La solicitud BYE se construye del mismo modo que solicitudes posteriores al INVITE en un dilogo Consideraciones:

El UA del llamante puede generar una solicitud BYE en cualquier momento El UA del llamado puede generar una solicitud BYE una vez que ha recibido el ACK del 2xx

La solicitud BYE termina el dilogo y la sesin establecidos entre los dos UAs
55

Liberacin de sesin -- Ejemplo

Telfono Alice Proxy atlanta.com Proxy biloxi.com Telfono Bob

Sesin de audio RTP

1. BYE

Bob cuelga el telfono

2. OK

56

Ejemplo: BYE (1)

BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0

57

Ejemplo OK (2)
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0
58

Modificacin de la sesin

Consiste en enviar una nueva solicitud INVITE en el dilogo (re-INVITE):

Permite cambiar la descripcin de la sesin: cambiar direcciones IP, puertos RTP/RTCP aadir o eliminar sesiones RTP, etc

El llamante y el llamado pueden modificar una sesin existente Si un UA recibe una respuesta final distinta de 2xx a una solicitud RE-invite, los parmetros de la sesin permanecen sin cambiar Un UAS tpicamente no genera respuestas 180 (RINGING) para una solicitud Re-INVITE
59

SDP: Session Description Protocol

SDP es un formato textual para describir sesiones multimedia Definido por el grupo de trabajo del IETF MMUSIC, en el RFC 4566

Cada lnea de una descripcin SDP es de la forma tipo=valor (tipo es un carcter) Formato general de una descripcin SDP

Seccin a nivel de sesin Seccin a nivel de informacin 1 ... Seccin a nivel de informacin N
60

Ejemplo descripcin SDP

v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 51372 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000
Seccin a nivel de sesin

Descripcin a nivel de informacin

Descripcin a nivel de informacin

61

Modelo Oferta/Respuesta SDP

Definido por el grupo de trabajo MMUSIC en RFC 3264 Inicialmente, SDP estaba pensado para describir sesiones multicast

El modelo Oferta/Respuesta permite acordar la descripcin de una sesin unicast Un usuario (ofertante) genera una carga SDP (oferta SDP) y la enva al usuario remoto El otro usuario genera una carga SDP (respuesta SDP) y la enva al usuario ofertante
62

Funcionamiento:

Ejemplo del modelo Oferta/Respuesta

Alice quiere establecer una videconferencia con Bob

Telfono Alice Proxy atlanta.com 1. INVITE Oferta SDP 3. TRYING 2. INVITE Oferta SDP 5. TRYING 7. RINGING 10. OK Respuesta SDP 12. ACK Proxy biloxi.com Telfono Bob

4. INVITE Oferta SDP 6. RINGING 9. OK Respuesta SDP

8. RINGING

11. OK Respuesta SDP

Sesiones de audio y video RTP

63

Ejemplo del modelo Oferta/respuesta

v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 51372 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000
Oferta SDP

v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49174 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49170 RTP/AVP 32 a=rtpmap:32 MPV/90000

Respuesta SDP 64

Extensiones a SIP

Fiabilidad de respuestas provisionales

Definida por el grupo de trabajo SIP del IETF en RFC 3262 Permite enviar de forma fiable respuestas provisionales (ej: RINGING) Se basa en el uso del mtodo PRACK y campos de cabecera adicionales (RAck y RSeq) Definida por el grupo de trabajo SIP del IETF en RFC 3312 Permite retrasar el establecimiento de la sesin mientras los UAs ejecutan un procedimiento de reserva de recursos (e.g,. RSVP) Se basa en la inclusin de cierta informacin (precondiciones) en la carga SDP
65

Integracin de gestin de recursos y SIP

Conferencia

SIP permite establecer un dilogo entre dos UAs

Resulta obvio, por tanto, establecer una sesin multimedia entre dos usuarios

El grupo de trabajo del IETF SIPPING estudia el uso de SIP para aplicaciones relacionadas con la telefona y multimedia El RFC 4353 presenta una serie de configuraciones que permiten establecer una conferencia basada en SIP entre varios usuarios

66

Aplicaciones de SIP

Pese a su relativamente corta vida, SIP ya est presente en importantes aplicaciones de comunicaciones Adems, muchas de estas aplicaciones probablemente tendrn un muy importante uso en el futuro, lo que hace an ms dorado el futuro de SIP Algunas aplicaciones de SIP:

Telefona sobre IP (VoIP) Sistemas de videoconferencia Sistemas de mensajera instantnea (IM) Core multimedia de la nueva arquitectura de servicios de telefona mvil 3G (IMS de 3GPP y 3GPP2).
67