You are on page 1of 129

INGENIERA INFORMTICA TESIS DE GRADO

SOLUCIN DE TRANSVERSABILIDAD DE NAT PARA EL INTERCAMBIO DE FLUJOS DE MEDIOS SOBRE UDP EN COMUNICACIONES VOIP CON SEALIZACIN SIP

Vctor Eduardo Cartes Len <victor.cartes@tivatechnologies.com> Juan Manuel Hanson Urunaga <juan.hanson@tivatechnologies.com> Tutor: Ing. Juan de Dios Fernndez

2008 Asuncin Paraguay

Palabras Clave: VoIP, NAT, NAT Traversal, SIP, SDP, RTP, P2P, Peer to Peer.

Resumen
El propsito de esta investigacin fue desarrollar una solucin para la problemtica de la transversabilidad de NAT en el intercambio de flujos de medios en comunicaciones VoIP con sealizacin SIP, aplicable a modelos de servicio en los que ni el Agente de Usuario SIP ni la red IP de acceso del abonado son controlados; y que fuera ms eficiente que las soluciones actuales para estos modelos. Los autores estudiaron a profundidad el problema que representan los NAT para comunicaciones VoIP y las soluciones actuales desde documentos oficiales y otras fuentes. Se mont un laboratorio para validar la informacin recopilada realizando llamadas de pruebas y analizando los paquetes intercambiados entre los extremos de la llamada frente a distintos escenarios. Los autores elaboraron una serie de recomendaciones para la configuracin de una red VoIP compatible con NAT. Se desarroll y document un modelo de solucin de transversabilidad de NAT compatible con los modelos de servicio estudiados, que optimiza el consumo de ancho de banda en los enlaces de la operadora y a la vez minimiza los factores relacionados a la solucin que podran degradar la calidad de la comunicacin. Los autores disearon y desarrollaron adems un servidor SIP bsico y un proxy RTP para implementar la solucin diseada y poder validarla mediante pruebas de laboratorio.

Abstract
This researchs propose was to develop a solution to NAT traversal for media flow exchange in VoIP communication with SIP signaling, applicable to service models which neither the SIP User Agent, neither the subscriber are controlled; and also it was more efficient than current solutions for these models. Authors studied deeply NAT issue for VoIP communications and current solutions from official documents and other sources. It was mounted a laboratory in order to validate recovered information by making test calls and by analyzing exchanged packets between call peers on different scenarios. Authors elaborated a list of recommendations for configuring a NAT capable VoIP network. It was developed and documented a NAT traversal solution supported by studied service models, which optimizes bandwidth use on operators links and at the same time minimizes factors related to this solution that could degrade quality of communication. Authors also developed a basic SIP server and RTP proxy to deploy the solution model and validate it by making laboratory tests.

A Beln, mi amada esposa, sin cuyo soporte constante e incondicional no habra podido llegar hasta aqu. Vctor

A mis padres y hermanos por el apoyo recibido en todo momento. Juan

Agradecimientos
Agradecemos a todos quienes han colaborado directa o indirectamente con nosotros para el logro este trabajo, en especial a ConeXionGroup y su departamento de Investigacin y Desarrollo, y al Ingeniero Juan de Dios Fernndez.

NDICE DE CONTENIDO
CAPTULO I CAPTULO II INTRODUCCIN ................................................................ 1 MARCO TERICO ............................................................. 9

II.1 - FUNDAMENTOS BSICOS DE VOZ SOBRE IP ..................................................... 9 II.1.a II.1.b II.1.c II.1.d Transmisin de Voz sobre una red conmutacin de paquetes .......... 10 Sealizacin de la llamada ................................................................ 12 Modelos de Servicio de Telefona IP ................................................ 29 Implicancias de Calidad .................................................................... 36

II.2 - TRADUCCIN DE DIRECCIONES DE RED (NAT) ............................................. 40 II.2.a II.2.b II.2.c II.2.d II.2.e mbitos de Direcciones de Red ........................................................ 40 Definicin de NAT............................................................................ 41 Por qu implementar NAT ................................................................ 41 Funcionamiento de un NAT .............................................................. 43 Implementaciones de NAT y polticas de mapeo ............................. 48

II.3 - PROBLEMTICA DE LOS NAT EN COMUNICACIONES VOIP ............................ 50 II.3.a II.3.b Problemas respecto a la sealizacin de la llamada .......................... 51 Problemas respecto al transporte del flujo de medios ....................... 54

II.4 - SOLUCIONES DE TRANSVERSABILIDAD DE NAT APLICABLES A VOIP SOBRE UDP ....................................................................................................................... 57 II.4.a II.4.b II.4.c II.4.d II.4.e Autocorreccin Unilateral de Direcciones ........................................ 57 Retransmisin del Flujo de Medios................................................... 60 ICE .................................................................................................... 63 STUN v2 ........................................................................................... 68 Gateways de Nivel de Aplicacin ..................................................... 69

CAPTULO III - MARCO METODOLGICO ........................................... 73 III.1 - PROFUNDIDAD Y DISEO DE LA TESIS .......................................................... 73 III.2 - REALIZACIN DE LA TESIS ........................................................................... 73 III.3 - INSTRUMENTOS Y PROCEDIMIENTOS UTILIZADOS PARA LA RECOLECCIN Y
EL TRATAMIENTO DE LA INFORMACIN ................................................................. 75

III.4 - MUESTRA UTILIZADA .................................................................................. 75

III.5 - ADECUACIN DE LOS MTODOS A LOS OBJETIVOS DE LA TESIS ..................... 75 III.6 - TRATAMIENTO DE LOS DATOS ...................................................................... 76 CAPTULO IV - RESULTADOS ................................................................... 77 IV.1 - MEJORES PRCTICAS PARA FACILITAR LA TRANSVERSABILIDAD DE NAT
PARA VOIP ............................................................................................................. 77

IV.1.a IV.1.b IV.1.c IV.1.d IV.1.e -

Sealizacin Simtrica y RTP Simtrico .......................................... 77 NAT con reutilizacin de mapeos independiente del destino ........... 78 Respuestas al origen del mensaje ...................................................... 78 Retransmisin permanente de la sealizacin................................... 79 Refresco peridico del mapeo de NAT ............................................. 79

IV.2 - EVALUACIN DEL ESTADO DEL ARTE .......................................................... 81 IV.2.a Debilidades de la retransmisin de flujos de medios ........................ 82

IV.3 - NUESTRA SOLUCIN .................................................................................... 86 IV.3.a IV.3.b Deteccin de NAT e identificacin de tipo de NAT ......................... 87 Intercambio del Flujo RTP a travs de NATs ................................... 95 CONCLUSIONES ............................................................. 111

CAPTULO V -

CAPTULO VI - RECOMENDACIONES .................................................. 114 BIBLIOGRAFA ............................................................................................... 115 ANEXOS ............................................................................................................ 118

LISTA DE FIGURAS
Figura 1 - Pila de Protocolos para VoIP propuesta por la IETF ........................... 10 Figura 2 Sintaxis de Mensajes SIP (BNF) ......................................................... 17 Figura 3 - Sintaxis (BNF) de encabezado SIP ...................................................... 17 Figura 4 - Sintaxis (BNF) del Request-Line.......................................................... 18 Figura 5 - Mensaje SIP Invite ............................................................................... 18 Figura 6 - Sintaxis de Status-Line (BNF) ............................................................. 19 Figura 7 - Sintaxis de Lineas SDP (BNF) ............................................................. 21 Figura 8: Sintaxis del Campo SDP "c" (Basado en RFC 4566) ............................ 23 Figura 9 - Sintaxis del Campo SDP "m" ............................................................... 23

Figura 10 - Secuencia de Sealizacin SIP ........................................................... 26 Figura 11 - Mensaje SIP INVITE ......................................................................... 27 Figura 13 - Modelos de Servicios de Telefona IP ................................................ 30 Figura 14 - Red de una Operadora VoIP de Lneas Troncales ............................. 34 Figura 15 - Red de una Operadora VoIP Clase 5 .................................................. 36 Figura 16 - Reutilizacin de mapeos de NAT independiente del destino ............. 45 Figura 17 - Reutilizacin de mapeos de NAT dependiente de la direccin de red destino ........................................................................................................... 47 Figura 18 - Reutilizacin de mapeos de NAT dependiente de direccin y puerto destino ........................................................................................................... 48 Figura 19 - Implementacin de Polticas de Reutilizacin de Mapeos ................. 49 Figura 20 - Escenario de Interconexin a travs de NATs ................................... 51 Figura 21 - Mensaje SIP recibido por el SIP Server ............................................. 53 Figura 22 - Secuencia Inicial de Sealizacin SIP de una sesin ......................... 55 Figura 23 - Direccin de Transporte en cuerpo SDP ............................................ 55 Figura 24 - Escenario par Retransmisin de Flujos de Medios ............................ 61 Figura 25 - Escenario simple para la implementacin de ICE .............................. 64 Figura 26 - Direcciones Candidatas de ICE .......................................................... 65 Figura 27 - Frentes de Soluciones de Transversabilidad de NATs ....................... 70 Figura 28 - Aplicacin de la extensin SIP: rport ................................................ 78 Figura 29 - Throughput real en Kbps sobre Ethernet segn cdec ....................... 85 Figura 30 - Direcciones de transporte en mensaje SIP REGISTER ..................... 89 Figura 31 - Escenario para la aplicacin de Reflexin Dirigida ........................... 90 Figura 32 - Secuencia de sealizacin para reconocimiento del tipo de NAT ..... 91 Figura 33 - Escenario para nuestra solucin de transversabilidad de NAT para el intercambio de flujos de medios ................................................................... 97 Figura 34 - Secuencia de mensajera para nuestra solucin ................................ 101

LISTA DE TABLAS
Tabla 1 - Campos SDP de Nivel de Sesin ........................................................... 21 Tabla 2 - Campos SDP de Nivel de Tiempo ......................................................... 22 Tabla 3 - Campos SDP de Nivel de Medios ......................................................... 22 Tabla 4 - Categorizacin de Conmutadores .......................................................... 33 Tabla 5 NATs ms utilizados y sus aplicaciones y sus polticas de reutilizacin de mapeos ...................................................................................................... 49 Tabla 6 - Throughput por Cdec ........................................................................... 84 Tabla 7 - Nodos del escenario para aplicacin de Reflexin Dirigida .................. 90 Tabla 8 - Tabla de mapeos de NAT activos ........................................................ 106 Tabla 9 - Tabla de mapeos de NAT activos (2) .................................................. 109

LISTA DE ANEXOS
ANEXO 1: Servidor SIP y Proxy RTP diseados y desarrollados por los autores de esta tesis para probar el modelo de transversabilidad de NAT desarrollado

CAPTULO I -

INTRODUCCIN

Internet es utilizado para el transporte de varios servicios adems del modelo bsico de transmisin de archivos, uno de ellos es el intercambio interactivo de voz y vdeo. Voz sobre IP (en adelante VoIP, por sus siglas en ingls: Voice over IP) sali al alcance del desarrollo de Internet, convergiendo dos corrientes tecnolgicas originalmente separadas: el de la telefona de Graham Bell y el de las redes de conmutacin de paquetes TCP/IP. El crecimiento de Internet ha sido tan acelerado al punto de comprometer la capacidad de direccionamiento IP. Hoy da hay ms nodos conectados a la Internet que direcciones IPv4 de mbito pblico asignables. La traduccin de direcciones de red (en adelante NAT, por sus siglas en ingls: Network Address Translation) representa una solucin a corto plazo mientras se implementa a largo plazo una solucin ms conveniente: la versin 6 del Protocolo de Internet (en adelante IPv6), que proveer un espectro mayor de direcciones IP. An as, la economizacin de direcciones no es la nica razn que impulsa la implementacin de NAT, sino tambin la seguridad inherente de separar los mbitos de direcciones IP manteniendo la conectividad de las redes. NAT dificulta la implementacin de comunicaciones de extremo a extremo (en adelante P2P, por su ttulo en ingls: Peer to Peer) como VoIP, el motivo principal es que en estas comunicaciones se negocian a nivel de aplicacin direcciones de transporte para el intercambio de datos de extremo a extremo, en el caso de VoIP, para el intercambio de flujos de medios; ms especficamente: la voz. La Transversabilidad de NAT para VoIP es la capacidad de establecer una sesin VoIP entre dos extremos, cuando el trfico IP entre ellos cursa a travs de uno o varios NAT.

Se han propuesto varias soluciones para este problema, y cada una de stas es propicia para cierto escenario pero es ineficiente, dbil o incluso inviable para otros escenarios.

I.1 - Definicin del Problema La industria de las telecomunicaciones ha dado lugar a modelos de servicio basados en VoIP caracterizados por ser directos al abonado (Conmutacin de Clase 5) y por no tener control sobre los Agentes de Usuario SIP de los abonados, ni sobre las redes IP de acceso de los mismos. Estos modelos de servicio soportan una gran variedad de dispositivos clientes y de diversos fabricantes, adems de la heterogeneidad de escenarios de conexin de sus abonados, admitiendo generalmente las conexiones a travs de Internet. La nica solucin formal y completa de transversabilidad de NAT para estos modelos de servicio, la retransmisin de los flujos de medios entre los extremos, es muy ineficiente en trminos de consumo de ancho de banda adems de restar calidad a la comunicacin. El propsito de esta investigacin es desarrollar un modelo de solucin ms eficiente para los modelos de servicio mencionados.

I.2 - Necesidad de Estudiar el Problema La necesidad de estudiar el problema radica en que los costos relacionados a las soluciones de transversabilidad de NAT para los modelos de servicio mencionados pueden ser muy elevados dependiendo del volumen de llamadas que se gestione. Estos costos estn ligados principalmente al consumo de ancho de banda en los enlaces de la operadora. Adems, estas soluciones afectan negativamente la calidad de las llamadas, empobreciendo la experiencia de los usuarios. 2

Estos modelos de servicio por su naturaleza podran ser los ms costo-efectivos entre los servicios de conmutacin VoIP de clase 5, principalmente porque no requieren implementar ni mantener las redes de acceso de sus abonados, sin embargo, los NAT y las soluciones actuales de transversabilidad de NAT les restan potencial comercial. Por estos motivos es necesario seguir trabajando en este problema, an cuando ya existen soluciones formales aplicables.

I.3 - Significacin del Problema El tratamiento de este problema es de inters de operadoras VoIP que brindan servicios directo al abonado sobre una red no controlada y sin acceso administrativo ni restricciones especiales sobre los Agentes de Usuario SIP. As tambin, es de inters para compaas que han implementado su red telefnica privada y/o call centers sobre redes IP no controladas. Adems, la documentacin clara, precisa y profunda del problema y de su tratamiento ser de utilidad para desarrolladores de aplicaciones VoIP.

I.4 - Delimitacin del Problema El presente estudio se realiz entre los aos 2006 y 2007. VoIP engloba varios estndares y corrientes de tecnologa, pero este estudio se basa especficamente en la arquitectura propuesta por la IETF, que defini los protocolos SIP (Rosenberg, et al., 2002) para la sealizacin de la llamada, SDP (Handley, et al., 2006) para la negociacin del intercambio de flujos de medios y RTP (Schulzrinne, et al., 2003) para el transporte de la voz codificada. Todos estos protocolos pueden operar sobre distintos protocolos de capa de transporte, esta tesis se basa en su aplicacin sobre el protocolo UDP. 3

La problemtica de NAT en comunicaciones VoIP puede dividirse en dos mbitos: el problema para la sealizacin y el problema para el intercambio de flujos de medios. En esta tesis se tratar especialmente el problema para el intercambio de flujos de medios, puesto que las soluciones actuales para la sealizacin son suficientes.

I.5 - Objetivos

I.5.a - Objetivo General Desarrollar un nuevo modelo de solucin de transversabilidad de NAT para el intercambio de flujos de medios sobre UDP en comunicaciones VoIP con sealizacin SIP, para modelos de servicios directos al abonado sin control sobre su red de acceso ni sobre su Agente de Usuario.

I.5.b - Objetivos Especficos


1.

Describir a detalle y de una manera accesible la problemtica de NAT en comunicaciones VoIP.

2.

Disear una solucin para modelos de servicios directos al abonado que no requiera control sobre la red IP de acceso del abonado ni sobre los agentes de usuario SIP.

3.

Lograr que la solucin mencionada no requiera nuevas extensiones en los protocolos soportados por los agentes involucrados.

4.

Lograr que la solucin mencionada sea ms eficiente que las soluciones actuales aplicables a los mismos modelos de servicio.

5.

Lograr que la solucin mencionada minimice los efectos negativos de las otras soluciones actuales aplicables sobre la calidad de la comunicacin.

I.6 - Definicin de Trminos AAA: Authentication, Authorization and Accounting; Autenticacin, Autorizacin y Contabilidad. ALG: Application Level Gateway, Gateway de Nivel de Aplicacin. Codec: Coder Decoder, Codificador Decodificador. ICE: Interactive Connectivity Establishment, Establecimiento de Conectividad Interactiva. IETF: Internet Enginering Task Force, Fuerza de Trabajo de Ingeniera de Internet. IP: Internet Protocol, o Protocolo de Internet. ISP: Internet Service Provider, Proveedor de Servicios de Internet. NAPT: Network Address and Port Translation, Traduccin de Direccin de Red y Puerto de Transporte. NAT: Acrnimo de Network Address Translation, o Traduccin de Direcciones de Red. Tambin se atribuye el trmino a: Traduccin de Direcciones de Red y de Puertos de Transporte; y a los dispositivos que realizan esta tarea. P2P: Peer to Peer, De Extremo a Extremo. PC: Personal Computer, Computador Personal. PCM: Pulse Coded Modulation, Modulacin por Codificacin de Pulsos.

PSTN: Public Switched Telephony Network, Red Pblica Conmutada de Telefona. RFC: Request For Comment, Solicitud de Comentarios. Documentos oficiales de la IETF que definen estndares. RTCP: RTP Control Protocol, o Protocolo de Control de RTP. RTP: Real Time Transport Protocol, o Protocolo de Transporte de Tiempo Real. SDP: Session Description Protocol, Protocolo de Descripcin de Sesin. SIP: Session Initiation Protocol, o Protocolo de Inicio de Sesin. STUN (2): Session Traversal Utilities for NAT, Utilitarios de transversabilidad de NAT para Sesiones. STUN: Simple Traversal of UDP through NAT, Transversabilidad Simple de UDP a travs de NAT. TCP: Transport Control Protocol, o Protocolo de Control de Transporte. TURN: Traversal Using Relay NAT, Transversabilidad de NAT Usando Retransmisin. UA: User Agent, Agente de Usuario. UAC: User Agent Client, Agente de Usuario Cliente. UAS: User Agent Servidor, Agente de Usuario Servidor. UDP: User Datagram Protocol, o Protocolo de Datagramas de Usuario.

UNSAF:

Unilateral

Self-Address

Fixing,

Autocorreccin

Unilateral

de

Direcciones. URI: Uniform Resource Identifier, Identificador de Recurso Uniforme. VoIP: Voice over IP (Internet Protocol), Voz sobre IP (Protocolo de Internet).

I.7 - Esquema de la Tesis Captulo I: Introduccin. Presenta una introduccin al contenido de la tesis, definiendo el problema de investigacin y justificando la necesidad del estudio; adems define los objetivos del presente trabajo. Captulo II: Marco Terico de la Tesis. Documenta los fundamentos tericos de nuestra investigacin. Apartado II.1: VoIP. Define fundamentos bsicos sobre VoIP. Se enfatiza la sealizacin de la llamada mediante el protocolo SIP, los modelos de servicio, y las implicancias de calidad de la comunicacin. Apartado II.2: Presenta la Traduccin de Direcciones de Red, NAT; define conceptos bsicos, justifica su uso, describe su arquitectura y su tipificacin basada en las polticas de reutilizacin de mapeos. Apartado II.3: Presenta los problemas de transversabilidad de NAT para comunicaciones VoIP. Apartado II.4: Expone las soluciones actuales a la problemtica de transversabilidad de NAT para VoIP. Captulo III: Marco Metodolgico. Define el tipo de investigacin y los detalles de la realizacin del presente trabajo.

Captulo IV: Expone los resultados de la investigacin. Evala el estado del arte dejando a la luz la necesidad de optimizar las soluciones actuales para ciertos escenarios. Propone un nuevo modelo de solucin de transversabilidad de NATs para el intercambio de flujos de medios en comunicaciones VoIP. Captulo V: Conclusiones. Presenta una breve evaluacin de los resultados obtenidos en funcin de los objetivos de la tesis. Captulo VI: Recomendaciones. Sugiere temas de investigacin complementarios de esta tesis.

CAPTULO II - MARCO TERICO

II.1 - Fundamentos Bsicos de Voz sobre IP Voz sobre el Protocolo de Internet, (en adelante: VoIP, por sus siglas en ingls: Voice over Internet Protocol) es un conjunto de tecnologas orientadas a la transmisin en paquetes de voz codificada a travs de una red IP. Esto permite transmitir datos y voz sobre una misma red, dando lugar a una reduccin de los costos de implantacin y mantenimiento de las redes de comunicacin al disminuir la complejidad de las mismas, ofreciendo adems la flexibilidad de soportar nuevos servicios como video conferencia a travs de Internet o la conexin con PCs (Hardy, 2003). Con el trmino voz, en un sentido ms general, nos referiremos a una seal de audio. El enfoque de nuestro estudio no discrimina una seal de audio o video, as que en adelante, cuando utilicemos el trmino voz nos referiremos tambin a medios en general. La Figura 1 muestra la pila de protocolos propuesta por la Fuerza de Trabajo de Ingeniera de Internet (en adelante IETF, por sus siglas en ingls: Internet Engeniering Task Force) como arquitectura para VoIP, si bien cada protocolo por separado no ha sido diseado especficamente para VoIP. En esta investigacin nos basaremos en esta arquitectura, por ser la predominante en la actualidad para comunicaciones VoIP. Esta arquitectura contempla el Protocolo de Iniciacin de Sesin (en adelante SIP, por sus siglas en ingls: Session Initiation Protocol) (Rosenberg, et al., 2002), para la sealizacin de las sesiones; mientras que el Protocolo de Descripcin de Sesin (en adelante SDP por su ttulo en ingls: Session Description Protocol) (Handley, et al., 2006) es utilizado para la negociacin del intercambio de flujos de voz entre los extremos de la sesin. El Protocolo de Transporte de Tiempo Real (en adelante

RTP por sus siglas en ingls: Real-Time Transport Protocol) (Schulzrinne, et al., 2003) es empleado para el transporte de las tramas de voz codificadas.

Figura 1 - Pila de Protocolos para VoIP propuesta por la IETF

SDP (RFC 4566) SIP (RFC 3261) TCP IP


Fuente: Elaboracin propia, basado en RFCs de la IETF

Audio / Video Aplicacin RTP (RFC 3550) UDP Transporte Red

II.1.a -

Transmisin de Voz sobre una red conmutacin de paquetes

