66.48 Seminario de Redes de Computadoras. Trabajo Práctico Nº: 2. Tema: Session Initiation Protocol Seminario de Redes de Computadoras

Transcripción

1 Facultad de Ingeniería Trabajo Práctico Nº: 2 Tema: Session Initiation Protocol (2º cuatrimestre 2007) Docentes: Ing. Marcelo Utard, Ing. Pablo Ronco Alumnos: Bianchi Mariano Pasqualini Adriano Ricci Alejandro Soto Fernando 74824

2 Trabajo Práctico Nº: Tema: Session Initiation Protocol SIP y Internet: Protocolos de Señalización La Internet Engineering Task Force Breve reseña histórica de SIP Internet Multimedia Protocol Stack Introducción a SIP Un ejemplo simple de establecimiento de sesión Llamada SIP con Proxy Server SIP registro ejemplo Transporte de los Mensajes Transporte UDP Transporte TCP Transporte TLS (Transport Layer Security) Transporte SCTP ( Stream Control Transport Protocol) Firewall y NAT...22 Firewalls...22 NAT SIP CLIENTE-SERVIDOR User Agents Agentes de presencia Back-to-Back User Agents (B2BUA) SIP gateways SIP Servers Proxy Servers Redirect Servers Registration Servers Confiabilidad Authentication SDP...37 Session Description Protocol Formato general de los campos de SDP Detalle de algunos campos: Funcionamiento sobre SIP:

3 1. SIP y Internet: SIP (Session Inititation Protocol) es un nuevo protocolo de señalización, presencia y mensajería instantánea desarrollado para establecer, modificar, y finalizar sesiones multimedia. En esta introducción veremos algunos conceptos básicos para entender el funcionamiento de SIP. SIP fue desarrollado por la IETF (Internet Engineering Task Force), y fue desarrollado para interactuar con otros protocolos de Internet como Transmission Control Protocol (TCP), Transmission Layer Security (TLS), User Datagram Protocol (UDP), Internet Protocol (IP), Domain Name System (DNS), y otros. 1.1 Protocolos de Señalización Este informe está basado en Session Initiation Protocol. Como su nombre indica, este protocolo permite que dos end-points establezcan sesiones multimedia entre sí. Las principales funciones del protocolo son las siguientes: Localizar al end point Contactarlo para establecer una sesión Intercambio de información para permitir que la sesión se establezca Modificar sesiones de media ya existentes Finalizar sesiones multimedia SIP también ha sido extendido para brindar información de presencia (on-line/off-line status) y brindar información sobre la ubicación como el contenido de una lista de contactos en sesiones de mensajería instantánea Estas funciones incluyen: Publicar y upgradear información de presencia Presencia y notificación de otros eventos Transporte de mensajes instantáneos Aunque algunos de los ejemplos tratan a SIP desde una perspectiva telefónica, hay muchos ejemplos que tratan sobre usos no-telefónicos de SIP. 1.2 La Internet Engineering Task Force SIP fue desarrollado por la IETF. La misma es una organización autónoma que hace contribuciones a la ingeniería y la evolución de Internet y sus tecnologías. Los dos tipos de documentos utilizados por la IETF son: Los Internet Drafts (I-Ds) y los Request For Comments (RFC). Los I-Ds son Documentos de trabajo del grupo. Cualquiera puede escribir sobre cualquier tema y presentarlo a la IETF. No hay una manera formal para formar parte de la IETF. Cualquiera puede participar. Al publicarse un nuevo documento RFC con un nuevo número, deja obsoleto el viejo RFC. Citaremos algunos I-Ds en este informe. Una norma comienza su vida como un I-D y luego avanza a un RFC mediante un consenso una vez que ya haya implementaciones sobre ese nuevo protocolo. Cualquier persona con acceso a Internet puede descargar cualquier I-D o RFC sin cargo utilizando Internet, FTP o correo electrónico. La forma de hacerlo se puede encontrar en el sitio Web de IETF: 3

4 1.3 Breve reseña histórica de SIP SIP fue originalmente desarrollado por la IETF Multi-Party Multimedia Session Control Working Group, conocido como MMUSIC. La versión 1.0 se presentó como un I-D Internet en Luego se introdujeron cambios importantes en el protocolo y así surgió la segunda versión, la 2.0, que se presentó como otro I-D en El protocolo obtuvo un estado de propuesto como estándar en marzo de 1999 y se publicó como RFC 2543 en abril de En septiembre de 1999, la SIP Working Group fue establecida por la IETF para satisfacer el creciente interés en el protocolo. En julio de 2000 se publicó el RFC 3261 con correcciones respecto al anterior, dejando así obsoleto (reemplazando) la especificación original RFC La popularidad de SIP en la IETF ha llevado a la formación de otros grupos de trabajo relacionados con SIP. Grupo de trabajo. Para avanzar con un Proyecto de Norma, un protocolo debe tener múltiples implementaciones independientes y operacionales. Desde los primeros días la RFC 2543, prueba de la interoperabilidad SIP SIP incorpora elementos de los dos protocolos de Internet ampliamente utilizado: Hyper Text Transport Protocol (HTTP) utilizado para la navegación Web y el Simple Mail Transport Protocol (SMTP) utilizado para el correo electrónico. Desde HTTP, SIP imita el comportamiento cliente-servidor y el uso de URLs y URIs. Desde SMTP, SIP imita los headers, su esquema de codificación y estilo. Por ejemplo, SIP reutiliza headers SMTP tales como TO, FROM, DATE y SUBJECT. La interacción de SIP con otros protocolos de Internet, tales como IP, TCP, UDP, DNS, y se describe en la siguiente sección. 1.4 Internet Multimedia Protocol Stack La figura 1.1 muestra las cuatro capas del stack de protocolos Multimedia de Internet. Figura 1.1. El stack de protocolos multimedia de Internet Capa física La capa más baja es la capa física y de enlace, que podría ser una interface ethernet (LAN), una línea telefónica (V.90 o modem de 56k) corriendo Protocolo de punto-a-punto (PPP), o 4

