Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
DISEÑO E IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTERCONEXIÓN DE REDES NGN
MEDIANTE EL PROTOCOLO SIP
ING. WILLIAM FERNANDO SANCHEZ PACHECO
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
BOGOTÁ D.C.
MAYO DE 2013
2
DISEÑO E IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTERCONEXIÓN DE REDES NGN
MEDIANTE EL PROTOCOLO SIP
ING. WILLIAM FERNANDO SANCHEZ PACHECO
Trabajo de profundización para optar por el título de
Magister en Ingeniería Electrónica
Director:
LUIS CARLOS TRUJILLO ARBOLEDA
Ingeniero Electrónico, M.Sc.
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
BOGOTÁ D.C.
MAYO DE 2013
3
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
MAESTRÍA EN INGENIERIA ELECTRÓNICA
RECTOR MAGNÍFICO: P. JOAQUÍN SÁNCHEZ GARCÍA S. J.
DECANO ACADÉMICO: Ing. JORGE SANCHEZ, Ph.D.
DECANO DEL MEDIO UNIVERSITARIO: P. SERGIO BERNAL RESTREPO S. J.
DIRECTOR DE LA MAESTRÍA: Ing. CESAR LEONARDO NIÑO. PH.D.
DIRECTOR DEL TRABAJO DE GRADO: Ing. LUIS CARLOS TRUJILLO ARBOLEDA, MSc.
4
NOTA DE ACEPTACIÓN
Nota de aceptación
______________________
______________________
______________________
_____________________
Presidente del Jurado
_____________________
Jurado
_____________________
Jurado
Bogotá, Mayo de 2013
5
ARTÍCULO 23 DE LA RESOLUCIÓN No. 13 DE JUNIO DE 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de
grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque los
trabajos no contengan ataques o polémicas puramente personales. Antes bien, que se vea en ellos el
anhelo de buscar la verdad y la justicia”.
Artículo 23 de la Resolución No. 13, del 6 de julio de 1946,
por la cual se reglamenta lo concerniente a Tesis y Exámenes
de Grado en la Pontificia Universidad Javeriana.
6
DEDICATORIA
Agradezco a mi mamá, a mis hermanos
Y en general a toda mi familia que me
Apoyo en todo mí proceso de
Formación académica.
William Fernando Sánchez Pacheco
7
TABLA DE CONTENIDO
1. INTRODUCCION ......................................................................................................................... 14
2. MARCO TEORICO ....................................................................................................................... 16
2.1. REDES DE NUEVA GENERACION (NGN) ......................................................................... 16
2.1.1. Componentes de las redes NGN. ..................................................................................... 17
2.1.2. Características de las redes NGN ..................................................................................... 18
2.1.3. Servicios y aplicaciones de las redes NGN ...................................................................... 20
2.1.3.1. Servicios de las redes NGN ..................................................................................... 20
2.1.3.2. Aplicaciones de las redes NGN................................................................................ 21
2.1.4. Arquitectura de Softswitch/MGC .................................................................................... 21
2.1.5. Arquitectura IMS/MGC .................................................................................................. 23
2.2. PROTOCOLO SIP (SESSION INITIATION PROTOCOL) ................................................... 27
2.2.1. Componentes de SIP ....................................................................................................... 29
2.2.2. Mensajes de Petición ....................................................................................................... 30
2.2.2.1. Extensiones del Protocolo SIP ................................................................................. 31
2.2.2.2. Estructuras e mensajes. ............................................................................................ 32
2.2.3. Mensajes de Respuesta .................................................................................................... 32
2.2.4. Cabecera SIP .................................................................................................................. 34
2.2.5. Cuerpo de los mensajes SIP (protocolo de descripción de la sesión SDP) ........................ 36
2.3. PROBLEMAS GENERALES DE INTEROPERABILIDAD .................................................. 37
2.3.1. Problemas específicos de interconexión del protocolo SIP ............................................... 38
2.3.2. Problemas específicos de interconexión del protocolo SIP e SDP .................................... 39
3. ESPECIFICACIONES ................................................................................................................... 40
3.1 Red NGN ZTE-PUJ ............................................................................................................ 42
3.2 Red NGN ANKLA ............................................................................................................. 43
3.3 Infraestructura de Interconexión redes NGN´s. .................................................................... 44
3.3.1 Nodo Captura .............................................................................................................. 44
3.3.2 Generador de tráfico .................................................................................................... 46
3.3.3 Simulador trama SIP ................................................................................................... 47
3.3.3.4 Firewall ...................................................................................................................... 47
4 DESARROLLOS. .......................................................................................................................... 48
8
4.3 ANÁLISIS DEL PROTOCOLO SIP. ...................................................................................... 48
4.3.3 Análisis del protocolo SIP ZTE-PUJ ............................................................................... 48
4.3.4 Análisis del protocolo SIP ANKLA................................................................................. 54
4.3.5 Comparación de las dos redes NGN´s ............................................................................. 59
4.4 PRUEBAS DE INTEROPERABILIDAD ............................................................................... 59
4.4.3 Escenario de interoperabilidad ZTE-ANKLA .................................................................. 59
4.4.4 VPN y sus características de interoperabilidad. ................................................................ 65
4.4.4.4 VPN Sitio a Sitio utilizando NAT ................................................................................ 66
4.4.4.5 Seguridad VPN IPSec ................................................................................................. 66
4.4.4.6 Descripción de los Parámetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y ANKLA……………………………………………………………………………………………………………………………………67
4.5 METODOLOGÍA DE ANÁLISIS DE INTEROPERABILIDAD ............................................ 67
4.5.3 Identificación y reconocimiento ...................................................................................... 68
4.5.3.4 Llamada Simple Entre Dispositivos IP A Través De Troncal SIP ................................. 69
4.5.3.5 Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones ...................... 70
4.6 INTEGRACIÓN GENERADOR DE TRÁFICO, NODO CAPTURA Y EMULADOR DE TRAMA SIP ...................................................................................................................................... 71
4.6.3 Integración Nodo Captura y Generador de Tráfico .......................................................... 71
4.6.4 Emulación de la trama SIP y Nodo Captura. .................................................................... 72
5 ANALISIS DE RESULTADOS ..................................................................................................... 73
5.3 CARACTERIZACION NODO CAPTURA ............................................................................ 73
5.3.3 Descripción del funcionamiento Nodo Captura ................................................................ 73
5.3.4 Características del hardware Nodo Captura ..................................................................... 74
5.3.5 Análisis Nodo Captura .................................................................................................... 74
5.3.6 Emulación Trama SIP para el Comportamiento del Nodo Captura. .................................. 76
5.3.6.4 SIP campo y longitudes mensaje Proxy SIP. ................................................................ 77
5.3.6.5 Parámetros TEL-URI .................................................................................................. 77
5.3.6.6 Invite –Reinvite (Subscribe) ........................................................................................ 77
5.3.6.7 Valor De Cabecera PRACK ........................................................................................ 78
5.4 NODO CAPTURA PLATAFORMA AVAYA ....................................................................... 78
5.5 MEDICIONES DE QOS ........................................................................................................ 79
6 CONCLUSIONES ......................................................................................................................... 81
7 BIBLIOGRAFIA ........................................................................................................................... 83
9
8 ANEXOS ....................................................................................................................................... 85
ACRONIMOS ....................................................................................................................................... 86
10
LISTA DE FIGURAS
Figura 2-1. Evolución de la Red Clásica a la NGN – Simplificación de la torre de Protocolos…………..17
Figura 2-2. Arquitectura de las redes de nueva generación (NGN)………………………………………..18
Figura 2-3. Separación de los servicios y el transporte en redes NGN…………………………………….18
Figura 2-4. Red NGN con arquitectura Softswitch…………………………………………………….......23
Figura 2-5. Arquitectura de redes y servicios IMS………………………………………………………...24
Figura 2-6. Vista general de la arquitectura IMS…………………………………………………………..26
Figura 2-7. Posición de SIP dentro de la pila de protocolos……………………………………………….28
Figura 2-8. Flujo de mensajes de una Sesión SIP………………………………………………………….28
Figura 2-9. Flujo de mensajes de una Sesión SIP con un analizador de protocolos……………………….29
Figura 2-10. Cliente SIP y Componentes del Sistema del Servidor……………………………………….29
Figura 3-1. Protocolos de la red NGN…………………………………………………………………..…41
Figura 3-2. Arquitectura básica de interconexión las diferentes redes NGN´s……………………………41
Figura 3-3. Arquitectura Red NGN ZTE-PUJ…...…………………………………………………….......42
Figura 3-4. Arquitectura ANKLA………………………………………………………………………….44
Figura 3-5. Arquitectura Nodo Captura…………………………………………………………………....45
Figura 4-1. Comunicación básica del protocolo SIP de la red NGN ZTE-PUJ …………………………...49
Figura 4-2. Comunicación básica del protocolo SIP de la red NGN ANKLA………………………...…..54
Figura 4-3. Estructura de un servidor Proxy SIP………………………………………………………......61
Figura 4-4. Estructura de mensajes SIP con un servidor Proxy SIP………………………………………62
Figura 4-5. Arquitectura PROXY de interconexión las diferentes redes NGN´s de estudio………………63
Figura 4-6. Llamada saliente: Mensaje INVITE + SDP con timbrado local……………………………...64
11
Figura 4-7. Llamada saliente: Mensaje INVITE + SDP con conexión temprana de media……………....64
Figura 4-8. Diagrama básico de la VPN las diferentes redes NGN´s………………………………….......65
Figura 4-9. Diagrama básico de NAT las diferentes redes NGN´s………………………………………...66
Figura 4-10. Configuración VPN de la Red NGN ZTE-PUJ y la red NGN ANKLA……………………68
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexión de usuarios las diferentes redes
NGN´s……………………………………………………………………………………………………...69
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexión de diferentes componentes de redes
NGN´s……………………………………………………………………………………………………...70
Figura 4-13. Generador de tráfico SIP a través de la troncal SIP de dos redes NGN……………………72
Figura 4-14. Emulador de tráfico SIP……………………………………………………………………...72
Figura 5-1. Generación de tráfico SIP las diferentes redes NGN´s………………………………………..75
Figura 5-2. Traza de una de las pruebas de interconexión de búsqueda de llamada se sesión de las
diferentes NGN´s…………………………………………………………………………………………..75
Figura 5-3. Diagrama de secuencia de la señalización SIP de una llamada de Softswitch Vs
Softswitch………………………………………………………………………………………………….76
Figura 5-4. Captura de traza de la señalización SIP de una llamada de Softswitch Vs Softswitch……76
12
LISTA DE TABLAS
Tabla 2-1. Categorías de Respuesta SIP…………………………………………………………………...33
Tabla 2-2. Código de Respuesta SIP……………………………………………………………………….34
Tabla 2-3. Elementos de la Cabecera SIP………………………………………………………………....35
Tabla 2-4. Abreviaturas de Nombre de Cabecera………………………………………………………….35
Tabla 2-5. Atributos de SDP…………………………………………………………………………….....36
Tabla 5-1. Mediciones de QoS para llamadas telefónicas IP (Protocolo SIP)…………………………..…79
13
ANEXOS
Anexo 1. Señalización SIP en diversos escenarios.
Anexo 2. Código fuente NODO CAPTURA.
Anexo 3. Archivos generados para medir QoS.
Anexo 4. Manual de instalación NODOD CAPTURA.
Anexo 5. Manual de instalación Generador de Tráfico.
Anexo 6. Documentación de interconexión redes NGN´s.
Anexo 7. Emulaciones Trama SIP.
14
1. INTRODUCCION
En el contexto actual y mundial del sector de las telecomunicaciones, la voz y los datos como redes
independientes, han dejado de ser la fuente de ingresos más importante para la gran mayoría de operadores
y fabricantes; es por ello que ha surgido la necesidad de aumentar e innovar en el portafolio de servicios
que estos ofrecen.
Con la aparición de una nueva generación de arquitecturas de red (todo IP), emerge también un nuevo
portafolio de servicios, en los que se mezclan voz y datos; estar a la vanguardia de esta nueva generación
de redes (NGN1), se convierte en un factor determinante de competitividad para los diferentes actores del
sector de las Telecomunicaciones y las Tecnologías de Información.
Al ser un mercado creciente encontramos múltiples operadores y fabricantes, que deben experimentar un
proceso de interconexión de elementos de red NGN, a través de distintos protocolos y además con otras
redes NGN, (alianza estratégica entre operadores y fabricantes) este escenario les origina numerosos
problemas de interconexión de equipos de red NGN por el protocolo SIP.
Las NGN al ser independiente la capa de control de la capa de transporte, aportan muchas ventajas a
aplicaciones sensibles a retardos como pueden ser IPTV, VoIP. La ETSI2 en su comité TISPAN3 ha
seleccionado el protocolo SIP (Protocolo de Inicio de Sesión), para la señalización en las redes NGN.
El protocolo SIP, es el que permite establecer, modificar y terminar “sesiones multimedia”; al ser el
protocolo determinado para la señalización de las redes NGN´s, el problema está en que los diferentes
fabricantes de redes de Nueva Generación implementan el protocolo SIP para la señalización de sus redes,
pero cada uno lo implementa con alguna restricción o parámetro adicional, esto se hace debido a la
flexibilidad que tiene el RF3261 para no permitir la integración de partes de diferentes fabricantes, esto
obliga a interactuar con su solo proveedor para la totalidad de la integración de la red.
En este trabajo de grado diseña e implementa una solución de interconexión de dos redes NGN (Centro de
Tecnologías de Telecomunicaciones ZTE-PUJ “Pontificia Universidad Javeriana” y el Laboratorio
1 Redes de Nueva Generación
2 Instituto Europeo de Normas de Telecomunicaciones
3 Telecomunicaciones e Internet Servicios convergentes y protocolos de red avanzada
15
ANKLA). El desarrollo se basó en cuatro partes (la interconexión de las redes NGN´s mediante una
conexión de internet VPN, un nodo captura que realiza el escucha de toda la señalización SIP, una
verificación de su estructura y por último se emplea un generador de trafico de VoIP para ver generar
grandes flujos de señalización con el protocolo SIP).
El objetivo general de este proyecto es; “Diseñar e implementar una solución de interconexión de redes
NGN mediante el protocolo SIP”, para este fin se cumplieron los siguientes objetivos específicos:
• Estudiar y analizar los parámetros del protocolo SIP en la interconexión redes NGN ZTE-PUJ y
ANKLA.
• Definir e Implementar un módulo basado en el protocolo SIP (software) que permita la
interconexión de redes NGN ZTE-PUJ y ANKLA.
• Evaluar la funcionalidad y el desempeño del módulo (software) del protocolo SIP, a través de las
pruebas de operatividad de las redes NGN ZTE-PUJ y ANKLA.
El documento se organiza de la siguiente forma: en el MARCO TEÓRICO, numeral 2, se describe de
manera general las redes NGN y el protocolo SIP. En las ESPECIFICACIONES, numeral 3, se describe
de forma general el desarrollo de la interconexión de las dos redes ZTE-PUJ y ANKLA y se referencia la
descripción de cada una de las redes NGN. En los DESARROLLOS, numeral 4, se explica cómo se
analizó el protocolo SIP en cada una de las redes NGN y como se implementó la interconexión para
posteriormente realizar la verificación, validación de la interconexión. En el numeral 5, se muestran los
resultados obtenidos, y en el numeral 6 se concluye acerca de la puesta en marca de la interconexión y el
buen funcionamiento de la misma.
16
2. MARCO TEORICO
En el marco teórico se hace un recuento de las diferentes arquitecturas y protocolos de comunicación que
son necesarios para entender el contexto de interconexión de redes NGN.
2.1. REDES DE NUEVA GENERACION (NGN)
En Colombia se ha iniciado la migración de la infraestructura de las redes de los operadores de
telecomunicaciones, para ofrecer los servicios de voz y datos bajo una infraestructura unificada sobre el
protocolo de Internet (Internet Protocol, IP). [4].
El Protocolo Internet (IP) que proporciona una plataforma común para todos los servicios de TIC, está
desvaneciendo al mismo tiempo el concepto de la denominada “larga distancia”. La figura 2-1 muestra lo
que ha ido sucediendo en los sectores de telecomunicaciones y audiovisual, donde por efecto de la
convergencia de servicios, redes, industria y dispositivos las redes que antes eran separados, se consolidan
ahora alrededor de una sola plataforma de acceso, obviando la multiplicidad de redes característica del
siglo pasado. El usuario ahora no tiene conciencia de las redes que le proporcionan los servicios
convergentes y en ocasiones lo único que percibe es si el medio de acceso es fijo o inalámbrico. Lo que
hace dos décadas se intentó conseguir con éxito muy limitado mediante la Red Digital de Servicios
Integrados (RDSI), es decir, múltiples servicios a través de un solo punto de acceso, está siendo
materializado hoy en día por las redes de nueva (o próxima) generación (“Next Generation Networks” o
NGNs por sus siglas en inglés) con núcleo IP (Internet Protocol).
La definición de la UIT para NGN es: “Red basada en paquetes que permite prestar servicios de
telecomunicación y en la que se pueden utilizar múltiples tecnologías de transporte de Banda Ancha
propiciadas por la QoS, y en la que las funciones relacionadas con los servicios son independientes de las
tecnologías subyacentes relacionadas con el transporte. Permite a los usuarios el acceso sin trabas a
redes y a proveedores de servicios y/o servicios de su elección. Se soporta movilidad generalizada que
permitirá la prestación coherente y ubicua de servicios a los usuarios.” [15].
17
Figura 2-1. Evolución de la Red Clásica a la NGN – Simplificación de la torre de Protocolos4
2.1.1. Componentes de las redes NGN.
Una red NGN consta de cuatro niveles que dan flexibilidad y escalabilidad a la red, cada nivel se conecta
mediante interfaces abiertas que permiten la interconexión e integración de nuevos servicios. Estos cuatro
niveles son los siguientes [4]:
• Servicios: Esta interfaz es la encargada de la conexión “lógica” con los usuarios.
• Control: Interfaz intermedia que permite la comunicación entre los niveles de servicio y de
transporte (Softswitch e IMS).
• Transporte: ofrece la conectividad y de calidad de servicio requeridos por los servicios.
• Acceso: Cualquier acceso de banda ancha para hacer llegar al usuario las aplicaciones solicitadas.
La tecnología usada puede ser en cable (fibra o cobre) o inalámbrica.
4 Tomado de Diseño de políticas óptimas en un entorno de convergencia de los medios de comunicación y las telecomunicaciones
“OSIPTEL”
18
Figura 2-2. Arquitectura de las redes de nueva generación (NGN)5
2.1.2. Características de las redes NGN
El factor diferenciador de las redes NGN´s es la separación entre la capa de transporte y la capa de
servicios que ofrece, de modo que los servicios se puedan ofrecer por separado y evolucionar
independientemente de la capa de transporte como se muestra en la siguiente figura.
Figura 2-3. Separación de los servicios y el transporte en redes NGN6
5 Tomado de Telefónica, 2006 6 Tomado de UIT Y.2011
19
En primer lugar, hay un conjunto de funciones de transporte que se encargan únicamente del transporte de
la información digital de cualquier tipo entre dos puntos físicamente separados. El transporte puede estar
formado por un conjunto complejo de redes, que constituyen las capas 1 a 3 en el modelo de referencia
básico OSI de 7 capas. Las funciones de transporte proporcionan la conectividad.
En particular, las funciones de transporte son:
• Conectividad entre usuarios;
• Conectividad entre el usuario y la plataforma de servicios;
• Conectividad entre plataformas de servicio.
Las plataformas de servicios proporcionan los servicios de usuario, por ejemplo, el servicio de telefonía,
servicio web, etc. Los servicios pueden estar formados por un conjunto complejo de plataformas de
servicios físicamente distribuidos, o, en el caso más sencillo, únicamente las funciones de servicio entre
dos ubicaciones de usuarios extremo.
En segundo lugar existe un conjunto de funciones de aplicación relacionadas con el servicio solicitado.
Los servicios pueden ser, por ejemplo, servicios de voz (incluido el servicio de telefonía), servicios de
datos (no limitándose éste a los servicios basados en la web), o servicios de vídeo (no limitándose
tampoco a las películas y a los programas de televisión), o una combinación de éstos (por ejemplo,
servicios multimedia, como la telefonía vídeo y los juegos).
Dado que existen muchas maneras de clasificar los servicios (por ejemplo, servicios en tiempo real/no en
tiempo real y servicios unidifusión/multidifusión/radiodifusión), en la figura 2-1 se proporciona un
ejemplo de lista de servicios (voz, datos y videos) que se prevé ofrecerán las redes de próxima generación
[15].
Actualmente las arquitecturas funcionales de las redes NGN implementadas son::
• SOFTSWITCH/MGC: También es conocido como Call Agent o Media Gateway Controller
(MGC). Es el mecanismo que provee el “control de provisión de servicio” en la red. Está a cargo
del Control de llamadas, maneja el control de las Pasarelas de Medio (Acceso y/o Enlace) vía
protocolo H.248. Realiza la función de una pasarela de señalización o usa una pasarela de
señalización para trabajar conjuntamente con la red de señalización PSTN N7. Provee conexión a
los servidores de Red inteligente/aplicaciones para proveer los mismos servicios que los
disponibles para los abonados TDM.
20
• IMS/MGC: La arquitectura genérica de IMS (IP Multimedia Subsystem) soporta la comunicación
entre equipos que utilizan SIP para la señalización y la administración de sesiones, además de los
protocolos ‘Diameter’ y Megaco/H.248’ para operaciones y manejo de recursos multimedia
respectivamente. Parte fundamental de la arquitectura IMS está compuesta por los servidores de
aplicación, quienes se encargan de: invocar los servicios, identificar qué señalización es requerida
y de qué forma los servicios interactúan ente sí.
2.1.3. Servicios y aplicaciones de las redes NGN
Las redes NGN pueden proveer gran cantidad de servicios y aplicaciones de forma individual o en
conjunto por tal motivo se realizará una descripción de cada uno de servicios y aplicaciones de redes
NGN.
2.1.3.1. Servicios de las redes NGN
Los servicios de las redes NGN se explican a continuación:
• Telefonía: NGN soporta la necesidad varios servicios de telefonía existentes (ej, Llamada en
espera, llamada tripartita, reenvío de llamadas, reloj despertador, identificador de llamadas, etc.)
• Servicios de datos: Permite el establecimiento de la conectividad en tiempo real entre varios
dispositivos finales, con varias características de valor agregado.
• Servicios multimedia: Permite que los usuarios interactúen utilizando voz, video y/o datos.
• Virtual Private Networks (VPNs): Mejora las capacidades de las empresas al permitir una
cobertura amplia, geográficamente dispersa, al combinar las redes privadas existentes con
porciones de la red pública.
• Computación pública en la red: Provee servicios públicos en la red para negocios y
consumidores.
• Mensajería unificada: Soporta la entrega de mensajes de voz, correo electrónico, fax y
mensajería instantánea a través de interfaces comunes.
• Comercio electrónico: Permite a los consumidores la compra de bienes y servicios sobre la red.
Servicios para empresas y compras desde el hogar pertenecen a esta categoría de servicios.
• Servicios de Call Center: Un suscriptor puede realizar una llamada a un centro de contacto para
la adquisición de nuevos productos o realizar consultas.
• Juegos interactivos: Ofrece a los consumidores una forma para conocer y establecer sesiones de
juegos interactivos en línea.
21
• Realidad Virtual Distribuida: Se refiere a la tecnología que genera representaciones de los
eventos del mundo real, personas, lugares, experiencias, etc.
• Domótica: Con la llegada los electrodomésticos inteligentes y de las redes al hogar, estas
aplicaciones pueden monitorear y controlar los sistemas de entretenimiento caseros y otros
aparatos electrodomésticos.
• Consultoría: Involucra la publicidad, para proveer información que permita generar un punto de
contacto entre proveedores y consumidores.
2.1.3.2. Aplicaciones de las redes NGN
Las aplicaciones de las redes NGN se enuncian a continuación:
• VoIP.
• Web Browsing.
• Chat.
• Mensajería Instantanea.
• WAP Browsing.
• Mensajería Multimedia.
• Video llamadas.
• Video Broadcasting.
• Video conferencia.
• IP PBX/Centrex.
• Email.
• Video por demanda (Peliculas, Juegos, Noticia, Deportes, Entrenamiento).
2.1.4. Arquitectura de Softswitch/MGC
Esta es una arquitectura muy significativa dentro de la estructura general de una NGN, ya que con esta
infraestructura de red hace posible el concepto de red de próxima generación.
“Es un dispositivo que provee control de llamada y servicios inteligentes para redes de conmutación de
paquetes. Un Softswitch sirve como plataforma de integración para aplicaciones e intercambio de
servicios. El Softswitch es capaz de transportar tráfico de voz, datos y vídeo de una manera más eficiente
22
que los equipos existentes, habilita al proveedor de servicio para soportar nuevas aplicaciones multimedia
integrando las existentes con las redes inalámbricas avanzadas para servicios de voz y Datos.”7
Un Gateway Controller combinado con el media Gateway y el Signalling Gateway representan la mínima
configuración de un Softswitch. El elemento controlador es frecuentemente conocido como Media
Gateway Controller (MGC). A continuación se describen los componentes de un Softswitch.
• GATEWAY CONTROLLER: Es la unidad funcional del Softswitch. Mantiene las normas para el
procesamiento de llamadas, por medio del Media Gateway y el Signalling Gateway los cuales
ayudan a mejorar su operatividad. El responsable de ejecutar el establecimiento y desconexión de
la llamada del Signalling Gateway. Frecuentemente esta unidad es referida como Call Agent o
Media Gateway Controller. Algunas veces el Call Agent es referido como el centro operativo del
Softswitch. Este componente se comunica con las otras partes del Softswitch y componentes
externos usando diferentes protocolos.
• SIGNALLING GATEWAY: Sirve como puente entre la red de señalización SS7 y los nodos
manejados por el Softswitch en la red IP.
• MEDIA GATEWAY: Actualmente soporta Multiplexación por división de tiempo (TDM) para
transporte de paquetes de voz al switch. Las aplicaciones de Codificación de voz, Decodificación
y compresión son soportadas, así como las interfaces de la Red telefónica pública (PSTN) y los
protocolos CAS e ISDN.
• MEDIA SERVER: Mejora las características funcionales del Softswitch, si es requerido soporta
Procesamiento Digital de Señales (DSP) así como la funcionalidad de la Respuesta de voz
interactiva (IVR).
• FEATURE SERVER: Controla los datos para la generación de la facturación, usa los recursos y
los servicios localizados en los componentes del Softswitch.
• SERVICES TARGETED: realiza funciones como traslación de direcciones, enrutamiento, IVR,
emergencia, llamadas en espera entre otras.
7 Tomado de RIOS, Javier y GARCIA, Moraima, Softswitch, febrero 2004
23
• SERVICE INTERFACE: Proporciona soporte para servicios suplementarios y clases de
servicios. Posee una arquitectura independiente de señalización, soporta protocolos como SIP,
H.323, SS7 e ISDN.
Un Softswitch puede contener uno o más componentes, sus funciones pueden residir en un sistema o
expandirse a través de varios sistemas como se muestra en la figura 2-4.
Figura 2-4. Red NGN con arquitectura Softswitch
2.1.5. Arquitectura IMS/MGC
La arquitectura genérica del IMS fue creada por 3GPP8 soporta la comunicación entre equipos que utilizan
SIP para la señalización y la administración de sesiones, además de los protocolos SIP, SDP,
DIAMETER, RTP, RTCP, RSVP y DiffServ, para operaciones y manejo de recursos multimedia
respectivamente. Parte fundamental de la arquitectura IMS está compuesta por los servidores de
aplicación, quienes se encargan de: invocar los servicios, identificar qué señalización es requerida y de
qué forma los servicios interactúan ente sí.
La arquitectura de NGN IMS/MGC suministra acceso a cualquier servicio sin importar el tipo de medio,
usa el plano de control común y trabaja para cualquier tipo de medio, existe un único plano de control para
voz, datos, video y cualquier otro tipo de servicio que requiera el usuario, el plano de control de IMS no
8 3rd Generation Partnership Project es una colaboración de grupos de asociaciones de telecomunicaciones.
24
necesita ninguna modificación, ni ninguna nueva tecnología para un nuevo tipo de medio y todo es
controlado por un protocolo de control de sesiones SIP.
En la siguiente figura se encuentra una red NGN con arquitectura IMS.
Figura 2-5. Arquitectura de redes y servicios IMS9
Call Session Control Function (CSCF)
Esta entidad agrupa tres elementos que son el serving (CSCF), proxy (CSCF), y el interrogating (CSCF).
El elemento Serving CSCF administra las sesiones SIP y coordina con otros elementos de la red el control de las llamadas/sesiones. El S-CSCF es responsable por las siguientes funciones:
• Registro SIP – procesa solicitudes de registro SIP (SIP REG de datos y condición de suscriptores
durante la duración de la sesión de registro;
• Control de la Sesión – ejecuta el establecimiento de la llamada/sesión, modificación y
terminación;
• Control de Servicio – interactúa con los Servidores de Aplicación (Application Server) para el
soporte de servicios y aplicaciones;
• Monitoreo de la llamada y generación de registros de tarifación;
• Provee seguridad para la sesión.
9 Tomado de www.3gpp.org/
25
El Proxy CSCF es el primer contacto para que un móvil SIP obtenga acceso a la red IMS a partir de una
red orientada a paquetes. El elemento P-CSCF:
• Provee el enrutamiento SIP entre los móviles SIP y la red IMS;
• Ejecuta una política de control definida por la operadora de la red;
• Coordina con la red de acceso, el control de recursos y calidad de las llamadas/sesiones (QoS);
• Adicionalmente, los operadores pueden ofrecer localmente servicios controlados por el PCSCF.
Para los servicios ofrecidos por la red IMS de origen (Home Network ), el PCSCF revisa la
señalización SIP para el servidor IMS en la red de origen.
El Interrogating-CSCF es el punto de contacto entre la red IMS y todas sus conexiones. Pueden existir
múltiplos I-CSCF en una red. Las funciones ejecutadas por el I-CSCF son:
• Designar un S-CSCF para un usuario ejecutando un registro SIP;
• Enrutar una petición SIP recibida de otra red en dirección al S-CSCF;
• Obtener del HSS (Home Subscriber Subsystem) la dirección del S-CSCF;
• Enrutar una petición SIP o respuesta para la designación óptima del MGW (Home Control of
roamers).
• Enviar peticiones/respuestas SIP al I-CSCF en una red de otro operador para designación óptima
de un Media Gateway (MGW), para terminación de una llamada en la red pública conmutada
(STFC).
• BREAKOUT GATEWAY CONTROL FUNCTION (BGCF): El BGCF selecciona la red en la
cual el acceso a la red pública conmutada (STFC) debe ocurrir. Si el BGCF determina que el
acceso va a ocurrir en la misma red en donde el BGCF está localizado, entonces el BGCF
selecciona un MGCF. El MGCF será responsable por la interoperabilidad con la red STFC. Si el
punto de acceso está en otra red, el BGCF enviará la señalización de esta sesión a un BGCF o
MGCF (dependiendo de la configuración) en la otra red. El objetivo final es minimizar el
recorrido de la llamada/sesión.
• MEDIA GATEWAY CONTROL FUNCTION (MGCF): El MGCF provee la función de
interoperabilidad de la señalización entre los elementos de la red IMS y las redes legadas (STFC).
El MGCF controla un conjunto de MGWs a través de la señalización H.248. La señalización
H.248 permite el establecimiento de recorridos para las sesiones que necesitan
interfuncionamiento (bajo la perspectiva de tráfico) entre la STFC y la red IMS.
26
• MULTIMEDIA RESOURCE FUNCTION CONTROLLER (MRFC): El MFRC controla los
recursos de media del elemento Función de Recursos Multimedia Procesador (MRFP). Por
ejemplo, recursos necesarios para proveer tonos, anuncios y conferencia.
• SIGNALING GATEWAY: Provee la conversión de señalización en ambas direcciones en la capa
de transporte entre SS7 y señalización basada en IP (por ejemplo ISUP/SS7 e ISUP/SCTP/IP).
• POLICY DECISION FUNCTION (PDF): PDF es la función lógica que implementa la decisión
en relación a la política a ser aplicada, y hace uso de mecanismos de QoS en la capa de
conectividad IP.
• HOME SUBSCRIBER SERVER (HSS): El HSS contiene la principal base de datos, con los
datos de todos los usuarios (incluyendo servicios autorizados), el cual varias entidades lógicas de
control (CSCF) acceden a los suscriptores. El HSS contiene los datos del usuario, que son pasados
al S-CSCF, y almacena la información temporaria con la localización del S-CSCF donde el
usuario está registrado en un dado momento.
Figura 2-6. Vista general de la arquitectura IMS10
10
Tomado de www.3gpp.org
27
2.2. PROTOCOLO SIP (SESSION INITIATION PROTOCOL)
SIP es un protocolo especificado por la IETF en el RFC 3261[10], además es aceptado como un protocolo
estándar por la organización 3GPP y forma parte de la arquitectura de NGN “Redes de Nueva
Generación”. Además SIP es usado globalmente como protocolo de señalización para VoIP.
Este protocolo se ubica en la capa aplicación y permite a las terminales IP establecer, en rutar, modificar y
cerrar sesiones de comunicaciones a través de redes IP; SIP por sí mismo no garantiza ni reserva ancho de
banda para la sesión ni provee calidad servicio (QoS) y no define un mecanismo de entrega de los
paquetes que transportan la información de la sesión. SIP está diseñado para trabajar independientemente
de la capa de transporte, puede ser transportado sobre TCP o UDP.
Utiliza el modelo de Internet ocupando ciertas funcionalidades de protocolos de Internet existentes tales
como HTTP (Hyper Text Transport Protocol) y SMTP (Simple Mail Transfer Protocol).
SIP se basa en el modelo cliente/servidor como HTTP. Para el direccionamiento utiliza el concepto
“Uniform Resource Locutor “o “URL SIP” que es similar a una dirección E-mail. Usa estas direcciones de
tipo correo electrónico para identificar a los usuarios en lugar de los dispositivos que los utilizan, de esta
manera cada participante en una red SIP es reconocido por una dirección, es decir por medio de una URL
SIP; logrando la independencia del dispositivo, y sin hacer distinción alguna entre voz y datos, teléfono u
ordenador.
Para permitir establecer una sesión entre dos terminales, SIP provee cinco servicios de señalización:
• Localización de los terminales
• Invitación a la sesión
• Intercambio de información de media para establecer la sesión
• Modificación de sesiones existentes
• Terminación de sesiones
Como ya se dijo SIP es un protocolo presente en la capa de aplicación diseñado de forma vertical, es decir
que es hospedado sobre otros protocolos para poder establecer adecuadamente las sesiones de multimedia
y el a su vez contiene un protocolo para describir los parámetros de inicialización de los flujos multimedia
SDP (protocolo de descripción de sesión).
28
Figura 2-7. Posición de SIP dentro de la pila de protocolos [1].
El protocolo SIP únicamente se utiliza para la señalización y no reserva recursos, y en consecuencia, no
puede asegurar la calidad de servicio. Una vez que la sesión esté establecida, los participantes
intercambian directamente su tráfico audio/video a través del protocolo Real-Time Transport Protocol
(RTP).
En las figuras 2-8 y 2-9 se explica de manera sencilla cómo se lleva a cabo una sesión SIP entre dos
usuarios y se representan las funciones básicas de SIP: localización del terminal, señal de la intención de
un usuario de comunicarse, negociación de los parámetros de la sesión a establecerse y terminación de la
sesión una vez establecida.
Figura 2-8. Flujo de mensajes de una Sesión SIP [10].
29
Figura 2-9. Flujo de mensajes de una Sesión SIP con un analizador de protocolos.
De esta manera SIP por medio de mensajes de petición y de respuesta provee la señalización necesaria
para el establecimiento y terminación de la llamada.
2.2.1. Componentes de SIP
SIP define los componentes que se muestra en la siguiente figura:
Figura 2-10. Cliente SIP y Componentes del Sistema del Servidor [2].
El Servidor Proxy (Proxy Server): este servidor recibe solicitudes de clientes que son resueltas por el
mismo servidor o las enruta hacia otros servidores. Los servidores Proxy SIP pueden tener un
reconocimiento local de los agentes de usuario desde un registrador SIP. Además pueden conocer varias
30
alternativas para localizar a un agente de usuario, y pueden intentar cada una de ellas en un proceso de
bifurcación que puede ser paralelo o secuencial.
El Servidor de Re direccionamiento (Redirect Server): este servidor acepta solicitudes SIP, traduce la
dirección SIP de destino en una o varias direcciones de red y las devuelve al cliente. De manera contraria
al ProxyServer, el Redirect Server no encamina las solicitudes SIP.
En el caso de la devolución de una llamada, el Proxy Server tiene la capacidad de traducir el número del
destinatario recibido en el mensaje SIP, a un número de reenvió de llamada y encaminar la llamada a este
nuevo destino, y eso de manera transparente para el cliente de origen; para el mismo servicio, el Redirect
Server devuelve el nuevo número de reenvió al cliente de origen quien se encarga de establecer una
llamada hacia este nuevo destino.
El Agente Usuario (UserAgent) o “UA”: se trata de una aplicación sobre un equipo de usuario que emite
y recibe solicitudes SIP. Se materializa por un software instalado sobre un « UserEquipment » o UE (PC,
teléfono IP). Los Clientes de agentes del usuario (UAC) envían peticiones SIP a la parte llamante, y los
Servidores de agentes del usuario (UAS) reciben las respuestas de la parte llamada. Cada usuario puede
tener varios agentes del usuario y cada uno asociado a una dirección SIP.
El Registrador (Registrar): se trata de un servidor quien acepta las solicitudes SIP REGISTER. SIP
dispone de la función de registro de los usuarios. El usuario indica por un mensaje REGISTER emitido al
registrador, la dirección donde se lo puede localizar (dirección IP). El “registrador” actualiza la base de
datos de localización. El registrador es una función asociada a un Proxy Server o a un Redirect Server. Un
mismo usuario puede registrarse sobre distintas UAs SIP, en este caso, la llamada le será entregada sobre
el conjunto de estas UAs [10].
2.2.2. Mensajes de Petición
Métodos SIP
El RFC 3261[10] define seis solicitudes/requerimientos o métodos SIP.
• INVITE [RFC3261] usado para el establecimiento de una sesión entre UAs. Contiene
información sobre el que genera la llamada y el destinatario así como sobre el tipo de flujo que
será intercambiado (voz, video, etc.).
• ACK [RFC3261] confirma la recepción de una respuesta SIP.
31
• BYE [RFC3261] permite la liberación de una sesión anteriormente establecida. Puede ser emitido
por el que genera la llamada o el que la recibe.
• REGISTER [RFC3261] usado por una UA para indicar correspondencia entre su dirección SIP y
su dirección de contacto al registrarla.
• CANCEL [RFC3261] utilizado para cancelar una solicitud pendiente.
• OPTIONS [RFC3261] utilizado para consultar las capacidades y el estado de un User Agent o
de un servidor. La respuesta debe incluir los métodos SIP que soporta [10].
2.2.2.1. Extensiones del Protocolo SIP
• SUBSCRIBE [RFC3265] utilizado para requerir notificación de evento. Los clientes UA (User
Agent) solicitan actualizaciones de presencia/disponibilidad de otros usuarios a partir de un
registrador SIP, cuando el usuario cambia la información de registro.
• NOTIFY [RFC3265] utilizado para notificar un evento. Actualizaciones instantáneas desde un
registrador a un cliente UA acerca de los usuarios que han cambiado la información del registro.
Los clientes UA deben primero enviar un mensaje SUBSCRIBE para recibir las actualizaciones
NOTIFY sobre un usuario determinado.
• PUBLISH [RFC3903] permite publicar el estado.
• REFER [RFC3515] utilizado para reenviar el receptor hacia un recurso identificado en este
método, es decir una transferencia a otra URL.
• MESSAGE [RFC3428] permite la transferencia de mensajes instantáneos. La mensajería
instantánea “Instant Messaging” o “IM” consiste en el intercambio de mensajes entre usuarios en
seudo tiempo real.
• INFO [RFC2976] permite transferir informaciones de señalización durante la llamada (por
ejemplo: ISUP).
• PRACK [RFC3311] definido para realizar una recepción confiable de las respuestas temporales
de tipo 1XX.
• UPDATE [RFC3311] permite a un terminal SIP actualizar los parámetros de una sesión
multimedia (flujo media y codecs). El método UPDATE puede ser enviado antes de que la sesión
sea establecida.
32
2.2.2.2. Estructuras e mensajes.
Un mensaje SIP consta de las siguientes partes:
• Línea de inicio: indica el propósito del mensaje.
• Cuerpo: proporcionan detalles del mensaje.
Línea de inicio
Su formato depende si el mensaje se trata de una respuesta o una solicitud.
Solicitudes SIP
Las solicitudes SIP son enviadas por los clientes para comunicarse con los servidores.
El formato de línea de inicio de una solicitud es el siguiente:
<Método> <Solicitud-URI> <versión SIP>
<Método> Es uno de los tipos de solicitudes SIP
<Solicitud-URI> Es el URL SIP u otro tipo de URL de la entidad que debería recibir el mensaje.
<versión SIP> Es actualmente SIP/2.0
A continuación algunos ejemplos:
INVITE sip:[email protected] SIP/2.0
ACK sip:[email protected];user=phone SIP/2.0
BYE tel:+1-408-555-1212;postd=p4199 SIP/2.0
2.2.3. Mensajes de Respuesta
Después de haber recibido e interpretado un requerimiento SIP, el destinatario de este requerimiento
devuelve una respuesta SIP.
El formato de línea de inicio de una respuesta es el siguiente:
<VersiónSIP> <Código de estado> <Frase razón>
33
<VersiónSIP> actualmente es SIP/2.0
<Código de estado> y <Frase razón> se establecen a uno de los pares de los código de Respuesta SIP
A continuación algunos ejemplos:
SIP /2.0 404 Not Found
SIP /2.0 180 Ringing
SIP /2.0 200 OK
Las respuestas SIP versión 2 estándar están codificadas con tres dígitos de respuesta y una descripción
textual. Las respuestas se clasifican en seis categorías, identificadas por el primer dígito el cual identifica a
que categoría pertenece como se muestra en la siguiente tabla.
Tabla 2-1. Categorías de Respuesta SIP [1].
En la siguiente tabla se muestra la totalidad de los mensajes de respuesta de tres dígitos con su descripción
[10].
34
Tabla 2-2. Código de Respuesta SIP [1] [10].
2.2.4. Cabecera SIP
La cabecera SIP representa un valor variable que es transportado a través de la red. Algunas cabeceras SIP
son obligatorias en cada mensaje, y otras si utilizan dependiendo del tipo de solicitud o de respuesta.
El formato de las cabeceras SIP es el siguiente:
<Nombre cabecera>: <Valor cabecera>
<Continuación de valor de cabecera>
<Nombre cabecera> se los enumera en la tabla 3
<Valor cabecera> una o más líneas de información.
<Continuación de valor de cabecera> continuación de la cabecera multilínea.
CODIGO DESCRIPCIÓN DE LA RESPUESTA CODIGO DESCRIPCIÓN DE LA RESPUESTA
1XX INFORMACION 420 Extensión errónea
100 Intentando 421 Extensión requerida
180 Ringing 422 Sesión del temporizador de intervalos demasiado pequeño
181 La llamada está remitiéndose 423 Intervalo demasiado corto
182 En Cola 428 Utilice token de autenticación
183 Progreso de la sesión 429 Proporcionar identidad REFER
2XX SUCESOS 480 No disponible temporalmente
200 OK 481 Circuito de llamada o transacción no existe
202 Aceptado 482 Detectado un bucle
3XX REDIRECCION 483 Demasiados saltos
300 Opciones múltiples 484 Dirección incompleta
301 Movido permanentemente 485 Ambiguo
302 Movido temporal 486 Ocupado aquí
305 Utilizar proxy 487 Solicitud terminada
380 Servicio Alternativo 488 No aceptable aquí
4XX ERROR DEL CLIENTE 489 Terminación de evento
400 Respuesta mala 491 Solicitud pendiente
401 Sin autorizacion 493 Solicitar indescifrable
402 Pago requerido 5XX ERROR DEL SERVIDOR
403 Prohibido 500 Error al interior del servidor
404 No encontrado 501 No implementado
405 Método no permitido 502 Gateway erróneo
406 No aceptable 503 Servicio no disponible
407 Se requiete autenticación de Proxy 504 Límite de tiempo del gateway
408 Se requiere límite de tiempo 505 Versión de SIP no soportada
409 Conflicto 513 Mensaje demasiado grande
410 Hecho 6XX ERROR GLOBAL
411 Longitud requerida 600 Ocupado completamente
413 Entidad solicitada demasiado grande 603 Declinar
414 Solicitud-URI demasiado grande 604 No existe en ninguna parte
415 Tipo de medio no soportado 606 No aceptable
416 Esquema URI no soportado
35
A continuación algunos ejemplos:
From: sip:[email protected]
User-Agent: Cisco VoIP Gateway / IOS12.x / SIP enable
Content-Type: application / sdp
La siguiente tabla muestra las cabeceras SIP las mismas que se organizan en cuatro grupos lógicos, el
orden en el que se presentan estos grupos representan como deberían aparecer en los mensajes SIP, es
decir: cabeceras generales, cabeceras de solicitud, cabeceras de respuesta y cabeceras de entidad.
Tabla 2-3. Elementos de la Cabecera SIP [1] [10].
Abreviaturas del nombre de cabecera
Algunos nombres de las cabeceras SIP puede ser abreviados para evitar la fragmentación de paquetes y los
servidores SIP deben tener la facultad de interpretar los nombres de cabecera normales y abreviados.
En la tabla 2-4 se muestra los nombres de cabeceras que pueden ser abreviados.
Tabla 2-4. Abreviaturas de Nombre de Cabecera [1] [10].
NOMBRE DE CABECERA COMPLETO NOMBRE DE CABECERA ABREVIADO
Call-ID i
Contact m
Content-Encoding e
Content-Length l
Content-Type c
From f
Subject s
To t
Via v
36
2.2.5. Cuerpo de los mensajes SIP (protocolo de descripción de la sesión SDP)
Como se había mencionado anteriormente el protocolo SIP es el encargado de establecer, modificar y
finalizar sesiones multimedia pero no de negociar parámetros (Codecs) entre los dos usuarios finales de
esto se encarga el protocolo SDP el cual se encuentra contenido en el protocolo SIP.
Protocolo de descripción de la sesión (SDP)
SDP es el protocolo de descripción de la sesión diseñado para identificar los atributos de una sesión,
incluyendo información administrativa, sobre el programa y sobre los medios [12]. SDP especifica un
estricto orden de los atributos; este orden se basa en minimizar el tamaño y complejidad del mensaje del
protocolo.
La tabla 2-5 especifica los atributos del protocolo SDP
Tabla 2-5. Atributos de SDP [12]
TIPO SDP DESCRIPCION
v= Versión del protocolo
o= Propietario-creador e identificador de sesión
s= Nombre de la sesión
i= *Información de la sesión
u= *URI de descripción
e= *Dirección de e-mail
p= Número de teléfono
c= *Información de la conexión
b= *Información de ancho de banda
<TIME_DESCR> Una o más descripciones horarias
z= *Ajustes de zona horaria
k= *Clave de encriptación
a= *Ninguna o más líneas de atributos de sesión
<MEDIA_DESCR> *Ninguna o más descripciones de los medios
t= Tiempo en que la sesión está activa
r= *Cero o más repeticiones
m= Nombre de los medios y dirección del transporte
i= *Título de los medios
c= *Información de la conexión
b= *Información del ancho de banda
k= *Clave de encriptación
a= *Ninguna o más líneas de atributo
DESCRIPCION DE SESION
DESCRIPCION DEL TIEMPO
DESCRIPCION DE MEDIOS
NOTA: *son opcionales
37
2.3. PROBLEMAS GENERALES DE INTEROPERABILIDAD
Los problemas de interoperabilidad de las redes NGN´s tanto en la arquitectura Softswitch e IMS
utilizando el protocolo SIP para la señalización pueden variar por varios motivos tal como:
• Problemas de código de respuesta: cuando un usuario final SIP fue movido y el usuario que
inicia la sesión SIP intenta conectar por los mismos caminos, no por otros dando como resultado
este tipo de errores un 404 Not Found o 480 temporalmente no disponible o 503 servicio no
disponible.
• SIP campo y longitudes mensaje: Mientras que el RFC no define ninguna longitud máxima de
los mensajes de SIP, la realidad es que los proveedores a menudo imponen límites de longitud de
los campos y los mensajes recibidos. Ya sea por razones de seguridad, arquitectura, lo cierto es
que hay muchos sistemas que no pueden o no quieren manejar los campos tan grandes como otros
sistemas pueden generar. A pesar del [RFC 3261] que define algunos códigos de respuesta
específicos 413 (Entidad de solicitud demasiado grande), 414 (Request-URI es demasiado larga) y
513(Mensaje demasiado grande)
• SIP y formatos URI11: A pesar del [RFC 3261] el formato SIP URI ha tenido un uso
generalizado como esencialmente el equivalente semántico de la URI TEL, aunque con una
sintaxis diferente. Los usuarios SIP no tienen una forma real de saber cuándo una URI pertenece a
un servidor SIP o a otro - el usuario presiona los botones numéricos y pulse en "Enviar", y el
usuario SIP lo que puede hacer es enviar el solicitud a sip: [dígitos] @ [dominio local]. Además,
muchos sistemas han sido diseñados o bien aprovisionados para manejar un solo tipo de sistema:
SIP URI. Esto ha llevado a los casos en que las solicitudes son rechazadas a menos de que el
esquema del URI este adecuado.
• TEL-URI y parámetros URI: El problema de la interoperabilidad más comunes en esta área es
la colocación de los parámetros TEL URI, por ejemplo, el "tgrp" y "contexto tronco" parámetros
de [RFC4904], y la "rn", "NPDI", y los parámetros "CIC" a partir de [RFC4694]. RFC 3261
sección 19.1.6 está muy claro que todas las características de la telefónica de abonado, incluyendo
los parámetros, se coloca en la parte de userinfo de una SIP URI. Por lo tanto los parámetros de
Tel-URI se convierten en parámetros de usuario de SIP, parámetros SIP URI no.
Un ejemplo, por lo tanto, de una SIP URI que contiene algunos de los mencionados parámetros
11
URI (Uniform Resource Identifer / Identificador Uniforme de Recurso)
38
URI Tel-sería la siguiente: sip: +12125551212 NPDI; tgrp = foo; tronco-context = example.com
@ example.net
Otro de los problemas comunes de interoperabilidad se refiere a los separadores visuales.
12125551212 +1 (212) 555-1212
2.3.1. Problemas específicos de interconexión del protocolo SIP
• Registró comportamiento de respuesta: Otra forma de los problemas de interoperabilidad que
surgen de las respuestas es el comportamiento de la UA en materia de registro y suscripción de
manejo de respuesta. Por ejemplo, la UA envía una petición pero el destinatario y recibe una
respuesta 3xx (301 Movido permanentemente, Movido temporalmente).
• Requerimiento de valor de cabecera: SIP ofrece un medio para indicar el uso de extensión, los
vendedores hacen suposiciones acerca de las capacidades de los otros UA, literalmente significa
"no quiero que esta solicitud tenga éxito, a menos de que el posible receptor conozca el uso de
extensión".
Por ejemplo, la etiqueta de opción 100rel para apoyar PRACK, se inserta en la cabecera de una
petición INVITE. Esto es fundamentalmente erróneo en el uso real. El apoyo a PRACK no es
universal, en todo sentido, y la inserción de esta etiqueta en la cabecera que conduce a las
llamadas fallidas. Ningún usuario o el operador quieren una llamada fallida, a menos que sea
literalmente imposible de tener éxito.
• Desvió de llamada: Funciones específicas de facturación, este es propietario del operador por lo
cual no son compatibles tanto de origen como destino.
• Consulta de trasferencia de llamadas: Supuestos específicos de cada operador versus modelos
implementados, Por ejemplo, algunas aplicaciones y modelos de implementación no son
compatibles con el de diálogo se referencia.
39
2.3.2. Problemas específicos de interconexión del protocolo SIP e SDP
• Oferta-INVITE a menos y Re-INVITE: Crea una invitación, al ser negada reenvía la invitación
y no puede establecer una comunicación por falta de parámetros en el protocolo SDP, por
ejemplo, que los dispositivos a enrutar las llamadas sobre la base del códec, o la asignación de
ancho de banda, o los dispositivos de transcodificación que se envían no estén de acuerdo con lo
necesario.
• Señalización: Funciones de pasarela de señalización, falta de parámetros entre proveedores un
dispositivo envía de una SDP, literalmente, no quiere que el otro extremo la reciba.
• Petición y respuesta SDP no coinciden: Un problema de interoperabilidad con frecuencia surge
cuando una oferta SDP contiene múltiples "m =" líneas de los medios de comunicación, pero la
respuesta SDP no contiene el mismo número de líneas.
• Medios compatibles Incompatibilidades: En la práctica, un número significativo de dispositivos
SIP sólo soportan ciertos tipos de códec.
40
3. ESPECIFICACIONES
En esta sección se describen los componentes que se tuvieron en cuenta en la elaboración de esta solución
de interconexión de la red NGN ZTE-PUJ con arquitectura Softswitch/MGC y red NGN ANKLA con
arquitectura Softswitch/MGC.
DESCRIPCIÓN GENERAL
El trabajo de profundización consiste en el diseño e implementación de una solución de interconexión de
dos plataformas de redes NGN de diferentes fabricantes con el protocolo SIP sobre la arquitectura
Softswitch/MGC; para esto se debe tener en cuenta una serie de aspectos que son fundamentales en el
desarrollo de la investigación los cuales se irán describiendo en el desarrollo del mismo.
Una característica fundamental de la red NGN es la capacidad de suministrar una gran variedad de
servicios, incluidos voz, vídeo, audio y datos visuales, mediante servicios basados en sesión e interactivos
en los modos unidifusión, multidifusión y difusión; Basándose en la separación de los servicios y
transporte como se describió en el numeral 2.1.2, la convergencia se centra en las técnicas de integración
de los diferentes protocolos de comunicación para asegurar el inter funcionamiento de la red de transporte
con los servicios y las aplicaciones, para la interpretación, generación, distribución y traducción de la
señalización correspondiente y así poder realizar la integración de los diferentes componentes de la
misma. La red NGN puede emplearse de manera coherente en cualquier instante o en cualquier lugar a
través de diferentes entornos que emplean equipos de terminales convergentes (es decir, equipos
terminales que son capaces de aceptar todos los servicios) en un entorno digital [4].
En la figura 3-1 se muestra los diferentes protocolos de comunicación que tiene en cuenta las redes NGN
para las comunicaciones con sus diferentes dependencias y con la integración con otras redes NGN.
Después de tener en cuenta los diferentes protocolos de comunicación de las redes NGN nos centraremos
en el protocolo SIP, el cual es el que nos permite realizar la interconexión en dos redes NGN mediante un
troncal SIP (canal de comunicación con múltiples conexiones de señalización con el protocolo SIP), esto
se realiza para poder compartir servicios de voz, video y datos entre las dos redes.
41
-
Figura 3-1. Protocolos de la red NGN12
En la figura 3-2 se muestra el diagrama básico de la interconexión entre red Red NGN ZTE-PUJ y
ANKLA.
Figura 3-2. Arquitectura básica de interconexión las diferentes redes NGN´s.
12 Tomado de “Introducción a los Protocolos NGN (ZTE)”
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
“CINTEL”
42
3.1 Red NGN ZTE-PUJ
La plataforma del Centro de Tecnologías de Telecomunicaciones ZTE-PUJ se basa en una red de próxima
generación marca ZTE, con arquitectura Softswitch/MGC de fabricación China. Desde ella, se puede
proveer servicios: voz sobre IP, telefonía tradicional/IP e Internet Banda ancha.
La arquitectura general de la red es la siguiente:
• Nivel de servicios. Servidores de aplicación tales como (Asterisk, Elastik, Open Source IMS,
Mobicents, Kamailio)
• Nivel de control. Softswitch (control, servicios, gestión de llamadas)
• Nivel de transporte. Core (conmutación de paquetes).
• Nivel de acceso. Inalámbrico, banda ancha, PSTN, ISDN, con equipos: UAM (MSAG), abonados
análogos y ADSL (convierte señales de voz análoga a IP; IAD, concentrador de líneas USUARIO
Analógicas 8-24, conexión IP hacia el SS; SG, señalización SS7; TG, trafico PSTN; AG, servidor
de acceso.
Por ser una NGN con arquitectura Softswitch/MGC, maneja en un mismo equipo: servicios, control,
transporte y acceso.
Figura 3-3. Arquitectura Red NGN ZTE-PUJ13
13 Tomado de la arquitectura NGN del laboratorio PUJ-ZTE
43
3.2 Red NGN ANKLA
El laboratorio ANKLA sigue una estructura de red NGN para la implementación de la plataforma de
pruebas, de acuerdo a las capas y funciones descritas en la arquitectura Softswitch/MGC, la plataforma
está constituida por:
• Telephony Softswitch Solution (TSS) versión 4.0 de Ericsson: Está conformado por un
Telephony Server (AXE), TSS Gateway Controller y un Media Gateway (MGW). Soporta
protocolos de señalización SS7 y SIGTRAN, protocolos de control de llamadas ISUP, SIP y
H.323, como protocolo de control de portadora H.248 y ADSL. Tiene una capacidad total de
1200 abonados TDM a través de un Access Gateway (AGW), ANKLA cuenta con una
capacidad instalada de 60 abonados. Provee servicios suplementarios como reloj despertador,
línea directa, llamada tripartita, identificadores de llamadas, marcación abreviada y llamada en
espera.
• Plataforma de servicios de Trópico: Está conformada por un servidor de aplicaciones (VAS) que
realiza las tareas de control y lógica del servicio en las diferentes aplicaciones instaladas, un
servidor de medios para la reproducción de anuncios y procesamiento multimedia (VMS) y un
módulo de reconocimiento de voz (ASR Nuance) encargado de las tareas de reconocimiento
automático de voz y su correspondiente conversión a texto. Provee servicios de Portal de Voz
para la atención de servicios de Call Center, mediante un IVR por reconocimiento de voz, y un
sistema de conversión numérica y distribución de llamadas para la atención del usuario
mediante operador.
• Plataforma de comunicaciones unificadas: Conformada por dos servidores AsteriskNow y
Elastix para realizar la integración de servicios entre usuarios Legacy (TDM) e IP, proveen
servicios de VoIP tales como videollamadas, IVR, y call center además de integrar servicios de
mensajería instantánea, fax, videoconferencias, tarificación y correo electrónico.
• Plataforma de IMS (IP Multimedia Subsystem): Conformada por una plataforma de entrega de
servicios IMS open source (Open Source IMS Core) desarrollada por el instituto Fokus de
Alemania con el objetivo de desplegar una plataforma de pruebas sin limitaciones en cuanto a
licencias. Está constituida por:
o Proxy Call Sessión Control Function (P-CSCF).
o Interrogating Call Sessión Control Function (I-CSCF).
44
o Serving Call Sessión Control Function (S-CSCF).
o Home Subscriber Server (HSS).
o Servidores de aplicaciones SIP (SIP AS).
Figura 3-4. Arquitectura ANKLA14
3.3 Infraestructura de Interconexión redes NGN´s.
Para la interconexión de las redes NGN´s ZTE-PUJ y ANKLA se tuvieron en cuenta una serie de
herramientas de tipo software y hardware que serán descritas a continuación.
3.3.1 Nodo Captura
El nodo captura es un sistema robusto, capaz de recolectar y encapsular enormes cantidades de
señalización SIP con capacidad de búsqueda instantánea, la cual nos da un análisis de extremo a extremo
de la señalización y con la posibilidad de realizar un estudio detallado del comportamiento y las
estructuras de las tramas del protocolo SIP, para poder identificar los problemas puntuales generados por
14 Tomado de la arquitectura NGN del laboratorio ANKLA “CINTEL”
45
los posibles cambios en las tramas y realizar una corrección de la misma; el funcionamiento del nodo
captura está dividido en tres partes el primero es un proxy SIP (Kamailio) que recolecta toda la
señalización SIP que le envía el “Capture Agent”. La ventaja de este tipo de solución es que vamos a
tener la posibilidad de ver todo ese tipo de tráfico en un sitio web (WebHomer).
• Kamailio es un servidor SIP de código abierto que puede adoptar todas las entidades lógicas
conocidas en un entorno VoIP:
� Servidor Registrador o Registrar Server
� Servidor Proxy o Proxy Server
� Servidor Redireccionador o Redirect Server
� Servidor de Localización o Location Server
• Capture Agent, está basado en el módulo sipcapture (El módulo sipcapture almacena y modifica
los mensajes SIP entrantes / salientes en la base de datos) para el servidor SIP Kamailio viene con
potentes opciones de filtrado de ajuste y, el manejo sin problemas de millones de paquetes por
nodo / hora.
• WebHomer, es la parte que se encarga de buscar, filtrar y mostrar los paquetes SIP y las sesiones
detalladas SIP, visualiza extremo a extremo los flujos de llamada extrayéndolas en archivos
PCAP´s para mostrar el tráfico y las estadísticas multiusuario, niveles de acceso.
Figura 3-5. Arquitectura Nodo Captura15
El Nodo Captura necesita de unos requisitos mínimos adicionales de software para su funcionamiento
como son los siguientes:
15 Tomado de http://www.sipcapture.org/
46
El Nodo Captura trabaja exclusivamente sobre ambientes Linux, necesita de un servidor web para la
publicación de la interfaz gráfica (WebHomer), una base de datos Mysql para que el servidor kamailio
guarde toda señalización SIP y servidor PHP para poder generar los reportes de señalización SIP.
• Servidor Linux
• Servidor Apache/Lighttpd
• Base de datos MySQL 5.1.43+
• Servidor PHP 5.2+ HP-GD, JSON)
3.3.2 Generador de tráfico
El generador de tráfico Distributed Internet Traffic Generator (D-ITG). Es una plataforma capaz de
producir tráfico a nivel de paquetes con gran exactitud, replicando apropiadamente procesos estocásticos
tanto para IDT (Inter Departure Time), como para variables PS (Packet Size) aleatorias (exponencial,
uniforme, Cauchy, normal y Pareto). Soporta generación de tráfico IPv4 e IPv6 y es capaz de generar
tráfico a nivel de red, transporte y aplicación.
D-ITG, es el software seleccionado para el proyecto que permite implementar algunos protocolos en la
capa de aplicación como: VoIP, Telnet, DNS, entre otros. En general, permite implementar protocolos
hasta en la capa de transporte, por lo que al modelar algún tipo de tráfico para ser generado e inyectado
por el D-ITG en la red, es necesario abstraer el comportamiento estadístico de la capa de aplicación y
encapsularlo en la capa de transporte, para que de esta manera logre emular la pila de protocolos TCP/IP
completa con solo implementar los protocolos de red y transporte.
El D-ITG no permite implementar todos los protocolos de aplicación que existen. Pero a nivel de los
sistemas de conmutación y transporte de una red, esto no tiene importancia porque los dispositivos de red
que componen estos sistemas solo operan hasta nivel de capa de red, y los niveles superiores, como
aplicaciones y transporte son encapsulados, uno dentro del otro. En consecuencia, la medida que se
obtiene usando el D-ITG es aceptable porque usa los protocolos de las capas de transporte, red e interfaz.
Lo anterior implica que para la realización de una medida de QoS en una red de telecomunicaciones, para
cada servicio por ejemplo, la QoS de una llamada telefónica IP es necesario modelar el tráfico de una
llamada telefónica IP real, de forma estadística, y entregarle estos parámetros al D-ITG, para configurarlo
y modelar el tráfico de una llamada telefónica IP. Posteriormente, ese tráfico moldeado se inyecta a la red,
que se encarga de implementar todos los protocolos de esa comunicación, hasta la capa de transporte.
47
3.3.3 Simulador trama SIP
SIP Inspector es una herramienta práctica que permite simular mensajes y escenarios del protocolo SIP.
SIP Inspector es una herramienta escrita en JAVA que te permite simular diferentes mensajes y
escenarios del Protocolo de Inicio de Sesiones (SIP). Puede crear propios escenarios de señalización SIP,
personalizar mensajes SIP y supervisar los mensajes recibidos y enviados. La herramienta permite
reproducir secuencias RPT desde un archivo pcap [25].
Es una herramienta ideal para auditarla seguridad de VOIP y con grandes aplicaciones para los que
quieran conocer más sobre el protocolo de señalización SIP, gracias a la incorporación de esquemas para
los casos de UAC y de UAS.
3.3.3.4 Firewall
Un cortafuego (firewall en inglés) es una parte de un sistema o una red que está diseñada para bloquear el
acceso no autorizado, permitiendo al mismo tiempo comunicaciones autorizadas.
Se trata de un dispositivo o conjunto de dispositivos configurados para permitir, limitar, cifrar, descifrar,
el tráfico entre los diferentes ámbitos sobre la base de un conjunto de normas y otros criterios.
Los cortafuegos pueden ser implementados en hardware o software, o una combinación de ambos. Los
cortafuegos se utilizan con frecuencia para evitar que los usuarios de Internet no autorizados tengan
acceso a redes privadas conectadas a Internet.
48
4 DESARROLLOS.
En esta sección del documento se explica y documentan todos los desarrollos e implementaciones
realizadas para el cumplimiento de los objetivos del proyecto. Las cuales fueron un análisis del
comportamiento y cabeceras de la señalización SIP en cada una de las redes NGN con arquitectura
Softswitch/MGC; se montó un escenario real para poder hacer un análisis de la interoperabilidad entre la
Red NGN ZTE-PUJ y ANKLA.
4.3 ANÁLISIS DEL PROTOCOLO SIP.
El análisis del protocolo SIP se realizó de manera detallada con una conexión básica, observando y
analizando la trama de señalización en cada una de sus partes en la red NGN con arquitectura
Softswitch/MGC, para poder tener un punto de partida del sistema de señalización a nivel de troncal SIP y
poder llegar a la interconexión de las dos redes NGN´s de diferente fabricante [1].
4.3.3 Análisis del protocolo SIP ZTE-PUJ
Se realizó un análisis de toda la trama de señalización SIP de la red NGN con arquitectura
Softswitch/MGC, el cual no muestra ningún tipo de modificación en los parámetros básicos del protocolo
según el RFC 3261como se muestra en el análisis de la siguiente señalización SIP.
49
Figura 4-1. Comunicación básica del protocolo SIP de la red NGN ZTE-PUJ
• Estructura de un mensaje INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To: "102"<sip:[email protected]>
From: "103"<sip: [email protected]>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@ 172.22.0.54
CSeq: 23944 INVITE
Contact: <sip103@ 172.22.0.54:5060>
Max-Forwards: 70
User-Agent: ZTE MULTIMEDIA SIPPHONE/V1.0 04-01-10
Content-Type: application/sdp
Content-Length: 288
v=0
o=1033608424475 IN IP4 10.66.74.136
s=session SDP
50
c=IN IP4 172.22.034
t=0 0
m=audio 10000 RTP/AVP 0 4 8 18
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
m=video 10002 RTP/AVP 34
a=rtpmap:34 H263/90000
NOTA: en la estructura el mensaje invite no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 183 RING
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To:"102"<sip:[email protected]>;tag=a290601-31939
From:"103"<sip:[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
User-Agent: ZTE Softswitch/1.0.0
Content-Type: application/sdp
Content-Length: 115
51
v=0
o= ERICSSON 32 32 IN IP4 10.41.6.1
s=phone-call
c=IN IP4 172.22.0.34
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 183RING no se encuentra ningún tipo de modificación o adicional en
la estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To:"102"<sip:[email protected]>;tag=a290601-31939
From:"103"<sip:[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
Record-Route: <sip:172.22.0.34;lr>
User-Agent: ZTE Softswitch/1.0.0
Content-Type: application/sdp
Content-Length: 115
v=0
o= ZTE 32 32 IN IP4 172.22.0.34
52
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje ACK
ACK sip:172.22.0.34;lr SIP/2.0
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To: "102"<sip:[email protected]>
From: "103"<sip:[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 ACK
Contact: <sip:#[email protected]:5060>
Max-Forwards: 70
Route: <sip:[email protected]>
NOTA: en la estructura el mensaje ACK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje BYE
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=776249e9.0
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=4dcf5bd7
To: “103"<sip:[email protected]>;tag=884a420a-7062206315162668
53
From: "102"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
User-Agent: ZTE Softswitch/1.0.0
Content-Length: 0
NOTA: en la estructura el mensaje BYE no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=776249e9.0
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=4dcf5bd7
To: "#0*109316"<sip:[email protected]>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
Después de haber analizado la trama de señalización SIP con el RFC 3261 de una comunicación básica de
la red NGN ZTE-PUJ con arquitectura Softswitch/MGC SIP no se encontró ningún tipo de modificación
o adición a la misma, el cual nos da un principio de interconexión sin presentar ningún problema.
54
4.3.4 Análisis del protocolo SIP ANKLA
Se realizó un análisis de toda la trama de señalización SIP de la red NGN con arquitectura
Softswitch/MGC, el cual no muestra ningún tipo de modificación en los parámetros básicos del protocolo
según el RFC 3261 como se muestra en el análisis de la siguiente señalización SIP.
Figura 4-2. Comunicación básica del protocolo SIP de la red NGN ANKLA
• Estructura de un mensaje INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To: "0755526778086"<sip:[email protected]>
From: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:#0*[email protected]:5060>
Max-Forwards: 70
User-Agent: ERICSSON MULTIMEDIA SIPPHONE/V1.0 04-01-10
Content-Type: application/sdp
55
Content-Length: 288
v=0
o=#0*109316 3507761179 3608424475 IN IP4 10.66.74.136
s=session SDP
c=IN IP4 10.66.74.136
t=0 0
m=audio 10000 RTP/AVP 0 4 8 18
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
m=video 10002 RTP/AVP 34
a=rtpmap:34 H263/90000
NOTA: en la estructura el mensaje INVITE no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 183 RING
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To:"0755526778086"<sip:[email protected]>;tag=a290601-31939
From:"#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
56
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
User-Agent: ERICSSON Softswitch/1.0.0
Content-Type: application/sdp
Content-Length: 115
v=0
o= ERICSSON 32 32 IN IP4 10.41.6.1
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 183 RING no se encuentra ningún tipo de modificación o adicional en
la estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To:"0755526778086"<sip:[email protected]>;tag=a290601-31939
From:"#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
Record-Route: <sip:10.41.6.1;lr>
User-Agent: ERICSSON Softswitch/1.0.0
57
Content-Type: application/sdp
Content-Length: 115
v=0
o= ERICSSON 32 32 IN IP4 10.41.6.1
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje ACK
ACK sip:10.41.6.1;lr SIP/2.0
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To: "0755526778086"<sip:[email protected]>
From: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 ACK
Contact: <sip:#0*[email protected]:5060>
Max-Forwards: 70
Route: <sip:[email protected]>
NOTA: en la estructura el mensaje ACK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje BYE
58
BYE sip:#0*[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.41.6.1:5060;branch=776249e9.0
Via: SIP/2.0/UDP 10.52.31.237:5060;branch=4dcf5bd7
To: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
User-Agent: ERICSSON Softswitch/1.0.0
Content-Length: 0
NOTA: en la estructura el mensaje BYE no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.41.6.1:5060;branch=776249e9.0
Via: SIP/2.0/UDP 10.52.31.237:5060;branch=4dcf5bd7
To: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
59
Después de haber analizado la trama de señalización SIP con el RFC 3261 de una señalización básica de
la red NGN ANKLA con arquitectura Softswitch/MGC no se encontró ningún tipo de modificación o
adición a la misma, el cual nos da un principio de interconexión sin presentar ningún problema.
4.3.5 Comparación de las dos redes NGN´s
Al realizar un estudio comparativo de la señalización SIP de las dos redes NGN´s ZTE-PUJ ANKLA no
se encuentra ninguna diferencia en la forma en que ambos fabricantes implementan el protocolo SIP al
interior de sus redes [4] [7] [8] [10].
4.4 PRUEBAS DE INTEROPERABILIDAD
En este numeral se tienen en cuanta todas las consideraciones técnicas a tomarse en cuenta para la
interoperabilidad e interconexión de las dos redes NGN a través de troncales SIP [7].
El uso del protocolo SIP permite la interconexión de equipos de múltiples fabricantes debido a su
estandarización y a la simplicidad del intercambio de mensajes [1].
4.4.3 Escenario de interoperabilidad ZTE-ANKLA
Uno de los mecanismos más recientes para los servicios convergentes es la capacidad de acceso basado en
SIP, o de manera más general, la conexión a redes NGN´s mediante troncales SIP [7]. Estas capacidades
posibilitan el uso de implementaciones basadas en estándares abiertos de conectividad SIP, ya sea para
hacer más eficiente el uso de la infraestructura existente de cable, de cobre o de fibra óptica (para
cobertura de voz y datos), o para extender el alcance geográfico de los carriers para atender nuevos
mercados a través de una conectividad IP. La interconexión a través de troncales SIP tiene algunas
ventajas para las redes NGN:
• Reduce los costos y la complejidad de las implementaciones gracias a la consolidación de la voz y
los datos sobre una sola red.
60
• Permite hacer uso de otros servicios IP dependientes del tipo de transporte como: transferencia de
mensajes de audio, video conferencias, presencia, mensajería instantánea, etc.
• Capacidad de expansión de los servicios de comunicaciones para satisfacer demandas no
contempladas.
• Implementación de servicios convergentes a lo largo de toda la empresa.
Inicialmente, H.323 estaba orientado a implementarse sobre redes corporativas, mientras que SIP se usaba
en redes de carriers. En los últimos años, ha ido creciendo la aceptación de la industria con respecto a SIP
como el protocolo primario de comunicación IP entre sistemas, independientemente de la aplicación.
En este caso se accede a la red NGN directamente desde las premisas de la red del cliente, o de una red de
datos privada, desde la cual se tiene conexión a Internet, incluso con otra red NGN. Desde esta red de
datos (red IP) se accede a través de una troncal SIP a la red NGN con arquitectura Softswitch/MGC.
Con SIP versión 2, se han adicionado nuevas características que permiten al equipo comunicarse con redes
VoIP de múltiples fabricantes. Sin embargo, todavía no existe una garantía de que todos los fabricantes,
interpreten e implementen los estándares de la misma forma [1].
Las troncales SIP proveen mayor flexibilidad en cuanto a la configuración de servidores proxy remotos,
de modo que se incrementa el potencial de interoperabilidad y la disponibilidad de la red. El proxy se
puede especificar simplemente ingresando su dirección IP como dirección para enrutar un servicio.
Algunas configuraciones de red pueden requerir el uso de uno o más servidores proxy de salida (por
ejemplo en presencia de un controlador de borde o si el proveedor de servicios usa múltiples nodos para
enrutar llamadas). Ver figura 4-3.
Dado el caso práctico de interoperabilidad de las redes NGN´s de estudia se implementó los Softswitchs
como servidores proxy.
61
Figura 4-3. Estructura de un servidor Proxy SIP16
En el RFC 2833 se define un método estándar para transmitir dígitos de señalización entre dos usuarios
finales transmisión RTP. Esto permite una transmisión confiable de los paquetes entre usuarios finales
independientemente de la calidad del CODEC utilizado para la transmisión de la voz.
Con el fin de activar determinados escenarios de llamadas como transferencia de llamadas sobre troncales
SIP, el método REFER el cual esta descrito en el RFC 3515. Luego que una llamada ha sido establecida
entre dos usuarios, se utiliza el método SIP REFER para transferir la llamada. El mensaje REFER provee
la información de contacto a la otra parte (donde la llamada será transferida).
El funcionamientos de la troncal SIP de realiza con las sesiones de la señalización SIP que normalmente
se establecen a través de un servidor Proxy SIP. El servidor Proxy SIP se ubica en medio del camino de la
señalización y provee un servicio de búsqueda para los mensajes entrantes y salientes. Este servicio puede
ser una búsqueda DNS o una búsqueda en una base de datos de información de presencia, en la cual los
usuarios han registrado su localización y su estado de presencia. En cualquier caso el trabajo del servidor
proxy es encontrar a la persona que está siendo invitada a una sesión de media.
El siguiente ejemplo nos da una visión del funcionamiento del PROXY SIP.
El USUARIO A desea realizar una llamada desde su teléfono IP hacia el teléfono de USUARIO B, por lo
que levanta el auricular del teléfono y marca. Este no conoce exactamente la localización de USUARIO B,
de manera que su teléfono (usuario SIP) re direcciona el mensaje INVITE hacia el servidor proxy SIP.
16 Tomado de Softswitch Architecture for VoIP
62
El servidor proxy realiza una búsqueda del URI de USUARIO B y obtiene su dirección IP, entonces envía
el mensaje INVITE hacia el teléfono de USUARIO B, añadiéndole al mismo un encabezado llamado
“Via:” el cual contiene la dirección IP del servidor proxy. Finalmente el mensaje contendrá dos
encabezados “Via:” contando con el original que contiene la IP de USUARIO A.
Debido a que el (usuario SIP) del USUARIO B recibe el mensaje INVITE con más de un encabezado
“Via:”, se sabe que el paquete ha atravesado un servidor proxy. El teléfono de USUARIO B responde con
un ‘180 Ringing’ enrutado hacia el USUARIO A a través del servidor proxy, y luego con un 200 OK
enrutado de la misma forma.
Las respuestas de USUARIO B contienen su IP, de manera que USUARIO A envía un ACK directamente
hacia USUARIO B (sin pasar por el proxy). En este punto la sesión se encuentra establecida y se desarrolla
directamente entre los dos (usuarios SIP), hasta que se termine la sesión con los mensajes BYE y 200 OK.
El ejemplo solo contiene un servidor proxy para la sesión SIP, sin embargo típicamente se tiene varios
servidores proxy en el camino de señalización, usualmente, al menos uno por sistema autónomo.
En la figura 4-3 se muestra la representación de mensajes SIP dos servidores proxy SIP.
Figura 4-4. Estructura de mensajes SIP con un servidor Proxy SIP17
Los servidores proxy se encuentran usualmente estructurados en una topología que el RFC 3261 define
como trapezoide SIP. Este trapezoide describe la forma en que la media y la señalización fluyen cuando:
17
Tomado de Softswitch Architecture for VoIP.
63
• Dos usuarios SIP de una sesión se encuentran en diferentes dominios.
• Cada dominio está configurado con un servidor proxy.
• Cada usuario SIP, su dominio está configurado para establecer sesiones fuera del dominio a través
de su servidor proxy.
En la figura 4-5 se realiza un diagrama de interconexión utilizando los diferentes Softswitch como
servidores proxy SIP para el intercambio de mensajes de señalización SIP con otras redes NGN; en este
caso se realiza entre el ZTE-PUJ) ANKLA
Figura 4-5. Arquitectura PROXY de interconexión las diferentes redes NGN´s de estudio
En el intercambio de mensajes SIP desde los diferentes PROXY de cada red también debemos tener en
cuenta el intercambio de los mensajes del protocolo SDP el cual está contenido dentro del protocolo SIP
como se describe en una llamada típica, el usuario SIP envía el mensaje INVITE junto con una petición de
establecimiento de sesión usando SDP. En este caso, el teléfono de destino responde con un ‘180 Ringing’
que permite escuchar un tono de confirmación de timbrado en el teléfono de origen. Cuando el auricular
del teléfono se levanta en el otro extremo, éste envía un mensaje 200 OK con la confirmación de uso de
SDP [7].
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
CINTEL
64
Figura 4-6. Llamada saliente: Mensaje INVITE + SDP con timbrado local
Otro escenario se da cuando conecta la media el momento en que recibe el mensaje 180 Ringing o 183 con
SDP. Si a continuación se recibe otro mensaje 180, la media no será desconectada, pero no existirá flujo
de media hasta que la llamada sea contestada.
Figura 4-7. Llamada saliente: Mensaje INVITE + SDP con conexión temprana de media
Hay que notar que el contenido SDP solo se puede incluir en respuestas provisionales si éstas son enviadas
de manera confiable. Como se puede ver en el flujo de mensajes de la Figura 4-7, las respuestas
provisionales son confirmadas mediante mensajes PRACK (Provisional Response ACK), el mismo que es
65
confirmado a su vez por un 200 OK. En éste y en los flujos siguientes, la presencia de SDP en los
mensajes de respuestas provisionales implica que éstos son entregados de forma segura.
Para poner una troncal SIP en espera, se envía un mensaje re-INVITE con una oferta SDP y con un
atributo ’sendonly’ (sesión unidireccional). El otro extremo de la troncal SIP puede seguir recibiendo
media. La dirección IP especificada en SDP seguirá siendo válida.
4.4.4 VPN y sus características de interoperabilidad.
La interconexión entre la red NGN ZTE-PUJ y ANKLA se realizó por medio de una Red Privada Virtual
(VPN) que es una forma de compartir y transmitir información entre diferentes redes que están situados en
diferentes áreas geográficas. Es una red de datos de gran seguridad que utilizando Internet como medio de
transmisión permite la transmisión de información confidencial entre las dos NGN´s. Aunque Internet es
una red pública y abierta, la transmisión de los datos se realiza a través de la creación de túneles virtuales,
asegurando la confidencialidad e integridad de los datos transmitidos. El diagrama básico de interconexión
de las dos redes NGN´s de estudio se muestra en la figura 4-8.
VPN SITE TO SITESOFTSWITCH
NGN ZTE
SOFTSWITCH
NGN ERICSSON
TRONCAL SIPTRONCAL SIP
Figura 4-8. Diagrama básico de la VPN las diferentes redes NGN´s
Una Red Privada Virtual (VPN) conecta los componentes de una red sobre otra, por medio de la conexión
de los usuarios de distintas redes a través de un "túnel" que se construye sobre Internet o sobre cualquier
otra red pública, negociando un esquema de cifrado y autentificación de los paquetes de datos para el
transporte, permitiendo el acceso remoto a servicios de red de forma transparente y segura con el grado de
conveniencia y seguridad que los usuarios conectados elijan. Las VPN están implementadas con firewalls,
con routers para lograr esa encriptación y autentificación.
66
4.4.4.4 VPN Sitio a Sitio utilizando NAT
(Network Address Translation) Traducción de Direcciones de Nombres es el proceso de cambiar una
dirección IP de una NGN (una dirección privada de la organización) por una dirección IP pública
enrutable, es decir poseen la capacidad para esconder las direcciones privadas de una NGN.
Los pasos siguientes describen el proceso de comunicación de entrada y salida con un dispositivo NAT
• Cuando un paquete precisa salir de la red interna, este es enviado hacia el firewall implementado
con NAT. Este por primera vez, cambia la dirección IP enrutable.
• El firewall implementado con NAT reenvía el paquete al dispositivo VPN que realiza el proceso
de cifrado del paquete.
• El paquete es enviado hacia el enrutador externo que sea transmitido a su destino.
• Cuando un paquete quiere entrar a una red interna debe primero dirigirse hacia el dispositivo VPN
que verifica su autenticidad. Luego este paquete es ruteado hacia el firewall implementado con
NAT que cambia la dirección IP por el número original, este es enviado hacia el enrutador interno
para ser dirigido hacia su destino.
En la figura 4-9 se muestra el diagrama de interconexión utilizado para las redes NGN´s ZTE-PUJ y
ANKLA, el cual nos muestra el direccionamiento que tiene cada una y como es el proceso de NAT que
tiene que realizar un paquete si desea ser enviado a la otra red.
VPN SITE TO SITE
IPsecSOFTSWITCH
NGN ZTE
172.22.0.48/28
SOFTSWITCH
NGN ERICSSON
192.168.0.0/24
TRONCAL SIPTRONCAL SIP
ASA 5510
IP PUBLICA
200.3.153.91
ASA 5505
IP PUBLICA
190.25.130.245
172.22.0.48/28 192.168.0.0/24
NAT
Figura 4-9. Diagrama básico de NAT las diferentes redes NGN´s
4.4.4.5 Seguridad VPN IPSec
En la implementación de la VPN para la interconexión de las diferentes redes NGN´s ZTE-PUJ y
ANKLA, un factor muy importante es la seguridad con la que nuestros datos son trasportados a través de
67
internet, por tal razón IPSec - Internet Protocol security el cual nos da una seguridad mejorada con
características tales como algoritmos de encriptación más fuertes y autenticación más comprensiva. IPSec
tiene dos modos de cifrado, túnel y transporte. El modo de túnel cifra el encabezado y la carga de cada
paquete, mientras que el método de transporte sólo encripta la carga o contenido de los paquetes. Sólo
sistemas que son compatibles con IPSec pueden usar este protocolo. También, todos los dispositivos
deben usar una clave común o certificado y deben tener implementadas políticas de seguridad similares.
Para usuarios de acceso remoto de VPN hay paquetes de software que proveen cifrado y conexión en un
PC. IPSec soporta cifrado de 56 bits (single DES) o 168 bits (triple-DES).
4.4.4.6 Descripción de los Parámetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y ANKLA
Después de haber explicado los diferentes componentes a tener en cuenta en la interconexión de las
diferentes redes NGN´s ZTE-PUJ y ANKLA, se decide crear un VPN sitio a sitio para el intercambio de
toda la señalización SIP y la media. Con esto las estas redes puedan compartir servicio y aplicaciones. Ver
figura 4-10.
Figura 4-10. Configuración VPN de la Red NGN ZTE-PUJ ANKLA
4.5 METODOLOGÍA DE ANÁLISIS DE INTEROPERABILIDAD
Después de establecer la interconexión de las dos redes NGN´s ZTE-PUJ y ANKLA mediante una VPN
sito a sitio para él envió de señalización SIP y media mediante una troncal SIP y utilizando los softswitch
como servidores PROXY para la conexión desde el interior de cada red con la otra NGN, se decide
implementar un elemento más, el NODO CAPTURA para que estudie, analice y modifique de ser
VPN SITE TO SITE* Ipsec authentication uses pre-shared
key: zte
*Tunnel Group Name: interconexion
*IKE group Encryption: DES / SHA
SOFTSWITCH
NGN ZTE
SOFTSWITCH
NGN ERICSSON
TRONCAL SIP
NODO CAPTURA
TRONCAL SIP
ASA 5510
IP PUBLICA
200.3.153.91
ASA 5510
IP PUBLICA
190.25.130.245
172.22.0.48/28 192.168.1.0/24NAT
68
necesario la señalización SIP que está pasando entre las dos redes NGN´s y no presente inconvenientes de
interoperabilidad de las mismas.
4.5.3 Identificación y reconocimiento
Para revisar los diferentes aspectos de interconexión e interoperabilidad de las diferentes redes NGN´s
ZTE-PUJ y ANKLA se realizaron una serie de pruebas de telefonía IP las cuales involucraron una serie de
componentes como fueron teléfonos SIP, softphones SIP, teléfonos analógicos tradicionales conectados a
la red SIP, un Proxy SIP (Softswitch) y el nodo captura para el análisis de resultados.
Para realizar las pruebas, se accedió desde un cliente SIP de la primera red NGN a través del Softswitch
(Servidor Proxy SIP) y enviando la señalización a través de una troncal SIP hacia la otra NGN como se
muestra en la figura 4-11.
Para cada escenario de pruebas se realizaron las configuraciones adecuadas en los equipos y se evaluó el
desempeño según el resultado esperado de la prueba.
Este esquema de pruebas permite comprobar la interoperabilidad del NODO CAPTURA a través de una
troncal SIP con algunos dispositivos necesarios para la conectividad y acceso a la red pública mediante
SIP, incluyendo: servidor proxy SIP, gateways FXO, gateways FXS, teléfonos analógicos, softphones SIP,
teléfonos IP. Además con esta implementación se pueden probar los siguientes escenarios de
interoperabilidad:
• Llamada simple entre dispositivos IP a través de troncal SIP.
• Llamada interna entre teléfonos SIP.
• Transferencia de llamadas usando el método REFER (RFC 3515).
• Escenarios de espera: espera unidireccional, espera mutua y desactivación de espera.
• Estados de presencia en dispositivos SIP.
• Identificación de llamadas CLIP (Calling Line Identification Presentation).
En primer lugar se estableció una conexión mediante de una VPN y él envió de señalización SIP y media a
través de la troncal SIP las cuales da soporte a todos los dispositivos SIP utilizados. Este procedimiento
consiste en configurar los Proxy SIP, así como la tabla de enrutamiento que específica la troncal, el mapeo
de direcciones IP, puertos a utilizarse, establecer el plan de numeración y los nombres de dominio
utilizados en la red SIP, esto para evitar conflictos de números y direcciones URI, finalmente establecer el
acceso externo mediante troncal SIP.
69
En el caso del servidor, se procedió a realizar los pasos necesarios para configurar los teléfonos SIP y los
softphones.
Para constatar y/o depurar los procedimientos en las pruebas asociadas a la conmutación de paquetes, se
procedió a capturar paquetes SIP y RTP mediante un analizador de protocolo (Wireshark) al interior de
cada red NGN y con el uso de un cliente SIP o softphone instalado en la PC como usuario SIP
destino/origen. Con este escenario de captura de paquetes también es posible verificar los mensajes
asociados a los estados de presencia; y en el medio de las redes NGN´s se configuro el Nodo Captura para
capturar toda la señalización SIP que se está enviando a través de la troncal SIP y así verificar su
interoperabilidad como se muestra en la figura 4-11.
4.5.3.4 Llamada Simple Entre Dispositivos IP A Través De Troncal SIP
Procedimiento: Como se observa en la Figura 4-11, en este escenario se establece una llamada desde un
softphone IP de la red NGN ZTE-PUJ hacia un softphone SIP de la red NGN ANKLA a través de la
troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el número de destino, en
el usuario SIP origen, debe recibir un mensaje INVITE desde la dirección del proxy, confirmando con el
timbrado del teléfono; cuando la llamada es contestada el destino envía un mensaje ‘200 OK’ y se
establece la sesión a través de paquetes RTP.
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexión de usuarios las diferentes redes NGN´s
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
CINTEL
70
Este mismo procedimiento se realizó desde la red NGN ANKLA hacia la red NGN ZTE-PUJ.
4.5.3.5 Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones
Procedimiento: Como se observa en la Figura 4-12, en este escenario se establece una llamada desde un
softphone IP de la red NGN ZTE-PUJ hacia un cliente SIP del servidor de aplicaciones de la red NGN
ANKLA a través de la troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el
número de destino, en el usuario SIP origen, se debe recibir un mensaje INVITE desde la dirección del
proxy, confirmando con el timbrado del teléfono; cuando la llamada es contestada el destino envía un
mensaje ‘200 OK’ y se establece la sesión a través de paquetes RTP.
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexión de diferentes componentes de redes NGN´s
Este mismo procedimiento se realizó desde la red NGN ANKLA “hacia la red NGN ZTE-PUJ.
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
CINTEL
71
4.6 INTEGRACIÓN GENERADOR DE TRÁFICO, NODO CAPTURA Y EMULADOR DE
TRAMA SIP
Después de realizar las pruebas con un solo usuario se implementaron otra serie de pruebas con un
generador de tráfico SIP, para poner a prueba la capacidad de interoperabilidad con flujos de señalización
SIP más grandes y observar el comportamiento del Nodo Captura.
4.6.3 Integración Nodo Captura y Generador de Tráfico
En la figura 4-13 se muestra la forma de inyectar el tráfico emulado con el generador de tráfico D-ITG en
la red NGN´s, el cual pasa por el Nodo Captura para realizar un análisis de grandes cantidades de
señalización SIP; y verificar según el RFC 3261 la estructura de trama SIP, y poder medir la calidad de
servicio (QoS).
La configuración utilizada para esta prueba fue instalar el equipo transmisor en la red ZTE-PUJ desde el
cual el D-ITG inyecta tráfico en la red y un equipo receptor en la red ANKLA que lo toma y lo procesa
generando un archivo de registro, con los parámetros medidos en la transmisión realizada. Esta captura
contiene datos que determinan el comportamiento estadístico de la aplicación, tales como: la tasa de
paquetes enviados (paquetes/segundo), el tamaño de los paquetes (bytes/paquete), el byte DSCP (servicios
diferenciados), el TTL, los protocolos usados en la transmisión, los puertos, el ancho de banda, entre
otros. Estos parámetros son tomados como datos de entrada al software D-ITG, donde se usan para
modelar el comportamiento estadístico a nivel de transmisión de las aplicaciones ofrecidas por la NGN y
emular el comportamiento real de la aplicación a la que se va a medir la QoS hasta llegar a la capa de
transporte (o nivel 4 en el modelo OSI).
NOTA: Este mismo procedimiento se realizó también desde la red NGN ANKLA como transmisor hacia
la red NGN ZTE-PUJ como receptor.
72
Figura 4-13. Generador de tráfico SIP a través de la troncal SIP de dos redes NGN.
4.6.4 Emulación de la trama SIP y Nodo Captura.
Se realizaron por último una serie de pruebas, modificando la trama del protocolo SIP por medio de
software SIP Inspector para comprobar el funcionamiento del Nodo Captura para analizar y solucionar los
problemas que se puedan presentar con el protocolo SIP a nivel de interoperabilidad.
Se realiza una serie de cambios en los parámetros del protocolo SIP y SDP acudiendo a los posibles
problemas que interoperabilidad que se enuncian en el numeral 2.3.
Figura 4-14. Emulador de tráfico SIP.
73
5 ANALISIS DE RESULTADOS
Los resultados obtenidos se basan en el funcionamiento del Nodo Captura en los diversos escenarios, esto
se logró después de hacer las diferentes pruebas de interoperabilidad especialmente evaluando la
señalización SIP y parámetros de QoS18.
5.3 CARACTERIZACION NODO CAPTURA
En este numeral del documento se explica el funcionamiento, puesta en marcha y protocolos de pruebas
realizadas en el Nodo Captura para validar su funcionamiento en un ambiente real en redes NGN´s
evaluando la señalización SIP.
5.3.3 Descripción del funcionamiento Nodo Captura
El nodo captura este compuesto por tres partes, el primero de ellos es un servidor SIP que para nuestro
caso utilizamos Kamailio versión 4, el cual es el encargado de almacenar en una base de datos, (Mysql)
toda la señalización SIP que le llega al nodo captura, el segundo de ellos es un agente captura que hace la
función de puerto de escucha y es el encargado de copiar, modificar y llevar toda la señalización SIP
hacia nuestro servido SIP y por ultimo una interfaz web que es la que se encarga de filtrar los resultados y
mostrarlos en un ambiente web.
Se instala el Nodo Captura, se realiza las modificaciones y desarrollos al interior del mismo para poder
observar el comportamiento de la trama SIP y llegado al caso realizar modificaciones a la trama para la
interoperabilidad de elementos de una red NGN o una integración de dos NGN´s de diferentes fabricantes.
Ver anexo 2.
18
Calidad de Servicio
74
5.3.4 Características del hardware Nodo Captura
Para la implementación e instalación del nodo captura se tuvo en cuenta una serie de requisitos tanto de
hardware como de software como fueron los siguientes:
Se instaló un sistema operativo Linux Ubunto versión 12.04 con todas sus actualizaciones sobre una
máquina que tenía la siguientes características de hardware: Procesador Intel Core i7-3770 3.4GHz, Disco
Duro de 1TB SATA y Memoria DDR3 8GB 1600MHz. El cual demostró un comportamiento aceptable
en cuanto rendimiento de maquina se refiere.
5.3.5 Análisis Nodo Captura
En este numeral se explica la plataforma de pruebas en la que se ha implementado el sistema y el
rendimiento del mismo. Se ha buscado un diseño adecuado para la señalización del protocolo SIP, que
muestre las condiciones reales las cuales permita pruebas y medidas con flexibilidad.
Se ha montado una serie de escenarios para caracterizar, tomar medicas de QoS y observar el
comportamiento de la señalización SIP de la red redes NGN ZTE-PUJ y ANKLA; para esto se puso en
marcha el Nodo Captura y se le inyecto tráfico por medio de generador de tráfico, este nos permite medir
un tráfico real (genera tráfico que emula la señalización SIP y tráfico de media RTP).
El escenario utilizado para las medidas se puede ver en la figura 5-1. Se ha utilizado UDP en lugar de
TCP, para evitar el control de flujo que TCP realiza por defecto. Así, el tráfico interferente siempre es el
mismo, y no se adapta al ancho de banda disponible, haciendo que el sistema trabaje siempre en el peor
caso.
El generador tráfico envía el tráfico en primer lugar al proxy de la red NGN ZTE-PUJ, después al Nodo
Captura el cual realiza la función de escucha para poder evaluar la señalización SIP, después al proxy
destino la red NGN ANKLA y por ultimo al receptor del generador de tráfico de la red de destino en la
figura 5-2 podemos observar la señalización que está pasando por el Nodo Captura.
Esta misma prueba se realizó en sentido contario desde la red NGN ANKLA hacia la red ZTE-PUJ.
75
Figura 5-1. Generación de tráfico SIP las diferentes redes NGN´s
Figura 5-2. Traza de una de las pruebas de interconexión de búsqueda de llamada se sesión de las diferentes NGN´s
Después de realizar un análisis detallado de la señalización SIP que está pasando por el Nodo Captura no
encontramos ningún parámetro adicional o faltante en sus cabeceras de mensajes SIP, la cual se puede ver
en la figura 5-3.
76
Figura 5-3. Diagrama de secuencia de la señalización SIP de una llamada de Softswitch Vs Softswitch
Se realiza una exportación a un analizador de protocolos (wireshark) para observar el comportamiento de
la señalización SIP entre las dos redes NGN´s esto se hace para tener una segunda visualización de los
mensajes SIP el cual no nos arroja ningún comportamiento que no esté contemplado en RFC 3162.
Figura 5-4. Captura de traza de la señalización SIP de una llamada de Softswitch Vs Softswitch
5.3.6 Emulación Trama SIP para el Comportamiento del Nodo Captura.
Al no encontrase ningún tipo de alteración en la trama SIP para la interoperabilidad de redes NGN´s
acudimos a un emulador de trama SIP (Sip Inspector) para probar el funcionamientos del Nodo Captura en
la detección y modificación de parámetros adicionales o faltantes en su señalización SIP (RFC 3261).
77
Se realiza una serie de pruebas invocando los problemas de interoperabilidad mencionados en el numeral
2-3.
5.3.6.4 SIP campo y longitudes mensaje Proxy SIP.
Mientras que el RFC 3261 no define ninguna longitud máxima de los mensajes de SIP, la realidad es que
los proveedores a menudo imponen límites de longitud de los campos y los mensajes recibidos. Ya sea por
razones de seguridad o arquitectura, lo cierto es que hay muchos sistemas que no pueden o no quieren
manejar los campos tan grandes como otros sistemas pueden generarlas. A pesar de que en el [RFC 3261]
se definen algunos códigos de respuesta específicos 413 (Entidad de solicitud demasiado grande), 414
(Request-URI es demasiado larga) y 513(Mensaje demasiado grande).
El Nodo captura realizó modificaciones a la trama SIP simulada para evitar este tipo de errores como son:
413 (Entidad de solicitud demasiado grande), 414 (Request-URI es demasiado larga) y 513(Mensaje
demasiado grande), dando como resultado un autentificación a un proxy. Ver anexo 7.1.
5.3.6.5 Parámetros TEL-URI
El problema de la interoperabilidad más común es en esta área, es la colocación de los parámetros TEL
URI, por ejemplo, el "tgrp" y "contexto tronco" parámetros del [RFC4904], y la "rn", "NPDI", y los
parámetros "CIC" a partir del [RFC4694]. El RFC 3261 sección 19.1.6 está muy claro que todas las
características de la telefonía de abonado, incluyendo los parámetros, se coloca en la parte de user-info de
una SIP URI. Por lo tanto los parámetros de Tel-URI se convierten en parámetros de usuario de SIP,
parámetros SIP URI no.
Se realizó la comprobación de la simulación de un TEL-URI a través del Nodo Captura dando como
resulta un envío de mensajes SIP, transparente para las entidades emisor y receptor. Ver anexo 7.2.
5.3.6.6 Invite –Reinvite (Subscribe)
Crea una invitación al ser negada reenvía la invitación y no puede establecer una comunicación por falta
de parámetros en el protocolo SDP, por ejemplo, que los dispositivos a enrutar las llamadas sobre la base
del códec, o la asignación de ancho de banda, o los dispositivos de transcodificación que se envían no
estén de acuerdo con lo necesario.
78
Se simulo un escenario evitando este tipo de problemas de interoperabilidad, dando como resultado un
envío de señalización SIP éxito. Ver Anexo 7.3
5.3.6.7 Valor De Cabecera PRACK
SIP ofrece un medio para indicar el uso de extensión, los vendedores hacen suposiciones acerca de las
capacidades de los otros UA, literalmente significa "no quiero que esta solicitud tenga éxito, a menos de
que el posible receptor conozca el uso de extensión".
Por ejemplo, la etiqueta de opción 100rel para apoyar PRACK, se inserta en la cabecera requieren de una
petición INVITE. Esto es fundamentalmente erróneo en el uso real. El apoyo a PRACK no es universal,
en todo sentido, y la inserción de esta etiqueta en la cabecera Requerir conduce a las llamadas fallidas.
Se emulo el escenario anterior dando como resultado un envío de señalización SIP éxito. Ver Anexo 7.4
5.4 NODO CAPTURA PLATAFORMA AVAYA
La plataforma AVAYA es una empresa privada de telecomunicaciones que se especializa en el sector de
la telefonía IP y centros de llamada; como lo describimos en la sección 2.3, los problemas de
interoperabilidad que se presenta a nivel de protocolo SIP y SDP se manifiesta en la integración de una
plataforma de un fabricante de telefonía IP caso específico AVAYA con otro fabricante de telefonía IP
genérico; se probó la solución de software denominado NODO CAPTURA en la interoperabilidad de las
plataformas mencionadas anteriormente.
La plataforma AVAYA en la implementación del protocolo de señalización SIP presenta una
implementación adicional en el mensaje de petición PRACK, este mensaje no permite la interoperabilidad
de este fabricante con otros dispositivos de hardware de otro fabricante, en la implementación del NODO
CAPTURA para probar su funcionamiento el modifica la señalización del fabricante AVAYA para que
sea interoperable con otro fabricante.
El NODO CAPTURA soluciono el siguiente problema de interoperabilidad del fabricante AVAYA: SIP
ofrece un medio para indicar el uso de extensión, los fabricantes caso específico de AVAYA hacen
suposiciones acerca de las capacidades de los otros UA, literalmente significa "no quiero que esta solicitud
tenga éxito, a menos de que el posible receptor conozca el uso de extensión".
79
Por ejemplo, la etiqueta de opción 100rel para apoyar PRACK, se inserta en la cabecera requieren de una
petición INVITE. Esto es fundamentalmente erróneo en el uso real. El apoyo a PRACK no es universal,
en todo sentido, y la inserción de esta etiqueta en la cabecera Requerir conduce a las llamadas fallidas.
5.5 MEDICIONES DE QOS
Se realiza una serie de protocolos de prueba para poder medir la QoS, en este caso específico se evaluó
Telefonía IP. Para las pruebas se usó como base la configuración que implementa el codec G.711, con un
consumo de ancho de banda de 74 kb/s unidireccionales equivalentes a aproximadamente 150kb/s
bidireccionales. La comunicación fue en ambos sentidos (ida y vuelta) y no se usó ninguna técnica de
supresión de silencios.
Telefonía IP se clasifica como Clase de QoS 0. Tiene como límite superior para los parámetros que
determinan su QoS: IPTD, 100 ms; IPDV 50 ms; IPLR, 1%; e IPER, 0.001. Las mediciones se realizaron
en cuatro escenarios, cada uno de ellos con un mayor requerimiento de capacidad de transmisión [18].
• Primer escenario: Se realizó una sola llamada IP, de Softswitch Vs Softswitch que tenía como
propósito obtener una medida de referencia, lo que era factible porque las NGN´s carecían de
cualquier otro tipo de tráfico. En consecuencia, las medidas tomadas son ideales en un entorno de
redes IP.
• Segundo Escenario: Se realizó una llamada IP desde el servidor de aplicaciones (Asterisk) de una
red NGN hacia el Softswitch de la otra NGN.
• Tercer escenario: Se realizan con llamadas IP de Softswitch Vs Softswitch simultáneas diez
llamadas.
• Cuarto escenario: Se realizan con llamadas IP desde el servidor de aplicaciones (Asterisk) de una
red NGN hacia el Softswitch de la otra NGN simultáneas veinte llamadas.
La tabla 5-1. Muestra los resultados obtenidos en las cuatro pruebas realizadas.
Tabla 5-1. Mediciones de QoS para llamadas telefónicas IP (Protocolo SIP)
Parametro Limite Superior Medición Diferencia Medición Diferencia Medición Diferencia Medición Diferencia
IPTD (ms) 100 0,1185 -99,8815 10,8085 -89,1915 11,514 -88,486 15,614 -84,386
IPDV (ms) 50 0,107 -49,893 1,224 -48,776 1,897 -48,103 1,809 -48,191
IPLR (%) 1,00% 0,00% -1,00% 0,00% -1,00% 0,00% -1,00% 0,00% -1,00%
IPER 0,001 0 -0,001 0 -0,001 0 -0,001 0 -0,001
CLASE QoS 0 0 0 0 0 0 0 0 0
TELEFONIA IP (SIP) 1 Llamada Softswitch Vs Softswitch 1 llamada Asterisk Vs Softswitch 10 llamadas Softswitch Vs Softswitch 20 llamadas Asterisk Vs Softswitch
80
A continuación se hace una descripción de los resultados obtenidos.
Los resultados anteriores nos muestran en el primer escenario se nota que las medidas que corresponden a
IPTD e IPDV son de tan solo 0.1185ms y 0.107ms, valores “insignificantes” frente al límite superior de la
clase 0. Estos valores “tan bajos” se explican en la diferencia que existe entre el ancho de banda de la red
(100 Mb/s) y el consumo de una llamada (150 kb/s), y en el hecho de que los elementos de las redes
NGN´s solo estén disponibles únicamente para el tráfico generado por esta llamada IP.
El segundo escenario nos muestra unos valores obtenidos para el IPTD (10.8085ms) e IPDV (1.224ms),
estos valores son bastante mayores a los tomados en la medición anterior, alrededor de 100 y 10 veces,
respectivamente, siguen estando muy por debajo de los límites establecidos. Los otros dos parámetros
evaluados, IPLR e IPER, no cambian de un escenario a otro. Los resultados, son altamente favorables,
algo que obedece a una razón fundamental: El único tráfico existente en la red, al momento de la prueba,
es esta llamada IP, la misma que, como se mencionó, tiene un consumo de ancho de banda de 150 kb/s, un
valor muy inferior al ancho de banda de transmisión de la red NGN.
El tercer escenario las llamadas simultáneas ocupan un ancho de banda de aproximadamente 300 kb/s. Si
se compara el IPTD y el IPDV obtenidos en esta medición, con los presentados en el escenario anterior, de
una llamada IP única, se encuentra que no hay mucha diferencia. La conclusión que surge de esta
observación es que, en este tipo de redes, la variación en el valor de los parámetros de IPTD e IPDV no
depende de la cantidad de llamadas simultáneas, sino de disponibilidad.
En el cuarto escenario se puede comparar con el tercer escenario debido a que los valores están por debajo
del límite, con la premisa de que las redes NGN´s se encuentran disponibles exclusivamente para estas
pruebas.
81
6 CONCLUSIONES
El tema de compartir servicios y aplicaciones en las redes NGN nos pone a pensar en una interconexión de
redes NGN con arquitectura Softswitch y en el caso específico ZTE-PUJ y ANKLA, este proceso conlleva
una serie de metodologías de interconexión y parámetros a tener en cuenta como son: la seguridad, la
señalización, la capacidad de tráfico entre otras; como estamos en una redes NGN netamente académicas
nos permite experimentar diferentes soluciones y realizar una serie de pruebas a nuestra disposición.
La interconexión se culminó con éxito dando así al cumplimiento del objetivo general y a los objetivos
específicos; Dándonos cuenta que no se encontraron problemas de interoperabilidad generados por la
señalización (protocolo SIP), pero esta situación se implementó de un Nodo Captura que fuera capaz de
analizar y modificar la señalización SIP.
La interconexión de las redes NGN de estudio se logró con diferentes elementos de red, como se muestra
en la figura 4-12 en este escenario se logró la implementación con éxito del Protocolo SIP/SDP mediante
una troncal SIP, para la transferencia de toda la señalización entre la dos redes NGN con arquitectura
Softswitch, para compartir todos los servicios con los que cada una de ellas cuenta.
Los diferentes análisis que se realizaron a la señalización del protocolo SIP/SDP se hicieron mediante un
software denominado Nodo Captura el cual se basa en varias RFCs y drafts. Este software nos permitió
realizar un estudio de toda la composición del protocolo SIP y llegado el caso realizar alguna
modificación de la trama SIP, después de toda la investigación de la señalización SIP se llegó a la
conclusión que el protocolo SIP/SDP no presenta ninguna modificación en sus estructuras de tramas en
ninguno de sus mensajes de petición ni de respuesta para la interoperabilidad de las redes NGN; para
probar el funcionamiento del Nodo Captura se realizó algunas simulaciones a la trama SIP para forzar
problemas de interoperabilidad como se describieron en el numeral 2.3 , estas pruebas se implementaron
por medio de un software denominado SIP Inspector dando como resultado el funcionamiento del Nodo
Captura en el análisis y solución de posibles errores encontrados en el protocolo SIP mediante la
simulación.
Se probó la solución del NODO CAPTURA en un escenario totalmente distinto, la interoperabilidad del
fabricante AVAYA con el fabricante genérico, encontrando problemas de interoperabilidad en el primer
fabricante; AVAYA presenta problemas de interoperabilidad con dispositivos de hardware de un
fabricante diferente; el NODO CAPTURA mediante la modificación de la señalización del mensaje de
82
petición PRACK, permito la interoperabilidad de este fabricante con otros dispositivos de VoIP de otro
fabricante genérico.
Por último se realizó algunos análisis de QoS en el funcionamiento de la troncal SIP, generando tráfico
SIP de múltiples conexiones a través del escenario de interoperabilidad montado, dando unos resultados
muy favorables como se muestra en la tabla 5-1.
Después de todo el análisis que se le realizo a la señalización del protocolo SIP, se demostró todo el
potencial que cuenta este protocolo en procesos de interoperabilidad de redes no solo de redes NGN, en
especial los que tiene que ver con comunicaciones unificadas.
Referente a esta parte del proyecto, como línea de trabajo futura seria realizar pruebas de señalización de
peticiones en paralelo en uno o varias redes conjuntamente, para así demostrar la interoperabilidad de toda
una solución de redes que manejas el protocolo SIP.
También habría que desplegar esta aplicación en un entorno NGN basado en arquitecturas IMS.
83
7 BIBLIOGRAFIA
LIBROS Y PUBLICACIONES
[1] Alan B. Johnston, Artech House telecommunications library, “SIP Understanding the session initiation
protocol” Second edition, 2004
[2] KEAGY, Scott, Integración de redes de voz y datos, tercera edición, Cisco Publication, Madrid, 2001
[3] Schulzrinne, H., and E. Wedlund, “Application-Layer Mobility Using SIP,” Mobility Mobile
Computing and Communications Review (MC2R), Vol. 4, No. 3, July 2000.
[4] Franklin D. Ohrtman, JR “Softswitch Architecture for VoIP”, McGraw-Hill, 2004.
[5] Grupo redes NGN. Medición de calidad del servicio en redes de próxima generación (NGN) en
Colombia, Entregables 1 a 4, Centro de Investigación de las Telecomunicaciones CINTEL, 2012.
[6] DÍAZ, Yony Fernando. “Estudio comparativo de las recomendaciones ITU-T G.107, P.862 y P.563
para evaluar la calidad de la voz en redes IP”. Universidad del Valle, Colombia. (2007).
[7] Zohreh Ayatollahi. “Interoperability Problems In Next Generation Network Protocols” IEEE 2008.
[8] Iravani Tabrizipoor, P. Gooran Oreimi, M. Pirhadi, M. Mirzabaghi, Y.Nasr Harandi, and M. Yaghoubi
Waskasi, “Investigation of Basic Services Interoperability Problems in Next Generation Networks",
ECUMN'2007, Toulouse, France, Feb 2007.
[9] KEAGY, Scott, Integración de redes de voz y datos, tercera edición, Cisco Publication, Madrid, 2001
NORMAS
[10] RFC 3261 “SIP: Session Initiation Protocol”, http://www.ietf.org/rfc/rfc3261.txt
[11] RFC 3265 “SIP Specific Events,” http://www.ietf.org/rfc/rfc3265.txt
84
[12] RFC 2327 “SDP: Session Description Protocol,” http://www.ietf.org/rfc/rfc2327.txt
[13] RFC 3372 “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,”
http://www.ietf.org/rfc/rfc3372.txt
[14] RFC 3455 “Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-
Generation Partnership Project (3GPP),” http://www.ietf.org/rfc/rfc3455.txt
[15] UIT-T (Unión Internacional de Telecomunicaciones, Estandarización); “Iniciativa de normalización
mundial de las redes de la próxima generación”.
[16] UIT-T (Unión Internacional de Telecomunicaciones, Estandarización Y.1540, “Servicio de
comunicación de datos con protocolo Internet - Parámetros de calidad de funcionamiento relativos a la
disponibilidad y la transferencia de paquetes de protocolo Internet”
[17] ETSI TS 185 001 V1.1.1 (2005-11), Next Generation Network (NGN) - Quality of Service (QoS)
Framework and Requirements. (2005)
[18] One-way transmission time (recommendation G.114). International Telecommunication Union (ITU),
feb. 1996.
[19] ETSI TISPAN. ES 282 003 Resource and Admission Control Subsystem (RACS) Functional
Architecture. 2006.
[20] UIT-T (Unión Internacional de Telecomunicaciones / Sector de normalización de las
telecomunicaciones). Recomendación Y.1541 (02/2006), Objetivos de calidad de funcionamiento de red
para servicios basados en el protocolo Internet. (2006)
INTERNET
[21] http://www.grid.unina.it/software/ITG/ Emulador de tráfico (Consultado febrero 2013).
[22] http://www.sipcapture.org/ Nodo captura (Consultado enero 2013).
[23] http://www.kamailio.org/w/ Servidor SIP (Consultado febrero 2013).
[24] https://code.google.com/p/captagent/ Agente que captura la señalización SIP (Consultado Enero
2013).
[25] https://sites.google.com/site/sipinspectorsite/ Emulador de tramas SIP (Consultado enero 2013).
85
8 ANEXOS
Anexos adjuntos en un CD.
86
ACRONIMOS
ADSL Asymmetric Digital Subscriber Line
BER Bit Error Rate
D-ITG Distributed Internet Traffic Generator
DNS Domain Name System
ETSI European Telecommunications Standards Institute
HTTP Hypertext Transfer Protocol
IAD Integrated Access Device
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
IP Internet Protocol
IPDV IP Delay Variation
IPER IP Packet Error Ratio
IPDR IP packet duplicate ratio
IPLAR IP Packet Loss Ratio
IPLR IP Packet Loss Ratio
IPTD IP Transfer Delay
ITU International Telecommunication Union
NGN Next Generation Network
QoS Quality of Service
87
RFC Request For Comments
RTCP Real-Time Transport Control Protocol
RTP Real-Time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
UA User Agent
UAC User Agent Client
UAS User Agent Servidor
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
VBR Variable Bit Rate
DISEÑO E IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTERCONEXIÓN DE REDES NGN
MEDIANTE EL PROTOCOLO SIP
ING. WILLIAM FERNANDO SANCHEZ PACHECO
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
BOGOTÁ D.C.
MAYO DE 2013
2
DISEÑO E IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTERCONEXIÓN DE REDES NGN
MEDIANTE EL PROTOCOLO SIP
ING. WILLIAM FERNANDO SANCHEZ PACHECO
Trabajo de profundización para optar por el título de
Magister en Ingeniería Electrónica
Director:
LUIS CARLOS TRUJILLO ARBOLEDA
Ingeniero Electrónico, M.Sc.
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
BOGOTÁ D.C.
MAYO DE 2013
3
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
MAESTRÍA EN INGENIERIA ELECTRÓNICA
RECTOR MAGNÍFICO: P. JOAQUÍN SÁNCHEZ GARCÍA S. J.
DECANO ACADÉMICO: Ing. JORGE SANCHEZ, Ph.D.
DECANO DEL MEDIO UNIVERSITARIO: P. SERGIO BERNAL RESTREPO S. J.
DIRECTOR DE LA MAESTRÍA: Ing. CESAR LEONARDO NIÑO. PH.D.
DIRECTOR DEL TRABAJO DE GRADO: Ing. LUIS CARLOS TRUJILLO ARBOLEDA, MSc.
4
NOTA DE ACEPTACIÓN
Nota de aceptación
______________________
______________________
______________________
_____________________
Presidente del Jurado
_____________________
Jurado
_____________________
Jurado
Bogotá, Mayo de 2013
5
ARTÍCULO 23 DE LA RESOLUCIÓN No. 13 DE JUNIO DE 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de
grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque los
trabajos no contengan ataques o polémicas puramente personales. Antes bien, que se vea en ellos el
anhelo de buscar la verdad y la justicia”.
Artículo 23 de la Resolución No. 13, del 6 de julio de 1946,
por la cual se reglamenta lo concerniente a Tesis y Exámenes
de Grado en la Pontificia Universidad Javeriana.
6
DEDICATORIA
Agradezco a mi mamá, a mis hermanos
Y en general a toda mi familia que me
Apoyo en todo mí proceso de
Formación académica.
William Fernando Sánchez Pacheco
7
TABLA DE CONTENIDO
1. INTRODUCCION ......................................................................................................................... 14
2. MARCO TEORICO ....................................................................................................................... 16
2.1. REDES DE NUEVA GENERACION (NGN) ......................................................................... 16
2.1.1. Componentes de las redes NGN. ..................................................................................... 17
2.1.2. Características de las redes NGN ..................................................................................... 18
2.1.3. Servicios y aplicaciones de las redes NGN ...................................................................... 20
2.1.3.1. Servicios de las redes NGN ..................................................................................... 20
2.1.3.2. Aplicaciones de las redes NGN................................................................................ 21
2.1.4. Arquitectura de Softswitch/MGC .................................................................................... 21
2.1.5. Arquitectura IMS/MGC .................................................................................................. 23
2.2. PROTOCOLO SIP (SESSION INITIATION PROTOCOL) ................................................... 27
2.2.1. Componentes de SIP ....................................................................................................... 29
2.2.2. Mensajes de Petición ....................................................................................................... 30
2.2.2.1. Extensiones del Protocolo SIP ................................................................................. 31
2.2.2.2. Estructuras e mensajes. ............................................................................................ 32
2.2.3. Mensajes de Respuesta .................................................................................................... 32
2.2.4. Cabecera SIP .................................................................................................................. 34
2.2.5. Cuerpo de los mensajes SIP (protocolo de descripción de la sesión SDP) ........................ 36
2.3. PROBLEMAS GENERALES DE INTEROPERABILIDAD .................................................. 37
2.3.1. Problemas específicos de interconexión del protocolo SIP ............................................... 38
2.3.2. Problemas específicos de interconexión del protocolo SIP e SDP .................................... 39
3. ESPECIFICACIONES ................................................................................................................... 40
3.1 Red NGN ZTE-PUJ ............................................................................................................ 42
3.2 Red NGN ANKLA ............................................................................................................. 43
3.3 Infraestructura de Interconexión redes NGN´s. .................................................................... 44
3.3.1 Nodo Captura .............................................................................................................. 44
3.3.2 Generador de tráfico .................................................................................................... 46
3.3.3 Simulador trama SIP ................................................................................................... 47
3.3.3.4 Firewall ...................................................................................................................... 47
4 DESARROLLOS. .......................................................................................................................... 48
8
4.3 ANÁLISIS DEL PROTOCOLO SIP. ...................................................................................... 48
4.3.3 Análisis del protocolo SIP ZTE-PUJ ............................................................................... 48
4.3.4 Análisis del protocolo SIP ANKLA................................................................................. 54
4.3.5 Comparación de las dos redes NGN´s ............................................................................. 59
4.4 PRUEBAS DE INTEROPERABILIDAD ............................................................................... 59
4.4.3 Escenario de interoperabilidad ZTE-ANKLA .................................................................. 59
4.4.4 VPN y sus características de interoperabilidad. ................................................................ 65
4.4.4.4 VPN Sitio a Sitio utilizando NAT ................................................................................ 66
4.4.4.5 Seguridad VPN IPSec ................................................................................................. 66
4.4.4.6 Descripción de los Parámetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y ANKLA……………………………………………………………………………………………………………………………………67
4.5 METODOLOGÍA DE ANÁLISIS DE INTEROPERABILIDAD ............................................ 67
4.5.3 Identificación y reconocimiento ...................................................................................... 68
4.5.3.4 Llamada Simple Entre Dispositivos IP A Través De Troncal SIP ................................. 69
4.5.3.5 Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones ...................... 70
4.6 INTEGRACIÓN GENERADOR DE TRÁFICO, NODO CAPTURA Y EMULADOR DE TRAMA SIP ...................................................................................................................................... 71
4.6.3 Integración Nodo Captura y Generador de Tráfico .......................................................... 71
4.6.4 Emulación de la trama SIP y Nodo Captura. .................................................................... 72
5 ANALISIS DE RESULTADOS ..................................................................................................... 73
5.3 CARACTERIZACION NODO CAPTURA ............................................................................ 73
5.3.3 Descripción del funcionamiento Nodo Captura ................................................................ 73
5.3.4 Características del hardware Nodo Captura ..................................................................... 74
5.3.5 Análisis Nodo Captura .................................................................................................... 74
5.3.6 Emulación Trama SIP para el Comportamiento del Nodo Captura. .................................. 76
5.3.6.4 SIP campo y longitudes mensaje Proxy SIP. ................................................................ 77
5.3.6.5 Parámetros TEL-URI .................................................................................................. 77
5.3.6.6 Invite –Reinvite (Subscribe) ........................................................................................ 77
5.3.6.7 Valor De Cabecera PRACK ........................................................................................ 78
5.4 NODO CAPTURA PLATAFORMA AVAYA ....................................................................... 78
5.5 MEDICIONES DE QOS ........................................................................................................ 79
6 CONCLUSIONES ......................................................................................................................... 81
7 BIBLIOGRAFIA ........................................................................................................................... 83
9
8 ANEXOS ....................................................................................................................................... 85
ACRONIMOS ....................................................................................................................................... 86
10
LISTA DE FIGURAS
Figura 2-1. Evolución de la Red Clásica a la NGN – Simplificación de la torre de Protocolos…………..17
Figura 2-2. Arquitectura de las redes de nueva generación (NGN)………………………………………..18
Figura 2-3. Separación de los servicios y el transporte en redes NGN…………………………………….18
Figura 2-4. Red NGN con arquitectura Softswitch…………………………………………………….......23
Figura 2-5. Arquitectura de redes y servicios IMS………………………………………………………...24
Figura 2-6. Vista general de la arquitectura IMS…………………………………………………………..26
Figura 2-7. Posición de SIP dentro de la pila de protocolos……………………………………………….28
Figura 2-8. Flujo de mensajes de una Sesión SIP………………………………………………………….28
Figura 2-9. Flujo de mensajes de una Sesión SIP con un analizador de protocolos……………………….29
Figura 2-10. Cliente SIP y Componentes del Sistema del Servidor……………………………………….29
Figura 3-1. Protocolos de la red NGN…………………………………………………………………..…41
Figura 3-2. Arquitectura básica de interconexión las diferentes redes NGN´s……………………………41
Figura 3-3. Arquitectura Red NGN ZTE-PUJ…...…………………………………………………….......42
Figura 3-4. Arquitectura ANKLA………………………………………………………………………….44
Figura 3-5. Arquitectura Nodo Captura…………………………………………………………………....45
Figura 4-1. Comunicación básica del protocolo SIP de la red NGN ZTE-PUJ …………………………...49
Figura 4-2. Comunicación básica del protocolo SIP de la red NGN ANKLA………………………...…..54
Figura 4-3. Estructura de un servidor Proxy SIP………………………………………………………......61
Figura 4-4. Estructura de mensajes SIP con un servidor Proxy SIP………………………………………62
Figura 4-5. Arquitectura PROXY de interconexión las diferentes redes NGN´s de estudio………………63
Figura 4-6. Llamada saliente: Mensaje INVITE + SDP con timbrado local……………………………...64
11
Figura 4-7. Llamada saliente: Mensaje INVITE + SDP con conexión temprana de media……………....64
Figura 4-8. Diagrama básico de la VPN las diferentes redes NGN´s………………………………….......65
Figura 4-9. Diagrama básico de NAT las diferentes redes NGN´s………………………………………...66
Figura 4-10. Configuración VPN de la Red NGN ZTE-PUJ y la red NGN ANKLA……………………68
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexión de usuarios las diferentes redes
NGN´s……………………………………………………………………………………………………...69
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexión de diferentes componentes de redes
NGN´s……………………………………………………………………………………………………...70
Figura 4-13. Generador de tráfico SIP a través de la troncal SIP de dos redes NGN……………………72
Figura 4-14. Emulador de tráfico SIP……………………………………………………………………...72
Figura 5-1. Generación de tráfico SIP las diferentes redes NGN´s………………………………………..75
Figura 5-2. Traza de una de las pruebas de interconexión de búsqueda de llamada se sesión de las
diferentes NGN´s…………………………………………………………………………………………..75
Figura 5-3. Diagrama de secuencia de la señalización SIP de una llamada de Softswitch Vs
Softswitch………………………………………………………………………………………………….76
Figura 5-4. Captura de traza de la señalización SIP de una llamada de Softswitch Vs Softswitch……76
12
LISTA DE TABLAS
Tabla 2-1. Categorías de Respuesta SIP…………………………………………………………………...33
Tabla 2-2. Código de Respuesta SIP……………………………………………………………………….34
Tabla 2-3. Elementos de la Cabecera SIP………………………………………………………………....35
Tabla 2-4. Abreviaturas de Nombre de Cabecera………………………………………………………….35
Tabla 2-5. Atributos de SDP…………………………………………………………………………….....36
Tabla 5-1. Mediciones de QoS para llamadas telefónicas IP (Protocolo SIP)…………………………..…79
13
ANEXOS
Anexo 1. Señalización SIP en diversos escenarios.
Anexo 2. Código fuente NODO CAPTURA.
Anexo 3. Archivos generados para medir QoS.
Anexo 4. Manual de instalación NODOD CAPTURA.
Anexo 5. Manual de instalación Generador de Tráfico.
Anexo 6. Documentación de interconexión redes NGN´s.
Anexo 7. Emulaciones Trama SIP.
14
1. INTRODUCCION
En el contexto actual y mundial del sector de las telecomunicaciones, la voz y los datos como redes
independientes, han dejado de ser la fuente de ingresos más importante para la gran mayoría de operadores
y fabricantes; es por ello que ha surgido la necesidad de aumentar e innovar en el portafolio de servicios
que estos ofrecen.
Con la aparición de una nueva generación de arquitecturas de red (todo IP), emerge también un nuevo
portafolio de servicios, en los que se mezclan voz y datos; estar a la vanguardia de esta nueva generación
de redes (NGN1), se convierte en un factor determinante de competitividad para los diferentes actores del
sector de las Telecomunicaciones y las Tecnologías de Información.
Al ser un mercado creciente encontramos múltiples operadores y fabricantes, que deben experimentar un
proceso de interconexión de elementos de red NGN, a través de distintos protocolos y además con otras
redes NGN, (alianza estratégica entre operadores y fabricantes) este escenario les origina numerosos
problemas de interconexión de equipos de red NGN por el protocolo SIP.
Las NGN al ser independiente la capa de control de la capa de transporte, aportan muchas ventajas a
aplicaciones sensibles a retardos como pueden ser IPTV, VoIP. La ETSI2 en su comité TISPAN3 ha
seleccionado el protocolo SIP (Protocolo de Inicio de Sesión), para la señalización en las redes NGN.
El protocolo SIP, es el que permite establecer, modificar y terminar “sesiones multimedia”; al ser el
protocolo determinado para la señalización de las redes NGN´s, el problema está en que los diferentes
fabricantes de redes de Nueva Generación implementan el protocolo SIP para la señalización de sus redes,
pero cada uno lo implementa con alguna restricción o parámetro adicional, esto se hace debido a la
flexibilidad que tiene el RF3261 para no permitir la integración de partes de diferentes fabricantes, esto
obliga a interactuar con su solo proveedor para la totalidad de la integración de la red.
En este trabajo de grado diseña e implementa una solución de interconexión de dos redes NGN (Centro de
Tecnologías de Telecomunicaciones ZTE-PUJ “Pontificia Universidad Javeriana” y el Laboratorio
1 Redes de Nueva Generación
2 Instituto Europeo de Normas de Telecomunicaciones
3 Telecomunicaciones e Internet Servicios convergentes y protocolos de red avanzada
15
ANKLA). El desarrollo se basó en cuatro partes (la interconexión de las redes NGN´s mediante una
conexión de internet VPN, un nodo captura que realiza el escucha de toda la señalización SIP, una
verificación de su estructura y por último se emplea un generador de trafico de VoIP para ver generar
grandes flujos de señalización con el protocolo SIP).
El objetivo general de este proyecto es; “Diseñar e implementar una solución de interconexión de redes
NGN mediante el protocolo SIP”, para este fin se cumplieron los siguientes objetivos específicos:
• Estudiar y analizar los parámetros del protocolo SIP en la interconexión redes NGN ZTE-PUJ y
ANKLA.
• Definir e Implementar un módulo basado en el protocolo SIP (software) que permita la
interconexión de redes NGN ZTE-PUJ y ANKLA.
• Evaluar la funcionalidad y el desempeño del módulo (software) del protocolo SIP, a través de las
pruebas de operatividad de las redes NGN ZTE-PUJ y ANKLA.
El documento se organiza de la siguiente forma: en el MARCO TEÓRICO, numeral 2, se describe de
manera general las redes NGN y el protocolo SIP. En las ESPECIFICACIONES, numeral 3, se describe
de forma general el desarrollo de la interconexión de las dos redes ZTE-PUJ y ANKLA y se referencia la
descripción de cada una de las redes NGN. En los DESARROLLOS, numeral 4, se explica cómo se
analizó el protocolo SIP en cada una de las redes NGN y como se implementó la interconexión para
posteriormente realizar la verificación, validación de la interconexión. En el numeral 5, se muestran los
resultados obtenidos, y en el numeral 6 se concluye acerca de la puesta en marca de la interconexión y el
buen funcionamiento de la misma.
16
2. MARCO TEORICO
En el marco teórico se hace un recuento de las diferentes arquitecturas y protocolos de comunicación que
son necesarios para entender el contexto de interconexión de redes NGN.
2.1. REDES DE NUEVA GENERACION (NGN)
En Colombia se ha iniciado la migración de la infraestructura de las redes de los operadores de
telecomunicaciones, para ofrecer los servicios de voz y datos bajo una infraestructura unificada sobre el
protocolo de Internet (Internet Protocol, IP). [4].
El Protocolo Internet (IP) que proporciona una plataforma común para todos los servicios de TIC, está
desvaneciendo al mismo tiempo el concepto de la denominada “larga distancia”. La figura 2-1 muestra lo
que ha ido sucediendo en los sectores de telecomunicaciones y audiovisual, donde por efecto de la
convergencia de servicios, redes, industria y dispositivos las redes que antes eran separados, se consolidan
ahora alrededor de una sola plataforma de acceso, obviando la multiplicidad de redes característica del
siglo pasado. El usuario ahora no tiene conciencia de las redes que le proporcionan los servicios
convergentes y en ocasiones lo único que percibe es si el medio de acceso es fijo o inalámbrico. Lo que
hace dos décadas se intentó conseguir con éxito muy limitado mediante la Red Digital de Servicios
Integrados (RDSI), es decir, múltiples servicios a través de un solo punto de acceso, está siendo
materializado hoy en día por las redes de nueva (o próxima) generación (“Next Generation Networks” o
NGNs por sus siglas en inglés) con núcleo IP (Internet Protocol).
La definición de la UIT para NGN es: “Red basada en paquetes que permite prestar servicios de
telecomunicación y en la que se pueden utilizar múltiples tecnologías de transporte de Banda Ancha
propiciadas por la QoS, y en la que las funciones relacionadas con los servicios son independientes de las
tecnologías subyacentes relacionadas con el transporte. Permite a los usuarios el acceso sin trabas a
redes y a proveedores de servicios y/o servicios de su elección. Se soporta movilidad generalizada que
permitirá la prestación coherente y ubicua de servicios a los usuarios.” [15].
17
Figura 2-1. Evolución de la Red Clásica a la NGN – Simplificación de la torre de Protocolos4
2.1.1. Componentes de las redes NGN.
Una red NGN consta de cuatro niveles que dan flexibilidad y escalabilidad a la red, cada nivel se conecta
mediante interfaces abiertas que permiten la interconexión e integración de nuevos servicios. Estos cuatro
niveles son los siguientes [4]:
• Servicios: Esta interfaz es la encargada de la conexión “lógica” con los usuarios.
• Control: Interfaz intermedia que permite la comunicación entre los niveles de servicio y de
transporte (Softswitch e IMS).
• Transporte: ofrece la conectividad y de calidad de servicio requeridos por los servicios.
• Acceso: Cualquier acceso de banda ancha para hacer llegar al usuario las aplicaciones solicitadas.
La tecnología usada puede ser en cable (fibra o cobre) o inalámbrica.
4 Tomado de Diseño de políticas óptimas en un entorno de convergencia de los medios de comunicación y las telecomunicaciones
“OSIPTEL”
18
Figura 2-2. Arquitectura de las redes de nueva generación (NGN)5
2.1.2. Características de las redes NGN
El factor diferenciador de las redes NGN´s es la separación entre la capa de transporte y la capa de
servicios que ofrece, de modo que los servicios se puedan ofrecer por separado y evolucionar
independientemente de la capa de transporte como se muestra en la siguiente figura.
Figura 2-3. Separación de los servicios y el transporte en redes NGN6
5 Tomado de Telefónica, 2006 6 Tomado de UIT Y.2011
19
En primer lugar, hay un conjunto de funciones de transporte que se encargan únicamente del transporte de
la información digital de cualquier tipo entre dos puntos físicamente separados. El transporte puede estar
formado por un conjunto complejo de redes, que constituyen las capas 1 a 3 en el modelo de referencia
básico OSI de 7 capas. Las funciones de transporte proporcionan la conectividad.
En particular, las funciones de transporte son:
• Conectividad entre usuarios;
• Conectividad entre el usuario y la plataforma de servicios;
• Conectividad entre plataformas de servicio.
Las plataformas de servicios proporcionan los servicios de usuario, por ejemplo, el servicio de telefonía,
servicio web, etc. Los servicios pueden estar formados por un conjunto complejo de plataformas de
servicios físicamente distribuidos, o, en el caso más sencillo, únicamente las funciones de servicio entre
dos ubicaciones de usuarios extremo.
En segundo lugar existe un conjunto de funciones de aplicación relacionadas con el servicio solicitado.
Los servicios pueden ser, por ejemplo, servicios de voz (incluido el servicio de telefonía), servicios de
datos (no limitándose éste a los servicios basados en la web), o servicios de vídeo (no limitándose
tampoco a las películas y a los programas de televisión), o una combinación de éstos (por ejemplo,
servicios multimedia, como la telefonía vídeo y los juegos).
Dado que existen muchas maneras de clasificar los servicios (por ejemplo, servicios en tiempo real/no en
tiempo real y servicios unidifusión/multidifusión/radiodifusión), en la figura 2-1 se proporciona un
ejemplo de lista de servicios (voz, datos y videos) que se prevé ofrecerán las redes de próxima generación
[15].
Actualmente las arquitecturas funcionales de las redes NGN implementadas son::
• SOFTSWITCH/MGC: También es conocido como Call Agent o Media Gateway Controller
(MGC). Es el mecanismo que provee el “control de provisión de servicio” en la red. Está a cargo
del Control de llamadas, maneja el control de las Pasarelas de Medio (Acceso y/o Enlace) vía
protocolo H.248. Realiza la función de una pasarela de señalización o usa una pasarela de
señalización para trabajar conjuntamente con la red de señalización PSTN N7. Provee conexión a
los servidores de Red inteligente/aplicaciones para proveer los mismos servicios que los
disponibles para los abonados TDM.
20
• IMS/MGC: La arquitectura genérica de IMS (IP Multimedia Subsystem) soporta la comunicación
entre equipos que utilizan SIP para la señalización y la administración de sesiones, además de los
protocolos ‘Diameter’ y Megaco/H.248’ para operaciones y manejo de recursos multimedia
respectivamente. Parte fundamental de la arquitectura IMS está compuesta por los servidores de
aplicación, quienes se encargan de: invocar los servicios, identificar qué señalización es requerida
y de qué forma los servicios interactúan ente sí.
2.1.3. Servicios y aplicaciones de las redes NGN
Las redes NGN pueden proveer gran cantidad de servicios y aplicaciones de forma individual o en
conjunto por tal motivo se realizará una descripción de cada uno de servicios y aplicaciones de redes
NGN.
2.1.3.1. Servicios de las redes NGN
Los servicios de las redes NGN se explican a continuación:
• Telefonía: NGN soporta la necesidad varios servicios de telefonía existentes (ej, Llamada en
espera, llamada tripartita, reenvío de llamadas, reloj despertador, identificador de llamadas, etc.)
• Servicios de datos: Permite el establecimiento de la conectividad en tiempo real entre varios
dispositivos finales, con varias características de valor agregado.
• Servicios multimedia: Permite que los usuarios interactúen utilizando voz, video y/o datos.
• Virtual Private Networks (VPNs): Mejora las capacidades de las empresas al permitir una
cobertura amplia, geográficamente dispersa, al combinar las redes privadas existentes con
porciones de la red pública.
• Computación pública en la red: Provee servicios públicos en la red para negocios y
consumidores.
• Mensajería unificada: Soporta la entrega de mensajes de voz, correo electrónico, fax y
mensajería instantánea a través de interfaces comunes.
• Comercio electrónico: Permite a los consumidores la compra de bienes y servicios sobre la red.
Servicios para empresas y compras desde el hogar pertenecen a esta categoría de servicios.
• Servicios de Call Center: Un suscriptor puede realizar una llamada a un centro de contacto para
la adquisición de nuevos productos o realizar consultas.
• Juegos interactivos: Ofrece a los consumidores una forma para conocer y establecer sesiones de
juegos interactivos en línea.
21
• Realidad Virtual Distribuida: Se refiere a la tecnología que genera representaciones de los
eventos del mundo real, personas, lugares, experiencias, etc.
• Domótica: Con la llegada los electrodomésticos inteligentes y de las redes al hogar, estas
aplicaciones pueden monitorear y controlar los sistemas de entretenimiento caseros y otros
aparatos electrodomésticos.
• Consultoría: Involucra la publicidad, para proveer información que permita generar un punto de
contacto entre proveedores y consumidores.
2.1.3.2. Aplicaciones de las redes NGN
Las aplicaciones de las redes NGN se enuncian a continuación:
• VoIP.
• Web Browsing.
• Chat.
• Mensajería Instantanea.
• WAP Browsing.
• Mensajería Multimedia.
• Video llamadas.
• Video Broadcasting.
• Video conferencia.
• IP PBX/Centrex.
• Email.
• Video por demanda (Peliculas, Juegos, Noticia, Deportes, Entrenamiento).
2.1.4. Arquitectura de Softswitch/MGC
Esta es una arquitectura muy significativa dentro de la estructura general de una NGN, ya que con esta
infraestructura de red hace posible el concepto de red de próxima generación.
“Es un dispositivo que provee control de llamada y servicios inteligentes para redes de conmutación de
paquetes. Un Softswitch sirve como plataforma de integración para aplicaciones e intercambio de
servicios. El Softswitch es capaz de transportar tráfico de voz, datos y vídeo de una manera más eficiente
22
que los equipos existentes, habilita al proveedor de servicio para soportar nuevas aplicaciones multimedia
integrando las existentes con las redes inalámbricas avanzadas para servicios de voz y Datos.”7
Un Gateway Controller combinado con el media Gateway y el Signalling Gateway representan la mínima
configuración de un Softswitch. El elemento controlador es frecuentemente conocido como Media
Gateway Controller (MGC). A continuación se describen los componentes de un Softswitch.
• GATEWAY CONTROLLER: Es la unidad funcional del Softswitch. Mantiene las normas para el
procesamiento de llamadas, por medio del Media Gateway y el Signalling Gateway los cuales
ayudan a mejorar su operatividad. El responsable de ejecutar el establecimiento y desconexión de
la llamada del Signalling Gateway. Frecuentemente esta unidad es referida como Call Agent o
Media Gateway Controller. Algunas veces el Call Agent es referido como el centro operativo del
Softswitch. Este componente se comunica con las otras partes del Softswitch y componentes
externos usando diferentes protocolos.
• SIGNALLING GATEWAY: Sirve como puente entre la red de señalización SS7 y los nodos
manejados por el Softswitch en la red IP.
• MEDIA GATEWAY: Actualmente soporta Multiplexación por división de tiempo (TDM) para
transporte de paquetes de voz al switch. Las aplicaciones de Codificación de voz, Decodificación
y compresión son soportadas, así como las interfaces de la Red telefónica pública (PSTN) y los
protocolos CAS e ISDN.
• MEDIA SERVER: Mejora las características funcionales del Softswitch, si es requerido soporta
Procesamiento Digital de Señales (DSP) así como la funcionalidad de la Respuesta de voz
interactiva (IVR).
• FEATURE SERVER: Controla los datos para la generación de la facturación, usa los recursos y
los servicios localizados en los componentes del Softswitch.
• SERVICES TARGETED: realiza funciones como traslación de direcciones, enrutamiento, IVR,
emergencia, llamadas en espera entre otras.
7 Tomado de RIOS, Javier y GARCIA, Moraima, Softswitch, febrero 2004
23
• SERVICE INTERFACE: Proporciona soporte para servicios suplementarios y clases de
servicios. Posee una arquitectura independiente de señalización, soporta protocolos como SIP,
H.323, SS7 e ISDN.
Un Softswitch puede contener uno o más componentes, sus funciones pueden residir en un sistema o
expandirse a través de varios sistemas como se muestra en la figura 2-4.
Figura 2-4. Red NGN con arquitectura Softswitch
2.1.5. Arquitectura IMS/MGC
La arquitectura genérica del IMS fue creada por 3GPP8 soporta la comunicación entre equipos que utilizan
SIP para la señalización y la administración de sesiones, además de los protocolos SIP, SDP,
DIAMETER, RTP, RTCP, RSVP y DiffServ, para operaciones y manejo de recursos multimedia
respectivamente. Parte fundamental de la arquitectura IMS está compuesta por los servidores de
aplicación, quienes se encargan de: invocar los servicios, identificar qué señalización es requerida y de
qué forma los servicios interactúan ente sí.
La arquitectura de NGN IMS/MGC suministra acceso a cualquier servicio sin importar el tipo de medio,
usa el plano de control común y trabaja para cualquier tipo de medio, existe un único plano de control para
voz, datos, video y cualquier otro tipo de servicio que requiera el usuario, el plano de control de IMS no
8 3rd Generation Partnership Project es una colaboración de grupos de asociaciones de telecomunicaciones.
24
necesita ninguna modificación, ni ninguna nueva tecnología para un nuevo tipo de medio y todo es
controlado por un protocolo de control de sesiones SIP.
En la siguiente figura se encuentra una red NGN con arquitectura IMS.
Figura 2-5. Arquitectura de redes y servicios IMS9
Call Session Control Function (CSCF)
Esta entidad agrupa tres elementos que son el serving (CSCF), proxy (CSCF), y el interrogating (CSCF).
El elemento Serving CSCF administra las sesiones SIP y coordina con otros elementos de la red el control de las llamadas/sesiones. El S-CSCF es responsable por las siguientes funciones:
• Registro SIP – procesa solicitudes de registro SIP (SIP REG de datos y condición de suscriptores
durante la duración de la sesión de registro;
• Control de la Sesión – ejecuta el establecimiento de la llamada/sesión, modificación y
terminación;
• Control de Servicio – interactúa con los Servidores de Aplicación (Application Server) para el
soporte de servicios y aplicaciones;
• Monitoreo de la llamada y generación de registros de tarifación;
• Provee seguridad para la sesión.
9 Tomado de www.3gpp.org/
25
El Proxy CSCF es el primer contacto para que un móvil SIP obtenga acceso a la red IMS a partir de una
red orientada a paquetes. El elemento P-CSCF:
• Provee el enrutamiento SIP entre los móviles SIP y la red IMS;
• Ejecuta una política de control definida por la operadora de la red;
• Coordina con la red de acceso, el control de recursos y calidad de las llamadas/sesiones (QoS);
• Adicionalmente, los operadores pueden ofrecer localmente servicios controlados por el PCSCF.
Para los servicios ofrecidos por la red IMS de origen (Home Network ), el PCSCF revisa la
señalización SIP para el servidor IMS en la red de origen.
El Interrogating-CSCF es el punto de contacto entre la red IMS y todas sus conexiones. Pueden existir
múltiplos I-CSCF en una red. Las funciones ejecutadas por el I-CSCF son:
• Designar un S-CSCF para un usuario ejecutando un registro SIP;
• Enrutar una petición SIP recibida de otra red en dirección al S-CSCF;
• Obtener del HSS (Home Subscriber Subsystem) la dirección del S-CSCF;
• Enrutar una petición SIP o respuesta para la designación óptima del MGW (Home Control of
roamers).
• Enviar peticiones/respuestas SIP al I-CSCF en una red de otro operador para designación óptima
de un Media Gateway (MGW), para terminación de una llamada en la red pública conmutada
(STFC).
• BREAKOUT GATEWAY CONTROL FUNCTION (BGCF): El BGCF selecciona la red en la
cual el acceso a la red pública conmutada (STFC) debe ocurrir. Si el BGCF determina que el
acceso va a ocurrir en la misma red en donde el BGCF está localizado, entonces el BGCF
selecciona un MGCF. El MGCF será responsable por la interoperabilidad con la red STFC. Si el
punto de acceso está en otra red, el BGCF enviará la señalización de esta sesión a un BGCF o
MGCF (dependiendo de la configuración) en la otra red. El objetivo final es minimizar el
recorrido de la llamada/sesión.
• MEDIA GATEWAY CONTROL FUNCTION (MGCF): El MGCF provee la función de
interoperabilidad de la señalización entre los elementos de la red IMS y las redes legadas (STFC).
El MGCF controla un conjunto de MGWs a través de la señalización H.248. La señalización
H.248 permite el establecimiento de recorridos para las sesiones que necesitan
interfuncionamiento (bajo la perspectiva de tráfico) entre la STFC y la red IMS.
26
• MULTIMEDIA RESOURCE FUNCTION CONTROLLER (MRFC): El MFRC controla los
recursos de media del elemento Función de Recursos Multimedia Procesador (MRFP). Por
ejemplo, recursos necesarios para proveer tonos, anuncios y conferencia.
• SIGNALING GATEWAY: Provee la conversión de señalización en ambas direcciones en la capa
de transporte entre SS7 y señalización basada en IP (por ejemplo ISUP/SS7 e ISUP/SCTP/IP).
• POLICY DECISION FUNCTION (PDF): PDF es la función lógica que implementa la decisión
en relación a la política a ser aplicada, y hace uso de mecanismos de QoS en la capa de
conectividad IP.
• HOME SUBSCRIBER SERVER (HSS): El HSS contiene la principal base de datos, con los
datos de todos los usuarios (incluyendo servicios autorizados), el cual varias entidades lógicas de
control (CSCF) acceden a los suscriptores. El HSS contiene los datos del usuario, que son pasados
al S-CSCF, y almacena la información temporaria con la localización del S-CSCF donde el
usuario está registrado en un dado momento.
Figura 2-6. Vista general de la arquitectura IMS10
10
Tomado de www.3gpp.org
27
2.2. PROTOCOLO SIP (SESSION INITIATION PROTOCOL)
SIP es un protocolo especificado por la IETF en el RFC 3261[10], además es aceptado como un protocolo
estándar por la organización 3GPP y forma parte de la arquitectura de NGN “Redes de Nueva
Generación”. Además SIP es usado globalmente como protocolo de señalización para VoIP.
Este protocolo se ubica en la capa aplicación y permite a las terminales IP establecer, en rutar, modificar y
cerrar sesiones de comunicaciones a través de redes IP; SIP por sí mismo no garantiza ni reserva ancho de
banda para la sesión ni provee calidad servicio (QoS) y no define un mecanismo de entrega de los
paquetes que transportan la información de la sesión. SIP está diseñado para trabajar independientemente
de la capa de transporte, puede ser transportado sobre TCP o UDP.
Utiliza el modelo de Internet ocupando ciertas funcionalidades de protocolos de Internet existentes tales
como HTTP (Hyper Text Transport Protocol) y SMTP (Simple Mail Transfer Protocol).
SIP se basa en el modelo cliente/servidor como HTTP. Para el direccionamiento utiliza el concepto
“Uniform Resource Locutor “o “URL SIP” que es similar a una dirección E-mail. Usa estas direcciones de
tipo correo electrónico para identificar a los usuarios en lugar de los dispositivos que los utilizan, de esta
manera cada participante en una red SIP es reconocido por una dirección, es decir por medio de una URL
SIP; logrando la independencia del dispositivo, y sin hacer distinción alguna entre voz y datos, teléfono u
ordenador.
Para permitir establecer una sesión entre dos terminales, SIP provee cinco servicios de señalización:
• Localización de los terminales
• Invitación a la sesión
• Intercambio de información de media para establecer la sesión
• Modificación de sesiones existentes
• Terminación de sesiones
Como ya se dijo SIP es un protocolo presente en la capa de aplicación diseñado de forma vertical, es decir
que es hospedado sobre otros protocolos para poder establecer adecuadamente las sesiones de multimedia
y el a su vez contiene un protocolo para describir los parámetros de inicialización de los flujos multimedia
SDP (protocolo de descripción de sesión).
28
Figura 2-7. Posición de SIP dentro de la pila de protocolos [1].
El protocolo SIP únicamente se utiliza para la señalización y no reserva recursos, y en consecuencia, no
puede asegurar la calidad de servicio. Una vez que la sesión esté establecida, los participantes
intercambian directamente su tráfico audio/video a través del protocolo Real-Time Transport Protocol
(RTP).
En las figuras 2-8 y 2-9 se explica de manera sencilla cómo se lleva a cabo una sesión SIP entre dos
usuarios y se representan las funciones básicas de SIP: localización del terminal, señal de la intención de
un usuario de comunicarse, negociación de los parámetros de la sesión a establecerse y terminación de la
sesión una vez establecida.
Figura 2-8. Flujo de mensajes de una Sesión SIP [10].
29
Figura 2-9. Flujo de mensajes de una Sesión SIP con un analizador de protocolos.
De esta manera SIP por medio de mensajes de petición y de respuesta provee la señalización necesaria
para el establecimiento y terminación de la llamada.
2.2.1. Componentes de SIP
SIP define los componentes que se muestra en la siguiente figura:
Figura 2-10. Cliente SIP y Componentes del Sistema del Servidor [2].
El Servidor Proxy (Proxy Server): este servidor recibe solicitudes de clientes que son resueltas por el
mismo servidor o las enruta hacia otros servidores. Los servidores Proxy SIP pueden tener un
reconocimiento local de los agentes de usuario desde un registrador SIP. Además pueden conocer varias
30
alternativas para localizar a un agente de usuario, y pueden intentar cada una de ellas en un proceso de
bifurcación que puede ser paralelo o secuencial.
El Servidor de Re direccionamiento (Redirect Server): este servidor acepta solicitudes SIP, traduce la
dirección SIP de destino en una o varias direcciones de red y las devuelve al cliente. De manera contraria
al ProxyServer, el Redirect Server no encamina las solicitudes SIP.
En el caso de la devolución de una llamada, el Proxy Server tiene la capacidad de traducir el número del
destinatario recibido en el mensaje SIP, a un número de reenvió de llamada y encaminar la llamada a este
nuevo destino, y eso de manera transparente para el cliente de origen; para el mismo servicio, el Redirect
Server devuelve el nuevo número de reenvió al cliente de origen quien se encarga de establecer una
llamada hacia este nuevo destino.
El Agente Usuario (UserAgent) o “UA”: se trata de una aplicación sobre un equipo de usuario que emite
y recibe solicitudes SIP. Se materializa por un software instalado sobre un « UserEquipment » o UE (PC,
teléfono IP). Los Clientes de agentes del usuario (UAC) envían peticiones SIP a la parte llamante, y los
Servidores de agentes del usuario (UAS) reciben las respuestas de la parte llamada. Cada usuario puede
tener varios agentes del usuario y cada uno asociado a una dirección SIP.
El Registrador (Registrar): se trata de un servidor quien acepta las solicitudes SIP REGISTER. SIP
dispone de la función de registro de los usuarios. El usuario indica por un mensaje REGISTER emitido al
registrador, la dirección donde se lo puede localizar (dirección IP). El “registrador” actualiza la base de
datos de localización. El registrador es una función asociada a un Proxy Server o a un Redirect Server. Un
mismo usuario puede registrarse sobre distintas UAs SIP, en este caso, la llamada le será entregada sobre
el conjunto de estas UAs [10].
2.2.2. Mensajes de Petición
Métodos SIP
El RFC 3261[10] define seis solicitudes/requerimientos o métodos SIP.
• INVITE [RFC3261] usado para el establecimiento de una sesión entre UAs. Contiene
información sobre el que genera la llamada y el destinatario así como sobre el tipo de flujo que
será intercambiado (voz, video, etc.).
• ACK [RFC3261] confirma la recepción de una respuesta SIP.
31
• BYE [RFC3261] permite la liberación de una sesión anteriormente establecida. Puede ser emitido
por el que genera la llamada o el que la recibe.
• REGISTER [RFC3261] usado por una UA para indicar correspondencia entre su dirección SIP y
su dirección de contacto al registrarla.
• CANCEL [RFC3261] utilizado para cancelar una solicitud pendiente.
• OPTIONS [RFC3261] utilizado para consultar las capacidades y el estado de un User Agent o
de un servidor. La respuesta debe incluir los métodos SIP que soporta [10].
2.2.2.1. Extensiones del Protocolo SIP
• SUBSCRIBE [RFC3265] utilizado para requerir notificación de evento. Los clientes UA (User
Agent) solicitan actualizaciones de presencia/disponibilidad de otros usuarios a partir de un
registrador SIP, cuando el usuario cambia la información de registro.
• NOTIFY [RFC3265] utilizado para notificar un evento. Actualizaciones instantáneas desde un
registrador a un cliente UA acerca de los usuarios que han cambiado la información del registro.
Los clientes UA deben primero enviar un mensaje SUBSCRIBE para recibir las actualizaciones
NOTIFY sobre un usuario determinado.
• PUBLISH [RFC3903] permite publicar el estado.
• REFER [RFC3515] utilizado para reenviar el receptor hacia un recurso identificado en este
método, es decir una transferencia a otra URL.
• MESSAGE [RFC3428] permite la transferencia de mensajes instantáneos. La mensajería
instantánea “Instant Messaging” o “IM” consiste en el intercambio de mensajes entre usuarios en
seudo tiempo real.
• INFO [RFC2976] permite transferir informaciones de señalización durante la llamada (por
ejemplo: ISUP).
• PRACK [RFC3311] definido para realizar una recepción confiable de las respuestas temporales
de tipo 1XX.
• UPDATE [RFC3311] permite a un terminal SIP actualizar los parámetros de una sesión
multimedia (flujo media y codecs). El método UPDATE puede ser enviado antes de que la sesión
sea establecida.
32
2.2.2.2. Estructuras e mensajes.
Un mensaje SIP consta de las siguientes partes:
• Línea de inicio: indica el propósito del mensaje.
• Cuerpo: proporcionan detalles del mensaje.
Línea de inicio
Su formato depende si el mensaje se trata de una respuesta o una solicitud.
Solicitudes SIP
Las solicitudes SIP son enviadas por los clientes para comunicarse con los servidores.
El formato de línea de inicio de una solicitud es el siguiente:
<Método> <Solicitud-URI> <versión SIP>
<Método> Es uno de los tipos de solicitudes SIP
<Solicitud-URI> Es el URL SIP u otro tipo de URL de la entidad que debería recibir el mensaje.
<versión SIP> Es actualmente SIP/2.0
A continuación algunos ejemplos:
INVITE sip:[email protected] SIP/2.0
ACK sip:[email protected];user=phone SIP/2.0
BYE tel:+1-408-555-1212;postd=p4199 SIP/2.0
2.2.3. Mensajes de Respuesta
Después de haber recibido e interpretado un requerimiento SIP, el destinatario de este requerimiento
devuelve una respuesta SIP.
El formato de línea de inicio de una respuesta es el siguiente:
<VersiónSIP> <Código de estado> <Frase razón>
33
<VersiónSIP> actualmente es SIP/2.0
<Código de estado> y <Frase razón> se establecen a uno de los pares de los código de Respuesta SIP
A continuación algunos ejemplos:
SIP /2.0 404 Not Found
SIP /2.0 180 Ringing
SIP /2.0 200 OK
Las respuestas SIP versión 2 estándar están codificadas con tres dígitos de respuesta y una descripción
textual. Las respuestas se clasifican en seis categorías, identificadas por el primer dígito el cual identifica a
que categoría pertenece como se muestra en la siguiente tabla.
Tabla 2-1. Categorías de Respuesta SIP [1].
En la siguiente tabla se muestra la totalidad de los mensajes de respuesta de tres dígitos con su descripción
[10].
34
Tabla 2-2. Código de Respuesta SIP [1] [10].
2.2.4. Cabecera SIP
La cabecera SIP representa un valor variable que es transportado a través de la red. Algunas cabeceras SIP
son obligatorias en cada mensaje, y otras si utilizan dependiendo del tipo de solicitud o de respuesta.
El formato de las cabeceras SIP es el siguiente:
<Nombre cabecera>: <Valor cabecera>
<Continuación de valor de cabecera>
<Nombre cabecera> se los enumera en la tabla 3
<Valor cabecera> una o más líneas de información.
<Continuación de valor de cabecera> continuación de la cabecera multilínea.
CODIGO DESCRIPCIÓN DE LA RESPUESTA CODIGO DESCRIPCIÓN DE LA RESPUESTA
1XX INFORMACION 420 Extensión errónea
100 Intentando 421 Extensión requerida
180 Ringing 422 Sesión del temporizador de intervalos demasiado pequeño
181 La llamada está remitiéndose 423 Intervalo demasiado corto
182 En Cola 428 Utilice token de autenticación
183 Progreso de la sesión 429 Proporcionar identidad REFER
2XX SUCESOS 480 No disponible temporalmente
200 OK 481 Circuito de llamada o transacción no existe
202 Aceptado 482 Detectado un bucle
3XX REDIRECCION 483 Demasiados saltos
300 Opciones múltiples 484 Dirección incompleta
301 Movido permanentemente 485 Ambiguo
302 Movido temporal 486 Ocupado aquí
305 Utilizar proxy 487 Solicitud terminada
380 Servicio Alternativo 488 No aceptable aquí
4XX ERROR DEL CLIENTE 489 Terminación de evento
400 Respuesta mala 491 Solicitud pendiente
401 Sin autorizacion 493 Solicitar indescifrable
402 Pago requerido 5XX ERROR DEL SERVIDOR
403 Prohibido 500 Error al interior del servidor
404 No encontrado 501 No implementado
405 Método no permitido 502 Gateway erróneo
406 No aceptable 503 Servicio no disponible
407 Se requiete autenticación de Proxy 504 Límite de tiempo del gateway
408 Se requiere límite de tiempo 505 Versión de SIP no soportada
409 Conflicto 513 Mensaje demasiado grande
410 Hecho 6XX ERROR GLOBAL
411 Longitud requerida 600 Ocupado completamente
413 Entidad solicitada demasiado grande 603 Declinar
414 Solicitud-URI demasiado grande 604 No existe en ninguna parte
415 Tipo de medio no soportado 606 No aceptable
416 Esquema URI no soportado
35
A continuación algunos ejemplos:
From: sip:[email protected]
User-Agent: Cisco VoIP Gateway / IOS12.x / SIP enable
Content-Type: application / sdp
La siguiente tabla muestra las cabeceras SIP las mismas que se organizan en cuatro grupos lógicos, el
orden en el que se presentan estos grupos representan como deberían aparecer en los mensajes SIP, es
decir: cabeceras generales, cabeceras de solicitud, cabeceras de respuesta y cabeceras de entidad.
Tabla 2-3. Elementos de la Cabecera SIP [1] [10].
Abreviaturas del nombre de cabecera
Algunos nombres de las cabeceras SIP puede ser abreviados para evitar la fragmentación de paquetes y los
servidores SIP deben tener la facultad de interpretar los nombres de cabecera normales y abreviados.
En la tabla 2-4 se muestra los nombres de cabeceras que pueden ser abreviados.
Tabla 2-4. Abreviaturas de Nombre de Cabecera [1] [10].
NOMBRE DE CABECERA COMPLETO NOMBRE DE CABECERA ABREVIADO
Call-ID i
Contact m
Content-Encoding e
Content-Length l
Content-Type c
From f
Subject s
To t
Via v
36
2.2.5. Cuerpo de los mensajes SIP (protocolo de descripción de la sesión SDP)
Como se había mencionado anteriormente el protocolo SIP es el encargado de establecer, modificar y
finalizar sesiones multimedia pero no de negociar parámetros (Codecs) entre los dos usuarios finales de
esto se encarga el protocolo SDP el cual se encuentra contenido en el protocolo SIP.
Protocolo de descripción de la sesión (SDP)
SDP es el protocolo de descripción de la sesión diseñado para identificar los atributos de una sesión,
incluyendo información administrativa, sobre el programa y sobre los medios [12]. SDP especifica un
estricto orden de los atributos; este orden se basa en minimizar el tamaño y complejidad del mensaje del
protocolo.
La tabla 2-5 especifica los atributos del protocolo SDP
Tabla 2-5. Atributos de SDP [12]
TIPO SDP DESCRIPCION
v= Versión del protocolo
o= Propietario-creador e identificador de sesión
s= Nombre de la sesión
i= *Información de la sesión
u= *URI de descripción
e= *Dirección de e-mail
p= Número de teléfono
c= *Información de la conexión
b= *Información de ancho de banda
<TIME_DESCR> Una o más descripciones horarias
z= *Ajustes de zona horaria
k= *Clave de encriptación
a= *Ninguna o más líneas de atributos de sesión
<MEDIA_DESCR> *Ninguna o más descripciones de los medios
t= Tiempo en que la sesión está activa
r= *Cero o más repeticiones
m= Nombre de los medios y dirección del transporte
i= *Título de los medios
c= *Información de la conexión
b= *Información del ancho de banda
k= *Clave de encriptación
a= *Ninguna o más líneas de atributo
DESCRIPCION DE SESION
DESCRIPCION DEL TIEMPO
DESCRIPCION DE MEDIOS
NOTA: *son opcionales
37
2.3. PROBLEMAS GENERALES DE INTEROPERABILIDAD
Los problemas de interoperabilidad de las redes NGN´s tanto en la arquitectura Softswitch e IMS
utilizando el protocolo SIP para la señalización pueden variar por varios motivos tal como:
• Problemas de código de respuesta: cuando un usuario final SIP fue movido y el usuario que
inicia la sesión SIP intenta conectar por los mismos caminos, no por otros dando como resultado
este tipo de errores un 404 Not Found o 480 temporalmente no disponible o 503 servicio no
disponible.
• SIP campo y longitudes mensaje: Mientras que el RFC no define ninguna longitud máxima de
los mensajes de SIP, la realidad es que los proveedores a menudo imponen límites de longitud de
los campos y los mensajes recibidos. Ya sea por razones de seguridad, arquitectura, lo cierto es
que hay muchos sistemas que no pueden o no quieren manejar los campos tan grandes como otros
sistemas pueden generar. A pesar del [RFC 3261] que define algunos códigos de respuesta
específicos 413 (Entidad de solicitud demasiado grande), 414 (Request-URI es demasiado larga) y
513(Mensaje demasiado grande)
• SIP y formatos URI11: A pesar del [RFC 3261] el formato SIP URI ha tenido un uso
generalizado como esencialmente el equivalente semántico de la URI TEL, aunque con una
sintaxis diferente. Los usuarios SIP no tienen una forma real de saber cuándo una URI pertenece a
un servidor SIP o a otro - el usuario presiona los botones numéricos y pulse en "Enviar", y el
usuario SIP lo que puede hacer es enviar el solicitud a sip: [dígitos] @ [dominio local]. Además,
muchos sistemas han sido diseñados o bien aprovisionados para manejar un solo tipo de sistema:
SIP URI. Esto ha llevado a los casos en que las solicitudes son rechazadas a menos de que el
esquema del URI este adecuado.
• TEL-URI y parámetros URI: El problema de la interoperabilidad más comunes en esta área es
la colocación de los parámetros TEL URI, por ejemplo, el "tgrp" y "contexto tronco" parámetros
de [RFC4904], y la "rn", "NPDI", y los parámetros "CIC" a partir de [RFC4694]. RFC 3261
sección 19.1.6 está muy claro que todas las características de la telefónica de abonado, incluyendo
los parámetros, se coloca en la parte de userinfo de una SIP URI. Por lo tanto los parámetros de
Tel-URI se convierten en parámetros de usuario de SIP, parámetros SIP URI no.
Un ejemplo, por lo tanto, de una SIP URI que contiene algunos de los mencionados parámetros
11
URI (Uniform Resource Identifer / Identificador Uniforme de Recurso)
38
URI Tel-sería la siguiente: sip: +12125551212 NPDI; tgrp = foo; tronco-context = example.com
@ example.net
Otro de los problemas comunes de interoperabilidad se refiere a los separadores visuales.
12125551212 +1 (212) 555-1212
2.3.1. Problemas específicos de interconexión del protocolo SIP
• Registró comportamiento de respuesta: Otra forma de los problemas de interoperabilidad que
surgen de las respuestas es el comportamiento de la UA en materia de registro y suscripción de
manejo de respuesta. Por ejemplo, la UA envía una petición pero el destinatario y recibe una
respuesta 3xx (301 Movido permanentemente, Movido temporalmente).
• Requerimiento de valor de cabecera: SIP ofrece un medio para indicar el uso de extensión, los
vendedores hacen suposiciones acerca de las capacidades de los otros UA, literalmente significa
"no quiero que esta solicitud tenga éxito, a menos de que el posible receptor conozca el uso de
extensión".
Por ejemplo, la etiqueta de opción 100rel para apoyar PRACK, se inserta en la cabecera de una
petición INVITE. Esto es fundamentalmente erróneo en el uso real. El apoyo a PRACK no es
universal, en todo sentido, y la inserción de esta etiqueta en la cabecera que conduce a las
llamadas fallidas. Ningún usuario o el operador quieren una llamada fallida, a menos que sea
literalmente imposible de tener éxito.
• Desvió de llamada: Funciones específicas de facturación, este es propietario del operador por lo
cual no son compatibles tanto de origen como destino.
• Consulta de trasferencia de llamadas: Supuestos específicos de cada operador versus modelos
implementados, Por ejemplo, algunas aplicaciones y modelos de implementación no son
compatibles con el de diálogo se referencia.
39
2.3.2. Problemas específicos de interconexión del protocolo SIP e SDP
• Oferta-INVITE a menos y Re-INVITE: Crea una invitación, al ser negada reenvía la invitación
y no puede establecer una comunicación por falta de parámetros en el protocolo SDP, por
ejemplo, que los dispositivos a enrutar las llamadas sobre la base del códec, o la asignación de
ancho de banda, o los dispositivos de transcodificación que se envían no estén de acuerdo con lo
necesario.
• Señalización: Funciones de pasarela de señalización, falta de parámetros entre proveedores un
dispositivo envía de una SDP, literalmente, no quiere que el otro extremo la reciba.
• Petición y respuesta SDP no coinciden: Un problema de interoperabilidad con frecuencia surge
cuando una oferta SDP contiene múltiples "m =" líneas de los medios de comunicación, pero la
respuesta SDP no contiene el mismo número de líneas.
• Medios compatibles Incompatibilidades: En la práctica, un número significativo de dispositivos
SIP sólo soportan ciertos tipos de códec.
40
3. ESPECIFICACIONES
En esta sección se describen los componentes que se tuvieron en cuenta en la elaboración de esta solución
de interconexión de la red NGN ZTE-PUJ con arquitectura Softswitch/MGC y red NGN ANKLA con
arquitectura Softswitch/MGC.
DESCRIPCIÓN GENERAL
El trabajo de profundización consiste en el diseño e implementación de una solución de interconexión de
dos plataformas de redes NGN de diferentes fabricantes con el protocolo SIP sobre la arquitectura
Softswitch/MGC; para esto se debe tener en cuenta una serie de aspectos que son fundamentales en el
desarrollo de la investigación los cuales se irán describiendo en el desarrollo del mismo.
Una característica fundamental de la red NGN es la capacidad de suministrar una gran variedad de
servicios, incluidos voz, vídeo, audio y datos visuales, mediante servicios basados en sesión e interactivos
en los modos unidifusión, multidifusión y difusión; Basándose en la separación de los servicios y
transporte como se describió en el numeral 2.1.2, la convergencia se centra en las técnicas de integración
de los diferentes protocolos de comunicación para asegurar el inter funcionamiento de la red de transporte
con los servicios y las aplicaciones, para la interpretación, generación, distribución y traducción de la
señalización correspondiente y así poder realizar la integración de los diferentes componentes de la
misma. La red NGN puede emplearse de manera coherente en cualquier instante o en cualquier lugar a
través de diferentes entornos que emplean equipos de terminales convergentes (es decir, equipos
terminales que son capaces de aceptar todos los servicios) en un entorno digital [4].
En la figura 3-1 se muestra los diferentes protocolos de comunicación que tiene en cuenta las redes NGN
para las comunicaciones con sus diferentes dependencias y con la integración con otras redes NGN.
Después de tener en cuenta los diferentes protocolos de comunicación de las redes NGN nos centraremos
en el protocolo SIP, el cual es el que nos permite realizar la interconexión en dos redes NGN mediante un
troncal SIP (canal de comunicación con múltiples conexiones de señalización con el protocolo SIP), esto
se realiza para poder compartir servicios de voz, video y datos entre las dos redes.
41
-
Figura 3-1. Protocolos de la red NGN12
En la figura 3-2 se muestra el diagrama básico de la interconexión entre red Red NGN ZTE-PUJ y
ANKLA.
Figura 3-2. Arquitectura básica de interconexión las diferentes redes NGN´s.
12 Tomado de “Introducción a los Protocolos NGN (ZTE)”
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
“CINTEL”
42
3.1 Red NGN ZTE-PUJ
La plataforma del Centro de Tecnologías de Telecomunicaciones ZTE-PUJ se basa en una red de próxima
generación marca ZTE, con arquitectura Softswitch/MGC de fabricación China. Desde ella, se puede
proveer servicios: voz sobre IP, telefonía tradicional/IP e Internet Banda ancha.
La arquitectura general de la red es la siguiente:
• Nivel de servicios. Servidores de aplicación tales como (Asterisk, Elastik, Open Source IMS,
Mobicents, Kamailio)
• Nivel de control. Softswitch (control, servicios, gestión de llamadas)
• Nivel de transporte. Core (conmutación de paquetes).
• Nivel de acceso. Inalámbrico, banda ancha, PSTN, ISDN, con equipos: UAM (MSAG), abonados
análogos y ADSL (convierte señales de voz análoga a IP; IAD, concentrador de líneas USUARIO
Analógicas 8-24, conexión IP hacia el SS; SG, señalización SS7; TG, trafico PSTN; AG, servidor
de acceso.
Por ser una NGN con arquitectura Softswitch/MGC, maneja en un mismo equipo: servicios, control,
transporte y acceso.
Figura 3-3. Arquitectura Red NGN ZTE-PUJ13
13 Tomado de la arquitectura NGN del laboratorio PUJ-ZTE
43
3.2 Red NGN ANKLA
El laboratorio ANKLA sigue una estructura de red NGN para la implementación de la plataforma de
pruebas, de acuerdo a las capas y funciones descritas en la arquitectura Softswitch/MGC, la plataforma
está constituida por:
• Telephony Softswitch Solution (TSS) versión 4.0 de Ericsson: Está conformado por un
Telephony Server (AXE), TSS Gateway Controller y un Media Gateway (MGW). Soporta
protocolos de señalización SS7 y SIGTRAN, protocolos de control de llamadas ISUP, SIP y
H.323, como protocolo de control de portadora H.248 y ADSL. Tiene una capacidad total de
1200 abonados TDM a través de un Access Gateway (AGW), ANKLA cuenta con una
capacidad instalada de 60 abonados. Provee servicios suplementarios como reloj despertador,
línea directa, llamada tripartita, identificadores de llamadas, marcación abreviada y llamada en
espera.
• Plataforma de servicios de Trópico: Está conformada por un servidor de aplicaciones (VAS) que
realiza las tareas de control y lógica del servicio en las diferentes aplicaciones instaladas, un
servidor de medios para la reproducción de anuncios y procesamiento multimedia (VMS) y un
módulo de reconocimiento de voz (ASR Nuance) encargado de las tareas de reconocimiento
automático de voz y su correspondiente conversión a texto. Provee servicios de Portal de Voz
para la atención de servicios de Call Center, mediante un IVR por reconocimiento de voz, y un
sistema de conversión numérica y distribución de llamadas para la atención del usuario
mediante operador.
• Plataforma de comunicaciones unificadas: Conformada por dos servidores AsteriskNow y
Elastix para realizar la integración de servicios entre usuarios Legacy (TDM) e IP, proveen
servicios de VoIP tales como videollamadas, IVR, y call center además de integrar servicios de
mensajería instantánea, fax, videoconferencias, tarificación y correo electrónico.
• Plataforma de IMS (IP Multimedia Subsystem): Conformada por una plataforma de entrega de
servicios IMS open source (Open Source IMS Core) desarrollada por el instituto Fokus de
Alemania con el objetivo de desplegar una plataforma de pruebas sin limitaciones en cuanto a
licencias. Está constituida por:
o Proxy Call Sessión Control Function (P-CSCF).
o Interrogating Call Sessión Control Function (I-CSCF).
44
o Serving Call Sessión Control Function (S-CSCF).
o Home Subscriber Server (HSS).
o Servidores de aplicaciones SIP (SIP AS).
Figura 3-4. Arquitectura ANKLA14
3.3 Infraestructura de Interconexión redes NGN´s.
Para la interconexión de las redes NGN´s ZTE-PUJ y ANKLA se tuvieron en cuenta una serie de
herramientas de tipo software y hardware que serán descritas a continuación.
3.3.1 Nodo Captura
El nodo captura es un sistema robusto, capaz de recolectar y encapsular enormes cantidades de
señalización SIP con capacidad de búsqueda instantánea, la cual nos da un análisis de extremo a extremo
de la señalización y con la posibilidad de realizar un estudio detallado del comportamiento y las
estructuras de las tramas del protocolo SIP, para poder identificar los problemas puntuales generados por
14 Tomado de la arquitectura NGN del laboratorio ANKLA “CINTEL”
45
los posibles cambios en las tramas y realizar una corrección de la misma; el funcionamiento del nodo
captura está dividido en tres partes el primero es un proxy SIP (Kamailio) que recolecta toda la
señalización SIP que le envía el “Capture Agent”. La ventaja de este tipo de solución es que vamos a
tener la posibilidad de ver todo ese tipo de tráfico en un sitio web (WebHomer).
• Kamailio es un servidor SIP de código abierto que puede adoptar todas las entidades lógicas
conocidas en un entorno VoIP:
� Servidor Registrador o Registrar Server
� Servidor Proxy o Proxy Server
� Servidor Redireccionador o Redirect Server
� Servidor de Localización o Location Server
• Capture Agent, está basado en el módulo sipcapture (El módulo sipcapture almacena y modifica
los mensajes SIP entrantes / salientes en la base de datos) para el servidor SIP Kamailio viene con
potentes opciones de filtrado de ajuste y, el manejo sin problemas de millones de paquetes por
nodo / hora.
• WebHomer, es la parte que se encarga de buscar, filtrar y mostrar los paquetes SIP y las sesiones
detalladas SIP, visualiza extremo a extremo los flujos de llamada extrayéndolas en archivos
PCAP´s para mostrar el tráfico y las estadísticas multiusuario, niveles de acceso.
Figura 3-5. Arquitectura Nodo Captura15
El Nodo Captura necesita de unos requisitos mínimos adicionales de software para su funcionamiento
como son los siguientes:
15 Tomado de http://www.sipcapture.org/
46
El Nodo Captura trabaja exclusivamente sobre ambientes Linux, necesita de un servidor web para la
publicación de la interfaz gráfica (WebHomer), una base de datos Mysql para que el servidor kamailio
guarde toda señalización SIP y servidor PHP para poder generar los reportes de señalización SIP.
• Servidor Linux
• Servidor Apache/Lighttpd
• Base de datos MySQL 5.1.43+
• Servidor PHP 5.2+ HP-GD, JSON)
3.3.2 Generador de tráfico
El generador de tráfico Distributed Internet Traffic Generator (D-ITG). Es una plataforma capaz de
producir tráfico a nivel de paquetes con gran exactitud, replicando apropiadamente procesos estocásticos
tanto para IDT (Inter Departure Time), como para variables PS (Packet Size) aleatorias (exponencial,
uniforme, Cauchy, normal y Pareto). Soporta generación de tráfico IPv4 e IPv6 y es capaz de generar
tráfico a nivel de red, transporte y aplicación.
D-ITG, es el software seleccionado para el proyecto que permite implementar algunos protocolos en la
capa de aplicación como: VoIP, Telnet, DNS, entre otros. En general, permite implementar protocolos
hasta en la capa de transporte, por lo que al modelar algún tipo de tráfico para ser generado e inyectado
por el D-ITG en la red, es necesario abstraer el comportamiento estadístico de la capa de aplicación y
encapsularlo en la capa de transporte, para que de esta manera logre emular la pila de protocolos TCP/IP
completa con solo implementar los protocolos de red y transporte.
El D-ITG no permite implementar todos los protocolos de aplicación que existen. Pero a nivel de los
sistemas de conmutación y transporte de una red, esto no tiene importancia porque los dispositivos de red
que componen estos sistemas solo operan hasta nivel de capa de red, y los niveles superiores, como
aplicaciones y transporte son encapsulados, uno dentro del otro. En consecuencia, la medida que se
obtiene usando el D-ITG es aceptable porque usa los protocolos de las capas de transporte, red e interfaz.
Lo anterior implica que para la realización de una medida de QoS en una red de telecomunicaciones, para
cada servicio por ejemplo, la QoS de una llamada telefónica IP es necesario modelar el tráfico de una
llamada telefónica IP real, de forma estadística, y entregarle estos parámetros al D-ITG, para configurarlo
y modelar el tráfico de una llamada telefónica IP. Posteriormente, ese tráfico moldeado se inyecta a la red,
que se encarga de implementar todos los protocolos de esa comunicación, hasta la capa de transporte.
47
3.3.3 Simulador trama SIP
SIP Inspector es una herramienta práctica que permite simular mensajes y escenarios del protocolo SIP.
SIP Inspector es una herramienta escrita en JAVA que te permite simular diferentes mensajes y
escenarios del Protocolo de Inicio de Sesiones (SIP). Puede crear propios escenarios de señalización SIP,
personalizar mensajes SIP y supervisar los mensajes recibidos y enviados. La herramienta permite
reproducir secuencias RPT desde un archivo pcap [25].
Es una herramienta ideal para auditarla seguridad de VOIP y con grandes aplicaciones para los que
quieran conocer más sobre el protocolo de señalización SIP, gracias a la incorporación de esquemas para
los casos de UAC y de UAS.
3.3.3.4 Firewall
Un cortafuego (firewall en inglés) es una parte de un sistema o una red que está diseñada para bloquear el
acceso no autorizado, permitiendo al mismo tiempo comunicaciones autorizadas.
Se trata de un dispositivo o conjunto de dispositivos configurados para permitir, limitar, cifrar, descifrar,
el tráfico entre los diferentes ámbitos sobre la base de un conjunto de normas y otros criterios.
Los cortafuegos pueden ser implementados en hardware o software, o una combinación de ambos. Los
cortafuegos se utilizan con frecuencia para evitar que los usuarios de Internet no autorizados tengan
acceso a redes privadas conectadas a Internet.
48
4 DESARROLLOS.
En esta sección del documento se explica y documentan todos los desarrollos e implementaciones
realizadas para el cumplimiento de los objetivos del proyecto. Las cuales fueron un análisis del
comportamiento y cabeceras de la señalización SIP en cada una de las redes NGN con arquitectura
Softswitch/MGC; se montó un escenario real para poder hacer un análisis de la interoperabilidad entre la
Red NGN ZTE-PUJ y ANKLA.
4.3 ANÁLISIS DEL PROTOCOLO SIP.
El análisis del protocolo SIP se realizó de manera detallada con una conexión básica, observando y
analizando la trama de señalización en cada una de sus partes en la red NGN con arquitectura
Softswitch/MGC, para poder tener un punto de partida del sistema de señalización a nivel de troncal SIP y
poder llegar a la interconexión de las dos redes NGN´s de diferente fabricante [1].
4.3.3 Análisis del protocolo SIP ZTE-PUJ
Se realizó un análisis de toda la trama de señalización SIP de la red NGN con arquitectura
Softswitch/MGC, el cual no muestra ningún tipo de modificación en los parámetros básicos del protocolo
según el RFC 3261como se muestra en el análisis de la siguiente señalización SIP.
49
Figura 4-1. Comunicación básica del protocolo SIP de la red NGN ZTE-PUJ
• Estructura de un mensaje INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To: "102"<sip:[email protected]>
From: "103"<sip: [email protected]>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@ 172.22.0.54
CSeq: 23944 INVITE
Contact: <sip103@ 172.22.0.54:5060>
Max-Forwards: 70
User-Agent: ZTE MULTIMEDIA SIPPHONE/V1.0 04-01-10
Content-Type: application/sdp
Content-Length: 288
v=0
o=1033608424475 IN IP4 10.66.74.136
s=session SDP
50
c=IN IP4 172.22.034
t=0 0
m=audio 10000 RTP/AVP 0 4 8 18
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
m=video 10002 RTP/AVP 34
a=rtpmap:34 H263/90000
NOTA: en la estructura el mensaje invite no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 183 RING
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To:"102"<sip:[email protected]>;tag=a290601-31939
From:"103"<sip:[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
User-Agent: ZTE Softswitch/1.0.0
Content-Type: application/sdp
Content-Length: 115
51
v=0
o= ERICSSON 32 32 IN IP4 10.41.6.1
s=phone-call
c=IN IP4 172.22.0.34
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 183RING no se encuentra ningún tipo de modificación o adicional en
la estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To:"102"<sip:[email protected]>;tag=a290601-31939
From:"103"<sip:[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
Record-Route: <sip:172.22.0.34;lr>
User-Agent: ZTE Softswitch/1.0.0
Content-Type: application/sdp
Content-Length: 115
v=0
o= ZTE 32 32 IN IP4 172.22.0.34
52
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje ACK
ACK sip:172.22.0.34;lr SIP/2.0
Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To: "102"<sip:[email protected]>
From: "103"<sip:[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 ACK
Contact: <sip:#[email protected]:5060>
Max-Forwards: 70
Route: <sip:[email protected]>
NOTA: en la estructura el mensaje ACK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje BYE
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=776249e9.0
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=4dcf5bd7
To: “103"<sip:[email protected]>;tag=884a420a-7062206315162668
53
From: "102"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
User-Agent: ZTE Softswitch/1.0.0
Content-Length: 0
NOTA: en la estructura el mensaje BYE no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=776249e9.0
Via: SIP/2.0/UDP 172.22.0.34:5060;branch=4dcf5bd7
To: "#0*109316"<sip:[email protected]>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
Después de haber analizado la trama de señalización SIP con el RFC 3261 de una comunicación básica de
la red NGN ZTE-PUJ con arquitectura Softswitch/MGC SIP no se encontró ningún tipo de modificación
o adición a la misma, el cual nos da un principio de interconexión sin presentar ningún problema.
54
4.3.4 Análisis del protocolo SIP ANKLA
Se realizó un análisis de toda la trama de señalización SIP de la red NGN con arquitectura
Softswitch/MGC, el cual no muestra ningún tipo de modificación en los parámetros básicos del protocolo
según el RFC 3261 como se muestra en el análisis de la siguiente señalización SIP.
Figura 4-2. Comunicación básica del protocolo SIP de la red NGN ANKLA
• Estructura de un mensaje INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To: "0755526778086"<sip:[email protected]>
From: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:#0*[email protected]:5060>
Max-Forwards: 70
User-Agent: ERICSSON MULTIMEDIA SIPPHONE/V1.0 04-01-10
Content-Type: application/sdp
55
Content-Length: 288
v=0
o=#0*109316 3507761179 3608424475 IN IP4 10.66.74.136
s=session SDP
c=IN IP4 10.66.74.136
t=0 0
m=audio 10000 RTP/AVP 0 4 8 18
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
m=video 10002 RTP/AVP 34
a=rtpmap:34 H263/90000
NOTA: en la estructura el mensaje INVITE no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 183 RING
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To:"0755526778086"<sip:[email protected]>;tag=a290601-31939
From:"#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
56
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
User-Agent: ERICSSON Softswitch/1.0.0
Content-Type: application/sdp
Content-Length: 115
v=0
o= ERICSSON 32 32 IN IP4 10.41.6.1
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 183 RING no se encuentra ningún tipo de modificación o adicional en
la estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To:"0755526778086"<sip:[email protected]>;tag=a290601-31939
From:"#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 INVITE
Contact: <sip:[email protected]>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
Record-Route: <sip:10.41.6.1;lr>
User-Agent: ERICSSON Softswitch/1.0.0
57
Content-Type: application/sdp
Content-Length: 115
v=0
o= ERICSSON 32 32 IN IP4 10.41.6.1
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
m=audio 4006 RTP/AVP 0
a=ptime:20
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje ACK
ACK sip:10.41.6.1;lr SIP/2.0
Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a
To: "0755526778086"<sip:[email protected]>
From: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
Call-ID: [email protected]
CSeq: 23944 ACK
Contact: <sip:#0*[email protected]:5060>
Max-Forwards: 70
Route: <sip:[email protected]>
NOTA: en la estructura el mensaje ACK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de un mensaje BYE
58
BYE sip:#0*[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.41.6.1:5060;branch=776249e9.0
Via: SIP/2.0/UDP 10.52.31.237:5060;branch=4dcf5bd7
To: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
User-Agent: ERICSSON Softswitch/1.0.0
Content-Length: 0
NOTA: en la estructura el mensaje BYE no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
• Estructura de 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.41.6.1:5060;branch=776249e9.0
Via: SIP/2.0/UDP 10.52.31.237:5060;branch=4dcf5bd7
To: "#0*109316"<sip:#0*[email protected]>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:[email protected]>;tag=a290601-31939
Call-ID: [email protected]
CSeq: 18927 BYE
Max-Forwards: 69
NOTA: en la estructura el mensaje 200 OK no se encuentra ningún tipo de modificación o adicional en la
estructura de su trama de señalización según el RFC 3261.
59
Después de haber analizado la trama de señalización SIP con el RFC 3261 de una señalización básica de
la red NGN ANKLA con arquitectura Softswitch/MGC no se encontró ningún tipo de modificación o
adición a la misma, el cual nos da un principio de interconexión sin presentar ningún problema.
4.3.5 Comparación de las dos redes NGN´s
Al realizar un estudio comparativo de la señalización SIP de las dos redes NGN´s ZTE-PUJ ANKLA no
se encuentra ninguna diferencia en la forma en que ambos fabricantes implementan el protocolo SIP al
interior de sus redes [4] [7] [8] [10].
4.4 PRUEBAS DE INTEROPERABILIDAD
En este numeral se tienen en cuanta todas las consideraciones técnicas a tomarse en cuenta para la
interoperabilidad e interconexión de las dos redes NGN a través de troncales SIP [7].
El uso del protocolo SIP permite la interconexión de equipos de múltiples fabricantes debido a su
estandarización y a la simplicidad del intercambio de mensajes [1].
4.4.3 Escenario de interoperabilidad ZTE-ANKLA
Uno de los mecanismos más recientes para los servicios convergentes es la capacidad de acceso basado en
SIP, o de manera más general, la conexión a redes NGN´s mediante troncales SIP [7]. Estas capacidades
posibilitan el uso de implementaciones basadas en estándares abiertos de conectividad SIP, ya sea para
hacer más eficiente el uso de la infraestructura existente de cable, de cobre o de fibra óptica (para
cobertura de voz y datos), o para extender el alcance geográfico de los carriers para atender nuevos
mercados a través de una conectividad IP. La interconexión a través de troncales SIP tiene algunas
ventajas para las redes NGN:
• Reduce los costos y la complejidad de las implementaciones gracias a la consolidación de la voz y
los datos sobre una sola red.
60
• Permite hacer uso de otros servicios IP dependientes del tipo de transporte como: transferencia de
mensajes de audio, video conferencias, presencia, mensajería instantánea, etc.
• Capacidad de expansión de los servicios de comunicaciones para satisfacer demandas no
contempladas.
• Implementación de servicios convergentes a lo largo de toda la empresa.
Inicialmente, H.323 estaba orientado a implementarse sobre redes corporativas, mientras que SIP se usaba
en redes de carriers. En los últimos años, ha ido creciendo la aceptación de la industria con respecto a SIP
como el protocolo primario de comunicación IP entre sistemas, independientemente de la aplicación.
En este caso se accede a la red NGN directamente desde las premisas de la red del cliente, o de una red de
datos privada, desde la cual se tiene conexión a Internet, incluso con otra red NGN. Desde esta red de
datos (red IP) se accede a través de una troncal SIP a la red NGN con arquitectura Softswitch/MGC.
Con SIP versión 2, se han adicionado nuevas características que permiten al equipo comunicarse con redes
VoIP de múltiples fabricantes. Sin embargo, todavía no existe una garantía de que todos los fabricantes,
interpreten e implementen los estándares de la misma forma [1].
Las troncales SIP proveen mayor flexibilidad en cuanto a la configuración de servidores proxy remotos,
de modo que se incrementa el potencial de interoperabilidad y la disponibilidad de la red. El proxy se
puede especificar simplemente ingresando su dirección IP como dirección para enrutar un servicio.
Algunas configuraciones de red pueden requerir el uso de uno o más servidores proxy de salida (por
ejemplo en presencia de un controlador de borde o si el proveedor de servicios usa múltiples nodos para
enrutar llamadas). Ver figura 4-3.
Dado el caso práctico de interoperabilidad de las redes NGN´s de estudia se implementó los Softswitchs
como servidores proxy.
61
Figura 4-3. Estructura de un servidor Proxy SIP16
En el RFC 2833 se define un método estándar para transmitir dígitos de señalización entre dos usuarios
finales transmisión RTP. Esto permite una transmisión confiable de los paquetes entre usuarios finales
independientemente de la calidad del CODEC utilizado para la transmisión de la voz.
Con el fin de activar determinados escenarios de llamadas como transferencia de llamadas sobre troncales
SIP, el método REFER el cual esta descrito en el RFC 3515. Luego que una llamada ha sido establecida
entre dos usuarios, se utiliza el método SIP REFER para transferir la llamada. El mensaje REFER provee
la información de contacto a la otra parte (donde la llamada será transferida).
El funcionamientos de la troncal SIP de realiza con las sesiones de la señalización SIP que normalmente
se establecen a través de un servidor Proxy SIP. El servidor Proxy SIP se ubica en medio del camino de la
señalización y provee un servicio de búsqueda para los mensajes entrantes y salientes. Este servicio puede
ser una búsqueda DNS o una búsqueda en una base de datos de información de presencia, en la cual los
usuarios han registrado su localización y su estado de presencia. En cualquier caso el trabajo del servidor
proxy es encontrar a la persona que está siendo invitada a una sesión de media.
El siguiente ejemplo nos da una visión del funcionamiento del PROXY SIP.
El USUARIO A desea realizar una llamada desde su teléfono IP hacia el teléfono de USUARIO B, por lo
que levanta el auricular del teléfono y marca. Este no conoce exactamente la localización de USUARIO B,
de manera que su teléfono (usuario SIP) re direcciona el mensaje INVITE hacia el servidor proxy SIP.
16 Tomado de Softswitch Architecture for VoIP
62
El servidor proxy realiza una búsqueda del URI de USUARIO B y obtiene su dirección IP, entonces envía
el mensaje INVITE hacia el teléfono de USUARIO B, añadiéndole al mismo un encabezado llamado
“Via:” el cual contiene la dirección IP del servidor proxy. Finalmente el mensaje contendrá dos
encabezados “Via:” contando con el original que contiene la IP de USUARIO A.
Debido a que el (usuario SIP) del USUARIO B recibe el mensaje INVITE con más de un encabezado
“Via:”, se sabe que el paquete ha atravesado un servidor proxy. El teléfono de USUARIO B responde con
un ‘180 Ringing’ enrutado hacia el USUARIO A a través del servidor proxy, y luego con un 200 OK
enrutado de la misma forma.
Las respuestas de USUARIO B contienen su IP, de manera que USUARIO A envía un ACK directamente
hacia USUARIO B (sin pasar por el proxy). En este punto la sesión se encuentra establecida y se desarrolla
directamente entre los dos (usuarios SIP), hasta que se termine la sesión con los mensajes BYE y 200 OK.
El ejemplo solo contiene un servidor proxy para la sesión SIP, sin embargo típicamente se tiene varios
servidores proxy en el camino de señalización, usualmente, al menos uno por sistema autónomo.
En la figura 4-3 se muestra la representación de mensajes SIP dos servidores proxy SIP.
Figura 4-4. Estructura de mensajes SIP con un servidor Proxy SIP17
Los servidores proxy se encuentran usualmente estructurados en una topología que el RFC 3261 define
como trapezoide SIP. Este trapezoide describe la forma en que la media y la señalización fluyen cuando:
17
Tomado de Softswitch Architecture for VoIP.
63
• Dos usuarios SIP de una sesión se encuentran en diferentes dominios.
• Cada dominio está configurado con un servidor proxy.
• Cada usuario SIP, su dominio está configurado para establecer sesiones fuera del dominio a través
de su servidor proxy.
En la figura 4-5 se realiza un diagrama de interconexión utilizando los diferentes Softswitch como
servidores proxy SIP para el intercambio de mensajes de señalización SIP con otras redes NGN; en este
caso se realiza entre el ZTE-PUJ) ANKLA
Figura 4-5. Arquitectura PROXY de interconexión las diferentes redes NGN´s de estudio
En el intercambio de mensajes SIP desde los diferentes PROXY de cada red también debemos tener en
cuenta el intercambio de los mensajes del protocolo SDP el cual está contenido dentro del protocolo SIP
como se describe en una llamada típica, el usuario SIP envía el mensaje INVITE junto con una petición de
establecimiento de sesión usando SDP. En este caso, el teléfono de destino responde con un ‘180 Ringing’
que permite escuchar un tono de confirmación de timbrado en el teléfono de origen. Cuando el auricular
del teléfono se levanta en el otro extremo, éste envía un mensaje 200 OK con la confirmación de uso de
SDP [7].
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
CINTEL
64
Figura 4-6. Llamada saliente: Mensaje INVITE + SDP con timbrado local
Otro escenario se da cuando conecta la media el momento en que recibe el mensaje 180 Ringing o 183 con
SDP. Si a continuación se recibe otro mensaje 180, la media no será desconectada, pero no existirá flujo
de media hasta que la llamada sea contestada.
Figura 4-7. Llamada saliente: Mensaje INVITE + SDP con conexión temprana de media
Hay que notar que el contenido SDP solo se puede incluir en respuestas provisionales si éstas son enviadas
de manera confiable. Como se puede ver en el flujo de mensajes de la Figura 4-7, las respuestas
provisionales son confirmadas mediante mensajes PRACK (Provisional Response ACK), el mismo que es
65
confirmado a su vez por un 200 OK. En éste y en los flujos siguientes, la presencia de SDP en los
mensajes de respuestas provisionales implica que éstos son entregados de forma segura.
Para poner una troncal SIP en espera, se envía un mensaje re-INVITE con una oferta SDP y con un
atributo ’sendonly’ (sesión unidireccional). El otro extremo de la troncal SIP puede seguir recibiendo
media. La dirección IP especificada en SDP seguirá siendo válida.
4.4.4 VPN y sus características de interoperabilidad.
La interconexión entre la red NGN ZTE-PUJ y ANKLA se realizó por medio de una Red Privada Virtual
(VPN) que es una forma de compartir y transmitir información entre diferentes redes que están situados en
diferentes áreas geográficas. Es una red de datos de gran seguridad que utilizando Internet como medio de
transmisión permite la transmisión de información confidencial entre las dos NGN´s. Aunque Internet es
una red pública y abierta, la transmisión de los datos se realiza a través de la creación de túneles virtuales,
asegurando la confidencialidad e integridad de los datos transmitidos. El diagrama básico de interconexión
de las dos redes NGN´s de estudio se muestra en la figura 4-8.
VPN SITE TO SITESOFTSWITCH
NGN ZTE
SOFTSWITCH
NGN ERICSSON
TRONCAL SIPTRONCAL SIP
Figura 4-8. Diagrama básico de la VPN las diferentes redes NGN´s
Una Red Privada Virtual (VPN) conecta los componentes de una red sobre otra, por medio de la conexión
de los usuarios de distintas redes a través de un "túnel" que se construye sobre Internet o sobre cualquier
otra red pública, negociando un esquema de cifrado y autentificación de los paquetes de datos para el
transporte, permitiendo el acceso remoto a servicios de red de forma transparente y segura con el grado de
conveniencia y seguridad que los usuarios conectados elijan. Las VPN están implementadas con firewalls,
con routers para lograr esa encriptación y autentificación.
66
4.4.4.4 VPN Sitio a Sitio utilizando NAT
(Network Address Translation) Traducción de Direcciones de Nombres es el proceso de cambiar una
dirección IP de una NGN (una dirección privada de la organización) por una dirección IP pública
enrutable, es decir poseen la capacidad para esconder las direcciones privadas de una NGN.
Los pasos siguientes describen el proceso de comunicación de entrada y salida con un dispositivo NAT
• Cuando un paquete precisa salir de la red interna, este es enviado hacia el firewall implementado
con NAT. Este por primera vez, cambia la dirección IP enrutable.
• El firewall implementado con NAT reenvía el paquete al dispositivo VPN que realiza el proceso
de cifrado del paquete.
• El paquete es enviado hacia el enrutador externo que sea transmitido a su destino.
• Cuando un paquete quiere entrar a una red interna debe primero dirigirse hacia el dispositivo VPN
que verifica su autenticidad. Luego este paquete es ruteado hacia el firewall implementado con
NAT que cambia la dirección IP por el número original, este es enviado hacia el enrutador interno
para ser dirigido hacia su destino.
En la figura 4-9 se muestra el diagrama de interconexión utilizado para las redes NGN´s ZTE-PUJ y
ANKLA, el cual nos muestra el direccionamiento que tiene cada una y como es el proceso de NAT que
tiene que realizar un paquete si desea ser enviado a la otra red.
VPN SITE TO SITE
IPsecSOFTSWITCH
NGN ZTE
172.22.0.48/28
SOFTSWITCH
NGN ERICSSON
192.168.0.0/24
TRONCAL SIPTRONCAL SIP
ASA 5510
IP PUBLICA
200.3.153.91
ASA 5505
IP PUBLICA
190.25.130.245
172.22.0.48/28 192.168.0.0/24
NAT
Figura 4-9. Diagrama básico de NAT las diferentes redes NGN´s
4.4.4.5 Seguridad VPN IPSec
En la implementación de la VPN para la interconexión de las diferentes redes NGN´s ZTE-PUJ y
ANKLA, un factor muy importante es la seguridad con la que nuestros datos son trasportados a través de
67
internet, por tal razón IPSec - Internet Protocol security el cual nos da una seguridad mejorada con
características tales como algoritmos de encriptación más fuertes y autenticación más comprensiva. IPSec
tiene dos modos de cifrado, túnel y transporte. El modo de túnel cifra el encabezado y la carga de cada
paquete, mientras que el método de transporte sólo encripta la carga o contenido de los paquetes. Sólo
sistemas que son compatibles con IPSec pueden usar este protocolo. También, todos los dispositivos
deben usar una clave común o certificado y deben tener implementadas políticas de seguridad similares.
Para usuarios de acceso remoto de VPN hay paquetes de software que proveen cifrado y conexión en un
PC. IPSec soporta cifrado de 56 bits (single DES) o 168 bits (triple-DES).
4.4.4.6 Descripción de los Parámetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y ANKLA
Después de haber explicado los diferentes componentes a tener en cuenta en la interconexión de las
diferentes redes NGN´s ZTE-PUJ y ANKLA, se decide crear un VPN sitio a sitio para el intercambio de
toda la señalización SIP y la media. Con esto las estas redes puedan compartir servicio y aplicaciones. Ver
figura 4-10.
Figura 4-10. Configuración VPN de la Red NGN ZTE-PUJ ANKLA
4.5 METODOLOGÍA DE ANÁLISIS DE INTEROPERABILIDAD
Después de establecer la interconexión de las dos redes NGN´s ZTE-PUJ y ANKLA mediante una VPN
sito a sitio para él envió de señalización SIP y media mediante una troncal SIP y utilizando los softswitch
como servidores PROXY para la conexión desde el interior de cada red con la otra NGN, se decide
implementar un elemento más, el NODO CAPTURA para que estudie, analice y modifique de ser
VPN SITE TO SITE* Ipsec authentication uses pre-shared
key: zte
*Tunnel Group Name: interconexion
*IKE group Encryption: DES / SHA
SOFTSWITCH
NGN ZTE
SOFTSWITCH
NGN ERICSSON
TRONCAL SIP
NODO CAPTURA
TRONCAL SIP
ASA 5510
IP PUBLICA
200.3.153.91
ASA 5510
IP PUBLICA
190.25.130.245
172.22.0.48/28 192.168.1.0/24NAT
68
necesario la señalización SIP que está pasando entre las dos redes NGN´s y no presente inconvenientes de
interoperabilidad de las mismas.
4.5.3 Identificación y reconocimiento
Para revisar los diferentes aspectos de interconexión e interoperabilidad de las diferentes redes NGN´s
ZTE-PUJ y ANKLA se realizaron una serie de pruebas de telefonía IP las cuales involucraron una serie de
componentes como fueron teléfonos SIP, softphones SIP, teléfonos analógicos tradicionales conectados a
la red SIP, un Proxy SIP (Softswitch) y el nodo captura para el análisis de resultados.
Para realizar las pruebas, se accedió desde un cliente SIP de la primera red NGN a través del Softswitch
(Servidor Proxy SIP) y enviando la señalización a través de una troncal SIP hacia la otra NGN como se
muestra en la figura 4-11.
Para cada escenario de pruebas se realizaron las configuraciones adecuadas en los equipos y se evaluó el
desempeño según el resultado esperado de la prueba.
Este esquema de pruebas permite comprobar la interoperabilidad del NODO CAPTURA a través de una
troncal SIP con algunos dispositivos necesarios para la conectividad y acceso a la red pública mediante
SIP, incluyendo: servidor proxy SIP, gateways FXO, gateways FXS, teléfonos analógicos, softphones SIP,
teléfonos IP. Además con esta implementación se pueden probar los siguientes escenarios de
interoperabilidad:
• Llamada simple entre dispositivos IP a través de troncal SIP.
• Llamada interna entre teléfonos SIP.
• Transferencia de llamadas usando el método REFER (RFC 3515).
• Escenarios de espera: espera unidireccional, espera mutua y desactivación de espera.
• Estados de presencia en dispositivos SIP.
• Identificación de llamadas CLIP (Calling Line Identification Presentation).
En primer lugar se estableció una conexión mediante de una VPN y él envió de señalización SIP y media a
través de la troncal SIP las cuales da soporte a todos los dispositivos SIP utilizados. Este procedimiento
consiste en configurar los Proxy SIP, así como la tabla de enrutamiento que específica la troncal, el mapeo
de direcciones IP, puertos a utilizarse, establecer el plan de numeración y los nombres de dominio
utilizados en la red SIP, esto para evitar conflictos de números y direcciones URI, finalmente establecer el
acceso externo mediante troncal SIP.
69
En el caso del servidor, se procedió a realizar los pasos necesarios para configurar los teléfonos SIP y los
softphones.
Para constatar y/o depurar los procedimientos en las pruebas asociadas a la conmutación de paquetes, se
procedió a capturar paquetes SIP y RTP mediante un analizador de protocolo (Wireshark) al interior de
cada red NGN y con el uso de un cliente SIP o softphone instalado en la PC como usuario SIP
destino/origen. Con este escenario de captura de paquetes también es posible verificar los mensajes
asociados a los estados de presencia; y en el medio de las redes NGN´s se configuro el Nodo Captura para
capturar toda la señalización SIP que se está enviando a través de la troncal SIP y así verificar su
interoperabilidad como se muestra en la figura 4-11.
4.5.3.4 Llamada Simple Entre Dispositivos IP A Través De Troncal SIP
Procedimiento: Como se observa en la Figura 4-11, en este escenario se establece una llamada desde un
softphone IP de la red NGN ZTE-PUJ hacia un softphone SIP de la red NGN ANKLA a través de la
troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el número de destino, en
el usuario SIP origen, debe recibir un mensaje INVITE desde la dirección del proxy, confirmando con el
timbrado del teléfono; cuando la llamada es contestada el destino envía un mensaje ‘200 OK’ y se
establece la sesión a través de paquetes RTP.
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexión de usuarios las diferentes redes NGN´s
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
CINTEL
70
Este mismo procedimiento se realizó desde la red NGN ANKLA hacia la red NGN ZTE-PUJ.
4.5.3.5 Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones
Procedimiento: Como se observa en la Figura 4-12, en este escenario se establece una llamada desde un
softphone IP de la red NGN ZTE-PUJ hacia un cliente SIP del servidor de aplicaciones de la red NGN
ANKLA a través de la troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el
número de destino, en el usuario SIP origen, se debe recibir un mensaje INVITE desde la dirección del
proxy, confirmando con el timbrado del teléfono; cuando la llamada es contestada el destino envía un
mensaje ‘200 OK’ y se establece la sesión a través de paquetes RTP.
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexión de diferentes componentes de redes NGN´s
Este mismo procedimiento se realizó desde la red NGN ANKLA “hacia la red NGN ZTE-PUJ.
Red NGN (Centro de Tecnologías de
Telecomunicaciones ZTE-PUJ)
“Pontificia Universidad Javeriana”
Red NGN (Laboratorio ANKLA)
CINTEL
71
4.6 INTEGRACIÓN GENERADOR DE TRÁFICO, NODO CAPTURA Y EMULADOR DE
TRAMA SIP
Después de realizar las pruebas con un solo usuario se implementaron otra serie de pruebas con un
generador de tráfico SIP, para poner a prueba la capacidad de interoperabilidad con flujos de señalización
SIP más grandes y observar el comportamiento del Nodo Captura.
4.6.3 Integración Nodo Captura y Generador de Tráfico
En la figura 4-13 se muestra la forma de inyectar el tráfico emulado con el generador de tráfico D-ITG en
la red NGN´s, el cual pasa por el Nodo Captura para realizar un análisis de grandes cantidades de
señalización SIP; y verificar según el RFC 3261 la estructura de trama SIP, y poder medir la calidad de
servicio (QoS).
La configuración utilizada para esta prueba fue instalar el equipo transmisor en la red ZTE-PUJ desde el
cual el D-ITG inyecta tráfico en la red y un equipo receptor en la red ANKLA que lo toma y lo procesa
generando un archivo de registro, con los parámetros medidos en la transmisión realizada. Esta captura
contiene datos que determinan el comportamiento estadístico de la aplicación, tales como: la tasa de
paquetes enviados (paquetes/segundo), el tamaño de los paquetes (bytes/paquete), el byte DSCP (servicios
diferenciados), el TTL, los protocolos usados en la transmisión, los puertos, el ancho de banda, entre
otros. Estos parámetros son tomados como datos de entrada al software D-ITG, donde se usan para
modelar el comportamiento estadístico a nivel de transmisión de las aplicaciones ofrecidas por la NGN y
emular el comportamiento real de la aplicación a la que se va a medir la QoS hasta llegar a la capa de
transporte (o nivel 4 en el modelo OSI).
NOTA: Este mismo procedimiento se realizó también desde la red NGN ANKLA como transmisor hacia
la red NGN ZTE-PUJ como receptor.
72
Figura 4-13. Generador de tráfico SIP a través de la troncal SIP de dos redes NGN.
4.6.4 Emulación de la trama SIP y Nodo Captura.
Se realizaron por último una serie de pruebas, modificando la trama del protocolo SIP por medio de
software SIP Inspector para comprobar el funcionamiento del Nodo Captura para analizar y solucionar los
problemas que se puedan presentar con el protocolo SIP a nivel de interoperabilidad.
Se realiza una serie de cambios en los parámetros del protocolo SIP y SDP acudiendo a los posibles
problemas que interoperabilidad que se enuncian en el numeral 2.3.
Figura 4-14. Emulador de tráfico SIP.
73
5 ANALISIS DE RESULTADOS
Los resultados obtenidos se basan en el funcionamiento del Nodo Captura en los diversos escenarios, esto
se logró después de hacer las diferentes pruebas de interoperabilidad especialmente evaluando la
señalización SIP y parámetros de QoS18.
5.3 CARACTERIZACION NODO CAPTURA
En este numeral del documento se explica el funcionamiento, puesta en marcha y protocolos de pruebas
realizadas en el Nodo Captura para validar su funcionamiento en un ambiente real en redes NGN´s
evaluando la señalización SIP.
5.3.3 Descripción del funcionamiento Nodo Captura
El nodo captura este compuesto por tres partes, el primero de ellos es un servidor SIP que para nuestro
caso utilizamos Kamailio versión 4, el cual es el encargado de almacenar en una base de datos, (Mysql)
toda la señalización SIP que le llega al nodo captura, el segundo de ellos es un agente captura que hace la
función de puerto de escucha y es el encargado de copiar, modificar y llevar toda la señalización SIP
hacia nuestro servido SIP y por ultimo una interfaz web que es la que se encarga de filtrar los resultados y
mostrarlos en un ambiente web.
Se instala el Nodo Captura, se realiza las modificaciones y desarrollos al interior del mismo para poder
observar el comportamiento de la trama SIP y llegado al caso realizar modificaciones a la trama para la
interoperabilidad de elementos de una red NGN o una integración de dos NGN´s de diferentes fabricantes.
Ver anexo 2.
18
Calidad de Servicio
74
5.3.4 Características del hardware Nodo Captura
Para la implementación e instalación del nodo captura se tuvo en cuenta una serie de requisitos tanto de
hardware como de software como fueron los siguientes:
Se instaló un sistema operativo Linux Ubunto versión 12.04 con todas sus actualizaciones sobre una
máquina que tenía la siguientes características de hardware: Procesador Intel Core i7-3770 3.4GHz, Disco
Duro de 1TB SATA y Memoria DDR3 8GB 1600MHz. El cual demostró un comportamiento aceptable
en cuanto rendimiento de maquina se refiere.
5.3.5 Análisis Nodo Captura
En este numeral se explica la plataforma de pruebas en la que se ha implementado el sistema y el
rendimiento del mismo. Se ha buscado un diseño adecuado para la señalización del protocolo SIP, que
muestre las condiciones reales las cuales permita pruebas y medidas con flexibilidad.
Se ha montado una serie de escenarios para caracterizar, tomar medicas de QoS y observar el
comportamiento de la señalización SIP de la red redes NGN ZTE-PUJ y ANKLA; para esto se puso en
marcha el Nodo Captura y se le inyecto tráfico por medio de generador de tráfico, este nos permite medir
un tráfico real (genera tráfico que emula la señalización SIP y tráfico de media RTP).
El escenario utilizado para las medidas se puede ver en la figura 5-1. Se ha utilizado UDP en lugar de
TCP, para evitar el control de flujo que TCP realiza por defecto. Así, el tráfico interferente siempre es el
mismo, y no se adapta al ancho de banda disponible, haciendo que el sistema trabaje siempre en el peor
caso.
El generador tráfico envía el tráfico en primer lugar al proxy de la red NGN ZTE-PUJ, después al Nodo
Captura el cual realiza la función de escucha para poder evaluar la señalización SIP, después al proxy
destino la red NGN ANKLA y por ultimo al receptor del generador de tráfico de la red de destino en la
figura 5-2 podemos observar la señalización que está pasando por el Nodo Captura.
Esta misma prueba se realizó en sentido contario desde la red NGN ANKLA hacia la red ZTE-PUJ.
75
Figura 5-1. Generación de tráfico SIP las diferentes redes NGN´s
Figura 5-2. Traza de una de las pruebas de interconexión de búsqueda de llamada se sesión de las diferentes NGN´s
Después de realizar un análisis detallado de la señalización SIP que está pasando por el Nodo Captura no
encontramos ningún parámetro adicional o faltante en sus cabeceras de mensajes SIP, la cual se puede ver
en la figura 5-3.
76
Figura 5-3. Diagrama de secuencia de la señalización SIP de una llamada de Softswitch Vs Softswitch
Se realiza una exportación a un analizador de protocolos (wireshark) para observar el comportamiento de
la señalización SIP entre las dos redes NGN´s esto se hace para tener una segunda visualización de los
mensajes SIP el cual no nos arroja ningún comportamiento que no esté contemplado en RFC 3162.
Figura 5-4. Captura de traza de la señalización SIP de una llamada de Softswitch Vs Softswitch
5.3.6 Emulación Trama SIP para el Comportamiento del Nodo Captura.
Al no encontrase ningún tipo de alteración en la trama SIP para la interoperabilidad de redes NGN´s
acudimos a un emulador de trama SIP (Sip Inspector) para probar el funcionamientos del Nodo Captura en
la detección y modificación de parámetros adicionales o faltantes en su señalización SIP (RFC 3261).
77
Se realiza una serie de pruebas invocando los problemas de interoperabilidad mencionados en el numeral
2-3.
5.3.6.4 SIP campo y longitudes mensaje Proxy SIP.
Mientras que el RFC 3261 no define ninguna longitud máxima de los mensajes de SIP, la realidad es que
los proveedores a menudo imponen límites de longitud de los campos y los mensajes recibidos. Ya sea por
razones de seguridad o arquitectura, lo cierto es que hay muchos sistemas que no pueden o no quieren
manejar los campos tan grandes como otros sistemas pueden generarlas. A pesar de que en el [RFC 3261]
se definen algunos códigos de respuesta específicos 413 (Entidad de solicitud demasiado grande), 414
(Request-URI es demasiado larga) y 513(Mensaje demasiado grande).
El Nodo captura realizó modificaciones a la trama SIP simulada para evitar este tipo de errores como son:
413 (Entidad de solicitud demasiado grande), 414 (Request-URI es demasiado larga) y 513(Mensaje
demasiado grande), dando como resultado un autentificación a un proxy. Ver anexo 7.1.
5.3.6.5 Parámetros TEL-URI
El problema de la interoperabilidad más común es en esta área, es la colocación de los parámetros TEL
URI, por ejemplo, el "tgrp" y "contexto tronco" parámetros del [RFC4904], y la "rn", "NPDI", y los
parámetros "CIC" a partir del [RFC4694]. El RFC 3261 sección 19.1.6 está muy claro que todas las
características de la telefonía de abonado, incluyendo los parámetros, se coloca en la parte de user-info de
una SIP URI. Por lo tanto los parámetros de Tel-URI se convierten en parámetros de usuario de SIP,
parámetros SIP URI no.
Se realizó la comprobación de la simulación de un TEL-URI a través del Nodo Captura dando como
resulta un envío de mensajes SIP, transparente para las entidades emisor y receptor. Ver anexo 7.2.
5.3.6.6 Invite –Reinvite (Subscribe)
Crea una invitación al ser negada reenvía la invitación y no puede establecer una comunicación por falta
de parámetros en el protocolo SDP, por ejemplo, que los dispositivos a enrutar las llamadas sobre la base
del códec, o la asignación de ancho de banda, o los dispositivos de transcodificación que se envían no
estén de acuerdo con lo necesario.
78
Se simulo un escenario evitando este tipo de problemas de interoperabilidad, dando como resultado un
envío de señalización SIP éxito. Ver Anexo 7.3
5.3.6.7 Valor De Cabecera PRACK
SIP ofrece un medio para indicar el uso de extensión, los vendedores hacen suposiciones acerca de las
capacidades de los otros UA, literalmente significa "no quiero que esta solicitud tenga éxito, a menos de
que el posible receptor conozca el uso de extensión".
Por ejemplo, la etiqueta de opción 100rel para apoyar PRACK, se inserta en la cabecera requieren de una
petición INVITE. Esto es fundamentalmente erróneo en el uso real. El apoyo a PRACK no es universal,
en todo sentido, y la inserción de esta etiqueta en la cabecera Requerir conduce a las llamadas fallidas.
Se emulo el escenario anterior dando como resultado un envío de señalización SIP éxito. Ver Anexo 7.4
5.4 NODO CAPTURA PLATAFORMA AVAYA
La plataforma AVAYA es una empresa privada de telecomunicaciones que se especializa en el sector de
la telefonía IP y centros de llamada; como lo describimos en la sección 2.3, los problemas de
interoperabilidad que se presenta a nivel de protocolo SIP y SDP se manifiesta en la integración de una
plataforma de un fabricante de telefonía IP caso específico AVAYA con otro fabricante de telefonía IP
genérico; se probó la solución de software denominado NODO CAPTURA en la interoperabilidad de las
plataformas mencionadas anteriormente.
La plataforma AVAYA en la implementación del protocolo de señalización SIP presenta una
implementación adicional en el mensaje de petición PRACK, este mensaje no permite la interoperabilidad
de este fabricante con otros dispositivos de hardware de otro fabricante, en la implementación del NODO
CAPTURA para probar su funcionamiento el modifica la señalización del fabricante AVAYA para que
sea interoperable con otro fabricante.
El NODO CAPTURA soluciono el siguiente problema de interoperabilidad del fabricante AVAYA: SIP
ofrece un medio para indicar el uso de extensión, los fabricantes caso específico de AVAYA hacen
suposiciones acerca de las capacidades de los otros UA, literalmente significa "no quiero que esta solicitud
tenga éxito, a menos de que el posible receptor conozca el uso de extensión".
79
Por ejemplo, la etiqueta de opción 100rel para apoyar PRACK, se inserta en la cabecera requieren de una
petición INVITE. Esto es fundamentalmente erróneo en el uso real. El apoyo a PRACK no es universal,
en todo sentido, y la inserción de esta etiqueta en la cabecera Requerir conduce a las llamadas fallidas.
5.5 MEDICIONES DE QOS
Se realiza una serie de protocolos de prueba para poder medir la QoS, en este caso específico se evaluó
Telefonía IP. Para las pruebas se usó como base la configuración que implementa el codec G.711, con un
consumo de ancho de banda de 74 kb/s unidireccionales equivalentes a aproximadamente 150kb/s
bidireccionales. La comunicación fue en ambos sentidos (ida y vuelta) y no se usó ninguna técnica de
supresión de silencios.
Telefonía IP se clasifica como Clase de QoS 0. Tiene como límite superior para los parámetros que
determinan su QoS: IPTD, 100 ms; IPDV 50 ms; IPLR, 1%; e IPER, 0.001. Las mediciones se realizaron
en cuatro escenarios, cada uno de ellos con un mayor requerimiento de capacidad de transmisión [18].
• Primer escenario: Se realizó una sola llamada IP, de Softswitch Vs Softswitch que tenía como
propósito obtener una medida de referencia, lo que era factible porque las NGN´s carecían de
cualquier otro tipo de tráfico. En consecuencia, las medidas tomadas son ideales en un entorno de
redes IP.
• Segundo Escenario: Se realizó una llamada IP desde el servidor de aplicaciones (Asterisk) de una
red NGN hacia el Softswitch de la otra NGN.
• Tercer escenario: Se realizan con llamadas IP de Softswitch Vs Softswitch simultáneas diez
llamadas.
• Cuarto escenario: Se realizan con llamadas IP desde el servidor de aplicaciones (Asterisk) de una
red NGN hacia el Softswitch de la otra NGN simultáneas veinte llamadas.
La tabla 5-1. Muestra los resultados obtenidos en las cuatro pruebas realizadas.
Tabla 5-1. Mediciones de QoS para llamadas telefónicas IP (Protocolo SIP)
Parametro Limite Superior Medición Diferencia Medición Diferencia Medición Diferencia Medición Diferencia
IPTD (ms) 100 0,1185 -99,8815 10,8085 -89,1915 11,514 -88,486 15,614 -84,386
IPDV (ms) 50 0,107 -49,893 1,224 -48,776 1,897 -48,103 1,809 -48,191
IPLR (%) 1,00% 0,00% -1,00% 0,00% -1,00% 0,00% -1,00% 0,00% -1,00%
IPER 0,001 0 -0,001 0 -0,001 0 -0,001 0 -0,001
CLASE QoS 0 0 0 0 0 0 0 0 0
TELEFONIA IP (SIP) 1 Llamada Softswitch Vs Softswitch 1 llamada Asterisk Vs Softswitch 10 llamadas Softswitch Vs Softswitch 20 llamadas Asterisk Vs Softswitch
80
A continuación se hace una descripción de los resultados obtenidos.
Los resultados anteriores nos muestran en el primer escenario se nota que las medidas que corresponden a
IPTD e IPDV son de tan solo 0.1185ms y 0.107ms, valores “insignificantes” frente al límite superior de la
clase 0. Estos valores “tan bajos” se explican en la diferencia que existe entre el ancho de banda de la red
(100 Mb/s) y el consumo de una llamada (150 kb/s), y en el hecho de que los elementos de las redes
NGN´s solo estén disponibles únicamente para el tráfico generado por esta llamada IP.
El segundo escenario nos muestra unos valores obtenidos para el IPTD (10.8085ms) e IPDV (1.224ms),
estos valores son bastante mayores a los tomados en la medición anterior, alrededor de 100 y 10 veces,
respectivamente, siguen estando muy por debajo de los límites establecidos. Los otros dos parámetros
evaluados, IPLR e IPER, no cambian de un escenario a otro. Los resultados, son altamente favorables,
algo que obedece a una razón fundamental: El único tráfico existente en la red, al momento de la prueba,
es esta llamada IP, la misma que, como se mencionó, tiene un consumo de ancho de banda de 150 kb/s, un
valor muy inferior al ancho de banda de transmisión de la red NGN.
El tercer escenario las llamadas simultáneas ocupan un ancho de banda de aproximadamente 300 kb/s. Si
se compara el IPTD y el IPDV obtenidos en esta medición, con los presentados en el escenario anterior, de
una llamada IP única, se encuentra que no hay mucha diferencia. La conclusión que surge de esta
observación es que, en este tipo de redes, la variación en el valor de los parámetros de IPTD e IPDV no
depende de la cantidad de llamadas simultáneas, sino de disponibilidad.
En el cuarto escenario se puede comparar con el tercer escenario debido a que los valores están por debajo
del límite, con la premisa de que las redes NGN´s se encuentran disponibles exclusivamente para estas
pruebas.
81
6 CONCLUSIONES
El tema de compartir servicios y aplicaciones en las redes NGN nos pone a pensar en una interconexión de
redes NGN con arquitectura Softswitch y en el caso específico ZTE-PUJ y ANKLA, este proceso conlleva
una serie de metodologías de interconexión y parámetros a tener en cuenta como son: la seguridad, la
señalización, la capacidad de tráfico entre otras; como estamos en una redes NGN netamente académicas
nos permite experimentar diferentes soluciones y realizar una serie de pruebas a nuestra disposición.
La interconexión se culminó con éxito dando así al cumplimiento del objetivo general y a los objetivos
específicos; Dándonos cuenta que no se encontraron problemas de interoperabilidad generados por la
señalización (protocolo SIP), pero esta situación se implementó de un Nodo Captura que fuera capaz de
analizar y modificar la señalización SIP.
La interconexión de las redes NGN de estudio se logró con diferentes elementos de red, como se muestra
en la figura 4-12 en este escenario se logró la implementación con éxito del Protocolo SIP/SDP mediante
una troncal SIP, para la transferencia de toda la señalización entre la dos redes NGN con arquitectura
Softswitch, para compartir todos los servicios con los que cada una de ellas cuenta.
Los diferentes análisis que se realizaron a la señalización del protocolo SIP/SDP se hicieron mediante un
software denominado Nodo Captura el cual se basa en varias RFCs y drafts. Este software nos permitió
realizar un estudio de toda la composición del protocolo SIP y llegado el caso realizar alguna
modificación de la trama SIP, después de toda la investigación de la señalización SIP se llegó a la
conclusión que el protocolo SIP/SDP no presenta ninguna modificación en sus estructuras de tramas en
ninguno de sus mensajes de petición ni de respuesta para la interoperabilidad de las redes NGN; para
probar el funcionamiento del Nodo Captura se realizó algunas simulaciones a la trama SIP para forzar
problemas de interoperabilidad como se describieron en el numeral 2.3 , estas pruebas se implementaron
por medio de un software denominado SIP Inspector dando como resultado el funcionamiento del Nodo
Captura en el análisis y solución de posibles errores encontrados en el protocolo SIP mediante la
simulación.
Se probó la solución del NODO CAPTURA en un escenario totalmente distinto, la interoperabilidad del
fabricante AVAYA con el fabricante genérico, encontrando problemas de interoperabilidad en el primer
fabricante; AVAYA presenta problemas de interoperabilidad con dispositivos de hardware de un
fabricante diferente; el NODO CAPTURA mediante la modificación de la señalización del mensaje de
82
petición PRACK, permito la interoperabilidad de este fabricante con otros dispositivos de VoIP de otro
fabricante genérico.
Por último se realizó algunos análisis de QoS en el funcionamiento de la troncal SIP, generando tráfico
SIP de múltiples conexiones a través del escenario de interoperabilidad montado, dando unos resultados
muy favorables como se muestra en la tabla 5-1.
Después de todo el análisis que se le realizo a la señalización del protocolo SIP, se demostró todo el
potencial que cuenta este protocolo en procesos de interoperabilidad de redes no solo de redes NGN, en
especial los que tiene que ver con comunicaciones unificadas.
Referente a esta parte del proyecto, como línea de trabajo futura seria realizar pruebas de señalización de
peticiones en paralelo en uno o varias redes conjuntamente, para así demostrar la interoperabilidad de toda
una solución de redes que manejas el protocolo SIP.
También habría que desplegar esta aplicación en un entorno NGN basado en arquitecturas IMS.
83
7 BIBLIOGRAFIA
LIBROS Y PUBLICACIONES
[1] Alan B. Johnston, Artech House telecommunications library, “SIP Understanding the session initiation
protocol” Second edition, 2004
[2] KEAGY, Scott, Integración de redes de voz y datos, tercera edición, Cisco Publication, Madrid, 2001
[3] Schulzrinne, H., and E. Wedlund, “Application-Layer Mobility Using SIP,” Mobility Mobile
Computing and Communications Review (MC2R), Vol. 4, No. 3, July 2000.
[4] Franklin D. Ohrtman, JR “Softswitch Architecture for VoIP”, McGraw-Hill, 2004.
[5] Grupo redes NGN. Medición de calidad del servicio en redes de próxima generación (NGN) en
Colombia, Entregables 1 a 4, Centro de Investigación de las Telecomunicaciones CINTEL, 2012.
[6] DÍAZ, Yony Fernando. “Estudio comparativo de las recomendaciones ITU-T G.107, P.862 y P.563
para evaluar la calidad de la voz en redes IP”. Universidad del Valle, Colombia. (2007).
[7] Zohreh Ayatollahi. “Interoperability Problems In Next Generation Network Protocols” IEEE 2008.
[8] Iravani Tabrizipoor, P. Gooran Oreimi, M. Pirhadi, M. Mirzabaghi, Y.Nasr Harandi, and M. Yaghoubi
Waskasi, “Investigation of Basic Services Interoperability Problems in Next Generation Networks",
ECUMN'2007, Toulouse, France, Feb 2007.
[9] KEAGY, Scott, Integración de redes de voz y datos, tercera edición, Cisco Publication, Madrid, 2001
NORMAS
[10] RFC 3261 “SIP: Session Initiation Protocol”, http://www.ietf.org/rfc/rfc3261.txt
[11] RFC 3265 “SIP Specific Events,” http://www.ietf.org/rfc/rfc3265.txt
84
[12] RFC 2327 “SDP: Session Description Protocol,” http://www.ietf.org/rfc/rfc2327.txt
[13] RFC 3372 “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,”
http://www.ietf.org/rfc/rfc3372.txt
[14] RFC 3455 “Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-
Generation Partnership Project (3GPP),” http://www.ietf.org/rfc/rfc3455.txt
[15] UIT-T (Unión Internacional de Telecomunicaciones, Estandarización); “Iniciativa de normalización
mundial de las redes de la próxima generación”.
[16] UIT-T (Unión Internacional de Telecomunicaciones, Estandarización Y.1540, “Servicio de
comunicación de datos con protocolo Internet - Parámetros de calidad de funcionamiento relativos a la
disponibilidad y la transferencia de paquetes de protocolo Internet”
[17] ETSI TS 185 001 V1.1.1 (2005-11), Next Generation Network (NGN) - Quality of Service (QoS)
Framework and Requirements. (2005)
[18] One-way transmission time (recommendation G.114). International Telecommunication Union (ITU),
feb. 1996.
[19] ETSI TISPAN. ES 282 003 Resource and Admission Control Subsystem (RACS) Functional
Architecture. 2006.
[20] UIT-T (Unión Internacional de Telecomunicaciones / Sector de normalización de las
telecomunicaciones). Recomendación Y.1541 (02/2006), Objetivos de calidad de funcionamiento de red
para servicios basados en el protocolo Internet. (2006)
INTERNET
[21] http://www.grid.unina.it/software/ITG/ Emulador de tráfico (Consultado febrero 2013).
[22] http://www.sipcapture.org/ Nodo captura (Consultado enero 2013).
[23] http://www.kamailio.org/w/ Servidor SIP (Consultado febrero 2013).
[24] https://code.google.com/p/captagent/ Agente que captura la señalización SIP (Consultado Enero
2013).
[25] https://sites.google.com/site/sipinspectorsite/ Emulador de tramas SIP (Consultado enero 2013).
85
8 ANEXOS
Anexos adjuntos en un CD.
86
ACRONIMOS
ADSL Asymmetric Digital Subscriber Line
BER Bit Error Rate
D-ITG Distributed Internet Traffic Generator
DNS Domain Name System
ETSI European Telecommunications Standards Institute
HTTP Hypertext Transfer Protocol
IAD Integrated Access Device
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
IP Internet Protocol
IPDV IP Delay Variation
IPER IP Packet Error Ratio
IPDR IP packet duplicate ratio
IPLAR IP Packet Loss Ratio
IPLR IP Packet Loss Ratio
IPTD IP Transfer Delay
ITU International Telecommunication Union
NGN Next Generation Network
QoS Quality of Service
87
RFC Request For Comments
RTCP Real-Time Transport Control Protocol
RTP Real-Time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
UA User Agent
UAC User Agent Client
UAS User Agent Servidor
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
VBR Variable Bit Rate