II.1.a.1. Codificacin y Decodificacin de Voz En su sentido fundamental, la voz es una seal analgica; y esto implica la necesidad de alterar su naturaleza para poder transmitirla a travs de una red digital. Llamamos Codificacin de Voz al proceso de convertir la seal analgica en datos digitales transmisibles sobre una red IP. Al proceso inverso consistente en tomar la seal digital y convertirla a una seal analgica audible se le llama Decodificacin de Voz. A los mecanismos de codificacin y decodificacin de seales de voz se los conoce como Codecs1 de Voz. Hay distintas maneras de digitalizar una seal analgica, definidas por varios estndares; la mayora est basada en la Codificacin por Modulacin de Pulsos, o PCM por sus siglas en ingls: Pulse Coded Modulation (Hardy, 2003). Los cdecs de voz, adems de codificar y decodificar la seal de voz, se encargan de comprimir la seal para su transmisin y de volver a descomprimirla en el

Por Codificadores - Decodificadores.

10

destino al recomponer la seal. Algunos cdecs como G.729 y G.723 tratan de reproducir un sonido subjetivo de la seal, en lugar de una representacin exacta de la onda de la seal analgica original. De esta manera se consigue reducir el volumen de datos a transmitirse para una seal de voz. En contra parte, estos esquemas son mucho ms sensibles a fenmenos de una red IP como el jitter y la prdida de paquetes (Hardy, 2003).

II.1.a.2. Protocolos RTP y RTCP Un dato de tiempo real es un dato cuya validez est determinada no solo por el valor propio del dato sino tambin por el tiempo, es decir, tiene restricciones de tiempo. As, el mismo dato, para una fraccin de tiempo puede ser vlido y para otra no. La voz y el vdeo interactivo son informacin de tiempo real. Cuando se codifica una trama de voz para su transmisin interactiva en una comunicacin VoIP, no da lo mismo que uno de los paquetes que encapsula parte codificada de la trama de voz llegue al destinatario con una diferencia de tiempo muy pronunciada respecto al resto de los paquetes, dependiendo del Jitter Buffer el mismo podra ser descartado para la recomposicin de la seal de voz; tampoco sera vlido un retardo general excesivo en el trfico IP, pues provocara una desincronizacin molestosa en la conversacin entre los usuarios (Hardy, 2003). Schulzrinne, et al. (2003) han definido el Protocolo de Transporte de Tiempo Real (en adelante RTP, por sus siglas en ingls: Real-Time Transport Protocol). Su nombre puede prestarse a confusiones, ya que RTP es un protocolo de capa de aplicacin y no de capa de transporte. RTP es un protocolo diseado especialmente para el transporte de datos de tiempo real como el vdeo o audio interactivo. RTP provee servicios de identificacin de la carga til, secuenciamiento, marcas de tiempo y monitorizacin del envo. Normalmente se utiliza RTP sobre UDP para aprovechar su servicio de multiplexacin y checksum, sin embargo, es posible implementar RTP sobre otros protocolos de capa de transporte.

11

RTCP es acrnimo de RTP Control Protocol, o Protocolo de Control de RTP. Fue diseado para monitorizar la calidad del servicio de una sesin RTP. Cuando RTP se implementa sobre UDP, RTCP correr sobre un puerto arriba del de RTP para la misma sesin. Escapa al inters de esta investigacin una descripcin ms profunda del diseo y la arquitectura de este protocolo. Para ms informacin, recomendamos referirse al RFC 3550 de la IETF (Schulzrinne, et al., 2003) que documenta la ltima definicin de RTP.

II.1.b -

Sealizacin de la llamada Las tecnologas para la codificacin, decodificacin y transmisin de voz

sobre una red IP no seran realmente tiles sin tcnicas para establecer, mantener, modificar y terminar la sesin de voz (llamada) entre los extremos. Nos referimos con sealizacin de una llamada al conjunto de mensajes orientados a estas tareas (Zhang, 2003). Actualmente existen dos protocolos principales orientados a la sealizacin VoIP, si bien no son los nicos. El primero en aparecer fue el conjunto de protocolos H.323 estandarizados por la ITU. Hoy da este protocolo es superado en popularidad por el Protocolo de Iniciacin de Sesin (en adelante SIP, por sus siglas en ingls: Session Initiation Protocol): la propuesta de la IETF (Rosenberg, et al., 2002).

II.1.b.1. SIP El Protocolo de Inicio de Sesin, o Session Initiation Protocol (en adelante: SIP) es un protocolo de capa de aplicacin normalizado por la IETF. Es utilizado como protocolo de sealizacin para el establecimiento, mantenimiento y terminacin de sesiones interactivas entre usuarios; estas sesiones pueden tratarse de conferencias multimedia, chats, sesiones de voz o distribucin de contenidos multimedia. 12

La ltima definicin de SIP est contenida en el RFC 3261 de la IETF (Rosenberg, et al., 2002). SIP es un protocolo fcilmente escalable, esto ha permitido que se le haya podido aadir diversas extensiones definidas en otros documentos RFC. SIP no define por s mismo un sistema de comunicaciones ni ofrece servicio alguno; es un protocolo flexible que se limita a ofrecer una serie de primitivas que las aplicaciones pueden utilizar para implementar servicios. El objetivo fue aportar un conjunto de funciones de procesamiento de llamadas y capacidades presentes en la Red Pblica Conmutada de Telefona (en adelante PSTN, por sus siglas en ingls: Public Switched Telephony Network). As, implement funciones tpicas que permite un telfono comn, como son llamar a un nmero, provocar que un telfono suene al ser llamado y escuchar la seal de tono o de ocupado. Aunque existen muchos otros protocolos de sealizacin para VoIP, SIP se caracteriza porque sus promotores tienen sus races en la comunidad IP2 y no en la industria de las telecomunicaciones. De hecho, SIP no fue concebido originalmente como un protocolo para la sealizacin de llamadas telefnicas, sino de cualquier sesin interactiva.

II.1.b.1.1.

Entidades SIP El RFC 3261 (Rosenberg, et al., 2002) define dos entidades principales:

los Agentes de Usuario (en adelante UA, por sus siglas en ingls: User Agent) y los Servidores SIP. A. Agente de Usuario (UA): se denomina a cada extremo de la sesin (Rosenberg, et al., 2002 p. 26);

SIP es la propuesta de la IETF para la sealizacin de sesiones VoIP (y otras).

13

a. UA Cliente (en adelante UAC): es la entidad lgica derivada del UA que genera peticiones SIP y recibe las respuestas a esas peticiones; b. UA Servidor (en adelante UAS): es la entidad lgica derivada del UA que recibe peticiones SIP y genera respuestas a tales peticiones; B. Servidores SIP: a. Servidor Proxy (Proxy Server): retransmite solicitudes y decide a qu otro servidor debe remitirlas, alterando los campos de la solicitud en caso de ser necesario. Es una entidad intermedia que acta como cliente y servidor con el propsito de establecer sesiones entre los usuarios (Rosenberg, et al., 2002 p. 23); b. Servidor de Registro (Registrar Server): es un servidor que acepta peticiones de registros de los usuarios y guarda la informacin de estas peticiones para suministrar un servicio de localizacin y traduccin de direcciones en el dominio que controla (Rosenberg, et al., 2002 p. 24); c. Servidor de Redireccin (Redirect Server): es un servidor que genera respuestas de redireccin a las peticiones que recibe, y reencamina estas peticiones hacia el prximo servidor

(Rosenberg, et al., 2002 p. 23).

II.1.b.1.2.

Mtodos SIP Los mtodos SIP son las funciones que un mensaje de solicitud invoca en

un UAS o Servidor SIP. Los mtodos que define el RFC 3261 (Rosenberg, et al., 2002) son los siguientes:

REGISTER:

Utilizado por el UA para registrarse a un dominio SIP. Informa la direccin de contacto del UA.

14

INVITE: ACK: BYE: CANCEL:

Utilizado para solicitar a un UAS el establecimiento de una sesin. Confirma la recepcin de un mensaje. Solicita la finalizacin de la sesin correspondiente. Cancela una solicitud pendiente de respuesta.

Otros documentos establecen otros mtodos como extensiones del protocolo.

II.1.b.1.3.

Identificacin de Usuarios: URI SIP De forma anloga a una direccin IP en una red IP, o a un nmero

telefnico en una PSTN, SIP identifica a cada usuario o recurso de comunicacin en una red SIP mediante un Indicador de Recursos Uniforme, o Uniform Resource Indicator (en adelante URI) (Rosenberg, et al., 2002 p. 148). Su construccin es similar a la de una direccin URL de correo electrnico, conteniendo un nombre de usuario y un dominio. De forma genrica su formato es el siguiente: sip:USUARIO[:CONTRASEA]@HOST[:PUERTO][;PARAMETROS][?ENCABEZ ADOS] Donde: USUARIO: es el identificador del recurso en particular alojado en HOST. CONTRASEA: Contrasea asociada a USUARIO. HOST: El host que provee el recurso SIP o nombre de dominio del recurso. En caso de indicarse un nombre de dominio, y no un host, el UAC deber resolver por DNS SRV la direccin de transporte del servidor SIP de ese dominio, consultando los SRV _sip._udp, _sip._tcp, etc. PUERTO: El puerto de transporte donde ser enviado el pedido.

15

PARAMETROS: Parmetros que afectan al pedido, construdos de desde el URI. ENCABEZADOS: Encabezados a ser incluidos en el pedido, construidos desde el URI. Algunos ejemplos de URIs SIP: sip:victor@ucsa.edu.py sip:juan@sip1.ucsa.edu.py sip:1234@ucsa.edu.py sip:1234@192.168.0.1 sip:victor@192.168.0.1:5060 sip:juan:contrasena@ucsa.edu.py:5060

II.1.b.1.4.

Transporte La norma establece los puertos 5060 TCP y UDP para el trfico SIP, sin

embargo es posible intercambiar trfico SIP utilizando otros puertos dependiendo de la configuracin de los dispositivos. SIP/UDP ha logrado mayor aceptacin hoy da.

II.1.b.1.5.

Mensajes SIP es un protocolo basado en texto plano y utiliza el juego de caracteres

UTF-8. Los mensajes SIP estn compuestos por tres secciones: la lnea inicial (RequestLine en el caso de mensajes de peticiones o Status-Line en el caso de mensajes de respuesta), encabezados y cuerpo del mensaje; opcional este ltimo (Rosenberg, et al., 2002 p. 26). Existen dos tipos de mensajes SIP: los mensajes de solicitud, que representan mtodos SIP; y los mensajes de respuesta, que indican estados SIP.

16

Figura 2 Sintaxis de Mensajes SIP (BNF)


mensaje-sip-generico := lina-inicial *encabezado CRLF ( cuerpo | ) Request-Line | Status-Line

linea-inicial

:=

Fuente: Elaboracin propia, basado en RFC 3261 (Rosenberg, et al., 2002)

II.1.b.1.5.1

Encabezados de los Mensajes Los encabezados del mensaje contienen informacin relacionada con la

solicitud que se enva. En caso de existir informacin contenida en el cuerpo del mensaje SIP, se indicar en la seccin de encabezados el tipo de informacin contenida y su longitud. Cada encabezado termina con un salto de lnea y el final de la seccin de encabezados se determina por una lnea vaca.
Figura 3 - Sintaxis (BNF) de encabezado SIP
encabezado := nombre-campo DOSPUNTOS valor *(COMA valor) CRLF

Fuente: Elaboracin propia, basado en RFC 3261 (Rosenberg, et al., 2002)

Existen encabezados opcionales y mandatorios. Los mandatorios son los siguientes: To: Indica el destinatario (lgico) de la solicitud; From: Indica el remitente (lgico) de la solicitud; Call-ID: Identificador nico que agrupa una serie de mensajes en un dilogo; Cseq: Implementado para identificar un orden en las transacciones. Est compuesto por un nmero entero secuencial y el nombre del mtodo al que corresponde la transaccin;

17

Via: Indica la direccin de transporte utilizada para la transaccin y establece dnde debern ser remitidas la respuesta del mensaje; Max-Forwards: Cantidad mxima de saltos que el mensaje puede dar en su recorrido hacia su destino; Contact: Provee el URI SIP que identifica la instancia que gener el mensaje de pedido, de manera que las solicitudes subsiguientes para esa instancia sean remitidas al URI SIP indicado.

II.1.b.1.5.2

Mensajes de Solicitud Los mensajes de solicitud se reconocen por contener un Request-Line (o

Lnea de Solicitud) en la lnea inicial del mensaje. El Request-Line contiene el nombre del mtodo, el URI del usuario destinatario de la solicitud, denominado Request URI (o simplemente RURI), y la versin del protocolo, todos separados por un espacio en blanco simple.
Figura 4 - Sintaxis (BNF) del Request-Line
Request-Line := Metodo SP Request-URI SP Version-SIP CRLF

Fuente: Elaboracin propia, basado en RFC 3261 (Rosenberg, et al., 2002)

Figura 5 - Mensaje SIP Invite


INVITE sip:222@ucsa.edu.py SIP/2.0 To: <sip:222@ucsa.edu.py> From: Victor Cartes <sip:111@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:111@192.168.10.23:6235> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 192.168.0.23 t=0 0 m=audio 9620 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Fuente: Elaboracin propia, en base a observaciones de pruebas de laboratorio

18

II.1.b.1.5.3

Mensajes de Respuesta Los mensajes de respuesta llevan un Status-Line (o Lnea de Estado) en

la lnea inicial del mensaje. Un Status-Line est compuesto por la versin del protocolo seguida por un cdigo de estado y una frase asociada; todos separados por un espacio en blanco simple.
Figura 6 - Sintaxis de Status-Line (BNF)
Status-Line := Version-SIP SP Codigo-Estado SP Descripcion-Estado CRLF

Fuente: Elaboracin propia, basado en RFC 3261 (Rosenberg, et al., 2002)

El RFC 3261 (Rosenberg, et al., 2002) define seis tipos de respuestas:

Cdigos 100 ~ 199:

Respuestas de aprovisionamiento. Pueden llegar antes de cualquier respuesta final. Brindan informacin respecto a la transicin de estados o eventos antes de la respuesta final.

Cdigos 200 ~ 299:

Respuestas finales de aprobacin. Indican la probacin de una solicitud.

Cdigos 300 ~ 399:

Respuestas de redireccin. Dan informacin sobre cambios en la ubicacin del usuario.

Cdigos 400 ~ 499:

Errores en la solicitud del UAC. El UAC no debera re-generar el pedido sin efectuar alguna alteracin en el mismo.

Cdigos 500 ~ 599:

Errores en el Servidor. Indican alguna falla en el servidor mientras procesaba el pedido.

Cdigos 600 ~ 699:

Errores globales. Indican que la solicitud no puede ser atendida por ningn servidor.

19

II.1.b.2. SDP SIP como tal no cuenta con encabezados para la negociacin del intercambio de flujos de medios (trfico RTP)3. La negociacin entre los UAs para la configuracin de los parmetros a utilizar para el intercambio de los flujos de medios se realiza utilizando el Protocolo de Descripcin de Sesin, o Session Desciption Protocol (en adelante SDP). La ltima definicin del SDP corresponde al RFC 4566 (Handley, et al., 2006). El contenido SDP viaja en el cuerpo de los mensajes SIP INVITE y SIP 200 OK. Adems puede encontrarse informacin SDP en el cuerpo de mensajes SIP de respuesta provisionales 180 (Ringing)4 cuando se desea reproducir en el UAC el tono de ringback generado en el UAS, y 183 (Session Progress) cuando el UAS desea reproducir audio no tarifado antes del establecimiento de la llamada, como por ejemplo, los anuncios antes de derivar la llamada al correo de voz (voicemail) del usuario. La Figura 11 muestra un mensaje SIP INVITE con contenido SDP. SDP es un protocolo empleado para describir una sesin multimedia, que consiste en un conjunto de flujos de medios (audio, vdeo o datos) que existen durante un determinado tiempo. La propuesta original de SDP fue diseada para anunciar informacin necesaria para los participantes y para aplicaciones multicast. Actualmente su uso est extendido para el anuncio y la negociacin de las capacidades de una sesin multimedia en Internet (Handley, et al., 2006).

Para el intercambio de mensajes RTP y RTCP (transporte de flujo de medios) se utilizan direcciones de transporte distintas a las utilizadas para el intercambio de mensajes SIP (sealizacin).
4

Usualmente, a efectos de economizar el consumo de ancho de banda, el ringback realmente no se reproduce desde el UAS, ste simplemente enva un mensaje SIP 180 ordenando al UAC la reproduccin del ringback.

20

Puesto que SDP es un protocolo de descripcin, los mensajes SDP se pueden transportar mediante distintos protocolos con SIP, SAP, RTSP, correo electrnico con aplicaciones MIME o protocolos como HTTP. Como el SIP, el SDP utiliza la codificacin de texto, un mensaje del SDP se compone de una serie de lneas, denominados campos, donde los nombres son abreviados por una sola letra.

II.1.b.2.1.

Formatos de mensajes SDP Cada lnea sigue la sintaxis atributo=valor y cada valor puede tener uno

o ms parmetros separados por un espacio simple, acorde a la Figura 7.


Figura 7 - Sintaxis de Lineas SDP (BNF)
linea valor := := nombre-campo IGUAL valor CRLF valor SP parametro |

Fuente: Elaboracin propia, basado en RFC 4566 (Handley, et al., 2006)

II.1.b.2.2.

Campos de SDP Un mensaje SDP contiene tres niveles de informacin: Descripcin a nivel de sesin; Descripcin de tiempos; Descripcin de tipo y formato de medio;

Tabla 1 - Campos SDP de Nivel de Sesin

Campo V O S I U E P

Descripcin Versin del Protocolo ID de Sesin y Origen Nombre de la Sesin Informacin de Sesin URI de la Sesin Direccin de Correo Electrnico Nmero de Telfono

Mandatorio Mandatorio Mandatorio Opcional Opcional Opcional Opcional

21

C B Z K A

Informacin de la Conexin Informacin del Ancho de Banda Correccin de Zona Horaria Clave de Encripcin Lneas de Atributo

Mandatorio Mandatorio Opcional Opcional Opcional

Fuente: RFC 4566 (Handley, et al., 2006)

Tabla 2 - Campos SDP de Nivel de Tiempo

Campo t R

Descripcin Tiempo de la sesin activa Repeticiones

Mandatorio Opcional

Fuente: RFC 4566 (Handley, et al., 2006)

Tabla 3 - Campos SDP de Nivel de Medios

Campo m I C B K A

Descripcin Medios y Puerto de Transporte Ttulo del Medio Informacin de Conexin Informacin de Ancho de Banda Clave de Encripcin Atributos de Medios

Mandatorio Opcional Opcional Opcional Opcional Opcional

Fuente: RFC 4566 (Handley, et al., 2006)

Debido a su relevancia al tema de esta tesis y a la solucin que propondremos ms adelante, prestaremos particular atencin a dos de los campos de SDP de Nivel de Medios, ms especficamente los campos Informacin de Conexin (c) y Medios y Puerto de Transporte (m). II.1.b.2.2.1 Campo Informacin de Conexin (c) El campo Informacin de Conexin (c) indica la direccin de red donde deber ser remitido el trfico de mensajes de transporte del flujo de medios.

22

Figura 8: Sintaxis del Campo SDP "c" (Basado en RFC 4566)


c = <TIPO DE RED> <TIPO DE DIRECCION> <DIRECCION DE CONEXION>

Fuente: RFC 4566 (Handley, et al., 2006)

Los parmetros del campo c son:

1. TIPO DE RED:

Cadena de texto indicando el tipo de red. Actualmente solo se define el tipo IN, que se refiere a Internet. Ms adelante podran definirse nuevos tipos.

2. TIPO DE DIRECCION:

Este campo permite la implementacin de SDP para sesiones no basadas en IP, aunque actualmente solo se definen los tipos IP4 e IP6.

3. DIRECCION DE CONEXION:

La propia direccin de red a ser utilizada para el intercambio del flujo de medios.

II.1.b.2.2.2

Campo Informacin de Medios y Puerto de Transporte (m) Mediante el campo Informacin de Medios y Puerto de Transporte (m),

se comunica al otro extremo de la comunicacin que tipo de medio (Ej.: Audio, Vdeo, etc.) debe enviar; a qu puerto de transporte; y cmo deber ser codificada la seal.
Figura 9 - Sintaxis del Campo SDP "m"
m = <TIPO DE MEDIO> <PUERTO> <PROTOCOLO> <LISTA FMT>

Fuente: RFC 4566 (Handley, et al., 2006)

Los parmetros del campo m son:

1. TIPO DE MEDIO:

Los tipos actualmente definidos son: audio, video, text, application y message.

23

2. PUERTO:

El puerto de transporte donde deber ser remitido el flujo de medios.

3. PROTOCOLO:

El protocolo de transporte a utilizar. No se refiere al protocolo de capa de transporte, sino al protocolo a utilizar para el transporte del flujo de medios. Los protocolos definidos hasta ahora son: udp: Se refiere a algn protocolo no especificado implementado sobre UDP; RTP/AVP: RTP, para conferencias de audio y/o video con un control mnimo e implementado sobre UDP; RTP/SAVP: RTP Seguro, implementado sobre UDP.

4. LISTA FMT:

Descripcin del formato del medio. Contiene sub-campos relacionados al protocolo de transporte del flujo de medios indicado.

II.1.b.2.3.

Modelo de Oferta/Respuesta con SDP El modelo Oferta/Respuesta de SDP es utilizado por dos entidades para

negociar parmetros de la configuracin de una sesin, tales como qu flujos de medios son parte de la sesin, qu codecs se utilizarn, etc. Este modelo de Oferta/Respuesta se utiliza no solo para crear sesiones, sino tambin para modificar sesiones existentes (Handley, et al., 2006). La entidad que desea iniciar la sesin genera un mensaje SDP que constituye la Oferta. Esta Oferta contiene el conjunto de flujos de medios que desea establecer (Ej. Un flujo para audio y otro para vdeo), la lista de cdecs que puede utilizar ordenados por preferencia, las direcciones de transporte que desea utilizar para recibir los flujos de medios, etc. En una sesin VoIP SIP, esta Oferta SDP viaja en el cuerpo del mensaje SIP INVITE. Al recibir la Oferta SDP, el otro extremo de la sesin genera una Respuesta SDP indicando cules flujos de medios son aceptados, qu cdecs sern 24

utilizados (seleccionados de la lista ofrecida por el UAC) y las direcciones de transporte donde desea recibir los flujos de medios. En una sesin VoIP SIP, esta Respuesta SDP viaja contenida en el cuerpo de mensajes SIP de respuesta como el 200 (OK), el 180 (Ringing) cuando el UAS desea reproducir y transmitir en banda el tono de ringback y el 180 (Session Progress) cuando el UAS desea reproducir mensajes no tarifados como los anuncios previos al correo de voz (voicemail).