5 de una línea de abonado digital (DSL) que corriendo ATM, o incluso una red inalámbrica Esta capa realiza funciones tales como intercambio de símbolos de cambio, sincronización de frames, y especificaciones de la interfaz física Capa Internet La siguiente capa en la Figura 1.1 es la capa de Internet. El Protocolo de Internet (IP) es utilizado en esta capa para rutear un paquete a través de la red usando la dirección IP de destino. IP es un protocolo no orientado a la conexión y utiliza el mecanismo del mejor esfuerzo para el delivery de paquetes. Los paquetes IP pueden ser perdidos, retrasados, o recibidos fuera de secuencia. La mayoría de las direcciones IP en este informe corresponden a la versión 4 (IPv4). Estas direcciones tienen cuatro octetos de largo, generalmente escritas por medio de la notación decimal (por ejemplo, ). Entre cada uno de los puntos se escribe un número de 8 bits en base decimal, es decir que el mismo va de 0 a 255. En la capa IP no se necesita un acknowledge para garantizar el arribo de un paquete. Se calcula un checksum para detectar corrupción de datos en el header IP, que puede producir el mal enrutamiento de un paquete. La corrupción o errores en la carga útil IP, sin embargo, no son detectados, dado que una capa superior debe llevar a cabo esta función, si es necesario. IP utiliza un solo octeto en el header paquete para determinar el nivel de transporte que deberá recibir ese paquete. IP versión 6 (IPv6) fue desarrollado por la IETF como un reemplazo de IPv4. Ha ido creciendo poco a poco y ahora es soportado por una serie de sistemas operativos. El mayor impacto de las redes de IPv6 será dado probablemente por los carriers de telefonía IP inalámbrica que necesitan la ventaja más importante de IPv6 sobre IPv4, es decir, un espacio mucho más amplio de direcciones. IPv6 aumenta el espacio de 32 bits en IPv4 a 128 bits, que permite más de 4 mil millones de direcciones IPv6. Hay muchas otras mejoras en IPv6 sobre IPv4, incluida la seguridad. Una dirección IPv6 es normalmente escrita como una secuencia de ocho números hexadecimales separados por dos puntos. Por ejemplo, 0:0:0:0: aaa: bbbb: cccc: dddd es una Dirección IPv6 escrita en este formato. Las direcciones IP utilizadas en la Internet pública se asignan en bloques por la Internet Assigned Number Association (IANA). Como resultado de esta centralización, las direcciones IP son únicas a nivel mundial. Esto permite que un paquete pueda ser transferido al público a través de Internet utilizando sólo la dirección IP de destino. Diversos protocolos se utilizan para enrutar paquetes a través de una red IP, pero están fuera del alcance de este informa. Subredes y otros aspectos de la estructura de direcciones IP tampoco están cubiertas aquí Capa de Transporte El siguiente nivel que se muestra en la Figura 1.1 es la capa de transporte. La misma utiliza un puerto que es un número de 16 bits de la capa de aplicación para entregar el datagrama o segmento a la correcta capa de aplicación en la dirección IP de destino. Algunos números de puerto están dedicados especialmente a ciertos protocolos. Estos puertos se denominan "well-known-ports". Por ejemplo, HTTP utiliza well-known port 80, mientras que SIP utiliza el well-known port 5060 ó Otros puertos pueden ser utilizados por cualquier protocolo. Estos son asignados dinámicamente a partir de un rango de números disponibles. Estos son los llamados puertos efímeros" y por lo general su rango va desde el puerto número a Los tres tipos de protocolos más comunes a nivel de transporte son: Transmission 5

6 Control Protocol, Transmisión Layer Security y User Datagram Protocol. Existe uno más no muy común, SCTP sobre el cual daremos algunos detalles SCTP El Transport Stream Control Protocol (SCTP) es similar a TCP ya que provee transporte confiable basado en streams. Sin embargo, tiene algunas ventajas respecto a TCP para un protocolo basado en mensaje. En primer lugar, se ha incorporado la segmentación de mensajes, a fin de que los mensajes individuales se separen en la capa de transporte. Otra ventaja es que SCTP evita el problema llamado "head of line blocking. Este es un problema común de TCP en el que un segmento descartado con una ventana larga produce que los mensajes esperen en el buffer hasta que el segmento descartado sea retransmitido Capa de Aplicación La capa superior que se muestra en la Figura 1.1 es la capa de aplicación. Esta incluye protocolos de señalización como SIP y los medios de comunicación, tales como protocolos de transporte en tiempo real (RTP). En esta capa también entraría el protocolo H.323, que es una alternativa de protocolo de señalización SIP desarrollada por la Unión Internacional de Telecomunicaciones (ITU). Session Description Protocol (SDP), se muestra más arriba que SIP en la pila de protocolo, ya que se encapsula en un mensaje SIP ABNF Representación El meta lenguaje Augmented Backus-Naur Format se utiliza en todo RFC 3261 [1] para describir la sintaxis de SIP, así como otros protocolos de Internet. Un ejemplo de construcción utilizado para describir un mensaje SIP es el siguiente: SIP mensaje = Request / Response Es decir: un mensaje SIP es, o bien una petición o una respuesta. SIP message en la parte izquierda del signo igual representa lo que se está definido. La parte derecha del igual contiene la definición. El "/" se utiliza para como significado lógico OR (nota: las versiones anteriores de ABNF utilizan " " en lugar de "/" como sintaxis). A continuación, se definen de manera análoga Solicitud y Respuesta usando ABNF: Request = Request-Line *( message-header ) CRLF [ message-body] El Request-Line se definirá en otra declaración ABNF. Los elementos entre paréntesis () son tratados como un único elemento. El "*" indica que el elemento puede ser repetido, separados por al menos un espacio. El número mínimo y máximo puede ser representado como x * y, lo que significa un mínimo y máximo de x de y dado que los valores por defecto son 0 e infinito, un solo "*" (como en este ejemplo) indica que cualquier número está permitido, incluso ninguno. CRLF se define como un transporte línea de retorno o los caracteres ASCII que se escriben la notación hexadecimal como 0x10 y 0x13. ABNF de SIP se describe en la Sección 25 del RFC