II.1.b.3. Secuencia de Sealizacin SIP/SDP de una Llamada Habiendo presentado las bases de los protocolos SIP y SDP, ya estamos en condiciones de analizar la secuencia de mensajera SIP/SDP para el establecimiento, mantenimiento y terminacin de una llamada VoIP. A continuacin, presentaremos un caso simple de sealizacin SIP para una llamada VoIP en la que involucraremos a dos usuarios: Vctor y Juan, donde Vctor llama a Juan; y ambos estn registrados al mismo dominio SIP.

25

Figura 10 - Secuencia de Sealizacin SIP

Victor

SIP Proxy

Juan

INVITE / SDP 100 Trying

1 2

INVITE / SDP 100 Trying

3 4

180 Ringing 180 Ringing

200 OK / SDP 200 OK / SDP

ACK

ACK

Flujo RTP

BYE

BYE

200 OK 200 OK

10

Fuente: Elaboracin propia, basado en RFC 3261 (Rosenberg, et al., 2002)

La figura anterior nos muestra el ejemplo simple de sealizacin de una llamada VoIP que analizaremos en detalle.

El usuario Vctor llama al usuario Juan. El UAC de Vctor genera un mensaje de pedido con el mtodo INVITE para el URI de Juan y lo enva a su

26

servidor SIP. Al comenzar la sesin, la nica informacin que Vctor conoce respecto al UA de Juan es su URI, no conoce su ubicacin (direccin de transporte del UA de Juan) ni sabe siquiera si se encuentra conectado. El Servidor SIP se encargar de encaminar el mensaje hacia el UA de Juan si reconoce al usuario y algn UA de Juan se encuentra registrado, o responder con un mensaje de error indicando que no se encuentra el usuario.
Figura 11 - Mensaje SIP INVITE
INVITE sip:juan@ucsa.edu.py SIP/2.0 To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:victor@192.168.10.23:6235> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 192.168.0.23 t=0 0 m=audio 9620 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Fuente: Elaboracin propia

El cuerpo del mensaje SIP INVITE contiene informacin SDP. De esta manera, el UA de Vctor le indica al destinatario de la llamada los parmetros que desea utilizar para el intercambio del flujo RTP.

El Proxy SIP responde inicialmente a Vctor con un mensaje de respuesta con cdigo de estado 100 (Trying), indicndole de esta manera al UAC de Vctor que la solicitud ha sido recibida y est siendo procesada, para evitar que el UAC retransmita su solicitud en caso de demorarse una respuesta final.

27

Si el UA de Juan se encuentra registrado, el Servidor SIP conocer la direccin de contacto de Juan y la direccin de transporte desde donde est conectado. En base a esta informacin, retransmitir el mensaje SIP INVITE recibido a Juan.

Al recibir el mensaje SIP INVITE, el UAS podr responder con un mensaje de respuesta provisional con cdigo de estado 100 (Trying), para indicarle al remitente del mensaje que la solicitud ha sido recibida y est siendo procesada, igual que en el paso 2.

El UA de Juan da alerta al usuario Juan de la llamada de Vctor (ring) y enva a Vctor un mensaje de respuesta provisional con cdigo 180 (Ringing) indicndole as que la llamada est siendo alertada. Cuando el UA de Vctor reciba este mensaje reproducir un tono de ringback, indicndole a Vctor que la llamada est siendo alertada (sonando) en el otro extremo.

Cuando Juan conteste la llamada, su UA enviar a Vctor un mensaje de respuesta final de aprobacin con el cdigo de estado 200 (OK). En el cuerpo de este mensaje, estar contenida informacin SDP, que le indicar al UA de Vctor los parmetros que el UA de Juan desea utilizar para el intercambio de mensajes RTP.

28

En caso que algn parmetro SDP solicitado por el UAC no sea aprobado por el UAS5, se responder con un mensaje de respuesta con un cdigo de estado de error de cliente (4xx).

Cuando el UAC haya recibido la aprobacin (200 OK) de su solicitud (INVITE), generar un mensaje SIP ACK, confirmando la recepcin del mensaje.

En este momento, tanto el UA de Vctor como el UA de Juan cuentan con la informacin suficiente de cada extremo para realizar el intercambio flujos de medios y comienzan a transmitir sus mensajes RTP hacia el otro extremo de la comunicacin, estableciendo as la llamada.

Cuando Vctor corte el telfono, su UAC generar un mensaje de solicitud con el mtodo BYE; indicndole as al UAS de Juan que la sesin debe terminar.

10

Al recibir esta solicitud, el UAS de Juan la aprueba respondiendo con un mensaje SIP 200 (OK), y da por terminada la transmisin de mensajes RTP y la sesin misma.

II.1.c -

Modelos de Servicio de Telefona IP El fuerte crecimiento de las redes IP por un lado y el avance en el

desarrollo de tcnicas de digitalizacin de voz, control y priorizacin de trafico han provocado en los ltimos tiempos una aceleracin en la adopcin de la telefona IP por empresas, instituciones y usuarios domsticos (Sinnreich, et al., 2001).

Ej.: Ningn cdec de la lista ofrecida mediante SDP por el UAC es soportada por el UAS.

29

Antes que nada, debemos recordar que VoIP no es un servicio, sino una tecnologa; o mejor dicho: un conjunto de estndares tecnolgicos orientados a la transmisin de voz sobre una red IP. Desde su concepcin y a medida que estas tecnologas fueron evolucionando se ha desarrollado distintos modelos de negocio tanto de manufactura como de servicios para la explotacin de VoIP que dieron lugar a un extenso abanico de posibilidades comerciales en la industria de las telecomunicaciones. Hemos elaborado una clasificacin de los modelos de servicios de telefona actuales basados en VoIP.
Figura 12 - Modelos de Servicios de Telefona IP

Modelos de Servicios de Telefona IP Intercambio Interactivo de Datos Multimedia

Uso Corporativo / Centrex

Telcos

Sobre Red IP Controlada

Lineas Troncales (Carrier)

Servicio Directo al Abonado

Sobre Red IP No Controlada

Sobre Red IP Controlada

Sobre Red IP No Controlada

Fuente: Elaboracin propia

II.1.c.1.

Centrex Centrex es un modelo de servicio de comunicacin de voz para redes

privadas corporativas, implementada mediante una PBX (Centralita Telefnica). Estas redes pueden a su vez estar conectadas a la PSTN (Sinnreich, et al., 2001). 30

Recientemente, se han desarrollado e implementado soluciones Centrex sobre redes IP empleando VoIP y mediante Centralitas Telefnicas IP (IP PBX). Este tipo de soluciones son convenientes para empresas con varias sucursales, ya que les permite emplear la red de datos TCP/IP que eventualmente interconecta a las sucursales para el transporte de las llamadas entre ellas, evitando as tarifacin de la PSTN. Adems, se ha implementado para Call Centers, donde los operadores no se encuentran en el mismo lugar geogrfico donde la compaa telefnica sirve la lnea. Este modelo de servicio es comnmente utilizado por grandes cadenas de hoteles, lneas areas y otros rubros similares; que ofrecen un nmero local en los pases de presencia a sus clientes para asistencia y otros servicios en varios idiomas, distribuyendo los operadores del call center en distintos pases (o estados) generalmente los sitios de presencia -, y brindando asistencia en distintos idiomas; lo cul sera mucho ms costoso si se tuviera que equipar un call center fsico por sitio de presencia, con gente que hablara los distintos idiomas que pudieran requerirse. Por otra parte, el bajo costo de los recursos humanos en algunos pases, ha llevado a algunas compaas a montar call centers remotos en esos pases, en un concepto similar al de la maquila. La interconexin TCP/IP de la red Centrex puede realizarse mediante una red IP privada, una red IP privada virtual (VPN) sobre internet, o directamente sobre internet. Los servicios tpicos de Centrex son: Plan privado de numeracin; Tarifa gratuita para las comunicaciones corporativas; Desvos; Transferencias; Capturas de llamadas; Etc.

31

II.1.c.2.

Softwares de Intercambio Interactivo de Flujos Multimedia En la actualidad, VoIP tambin es implementado para ofrecer servicios

de valor agregado de varios productos de mensajera instantnea, permitiendo la transmisin no solo de textos y archivos, sino tambin intercambio interactivo de voz y vdeo de extremo a extremo entre usuarios del mismo servicio de mensajera instantnea (Hardy, 2003). Algunos de estos productos, como el caso de Skype, han incorporado conexiones a PSTNs, posibilitando el establecimiento de llamadas de voz no solo a otros usuarios del producto de mensajera, sino tambin a nmeros de lnea fija y celulares. Entre estos productos de mensajera instantnea podemos citar los siguientes: Skype, Google Talk, MSN Messenger, Yahoo! Messenger, Gizmo Project, Ekiga.

II.1.c.3.

Comunicaciones Conmutadas y de Extremo a Extremo Cuando Graham Bell efectu la primera llamada telefnica de la historia,

solo haba una lnea y dos extremos, un claro ejemplo de una conexin de Extremo a Extremo, o Peer to Peer. Sin embargo, si el escenario est compuesto por ms abonados, el costo de implementacin de una red fsica de todos contra todos la hara inviable. Como respuesta a este problema surge el esquema de conmutacin o switching, donde una tercera entidad se encarga de funciones tales como:

32

Registro de abonados; Encaminamiento; Sealizacin; Manejo de las sesiones; AAA.

II.1.c.4.

Categorizacin Jerrquica de Conmutadores La conocida compaa telefnica norteamericana AT&T estableci una

clasificacin jerrquica de sus switches de cara a la definicin de sus planes de numeracin, esta clasificacin tiene su par definido por la entonces CCITT, hoy conocida como la ITU-T (International Engineering Consortium, 2007).
Tabla 4 - Categorizacin de Conmutadores

ATT Clase 1 - Centro Regional Clase 2 - Centro Seccional Clase 3 - Centro Primario Clase 4 - Punto de Facturacin Clase 5 - Oficina Terminal
Fuente: International Engineering Consortium, 2007

CCITT Centro Cuaternario Centro Terciario Centro Secundario Centro Primario Oficina Local

II.1.c.5.

Operadoras de Lneas Troncales (Clases 1~4) Estas operadoras conmutan llamadas entre conmutadores o entre

operadoras, no ofrecen servicios a los usuarios finales directamente. Varias de estas operadoras han optado por implementar VoIP principalmente porque los costos de implementacin, administracin y mantenimiento de una red de conmutacin de paquetes son por mucho inferiores a los de una red de conmutacin de circuitos (Hardy, 2003).

33

Por ejemplo, si hacemos una llamada desde la red telefnica conmutada pblica (PSTN) de COPACO en Asuncin a un nmero de Telefnica en Espaa, la interconexin entre estas operadoras puede establecerse sobre IP, empleando VoIP. Otro modelo de negocio clsico para estas operadoras es el de las populares Calling Cards, o Tarjetas de Llamadas, generalmente utilizadas para llamadas de larga distancia. La siguiente figura presenta un esquema bsico de la red de la Operadora de Telefona IP de Lneas Troncales para la provisin de los servicios recin comentados. El diseo de la red puede discrepar del modelo que describimos aqu, aunque por lo general las diferencias no son grandes.
Figura 13 - Red de una Operadora VoIP de Lneas Troncales

Servidor SIP (Softswitch)

Red IP

PSTN A

Media Gateway / Signalling Gateway

Media Gateway / Signalling Gateway

PSTN B

Abonado A

Abonado B

Fuente: Elaboracin propia

II.1.c.6.

Operadora de Servicios Directos al Abonado (Clase 5) Una Operadora de Telefona Clase 5 ofrece servicios directo al abonado,

y conmuta el trfico entre la lnea de abonado, que conecta al abonado con la operadora, 34

y las lneas troncales que interconecta a la operadora con otras operadoras, o conmutadores de la misma operadora (Hardy, 2003). Para una operadora de Telefona IP Clase 5 debemos asumir que la conexin con el abonado se realiza mediante una red IP. La operadora telefnica puede tener control sobre esta lnea de abonado, cuando el abonado se conecta directamente a su red, o a una red de su jurisdiccin. Sin embargo, la operadora podra tambin no tener control sobre la conexin con el abonado, por ejemplo, cuando ste se conecta a travs de Internet. Tal es el caso de modelos de negocios como el que implementaron compaas como Vonage. Nos interesa particularmente este ltimo modelo de interconexin con el abonado, puesto que es bajo este esquema, en el que el que los escenarios de conexin de los abonados son muy heterogneos, donde surge la necesidad de garantizar todos los servicios a ste, an cuando se conecte desde tras un NAT. El siguiente esquema presenta un modelo general de red de una Operadora VoIP Clase 5. En l se observa una red IP como red troncal de la operadora. Los abonados se conectan a travs de redes IP. Un Media Gateway / Signalling Gateway (Pasarela de medios y de sealizacin) acta de interfaz entre la Red Conmutada Pblica de Telefona (PSTN) para permitir el establecimiento de sesiones (llamadas) entre abonados conectados directamente al dominio de la PSTN y abonados conectados al dominio IP. Un Softswitch se encarga de conmutar todo el trfico de llamadas dentro del dominio IP de la red de la operadora.

35

Figura 14 - Red de una Operadora VoIP Clase 5

Internet

Softswitch

Router IP

Red IP de la Operadora

PSTN

Media Gateway / Signalling Gateway Abonado A

Abonado B Abonado C

Abonado D

Fuente: Elaboracin propia

II.1.d -

Implicancias de Calidad Las expectativas de calidad de cualquier usuario de telefona IP, se miden

principalmente por las diferencias de calidad percibidas respecto a la telefona convencional, sobre redes de conmutacin de circuitos; sin embargo, una red de conmutacin de paquetes es menos propicia, en trminos de calidad, que una red de conmutacin de circuitos para la transmisin de voz; y lograr que VoIP se ajuste a los estndares de calidad de la telefona convencional es difcil (Hardy, 2003). Existen problemas de calidad, como la atenuacin de la potencia de la comunicacin o el ruido en lnea, que por la naturaleza de sus causas no se reproducen sobre sistemas de transmisin digital; sin embargo, en una red de conmutacin de paquetes existen nuevos fenmenos perjudiciales para la transmisin de voz y de cualquier trfico de tiempo real. Como ya hemos discutido anteriormente, el trfico de datos de tiempo real, a diferencia del trfico de datos normales, cuenta con restricciones de tiempo que

36

determinan la validez de los mismos; en pocas palabras, no da lo mismo recibir un dato en un momento que en otro. En una red IP, la transmisin de datos se realiza por paquetes. Una misma trama de voz puede viajar en varios paquetes, y a su vez cada paquete puede tomar un camino independiente desde el origen hasta el destino, y pudiendo llegar algunos en menor tiempo que otros dependiendo de las condiciones de las redes por las que cada paquete tuvo que atravesar. Esta es la causa principal por lo que la transmisin de la voz es muy sensible sobre una red IP. Seguidamente se describen algunos de los fenmenos que afectan la calidad en una comunicacin VoIP.

II.1.d.1. Retardo Segn Hardy (2003), los principales orgenes del retardo en una transmisin VoIP se encuentran en: La Codificacin y la Decodificacin: es decir, el tiempo que necesitan los cdecs para procesar una trama de voz; El ensamblado de los paquetes: el tiempo necesario para llenar un paquete antes de su transmisin; La serializacin: el tiempo que toma introducir un paquete a la lnea de transmisin; El encolamiento: el tiempo que el paquete debe esperar en cola cuando la interfaz de transmisin de un nodo de la red est ocupada; La amortizacin del Jitter o Dejittering: el tiempo que el receptor almacena los paquetes entrantes en un buffer a la espera de paquetes a destiempo antes de comenzar a recomponer la trama de voz.

37

II.1.d.2. Jitter El Jitter es la varianza de retardo entre los paquetes de una transmisin. En una red TCP/IP el curso de cada paquete de una transmisin es independiente del curso de los otros paquetes, es decir, en la misma transmisin cada paquete puede tomar un camino distinto para alcanzar al mismo nodo destino; y cada camino distinto puede presentar condiciones distintas producindose retardos distintos para los paquetes. Como resultado, el host destino puede recibir algunos paquetes a destiempo (Hardy, 2003). Para una transmisin de datos normales, como un e-mail por SMTP o trfico HTTP contra un sitio web, el Jitter no es tan daino, ya que puede aguardarse la llegada de todos los mensajes antes de recomponer el mensaje, haciendo uso o no de retransmisiones. Con el trfico de voz interactivo de una llamada VoIP es distinto, ya que es informacin de tiempo real, con restricciones de tiempo; el trfico de mensajes RTP debe mantenerse como un flujo continuo. En el receptor normalmente se implementa un buffer para el trfico entrante, en funcin de amortizar el Jitter; este buffer es conocido como Jitter Buffer (Hardy, 2003). En el Jitter Buffer se van almacenando los paquetes que arriban durante un tiempo determinado, tras el cual se utilizar los paquetes del buffer para recomponer la trama de voz transmitida, descartando los paquetes que llegan a destiempo. El cdec se ocupa luego de llenar los espacios vacos dejados por paquetes que faltan, de la forma que lo establezca del algoritmo empleado.

II.1.d.3. Algunos efectos perceptibles por el usuario

II.1.d.3.1.

Ruido durante el dilogo En ocasiones, durante una llamada VoIP puede percibirse un ruido de

fondo cuando nuestro interlocutor est hablando, y tal vez dicho ruido desaparezca cuando nuestro interlocutor deja de hablar. Este fenmeno no es totalmente propio de VoIP, y es el clsico ruido en lnea que tiene lugar en llamadas sobre una red telefnica 38

convencional. En llamadas VoIP puede suceder cuando existe un tramo de red analgica entre ambas partes de la llamada; es decir, cuando la comunicacin no se realiza enteramente sobre una red IP. El hecho que el ruido se detenga cuando nuestro interlocutor deja de hablar, se debe a la supresin de silencio, comnmente implementada al codificar la seal de voz para ahorrar ancho de banda, transmitiendo solo cuando el usuario habla: ms tcnicamente, cuando la seal analgica recibida alcanza un nivel mnimo de potencia (Hardy, 2003 p. 28).

II.1.d.3.2.

Eco Para Hardy (2003 p. 29), en comunicaciones VoIP el eco es un efecto del

retardo elevado cuando el extremo opuesto de la llamada se encuentra conectado a una PSTN a la cual se conecta la red IP mediante un Media Gateway. En una red telefnica de conmutacin de circuitos, el eco es generado por el lado terminador de la conexin debido a la reflexin de la energa de la seal de voz. Este eco es perceptible por el Media Gateway, codificado como una seal de voz y transmitido de vuelta al extremo IP. Si el retardo total excede los 50 ms, el eco ser perceptible por el extremo IP.

II.1.d.3.3.

Distorsin de la voz Segn Hardy (2003, p. 30), La distorsin de la voz es la deformacin de

las ondas naturales de la voz, produciendo sonidos que no podran ser articulados por el ser humano. Este tipo de problemas surgen principalmente de los procesos de codificacin y

decodificacin de la voz. Estos efectos pueden darse con cdecs basados en PCM, cuando la amplitud de las ondas del sonido de ambiente es muy elevada, cercana a la amplitud de la onda de la seal de voz. En este caso, el producto de la codificacin puede combinar ambos sonidos. Tambin es comn cuando la tasa de paquetes descartados excede el mnimo recomendado por el cdec utilizado, habindose recolectado en el buffer de entrada muy pocos paquetes para recomponer la trama de voz, dejando demasiados 39

huecos que llenar en la seal codificada recibida. En este caso, dependiendo del cdec, se llenarn los espacios empleando algn mtodo interpolando paquetes adyacentes o proyectando posibles valores, generando una seal posiblemente muy distinta a la emitida.

II.1.d.3.4.

Prdida del ritmo de la conversacin El retardo en una comunicacin telefnica, empleando cualquier

tecnologa, genera una prdida en el ritmo de la conversacin, empobreciendo la experiencia del usuario e incluso hacindola molestosa y estresante.

II.2 - Traduccin de Direcciones de Red (NAT)

II.2.a -

mbitos de Direcciones de Red En adelante, utilizaremos por convencin el trmino mbito de

Direcciones de Red para referirnos al dominio o las redes en las que existen rutas hacia una direccin IP determinada. Internet es el mbito de Direcciones de Red Pblicas, en donde hay rutas que interconectan a todos los nodos de red entre s dentro de ese mbito pblico de direcciones. Nos referiremos a este mbito Pblico como Red Pblica y a las direcciones de red de este mbito Pblico como Direcciones Pblicas de Red, o bien Direcciones IP Pblicas6.

Tambin se las conoce como Direcciones IP Vlidas

40

Pero recordemos que el mbito Pblico de Direcciones de Internet no es el nico mbito de Direcciones de Red. Quien quiera puede montar una red TCP/IP privada ajena a la internet pblica. No existe inconveniente alguno en emplear cualquier segmento de direcciones IP en estas redes privadas, siempre y cuando no se desee conectarlas a la red pblica; ya que podran utilizarse segmentos de direcciones que existen en la red pblica y que debido a las rutas en la red privada seran inalcanzables desde esta ltima. Como solucin a este asunto, la IETF ha normalizado los segmentos de direcciones IP para su uso exclusivo en redes privadas, stos no deben ser enrutados en la internet pblica (Rekhter, et al., 1996).

II.2.b -

Definicin de NAT Para permitir la interconexin de redes de diferentes mbitos de

direcciones se emplea la Traduccin de Direcciones de Red, o simplemente NAT, siglas de su ttulo en ingls: Network Address Translation (Audet, et al., 2006). Para lograr su objetivo, un NAT adems de traducir direcciones de capa de red, debe modificar a veces las direcciones de capa de transporte (puertos), por lo que algunos autores se refieren a estas tcnicas como NAPT (Ford, et al., 2005; Thernelius, 2000), siglas de: Network Address and Port Translation; en espaol: Traduccin de Direccin de Red y Puerto. Aunque es comnmente aceptado el trmino NAT para referirse a ambos casos. En adelante nos referiremos a la tupla compuesta por una direccin IP y puerto de transporte como direccin de transporte; as lo sugieren varios autores (Schulzrinne, et al., 2003 p. 9; Daigle, 2002).

II.2.c -

Por qu implementar NAT El rpido crecimiento de la Internet ha dado lugar a un problema serio, la

insuficiencia de direcciones IP. Actualmente, Internet opera sobre la versin 4 del

41