7 2. Introducción a SIP A menudo, la mejor manera de aprender un protocolo es ver ejemplos de su uso. Si bien la terminología, estructuras, y el formato de un nuevo protocolo puede ser confuso al principio leer, un ejemplo de flujo de mensajes puede dar una rápida comprensión de algunos de los conceptos claves de un protocolo. Los ejemplos de intercambios de mensajes que se detallarán en este informe introducirán a SIP como se define en el RFC El primer ejemplo muestra la base de intercambio de mensajes entre dos dispositivos SIP para establecer y terminar un período de sesiones. El segundo ejemplo se muestra el mensaje intercambio cuando se utiliza un servidor SIP proxy. El tercer ejemplo muestra una registración SIP. El cuarto ejemplo muestra presencia SIP y mensajería instantánea Ejemplo. Finalmente se estudia la transmisión de mensajes SIP usando UDP, TCP, TLS, y SCTP. Los ejemplos se presentan utilizando diagramas de flujo de llamadas entre el que origina la llamada y el que la recibe, junto con los detalles de cada mensaje. Cada flecha en las figuras representa un mensaje SIP, con la flecha que indica la dirección de transmisión. Las líneas gruesas en las cifras indican el flujo de media (paquetes de audio). En estos ejemplos, se asumirá que la media utiliza el protocolo RTP, pero podría ser otro protocolo. 2.1 Un ejemplo simple de establecimiento de sesión La figura 2.1 muestra el intercambio de mensajes SIP entre dos dispositivos obviamente habilitados para SIP. Figura 2.1 Un ejemplo simple de establecimiento de sesión SIP. Los dos dispositivos pueden ser por ejemplo teléfonos SIP. Se asume que ambos dispositivos están conectados a una red IP como Internet y que se conocen las respectivas direcciones IP. 7

8 El originador de la llamada, Tesla, comienza el intercambio de mensajes mediante el envío de un mensaje SIP INVITE al destinatario de la llamada, Marconi. El INVITE contiene los detalles de la reunión, o bien el tipo de llamada que se solicita. Podría ser una simple sesión de voz (de audio), una sesión multimedia tales como una videoconferencia, o podría ser una sesión de de juego. El mensaje INVITE contiene los siguientes campos: INVITE sip:marconi@radio.org SIP/2.0 Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hg4bkfw19b Max-Forwards: 70 To: G. Marconi <sip:marconi@radio.org> From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341 Call-ID: @lab.high-voltage.org CSeq: 1 INVITE Subject: About That Power Outage... Contact: <sip:n.tesla@lab.high-voltage.org> Content-Type: application/sdp Content-Length: 158 v=0 o=tesla IN IP4 lab.high-voltage.org s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Dado que SIP es un protocolo de texto codificado, esto es en realidad cómo se vería el mensaje SIP "en el cable" como un datagrama UDP transportado, por ejemplo, sobre Ethernet. Los campos que figuran en el mensaje INVITE son llamados campos de header header. Ellos tienen la forma de header: valor CRLF. La primera línea del mensaje de solicitud, llamada la línea de salida, lista los métodos, que es INVITE, la petición de URI, luego la versión de SIP (2.0), todos separados por espacios. Cada línea de un mensaje SIP es terminada por un CRLF. El primer campo de header es el Via. Cada dispositivo SIP que se origina o forwardea un mensaje SIP coloca su propia dirección en el campo Via, como normalmente se escribe el nombre de la máquina, se puede resolver en una dirección IP utilizando una consulta DNS. El campo de header Via contiene el número de versión (2.0), un "/", luego UDP para transporte UDP, un espacio, a continuación, el nombre del host o dirección, dos puntos, luego un número de puerto, en este ejemplo la se utiliza el well-known- port El siguiente campo de header que se muestra es el Max-Forwards, que es inicializado con un entero grande y decrementado por cada servidor SIP, que recibe y reenvía la solicitud, para impedir un loop infinito. El siguiente header son los campos FROM y TO, que muestran al iniciador y el destinatario de la solicitud SIP. Cuando una etiqueta de nombre se utiliza, como en este ejemplo, la SIP URI está encerrada entre corchetes y utilizado para el ruteo de la solicitud. La etiqueta de nombre podría ser mostrada durante la alerta, por ejemplo, pero no es utilizada por el protocolo. El campo de header Call-ID es un identificador usado para llevar el registro de una determinada sesión SIP. El iniciador de la solicitud a nivel local crea una cadena única, 8

9 generalmente añade un y el nombre de host para que sea único a nivel mundial. El user agent que genera el INVITE inicial para establecer la sesión genera el Call-ID que es único y el TO. En respuesta al INVITE, el user agent responder a la solicitud generará a la c etiqueta. La combinación de la etiqueta (que figura en el campo de header From), código remoto (Para que figuran en el campo de header), y la convocatoria de la ID identifica de forma exclusiva período de sesiones establecido, conocido como un "diálogo". Este diálogo identificador es utilizado por ambos partes para identificar la presente convocatoria, ya que podría haber creado varias llamadas entre las peticiones posteriores en el período de sesiones se estableció utilizar este cuadro de diálogo identificador, como se muestra en los siguientes ejemplos. El siguiente campo de header que se muestra es el CSeq, o secuencia de comandos. Contiene un número, seguido por el nombre de método, en este caso INVITE. Este número se incrementa para cada nueva solicitud enviada. En este ejemplo, el comando número de secuencia se inicializa a 1, pero podría empezar en otro valor. La Via campos de header más el Max-Forwards, To, From, Call-ID, y CSeq representan el mínimo necesario de header a establecer en cualquier mensaje de solicitud SIP. Existen otros campos de header que se pueden incluir como opcionales. Un campo de header de contacto también se necesita en este mensaje INVITE, que contiene la URI SIP de Tesla, conocido como un user agent (UA), este URI puede usarse para enrutar los mensajes directamente a Tesla. Existen campos de header adicionales al INVITE presente en este mensaje, que contienen los medios de comunicación de la información necesaria para creación de la llamada. El tipo de contenido y longitud del header indican los campos que el cuerpo del mensaje SDP y contiene 158 octetos de datos. La base del octeto contar de 158 se presenta en el cuadro 2.1, donde el CR LF al final de Cada línea se muestra como una y el octeto para cada línea se muestra en el lado derecho. Una línea en blanco separa el cuerpo del mensaje del campo de header Lista, que termina con el campo Content-Lenght. En este caso, son siete líneas de datos SDP que describen los atributos de media que Tesla (el llamador) desea para la llamada. Esta información es necesaria ya que SIP no se encarga de establecer el tipo de media que se establecerá durante la sesión. El cuadro 2,2 incluye: Conexión dirección IP ( ); Medios de formato (de audio); Número de puerto (49170); Protocolo de transporte de media(rtp); Codec utilizado (PCM Ley µ); Frecuencia de muestreo (8000 Hz). 9