Protocolo de Internet (IPv4). Las direcciones IPv4 estn compuestas por 4 octetos de bits, 32 bits en total, lo que da un conjunto de 4.294.967.296 (232) posibles direcciones IP, de las cuales, muchas no son utilizables por cumplir funciones de segmentacin de red (multicasting) (Bruno, et al., 2000). Est claro que la cantidad de direcciones de red que ofrece IPv4 es insuficiente para asignar una direccin a cada nodo que se conecta a la Internet. Las Traducciones de Direcciones de Red (NAT) se han propuesto como una solucin a corto plazo mientras se desarrolla e implementa una solucin formal a este problema: IPv6. Pero la transicin a IPv6 todava llevar un buen tiempo (Audet, et al., 2006). NAT permite multiplexar varias direcciones IP privadas en una sola direccin IP pblica, economizando el uso de direcciones IP pblicas. Pero la economa de direcciones de red no es el nico motivo que impulsa la implementacin de NATs en redes TCP/IP. Los NAT adems cumplen el roll de firewall, ya que no es posible establecer una conexin desde Internet a un nodo de red privada, por el simple hecho de que no existirn rutas en Internet para llegar la red privada de ste nodo (Niccolini, 2005). Hoy da es usual conectarse a Internet a travs de un NAT. Es normal que las compaas de provisin de servicios de Internet (ISP) asignen a sus clientes direcciones IP privadas. Tambin es muy comn que al conectarnos a Internet desde una oficina, una universidad, un hotel o algn hotspot Wi-Fi en algn sitio pblico nos estemos conectando directamente a una red privada, y que el trfico IP que cursamos con la Internet atraviese uno o ms NATs.

42

II.2.d -

Funcionamiento de un NAT Hasta aqu se ha definido tan solo el concepto y el propsito de NAT.

Ahora comenzaremos a describir su funcionamiento, para lo cual nos basaremos en el IETF Internet Draft: NAT Behavioral Requirements for Unicast UDP (Audet, et al., 2006). En adelante nos referiremos como red privada, interior o interna a la red conectada al extremo interno o privado del dispositivo que realizar el NAT; y como red pblica o exterior a la red conectada al extremo externo del NAT. El problema que se analiza en este trabajo de investigacin se basa en el funcionamiento de comunicaciones VoIP con sealizacin SIP/UDP 7 y RTP/UDP como protocolo para el transporte del flujo de medios. As que vimos conveniente enfocarnos en el comportamiento de un NAT para el manejo de paquetes UDP/IP, obviando los detalles para el manejo de paquetes sobre TCP u otros protocolos de capa de transporte.

II.2.d.1. Mapeo de Direcciones de Red y de Puertos de Transporte Cuando un nodo interno A establece una sesin contra un nodo externo B a travs de un NAT (con un primer mensaje desde A:a con destino a B:b), el NAT asigna a la sesin una direccin de transporte externa M:m, de manera que los mensajes que B desee enviar a A:a los remita a M:m y el NAT los reciba, modifique los encabezados de red y transporte (especficamente los campos de destino); y luego reenve los mensajes a A. Llamamos mapeo de NAT a la relacin establecida en el NAT entre: la direccin de transporte del nodo interno A:a; la direccin de transporte del nodo externo

En casos como ste se utilizar la barra de divisiones para indicar una tupla de protocolos de un mismo paquete, donde el protocolo de la izquierda representa a una capa superior en el modelo TCP/IP.

43

B:b; y la direccin de transporte externa del NAT M:m asignados para la sesin. El mapeo establece la traduccin que realizar el NAT durante la sesin entre A:a y B:b. A la direccin de transporte asignada por el NAT para el trfico entre la direccin de transporte interna A:a y la direccin de transporte del host remoto externo B:b se la conoce como direccin de transporte reflexiva de A:a para B:b.

II.2.d.2. Vigencia del Mapeo de NAT Cuando el NAT establece un mapeo, le asigna a ste un tiempo de expiracin, definido formalmente como Tiempo de ExpiracinMapeo
X

= Tiempo

ActualSistema + Tiempo de ValidezMapeos; donde Tiempo de ExpiracinMapeo X es una marca de tiempo que establece cundo dejar de ser vlido el mapeo X, Tiempo Actual es una marca de tiempo que indica el tiempo actual del sistema donde se ejecuta el NAT y Tiempo de ValidezMapeos es una constante numrica que indica la diferencia entre la Marca de Tiempo ActualSistema y la Marca de Tiempo de ExpiracinMapeo X. Excedido el Tiempo de Expiracin, los mensajes enviados desde el nodo externo hacia la direccin externa asignada por el mapeo sern rechazados en el NAT; y las direcciones de transporte de los mensajes desde dentro hacia fueran podrn ser o no traducidas de la misma manera que las veces anteriores dependiendo de la poltica de reutilizacin de mapeos de NAT implementada.

II.2.d.2.1.

Tiempo de Validez No existe ninguna norma respecto al valor del tiempo de validez del

mapeo, pero normalmente suele estar entre uno (1) y diez (10) minutos.

II.2.d.2.2.

Actualizacin del Tiempo de Expiracin Cuando un mensaje trafica a travs del mapeo del NAT, el Tiempo de

Expiracin se actualiza en base al Tiempo Actual.

44

Algunas implementaciones de NAT actualizan el tiempo de expiracin solo con trfico saliente, es decir, trfico desde la red interna hacia la red externa del NAT.

II.2.d.3. Polticas de Reutilizacin de Mapeos de NAT Habiendo definido el concepto de mapeo de NAT, podemos describir el factor clave en el comportamiento de los NAT para nuestro estudio: Las Polticas de Reutilizacin de Mapeos. Podemos definir a estas polticas como el criterio del NAT para reutilizar o no un mapeo establecido inicialmente para una sesin entre el nodo interno A:a y el nodo externo B:b para nuevas sesiones establecidas desde los mismos direccin y puerto de origen A:a hacia otra direccin o puerto externos de destino.

II.2.d.3.1.

Reutilizacin de Mapeo Independiente del Destino El NAT reutilizar el mismo mapeo para todas las sesiones iniciadas

desde A:a hacia cualquier destino.


Figura 15 - Reutilizacin de mapeos de NAT independiente del destino

B:a B:b
1 2

A:a

1 2 3

M:m
3

A
Dir. Base A:a A:a A:a

NAT
Dir. Destino B:a B:b C:c Dir. Reflexiva M:m M:m M:m

C:c

Fuente: Elaboracin propia, basado en Audet, et al. (2006)

45

El RFC 3489, que dicta las definiciones del protocolo STUN (Rosenberg, et al., 2003), establece una clasificacin de polticas de reutilizacin de mapeo de NAT en la que las primeras tres de sus cuatro polticas son subdivisiones de la Poltica de Mapeo Independiente del Destino: 1. Full Cone NAT: Cualquier nodo externo puede establecer una conexin con el nodo interno utilizando la direccin y el puerto externos asignados por el NAT para alguna sesin establecida previamente por el nodo interno hacia cualquier otro nodo externo. 2. Restricted Cone NAT: Puede establecerse una conexin desde cualquier puerto de un nodo externo utilizando la direccin y el puerto asignados por el NAT para una sesin previamente establecida hacia cualquier puerto del mismo nodo externo. 3. Port Restricted Cone NAT: Ninguna conexin puede establecerse desde el exterior. Es necesario que el nodo interno establezca siempre la sesin hacia una direccin y puerto externos para que se pueda emitir un mensaje desde la misma direccin de transporte externa para el nodo interno a travs de la direccin y puerto externos asignada por el NAT.

II.2.d.3.2.

Reutilizacin de Mapeo Dependiente de la Direccin de Red Destino El NAT reutiliza el mismo mapeo en todas las sesiones iniciadas desde la

misma direccin y puerto internos de origen A:a hacia la misma direccin de red externa de destino, sin importar el puerto de destino.

46

Figura 16 - Reutilizacin de mapeos de NAT dependiente de la direccin de red destino

B:a B:b
1 2 1 2 3

M:m M:n
3

A:a

A
Dir. Base A:a A:a A:a

NAT
Dir. Destino B:a B:b C:c Dir. Reflexiva M:m M:m M:n

C:c

Fuente: Elaboracin propia, basado en Audet, et al. (2006)

II.2.d.3.3.

Reutilizacin de Mapeo Dependiente de la Direccin y Puerto Destino El NAT reutiliza el mismo mapeo en todas las sesiones iniciadas desde la

misma direccin y puerto internos de origen A:a hacia la misma direccin de red externa de destino y el mismo puerto de transporte externo de destino.

47

Figura 17 - Reutilizacin de mapeos de NAT dependiente de direccin y puerto destino

B:a B:b
1

M:m A:a
1 2 3

M:n M:o
3

A
Dir. Base A:a A:a A:a

NAT
Dir. Destino B:a B:b C:c Dir. Reflexiva M:m M:n M:o

C:c

Fuente: Elaboracin propia, basado en Audet, et al. (2006)

El RFC 3489 (Rosenberg, et al., 2003) se refiere a esta poltica de reutilizacin de mapeo de NAT como Symmetric NAT.

II.2.e -

Implementaciones de NAT y polticas de mapeo Ford, et al. (2005) analizaron las polticas de NAT aplicadas en una

muestra de 380 implementaciones distintas de NATs de varios fabricantes. El resultado fue alentador para los desarrolladores e implementadores de soluciones de transversabilidad de NAT sobre UDP; ya que de las 380 implementaciones, 310 (82%) aplicaban la poltica de reutilizacin de mapeos de NAT independiente del destino, y tan solo 70 (18%) aplicaban alguna de las polticas de reutilizacin de mapeos dependiente del destino.

48

Figura 18 - Implementacin de Polticas de Reutilizacin de Mapeos

Implementacin de Polticas de Reutilizacin de Mapeos

Reutilizacin Independiente del Destino: 82% Reutilizacin Dependiente del Destino: 18%

Fuente: Ford, et al. (2005)

Tabla 5 NATs ms utilizados y sus aplicaciones y sus polticas de reutilizacin de mapeos

3Com Belkin Cisco D-Link FreeBSD Linksys Linux MS Windows Netgear

Muestra 7 14 12 21 9 46 32 33 37

Mapeo Independiente del Destino 7 14 12 16 7 45 26 31 31

Porcentaje 100% 100% 100% 76% 78% 98% 81% 94% 84%

Fuente: Ford, et al. (2005)

49

II.3 - Problemtica de los NAT en Comunicaciones VoIP Los NATs representan una problemtica importante para la

implementacin de cualquier sistema de comunicacin de extremo a extremo (en adelante P2P, por el ttulo en ingls: Peer to Peer), VoIP no es una excepcin (Georgescu, Adrian, 2008). En este captulo describiremos los problemas que implica un NAT para el establecimiento de una comunicacin VoIP, utilizando SIP y SDP como protocolos de sealizacin de la llamada, RTP como protocolo para el transporte del flujo de voz y UDP como protocolo de capa de transporte. Para facilitar el estudio de los casos de problemas de las comunicaciones VoIP a travs de NAT, definamos el siguiente escenario: el UAC, con direccin IP 192.168.0.23 est conectado directamente a la red privada 192.168.0.0/24, que se conecta a Internet a travs de un NAT cuya direccin IP pblica es la 74.125.19.103; el Servidor SIP al igual que el UAS estn conectados directamente a Internet con las IPs 207.46.193.254 y 207.16.44.22 respectivamente.

50

Figura 19 - Escenario de Interconexin a travs de NATs

sip:juan@ucsa.edu.py
207.16.44.22

sip:victor@ucsa.edu.py
192.168.0.23

IP Privada 192.168.0.1

IP Pblica 216.55.240.44 Internet 207.46.193.254

Red Privada 192.168.0.0/24

SIP Server ucsa.edu.py

Fuente: Elaboracin propia

Tanto con VoIP como con la mayora de los sistemas P2P, el problema principal se basa en la necesidad de los protocolos de capa de aplicacin de negociar direcciones IP y puertos de transporte en la carga til del mensaje (Georgescu, Adrian, 2008; Niccolini, 2005), es decir, a nivel de aplicacin. Entonces, cuando existe un NAT entre ambos extremos de la comunicacin, ste modificar slo los encabezados de red y de transporte, no as los datos en la capa de aplicacin, a menos que el NAT est implementado en un Application Layer Gateway o Pasarela de Capa de Aplicacin, como veremos ms adelante. Dividiremos los problemas en dos grupos: los problemas respecto a la sealizacin de la llamada y los problemas respecto al transporte del flujo de medios.

II.3.a -

Problemas respecto a la sealizacin de la llamada Recordemos que con sealizacin nos referimos a la mensajera entre

las entidades involucradas en una llamada para negociarla, establecerla, dar aviso de sta y terminarla.

51

II.3.a.1. Construccin de los Encabezados SIP Via y Contact El encabezado Via indica la direccin de transporte8 utilizada para la transaccin a la que corresponde un mensaje, la cul ser utilizada para enviar las respuestas a tal mensaje (Rosenberg, et al., 2002 p. 39). Cuando un UAC genera un mensaje de solicitud SIP debe incluir ste encabezado e indicar en l la direccin IP y puerto de transporte en la que espera recibir las respuestas a sus mensajes (Georgescu, Adrian, 2008). La norma para la implementacin de SIP sobre UDP establece que los mensajes de respuesta deben ser dirigidos a la direccin IP de origen del mensaje de solicitud recibido (Indicado en la Capa de Red) y al puerto de transporte indicado en el tope del encabezado SIP Via (Indicado en la Capa de Aplicacin). Considerando el caso en el que un UAC y un UAS se encontrasen en redes de mbitos distintos, el UAC construira el encabezado Via con una direccin de transporte no accesible para el destinatario del mensaje.

Direccin IP, y Puerto y Protocolo de Transporte.

52

Figura 20 - Mensaje SIP recibido por el SIP Server


Capa de Aplicacin
INVITE sip:juan@ucsa.edu.py SIP/2.0 To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:victor@192.168.10.23:6235> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 192.168.0.23 t=0 0 m=audio 9620 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 7777 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 74.125.19.103 Direccin de Destino: 207.46.193.254

Fuente: Elaboracin propia

El mismo problema se da con la construccin del encabezado SIP Contact, el cual indica el URI donde se ubicar a la instancia del UA que gener el mensaje para futuras transacciones SIP. Cuando hay un NAT entre el UA y el UAS o Servidor SIP, se indicar en el Host del URI una direccin probablemente inaccesible desde las redes del UAS o el Servidor SIP destinatario del mensaje, imposibilitando as la entrega de mensajes de transacciones SIP no comenzadas por ese UA; como por ejemplo: en el caso de tener que entregarle una llamada, o ms especficamente, un mensaje SIP INVITE inicial desde otro UA.

II.3.a.2. Expiracin del mapeo de NAT Anteriormente hemos hablado respecto a la vigencia de un mapeo de NAT. Establecimos que si el trfico a travs del NAT, relacionado con un mapeo determinado, cesa durante un tiempo superior al tiempo de validez del mapeo de NAT,

53

el mapeo expira, dejando al nodo externo del mapeo sin posibilidad de comunicarse con el nodo interno del mapeo antes que ste ltimo vuelva a enviar algn mensaje al nodo externo, reactivando el mapeo anterior o estableciendo un nuevo mapeo en el NAT. Si esto sucediera entre un UA, como nodo interno del NAT, y un SIP Server, como nodo externo del NAT, el SIP Server no podra dar aviso al UA de llamadas entrantes u otro evento que le concierna (Georgescu, Adrian, 2008; Rosenberg, 2007 p. 101).

II.3.b -

Problemas respecto al transporte del flujo de medios Los problemas relacionados con el transporte del flujo de medios, son un

tanto ms complicados que los problemas relacionados a la sealizacin; y requieren soluciones de transversabilidad de NAT mucho ms complejas que las implementadas para la sealizacin (Georgescu, Adrian, 2008).

II.3.b.1. Construccin del SDP Como ya hemos comentado, SIP en s no cuenta con todos los atributos necesarios para negociar el intercambio de flujo de medios (o voz) de una llamada VoIP. Pero como es un protocolo muy fcil de extender, pudo embutirse en el cuerpo de sus mensajes, el de solicitud INVITE y el de respuesta 200 (y otros) informacin de otro protocolo, el Protocolo de Descripcin de Sesin: SDP, por sus siglas en ingls (Handley, et al., 2006). El SDP es utilizado por los extremos de la llamada (Agentes de Usuario) para negociar aspectos que regirn el intercambio de los paquetes RTP para el transporte del flujo de medios. Entre estos aspectos est la direccin IP y puerto de transporte que utilizar cada UA para recibir los paquetes RTP enviados por el otro UA. Analicemos el intercambio inicial de mensajes SIP para el

establecimiento de una llamada VoIP a travs de un SIP Proxy.

54

Figura 21 - Secuencia Inicial de Sealizacin SIP de una sesin

sip:victor@ucsa.edu.py (UAC)

SIP Proxy

sip:juan@ucsa.edu.py (UAS)

INVITE / SDP 100 Trying INVITE / SDP 100 Trying

180 Ringing 180 Ringing

200 OK / SDP 200 OK / SDP

Fuente: Elaboracin propia, basado en RFC 3261 (Rosenberg, et al., 2002)

Observemos con mayor detalle el primer mensaje de INVITE / SDP:


Figura 22 - Direccin de Transporte en cuerpo SDP
INVITE sip:juan@ucsa.edu.py SIP/2.0 To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:victor@192.168.10.23:6235> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 192.168.0.23 t=0 0 m=audio 9620 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Fuente: Elaboracin propia, basado en RFC 4566 (Handley, et al., 2006)

Este mensaje est dividido en dos secciones, los encabezados y el cuerpo del mensaje, separados por una lnea vaca. En el cuerpo del mensaje se encuentra la informacin del SDP en forma de tuplas de atributos y valores.

55

El UAC deber construir el atributo c del SDP del mensaje INVITE con la direccin IP que dispondr para recibir los mensajes RTP del otro extremo de la llamada. De esta manera le indica al UAS la direccin IP a la que debe dirigir el flujo RTP (Handley, et al., 2006). Adems, el UAC construir el atributo m con el puerto de transporte que asignar para recibir los mensajes RTP del otro extremo de la llamada. De esta manera le indica al UAS a qu puerto de transporte deber remitir el flujo RTP. Ahora consideremos el escenario planteado en la Figura 19. El UAC, que se encuentra conectado a la red privada, tiene la direccin 192.168.0.23, y abrir el puerto UDP 9620 para recibir los mensajes RTP de la llamada que est iniciando. Utilizar estos datos para construir la informacin de SDP que viajar en el primer mensaje SIP INVITE. Sin embargo, esta direccin, indicada en el SDP, no es alcanzable por el otro extremo de la llamada, por encontrarse conectado a una red de mbito distinto. Sin ningn mecanismo o herramienta adicional, el UAC no tiene forma de saber qu direccin IP pblica y puerto UDP el NAT asignar para el mapeo de la direccin IP y puerto UDP que dispuso para la recepcin de mensajes RTP. An con cualquier mecanismo que le permita al UAC descubrir cmo son traducidos esta direccin y puerto en el NAT para un host externo determinado, si la poltica de reutilizacin de mapeos aplicada no es independiente del destino, esta informacin resultara obsoleta; porque al momento de construir el primer mensaje SIP INVITE / SDP, el UAC an no conoce la direccin IP y puertos a los que deber remitir sus mensajes RTP, as que no podr generar trfico experimental desde la direccin IP y puerto UDP que abri para el intercambio de RTP para que el NAT establezca el mapeo correspondiente (Niccolini, 2005; Rosenberg, 2007).

56

II.4 - Soluciones de Transversabilidad de NAT aplicables a VoIP sobre UDP

II.4.a -

Autocorreccin Unilateral de Direcciones Daigle (2002) defini el concepto de Autocorreccin Unilateral de

Direcciones (en adelante UNSAF por sus siglas en ingls: Unilateral Self-Address Fixing), a los mecanismos por los cuales algn proceso iniciador de una comunicacin intenta
determinar la direccin IP (y puerto de transporte) por el que es conocido (desde el exterior de un NAT), es decir, la traduccin que ha realizado el NAT (mapeo) para los mensajes

desde una direccin IP y puerto de transporte, o direccin reflexiva de transporte. Conocer las direcciones reflexivas de transporte para las direcciones de transporte locales abiertas para el trfico SIP y RTP, permitir a un UA que se encuentre tras un NAT utilizar esas direcciones al componer la carga til SIP y SDP. Sin embargo, estas tcnicas son vlidas solo cuando el NAT emplea una poltica de reutilizacin de mapeos de NAT independiente del destino.

II.4.a.1. STUN Clsico La Transversabilidad Simple de UDP a travs de NAT, o Simple Traversal of UDP through NAT (en adelante STUN) es una solucin de transversabilidad de NAT para UDP normalizada por la IETF en el RFC 3489 (Rosenberg, et al., 2003). Esta primera concepcin de STUN propone un protocolo para la Correccin Unilateral de Direcciones (Daigle, 2002), el descubrimiento de la presencia de un NAT y el tipo de implementacin de NAT.

57

II.4.a.1.1.

Entidades de la solucin STUN Para la implementacin de la solucin se requiere de la participacin de

dos entidades principales: A. Cliente STUN: Es una entidad que genera mensajes de solicitud STUN. El cliente STUN se implementa sobre sistemas finales, como un UA SIP. B. Servidor STUN: Es una entidad que recibe mensajes de solicitud STUN y enva respuestas. Los servidores STUN estn generalmente conectados directamente a la Internet pblica.

II.4.a.1.2.

Deteccin de NATs entre el Cliente y el Servidor STUN El mensaje de solicitud STUN Binding se utiliza para determinar los

mapeos establecidos en el NAT (o los NATs) entre el cliente STUN y el servidor STUN. El cliente STUN enva el mensaje Binding (sobre UDP) al servidor STUN; el cual obtiene la direccin IP y puerto de transporte del mensaje de solicitud recibido (que coincide con la direccin externa del mapeo del NAT ms prximo al servidor STUN), construye un mensaje de respuesta aadiendo esta direccin (reflexiva) de transporte a la carga til del mensaje, y lo enva de vuelta al cliente. Cuando el cliente STUN recibe el mensaje de respuesta, compara la direccin IP y puerto de transporte indicados en la carga til del mensaje con la direccin IP y puerto de transporte que utiliz para enviar el mensaje de solicitud, si no coinciden, se asume que hay uno o ms NATs entre el cliente y el servidor.

II.4.a.1.3.

Determinacin del Tipo de NAT entre el Cliente y el Servidor STUN El RFC 3489 (Rosenberg, et al., 2003) define cuatro tipos de

implementaciones de NAT que comentaremos en esta seccin. Sin embargo, debemos recalcar que tanto la experiencia como la literatura nos dice que esta clasificacin no refleja enteramente la realidad.

58

A. Full Cone NAT: Todos los mensajes de la misma direccin de transporte interna A:a son mapeados a la misma direccin de transporte externa N:n, es decir, se aplica reutilizacin de mapeos independiente del destino; adems, cualquier host externo puede alcanzar a A:a a travs de N:n. B. Restricted Cone NAT: Todos los mensajes de la misma direccin de transporte interna A:a son mapeados a la misma direccin de transporte externa N:n; pero un host externo X puede alcanzar a la direccin de transporte interna, solo si se gener previamente un mensaje desde esa direccin de transporte interna hacia el host X. C. Restricted Port NAT: Similar al modelo de Restricted Cone NAT, pero la restriccin incluye nmeros de puerto. D. Symmetric NAT: Se aplica reutilizacin de mapeos dependiente del destino; adems, una direccin de transporte externa X:x slo podr enviar mensajes a una direccin de transporte interna A:a si sta le envi un mensaje antes. Existen parmetros en el mensaje de solicitud STUN Binding que permiten que el cliente STUN solicite al servidor que las respuestas sean enviadas a alguna otra direccin, o desde una direccin IP y puerto de transporte distintos. Una vez que el cliente haya descubierto la presencia de uno o varios NATs en su ruta hacia el Servidor, puede enviar un segundo mensaje Binding, pero a una direccin distinta del primer mensaje y siempre desde la misma direccin de transporte local. Si la direccin de transporte indicada en el cuerpo del mensaje de respuesta de este segundo Binding coincide con la de la respuesta del primer Binding, entonces de asume que entre el Cliente y el Servidor hay un NAT que implementa reutilizacin de mapeos independiente del destino (Full Cone, Restricted Cone o Port Restricted Cone); en el caso contrario, se asume que el NAT es simtrico.

II.4.a.1.4.

Aplicacin de la Correccin Unilateral de Direcciones Si el UA mediante STUN determina que existe un NAT entre l y la

internet pblica, entonces deber construir la carga til del mensaje SIP con las

59

direcciones reflexivas de transporte, recibidas en los mensajes de respuesta a los mensajes STUN Binding que previamente envi a su servidor STUN.

II.4.a.2. Limitaciones de la Autocorreccin Unilateral de Direcciones STUN, como cualquier otra implementacin de tcnicas de

Autocorreccin Unilateral de Direcciones, es vlida solo para implementaciones de NAT que empleen la poltica de reutilizacin de mapeos independiente del destino. El motivo es fcil de explicar: Si el mapeo es dependiente del destino, la direccin reflexiva de transporte para una misma direccin interna A:a no ser la misma para los mensajes con destino al servidor STUN que con los mensajes con destino al UAS. Adems, para la aplicacin de tcnicas de Autocorreccin Unilateral de Direcciones se requiere soporte de aplicaciones como STUN en el UA. Esto aade requerimientos de compatibilidad de la operadora para los sistemas finales (Agentes de Usuarios SIP) de su red, e incrementa la dependencia de la operadora sobre los UAs porque se cede a stos la aplicacin de la lgica para la transversabilidad de NATs.

II.4.b -

Retransmisin del Flujo de Medios Esta tcnica consiste en la participacin de una entidad tercera que har

de pasarela para el flujo de mensajes RTP y RTCP entre los extremos de una sesin, a la que nos referiremos en adelante como Proxy RTP. Para que la solucin sea vlida, el proxy RTP debe ser alcanzable por ambos extremos de la llamada; as que generalmente est conectado directamente al internet pblico. A diferencia de las tcnicas de Autocorreccin Unilateral de Direcciones, las prcticas de retransmisin del flujo de medios garantizan la transversabilidad de NATs sin importar la poltica de reutilizacin de mapeos que stos utilicen.

60

Es posible ejecutar los procesos para la inclusin del Proxy RTP dentro de la conversacin entre los extremos tanto en los mismos extremos (Agentes de Usuario) como en el Servidor (Proxy) SIP. Seguidamente analizaremos ambos casos.
Figura 23 - Escenario par Retransmisin de Flujos de Medios

Servidor SIP Proxy RTP


Me
Me n s aje P s RT

n sa

jes

RT P

Red Privada A

Internet

Red Privada B

victor

NAT

NAT

juan

Fuente: Elaboracin propia

II.4.b.1. Control de la retransmisin por el UA a travs de TURN En este caso, el propio UA, antes de comunicar al otro extremo de la llamada las direcciones de transporte que utilizar para el intercambio de mensajes RTP y RTCP, solicitar al Proxy RTP que asigne dos direcciones de transporte para el intercambio de mensajes RTP y RTCP de la llamada, el Proxy RTP reservar dos direcciones de transporte y se las comunicar al UA, el cual las utilizar para llenar los campos respectivos dentro del cuerpo SDP que incluir en el mensaje SIP que enviar al otro extremo. El UA enviar sus paquetes RTP y RTCP a las direcciones asignadas por el proxy RTP, haciendo que se establezca un mapeo en el NAT, permitiendo el trfico bidireccional a travs del NAT entre el UA y el Proxy RTP para el intercambio de mensajes RTP y RTCP. El otro extremo de la llamada dirigir sus paquetes RTP y RTCP a la direccin de transporte asignada por el proxy RTP. El proxy RTP reenviar todos los mensajes recibidos de un extremo de la llamada al otro. Cualquiera de los extremos que se encuentre en una red privada conectada a internet a travs de NATs deber realizar este proceso, si este es el caso de 61

ambos, ambos debern hacerlo y el flujo de mensajes RTP y RTCP podra tener que pasar por dos proxies RTP para llegar desde un extremo de la comunicacin a otro. Transversabilidad de NATs Utilizando Retransmisin, o Traversal Using Relay NAT (en adelante TURN) (Rosenberg, et al., 2005) es un protocolo estndar de la IETF para las negociaciones entre un cliente y un servidor pblico que har retransmisin de datos en una comunicacin. En el caso especfico de las comunicaciones VoIP, TURN es utilizado por UAs para solicitar direcciones de transporte en un Proxy RTP. Esta solucin requiere una relacin de confianza entre el UA y el servidor TURN (tal como existe entre el UA y el Servidor SIP), por esta razn TURN adems provee un mecanismo de autenticacin mutua y chequeo de integridad para los mensajes intercambiados, basado en una clave privada compartida.

II.4.b.2. Control de la retransmisin del flujo de medios por el Servidor SIP Tambin es posible controlar la retransmisin de los mensajes RTP en la comunicacin desde el servidor SIP, deslindando al UA de toda responsabilidad y control sobre los procesos de retransmisin para la transversabilidad de NATs en la comunicacin (Georgescu, Adrian, 2008). La operacin de esta solucin, se describe en esta secuencia: 1. UAC enva un mensaje SIP INVITE / SDP al Servidor SIP para iniciar una sesin con el UAS. 2. El Servidor SIP solicita a un Proxy RTP que asigne un par de direcciones de transporte para el trfico RTP y RTCP entre el UAC y el UAS. 3. El Proxy RTP le comunica al Servidor SIP cules son estas direcciones de transporte asignadas. 4. El Servidor SIP modifica el contenido SDP del mensaje enviado por el UAC utilizando las direcciones de transporte asignadas por el Proxy RTP. 62