10 Cuadro 2.1. Ejemplo de cálculo de Content-Lenght Cuadro 2.2. Ejemplo de datos SDP. INVITE es un ejemplo de un mensaje de solicitud SIP. Hay otros cinco métodos o tipos de peticiones SIP actualmente definidos en el SIP RFC 3261 y otros en la extensión RFC. El siguiente mensaje en la Figura 2,1 es una Señal 180 de Ringing que se envía en respuesta a la INVITE. Este mensaje indica que Marconi ha recibido la alerta y que INVITE se está llevando a cabo. El tono de alerta podría ser un teléfono, un mensaje en destellando en la pantalla, o cualquier otro método de atraer la atención de la llamada. La señal de ringing tiene la siguiente estructura: SIP/ Ringing Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hg4bkfw19b ;received= To: G. Marconi <sip:marconi@radio.org>;tag=a53e42 From: Nikola Tesla <sip:n.tesla@high-voltage.org>>;tag=76341 Call-ID: @lab.high-voltage.org CSeq: 1 INVITE Contact: <sip:marconi@tower.radio.org> Content-Length: 0 Cuando Marconi decide aceptar la llamada (es decir, el teléfono atiende), se envía una señal de 200 OK. Esta respuesta también indica que el tipo de media propuesto por la persona que llama es aceptable. Los 200 OK son un ejemplo de una respuesta "Success class". El cuerpo de mensaje 200 OK contiene la información de media de Marconi: 10

11 SIP/ OK Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hg4bkfw19b ;received= To: G. Marconi From: Nikola Tesla Call-ID: CSeq: 1 INVITE Contact: <sip:marconi@tower.radio.org> Content-Type: application/sdp Content-Length: 155 v=0 o=marconi IN IP4 tower.radio.org s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Esta respuesta se construye de la misma manera que los 180 de señal de llamada y contiene la respuesta a la misma etiqueta y el URI de contacto. La capacidad de los medios de comunicación, sin embargo, deberá ser comunicada en un cuerpo de mensaje SDP añadido a la respuesta. Desde el mismo campo SDP campos como el cuadro 2,2, el SDP contiene: IP destino ( ); Formato de Media (audio); Número de puerto (60000); Protocolo de transporte para Media (RTP); Codificación de Media (PCM µ Ley); Frecuencia de muestreo (8000 Hz). El último paso es la confirmación o acknowledgement que Tesla ha recibido con éxito la respuesta de Marconi: ACK sip:marconi@tower.radio.org SIP/2.0 Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hg4bk321g Max-Forwards: 70 To: G. Marconi <sip:marconi@radio.org>;tag=a53e42 From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341 Call-ID: @lab.high-voltage.org CSeq: 1 ACK Content-Length: 0 La secuencia de comandos, CSeq, tiene el mismo número que el INVITE, pero el método es definido como ACK. En este punto, la media durante la sesión se transporta utilizando otro protocolo, típicamente RTP. Campo de header contiene un nuevo identificador de la transacción INVITE, ya que un ACK enviado a reconocer un 200 OK se considera una transacción por separado. Este mensaje indica que el intercambio es SIP de extremo a extremo como protocolo de señalización. Dos end-points ejecutan una pila de protocolo SIP y sabiendo de los otros las direcciones IP puede utilizar SIP para establecer una sesión de media entre ellos. Aunque menos evidente, aquí también se muestra el ejemplo cliente-servidor natural del protocolo SIP. Cuando Tesla origina el INVITE, está actuando como un cliente SIP. Cuando Marconi responde a la petición, está actuando como un servidor SIP. Después de establecida la sesión de media, Marconi origina un BYE y actúa como cliente de la SIP, al tiempo que Tesla actúa como 11

12 servidor de la SIP cuando responde.. En la Figura 2.1, Marconi envía una solicitud de BYE para terminar la comunicación: BYE SIP/2.0 Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hg4bk392kf Max-Forwards: 70 To: Nikola Tesla From: G. Marconi Call-ID: CSeq: 1 BYE Content-Length: 0 El campo Via en este ejemplo es rellenado con la acogida Marconi dirección y contiene un nuevo identificador dado que la transacción se considera un BYE aparte de la transacción INVITE ACK o transacciones que aparecen anteriormente. A partir del header se observa que esta petición se originó por Marconi, en que se invirtió a partir de los mensajes de la transacción anterior. Tesla, sin embargo, es capaz de identificar el cuadro de diálogo utilizando la presencia de los mismos y las etiquetas de identificación de llamada como el INVITE, y finalizar la sesión. Observar que todos los identificadores que se muestra en el ejemplo comienzan con la cadena z9hg4bk. Esta es una cadena especial que indica que la rama ID se ha calculado utilizando normas estrictas definidas en el RFC 3261 y es el resultado se puede utilizar como un identificador de transacción. La respuesta a la confirmación BYE es un 200 OK: SIP/ OK Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hg4bk392kf ;received= To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341 From: G. Marconi <sip:marconi@radio.org>;tag=a53e42 Call-ID: @lab.high-voltage.org CSeq: 1 BYE Content-Length: 0 La respuesta hace eco de la CSeq de la solicitud original: 1 BYE. 2.2 Llamada SIP con Proxy Server En el intercambio de mensajes de la figura 2.1, Tesla sabía la dirección IP de Marconi y pudo enviar el INVITE directamente a esa dirección. Esto no se dará en el caso general, una dirección IP no se puede utilizar como un número de teléfono. Una razón es que a menudo las direcciones IP asignadas en forma dinámica debido a la escasez de direcciones IPv4. Por ejemplo, cuando en un PC marca a un proveedor de servicios Internet (ISP), se le asigna una dirección IP utilizando DHCP. La dirección IP no cambia, pero es diferente para cada telefónico en el período de sesiones. Incluso para una conexión ADSL, una dirección IP puede cambiar después de cada reinicio de la PC. Además, una dirección IP no identifica unívocamente a un usuario, pero identifica un nodo en una red IP física. Podemos tener una dirección IP en su oficina, otro en casa, y aún otro cuando inicia la sesión de forma remota cuando viaje. Idealmente, habría una sola dirección. Por otra parte, una solicitud con rutas utilizando sólo las direcciones IP va a alcanzar sólo un end point de un solo dispositivo. Dado que la comunicación es típicamente de usuario a usuario en lugar de dispositivo a dispositivo, un esquema de direccionamiento más útil sería 12

13 permitir a un particular, a los usuarios llamar a otro usuario, lo que daría lugar a que la solicitud llegase a destino, independientemente del tipo de dispositivo que se utilizan. Figura 2.2. Un ejemplo de una llamada SIP con un proxy server. En la figura 2.2 se muestra un ejemplo típico de una llamada SIP con un tipo de servidor SIP llamado un "servidor proxy." En este ejemplo, Schroedinger llama a Heisenberg a través de un servidor proxy SIP. Un servidor proxy SIP funciona de modo similar a la un proxy HTTP y otros protocolos de Internet. Un servidor proxy SIP no crea o termina sesiones, pero se encuentra en medio de un intercambio de mensajes SIP. Este ejemplo muestra un servidor proxy, pero puede haber múltiples servidores proxy en una vía de señalización. SIP tiene dos grandes categorías de URI: los que corresponden a un usuario, y los que corresponden a un único dispositivo o end point. El usuario se conoce como URI una dirección de registro (ROA) y de una solicitud enviada a una dirección de registro requerirá búsquedas de bases de datos y de servicios y operaciones y de la característica que puede dar lugar a la solicitud de ser enviado a uno o más dispositivos finales. Un dispositivo URI es conocido como un contacto, y normalmente no requiere base de datos de búsquedas. Una dirección de registro suele ser URI Para utilizados en y desde la header, ya que esta es la forma de llegar a una persona Y es apta para el almacenamiento en los libros de dirección y en la repatriación de llamadas perdidas. Un dispositivo URI se utiliza generalmente en un campo de header de contacto y está asociado a un usuario por un período más corto de tiempo. El método de relación (o vinculante) de un contacto URI con una dirección de registro URI será discutido en el siguiente ejemplo. Dado que Schroedinger no sabe exactamente dónde se encuentra actualmente Heisenberg ni qué dispositivo está utilizando actualmente, se utiliza un servidor proxy SIP para la rutear el mensaje de INVITE. En primer lugar, se realiza una consulta DNS de la URI de Heisenberg (munich.de), y así se obtiene la dirección IP del proxy server que se ocupa de ese dominio proxy.munich.de. El INVITE es luego reenviado a dicha dirección IP: 13

14 INVITE SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKmp17a Max-Forwards: 70 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Subject: Where are you exactly? Contact: <sip:schroed5244@pc33.aol.com> Content-Type: application/sdp Content-Length: 159 v=0 o=schroed IN IP s=phone Call t=0 0 c=in IP m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 El proxy SIP busca el URI en la petición de URI (sorbo: werner. Heisenberg@munich.de) en su base de datos y localiza a Heisenberg. De esta forma finaliza el proceso de dos pasos: 1. Búsqueda DNS para localizar la dirección IP del servidor proxy; luego el proxy realiza una búsqueda en base de datos para encontrar la dirección IP. 2. El INVITE es forwardeado a Heisenberg con la dirección IP del segundo Via estampado con la dirección IP del proxy: INVITE sip:werner.heisenberg@ SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bKmp17a Max-Forwards: 69 To: Heisenberg <sip:werner.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@ CSeq: 1 INVITE Contact: <sip:schroed5244@pc33.aol.com> Content-Type: application/sdp Content-Length: 159 v=0 o=schroed IN IP s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Por los dos campos de header Via, Heisenberg sabe que el INVITE se ha ruteado a través de un servidor proxy. Habiendo recibido el INVITE, Heinsenberg envía una señal 180 de respuesta al proxy: SIP/ Ringing Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk ;received= Via: SIP/2.0/UDP :5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag= From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@ CSeq: 1 INVITE Contact: <sip:werner.heisenberg@ > Content-Length: 0 14

15 Una vez más, esta respuesta contiene los campos Via, y TO, From, Call-ID, y CSeq del INVITE. Luego se envía una respuesta a la dirección en el primer campo de encabezado Via, Proxy.munich.de para el número de puerto que figuran en el campo de encabezado Via: 5060, en el presente ejemplo. Notar que el campo de header tiene ahora una etiqueta que se le añade a para identificar este diálogo. El proxy recibe la respuesta, verifica que el primer campo de header ha Via contenga su propia dirección (proxy.munich.de), utiliza el identificador de la transacción Via header, que luego elimina Via campo de encabezado, luego remite la respuesta a la dirección en el siguiente campo del header Via: IP , puerto La consiguiente respuesta enviada por el servidor proxy para Schroedinger es: SIP/ Ringing Via: SIP/2.0/UDP :5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag= From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@ CSeq: 1 INVITE Contact: <sip:werner.heisenberg@ > Content-Length: 0 El uso de los campos en la header Via para ruteo y reenvío de mensajes SIP reduce la complejidad en la transmisión de mensajes. La solicitud requiere una búsqueda en base de datos por el proxy para ser transferido. La respuesta no requiere de búsqueda debido a que el ruteo está incorporado en el mensaje en el campo Via campos. Además, este asegura que las respuestas a través de la ruta de vuelta el mismo conjunto de los poderes que se presente la petición. La llamada es aceptada por Heisenberg, que envía un 200 OK como respuesta: SIP/ OK Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk ;received= Via: SIP/2.0/UDP :5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag= From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@ CSeq: 1 INVITE Contact: <sip:werner.heisenberg@ > Content-Type: application/sdp Content-Length: 159 v=0 o=heisenberg IN IP s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 El servidor proxy reenvía el 200 OK mensaje después de eliminar a Schroedinger en el primer Via: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag= From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@ CSeq: 1 INVITE Contact: <sip:werner.heisenberg@ > Content-Type: application/sdp Content-Length: 159 v=0 15