5. El Servidor enva el nuevo mensaje al UAS. 6. El UAS enva mensajes provisionales irrelevantes para la solucin (100 Trying, 180 Ringing, etc.) que el Servidor SIP reenva al UAC. 7. El UAS enva un mensaje SIP 200 OK / SDP 8. El Servidor SIP corrige el contenido SDP del mensaje con las direcciones de transporte que el Proxy RTP asign a la comunicacin. 9. El Servidor SIP enva el mensaje SIP 200 / SDP corregido al UAC. 10. El UAC enva un mensaje SIP ACK y comienza a enviar trfico RTP y RTCP hacia las direcciones de transporte asignadas por el Proxy RTP (as como se le indic en el contenido SDP dentro del mensaje SIP 200 que recibi. 11. El Proxy RTP recibe los mensajes RTP y RTCP del UAC, y descubre las direcciones de transporte reflexivas del UAC. 12. El Servidor SIP reenva el mensaje SIP ACK al UAS. 13. El UAS comienza a enviar trfico RTP y RTCP hacia las direcciones de transporte asignadas por el Proxy RTP. 14. El Proxy RTP descubre las direcciones de transporte del UAS. 15. El Proxy RTP hace bypass de los mensajes RTP y RTCP recibidos del UAC y el UAS.

II.4.c -

ICE El Establecimiento Interactivo de Conectividad, o Interactive

Connectivity Establishment (en adelante ICE), es un protocolo para la transversabilidad de NATs para el establecimiento de sesiones multimedia con el modelo de Oferta / Respuesta (Ver apartado II.1.b.2.3. ). ICE hace uso de otras soluciones como STUN y TURN. Expondremos seguidamente el funcionamiento de ICE, basados en las definiciones de Rosenberg (2007). ICE es vlido para cualquier protocolo que utilice el modelo de Oferta / Respuesta. A nosotros nos interesa particularmente su aplicacin con SDP sobre SIP.

63

ICE no se presenta como una solucin de transversabilidad para la sealizacin SIP, sino para el intercambio de flujos de medios negociados mediante SDP.

II.4.c.1.

Escenario para Implementacin de ICE Para describir el funcionamiento de ICE, nos basaremos en un escenario

sencillo derivado de los ejemplos que hemos estado utilizando, en el que dos agentes, Vctor y Juan, intentan establecer una sesin de medios entre ellos. Ambos se comunican mediante el protocolo SIP, a travs del cual intercambian sus Ofertas y Respuestas SDP. Ambos extremos intercambian sus mensajes SIP a travs del Servidor (Proxy) SIP. Adems de estos elementos, tambin son parte del escenario servidores STUN y TURN que son utilizados por ICE. Al principio del proceso, los UA pueden no conocer nada respecto a la topologa de su red, ICE les permitir conocer la informacin necesaria respecto a sus redes para poder escoger los mejores caminos para el intercambio del flujo de medios entre ellos.
Figura 24 - Escenario simple para la implementacin de ICE

Servidor SIP Servidor STUN Servidor TURN

Red Privada A victor

Internet

Red Privada B

NAT

NAT

juan

Fuente: Elaboracin propia, basado en Rosenberg (2007)

64

II.4.c.2.

Direcciones Candidatas Cada extremo de la comunicacin (UA) tiene una variedad de

direcciones de transporte que podra utilizar para comunicarse con el otro extremo, las cuales son: Candidata del Host: la direccin de transporte local del host (asociada a su propia interfaz de red fsica o virtual); Candidata Reflexiva del UA contra el Servidor: La direccin reflexiva del NAT para la direccin del UA en comunicaciones contra el Servidor STUN o TURN; Candidata de Retransmisin (Relay): La direccin de retransmisin (relay) dispuesta en el Servidor TURN.
Figura 25 - Direcciones Candidatas de ICE
Direccin Local (Candidata del Host) Candidata Reflexiva Candidata de Relay

Red Privada A victor

Internet

NAT

Servidor TURN

Fuente: Elaboracin propia

En principio, se debe asumir que cualquiera de las direcciones candidatas de un extremo tiene conectividad con cualquiera de las direcciones candidatas del otro extremo. Sin embargo, en la prctica, muchas combinaciones podran no funcionar. Por ejemplo: si ambos UA se encuentran tras NATs y en redes distintas, las direcciones de red en sus propias interfaces de red no tendran conectividad directa entre ellas. El objetivo de ICE es hacer que los extremos descubran qu combinaciones de direcciones candidatas funcionarn, lo cual depende directamente de las topologas de las redes entre los extremos.

65

ICE realiza un tanteo sistemtico de las posibles combinaciones de direcciones candidatas. Antes de comenzar estos tanteos, el UA debe conocer cules son sus direcciones candidatas. La direccin Candidata del Host es la propia direccin asociada a la interfaz de red fsica o virtual del host. Si el Host (UA) est directamente conectado a ms de una red, entonces cada direccin de red local con la que cuente se convierte en una Candidata del Host. La direccin Candidata Reflexiva se obtiene mediante una solicitud de Binding al servidor STUN (Ver apartado II.4.a.1.2. ) o una solicitud de Allocate a un Servidor TURN (II.4.b.1. ). Si existe ms de un NAT entre el UA y el Servidor STUN o TURN, entonces se crear en cada NAT un mapeo distinto para la direccin de transporte local del UA; pero se tomar como Candidata Reflexiva solo la direccin del mapeo del NAT ms prximo al Servidor STUN o TURN, por ser la direccin de origen del mensaje recibido por el Servidor STUN o TURN desde el UA. La direccin Candidata de Relay se obtiene mediante una solicitud de Allocate al Servidor TURN, el cul asignar una direccin de transporte local donde recibir mensajes que habr de retransmitir a la direccin reflexiva del UA. Esta direccin de transporte, Candidata de Relay, ser comunicada al UA en un mensaje de respuesta al Allocate.

II.4.c.3.

Chequeos de Conectividad Cuando Vctor, el UA que origina la llamada, obtiene sus direcciones

candidatas; las ordena de mayor a menor prioridad y se las comunica a Juan, el UA que recibe la llamada, mediante atributos en la Oferta SDP (Ver apartado II.1.b.2.3. ). Juan, a su vez, comunica sus direcciones candidatas a Vctor mediante atributos en la Respuesta SDP. Una vez que ambos UAs tengan conocimiento de las direcciones candidatas del otro extremo de la comunicacin, cada uno crea todos los Pares de 66

Candidatas posibles en base a las combinaciones de sus candidatas con las candidatas del otro extremo. Seguidamente se realizan los chequeos de conectividad. Cada chequeo de conectividad consiste en un mensaje de solicitud STUN Binding (Ver apartado II.4.a.1.2. ) sobre un Par de Candidatas desde la direccin local a cada una de las candidatas del otro extremo, y su respectiva respuesta. Para que estos chequeos sean vlidos, deben realizarse desde las mismas direcciones de transporte locales a ser utilizadas para el intercambio de mensajes RTP. Si existe un NAT entre Vctor y Juan, los mensajes STUN que cada uno enviar a cada direccin candidata del otro extremo, dependiendo de la poltica de reutilizacin de mapeos de los NAT en medio (Ver apartado II.2.d.3. ), podran generar mapeos distintos en los NAT a la direccin Candidata Reflexiva del UA contra el Servidor. El extremo receptor del mensaje STUN se dar cuenta de esto al notar que la direccin de transporte de origen del mensaje, tomada de las capas de red y de transporte, no corresponde a ninguna de las direcciones candidatas registradas del otro extremo. A estas nuevas direcciones aprendidas se las denomina: direcciones Candidatas Reflexivas contra el Extremo; y se las trata como cualquier otra candidata realizando nuevas combinaciones y los chequeos de conectividad correspondientes.

II.4.c.4.

Finalizacin del Proceso Una vez realizados los chequeos, cada extremo elige entre los Pares de

Candidatas que funcionaron el que corresponde a la candidata del otro extremo con mayor prioridad9, y enviar a sta sus mensajes RTP.

Cada extremo comunic mediante SDP al otro extremo sus candidatas, ordenadas segn su prioridad de mayor a menor.

67

II.4.d -

STUN v2 En agosto del 2007, la IETF public un borrador que propone una nueva

herramienta basada en STUN clsico denominada: Utilitarios de transversabilidad de NAT para Sesiones (Rosenberg, et al., 2007), o Session Traversal Utilities for NAT, conservando la sigla STUN. La segunda versin de STUN no propone una solucin nueva, sino ms bien un mecanismo para integrar el esquema bsico de STUN Clsico con otras soluciones, creando as una solucin completa de transversabilidad de NATs. A toda solucin que STUN utilice como componente se la denomina Uso de STUN (Rosenberg, et al., 2007 p. 27). A la fecha, la IETF ha publicado borradores proponiendo nuevas definiciones de TURN y ICE; esta vez como Usos de STUN. En este captulo no entraremos en detalle sobre los protocolos que hacen a STUN v2 pues redundaramos definiciones que ya hemos establecido previamente en esta misma tesis, cuando describimos STUN Clsico, TURN y ICE. Como ya hemos discutido antes, el RFC 3489 (Rosenberg, et al., 2003) presenta a STUN como una solucin completa de transversabilidad de NAT, que hace capaz al cliente de descubrir su direccin reflexiva para con un host remoto externo. Sin embargo, STUN no funciona en todos los escenarios, como cuando el NAT aplica una poltica de reutilizacin de NAT dependiente del destino, as que no debe tomarse como una solucin completa, tal como fue presentado originalmente. El escenario para la implementacin de STUN v2 es similar al de STUN clsico, con un agente STUN (cliente), un servidor STUN y ninguno, uno o ms NATs en medio. STUN v2 utiliza el mecanismo para la deteccin de la presencia y tipo de NATs definido ya para STUN Clsico.

68

Si se ha detectado un NAT entre el agente y el servidor, y el NAT reutiliza mapeos independientemente del destino, entonces las definiciones del STUN Clsico y el mtodo Binding para implementar la autocorreccin unilateral de direcciones sern aplicadas por STUN v2. Si el tipo de NAT necesitara tcnicas de transversabilidad ms complejas podrn utilizarse otros Usos de STUN, como TURN y ICE. En ambos casos, el mismo servidor STUN deber proporcionar soporte para estos Usos cual si fuere un servidor TURN o ICE, solo que la mensajera entre el agente y el servidor se realizar mediante STUN.

II.4.e -

Gateways de Nivel de Aplicacin Fabricantes y desarrolladores han atacado el problema de NAT en

comunicaciones P2P desde distintos frentes. Por un lado hemos presentado soluciones a nivel de cliente como STUN, TURN y ICE, donde, por ms que se requiera asistencia de servidores para el procesamiento de la solucin, la lgica de la solucin se aplica en el cliente (UA). Por otro lado, la retransmisin controlada por el servidor, tambin presentada en esta tesis, es un ejemplo de solucin aplicada a nivel de servidor, ya que el procesamiento de la solucin se realiza a nivel de servidor. Un tercer frente de solucin que hasta aqu no hemos comentado, es el que involucra al propio NAT en la administracin de la solucin de transversabilidad. En este captulo describiremos los Gateways de Nivel (o Capa) de Aplicacin, o Application Level (Layer) Gateways (en adelante ALG).

II.4.e.1.

Planteamiento de los ALG Como su nombre ya lo indica, los ALG operan sobre la capa de

aplicacin del modelo TCP/IP, a diferencia de las implementaciones regulares de NAT

69

y firewall que hemos discutido antes, las cuales solo procesan los paquetes a nivel de red y de transporte.
Figura 26 - Frentes de Soluciones de Transversabilidad de NATs

Soluciones a Nivel de Servidor


Servidor

Solucin a Nivel de NAT


NAT

Solucin a Nivel de Cliente


Cliente

{ { {

Retransmisin controlada por el Servidor

Gateways de Capa de Aplicacin

STUN

TURN

ICE

...

Fuente: Elaboracin propia

Como ya hemos establecido, el problema que representan los NAT para las comunicaciones P2P radica en que los extremos de la comunicacin negocian previamente las direcciones de transporte que utilizarn, y estas direcciones viajan en la capa de aplicacin de los mensajes que previamente intercambian, y si existe un NAT en medio, estas direcciones no sern vlidas para la comunicacin, en el sentido que no sern alcanzables por alguno de los extremos o ambos. Por s mismo, el cliente no podr predecir cmo se mapearn sus mensajes desde la direccin negociada para construir debidamente la carga til de sus mensajes. No obstante, esta vez no le daremos trabajo al cliente. Imaginemos que el NAT no solo realiza traducciones a nivel de capas de red y transporte, sino adems modifica la informacin a nivel de aplicacin de los mensajes corrigiendo las direcciones de transporte indicadas en la capa de aplicacin por las direcciones de transporte por las que las traducir ms adelante. Esto es posible mediante ALGs como complementos de NATs (Thernelius, 2000).

70

II.4.e.2.

Modelo de Funcionamiento de un ALG para SIP/SDP No existe norma alguna para la implementacin de un ALG, depende del

fabricante y del protocolo de capa de aplicacin para el cual ser utilizado. En esta tesis nos interesa particularmente los ALG para SIP/SDP, as que plantearemos un modelo bsico de funcionamiento para soporte de tales protocolos; basados en el trabajo de Thernelius, 2000.

II.4.e.2.1.

Criterios para recurrir al ALG En el caso que estudiamos, los ALG son solo tiles para procesar los

mensajes salientes, pues son los que requerirn traduccin. Adems, el NAT debe decidir mediante algn criterio si hacer o no que el ALG para SIP/SDP procese un mensaje. Un criterio aceptado para invocar al ALG es que el puerto de transporte destino de los mensajes salientes sean 5060
10

TCP o UDP.

Sin embargo, este criterio solo es vlido si no se levanta la sesin SIP sobre el puerto predeterminado.

II.4.e.2.2.

Validacin del Mensaje Para el ALG es ms sencillo identificar la naturaleza del mensaje que

para el NAT, ya que lo analiza a nivel de capa de aplicacin. Lo primero que el ALG debe hacer es validar el mensaje, es decir, cerciorarse de que el mismo es un mensaje SIP en texto plano; caso contrario, el mensaje deber ser omitido por el ALG, y el control deber ser devuelto al NAT. Los mensajes SIP estn basados en texto, as que la validacin es una tarea sencilla que puede lograrse a travs de un analizador lxico-sintctico simple.

10

Recordemos que 5060 es el nmero de puerto de transporte predeterminado para SIP, tanto sobre UDP como TCP.

71

II.4.e.2.3.

Correccin de la carga til del mensaje El ALG debe buscar en la carga til del mensaje SIP toda incurrencia de

la direccin IP del UA y los nmeros que sabe corresponden a puertos de transporte del UA en los campos del mensaje donde deben estar. Mediante algn mecanismo que no describiremos aqu, el ALG debe comunicar las direcciones de transporte identificadas en el mensaje al NAT, el cul debe crear y activar los mapeos correspondientes y comunicrselos al ALG. El ALG reemplazar las direcciones de transporte en la carga til del mensaje por las direcciones de transporte externas correspondientes segn los mapeos realizados por el NAT. Para conocer los campos especficos del mensaje que deben ser modificados, remtase al apartado II.2 -. Terminado este proceso, se devolver el control del mensaje al NAT, el cul realizar las traducciones correspondientes (al margen del trabajo realizado por el ALG) y enviar el mensaje al siguiente salto camino a su destino.

II.4.e.2.4.

Establecimiento de la sesin de medios Llegado el momento, el otro extremo de la comunicacin enviar sus

mensajes RTP para nuestro UA a la direccin de transporte indicada en la carga til del mensaje, la cual corresponde a la direccin externa del mapeo creado por el NAT y escrita en la carga til por el ALG. El NAT recibir el mensaje y lo remitir a la direccin de transporte que el UA propuso inicialmente y en la cual est esperando por los mensajes RTP.

72

CAPTULO III - MARCO METODOLGICO

III.1 - Profundidad y Diseo de la Tesis La presente es una investigacin descriptiva, pues detalla la problemtica de transversabilidad de NAT en comunicaciones VoIP, adems de exponer las soluciones actuales para este problema y el alcance de las mismas. Se describi adems los resultados de los experimentos realizados por los autores, que sacaron a la luz un nuevo modelo de solucin. Se adopt para esta tesis un enfoque cualitativo.

III.2 - Realizacin de la Tesis Se estudi el diseo y la arquitectura de las tecnologas relacionadas al problema de investigacin en base a sus normas oficiales. Entre estos estndares se incluyen los protocolos IP, SIP, SDP y RTP; los mecanismos para la codificacin y decodificacin de seales analgicas (voz); las soluciones de transversabilidad de NAT: STUN Clsico, STUN v2, TURN, ICE, etc. Para relevar informacin tecnolgica no normalizada y obtener las fuentes bibliogrficas oficiales de las tecnologas normalizadas, se consult fuentes secundarias a partir de libros y otros documentos impresos y en formato digital, incluyendo audio de grabaciones de entrevistas. Se particip del Tercer Congreso Anual de Desarrolladores VoIP, organizado por la TMC y celebrado en agosto del ao 2006 en Santa Clara, California, Estados Unidos; donde se discuti respecto a la problemtica de los NAT para VoIP con especialistas vinculados a organizaciones como la IETF y compaas como Google, Cisco, AT&T, Avaya y Digium.

73

Se intercambi correo electrnico con otros especialistas con el fin de afinar el conocimiento sobre el problema, las soluciones actuales y la tecnologa relacionada. Se mont un laboratorio y fue utilizado en principio para observar el problema en detalle, y aplicar y analizar algunas de las soluciones actuales. El laboratorio estuvo compuesto por una red separada en dos dominios de direcciones: A y B, unidas por un router con una interfaz de red conectada directamente a cada dominio, enmascarando11 todo el trfico desde el dominio A hacia el dominio B, convirtindose A en la red interna del NAT, y B en la red externa. Se conect directamente a la red interna un Agente de Usuario SIP, y en la red externa otro Agente de Usuario SIP, un servidor SIP y un proxy RTP. Se realizaron llamadas desde un Agente de Usuario SIP hacia el otro, alternando el sentido. Las llamadas eran conmutadas (a nivel de capa de aplicacin) por el Servidor SIP; y dependiendo del escenario y de la solucin que se estaba probando, el proxy RTP conmutaba (a nivel de capa de aplicacin) el trfico RTP y RTCP. Durante las pruebas, se realizaron capturas del trfico IP en la red de laboratorio mediante un sniffer, y se analizaron los paquetes SIP, RTP y RTCP intercambiados entre los agentes involucrados en las llamadas. Para probar el nuevo modelo de solucin, los autores disearon y desarrollaron un Servidor SIP bsico, implementando parcialmente el RFC 3261 (Rosenberg, et al., 2002) y dotando al servidor de las funcionalidades mnimas necesarias para actuar de Servidor de Registro y Servidor Proxy; adems de implementar en l las definiciones del nuevo modelo que documenta esta tesis. Se desarroll tambin un Proxy RTP controlado por el Servidor SIP, y la interfaz de comunicacin entre ambos.

11

Con enmascarar nos referimos a hacer NAT de todo el trfico desde un dominio interno hacia un dominio externo traduciendo las direcciones de red a una direccin del dominio externo.

74

III.3 - Instrumentos y Procedimientos Utilizados para la Recoleccin y el Tratamiento de la Informacin Gran parte de esta investigacin est basada en revisiones bibliogrficas, principalmente a partir de fuentes primarias, como las normas de los protocolos relevantes. Tambin se recogi informacin de conferencias, entrevistas con especialistas y pruebas de laboratorio. Para el caso de las pruebas de laboratorio, se emple un sniffer para capturar el trfico IP intercambiado entre los nodos de la red del laboratorio durante las pruebas. Y se utiliz un analizador de trfico IP para analizar el contenido de los mensajes intercambiados a niveles de aplicacin, transporte e internet.

III.4 - Muestra Utilizada Definiciones de protocolos estndares: SIP (Rosenberg, et al., 2002), SDP (Handley, et al., 2006) y RTP (Schulzrinne, et al., 2003); mensajes y secuencias. Definiciones de soluciones estndares de transversabilidad de NAT aplicables a VoIP: STUN (Rosenberg, et al., 2003), TURN (Rosenberg, et al., 2005), ICE (Rosenberg, 2007), STUNv2 (Rosenberg, et al., 2007); mensajes y secuencias. Trfico IP, y especficamente mensajes SIP, SDP y RTP intercambiados entre agentes en un ambiente controlado (red de laboratorio).

III.5 - Adecuacin de los mtodos a los objetivos de la tesis Se relev los detalles de la problemtica que trata esta tesis desde documentos oficiales de las normas de la tecnologa relacionada y adems se realiz experimentos en ambiente controlado, en funcin de explicar el problema correcta y completamente, segn establece el primer objetivo especfico de esta investigacin.

75

Se mont un laboratorio con aplicaciones propias desarrolladas cumpliendo con normas estndares de los protocolos involucrados, con el propsito de validar la solucin desarrollada como respuesta al objetivo general y los objetivos especficos 2, 3, 4 y 5 de esta investigacin. Pudo haberse creado nuevos mdulos para proyectos de cdigo abierto como el SIP Express Router y el Open SIP Express Router implementando la solucin propuesta en esta tesis, sin embargo, el objetivo principal de este trabajo no es elaborar un software, sino desarrollar un modelo de solucin aplicable por cualquier desarrollador de aplicaciones VoIP con sealizacin SIP. Optamos por desarrollar nuestras propias aplicaciones, con funcionalidades SIP reducidas para resaltar en el cdigo los detalles de nuestro modelo de solucin sobre la arquitectura SIP misma.

III.6 - Tratamiento de los datos No se aplico ninguna prueba estadstica para el tratamiento de los datos y la presentacin de los resultados, porque el tipo de muestra analizada y el enfoque adoptado para esta investigacin no lo han requerido. Se desarrollaron ecuaciones para modelar el volumen de datos real transferido para el transporte de un flujo bsico de medios. El resto de las observaciones fue registrado para su posterior anlisis cualitativo que desemboc en una evaluacin objetiva del estado del arte y de las necesidades, y en el desarrollo de una nueva solucin.

76

CAPTULO IV - RESULTADOS

IV.1 - Mejores Prcticas para facilitar la Transversabilidad de NAT para VoIP Las recomendaciones contenidas en este captulo no representan soluciones completas de transversabilidad de NAT, ms bien, prcticas recomendables que solucionan algunos de los problemas especficos de las comunicaciones VoIP a travs de NAT o que permiten la implementacin de soluciones completas de transversabilidad. Recomendamos: A. Sealizacin Simtrica y RTP Simtrico, B. NAT con reutilizacin de mapeos independiente del destino, C. Respuestas al origen de los mensajes, D. Retransmisin en pasarela (relaying) permanente de la sealizacin, y E. Refresco peridico del mapeo de NAT.

IV.1.a -

Sealizacin Simtrica y RTP Simtrico La sealizacin simtrica es el pilar de nuestra lista de mejores prcticas

para asegurar la compatibilidad de dispositivos SIP con las soluciones de transversabilidad de NAT. Consiste en utilizar la misma direccin de transporte tanto para enviar como para recibir mensajes SIP. Dicho de otra manera, consiste en que un dispositivo SIP espere la respuesta a sus mensajes en la misma direccin de transporte que utiliz para enviarlos. De la misma forma, RTP Simtrico consiste en utilizar una misma direccin de transporte para enviar y recibir paquetes RTP de un mismo flujo.

77

Afortunadamente, tanto la sealizacin simtrica como el RTP simtrico son implementados comnmente por los fabricantes de dispositivos SIP / VoIP.

IV.1.b -

NAT con reutilizacin de mapeos independiente del destino La implementacin de la poltica de reutilizacin de mapeos

independiente del destino permite la aplicacin de mtodos de Correccin Unilateral de Direcciones. En otro caso, la nica solucin efectiva para las comunicaciones de extremo a extremo sera retransmitir en pasarela el trfico IP, lo cual es muy costoso cuando se aplica a VoIP; o la aplicacin de Application Layer Gateways, tcnica no viable cuando no se tiene control sobre la red de acceso del abonado, lo cual sucede en casi todos los modelos de servicio explotados en la actualidad.

IV.1.c -

Respuestas al origen del mensaje Es una prctica sencilla y un requisito excluyente en funcin de la

transversabilidad de NATs para la sealizacin de la llamada que consiste en que las respuestas a los mensajes sean enviadas a la direccin de transporte de origen de los mismos, aprovechando as el mapeo establecido en el NAT. Para esto se requiere sealizacin simtrica. Es parmetro rport es una extensin del protocolo SIP que se aplica al encabezado Via y que permite a un cliente solicitar al servidor que las respuestas a su mensaje sean remitidas a la direccin IP y puerto de origen del mensaje (Rosenberg, et al., 2003).
Figura 27 - Aplicacin de la extensin SIP: rport
INVITE sip:juan@ucsa.edu.py SIP/2.0 To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport .

. .

Fuente: Elaboracin propia

78

Implementando la extensin rport, el UA que se encuentre tras un NAT podr sortear el problema de la construccin del encabezado Via (Ver II.3.a.1. ), ya que, aunque haya escrito su direccin privada en ese encabezado, el nodo remoto, el otro UAS o el SIP Server enviar las respuestas del mensaje a su direccin de origen, que corresponde a la direccin del mapeo del NAT ms prximo al nodo remoto12.

IV.1.d -

Retransmisin permanente de la sealizacin En el caso que el intercambio de mensajes de sealizacin se realice

mediante un SIP Proxy, ste deber ser pasarela para todos los mensajes SIP durante todo el dilogo SIP. Esto asegurar la transversabilidad de NATs para la sealizacin, siempre en cuanto los mensajes sean respondidos a su direccin de transporte de origen, principalmente cuando ambos extremos de la llamada se encuentran tras NATs distintos, ya que as las respuestas a los mensajes siempre llegarn al NAT desde la direccin de destino del mensaje que es respondido.

IV.1.e -

Refresco peridico del mapeo de NAT Para evitar que expire el mapeo de NAT dispuesto para la sealizacin

SIP de algn UA que se encuentre detrs del NAT, se debe garantizar que se curse trfico peridicamente, refrescando as el tiempo de expiracin, y en intervalos de tiempo no superiores al menor de los tiempos de validez (Ver II.2.d.2.1. ) de los mapeos de los NATs que atraviesa el trfico. Como analizamos ms atrs, el tiempo de validez de los mapeos de NAT son variables y dependen meramente de la implementacin del NAT y el fabricante. No existe una solucin para obtener el tiempo de validez de los mapeos de NAT, y el tanteo para conocer esta variable requerira bastante tiempo. Recomendamos entonces cursar

12

Direccin Reflexiva

79

trfico al menos cada 60 segundos, que es la mnima recomendada como tiempo de validez de los NATs. Proponemos dos mtodos para cursar trfico peridico entre el servidor SIP y el UA a travs de un NAT: A. Reducir el tiempo de expiracin de la registracin del UA a 60 segundos, B. Mensajes peridicos desde el SIP Server. Estos mtodos pueden aplicarse de manera no exclusiva, pero con la aplicacin de tan solo uno de ellos, bastar.

IV.1.e.1. Reducir el Tiempo de Expiracin de la Registracin del UA Para registrarse a una red SIP, el UA enva al Servidor SIP un mensaje SIP REGISTER. Este mensaje contiene un encabezado llamado Contact que indica el URI donde el UA debe ser contactado entre otros parmetros. Uno de estos parmetros es el expire que indica en segundos el tiempo en que el UA desea sea vigente su registracin. Tambin un UA puede informar este valor mediante el encabezado Expiration en el mensaje SIP REGISTER. El Servidor SIP puede rechazar ese valor e indicarle otro. Esto se consigue modificando el mismo parmetro expire en el encabezado Contact del mensaje SIP 200 OK que responde al SIP REGISTER. Recomendamos establecer el tiempo de validez de la registracin en 60 segundos; de esta manera el UA enviar mensajes SIP REGISTER en intervalos iguales o poco inferiores a 60 segundos.

IV.1.e.2. Mensajes peridicos desde el SIP Server Los mensajes de solicitud SIP OPTIONS son ideales para esta tarea. El mtodo SIP OPTIONS [] permite que un UA consulte a otro UA o a un SIP Server por
sus capacidades informacin acerca de los mtodos SIP que soporta, los tipos de contenido, extensiones, cdecs, etc. (Rosenberg, et al., 2002). Como se supone, este mtodo provoca

80

una respuesta SIP del UA consultado, y con esta respuesta que atravesar el NAT se refrescar con seguridad el mapeo.

IV.2 - Evaluacin del Estado del Arte Hemos presentado las tcnicas de transversabilidad de NATs para VoIP propuestas hasta hoy da y los estndares que responden a ellas. Cada una de tales tcnicas es vlida para un escenario especfico, pero por lo general es ineficaz, ineficiente o incluso inviable para otros posibles escenarios. As, STUN es vlido slo cuando el NAT reutiliza mapeos independientemente del destino, por lo que no puede considerarse una solucin completa de transversabilidad. TURN, o las tcnicas de retransmisin del flujo RTP en general, solucionan cualquier tipo de NAT, sin embargo, su implementacin puede ser muy costosa para algunos escenarios en trminos de consumo de ancho de banda y calidad de la comunicacin. Los ALG requieren control sobre la red del abonado, lo cual no es posible con muchos modelos de servicio. Encontramos en cada solucin ciertas ventajas y debilidades para uno u otro escenario, por lo que es fcil valorar la utilidad de poder combinar las soluciones y utilizarlas selectivamente; y pensando en esto, ICE fue concebido y ms tarde la segunda versin de STUN. Un factor comn visible en estas soluciones es que la lgica, e inherentemente el procesamiento de la solucin, corresponden al dispositivo cliente (o en la red del cliente, en el caso de los ALG); sin embargo, existen modelos de servicio en los que no se cuenta con control sobre el UA; o bien se puede querer no tener el control sobre el UA ni exigirle capacidades extras, ya sea para asegurar la compatibilidad con la mayor cantidad de fabricantes posible o simplemente por darle mayor libertad al usuario, o para facilitar la configuracin de los equipos. Entre todas las soluciones que hemos descrito, hay una que no se centra en el UA ni en su red: la tcnica de retransmisin del flujo de medios coordinada por el Servidor SIP.

81

En esta tesis buscamos una solucin de transversabilidad de NATs para modelos de servicios directos al abonado en el que no se cuenta con control sobre la red IP de acceso del abonado ni el dispositivo cliente; as que podra uno suponer que la tcnica de retransmisin de flujos de medios coordinada por el Servidor SIP es una solucin suficiente a nuestro problema, lo cual es correcto. Sin embargo, retransmitir los flujos de mensajes RTP entre los extremos de la comunicacin no es una solucin ptima; conlleva costos muy elevados en trminos de consumo de ancho de banda y calidad de la comunicacin.

IV.2.a -

Debilidades de la retransmisin de flujos de medios Debe optarse por la retransmisin del flujo de medios solo como ltima

opcin, debido a que agregar saltos a la comunicacin puede degradar su calidad y aadir latencia; y adems representan un consumo extra de ancho de banda para la operadora que, dependiendo del volumen de llamadas concurrentes que gestiona, puede llegar a ser muy importante e incluso prohibitivo.

IV.2.a.1.1.

Consumo excesivo de ancho de banda de los enlaces de la operadora El trfico del flujo de voz de una comunicacin VoIP no es un trfico

liviano. Para demostrar esto de una manera ms explcita, utilicemos como ejemplo una llamada con la siguiente configuracin: Cdec de voz: G.711 (80 Tramas por Paquete); Protocolo de Capa de Aplicacin: RTP; Protocolo de Capa de Transporte: UDP; Protocolo de Capa de Acceso a Red: Ethernet. Nos concentramos siempre en un modelo de servicio en que las redes IP de acceso de los abonados no son jurisdiccin de la operadora; por ejemplo, los clientes podran estar conectados a la operadora a travs de la Internet.

82

La carga til de los paquetes RTP estn compuestas por una o ms tramas de voz digitalizadas mediante un cdec. Podemos modelar el clculo del tamao de la carga til de los paquetes mediante la siguiente ecuacin: = ( ) Donde: es el tamao de la carga til del paquete en bits, es el tamao de una muestra de voz (seal analgica) en ms, es la muestra codificada (digitalizada), es el cdec utilizado para codificar (digitalizar) la muestra de voz, () es una funcin que devuelve la cantidad de bits de una cadena de bits, , siglas de Frames per Packet, en espaol: Tramas por Paquete; indica la cantidad de tramas enviadas por paquete. El tamao de cada muestra de voz codificada ( ) con G.711 () tiene 8 bits (( )). En el ejemplo utilizamos 80 tramas por paquete (), lo que da como resultado 640 bits () en la carga til de cada paquete. Para obtener el tamao total de cada paquete (), a la carga til () debemos sumarle los encabezados de las capas de aplicacin (), transporte (), internet () y acceso a red (). = + + + + El encabezado RTP () consta de 96 bits. En el ejemplo se indica UDP como protocolo de capa de transporte; el encabezado UDP () consta de 64 bits. El encabezado IP () est compuesto por 160 bits en total. Y la cabecera Ethernet con el cdigo de correccin de errores rene 144 bits. El tamao total resultante de cada paquete es: 640 () + 96 () + 64 () + 160 () + 144 () = 1.104 bits ().

83

G.711 codifica muestras de voz () de 0,125 ms., digitalizando en total 8.000 tramas por segundo (). 1000

Como cada paquete transporta 80 tramas (), se envan 100 paquetes por segundo () para enviar los 8000 tramas generadas en la misma unidad de tiempo.

Si cada segundo se envan 100 paquetes () de un tamao total de 1.104 bits () cada uno, se genera un throughput real () de 110.400 bps, o 108 Kbps. = Por cada llamada con esta configuracin, la operadora, en cuya red se encuentra el proxy RTP, debe soportar una tasa de transferencia 216 Kbps (2 ) de bajada, ya que recibe trfico RTP desde los dos extremos de la llamada; y 216 Kbps (2 ) de subida, ya que enva trfico RTP hacia los dos extremos de la llamada. Para transportar 100 llamadas concurrentes, la conexin a Internet de la operadora debera soportar una tasa de transferencia de 21 Mbps de bajada y 21 Mbps de salida.
Tabla 6 - Throughput por Cdec

Cdec G.711 G.711 G.711 G.729 G.729 G.729

Tramas / Paquete 80 160 240 1 2 3

Thoutghput Ethernet (Kbps) 108 86 78 53 30 23

Throughput Fr (Kbps) 100 81 75 45 27 20

84

G.729 G.729 G.723.1 (6.4) G.723.1 (6.4) G.723.1 (6.4) G.723.1 (5.3) G.723.1 (5.3) G.723.1 (5.3)

4 5 1 2 3 1 2 3

19 17 21 14 11 20 13 10

17 15 19 13 10 18 11 9

Fuente: Elaboracin propia

Figura 28 - Throughput real en Kbps sobre Ethernet segn cdec

120 100 80 60 40 20 0 G.711 (80 FPP) G.711 (160 FPP) G.729 (1 FPP) G.729 (2 FPP) Encabezado Ethernet Encabezado IP Encabezado UDP Encabezado RTP Carga Util

Fuente: Elaboracin propia

IV.2.a.1.2.

Degradacin de la calidad de la comunicacin Como ya hemos analizado en el Marco Terico de esta Tesis, la

transmisin de voz como de cualquier otro flujo de informacin de tiempo real, es crtica y bastante sensible a fenmenos muy comunes en redes de conmutacin de paquetes, como el jitter, paquetes perdidos y latencia. Aadir saltos a la comunicacin, como sucede con las tcnicas de retransmisin de flujos de medios, aumenta la

85

probabilidad de que estos fenmenos sucedan y por ende acentan los efectos sobre la calidad de la llamada, empobreciendo la experiencia del usuario. Cuando se dispone un proxy para el trfico RTP de una comunicacin, puede aparentar que solo se aade un salto innecesario en la ruta de los mensajes RTP, y de hecho sucede tal cual analizando el trfico a nivel de aplicacin. Sin embargo, analizando el trfico a nivel de red, los mensajes pueden llegar a conmutarse varias decenas de veces ms que si fueran dirigidos de un extremo a otro. Adems sabemos que en una red IP cada paquete toma una ruta independientemente del resto de los paquetes, y las condiciones de red y enlace de cada camino puede variar enormemente generando varianzas entre los tiempos de un paquete y otro, produciendo el fenmeno que conocemos como Jitter, el cual puede ser muy nocivo para la calidad de una llamada VoIP. Por otro lado, como es lgico, al aadir el nmero de saltos se aade latencia a la comunicacin, pudindose producir efectos como el eco en la comunicacin, degradando la calidad de la experiencia del usuario. Por estos motivos debe evitarse la retransmisin del trfico RTP siempre que sea posible, y aprovecharse toda oportunidad conectar a los extremos de la comunicacin directamente, sin conmutacin a nivel de aplicacin.

IV.3 - Nuestra Solucin El modelo de transversabilidad que hemos desarrollado y proponemos en esta tesis, es una tcnica que no requiere soporte del Agente de Usuario SIP, cuya participacin es pasiva; la lgica de la solucin es ejecutada en el Servidor SIP. Esta tcnica se basa en la tcnica de retransmisin coordinada por el Servidor SIP, sin embargo, intenta coordinar entre los extremos un intercambio directo

86

de flujos RTP, empleando una pasarela para el trfico RTP solo cuando alguno de los NAT involucrados reutiliza mapeos dependientemente del destino. De esta manera, nuestra propuesta es una solucin completa, a diferencia de STUN Clsico. Es una solucin que optimiza recursos ms que las tcnicas puramente de retransmisin. Adems no requiere soporte de la solucin en los Agentes de Usuario SIP ni en la red el abonado; puede ser enteramente implementada a nivel de servidor y de manera transparente para los clientes. Las secuencias de sealizacin y los contenidos de los mensajes que se muestran en este captulo son enteramente producto de nuestras pruebas en laboratorio. La carga de los mensajes a nivel de aplicacin (SIP y SDP) que presentamos corresponde al contenido real de los mensajes en esa capa; salvo algunas direcciones IP y URIs que han sido modificadas para facilitar la interpretacin de los mensajes. Los contenidos de las capas inferiores (transporte e internet) que exponemos no estarn expresados en su sintaxis real; hemos optado por presentar la informacin relevante de estos niveles en texto plano y en un formato sencillo y comprensible.

IV.3.a -

Deteccin de NAT e identificacin de tipo de NAT Como hemos presentado en el Marco Terico de esta Tesis, STUN ya ha

propuesto una tcnica para el descubrimiento de NATs entre el cliente y el servidor STUN, e incluso la identificacin de su tipo. Sin embargo, STUN es una solucin aplicable a nivel de cliente; y nosotros necesitamos descubrir la existencia y tipo de NAT existente entre el cliente y el servidor desde el servidor, y adems, sin requerir ninguna funcionalidad extra en el cliente. Los procedimientos de deteccin de NAT e identificacin de tipo de NAT deben ejecutarse cada vez que el cliente se registre a la red, ms especficamente, cada vez que el UA enve un mensaje SIP REGISTER al Servidor SIP y ste sea aceptado; y tal informacin debe mantenerse durante el tiempo en que el cliente est

87

conectado. Estos chequeos deben realizarse con cada REGISTER en caso que el escenario de conexin del UA haya sufrido algn cambio.

IV.3.a.1. Deteccin de presencia de NAT Para descubrir la presencia de uno o varios NATs entre el User Agent y el Servidor SIP basta con analizar las direcciones de transporte presentes en campos especficos dentro de la carga til del mensaje SIP y compararlos con la direccin de transporte de origen del mensaje. Estos campos son: Via: donde se indica la direccin de transporte a donde debern ser remitidas las respuestas; Contact: donde se indica el URI donde deber ser contactado el UA para futuras solicitudes13. Si las direcciones no coinciden, se asume que el paquete ha pasado por un NAT en su trnsito hacia el Servidor SIP.

13

Ver lnea 007 de la Figura 29

88

Figura 29 - Direcciones de transporte en mensaje SIP REGISTER


Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 REGISTER sip:ucsa.edu.py SIP/2.0 To: Victor <sip:victor@ucsa.edu.py> From: Victor <sip:victor@ucsa.edu.py>;tag=0471a117 Via: SIP/2.0/UDP 192.168.201.1:6000;branch=z9hG4bK-d87543-554575165-1--d87543-;rport Call-ID: 991c25278063a318 CSeq: 1 REGISTER Contact: <sip:2180009121@192.168.201.1:6000> Expires: 3600 Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: Mi User Agent Content-Length: 0

Capa de Transporte
Protocolo: UDP Puerto de Origen: 6918 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 74.125.19.103 Direccin de Destino: 207.46.193.254

Fuente: Elaboracin propia

Esta primera prueba, solo nos informa sobre la existencia de un NAT, no nos indica el tipo de NAT, en caso de existir uno.

IV.3.a.2. Identificacin del Tipo de NAT mediante Reflexin Dirigida En este apartado describiremos nuestra solucin para la identificacin del tipo de NAT resultante entre el UA y el Servidor SIP, mediante la tcnica a la que hemos llamado: Reflexin Dirigida; totalmente ejecutable desde el Servidor SIP. Para la aplicacin de esta tcnica, se requiere que el Servidor SIP est escuchando en dos direcciones de transporte distintas. A la direccin de transporte oficial del Servidor SIP, es decir, aquella donde recibir normalmente sealizacin SIP, la llamaremos direccin primaria. A la otra direccin IP, la cual tambin recibir mensajes SIP, pero cuyo propsito es solo servir de apoyo a nuestra solucin, la llamaremos direccin secundaria.

89

Consideremos las siguientes direcciones de dispositivos en nuestra red:


Tabla 7 - Nodos del escenario para aplicacin de Reflexin Dirigida

Dispositivo User Agent NAT (Direccin Interna) NAT (Direccin Externa) Servidor SIP (Direccin Primaria) Servidor SIP (Direccin Secundaria)
Fuente: Elaboracin propia

Direccin IP 192.168.0.23 192.168.0.1 100.10.10.1 74.1.1.10 74.1.1.11

Figura 30 - Escenario para la aplicacin de Reflexin Dirigida

74.1.1.10 74.1.1.11

Servidor SIP ucsa.edu.py sip:victor@ucsa.edu.py


192.168.0.23 IP Privada IP Pblica 192.168.0.1 100.1.1.10 Internet

Red Privada 192.168.0.0/24

Fuente: Elaboracin propia

Para la identificacin del tipo de NAT desde el Servidor SIP nos valdremos de caractersticas bsicas del protocolo SIP. Como ya explicamos antes, el encabezado SIP Via en un mensaje de solicitud indica dnde debe remitirse la respuesta de tal mensaje.

90

Figura 31 - Secuencia de sealizacin para reconocimiento del tipo de NAT

Victor (UA)

NAT BOX

Servidor SIP

Servidor SIP'

SIP: REGISTER

SIP: REGISTER

SIP: 200 OK

SIP: 200 OK

SIP: OPTIONS

SIP: OPTIONS

SIP: 200 OK

SIP: 200 OK

Fuente: Elaboracin propia

Cuando el Servidor SIP reciba un mensaje SIP REGISTER en su direccin primaria, si corresponde aceptarlo y se descubre que el UA se encuentra tras un NAT (o varios), entonces recordar la direccin de transporte de origen del mensaje, pues es esa la direccin reflexiva del UA, que le servir alcanzarlo y hacerle llegar los mensajes de solicitud subsiguientes.

91

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 REGISTER sip:ucsa.edu.py SIP/2.0 To: Victor <sip:victor@ucsa.edu.py> From: Victor <sip:victor@ucsa.edu.py>;tag=0471a117 Via: SIP/2.0/UDP 192.168.0.23:5060;branch=z9hG4bK-d87543-554575165-1--d87543-;rport Call-ID: 991c25278063a318 CSeq: 1 REGISTER Contact: <sip:victor@192.168.0.23:6000> Expires: 3600 Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: Mi User Agent Content-Length: 0

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 192.168.0.23 Direccin de Destino: 74.1.1.10

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 REGISTER sip:ucsa.edu.py SIP/2.0 To: Victor <sip:victor@ucsa.edu.py> From: Victor <sip:victor@ucsa.edu.py>;tag=0471a117 Via: SIP/2.0/UDP 192.168.0.23:5060;branch=z9hG4bK-d87543-554575165-1--d87543-;rport Call-ID: 991c25278063a318 CSeq: 1 REGISTER Contact: <sip:victor@192.168.0.23:6000> Expires: 3600 Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: Mi User Agent Content-Length: 0

Capa de Transporte
Protocolo: UDP Puerto de Origen: 6918 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 100.1.1.10 Direccin de Destino: 74.1.1.10

Seguidamente, el Servidor SIP enviar un mensaje de solicitud SIP desde su direccin primaria y apuntar el campo Via a su direccin secundaria.

92

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 OPTIONS sip:victor@192.168.0.23:5060 SIP/2.0 To: Victor <sip:victor@ucsa.edu.py> From: Servidor <sip:servidor@ucsa.edu.py>;tag=0471a117 Via: SIP/2.0/UDP 74.1.1.11:5060;branch=z9hG4bK-d87543-554575165-1--d87543Call-ID: 991c25278063a318 CSeq: 1 OPTIONS Contact: <sip:servidor@74.1.1.11:6000> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: Mi User Agent Content-Length: 0

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 6918

Capa de Internet
Protocolo: IP Direccin de Origen: 74.1.1.10 Direccin de Destino: 100.1.1.10

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 OPTIONS sip:victor@192.168.0.23:5060 SIP/2.0 To: Victor <sip:victor@ucsa.edu.py> From: Servidor <sip:ucsa.edu.py>;tag=0471a117 Via: SIP/2.0/UDP 74.1.1.11:5060;branch=z9hG4bK-d87543-554575165-1--d87543Call-ID: 991c25278063a318 CSeq: 1 OPTIONS Contact: <sip:servidor@74.1.1.11:5060> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: Mi User Agent Content-Length: 0

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 74.1.1.10 Direccin de Destino: 192.168.0.23

Cuando el UA reciba el mensaje de solicitud, enviar la respuesta a la direccin secundaria del Servidor SIP.

93

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 SIP/2.0 200 OK To: Victor <sip:victor@ucsa.edu.py> From: Servidor <sip:ucsa.edu.py>;tag=0471a117 Via: SIP/2.0/UDP 74.1.1.11:5060;branch=z9hG4bK-d87543-554575165-1--d87543Call-ID: 991c25278063a318 CSeq: 1 OPTIONS Contact: <sip:servidor@74.1.1.11:5060> Accept: */* Accept-Encoding: Accept-Language: en Support: Content-Length: 0

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 192.168.0.23 Direccin de Destino: 74.1.1.11

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 SIP/2.0 200 OK To: Victor <sip:victor@ucsa.edu.py> From: Servidor <sip:ucsa.edu.py>;tag=0471a117 Via: SIP/2.0/UDP 74.1.1.11:5060;branch=z9hG4bK-d87543-554575165-1--d87543Call-ID: 991c25278063a318 CSeq: 1 OPTIONS Contact: <sip:servidor@74.1.1.11:5060> Accept: */* Accept-Encoding: Accept-Language: en Support: Content-Length: 0

Capa de Transporte
Protocolo: UDP Puerto de Origen: 6918 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 100.1.1.10 Direccin de Destino: 74.1.1.11

En el Servidor, se compararn las direcciones de transporte de origen del mensaje SIP REGISTER enviado originalmente por el UA, y de la ltima respuesta, tambin enviado por el UA pero a la direccin secundaria del Servidor SIP. Si ambas direcciones coinciden, entonces se registra que el UA se encuentra tras un NAT (o el resultante de varios NAT) que reutiliza mapeos independientemente del destino, de lo 94

contrario, se asume que al menos uno de los NATs que cubren al UA reutiliza mapeos dependientemente del destino, o al menos la direccin IP de destino. Para nuestra solucin, no es particularmente importante diferenciar si la reutilizacin dependiente del destino es dependiente solo de la direccin IP del destino, o adems de la direccin de transporte del destino; nos basta con poder reconocer si la reutilizacin del mapeo mantiene o no alguna relacin con el destino.

IV.3.b -

Intercambio del Flujo RTP a travs de NATs

IV.3.b.1. Fundamentos de la Solucin Todo el contenido de esta tesis gira en torno a este apartado, en el que describiremos nuestra tcnica para la transversabilidad de NATs en funcin del intercambio del flujo de medios. Antes de continuar, recordemos que tenemos por objetivo que la lgica de nuestra solucin se ejecute a nivel de servidor, que no se requiera soporte en el cliente de ninguna tecnologa aparte de la propia para establecer una comunicacin VoIP con sealizacin SIP y que adems optimice recursos y no degrade la calidad de la comunicacin. En un captulo anterior hemos presentado una solucin de

transversabilidad de NATs para el intercambio de flujos RTP, en donde el procesamiento de la solucin se realiza a nivel de servidor: nos referimos a la basada en retransmisin del flujo RTP controlada por el Servidor SIP. Tal solucin cumple con algunos de nuestros objetivos, sin embargo, hacer de proxy del flujo RTP implica un consumo extra de ancho de banda que no existira de enlazar a los extremos de la comunicacin directamente. Tal como ya hemos analizado anteriormente, este consumo extra de ancho de banda para un volumen elevado de llamadas VoIP concurrentes puede representar un costo muy elevado.

95

Por otro lado la transmisin de voz, como de cualquier otro tipo de informacin de tiempo real, es crtica y muy sensible a fenmenos muy usuales en una red TCP/IP, como el Jitter. Cuanto ms saltos de conmutacin den los paquetes IP que transportan mensajes RTP antes de llegar a destino, ms propensa ser la comunicacin a sufrir problemas de calidad. Al implementar un Proxy RTP en la comunicacin, aadimos al menos uno y tal vez muchos saltos extra para el trfico RTP. Existen casos de NAT en el que la retransmisin del flujo RTP no es realmente necesaria, y en su lugar es posible establecer un intercambio directo entre los extremos de la comunicacin; tan solo hasta hoy no se ha formalizado una tcnica para descubrir el tipo de NAT entre el UA y el Servidor, desde Servidor; ni para enlazar a los extremos directamente para el intercambio de sus mensajes RTP, tambin desde el Servidor. La tcnica de retransmisin del flujo RTP coordinada por el Servidor SIP, tal como se ha documentado hasta ahora, no hace diferencias de los tipos de NAT y en cualquier caso hace bypass del trfico RTP entre los extremos. Nosotros ya hemos propuesto una tcnica para determinar si el NAT, o el resultante de todos los NAT que cubren a un UA, reutilizan mapeos dependiente o independientemente del destino. De esta manera podemos saber si es realmente necesario retransmitir el flujo RTP: cuando el NAT reutiliza mapeos en dependencia del destino; o si es posible lograr que el intercambio de flujos RTP se realice de forma directa entre los extremos de la comunicacin: cuando el NAT reutiliza mapeos independientemente del destino. Decimos que es posible lograr que el intercambio de flujos RTP se realice directamente entre los extremos cuando los NATs implementan reutilizacin de mapeos independientemente del destino porque: si es posible conocer la direccin

96

reflexiva14 de la direccin de transporte que el UA utiliza para transmitir y recibir paquetes RTP hacia cualquier destino externo, podemos reconfigurar los parmetros para el intercambio del flujo de medios entre los extremos de manera que se realice en forma directa; ya que sabemos que se utilizar el mismo mapeo cuando el UA transmita hacia el otro extremo de la comunicacin, as que tan solo debemos decirle al otro extremo que transmita su trfico RTP hacia la direccin reflexiva que ya conocemos de nuestro UA y viceversa.

IV.3.b.2. Detalles Tcnicos de la Solucin En la siguiente figura, planteamos el escenario en el que nos basaremos para describir la solucin, y que corresponde al escenario que hemos montado en laboratorio y sobre el cual hemos basado nuestras pruebas. Las direcciones IP de la red externa del NAT, representada en nuestro diagrama como Internet, han sido cambiadas para facilitar la comprensin del modelo; estos cambios son irrelevantes para el modelo en s.
Figura 32 - Escenario para nuestra solucin de transversabilidad de NAT para el intercambio de flujos de medios

74.1.1.10

sip:juan@ucsa.edu.py
200.2.2.20

Servidor SIP ucsa.edu.py

sip:victor@ucsa.edu.py
192.168.0.23

IP Privada IP Pblica 192.168.0.1 100.1.1.10 Internet 74.1.1.20

Red Privada 192.168.0.0/24

Proxy RTP

Fuente: Elaboracin propia

14

Direccin de transporte externa del mapeo del NAT para la direccin de transporte de un host interno, a la que llamamos base.

97

En el escenario mostramos que solo uno de los dos agentes de usuario SIP se encuentra tras un NAT; esta no es ninguna restriccin para nuestra solucin. Nuestra solucin es aplicable cuando el extremo originador (UAC) se encuentra tras ningn, uno o ms NATs; as tambin, el extremo terminador (UAS) puede encontrarse tras ningn, uno o ms NATs.

IV.3.b.2.1.

Anatoma del Proxy RTP El Proxy RTP es un servidor que recibe trfico RTP y RTCP de un

extremo de la sesin y lo retransmite a los otros extremos de la misma sesin. El Proxy RTP de nuestro modelo es controlado por el Servidor SIP. Es el Servidor SIP quien solicita al Proxy RTP que habilite un canal para hacer bypass de los flujos de paquetes RTP y la mensajera RTCP entre los extremos; es decir, que disponga una direccin de transporte por cada extremo de la comunicacin, en donde se recibir trfico RTP desde ese extremo para retransmitirse a los otros extremos de la llamada. Tcnicamente, un canal en nuestro Proxy RTP est compuesto por dos sockets servidores UDP recordemos que nuestra solucin est orientada a RTP sobre UDP - por cada extremo de la comunicacin. Un socket recibir paquetes RTP y el otro recibir paquetes RTCP, aunque el proxy no procesa estos paquetes, simplemente los conmuta. El RFC 3550 establece que cuando RTP se implementa sobre UDP, empleando el puerto UDP X, para RTCP se emplear el puerto UDP X+1 15. Por lo tanto, si se abre un socket servidor UDP en el puerto Y del Proxy RTP, el otro socket (dispuesto para recibir trfico RTCP) escuchar el puerto Y+1.

15

La implementacin de RTP y RTCP sobre otros protocolos de capa de transporte tienen otras restricciones.

98

Otro componente de nuestro Proxy RTP es un switcher que retransmitir los paquetes recibidos en un socket servidor a los otros sockets del mismo canal y para el mismo protocolo. Para hacer bypass del trfico RTP/UDP o RTP/TCP entre los dos extremos de la llamada, basta tan solo una direccin de transporte escuchando en el Proxy, y dirigir el trfico de ambos extremos hacia esa misma direccin de transporte. Adems, implementar un solo socket servidor para hacer el bypass entre dos clientes conectados al mismo servidor es mucho ms sencillo que implementar un socket servidor distinto para cada cliente y luego hacer bypass del trfico entre clientes. Sin embargo en esta tesis proponemos la manera difcil: implementar un socket servidor distinto por cada cliente porque necesitamos identificar a cul de los extremos corresponde cul flujo de mensajes RTP, ms especficamente, necesitamos conocer las direcciones de transporte origen de los mensajes RTP de cada extremo discriminadamente. No existe ningn parmetro en los encabezados y mucho menos en la carga til de los mensajes RTP o RTCP con el que se pueda relacionarlos con los mensajes SDP que configuraron ese trfico, ni mucho menos con la sesin SIP a la que corresponde ese trfico; por ende, tampoco es posible identificar por este medio cul de los extremos de la llamada genera cul flujo de mensajes RTP. Tampoco es posible relacionar el trfico RTP con algn extremo basados en la direccin de transporte origen de los mensajes RTP y las direcciones de transporte origen para el trfico RTP negociadas por SDP, ya que, como sabemos, no coincidirn si el UA se encuentra tras uno o varios NAT. As que, sin requerir ninguna extensin en los protocolos, para relacionar a un extremo de la comunicacin, con un origen de flujo de mensajes RTP, solo nos queda el recurso de dirigir el trfico RTP de cada UA a direcciones destino distintas, y relacionar la direccin de transporte origen de un flujo de mensajes RTP con un UA mediante la direccin de destino de ese trfico. Para que el Servidor SIP se comunique con el Proxy RTP, se recomienda se establezca una conexin TCP/IP persistente entre ambos, donde el Proxy RTP acte de servidor. Si debido a la arquitectura del Servidor SIP, no es posible o conveniente mantener una conexin persistente entre ambas entidades, el Servidor SIP deber levantar un socket servidor para recibir futuras notificaciones del Proxy RTP. 99

No nos interesa definir un estndar para la comunicacin entre el Servidor SIP y el Proxy RTP. Con el objeto de probar nuestra solucin, hemos implementado esta comunicacin mediante un protocolo propietario basado en mensajes XML para el intercambio de la mnima informacin suficiente para la correcta operacin de la solucin. Y solo en forma de ejemplo, lo presentamos a continuacin. Este protocolo est compuesto por cuatro mensajes: 1. ProxyReq: mensaje mediante el cual el Servidor SIP solicita al Proxy RTP la asignacin de un canal para la retransmisin de los flujos de mensajes RTP para una sesin; 2. ProxyResp: mensaje de respuesta del Proxy RTP al Servidor SIP, en el que aprueba o rechaza su solicitud; y en el caso de aprobarla, indica la direccin de transporte del canal abierto para el intercambio de mensajes RTP de la sesin; 3. ProxyInform: mensaje en el que el Proxy RTP notifica al Servidor SIP las direcciones de transporte origen de los mensajes RTP de cada extremo de una sesin; 4. ProxyAck: acuse de recibo enviado por el Servidor SIP. Un campo comn en todos estos mensajes es el Call-ID, extrado del campo SIP Call-ID de los mensajes SIP de la sesin involucrada. Este campo, que hace de clave primaria de una sesin SIP, servir para relacionar los mensajes entre el Servidor SIP y el Proxy RTP con una sesin SIP determinada.

IV.3.b.2.2.

Lgica de la Solucin Supongamos aqu que el UA que originar la sesin ser el de Vctor

(sip:victor@ucsa.edu.py), el extremo que se encuentra conectado desde la Red Privada; en adelante nos referiremos a este UA como Vctor. Por otro lado, el extremo recibidor de la llamada, ser Juan.

100

Para que la sesin se apruebe, Juan debe encontrarse registrado a la red SIP; y por lo tanto, asumimos que el Servidor tiene conocimiento de la existencia y el tipo de NAT (o el tipo resultante de los NATs) que est cubriendo a Juan; ya que al momento de la registracin de Juan se debi haber ejecutado los procedimientos para el reconocimiento de NATs, y de existir alguno, los procedimientos para la tipificacin del NAT mediante nuestra tcnica de Reflexin Dirigida. Por otro lado, para que esta sesin se establezca, no es un requerimiento tcnico que Vctor se encuentre registrado a la red (aunque por lo general es un requerimiento de la operadora); as es que si Vctor no se ha registrado previamente, se desconoce an la existencia y tipo de algn NAT entre l y el Servidor SIP. En este caso se deber ejecutar los procesos para el reconocimiento y tipificacin de NATs entre Vctor y el Servidor SIP al momento de recibir el mensaje SIP INVITE de Vctor. No es necesario que se detengan los procesos para el establecimiento de la llamada.
Figura 33 - Secuencia de mensajera para nuestra solucin

Victor

NAT

Servidor SIP

Proxy RTP

Juan

SIP: INVITE / SDP

SIP: INVITE / SDP SIP: 100 Trying SIP: 100 Trying


4 3

XML: ProxyReq XML: ProxyResp

5 6

SIP: INVITE / SDP SIP: 100 Trying SIP: 180 Ringing 180 Ringing 180 Ringing
11 13 10 12

7 8 9

200 OK / SDP 200 OK / SDP

200 OK / SDP ACK


15

14

ACK

16

ACK

17

Flujo RTP

Flujo RTP
XML: ProxyInform XML: ProxyAck
18 19

Flujo RTP

SIP: INVITE / SDP SIP: INVITE / SDP 200 OK / SDP


22 21

20

SIP: INVITE / SDP 200 OK / SDP


25

24

200 OK / SDP

23

Flujo RTP

Flujo RTP

Fuente: Elaboracin Propia

101

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 INVITE sip:juan@ucsa.edu.py SIP/2.0 To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:victor@192.168.10.23:6235> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 192.168.0.23 t=0 0 m=audio 9620 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 6235 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 192.168.0.23 Direccin de Destino: 74.1.1.10

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 INVITE sip:juan@ucsa.edu.py SIP/2.0 To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:victor@192.168.10.23:6235> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 192.168.0.23 t=0 0 m=audio 9620 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 7777 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 100.1.1.10 Direccin de Destino: 74.1.1.10

102

Cuando Vctor enve el primer SIP INVITE, y ste sea aceptado por el Servidor SIP, el Servidor SIP solicitar al Proxy RTP16 que disponga un canal para la retransmisin de los flujos de mensajes RTP y RTCP entre los extremos de la sesin que est coordinndose. El Proxy RTP crear un nuevo canal para la sesin, asignando las direcciones de transporte: [P:v]: para el destino del flujo RTP de Vctor (Ej: 74.1.1.20:10000); [P:v+1]: para el destino de los mensajes RTCP de Vctor (Ej: 74.1.1.20:10001); [P:j]: para el destino del flujo RTP de Juan (Ej: 74.1.1.20:10002); [P:j+1]: para el destino de los mensajes RTCP de Juan (Ej: 74.1.1.20:10003). El Proxy RTP enviar un mensaje de respuesta al Servidor SIP - Mensaje Proxy:Resp indicndole las direcciones [P:v] y [P:j]. El Servidor SIP modificar en el cuerpo del mensaje SIP INVITE recibido los campos SDP: Medios y Protocolo de Transporte (m) e Informacin de Conexin (c) con la direccin de transporte [P:j]. Y antes de retransmitir el mensaje hacia Juan, agregar su direccin al tope del encabezado SIP Via. De esta manera, el Servidor SIP como si fuera Vctor le indica a Juan que dirija su flujo de mensajes RTP a la direccin de transporte [P:j], del Proxy RTP, y sus mensajes RTCP a la direccin [P:j+1].

16

Mediante el mensaje Proxy:Req

103

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 INVITE sip:juan@200.2.2.20 SIP/2.0 To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 74.1.1.10:5060;branch=aaa123-;rport Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:victor@192.168.10.23:6235> Max-Forwards: 69 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 74.1.1.20 t=0 0 m=audio 10002 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 74.1.1.10 Direccin de Destino: 200.2.2.20

Cuando Juan apruebe la solicitud de iniciar sesin, o dicho de otra manera, cuando el usuario Juan conteste la llamada, el UA de Juan enviar un mensaje de respuesta SIP 200 OK / SDP indicndole a Vctor que la llamada ha sido aprobada y la direccin de transporte que utilizar para enviar y recibir paquetes RTP de esta sesin (e inherentemente, la direccin de transporte para los paquetes RTCP). El Servidor SIP recibir el mensaje SIP 200 OK / SDP, y antes de retransmitirlo a Vctor, suprimir su direccin del tope del encabezado SIP Via y modificar los campos SDP: Medios y Protocolo de Transporte (m) e Informacin de Conexin (c) con la direccin de transporte [P:v] que previamente le ha asignado el Proxy RTP. De esta manera le indicar a Vctor que dirija el flujo de mensajes RTP para Juan hacia el Proxy RTP.

104

12

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 SIP/2.0 200 OK To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 74.1.1.10:5060;branch=aaa123-;rport Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:juan@200.2.2.20:5060;user=phone> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 200.2.2.20 t=0 0 m=audio 7801 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 200.2.2.20 Direccin de Destino: 74.1.1.10

13

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 SIP/2.0 200 OK To: <sip:juan@ucsa.edu.py> From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 74.1.1.10:5060;branch=aaa123-;rport Via: SIP/2.0/UDP 192.168.0.23:6235;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:juan@200.2.2.20:5060;user=phone> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: MiTelefonoSIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 192.168.0.23 s=MiTelefonoSIP c=IN IP4 74.1.1.20 t=0 0 m=audio 10000 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 7777

Capa de Internet
Protocolo: IP Direccin de Origen: 74.1.1.10 Direccin de Destino: 100.1.1.10

105

A partir de este momento, ambos extremos cuentan con suficiente informacin para establecer la llamada, y lo harn tan pronto Vctor enve un mensaje SIP ACK. Entonces ambos extremos enviarn trfico RTP y RTCP hacia el Proxy RTP, y cuando ste haya recibido trfico de ambos extremos, y conozca la direccin de origen de sus dos clientes, comenzar a retransmitir el trfico de un extremo a otro. Se habr atravesado el NAT que cubre a Vctor para realizar el intercambio de flujos de medios; ya que cuando Vctor comenz a cursar trfico RTP y RTCP hacia el Proxy RTP, el NAT habr creado dos nuevos mapeos para el trfico IP desde las direcciones de transporte de origen de Vctor para su trfico RTP y RTCP hacia las direcciones de destino externas [P:v] y [P:v+1], que corresponden al Proxy RTP. De esta manera, se hace posible llegar a las direcciones base de Vctor para el intercambio de flujos de medios desde las direcciones [P:v] y [P:v+1]. Siguiendo nuestro ejemplo, los mapeos activos en el NAT seran los presentados en la siguiente tabla.
Tabla 8 - Tabla de mapeos de NAT activos

Direccin Base 192.168.0.23:6235 192.168.0.23:9620 192.168.0.23:9621

Direccin Destino 74.1.1.10:5060 74.1.1.20:10000 74.1.1.20:10001

Direccin Reflexiva 100.1.1.10:7777 100.1.1.10:20000 100.1.1.10:20001

Descripcin SIP a Servidor SIP RTP a Proxy RTP RTCP a Proxy RTP

Fuente: Elaboracin propia

Cuando ya ambos extremos estn cursando trfico RTP a travs del Proxy RTP, ste ltimo conocer las direcciones de transporte origen de ambos: Vctor y Juan: [V:p]: Direccin reflexiva en el NAT tope de la direccin de transporte de Vctor para el intercambio de paquetes RTP, en nuestro ejemplo: 100.1.1.10:20000; [V:p+1]: Direccin reflexiva en el NAT tope de la direccin de transporte de Vctor para el intercambio de paquetes RTCP, en nuestro ejemplo: 100.1.1.10:20001;

106

[J:q]: Direccin de transporte de Juan para el intercambio de paquetes RTP, en nuestro ejemplo: 200.2.2.20:7801; [J:q+1]: Direccin de transporte de Juan para el intercambio de paquetes RTCP, en nuestro ejemplo: 200.2.2.20:7802. Seguidamente, el Proxy RTP deber comunicar estas direcciones al

Servidor SIP. En nuestra implementacin, esta notificacin se da mediante el mensaje XML:ProxyInform. El Servidor SIP sabe de la existencia y el tipo de NAT existente entre cada extremo y l, porque aplic nuestra tcnica de Reflexin Dirigida para localizar y tipificar NATs entre cada extremo y l. Si est presente algn NAT que implemente reutilizacin de mapeos dependiente del destino, entonces la configuracin de la llamada no se alterar, y el intercambio de flujos de medios se seguir realizando a travs del Proxy RTP. Pero si no existe ningn NAT que implemente reutilizacin de mapeos dependiente del destino, entonces es posible reconfigurar la llamada para que el intercambio de flujos de medios se realice directamente entre los extremos de la llamada, conmutado solo a nivel de red. SIP permite reconfigurar los parmetros de una sesin cuando esta ya est en curso, mediante re-Invites. Cuando uno de los extremos quiere alterar algn parmetro previamente negociado para el establecimiento de la llamada, como por ejemplo el cdec de voz a ser utilizado o la direccin de transporte para el intercambio de flujos de medios, simplemente enva un mensaje SIP INVITE con la nueva configuracin. A los mensajes SIP INVITE enviados una vez la sesin ya se encuentra establecida, se los conoce como re-Invites. Como enseamos en la Figura 33, en nuestro modelo no son los extremos de la comunicacin quienes reenviarn los re-Invites, sino el Servidor SIP, quien tiene toda la informacin necesaria para reconfigurar la llamada, y adems tiene los mapeos de los NAT para la sealizacin abiertos para l.

107

El servidor SIP enviar un re-Invite a Vctor, hacindose pasar por Juan, ajustando los parmetros del SDP para que Vctor dirija sus mensajes RTP y RTCP hacia las direcciones de transporte de Juan para el intercambio de flujos de medios: [J:q] y [J:q+1] respectivamente.

20

Capa de Aplicacin
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 INVITE sip:victor@100.1.1.10 SIP/2.0 To: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e From: Juan Hanson <sip:juan@ucsa.edu.py>;tag=8f1bea01 Via: SIP/2.0/UDP 74.1.1.10:5060;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:juan@74.1.1.10:5060> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: UCSA_SIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 74.1.1.10 s=UCSA_SIP c=IN IP4 200.2.2.20 t=0 0 m=audio 7801 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 192.168.0.23 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 7777

Capa de Internet
Protocolo: IP Direccin de Origen: 74.1.1.10 Direccin de Destino: 100.1.1.10

Vctor recibir el SIP re-INVITE y responder con un 200 OK. Seguidamente, dirigir sus paquetes RTP y RTCP hacia las direcciones de transporte de Juan: [J:q] y [J:q+1], respectivamente. Como Juan est directamente conectado a la red pblica, sin un NAT en el medio, no dejar de recibir el flujo RTP en ningn momento. Si existiera un NAT cubriendo a Juan, los mensajes RTP no llegaran hasta Juan hasta que l comience a enviar mensajes RTP hacia la direccin de transporte reflexiva de Vctor para el intercambio RTP, ya que recin ah se activara el mapeo correspondiente en el NAT.

108

En el NAT que cubre a Vctor, se activarn dos nuevos mapeos para el trfico RTP y RTCP desde Vctor hacia Juan, reutilizando la direccin reflexiva de los mapeos anteriores para las mismas direcciones de transporte origen; o dicindolo de otra manera: reutilizando los mapeos anteriores para otra direccin de transporte destino.
Tabla 9 - Tabla de mapeos de NAT activos (2)

Direccin Base 192.168.0.23:6235 192.168.0.23:9620 192.168.0.23:9621 192.168.0.23:9620 192.168.0.23:9621

Direccin Destino 74.1.1.10:5060 74.1.1.20:10000 74.1.1.20:10001 74.1.1.20:10000 74.1.1.20:10001

Direccin Reflexiva 100.1.1.10:7777 100.1.1.10:20000 100.1.1.10:20001 100.1.1.10:20000 100.1.1.10:20001

Descripcin SIP a Servidor SIP RTP a Proxy RTP RTCP a Proxy RTP RTP a Juan RTCP a Juan

Fuente: Elaboracin propia

De la misma forma que con Vctor, el servidor SIP enviar un re-Invite a Juan ajustando los parmetros del SDP para que Juan dirija sus mensajes RTP y RTCP hacia las direcciones de transporte reflexivas de Vctor para el intercambio de flujos de medios: [V:p] y [V:p+1] respectivamente.

Capa de Aplicacin
24

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024

INVITE sip:juan@200.2.2.20 SIP/2.0 To: Juan Hanson <sip:juan@ucsa.edu.py>;tag=8f1bea01 From: Victor Cartes <sip:victor@ucsa.edu.py>;tag=7f1bea0e Via: SIP/2.0/UDP 74.1.1.10:5060;branch=z9hG4bK-d87543-241641872-1--d87543-;rport Call-ID: 8110a31f8f533715 CSeq: 1 INVITE Contact: <sip:victor@74.1.1.10:5060> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: UCSA_SIP Content-Length: 274 v=0 o=- 19725484 19725700 IN IP4 74.1.1.10 s=UCSA_SIP c=IN IP4 100.1.1.10 t=0 0 m=audio 20000 RTP/AVP 100 6 0 8 3 18 5 101 a=alt:1 1 : 44A99D76 0DDA8196 74.1.1.10 9620 a=fmtp:101 0-15 a=rtpmap:100 speex/16000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Capa de Transporte
Protocolo: UDP Puerto de Origen: 5060 Puerto de Destino: 5060

Capa de Internet
Protocolo: IP Direccin de Origen: 74.1.1.10 Direccin de Destino: 200.2.2.20

109

Juan recibir el re-Invite, y dirigir sus paquetes RTP y RTCP a las direcciones de transporte reflexivas de Vctor: [V:p] y [V:p+1], respectivamente. Como previamente ya se activ un mapeo en el NAT que cubre a Vctor para el trfico desde las direcciones base de [V:p] y [V:p+1] hacia [J:q] y [J:q+1] respectivamente, entonces los mensajes que se remitan desde [J:q] hacia [V:p], igual que con la otra tupla, sern aceptados por el NAT y reenviados a las direcciones base correspondientes. De esta manera, conseguimos el intercambio directo de flujos de medios sobre UDP entre los extremos de la llamada atravesando NATs; cumpliendo con el objetivo principal de este trabajo.

110

CAPTULO V - CONCLUSIONES
Hemos documentado la problemtica de la transversabilidad de NAT para sesiones VoIP con sealizacin SIP de una forma completa y accesible, como los materiales que hemos relevado no lo han conseguido independientemente. El documento confeccionado tiene valor terico para otros investigadores y desarrolladores de soluciones VoIP. Cumplimos as nuestro primer objetivo especfico: Describir a detalle y de una manera accesible la problemtica de NAT en comunicaciones VoIP. Hemos escogido y estudiado un grupo de modelos de servicios basados en VoIP, debido a la ineficiencia de las soluciones de transversabilidad de NAT aplicables a tales modelos; y basados en las soluciones estudiadas, hemos diseado un modelo de solucin aplicable ms eficiente. Este modelo optimiza el consumo de ancho de banda en los enlaces de la operadora contra las redes de sus abonados, adems de minimizar factores que influyen negativamente sobre la calidad de la comunicacin, y que las otras soluciones aplicables acentan. De esta manera hemos alcanzado el objetivo general de este trabajo y los objetivos especficos 2, 3, 4 y 5; que pasaremos a detallar. Hemos logrado un diseo de solucin cuya lgica se ejecuta en el Servidor SIP, y que no requiere soporte activo en el dispositivo cliente (Agente de Usuario SIP) ni control sobre la red IP de acceso del abonado. Con esto, hemos respondido al segundo objetivo especfico de esta tesis: Disear una solucin para modelos de servicios directos al abonado que no requiera control sobre la red IP de acceso del abonado ni sobre los agentes de usuario SIP. Para la implementacin del modelo de solucin mencionado, no se requiere el soporte de ninguna tecnologa en los Agentes de Usuario SIP, fuera de los estndares mnimos necesarios para cumplir con sus funciones bsicas de realizar y recibir llamadas. Tampoco se requieren nuevas extensiones para los protocolos utilizados ni para ningn otro estndar. Por lo tanto, este modelo puede ser aplicado de forma transparente para los usuarios del servicio y sin necesidad de cambios de

111

configuracin, ni de versiones de software ni de hardware en los dispositivos clientes. De esta manera alcanzamos el tercer objetivo especfico que nos hemos propuesto: Lograr que la solucin mencionada no requiera nuevas extensiones en los protocolos soportados por los agentes involucrados. El modelo que hemos propuesto optimiza el consumo de ancho de banda de la operadora, respecto a las soluciones actuales, debido a que solo se retransmite el trfico RTP durante toda la sesin cuando el tipo de NAT resultante presente frente a alguno de los extremos no admite otro mtodo. Segn los resultados del estudio de Bryan Ford (Ford, et al., 2005), el 82% de las implementaciones de NAT s admiten la aplicacin de ste mtodo y no requieren de la retransmisin para asegurar la transversabilidad. Basados en estos argumentos, concluimos que se ha satisfecho el cuarto objetivo especfico de esta tesis, que estableca: Lograr que la solucin mencionada sea ms eficiente que las soluciones actuales aplicables a los mismos modelos de servicio. Al evitar la retransmisin cuando se da la posibilidad, nuestra solucin no solo consigue economizar el consumo de ancho de banda, sino adems puede restarle muchos saltos de conmutacin a nivel de red al trfico IP entre un extremo y otro de la comunicacin, minimizando la ocurrencia de fenmenos como el retardo y el jitter, que restaran calidad a la comunicacin. As cumplimos el quinto objetivo especfico que nos hemos propuesto: Lograr que la solucin mencionada minimice los efectos negativos de las otras soluciones actuales aplicables sobre la calidad de la comunicacin. Para que nuestra solucin sea aplicable, se requiere la capacidad no solo de detectar desde el Servidor SIP la presencia de NATs frente a los Agentes de Usuario SIP que se conectan a l, sino adems se requiere identificar el tipo de poltica de reutilizacin de mapeos del NAT resultante. Para tal efecto hemos propuesto una tcnica a la que denominamos: Reflexin Dirigida.

112

En toda la bibliografa consultada no se encontraron referencias formales al modelo de solucin que hemos diseado y descrito como resultado de esta tesis. Por este motivo, asumimos que se trata de un nuevo modelo. Por todo esto, nuestra tesis, adems de valor terico tiene valor prcticotcnico, econmico y adems social, ya que le permitir a operadoras de telecomunicaciones que implementen VoIP con modelos de servicios similares a los que hemos analizado reducir costos, potenciar la calidad de su servicio y explotarlo a un precio menor. Por ltimo, creemos que el modelo de solucin que hemos propuesto puede servir de base para nuevas soluciones a este mismo problema, de la misma forma que nosotros nos hemos basado en otras propuestas. Esperamos tambin que pueda generalizarse para su aplicacin en la transversabilidad de NAT para otras aplicaciones P2P, o incluso, pueda abstraerse su lgica para el desarrollo de soluciones de otros problemas similares.

113

CAPTULO VI - RECOMENDACIONES
Se recomienda realizar un estudio cuantitativo sobre la incidencia de fenmenos como el retardo y el jitter durante la distribucin de paquetes RTP, en la decodificacin de seales de voz, segn cdec. Y un estudio estadstico sobre diferencias de jitter y retardo entre sesiones con y sin retransmisin de lujos de paquetes RTP. Por otra parte, para la aplicacin de nuestra solucin, hemos propuesto a grandes rasgos un diseo de proxy RTP mucho ms complejo que cualquier proxy RTP que solo tuviera que hacer bypass del trfico entre los extremos durante toda la sesin. El motivo principal, como ya hemos explicado en el Captulo IV, es que necesitamos discriminar cada flujo de mensajes RTP y asociarlo con el extremo de la sesin correspondiente para continuar el desarrollo de nuestra solucin; y solo conseguimos lograrlo basndonos en la direccin de transporte destino de los paquetes RTP dirigidos hacia el proxy; apuntando cada flujo RTP a una direccin de transporte distinta en el proxy RTP. Simplificar este mtodo podra significar una implementacin ms sencilla y eficiente del proxy RTP que requerir menos recursos de procesamiento y por sobre todo de memoria en los proxies. Por ende, recomendamos investigar y desarrollar nuevas alternativas.

114

BIBLIOGRAFA
Audet, F. y Jennings, C. 2006. NAT Behavioral Requirements for Unicast UDP (Requerimientos de comportamiento de NAT para UDP unicast). [En lnea] 2006. http://tools.ietf.org/id/draft-ietf-behave-nat-udp-07.txt. Bolot, Jean Chrysostome y Vega-Garca, Andrs. 1996. Control Mechanisms for Packet Audio in the Internet (Mecanismos de control para audio paquetizado en internet). [En lnea] 1996. http://citeseer.ist.psu.edu/265952.html. Bruno, A. Anthony y Kim, Jacqueline. 2000. CCDA Exam Certification Guide. Indianapolis, USA : Cisco Press, 2000. 0-7357-0074-5. Daigle, L. 2002. IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation (Consideraciones para la Autocorrecin Unilateral de Direcciones a travs de NAT). [En lnea] IETF, 2002.

http://www.ietf.org/rfc/rfc3424.txt. RFC 3424. Ford, Bryan, Srisuresh, Pyda y Kegel, Dan. 2005. Peer-to-Peer Communication Across Network Address Translators. [En lnea] 2005.

http://citeseer.ist.psu.edu/731089.html. Georgescu, Adrian. 2008. Best practices for SIP NAT traversal (Mejores Prcticas de Transversabilidad de NAT para SIP). AG Projects. [En lnea] AG Projects, 2008. http://mediaproxy.ag-projects.com/NATtraversalBestPractices.pdf. Handley, M, Jacobson, V y Perkins, C. 2006. SDP: Session Description Protocol. [En lnea] IETF, 2006. http://www.ietf.org/rfc/rfc4566.txt. RFC 4566. Hardy, William C. 2003. VoIP Service Quality. Measuring and Evaluating PacketSwitched Voice (Calidad de servicios VoIP. Midiendo y Evaluando la Voz en Paquetes Conmutados). s.l. : McGraw-Hill, 2003.

International Engineering Consortium. 2007. Fundamentals of Telecommunications (Fundamentos de las Telecomunicaciones). [En lnea] 2007.

http://www.iec.org/online/tutorials/fund_telecom/index.html. Niccolini, Saveiro. 2005. Security in IP Telephony: selected topics (Seguridad en Telefona IP: tpicos seleccionados). Heidelberg, Germany : NEC Europe Ltd., 2005. Poikselka, Miikka, y otros. 2004. The IMS. IP Multimedia Concepts and Services in the Mobile Domain (El IMS. Conceptos y Servicios de Multimedios IP en el Dominio Mvil). s.l. : John Wiley & Sons, Ltd, 2004. Rekhter, Y., y otros. 1996. Address Allocation for Private Internets (Asignacin de Direcciones para Redes IP Privadas). [En lnea] IETF, 1996.

http://www.ietf.org/rfc/rfc1918.txt. RFC 1918. Rosenberg, J. 2007. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. [En lnea] 2007. http://www.ietf.org/id/draft-ietf-mmusic-ice-18.txt. . 2007. SIP NAT Traversal (Traversabilidad de NAT para SIP). [Digital/MP3] s.l. : Blue Box: The VoIP Security Podcast, 2007. Rosenberg, J. y Schulzrinne, H. 2003. An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing. [En lnea] IETF, 2003.

http://www.ietf.org/rfc/rfc3581.txt. RFC 3581. . 2002. Session Initiation Protocol (SIP): Locating SIP Servers. [En lnea] IETF, 2002. http://www.ietf.org/rfc/rfc3263.txt. RFC 3263. Rosenberg, J., Huitema, C. y Mahy, R. 2003. STUN - Simple Traversal of User Datagram Protocol (UDP) Through Netwok Address Translators (NAT) (STUN Traversabilidad simple de UDP a travs de NAT). [En lnea] IETF, 2003. http://www.ietf.org/rfc/rfc3489.txt. RFC 3489.

Rosenberg, J., Mahy, R. y Huitema, C. 2005. Traversal Using Relay NAT (TURN) (Traversabilidad de NAT utilizando Retransmisin). [En lnea] IETF, 2005. http://tools.ietf.org/id/draft-rosenberg-midcom-turn-07.txt. Rosenberg, J., y otros. 2007. Session Traversal Utilities for NAT (STUN). [En lnea] IETF, 2007. http://tools.ietf.org/id/draft-ietf-behave-rfc3489bis-09.txt. Rosenberg, J., y otros. 2002. SIP: Session Initiation Protocol (Protocolo de Iniciacin de Sesin). [En lnea] IETF, 2002. http://www.ietf.org/rfc/rfc3261.txt. RFC 3261. Schulzrinne, H., y otros. 2003. RTP: A Transport Protocol for Real-Time Applications (RTP: Un protocolo de transporte para aplicaciones de tiempo real). [En lnea] IETF, 2003. http://www.ietf.org/rfc/tfc3550.txt. RFC 3550. Sinnreich, Henry y Johnston, Alan. 2001. Internet Communications Using SIP Delivering VoIP and Multimedia Services with Session Initiation Protocol (Comunicaciones de Internet utilizando VoIP y Servicios Multimedia con el Protocolo de Iniciacin de Sesin). s.l. : John Wiley and Sons Inc., 2001. Srisuresh, P. y Holdrege, M. 1999. IP Network Translator (NAT) Terminology and Considerations (Traductor de Red IP (NAT) Terminologa y Consideraciones). [En lnea] IETF, 1999. http://www.ietf.org/rfc/rfc2663.txt. RFC 2663. Thernelius, Fredrik. 2000. SIP, NAT, and Firewalls (SIP, NAT, y Firewalls). s.l. : Tesis M.S. Kungl Tekniska Hogskolan, 2000. Zhang, ChenXin. 2003. SIP and Application Internetworking (SIP y Redes IP de Aplicacin). s.l. : Helsinki University of Tehcnology - Telecommunication Software and Multimedia Lab, 2003.

ANEXOS

118

119