16 o=heisenberg IN IP c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 La presencia de la header de contacto sobre el terreno con la dirección del SIP URI Heisenberg en las 200 OK Schroedinger permite enviar directamente la ACK a Heisenberg, sin pasar por el proxy. Esta petición, y todas las futuras solicitudes seguirán utilizando esta etiqueta en la header TO ACK sip:werner.heisenberg@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKka42 Max-Forwards: 70 To: Heisenberg <sip:werner.heisenberg@munich.de>;tag= From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@ CSeq: 1 ACK Content-Length: 0 Esto demuestra que el servidor proxy no es realmente "en la llamada". Facilita a los dos extremos de localización y contacto con los demás, pero puede retirarse de la señalización camino tan pronto como ya no añade ningún valor al intercambio. Un servidor proxy puede forzar más a la ruta de mensajes a través de él mediante la inserción del campo Record- Route. Además, es posible disponer de un servidor proxy que no retiene ningún conocimiento del hecho de que Hay un período de sesiones establecido entre Schroedinger y Heisenberg (a que se refiere información de estado de la llamada). Tener en cuenta que los medios de comunicación son siempre de extremo a extremo y no a través del proxy. SIP en el camino de la señalización de los mensajes es totalmente independiente de la ruta de la media. En telefonía, esto es descrito como la separación de canal de control y canal portador (bearer). La sesión de media termina cuando Heisenberg envía un BYE: BYE sip:schroed5244@pc33.aol.com SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK4332 Max-Forwards: 70 To: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 From: Heisenberg <sip:werner.heisenberg@munich.de>;tag= Call-ID: 10@ CSeq: 2000 BYE Content-Length: 0 Tenga en cuenta que la CSeq de Heisenberg fue inicializada en Cada dispositivo SIP mantiene su propio espacio independiente de CSeq. Schroedinger confirma con 200 OK respuesta: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bK4332 To: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 From: Heisenberg <sip:werner.heisenberg@munich.de>;tag= Call-ID: 10@ CSeq: 2000 BYE Content-Length: 0 16

17 2.3 SIP registro ejemplo En este ejemplo, se muestra en la Figura 2.3, Heisenberg envía una petición SIP REGISTER a un tipo de servidor SIP conocido como un servidor de registro. El servidor SIP Registrar recibe el mensaje y utiliza la información para actualizar su base de datos utilizada las peticiones SIP. "Conocido" dirección, tal vez impresa en su tarjeta de visita o se publica en una Figura 2.3. Ejemplo de registración SIP. El mensaje REGISTER enviado por Heinsenberg al SIP registrar tiene la siguiente forma: REGISTER sip:registrar.munich.de SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKus19 Max-Forwards: 70 To: Werner Heisenberg <sip:werner.heisenberg@munich.de> From: Werner Heisenberg <sip:werner.heisenberg@munich.de> ;tag=3431 Call-ID: 23@ CSeq: 1 REGISTER Contact: sip:werner.heisenberg@ Content-Length: 0 El Registrar server acepta la registración como satisfactoria y envía un 200 OK como respuesta a Heisenberg. SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bKus19 To: Werner Heisenberg <sip:werner.heisenberg@munich.de>;tag=8771 From: Werner Heisenberg <sip:werner.heisenberg@munich.de> ;tag=3431 Call-ID: 23@ CSeq: 1 REGISTER Contact: <sip:werner.heisenberg@munich.de>;expires=3600 Content-Length: 0 El contacto URI se devuelve junto con un parámetro de expiración, que indica cuánto tiempo es válido el registro, que en este caso es 1 hora (3600 segundos). Si Heisenberg quisiera que el registro sea válido más allá de ese intervalo, REGISTRO debe enviar otra solicitud en el intervalo de caducidad. El registro suele realizarse automáticamente en la inicialización de un dispositivo SIP y a intervalos regulares determinados por el intervalo elegido por expiración en el servidor de registro. El registro es un aditivo proceso aditivo de más de un dispositivo Pueden registrarse 17

18 en contra de un URI de SIP. Si más de un dispositivo está registrado, un apoderado podrá remitir la solicitud a uno o ambos dispositivos, ya sea en forma secuencial o paralela. Adicionalmente a las operaciones de registro, se puede utilizar para borrarlos u obtener una lista de los dispositivos actualmente registrados. 2.5 Transporte de los Mensajes La RFC 3261 define el uso de TCP, UDP o TLS. Un documento de extensión define el uso de SCTP. Como los mensajes SIP son transportados usando estos cuatro protocolos será descrito en las secciones siguientes. Capa de Aplicación Los protocolos usados en la capa de aplicación son varios: SIP: para la establecimiento, mantención y cierre de la comunicación RTP: Real Time Transport Protocol SDP: Session Description Protocol Discutiremos ahora el uso de UDP, TCP, TLS y SCTP para el transporte de SIP Transporte UDP Cuando se usa UDP, cada mensaje de Request o Response es transportado en un datagrama UDP individual. La figura muestra un Sip BYE Request usando UDP 18

19 El puerto de origen es elegido de un pool de puertos permitidos o alguna veces el puerto default 5060 es usado. La falta de handshaking o acknowledgment en UDP significa que el datagrama podría perderse y el mensaje SIP junto con el. Sin embargo, el checksum permite a UDP descartar paquetes dañados o asumir que el mensaje esta completo y sin errores Transporte TCP TCP provee un nivel de transporte confiable, pero al costo de complejidad y retardo en las retransmisiones sobre la red. El uso de TCP en mensajes SIP es mostrado en la figura: 19

20 Al igual que en el caso UDP el well-known sip port 5060 es elegido para el puerto de destino; y el puerto de origen es elegido de un pool de puertos elegidos. Antes de que el mensaje pueda ser enviado la conexión TCP debe ser establecida entre los extremos. Este intercambio de datagramas es mostrado en la figura anterior como una única flecha, pero en realidad es un three-way handshake entre los endpoints. Una vez que la conexión es establecida el mensaje es establecido. La desventaja de TCP es el establecimiento de la conexión y la necesidad de los servers para mantener el estado de la conexión en la capa de transporte Transporte TLS (Transport Layer Security) TLS esta basado en el protocolo SSL (Secure Socket Layer) usado en los navegadores Web. TLS es comúnmente utilizado hoy en día para sitios Web seguros usando https. Información usando el transporte de TLS es encriptada para que una tercera parte no pueda interceptarla. Previamente al transporte un TLS handshake es usado para establecer la conexión, negociando las encryption keys usadas para el transporte TLS. Los cálculos criptográficos para TLS no son triviales y varias mensajes de ida y vuelta son necesarios para abrir una conexión, lo que puede agregar latencia a los mensajes. Además la verificación del certificado introduce latencia también. Sin embargo transporte por TLS tiene claramente ventajas de seguridad sobre UDP y TCP. Muchos sistemas operativos soportan TLS debido a su amplio uso en https. 20

21 2.5.4 Transporte SCTP ( Stream Control Transport Protocol) SCTP es similar a TCP en el sentido que provee transporte confiable basado en stream. Sin embargo tiene algunas ventajas sobre TCP para una transmisión basada en mensajes. SCTP esta pensado para la transmisión de mensajes, con los cual los mensajes individuales son separados en la capa de transporte. SCTP requiere que el sistema operativo lo soporte lo cual inicialmente demorara su uso en Internet. Hay que notar que la ventaja de SCTP sobre TCP solamente ocurre durante perdida de paquetes. En un ambiente sin perdida la performance es idéntica. Si una conexión TCP esta siendo usada para varias transacciones y diálogos SIP, el problema de head of line blocking puede causar que el buffer que contiene validos mensajes SIP, que pudieran ser procesados por el Server. Debido a su delineamiento por mensajes, SCTP es capaz de continuar reenviando mensajes a la capa de aplicación mientras simultáneamente pide retransmisiones de mensajes descartados. Notar que esto es un problema solamente cuando múltiples aplicaciones son multiplexadas sobre una sola conexión TCP. Un ejemplo de esto es una conexión TCP entre dos Proxy servers. Para la conexión entre un cliente y un Proxy esto no seria un problema a menos que tenga varios diálogos establecidos. El uso de SIP sobre SCTP esta descripto en Rosenberg, J., H. Schulzrinne, and G. Camarillo, The Stream Control Transmission Protocol as a Transport for the Session Initiation Protocol, IETF Internet-Draft, Work inprogress,

22 2.6 Firewall y NAT Firewalls La mayoría de las LAN corporativas se conectan a Internet a través de un firewall. A firewall es un software usado para proteger la LAN de varios tipos de ataques y accesos no autorizados. Algunas veces son usados para prevenir que usuarios accedas a ciertos recursos de Internet. A firewall puede ser pensado como una puerta de un solo sentido que permite paquetes salientes de la LAN hacia Internet, pero bloquea paquetes entrantes desde Internet a menos que estos sean respuestas a requerimientos. Solo algunos ciertos tipos de requests desde Internet serán permitidos a pasar a la LAN, como ser http request hacia el Server Web corporativo. El firewall hace esto manteniendo un rastro de las conexiones TCP abiertas. Los firewall presentan un desafió para las sesiones SIP. Debido a que SIP puede usar TCP y un puerto bien conocido, configurando el firewall para dejar pasar SIP no es muy dificultoso. Sin embargo esto no ayuda a la sesión del audio, la cual usa RTP sobre UDP en varios puertos que serán bloqueados por el firewall. Un firewall necesita entender SIP, para leer el contenido del INVITE y 200 OK response, y así extraer las direcciones IP y los números de puertos desde la descripción de la Sesión SPD y abrir esos puertos para permitir que pase ese trafico. Esos puertos pueden ser cerrados cuando un BYE es enviado o un temer expire. NAT Network address tranlator (NAT) también puede causar serios problemas para Sip. Nat es básicamente usado para conservar direcciones IPv4. Es usado en un router o firewall que provee la única conexión de la LAN a Internet. Nat permite a ip privadas ser usadas internamente dentro de la LAN. Cuando un paquete es enviado desde la LAN hacia Internet, el NAT cambia la ip privada en el heather del datagrama por una ip publica. Esto significa que cada nodo en la red no tiene una dirección publica (única). Respuestas desde Internet son traducidas hacia atrás a las ip privadas. Sin embargo NAT no es completamente transparente para niveles superiores. Para un protocolo de señalización como SIP, NAT puede causar problemas particulares. Debido a que las respuestas en SIP son ruteadas usando el heather Via, un dispositivo detrás de un NAT, colocara su no ruteable ip privada en el campo Via de los mensajes que origina. Cuando el requerimientos es enviado al exterior de la LAN, los encabezados IP y UDP serán reescritos con una Ip publica y otro puerto aleatorio. El Nat mantendrá un registro de las ips privadas, publicas y los puertos. Sin embargo, la direccion IP en el mensaje SIP, así como también los campos Via y Contact o las IPs en el campo SPD no serán reescritas y no serán ruteables. 22

23 INVITE SIP/2.0 Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hg4bkfw19b Max-Forwards: 70 To: G. Marconi From: Nikola Tesla Call-ID: CSeq: 1 INVITE Subject: About That Power Outage... Contact: <sip:n.tesla@lab.high-voltage.org> Content-Type: application/sdp Content-Length: 158 v=0 o=tesla IN IP4 lab.high-voltage.org s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 SIP/ OK Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hg4bkfw19b ;received= To: G. Marconi <sip:marconi@radio.org>;tag=a53e42 From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341 Call-ID: @lab.high-voltage.org CSeq: 1 INVITE Contact: <sip:marconi@tower.radio.org> Content-Type: application/sdp Content-Length: 155 v=0 o=marconi IN IP4 tower.radio.org s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/

24 * 8 # * 8 # TP2 SIP Para parcialmente resolver este problema, SIP tiene un mecanismo para detectar la presencia de NAT. Cada Proxy o user agent que recive un request chequea la ip recibida con la ip en el campo Via. Si las direcciones son diferentes, entonces hay un NAT entre ellos. El no ruteable Via header es arreglado agregandole un received tag que contiene la ip publica con la que se recibió el paquete. Fuera del NAT, la respuesta es ruteada usando la ip recibida. Dentro del NAT, la direccion de Via es usada. Esto no resuelve el problema de la transmisión del audio/video. Otro problema con NAT es el periodo de tiempo que el NAT mantiene el bindeo entre la ip publica y privada. Para una conexión TCP esto no es un problema ya que el bindeo se mantiene hasta que se cierre la conexión. Para una sesión UDP SIP, el periodo de tiempo es determinado por la aplicación. Si el bindeo fuese removido antes de que el BYE fuese enviado, la conexión se cerraría y no habría posibilidad de señalización. Por lo tanto un keepalive mecahnism debe ser usado para mantener el bindeo. Problema del Nat USER A ip Pr2 ippr1 ip Pu1 red ip SIP PROXY USER B red ip USER A Pr2(5060) INVITE Pu2(5061) ip Pu2 ip Pu3 Via: UDP (5060) From:userA@dominioA.com To: userb@dominiob.com Contact: c= m=audio Via: cada sip divice que origina o foward un mensaje sip pone su direccion en el campo via. Contact: contiene la direccion Sip del dispositivo, conocido como user agent (UA). esta direccion puede ser utilizada para rutear mensajes en forma directa a ese dispositivo. Pr2(5060) 200OK Pu2(5061) Via: (5060) Contact: IpPu3 c= Pu3 m = audio responde a Contact directamente Pu1(1024) INVITE Pu2(5061) Via: (5060) Contact: c= m=audio Pu1(1024) 200OK Pu2(5061) Via: ) Contact: IpPu3 c= Pu3 m = audio rutea el mensaje mirando el To del Invite y consultando su tabla No funciona si el Nat cambio el puerto, pq el received tag no lo incluye Pu2(5061) INVITE Pu3(5060) Via: Pu2(5061) Via: (5060); received=pu1 Contact: c= m=audio Pu2(5061) 200OK Pu3(5060) Via:Pu2(5061) Via: (5060); received= Pu1 Contact: Pu3 c= Pu3 m = audio La parte llamada solo tiena ip del proxy sip y la ip privada del que llama. La respuesta es enviada a la direccion y puerto que figura en el primer Via Pr2(5060) ACK Pu3(5061) Via: (5060) c= m=audio Pu1(1024) ACK Pu3(5061) Via: (5060) c= m=audio Pr2(49430 ) MEDIA SESSION Pu3(49172 ) Pu1(1025) MEDIA SESSION Pu 3(49172) La sesion de media empieza usando la informacion pasa por SPD 24

25 * 8 # * 8 # TP2 SIP Solucion al problema de Nat USER A ip Pr2 1 ippr1 Pr2(5060) INVITE Pu2(5061) Via: UDP (5060) - dispositiva origina Contact: c= m=audio Via: cada sip divice que origina o foward un mensaje sip pone su direccion en el campo via. Contact: contiene la direccion Sip del dispositivo, conocido como user agent (UA). esta direccion puede ser utilizada para rutear mensajes en forma directa a ese dispositivo. TRYING ip Pu1 red ip Pu1(44315) INVITE Pu2(5061) Via: (5060) Contact: c= m=audio TRYING RINING ip Pu2 rutea el mensaje mirando el To del Invite y consultando su tabla SIP PROXY USER B + SESSION BORDER CONTROLLER red ip Pu2(5061) INVITE Pu3(5060) Via: Pu2(5061) Contact: Pu2(5061) c= Pu2 m=audio RINING USER B ip Pu3 La respuesta es enviada a la direccion y puerto que figura en el primer Via RINING Pr2(5060) 200OK Pu2(5061) Via: (5060) Contact: IpPu2 c= Pu2 m = audio Pu1(44315) 200OK Pu2(5061) Via: (5060), received=pu1 Contact: IpPu2 c= Pu2 m = audio Pu2(5061) 200OK Pu3(5060) Via:Pu2(5061) ; received= Pu2 Via: (5060); received= Pu1 Contact: IpPu3 c= Pu3 m = audio Pr2(5060) ACK Pu2(5061) Via: (5060) Pu1(44315) ACK Pu2(5061) Via: (5060) Pr2(13126 ) MEDIA SESSION Pu2 (40062 ) Pu1(44316 ) MEDIA SESSION Pu2 (40062 ) Pu2(5061) ACK Pu3(5060) Via: (5060) Pu2(40060 ) MEDIA SESSION Pu3(16480 ) La sesion de media empieza usando la informacion pasa por SPD Otro problema con NAT es el periodo de tiempo que el NAT mantiene el bindeo entre la ip publica y privada. Para una conexión TCP esto no es un problema ya que el bindeo se mantiene hasta que se cierre la conexión. Para una sesión UDP SIP, el periodo de tiempo es determinado por la aplicación. Si el bindeo fuese removido antes de que el BYE fuese enviado, la conexión se cerraría y no habría posibilidad de señalización. Por lo tanto un keepalive mecanismo debe ser usado para mantener el bindeo. 25