MIRAR DEFINIR TEMA SanchezPachecoWilliamFernando2013

DISEO E IMPLEMENTACIN DE UNA SOLUCIN DE INTERCONEXIN DE REDES NGN
MEDIANTE EL PROTOCOLO SIP
ING. WILLIAM FERNANDO SANCHEZ PACHECO
PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERA
DEPARTAMENTO DE ELECTRNICA
BOGOT D.C.
MAYO DE 2013

Trabajo de profundizacin para optar por el ttulo de

Magister en Ingeniera Electrnica
Director:
LUIS CARLOS TRUJILLO ARBOLEDA
Ingeniero Electrnico, M.Sc.

BOGOT D.C.
MAYO DE 2013
2

MAESTRA EN INGENIERIA ELECTRNICA
RECTOR MAGNFICO:
P. JOAQUN SNCHEZ GARCA S. J.
DECANO ACADMICO:
Ing. JORGE SANCHEZ, Ph.D.
DECANO DEL MEDIO UNIVERSITARIO:
P. SERGIO BERNAL RESTREPO S. J.
DIRECTOR DE LA MAESTRA:
DIRECTOR DEL TRABAJO DE GRADO:
Ing. CESAR LEONARDO NIO. PH.D.

Ing. LUIS CARLOS TRUJILLO ARBOLEDA, MSc.
NOTA DE ACEPTACIN
Nota de aceptacin
______________________
______________________
______________________
_____________________
Presidente del Jurado
_____________________
Jurado
_____________________
Jurado
Bogot, Mayo de 2013
ARTCULO 23 DE LA RESOLUCIN No. 13 DE JUNIO DE 1946
La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de
grado. Slo velar porque no se publique nada contrario al dogma y la moral catlica y porque los
trabajos no contengan ataques o polmicas puramente personales. Antes bien, que se vea en ellos el
anhelo de buscar la verdad y la justicia.
Artculo 23 de la Resolucin No. 13, del 6 de julio de 1946,

por la cual se reglamenta lo concerniente a Tesis y Exmenes
de Grado en la Pontificia Universidad Javeriana.
DEDICATORIA
Agradezco a mi mam, a mis hermanos

Y en general a toda mi familia que me
Apoyo en todo m proceso de
Formacin acadmica.
William Fernando Snchez Pacheco
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.
Caractersticas 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 Peticin....................................................................................................... 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 descripcin de la sesin SDP) ........................ 36
2.3.
3.
PROBLEMAS GENERALES DE INTEROPERABILIDAD .................................................. 37
2.3.1.
Problemas especficos de interconexin del protocolo SIP ............................................... 38
2.3.2.
Problemas especficos de interconexin del protocolo SIP e SDP .................................... 39
ESPECIFICACIONES ................................................................................................................... 40
3.1
Red NGN ZTE-PUJ ............................................................................................................ 42
3.2
Red NGN ANKLA ............................................................................................................. 43
3.3
Infraestructura de Interconexin redes NGNs. .................................................................... 44
3.3.1
Nodo Captura .............................................................................................................. 44
3.3.2
Generador de trfico.................................................................................................... 46
3.3.3
Simulador trama SIP ................................................................................................... 47
3.3.3.4
Firewall ...................................................................................................................... 47
DESARROLLOS. .......................................................................................................................... 48
7
4.3
ANLISIS DEL PROTOCOLO SIP. ...................................................................................... 48
4.3.3
Anlisis del protocolo SIP ZTE-PUJ ............................................................................... 48
4.3.4
Anlisis del protocolo SIP ANKLA................................................................................. 54
4.3.5
Comparacin de las dos redes NGNs ............................................................................. 59
4.4
PRUEBAS DE INTEROPERABILIDAD ............................................................................... 59
4.4.3
Escenario de interoperabilidad ZTE-ANKLA .................................................................. 59
4.4.4
VPN y sus caractersticas 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 Descripcin de los Parmetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y
ANKLA67
4.5
METODOLOGA DE ANLISIS DE INTEROPERABILIDAD............................................ 67
4.5.3
Identificacin y reconocimiento ...................................................................................... 68
4.5.3.4
Llamada Simple Entre Dispositivos IP A Travs De Troncal SIP ................................. 69
4.5.3.5
Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones ...................... 70
4.6
INTEGRACIN GENERADOR DE TRFICO, NODO CAPTURA Y EMULADOR DE
TRAMA SIP ...................................................................................................................................... 71
4.6.3
Integracin Nodo Captura y Generador de Trfico .......................................................... 71
4.6.4
Emulacin de la trama SIP y Nodo Captura. .................................................................... 72
ANALISIS DE RESULTADOS ..................................................................................................... 73

5.3
CARACTERIZACION NODO CAPTURA ............................................................................ 73
5.3.3
Descripcin del funcionamiento Nodo Captura................................................................ 73
5.3.4
Caractersticas del hardware Nodo Captura ..................................................................... 74
5.3.5
Anlisis Nodo Captura .................................................................................................... 74
5.3.6
Emulacin 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
Parmetros 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
CONCLUSIONES ......................................................................................................................... 81
BIBLIOGRAFIA ........................................................................................................................... 83
8
ANEXOS ....................................................................................................................................... 85
ACRONIMOS ....................................................................................................................................... 86
LISTA DE FIGURAS
Figura 2-1. Evolucin de la Red Clsica a la NGN Simplificacin de la torre de Protocolos..17

Figura 2-2. Arquitectura de las redes de nueva generacin (NGN)..18
Figura 2-3. Separacin 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. Posicin de SIP dentro de la pila de protocolos.28
Figura 2-8. Flujo de mensajes de una Sesin SIP.28
Figura 2-9. Flujo de mensajes de una Sesin 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 bsica de interconexin las diferentes redes NGNs41
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. Comunicacin bsica del protocolo SIP de la red NGN ZTE-PUJ ...49
Figura 4-2. Comunicacin bsica 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 SIP62
Figura 4-5. Arquitectura PROXY de interconexin las diferentes redes NGNs de estudio63
Figura 4-6. Llamada saliente: Mensaje INVITE + SDP con timbrado local...64
10
Figura 4-7. Llamada saliente: Mensaje INVITE + SDP con conexin temprana de media....64
Figura 4-8. Diagrama bsico de la VPN las diferentes redes NGNs.......65
Figura 4-9. Diagrama bsico de NAT las diferentes redes NGNs...66
Figura 4-10. Configuracin VPN de la Red NGN ZTE-PUJ y la red NGN ANKLA68
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexin de usuarios las diferentes redes
NGNs...69
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexin de diferentes componentes de redes
NGNs...70
Figura 4-13. Generador de trfico SIP a travs de la troncal SIP de dos redes NGN72
Figura 4-14. Emulador de trfico SIP...72
Figura 5-1. Generacin de trfico SIP las diferentes redes NGNs..75
Figura 5-2. Traza de una de las pruebas de interconexin de bsqueda de llamada se sesin de las
diferentes NGNs..75
Figura 5-3. Diagrama de secuencia de la sealizacin SIP de una llamada de Softswitch Vs
Softswitch.76
Figura 5-4. Captura de traza de la sealizacin SIP de una llamada de Softswitch Vs Softswitch76
11
LISTA DE TABLAS
Tabla 2-1. Categoras de Respuesta SIP...33

Tabla 2-2. Cdigo 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 telefnicas IP (Protocolo SIP)..79
12
ANEXOS
Anexo 1. Sealizacin SIP en diversos escenarios.

Anexo 2. Cdigo fuente NODO CAPTURA.
Anexo 3. Archivos generados para medir QoS.
Anexo 4. Manual de instalacin NODOD CAPTURA.
Anexo 5. Manual de instalacin Generador de Trfico.
Anexo 6. Documentacin de interconexin redes NGNs.
Anexo 7. Emulaciones Trama SIP.
13
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 ms importante para la gran mayora 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 aparicin de una nueva generacin de arquitecturas de red (todo IP), emerge tambin un nuevo
portafolio de servicios, en los que se mezclan voz y datos; estar a la vanguardia de esta nueva generacin
de redes (NGN1), se convierte en un factor determinante de competitividad para los diferentes actores del
sector de las Telecomunicaciones y las Tecnologas de Informacin.
Al ser un mercado creciente encontramos mltiples operadores y fabricantes, que deben experimentar un
proceso de interconexin de elementos de red NGN, a travs de distintos protocolos y adems con otras
redes NGN, (alianza estratgica entre operadores y fabricantes) este escenario les origina numerosos
problemas de interconexin 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 Sesin), para la sealizacin en las redes NGN.
El protocolo SIP, es el que permite establecer, modificar y terminar sesiones multimedia; al ser el
protocolo determinado para la sealizacin de las redes NGNs, el problema est en que los diferentes
fabricantes de redes de Nueva Generacin implementan el protocolo SIP para la sealizacin de sus redes,
pero cada uno lo implementa con alguna restriccin o parmetro adicional, esto se hace debido a la
flexibilidad que tiene el RF3261 para no permitir la integracin de partes de diferentes fabricantes, esto
obliga a interactuar con su solo proveedor para la totalidad de la integracin de la red.
En este trabajo de grado disea e implementa una solucin de interconexin de dos redes NGN (Centro de
Tecnologas de Telecomunicaciones ZTE-PUJ Pontificia Universidad Javeriana y el
1
Redes de Nueva Generacin

Instituto Europeo de Normas de Telecomunicaciones
3
Telecomunicaciones e Internet Servicios convergentes y protocolos de red avanzada
2
14
Laboratorio
ANKLA). El desarrollo se bas en cuatro partes (la interconexin de las redes NGNs mediante una
conexin de internet VPN, un nodo captura que realiza el escucha de toda la sealizacin SIP, una
verificacin de su estructura y por ltimo se emplea un generador de trafico de VoIP para ver generar
grandes flujos de sealizacin con el protocolo SIP).
El objetivo general de este proyecto es; Disear e implementar una solucin de interconexin de redes
NGN mediante el protocolo SIP, para este fin se cumplieron los siguientes objetivos especficos:
Estudiar y analizar los parmetros del protocolo SIP en la interconexin redes NGN ZTE-PUJ y
ANKLA.
Definir e Implementar un mdulo basado en el protocolo SIP (software) que permita la

interconexin de redes NGN ZTE-PUJ y ANKLA.
Evaluar la funcionalidad y el desempeo del mdulo (software) del protocolo SIP, a travs de las
pruebas de operatividad de las redes NGN ZTE-PUJ y ANKLA.
El documento se organiza de la siguiente forma: en el MARCO TERICO, 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 interconexin de las dos redes ZTE-PUJ y ANKLA y se referencia la
descripcin de cada una de las redes NGN. En los DESARROLLOS, numeral 4, se explica cmo se
analiz el protocolo SIP en cada una de las redes NGN y como se implement la interconexin para
posteriormente realizar la verificacin, validacin de la interconexin. En el numeral 5, se muestran los
resultados obtenidos, y en el numeral 6 se concluye acerca de la puesta en marca de la interconexin y el
buen funcionamiento de la misma.
15
2. MARCO TEORICO
En el marco terico se hace un recuento de las diferentes arquitecturas y protocolos de comunicacin que
son necesarios para entender el contexto de interconexin de redes NGN.
2.1. REDES DE NUEVA GENERACION (NGN)
En Colombia se ha iniciado la migracin 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 comn 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 caracterstica 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 inalmbrico. Lo que
hace dos dcadas se intent conseguir con xito muy limitado mediante la Red Digital de Servicios
Integrados (RDSI), es decir, mltiples servicios a travs de un solo punto de acceso, est siendo
materializado hoy en da por las redes de nueva (o prxima) generacin (Next Generation Networks o
NGNs por sus siglas en ingls) con ncleo IP (Internet Protocol).
La definicin de la UIT para NGN es: Red basada en paquetes que permite prestar servicios de
telecomunicacin y en la que se pueden utilizar mltiples tecnologas de transporte de Banda Ancha
propiciadas por la QoS, y en la que las funciones relacionadas con los servicios son independientes de las
tecnologas 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 eleccin. Se soporta movilidad generalizada que
permitir la prestacin coherente y ubicua de servicios a los usuarios. [15].
16
Figura 2-1. Evolucin de la Red Clsica a la NGN Simplificacin 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 interconexin e integracin de nuevos servicios. Estos cuatro
niveles son los siguientes [4]:
Servicios: Esta interfaz es la encargada de la conexin lgica con los usuarios.
Control: Interfaz intermedia que permite la comunicacin 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 tecnologa usada puede ser en cable (fibra o cobre) o inalmbrica.
Tomado de Diseo de polticas ptimas en un entorno de convergencia de los medios de comunicacin y las telecomunicaciones
OSIPTEL
17
Figura 2-2. Arquitectura de las redes de nueva generacin (NGN)5
2.1.2.
Caractersticas de las redes NGN
El factor diferenciador de las redes NGNs es la separacin 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. Separacin de los servicios y el transporte en redes NGN6
Tomado de Telefnica, 2006

Tomado de UIT Y.2011
18
En primer lugar, hay un conjunto de funciones de transporte que se encargan nicamente del transporte de
la informacin digital de cualquier tipo entre dos puntos fsicamente separados. El transporte puede estar
formado por un conjunto complejo de redes, que constituyen las capas 1 a 3 en el modelo de referencia
bsico 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 telefona,
servicio web, etc. Los servicios pueden estar formados por un conjunto complejo de plataformas de
servicios fsicamente distribuidos, o, en el caso ms sencillo, nicamente las funciones de servicio entre
dos ubicaciones de usuarios extremo.
En segundo lugar existe un conjunto de funciones de aplicacin relacionadas con el servicio solicitado.
Los servicios pueden ser, por ejemplo, servicios de voz (incluido el servicio de telefona), servicios de
datos (no limitndose ste a los servicios basados en la web), o servicios de vdeo (no limitndose
tampoco a las pelculas y a los programas de televisin), o una combinacin de stos (por ejemplo,
servicios multimedia, como la telefona vdeo y los juegos).
Dado que existen muchas maneras de clasificar los servicios (por ejemplo, servicios en tiempo real/no en
tiempo real y servicios unidifusin/multidifusin/radiodifusin), en la figura 2-1 se proporciona un
ejemplo de lista de servicios (voz, datos y videos) que se prev ofrecern las redes de prxima generacin
[15].
Actualmente las arquitecturas funcionales de las redes NGN implementadas son::
SOFTSWITCH/MGC: Tambin es conocido como Call Agent o Media Gateway Controller

(MGC). Es el mecanismo que provee el control de provisin de servicio en la red. Est a cargo
del Control de llamadas, maneja el control de las Pasarelas de Medio (Acceso y/o Enlace) va
protocolo H.248. Realiza la funcin de una pasarela de sealizacin o usa una pasarela de
sealizacin para trabajar conjuntamente con la red de sealizacin PSTN N7. Provee conexin a
los servidores de Red inteligente/aplicaciones para proveer los mismos servicios que los
disponibles para los abonados TDM.
19
IMS/MGC: La arquitectura genrica de IMS (IP Multimedia Subsystem) soporta la comunicacin

entre equipos que utilizan SIP para la sealizacin y la administracin de sesiones, adems 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
aplicacin, quienes se encargan de: invocar los servicios, identificar qu sealizacin es requerida
y de qu forma los servicios interactan 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 descripcin 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 continuacin:
Telefona: NGN soporta la necesidad varios servicios de telefona existentes (ej, Llamada en
espera, llamada tripartita, reenvo 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 caractersticas de valor agregado.
Servicios multimedia: Permite que los usuarios interacten utilizando voz, video y/o datos.
Virtual Private Networks (VPNs): Mejora las capacidades de las empresas al permitir una
cobertura amplia, geogrficamente dispersa, al combinar las redes privadas existentes con
porciones de la red pblica.
Computacin pblica en la red: Provee servicios pblicos en la red para negocios y

consumidores.
Mensajera unificada: Soporta la entrega de mensajes de voz, correo electrnico, fax y

mensajera instantnea a travs de interfaces comunes.
Comercio electrnico: Permite a los consumidores la compra de bienes y servicios sobre la red.
Servicios para empresas y compras desde el hogar pertenecen a esta categora de servicios.
Servicios de Call Center: Un suscriptor puede realizar una llamada a un centro de contacto para
la adquisicin de nuevos productos o realizar consultas.
Juegos interactivos: Ofrece a los consumidores una forma para conocer y establecer sesiones de
juegos interactivos en lnea.
20
Realidad Virtual Distribuida: Se refiere a la tecnologa que genera representaciones de los

eventos del mundo real, personas, lugares, experiencias, etc.
Domtica: Con la llegada los electrodomsticos inteligentes y de las redes al hogar, estas
aplicaciones pueden monitorear y controlar los sistemas de entretenimiento caseros y otros
aparatos electrodomsticos.
Consultora: Involucra la publicidad, para proveer informacin 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 continuacin:
VoIP.
Web Browsing.
Chat.
Mensajera Instantanea.
WAP Browsing.
Mensajera 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 prxima generacin.
Es un dispositivo que provee control de llamada y servicios inteligentes para redes de conmutacin de
paquetes. Un Softswitch sirve como plataforma de integracin para aplicaciones e intercambio de
servicios. El Softswitch es capaz de transportar trfico de voz, datos y vdeo de una manera ms eficiente
21
que los equipos existentes, habilita al proveedor de servicio para soportar nuevas aplicaciones multimedia
integrando las existentes con las redes inalmbricas avanzadas para servicios de voz y Datos.7
Un Gateway Controller combinado con el media Gateway y el Signalling Gateway representan la mnima
configuracin de un Softswitch. El elemento controlador es frecuentemente conocido como Media
Gateway Controller (MGC). A continuacin 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 desconexin 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 sealizacin SS7 y los nodos
manejados por el Softswitch en la red IP.
MEDIA GATEWAY: Actualmente soporta Multiplexacin por divisin de tiempo (TDM) para
transporte de paquetes de voz al switch. Las aplicaciones de Codificacin de voz, Decodificacin
y compresin son soportadas, as como las interfaces de la Red telefnica pblica (PSTN) y los
protocolos CAS e ISDN.
MEDIA SERVER: Mejora las caractersticas funcionales del Softswitch, si es requerido soporta
Procesamiento Digital de Seales (DSP) as como la funcionalidad de la Respuesta de voz
interactiva (IVR).
FEATURE SERVER: Controla los datos para la generacin de la facturacin, usa los recursos y
los servicios localizados en los componentes del Softswitch.
SERVICES TARGETED: realiza funciones como traslacin de direcciones, enrutamiento, IVR,

emergencia, llamadas en espera entre otras.
Tomado de RIOS, Javier y GARCIA, Moraima, Softswitch, febrero 2004
22
SERVICE INTERFACE: Proporciona soporte para servicios suplementarios y clases de

servicios. Posee una arquitectura independiente de sealizacin, soporta protocolos como SIP,
H.323, SS7 e ISDN.
Un Softswitch puede contener uno o ms componentes, sus funciones pueden residir en un sistema o
expandirse a travs 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 genrica del IMS fue creada por 3GPP8 soporta la comunicacin entre equipos que utilizan
SIP para la sealizacin y la administracin de sesiones, adems de los protocolos SIP, SDP,
DIAMETER, RTP, RTCP, RSVP y DiffServ, para operaciones y manejo de recursos multimedia
aplicacin, quienes se encargan de: invocar los servicios, identificar qu sealizacin es requerida y de
qu forma los servicios interactan ente s.
La arquitectura de NGN IMS/MGC suministra acceso a cualquier servicio sin importar el tipo de medio,
usa el plano de control comn 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
3rd Generation Partnership Project es una colaboracin de grupos de asociaciones de telecomunicaciones.
23
necesita ninguna modificacin, ni ninguna nueva tecnologa 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 condicin de suscriptores
durante la duracin de la sesin de registro;
Control de la Sesin ejecuta el establecimiento de la llamada/sesin, modificacin y

terminacin;
Control de Servicio interacta con los Servidores de Aplicacin (Application Server) para el
soporte de servicios y aplicaciones;
Monitoreo de la llamada y generacin de registros de tarifacin;
Provee seguridad para la sesin.
Tomado de www.3gpp.org/
24
El Proxy CSCF es el primer contacto para que un mvil 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 mviles SIP y la red IMS;
Ejecuta una poltica 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
sealizacin 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
mltiplos 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 peticin SIP recibida de otra red en direccin al S-CSCF;
Obtener del HSS (Home Subscriber Subsystem) la direccin del S-CSCF;
Enrutar una peticin SIP o respuesta para la designacin ptima del MGW (Home Control of
roamers).
Enviar peticiones/respuestas SIP al I-CSCF en una red de otro operador para designacin ptima
de un Media Gateway (MGW), para terminacin de una llamada en la red pblica conmutada
(STFC).
BREAKOUT GATEWAY CONTROL FUNCTION (BGCF): El BGCF selecciona la red en la

cual el acceso a la red pblica 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 sealizacin de esta sesin a un BGCF o
MGCF (dependiendo de la configuracin) en la otra red. El objetivo final es minimizar el
recorrido de la llamada/sesin.
MEDIA GATEWAY CONTROL FUNCTION (MGCF): El MGCF provee la funcin de

interoperabilidad de la sealizacin entre los elementos de la red IMS y las redes legadas (STFC).
El MGCF controla un conjunto de MGWs a travs de la sealizacin H.248. La sealizacin
H.248
permite
el
establecimiento
de
recorridos
para
las
sesiones
interfuncionamiento (bajo la perspectiva de trfico) entre la STFC y la red IMS.

25
que
necesitan
MULTIMEDIA RESOURCE FUNCTION CONTROLLER (MRFC): El MFRC controla los

recursos de media del elemento Funcin de Recursos Multimedia Procesador (MRFP). Por
ejemplo, recursos necesarios para proveer tonos, anuncios y conferencia.
SIGNALING GATEWAY: Provee la conversin de sealizacin en ambas direcciones en la capa

de transporte entre SS7 y sealizacin basada en IP (por ejemplo ISUP/SS7 e ISUP/SCTP/IP).
POLICY DECISION FUNCTION (PDF): PDF es la funcin lgica que implementa la decisin
en relacin a la poltica 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 lgicas de
control (CSCF) acceden a los suscriptores. El HSS contiene los datos del usuario, que son pasados
al S-CSCF, y almacena la informacin temporaria con la localizacin 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
26
2.2. PROTOCOLO SIP (SESSION INITIATION PROTOCOL)
SIP es un protocolo especificado por la IETF en el RFC 3261[10], adems es aceptado como un protocolo
estndar por la organizacin 3GPP y forma parte de la arquitectura de NGN Redes de Nueva
Generacin. Adems SIP es usado globalmente como protocolo de sealizacin para VoIP.
Este protocolo se ubica en la capa aplicacin y permite a las terminales IP establecer, en rutar, modificar y
cerrar sesiones de comunicaciones a travs de redes IP; SIP por s mismo no garantiza ni reserva ancho de
banda para la sesin ni provee calidad servicio (QoS) y no define un mecanismo de entrega de los
paquetes que transportan la informacin de la sesin. SIP est diseado 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 direccin E-mail. Usa estas direcciones de
tipo correo electrnico 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 direccin, es decir por medio de una URL
SIP; logrando la independencia del dispositivo, y sin hacer distincin alguna entre voz y datos, telfono u
ordenador.
Para permitir establecer una sesin entre dos terminales, SIP provee cinco servicios de sealizacin:
Localizacin de los terminales
Invitacin a la sesin
Intercambio de informacin de media para establecer la sesin
Modificacin de sesiones existentes
Terminacin de sesiones
Como ya se dijo SIP es un protocolo presente en la capa de aplicacin diseado 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 parmetros de inicializacin de los flujos multimedia
SDP (protocolo de descripcin de sesin).
27
Figura 2-7. Posicin de SIP dentro de la pila de protocolos [1].
El protocolo SIP nicamente se utiliza para la sealizacin y no reserva recursos, y en consecuencia, no

puede asegurar la calidad de servicio. Una vez que la sesin est establecida, los participantes
intercambian directamente su trfico audio/video a travs del protocolo Real-Time Transport Protocol
(RTP).
En las figuras 2-8 y 2-9 se explica de manera sencilla cmo se lleva a cabo una sesin SIP entre dos
usuarios y se representan las funciones bsicas de SIP: localizacin del terminal, seal de la intencin de
un usuario de comunicarse, negociacin de los parmetros de la sesin a establecerse y terminacin de la
sesin una vez establecida.
Figura 2-8. Flujo de mensajes de una Sesin SIP [10].
28
Figura 2-9. Flujo de mensajes de una Sesin SIP con un analizador de protocolos.
De esta manera SIP por medio de mensajes de peticin y de respuesta provee la sealizacin necesaria
para el establecimiento y terminacin 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. Adems pueden conocer varias
29
alternativas para localizar a un agente de usuario, y pueden intentar cada una de ellas en un proceso de
bifurcacin que puede ser paralelo o secuencial.
El Servidor de Re direccionamiento (Redirect Server): este servidor acepta solicitudes SIP, traduce la
direccin 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 devolucin de una llamada, el Proxy Server tiene la capacidad de traducir el nmero del
destinatario recibido en el mensaje SIP, a un nmero 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 nmero 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 aplicacin sobre un equipo de usuario que emite
y recibe solicitudes SIP. Se materializa por un software instalado sobre un UserEquipment o UE (PC,
telfono IP). Los Clientes de agentes del usuario (UAC) envan 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 direccin SIP.
El Registrador (Registrar): se trata de un servidor quien acepta las solicitudes SIP REGISTER. SIP
dispone de la funcin de registro de los usuarios. El usuario indica por un mensaje REGISTER emitido al
registrador, la direccin donde se lo puede localizar (direccin IP). El registrador actualiza la base de
datos de localizacin. El registrador es una funcin 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 Peticin
Mtodos SIP
El RFC 3261[10] define seis solicitudes/requerimientos o mtodos SIP.
INVITE [RFC3261] usado para el establecimiento de una sesin entre UAs. Contiene
informacin 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 recepcin de una respuesta SIP.

30
BYE [RFC3261] permite la liberacin de una sesin 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 direccin SIP y
su direccin 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 mtodos SIP que soporta [10].
2.2.2.1. Extensiones del Protocolo SIP
SUBSCRIBE [RFC3265] utilizado para requerir notificacin 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 informacin de registro.
NOTIFY [RFC3265] utilizado para notificar un evento. Actualizaciones instantneas desde un

registrador a un cliente UA acerca de los usuarios que han cambiado la informacin 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
mtodo, es decir una transferencia a otra URL.
MESSAGE [RFC3428] permite la transferencia de mensajes instantneos. La mensajera

instantnea Instant Messaging o IM consiste en el intercambio de mensajes entre usuarios en
seudo tiempo real.
INFO [RFC2976] permite transferir informaciones de sealizacin durante la llamada (por

ejemplo: ISUP).
PRACK [RFC3311] definido para realizar una recepcin confiable de las respuestas temporales
de tipo 1XX.
UPDATE [RFC3311] permite a un terminal SIP actualizar los parmetros de una sesin
multimedia (flujo media y codecs). El mtodo UPDATE puede ser enviado antes de que la sesin
sea establecida.
31
2.2.2.2. Estructuras e mensajes.

Un mensaje SIP consta de las siguientes partes:
Lnea de inicio: indica el propsito del mensaje.
Cuerpo: proporcionan detalles del mensaje.
Lnea 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 lnea de inicio de una solicitud es el siguiente:
<Mtodo> <Solicitud-URI> <versin SIP>
<Mtodo> Es uno de los tipos de solicitudes SIP
<Solicitud-URI> Es el URL SIP u otro tipo de URL de la entidad que debera recibir el mensaje.
<versin SIP> Es actualmente SIP/2.0
A continuacin algunos ejemplos:
INVITE sip:jdoe@company.com SIP/2.0
ACK sip:+14085551212@192.168.1.1;user=phone SIP/2.0
BYE tel:+1-408-555-1212;postd=p4199 SIP/2.0
2.2.3.
Mensajes de Respuesta
Despus de haber recibido e interpretado un requerimiento SIP, el destinatario de este requerimiento

devuelve una respuesta SIP.
El formato de lnea de inicio de una respuesta es el siguiente:
<VersinSIP> <Cdigo de estado> <Frase razn>
32
<VersinSIP> actualmente es SIP/2.0

<Cdigo de estado> y <Frase razn> se establecen a uno de los pares de los cdigo de Respuesta SIP
SIP /2.0 404 Not Found
SIP /2.0 180 Ringing
SIP /2.0 200 OK
Las respuestas SIP versin 2 estndar estn codificadas con tres dgitos de respuesta y una descripcin
textual. Las respuestas se clasifican en seis categoras, identificadas por el primer dgito el cual identifica a
que categora pertenece como se muestra en la siguiente tabla.
Tabla 2-1. Categoras de Respuesta SIP [1].
En la siguiente tabla se muestra la totalidad de los mensajes de respuesta de tres dgitos con su descripcin
[10].
33
CODIGO DESCRIPCIN DE LA RESPUESTA CODIGO DESCRIPCIN DE LA RESPUESTA

1XX
100
180
181
182
183
2XX
200
202
3XX
300
301
302
305
380
4XX
400
401
402
403
404
405
406
407
408
409
410
411
413
414
415
416
INFORMACION
Intentando
Ringing
La llamada est remitindose
En Cola
Progreso de la sesin
SUCESOS
OK
Aceptado
REDIRECCION
Opciones mltiples
Movido permanentemente
Movido temporal
Utilizar proxy
Servicio Alternativo
ERROR DEL CLIENTE
Respuesta mala
Sin autorizacion
Pago requerido
Prohibido
No encontrado
Mtodo no permitido
No aceptable
Se requiete autenticacin de Proxy
Se requiere lmite de tiempo
Conflicto
Hecho
Longitud requerida
Entidad solicitada demasiado grande
Solicitud-URI demasiado grande
Tipo de medio no soportado
Esquema URI no soportado
420
421
422
423
428
429
480
481
482
483
484
485
486
487
488
489
491
493
5XX
500
501
502
503
504
505
513
6XX
600
603
604
606
Extensin errnea
Extensin requerida
Sesin del temporizador de intervalos demasiado pequeo
Intervalo demasiado corto
Utilice token de autenticacin
Proporcionar identidad REFER
No disponible temporalmente
Circuito de llamada o transaccin no existe
Detectado un bucle
Demasiados saltos
Direccin incompleta
Ambiguo
Ocupado aqu
Solicitud terminada
No aceptable aqu
Terminacin de evento
Solicitud pendiente
Solicitar indescifrable
ERROR DEL SERVIDOR
Error al interior del servidor
No implementado
Gateway errneo
Servicio no disponible
Lmite de tiempo del gateway
Versin de SIP no soportada
Mensaje demasiado grande
ERROR GLOBAL
Ocupado completamente
Declinar
No existe en ninguna parte
No aceptable
Tabla 2-2. Cdigo de Respuesta SIP [1] [10].
2.2.4.
Cabecera SIP
La cabecera SIP representa un valor variable que es transportado a travs 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>
<Continuacin de valor de cabecera>
<Nombre cabecera> se los enumera en la tabla 3
<Valor cabecera> una o ms lneas de informacin.
<Continuacin de valor de cabecera> continuacin de la cabecera multilnea.
34

From: sip:102@2.0.0.1
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 lgicos, el
orden en el que se presentan estos grupos representan como deberan 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 fragmentacin 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.
NOMBRE DE CABECERA COMPLETO
Call-ID
Contact
Content-Encoding
Content-Length
Content-Type
From
Subject
To
Via
NOMBRE DE CABECERA ABREVIADO

i
m
e
l
c
f
s
t
v
Tabla 2-4. Abreviaturas de Nombre de Cabecera [1] [10].
35
2.2.5.
Cuerpo de los mensajes SIP (protocolo de descripcin de la sesin SDP)
Como se haba mencionado anteriormente el protocolo SIP es el encargado de establecer, modificar y

finalizar sesiones multimedia pero no de negociar parmetros (Codecs) entre los dos usuarios finales de
esto se encarga el protocolo SDP el cual se encuentra contenido en el protocolo SIP.
Protocolo de descripcin de la sesin (SDP)
SDP es el protocolo de descripcin de la sesin diseado para identificar los atributos de una sesin,
incluyendo informacin administrativa, sobre el programa y sobre los medios [12]. SDP especifica un
estricto orden de los atributos; este orden se basa en minimizar el tamao y complejidad del mensaje del
protocolo.
La tabla 2-5 especifica los atributos del protocolo SDP
TIPO SDP
DESCRIPCION
DESCRIPCION DE SESION
v=
Versin del protocolo
o=
Propietario-creador e identificador de sesin
s=
Nombre de la sesin
i=
*Informacin de la sesin
u=
*URI de descripcin
e=
*Direccin de e-mail
p=
Nmero de telfono
c=
*Informacin de la conexin
b=
*Informacin de ancho de banda
<TIME_DESCR> Una o ms descripciones horarias
z=
*Ajustes de zona horaria
k=
*Clave de encriptacin
a=
*Ninguna o ms lneas de atributos de sesin
<MEDIA_DESCR> *Ninguna o ms descripciones de los medios
DESCRIPCION DEL TIEMPO
t=
Tiempo en que la sesin est activa
r=
*Cero o ms repeticiones
DESCRIPCION DE MEDIOS
m=
Nombre de los medios y direccin del transporte
i=
*Ttulo de los medios
c=
b=
*Informacin del ancho de banda
k=
a=
*Ninguna o ms lneas de atributo
NOTA: *son opcionales
Tabla 2-5. Atributos de SDP [12]
36
2.3. PROBLEMAS GENERALES DE INTEROPERABILIDAD
Los problemas de interoperabilidad de las redes NGNs tanto en la arquitectura Softswitch e IMS
utilizando el protocolo SIP para la sealizacin pueden variar por varios motivos tal como:
Problemas de cdigo de respuesta: cuando un usuario final SIP fue movido y el usuario que
inicia la sesin 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 mxima de
los mensajes de SIP, la realidad es que los proveedores a menudo imponen lmites 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 cdigos de respuesta
especficos 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 semntico de la URI TEL, aunque con una
sintaxis diferente. Los usuarios SIP no tienen una forma real de saber cundo una URI pertenece a
un servidor SIP o a otro - el usuario presiona los botones numricos y pulse en "Enviar", y el
usuario SIP lo que puede hacer es enviar el solicitud a sip: [dgitos] @ [dominio local]. Adems,
muchos sistemas han sido diseados 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 parmetros URI: El problema de la interoperabilidad ms comunes en esta rea es

la colocacin de los parmetros TEL URI, por ejemplo, el "tgrp" y "contexto tronco" parmetros
de [RFC4904], y la "rn", "NPDI", y los parmetros "CIC" a partir de [RFC4694]. RFC 3261
seccin 19.1.6 est muy claro que todas las caractersticas de la telefnica de abonado, incluyendo
los parmetros, se coloca en la parte de userinfo de una SIP URI. Por lo tanto los parmetros de
Tel-URI se convierten en parmetros de usuario de SIP, parmetros SIP URI no.
Un ejemplo, por lo tanto, de una SIP URI que contiene algunos de los mencionados parmetros
11
URI (Uniform Resource Identifer / Identificador Uniforme de Recurso)
37
URI Tel-sera 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 especficos de interconexin 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 suscripcin de
manejo de respuesta. Por ejemplo, la UA enva una peticin 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 extensin, 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
extensin".
Por ejemplo, la etiqueta de opcin 100rel para apoyar PRACK, se inserta en la cabecera de una
peticin INVITE. Esto es fundamentalmente errneo en el uso real. El apoyo a PRACK no es
universal, en todo sentido, y la insercin de esta etiqueta en la cabecera que conduce a las
llamadas fallidas. Ningn usuario o el operador quieren una llamada fallida, a menos que sea
literalmente imposible de tener xito.
Desvi de llamada: Funciones especficas de facturacin, este es propietario del operador por lo
cual no son compatibles tanto de origen como destino.
Consulta de trasferencia de llamadas: Supuestos especficos de cada operador versus modelos

implementados, Por ejemplo, algunas aplicaciones y modelos de implementacin no son
compatibles con el de dilogo se referencia.
38
2.3.2.
Problemas especficos de interconexin del protocolo SIP e SDP
Oferta-INVITE a menos y Re-INVITE: Crea una invitacin, al ser negada reenva la invitacin
y no puede establecer una comunicacin por falta de parmetros en el protocolo SDP, por
ejemplo, que los dispositivos a enrutar las llamadas sobre la base del cdec, o la asignacin de
ancho de banda, o los dispositivos de transcodificacin que se envan no estn de acuerdo con lo
necesario.
Sealizacin: Funciones de pasarela de sealizacin, falta de parmetros entre proveedores un

dispositivo enva de una SDP, literalmente, no quiere que el otro extremo la reciba.
Peticin y respuesta SDP no coinciden: Un problema de interoperabilidad con frecuencia surge

cuando una oferta SDP contiene mltiples "m =" lneas de los medios de comunicacin, pero la
respuesta SDP no contiene el mismo nmero de lneas.
Medios compatibles Incompatibilidades: En la prctica, un nmero significativo de dispositivos

SIP slo soportan ciertos tipos de cdec.
39
3. ESPECIFICACIONES
En esta seccin se describen los componentes que se tuvieron en cuenta en la elaboracin de esta solucin
de interconexin de la red NGN ZTE-PUJ con arquitectura Softswitch/MGC y red NGN ANKLA con
arquitectura Softswitch/MGC.
DESCRIPCIN GENERAL
El trabajo de profundizacin consiste en el diseo e implementacin de una solucin de interconexin 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 investigacin los cuales se irn describiendo en el desarrollo del mismo.
Una caracterstica fundamental de la red NGN es la capacidad de suministrar una gran variedad de
servicios, incluidos voz, vdeo, audio y datos visuales, mediante servicios basados en sesin e interactivos
en los modos unidifusin, multidifusin y difusin; Basndose en la separacin de los servicios y
transporte como se describi en el numeral 2.1.2, la convergencia se centra en las tcnicas de integracin
de los diferentes protocolos de comunicacin para asegurar el inter funcionamiento de la red de transporte
con los servicios y las aplicaciones, para la interpretacin, generacin, distribucin y traduccin de la
sealizacin correspondiente y as poder realizar la integracin de los diferentes componentes de la
misma. La red NGN puede emplearse de manera coherente en cualquier instante o en cualquier lugar a
travs 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 comunicacin que tiene en cuenta las redes NGN
para las comunicaciones con sus diferentes dependencias y con la integracin con otras redes NGN.
Despus de tener en cuenta los diferentes protocolos de comunicacin de las redes NGN nos centraremos
en el protocolo SIP, el cual es el que nos permite realizar la interconexin en dos redes NGN mediante un
troncal SIP (canal de comunicacin con mltiples conexiones de sealizacin con el protocolo SIP), esto
se realiza para poder compartir servicios de voz, video y datos entre las dos redes.
40
Figura 3-1. Protocolos de la red NGN12
En la figura 3-2 se muestra el diagrama bsico de la interconexin entre red Red NGN ZTE-PUJ y
ANKLA.
Red NGN (Centro de Tecnologas de

Telecomunicaciones ZTE-PUJ)
Pontificia Universidad Javeriana
Red NGN (Laboratorio ANKLA)

CINTEL
Figura 3-2. Arquitectura bsica de interconexin las diferentes redes NGNs.
12
Tomado de Introduccin a los Protocolos NGN (ZTE)
41
3.1 Red NGN ZTE-PUJ
La plataforma del Centro de Tecnologas de Telecomunicaciones ZTE-PUJ se basa en una red de prxima
generacin marca ZTE, con arquitectura Softswitch/MGC de fabricacin China. Desde ella, se puede
proveer servicios: voz sobre IP, telefona tradicional/IP e Internet Banda ancha.
La arquitectura general de la red es la siguiente:
Nivel de servicios. Servidores de aplicacin tales como (Asterisk, Elastik, Open Source IMS,
Mobicents, Kamailio)
Nivel de control. Softswitch (control, servicios, gestin de llamadas)
Nivel de transporte. Core (conmutacin de paquetes).
Nivel de acceso. Inalmbrico, banda ancha, PSTN, ISDN, con equipos: UAM (MSAG), abonados
anlogos y ADSL (convierte seales de voz anloga a IP; IAD, concentrador de lneas USUARIO
Analgicas 8-24, conexin IP hacia el SS; SG, sealizacin 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
42
3.2 Red NGN ANKLA
El laboratorio ANKLA sigue una estructura de red NGN para la implementacin 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) versin 4.0 de Ericsson: Est conformado por un
Telephony Server (AXE), TSS Gateway Controller y un Media Gateway (MGW). Soporta
protocolos de sealizacin 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 travs de un Access Gateway (AGW), ANKLA cuenta con una
capacidad instalada de 60 abonados. Provee servicios suplementarios como reloj despertador,
lnea directa, llamada tripartita, identificadores de llamadas, marcacin abreviada y llamada en
espera.
Plataforma de servicios de Trpico: Est conformada por un servidor de aplicaciones (VAS) que
realiza las tareas de control y lgica del servicio en las diferentes aplicaciones instaladas, un
servidor de medios para la reproduccin de anuncios y procesamiento multimedia (VMS) y un
mdulo de reconocimiento de voz (ASR Nuance) encargado de las tareas de reconocimiento
automtico de voz y su correspondiente conversin a texto. Provee servicios de Portal de Voz
para la atencin de servicios de Call Center, mediante un IVR por reconocimiento de voz, y un
sistema de conversin numrica y distribucin de llamadas para la atencin del usuario
mediante operador.
Plataforma de comunicaciones unificadas: Conformada por dos servidores AsteriskNow y

Elastix para realizar la integracin de servicios entre usuarios Legacy (TDM) e IP, proveen
servicios de VoIP tales como videollamadas, IVR, y call center adems de integrar servicios de
mensajera instantnea, fax, videoconferencias, tarificacin y correo electrnico.
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 Sessin Control Function (P-CSCF).
Interrogating Call Sessin Control Function (I-CSCF).

43
Serving Call Sessin Control Function (S-CSCF).
Home Subscriber Server (HSS).
Servidores de aplicaciones SIP (SIP AS).
Figura 3-4. Arquitectura ANKLA14
3.3 Infraestructura de Interconexin redes NGNs.
Para la interconexin de las redes NGNs ZTE-PUJ y ANKLA se tuvieron en cuenta una serie de
herramientas de tipo software y hardware que sern descritas a continuacin.
3.3.1
Nodo Captura
El nodo captura es un sistema robusto, capaz de recolectar y encapsular enormes cantidades de

sealizacin SIP con capacidad de bsqueda instantnea, la cual nos da un anlisis de extremo a extremo
de la sealizacin 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
44
los posibles cambios en las tramas y realizar una correccin de la misma; el funcionamiento del nodo
captura est dividido en tres partes el primero es un proxy SIP (Kamailio) que recolecta toda la
sealizacin SIP que le enva el Capture Agent. La ventaja de este tipo de solucin es que vamos a
tener la posibilidad de ver todo ese tipo de trfico en un sitio web (WebHomer).
Kamailio es un servidor SIP de cdigo abierto que puede adoptar todas las entidades lgicas
conocidas en un entorno VoIP:
Servidor Registrador o Registrar Server
Servidor Proxy o Proxy Server
Servidor Redireccionador o Redirect Server
Servidor de Localizacin o Location Server
Capture Agent, est basado en el mdulo sipcapture (El mdulo 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 extrayndolas en archivos
PCAPs para mostrar el trfico y las estadsticas multiusuario, niveles de acceso.
Figura 3-5. Arquitectura Nodo Captura15
El Nodo Captura necesita de unos requisitos mnimos adicionales de software para su funcionamiento
como son los siguientes:
15
Tomado de http://www.sipcapture.org/
45
El Nodo Captura trabaja exclusivamente sobre ambientes Linux, necesita de un servidor web para la
publicacin de la interfaz grfica (WebHomer), una base de datos Mysql para que el servidor kamailio
guarde toda sealizacin SIP y servidor PHP para poder generar los reportes de sealizacin 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 trfico
El generador de trfico Distributed Internet Traffic Generator (D-ITG). Es una plataforma capaz de
producir trfico a nivel de paquetes con gran exactitud, replicando apropiadamente procesos estocsticos
tanto para IDT (Inter Departure Time), como para variables PS (Packet Size) aleatorias (exponencial,
uniforme, Cauchy, normal y Pareto). Soporta generacin de trfico IPv4 e IPv6 y es capaz de generar
trfico a nivel de red, transporte y aplicacin.
D-ITG, es el software seleccionado para el proyecto que permite implementar algunos protocolos en la
capa de aplicacin como: VoIP, Telnet, DNS, entre otros. En general, permite implementar protocolos
hasta en la capa de transporte, por lo que al modelar algn tipo de trfico para ser generado e inyectado
por el D-ITG en la red, es necesario abstraer el comportamiento estadstico de la capa de aplicacin 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 aplicacin que existen. Pero a nivel de los
sistemas de conmutacin 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 realizacin de una medida de QoS en una red de telecomunicaciones, para
cada servicio por ejemplo, la QoS de una llamada telefnica IP es necesario modelar el trfico de una
llamada telefnica IP real, de forma estadstica, y entregarle estos parmetros al D-ITG, para configurarlo
y modelar el trfico de una llamada telefnica IP. Posteriormente, ese trfico moldeado se inyecta a la red,
que se encarga de implementar todos los protocolos de esa comunicacin, hasta la capa de transporte.
46
3.3.3
Simulador trama SIP
SIP Inspector es una herramienta prctica 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 sealizacin 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 ms sobre el protocolo de sealizacin SIP, gracias a la incorporacin de esquemas para
los casos de UAC y de UAS.
3.3.3.4 Firewall
Un cortafuego (firewall en ingls) es una parte de un sistema o una red que est diseada 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 trfico 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 combinacin 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.
47
DESARROLLOS.
En esta seccin del documento se explica y documentan todos los desarrollos e implementaciones
realizadas para el cumplimiento de los objetivos del proyecto. Las cuales fueron un anlisis del
comportamiento y cabeceras de la sealizacin SIP en cada una de las redes NGN con arquitectura
Softswitch/MGC; se mont un escenario real para poder hacer un anlisis de la interoperabilidad entre la
Red NGN ZTE-PUJ y ANKLA.
4.3
ANLISIS DEL PROTOCOLO SIP.
El anlisis del protocolo SIP se realiz de manera detallada con una conexin bsica, observando y
analizando la trama de sealizacin en cada una de sus partes en la red NGN con arquitectura
Softswitch/MGC, para poder tener un punto de partida del sistema de sealizacin a nivel de troncal SIP y
poder llegar a la interconexin de las dos redes NGNs de diferente fabricante [1].
4.3.3
Anlisis del protocolo SIP ZTE-PUJ
Se realiz un anlisis de toda la trama de sealizacin SIP de la red NGN con arquitectura
Softswitch/MGC, el cual no muestra ningn tipo de modificacin en los parmetros bsicos del protocolo
segn el RFC 3261como se muestra en el anlisis de la siguiente sealizacin SIP.
48
Figura 4-1. Comunicacin bsica del protocolo SIP de la red NGN ZTE-PUJ
Estructura de un mensaje INVITE
INVITE sip:102@172.22.0.34 SIP/2.0

Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a
To: "102"<sip:102@172.22.0.34>
From: "103"<sip: 103@172.22.0.34>;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
49
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 ningn tipo de modificacin o adicional en la
estructura de su trama de sealizacin segn el RFC 3261.
Estructura de un mensaje 183 RING
SIP/2.0 183 Session Progress

To:"102"<sip:102@172.22.0.34>;tag=a290601-31939
From:"103"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 23944 INVITE
Contact: <sip:102@172.22.0.34>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE
User-Agent: ZTE Softswitch/1.0.0
Content-Length: 115
50
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 ningn tipo de modificacin o adicional en
la estructura de su trama de sealizacin segn el RFC 3261.
Estructura de un mensaje 200 OK
SIP/2.0 200 OK
To:"102"<sip:102@172.22.0.34>;tag=a290601-31939
From:"103"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 23944 INVITE
Contact: <sip:102@172.22.0.34>
Record-Route: <sip:172.22.0.34;lr>
Content-Length: 115
v=0
o= ZTE 32 32 IN IP4 172.22.0.34
51
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
a=ptime:20
NOTA: en la estructura el mensaje 200 OK no se encuentra ningn tipo de modificacin o adicional en la
Estructura de un mensaje ACK
ACK sip:172.22.0.34;lr SIP/2.0

To: "102"<sip:102@172.22.0.34>
From: "103"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 23944 ACK
Contact: <sip:#103@172.22.0.54:5060>
Max-Forwards: 70
Route: <sip:102@172.22.0.34>
NOTA: en la estructura el mensaje ACK no se encuentra ningn tipo de modificacin o adicional en la
Estructura de un mensaje BYE
BYE sip:102@172.22.0.54: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:103@172.22.0.34>;tag=884a420a-7062206315162668
52
From: "102"<sip:102@172.22.0.34>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 18927 BYE
Max-Forwards: 69
Content-Length: 0
NOTA: en la estructura el mensaje BYE no se encuentra ningn tipo de modificacin o adicional en la
Estructura de 200 OK
SIP/2.0 200 OK
To: "#0*109316"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:102@172.22.0.34>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 18927 BYE
Max-Forwards: 69
Despus de haber analizado la trama de sealizacin SIP con el RFC 3261 de una comunicacin bsica de
la red NGN ZTE-PUJ con arquitectura Softswitch/MGC SIP no se encontr ningn tipo de modificacin
o adicin a la misma, el cual nos da un principio de interconexin sin presentar ningn problema.
53
4.3.4
Anlisis del protocolo SIP ANKLA
segn el RFC 3261 como se muestra en el anlisis de la siguiente sealizacin SIP.
Figura 4-2. Comunicacin bsica del protocolo SIP de la red NGN ANKLA
INVITE sip:0755526778086@10.41.6.1 SIP/2.0

To: "0755526778086"<sip:0755526778086@10.41.6.1>
From: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 INVITE
Contact: <sip:#0*109316@10.66.74.136:5060>
Max-Forwards: 70
User-Agent: ERICSSON MULTIMEDIA SIPPHONE/V1.0 04-01-10
54
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
a=ptime:20
a=rtpmap:18 G729/8000
a=rtpmap:34 H263/90000
NOTA: en la estructura el mensaje INVITE no se encuentra ningn tipo de modificacin o adicional en la

To:"0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
From:"#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 INVITE
Contact: <sip:0755526778086@10.41.6.1>
55
User-Agent: ERICSSON Softswitch/1.0.0
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
a=ptime:20
NOTA: en la estructura el mensaje 183 RING no se encuentra ningn tipo de modificacin o adicional en
SIP/2.0 200 OK
To:"0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
From:"#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 INVITE
Contact: <sip:0755526778086@10.41.6.1>
56
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
a=ptime:20
ACK sip:10.41.6.1;lr SIP/2.0

To: "0755526778086"<sip:0755526778086@10.41.6.1>
From: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 ACK
Contact: <sip:#0*109316@10.66.74.136:5060>
Max-Forwards: 70
Route: <sip:0755526778086@10.41.6.1>

57
BYE sip:#0*109316@10.66.74.136:5060 SIP/2.0

To: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 18927 BYE
Max-Forwards: 69
Content-Length: 0
SIP/2.0 200 OK
To: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 18927 BYE
Max-Forwards: 69
58
Despus de haber analizado la trama de sealizacin SIP con el RFC 3261 de una sealizacin bsica de
la red NGN ANKLA con arquitectura Softswitch/MGC no se encontr ningn tipo de modificacin o
adicin a la misma, el cual nos da un principio de interconexin sin presentar ningn problema.
4.3.5
Comparacin de las dos redes NGNs
Al realizar un estudio comparativo de la sealizacin SIP de las dos redes NGNs 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 tcnicas a tomarse en cuenta para la
interoperabilidad e interconexin de las dos redes NGN a travs de troncales SIP [7].
El uso del protocolo SIP permite la interconexin de equipos de mltiples fabricantes debido a su
estandarizacin y a la simplicidad del intercambio de mensajes [1].
4.4.3
Escenario de interoperabilidad ZTE-ANKLA
Uno de los mecanismos ms recientes para los servicios convergentes es la capacidad de acceso basado en
SIP, o de manera ms general, la conexin a redes NGNs mediante troncales SIP [7]. Estas capacidades
posibilitan el uso de implementaciones basadas en estndares abiertos de conectividad SIP, ya sea para
hacer ms 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 geogrfico de los carriers para atender nuevos
mercados a travs de una conectividad IP. La interconexin a travs de troncales SIP tiene algunas
ventajas para las redes NGN:
Reduce los costos y la complejidad de las implementaciones gracias a la consolidacin de la voz y

los datos sobre una sola red.
59
Permite hacer uso de otros servicios IP dependientes del tipo de transporte como: transferencia de
mensajes de audio, video conferencias, presencia, mensajera instantnea, etc.
Capacidad de expansin de los servicios de comunicaciones para satisfacer demandas no

contempladas.
Implementacin 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 aos, ha ido creciendo la aceptacin de la industria con respecto a SIP
como el protocolo primario de comunicacin IP entre sistemas, independientemente de la aplicacin.
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 conexin a Internet, incluso con otra red NGN. Desde esta red de
datos (red IP) se accede a travs de una troncal SIP a la red NGN con arquitectura Softswitch/MGC.
Con SIP versin 2, se han adicionado nuevas caractersticas que permiten al equipo comunicarse con redes
VoIP de mltiples fabricantes. Sin embargo, todava no existe una garanta de que todos los fabricantes,
interpreten e implementen los estndares de la misma forma [1].
Las troncales SIP proveen mayor flexibilidad en cuanto a la configuracin 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 direccin IP como direccin para enrutar un servicio.
Algunas configuraciones de red pueden requerir el uso de uno o ms servidores proxy de salida (por
ejemplo en presencia de un controlador de borde o si el proveedor de servicios usa mltiples nodos para
enrutar llamadas). Ver figura 4-3.
Dado el caso prctico de interoperabilidad de las redes NGNs de estudia se implement los Softswitchs
como servidores proxy.
60
Figura 4-3. Estructura de un servidor Proxy SIP16
En el RFC 2833 se define un mtodo estndar para transmitir dgitos de sealizacin entre dos usuarios
finales transmisin RTP. Esto permite una transmisin confiable de los paquetes entre usuarios finales
independientemente de la calidad del CODEC utilizado para la transmisin de la voz.
Con el fin de activar determinados escenarios de llamadas como transferencia de llamadas sobre troncales
SIP, el mtodo REFER el cual esta descrito en el RFC 3515. Luego que una llamada ha sido establecida
entre dos usuarios, se utiliza el mtodo SIP REFER para transferir la llamada. El mensaje REFER provee
la informacin de contacto a la otra parte (donde la llamada ser transferida).
El funcionamientos de la troncal SIP de realiza con las sesiones de la sealizacin SIP que normalmente
se establecen a travs de un servidor Proxy SIP. El servidor Proxy SIP se ubica en medio del camino de la
sealizacin y provee un servicio de bsqueda para los mensajes entrantes y salientes. Este servicio puede
ser una bsqueda DNS o una bsqueda en una base de datos de informacin de presencia, en la cual los
usuarios han registrado su localizacin y su estado de presencia. En cualquier caso el trabajo del servidor
proxy es encontrar a la persona que est siendo invitada a una sesin de media.
El siguiente ejemplo nos da una visin del funcionamiento del PROXY SIP.
El USUARIO A desea realizar una llamada desde su telfono IP hacia el telfono de USUARIO B, por lo
que levanta el auricular del telfono y marca. Este no conoce exactamente la localizacin de USUARIO B,
de manera que su telfono (usuario SIP) re direcciona el mensaje INVITE hacia el servidor proxy SIP.
16
Tomado de Softswitch Architecture for VoIP
61
El servidor proxy realiza una bsqueda del URI de USUARIO B y obtiene su direccin IP, entonces enva
el mensaje INVITE hacia el telfono de USUARIO B, aadindole al mismo un encabezado llamado
Via: el cual contiene la direccin 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 ms de un encabezado
Via:, se sabe que el paquete ha atravesado un servidor proxy. El telfono de USUARIO B responde con
un 180 Ringing enrutado hacia el USUARIO A a travs 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 enva un ACK directamente
hacia USUARIO B (sin pasar por el proxy). En este punto la sesin se encuentra establecida y se desarrolla
directamente entre los dos (usuarios SIP), hasta que se termine la sesin con los mensajes BYE y 200 OK.
El ejemplo solo contiene un servidor proxy para la sesin SIP, sin embargo tpicamente se tiene varios
servidores proxy en el camino de sealizacin, usualmente, al menos uno por sistema autnomo.
En la figura 4-3 se muestra la representacin de mensajes SIP dos servidores proxy SIP.
Los servidores proxy se encuentran usualmente estructurados en una topologa que el RFC 3261 define
como trapezoide SIP. Este trapezoide describe la forma en que la media y la sealizacin fluyen cuando:
17
Tomado de Softswitch Architecture for VoIP.
62
Dos usuarios SIP de una sesin 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 travs
de su servidor proxy.
En la figura 4-5 se realiza un diagrama de interconexin utilizando los diferentes Softswitch como
servidores proxy SIP para el intercambio de mensajes de sealizacin SIP con otras redes NGN; en este
caso se realiza entre el ZTE-PUJ) ANKLA


CINTEL
Figura 4-5. Arquitectura PROXY de interconexin las diferentes redes NGNs de estudio
En el intercambio de mensajes SIP desde los diferentes PROXY de cada red tambin 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 tpica, el usuario SIP enva el mensaje INVITE junto con una peticin de
establecimiento de sesin usando SDP. En este caso, el telfono de destino responde con un 180 Ringing
que permite escuchar un tono de confirmacin de timbrado en el telfono de origen. Cuando el auricular
del telfono se levanta en el otro extremo, ste enva un mensaje 200 OK con la confirmacin de uso de
SDP [7].
63
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 continuacin 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 conexin 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
64
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 enva un mensaje re-INVITE con una oferta SDP y con un
atributo sendonly (sesin unidireccional). El otro extremo de la troncal SIP puede seguir recibiendo
media. La direccin IP especificada en SDP seguir siendo vlida.
4.4.4
VPN y sus caractersticas de interoperabilidad.
La interconexin 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 informacin entre diferentes redes que estn situados en
diferentes reas geogrficas. Es una red de datos de gran seguridad que utilizando Internet como medio de
transmisin permite la transmisin de informacin confidencial entre las dos NGNs. Aunque Internet es
una red pblica y abierta, la transmisin de los datos se realiza a travs de la creacin de tneles virtuales,
asegurando la confidencialidad e integridad de los datos transmitidos. El diagrama bsico de interconexin
de las dos redes NGNs de estudio se muestra en la figura 4-8.
TRONCAL SIP
TRONCAL SIP
VPN SITE TO SITE

SOFTSWITCH
NGN ZTE
SOFTSWITCH
NGN ERICSSON
Figura 4-8. Diagrama bsico de la VPN las diferentes redes NGNs
Una Red Privada Virtual (VPN) conecta los componentes de una red sobre otra, por medio de la conexin
de los usuarios de distintas redes a travs de un "tnel" que se construye sobre Internet o sobre cualquier
otra red pblica, negociando un esquema de cifrado y autentificacin 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 estn implementadas con firewalls,
con routers para lograr esa encriptacin y autentificacin.
65
4.4.4.4 VPN Sitio a Sitio utilizando NAT
(Network Address Translation) Traduccin de Direcciones de Nombres es el proceso de cambiar una

direccin IP de una NGN (una direccin privada de la organizacin) por una direccin IP pblica
enrutable, es decir poseen la capacidad para esconder las direcciones privadas de una NGN.
Los pasos siguientes describen el proceso de comunicacin 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 direccin IP enrutable.
El firewall implementado con NAT reenva 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 direccin IP por el nmero original, este es enviado hacia el enrutador interno
para ser dirigido hacia su destino.
En la figura 4-9 se muestra el diagrama de interconexin utilizado para las redes NGNs 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.
NAT
172.22.0.48/28
192.168.0.0/24
TRONCAL SIP
SOFTSWITCH
NGN ZTE
172.22.0.48/28
ASA 5510
IP PUBLICA
200.3.153.91
TRONCAL SIP
VPN SITE TO SITE ASA 5505

IP PUBLICA
IPsec
190.25.130.245
SOFTSWITCH
NGN ERICSSON
192.168.0.0/24
Figura 4-9. Diagrama bsico de NAT las diferentes redes NGNs
4.4.4.5 Seguridad VPN IPSec
En la implementacin de la VPN para la interconexin de las diferentes redes NGNs ZTE-PUJ y

ANKLA, un factor muy importante es la seguridad con la que nuestros datos son trasportados a travs de
66
internet, por tal razn IPSec - Internet Protocol security el cual nos da una seguridad mejorada con
caractersticas tales como algoritmos de encriptacin ms fuertes y autenticacin ms comprensiva. IPSec
tiene dos modos de cifrado, tnel y transporte. El modo de tnel cifra el encabezado y la carga de cada
paquete, mientras que el mtodo de transporte slo encripta la carga o contenido de los paquetes. Slo
sistemas que son compatibles con IPSec pueden usar este protocolo. Tambin, todos los dispositivos
deben usar una clave comn o certificado y deben tener implementadas polticas de seguridad similares.
Para usuarios de acceso remoto de VPN hay paquetes de software que proveen cifrado y conexin en un
PC. IPSec soporta cifrado de 56 bits (single DES) o 168 bits (triple-DES).
4.4.4.6 Descripcin de los Parmetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y ANKLA
Despus de haber explicado los diferentes componentes a tener en cuenta en la interconexin de las
diferentes redes NGNs ZTE-PUJ y ANKLA, se decide crear un VPN sitio a sitio para el intercambio de
toda la sealizacin SIP y la media. Con esto las estas redes puedan compartir servicio y aplicaciones. Ver
figura 4-10.
VPN SITE TO SITE

NODO CAPTURA
* Ipsec authentication uses pre-shared

key: zte
*Tunnel Group Name: interconexion
*IKE group Encryption: DES / SHA
TRONCAL SIP
TRONCAL SIP
SOFTSWITCH
NGN ZTE
ASA 5510
IP PUBLICA
200.3.153.91
ASA 5510
IP PUBLICA
190.25.130.245
NAT
172.22.0.48/28
SOFTSWITCH
NGN ERICSSON
192.168.1.0/24
Figura 4-10. Configuracin VPN de la Red NGN ZTE-PUJ ANKLA
4.5
METODOLOGA DE ANLISIS DE INTEROPERABILIDAD
Despus de establecer la interconexin de las dos redes NGNs ZTE-PUJ y ANKLA mediante una VPN
sito a sitio para l envi de sealizacin SIP y media mediante una troncal SIP y utilizando los softswitch
como servidores PROXY para la conexin desde el interior de cada red con la otra NGN, se decide
implementar un elemento ms, el NODO CAPTURA para que estudie, analice y modifique de ser
67
necesario la sealizacin SIP que est pasando entre las dos redes NGNs y no presente inconvenientes de
interoperabilidad de las mismas.
4.5.3
Identificacin y reconocimiento
Para revisar los diferentes aspectos de interconexin e interoperabilidad de las diferentes redes NGNs
ZTE-PUJ y ANKLA se realizaron una serie de pruebas de telefona IP las cuales involucraron una serie de
componentes como fueron telfonos SIP, softphones SIP, telfonos analgicos tradicionales conectados a
la red SIP, un Proxy SIP (Softswitch) y el nodo captura para el anlisis de resultados.
Para realizar las pruebas, se accedi desde un cliente SIP de la primera red NGN a travs del Softswitch
(Servidor Proxy SIP) y enviando la sealizacin a travs 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
desempeo segn el resultado esperado de la prueba.
Este esquema de pruebas permite comprobar la interoperabilidad del NODO CAPTURA a travs de una
troncal SIP con algunos dispositivos necesarios para la conectividad y acceso a la red pblica mediante
SIP, incluyendo: servidor proxy SIP, gateways FXO, gateways FXS, telfonos analgicos, softphones SIP,
telfonos IP. Adems con esta implementacin se pueden probar los siguientes escenarios de
interoperabilidad:
Llamada simple entre dispositivos IP a travs de troncal SIP.
Llamada interna entre telfonos SIP.
Transferencia de llamadas usando el mtodo REFER (RFC 3515).
Escenarios de espera: espera unidireccional, espera mutua y desactivacin de espera.
Estados de presencia en dispositivos SIP.
Identificacin de llamadas CLIP (Calling Line Identification Presentation).
En primer lugar se estableci una conexin mediante de una VPN y l envi de sealizacin SIP y media a
travs 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 especfica la troncal, el mapeo
de direcciones IP, puertos a utilizarse, establecer el plan de numeracin y los nombres de dominio
utilizados en la red SIP, esto para evitar conflictos de nmeros y direcciones URI, finalmente establecer el
acceso externo mediante troncal SIP.
68
En el caso del servidor, se procedi a realizar los pasos necesarios para configurar los telfonos SIP y los
softphones.
Para constatar y/o depurar los procedimientos en las pruebas asociadas a la conmutacin 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 tambin es posible verificar los mensajes
asociados a los estados de presencia; y en el medio de las redes NGNs se configuro el Nodo Captura para
capturar toda la sealizacin SIP que se est enviando a travs 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 Travs 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 travs de la
troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el nmero de destino, en
el usuario SIP origen, debe recibir un mensaje INVITE desde la direccin del proxy, confirmando con el
timbrado del telfono; cuando la llamada es contestada el destino enva un mensaje 200 OK y se
establece la sesin a travs de paquetes RTP.


CINTEL
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexin de usuarios las diferentes redes NGNs
69
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
softphone IP de la red NGN ZTE-PUJ hacia un cliente SIP del servidor de aplicaciones de la red NGN
ANKLA a travs de la troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el
nmero de destino, en el usuario SIP origen, se debe recibir un mensaje INVITE desde la direccin del
proxy, confirmando con el timbrado del telfono; cuando la llamada es contestada el destino enva un
mensaje 200 OK y se establece la sesin a travs de paquetes RTP.


CINTEL
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexin de diferentes componentes de redes NGNs
70
4.6

TRAMA SIP
Despus de realizar las pruebas con un solo usuario se implementaron otra serie de pruebas con un
generador de trfico SIP, para poner a prueba la capacidad de interoperabilidad con flujos de sealizacin
SIP ms grandes y observar el comportamiento del Nodo Captura.
4.6.3
Integracin Nodo Captura y Generador de Trfico
En la figura 4-13 se muestra la forma de inyectar el trfico emulado con el generador de trfico D-ITG en
la red NGNs, el cual pasa por el Nodo Captura para realizar un anlisis de grandes cantidades de
sealizacin SIP; y verificar segn el RFC 3261 la estructura de trama SIP, y poder medir la calidad de
servicio (QoS).
La configuracin utilizada para esta prueba fue instalar el equipo transmisor en la red ZTE-PUJ desde el
cual el D-ITG inyecta trfico en la red y un equipo receptor en la red ANKLA que lo toma y lo procesa
generando un archivo de registro, con los parmetros medidos en la transmisin realizada. Esta captura
contiene datos que determinan el comportamiento estadstico de la aplicacin, tales como: la tasa de
paquetes enviados (paquetes/segundo), el tamao de los paquetes (bytes/paquete), el byte DSCP (servicios
diferenciados), el TTL, los protocolos usados en la transmisin, los puertos, el ancho de banda, entre
otros. Estos parmetros son tomados como datos de entrada al software D-ITG, donde se usan para
modelar el comportamiento estadstico a nivel de transmisin de las aplicaciones ofrecidas por la NGN y
emular el comportamiento real de la aplicacin 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 tambin desde la red NGN ANKLA como transmisor hacia
la red NGN ZTE-PUJ como receptor.
71
Figura 4-13. Generador de trfico SIP a travs de la troncal SIP de dos redes NGN.
4.6.4
Emulacin 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 parmetros 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 trfico SIP.
72
ANALISIS DE RESULTADOS
Los resultados obtenidos se basan en el funcionamiento del Nodo Captura en los diversos escenarios, esto
se logr despus de hacer las diferentes pruebas de interoperabilidad especialmente evaluando la
sealizacin SIP y parmetros 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 NGNs
evaluando la sealizacin SIP.
5.3.3
Descripcin 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 versin 4, el cual es el encargado de almacenar en una base de datos, (Mysql)
toda la sealizacin SIP que le llega al nodo captura, el segundo de ellos es un agente captura que hace la
funcin de puerto de escucha y es el encargado de copiar, modificar y llevar toda la sealizacin 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 integracin de dos NGNs de diferentes fabricantes.
Ver anexo 2.
18
Calidad de Servicio
73
5.3.4
Caractersticas del hardware Nodo Captura
Para la implementacin e instalacin 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 versin 12.04 con todas sus actualizaciones sobre una
mquina que tena la siguientes caractersticas 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
Anlisis 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 diseo adecuado para la sealizacin 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 sealizacin SIP de la red redes NGN ZTE-PUJ y ANKLA; para esto se puso en
marcha el Nodo Captura y se le inyecto trfico por medio de generador de trfico, este nos permite medir
un trfico real (genera trfico que emula la sealizacin SIP y trfico 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 trfico 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 trfico enva el trfico en primer lugar al proxy de la red NGN ZTE-PUJ, despus al Nodo
Captura el cual realiza la funcin de escucha para poder evaluar la sealizacin SIP, despus al proxy
destino la red NGN ANKLA y por ultimo al receptor del generador de trfico de la red de destino en la
figura 5-2 podemos observar la sealizacin 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.
74
Figura 5-1. Generacin de trfico SIP las diferentes redes NGNs
Figura 5-2. Traza de una de las pruebas de interconexin de bsqueda de llamada se sesin de las diferentes NGNs
Despus de realizar un anlisis detallado de la sealizacin SIP que est pasando por el Nodo Captura no
encontramos ningn parmetro adicional o faltante en sus cabeceras de mensajes SIP, la cual se puede ver
en la figura 5-3.
75
Figura 5-3. Diagrama de secuencia de la sealizacin SIP de una llamada de Softswitch Vs Softswitch
Se realiza una exportacin a un analizador de protocolos (wireshark) para observar el comportamiento de

la sealizacin SIP entre las dos redes NGNs esto se hace para tener una segunda visualizacin de los
mensajes SIP el cual no nos arroja ningn comportamiento que no est contemplado en RFC 3162.
Figura 5-4. Captura de traza de la sealizacin SIP de una llamada de Softswitch Vs Softswitch
5.3.6
Emulacin Trama SIP para el Comportamiento del Nodo Captura.
Al no encontrase ningn tipo de alteracin en la trama SIP para la interoperabilidad de redes NGNs
acudimos a un emulador de trama SIP (Sip Inspector) para probar el funcionamientos del Nodo Captura en
la deteccin y modificacin de parmetros adicionales o faltantes en su sealizacin SIP (RFC 3261).
76
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 mxima de los mensajes de SIP, la realidad es que
los proveedores a menudo imponen lmites 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 cdigos de respuesta especficos 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 autentificacin a un proxy. Ver anexo 7.1.
5.3.6.5 Parmetros TEL-URI
El problema de la interoperabilidad ms comn es en esta rea, es la colocacin de los parmetros TEL

URI, por ejemplo, el "tgrp" y "contexto tronco" parmetros del [RFC4904], y la "rn", "NPDI", y los
parmetros "CIC" a partir del [RFC4694]. El RFC 3261 seccin 19.1.6 est muy claro que todas las
caractersticas de la telefona de abonado, incluyendo los parmetros, se coloca en la parte de user-info de
una SIP URI. Por lo tanto los parmetros de Tel-URI se convierten en parmetros de usuario de SIP,
parmetros SIP URI no.
Se realiz la comprobacin de la simulacin de un TEL-URI a travs del Nodo Captura dando como
resulta un envo de mensajes SIP, transparente para las entidades emisor y receptor. Ver anexo 7.2.
5.3.6.6 Invite Reinvite (Subscribe)

Crea una invitacin al ser negada reenva la invitacin y no puede establecer una comunicacin por falta
de parmetros en el protocolo SDP, por ejemplo, que los dispositivos a enrutar las llamadas sobre la base
del cdec, o la asignacin de ancho de banda, o los dispositivos de transcodificacin que se envan no
estn de acuerdo con lo necesario.
77
Se simulo un escenario evitando este tipo de problemas de interoperabilidad, dando como resultado un
envo de sealizacin SIP xito. Ver Anexo 7.3
5.3.6.7 Valor De Cabecera PRACK

SIP ofrece un medio para indicar el uso de extensin, 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 extensin".
Por ejemplo, la etiqueta de opcin 100rel para apoyar PRACK, se inserta en la cabecera requieren de una
peticin INVITE. Esto es fundamentalmente errneo en el uso real. El apoyo a PRACK no es universal,
en todo sentido, y la insercin de esta etiqueta en la cabecera Requerir conduce a las llamadas fallidas.
Se emulo el escenario anterior dando como resultado un envo de sealizacin 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 telefona IP y centros de llamada; como lo describimos en la seccin 2.3, los problemas de
interoperabilidad que se presenta a nivel de protocolo SIP y SDP se manifiesta en la integracin de una
plataforma de un fabricante de telefona IP caso especfico AVAYA con otro fabricante de telefona IP
genrico; se prob la solucin de software denominado NODO CAPTURA en la interoperabilidad de las
plataformas mencionadas anteriormente.
La plataforma AVAYA en la implementacin del protocolo de sealizacin SIP presenta una
implementacin adicional en el mensaje de peticin PRACK, este mensaje no permite la interoperabilidad
de este fabricante con otros dispositivos de hardware de otro fabricante, en la implementacin del NODO
CAPTURA para probar su funcionamiento el modifica la sealizacin 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 extensin, los fabricantes caso especfico 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 extensin".
78
5.5
MEDICIONES DE QOS
Se realiza una serie de protocolos de prueba para poder medir la QoS, en este caso especfico se evalu
Telefona IP. Para las pruebas se us como base la configuracin 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 comunicacin fue en ambos sentidos (ida y vuelta) y no se us ninguna tcnica de
supresin de silencios.
Telefona IP se clasifica como Clase de QoS 0. Tiene como lmite superior para los parmetros 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 transmisin [18].
Primer escenario: Se realiz una sola llamada IP, de Softswitch Vs Softswitch que tena como
propsito obtener una medida de referencia, lo que era factible porque las NGNs carecan de
cualquier otro tipo de trfico. 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 simultneas 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 simultneas veinte llamadas.
La tabla 5-1. Muestra los resultados obtenidos en las cuatro pruebas realizadas.
TELEFONIA IP (SIP)
1 Llamada Softswitch Vs Softswitch
Parametro Limite Superior
Medicin
Diferencia
IPTD (ms)
100
0,1185
-99,8815
IPDV (ms)
50
0,107
-49,893
IPLR (%)
1,00%
0,00%
-1,00%
IPER
0,001
0
-0,001
CLASE QoS
0
0
0
1 llamada Asterisk Vs Softswitch

Medicin
Diferencia
10,8085
-89,1915
1,224
-48,776
0,00%
-1,00%
0
-0,001
0
0
10 llamadas Softswitch Vs Softswitch

Medicin
Diferencia
11,514
-88,486
1,897
-48,103
0,00%
-1,00%
0
-0,001
0
0
20 llamadas Asterisk Vs Softswitch

Medicin
Diferencia
15,614
-84,386
1,809
-48,191
0,00%
-1,00%
0
-0,001
0
0
Tabla 5-1. Mediciones de QoS para llamadas telefnicas IP (Protocolo SIP)
79
A continuacin se hace una descripcin 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 lmite 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
NGNs solo estn disponibles nicamente para el trfico 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 medicin anterior, alrededor de 100 y 10 veces,
respectivamente, siguen estando muy por debajo de los lmites establecidos. Los otros dos parmetros
evaluados, IPLR e IPER, no cambian de un escenario a otro. Los resultados, son altamente favorables,
algo que obedece a una razn fundamental: El nico trfico 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 transmisin de la red NGN.
El tercer escenario las llamadas simultneas ocupan un ancho de banda de aproximadamente 300 kb/s. Si
se compara el IPTD y el IPDV obtenidos en esta medicin, con los presentados en el escenario anterior, de
una llamada IP nica, se encuentra que no hay mucha diferencia. La conclusin que surge de esta
observacin es que, en este tipo de redes, la variacin en el valor de los parmetros de IPTD e IPDV no
depende de la cantidad de llamadas simultneas, sino de disponibilidad.
En el cuarto escenario se puede comparar con el tercer escenario debido a que los valores estn por debajo
del lmite, con la premisa de que las redes NGNs se encuentran disponibles exclusivamente para estas
pruebas.
80
CONCLUSIONES
El tema de compartir servicios y aplicaciones en las redes NGN nos pone a pensar en una interconexin de
redes NGN con arquitectura Softswitch y en el caso especfico ZTE-PUJ y ANKLA, este proceso conlleva
una serie de metodologas de interconexin y parmetros a tener en cuenta como son: la seguridad, la
sealizacin, la capacidad de trfico entre otras; como estamos en una redes NGN netamente acadmicas
nos permite experimentar diferentes soluciones y realizar una serie de pruebas a nuestra disposicin.
La interconexin se culmin con xito dando as al cumplimiento del objetivo general y a los objetivos
especficos; Dndonos cuenta que no se encontraron problemas de interoperabilidad generados por la
sealizacin (protocolo SIP), pero esta situacin se implement de un Nodo Captura que fuera capaz de
analizar y modificar la sealizacin SIP.
La interconexin 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 implementacin con xito del Protocolo SIP/SDP mediante
una troncal SIP, para la transferencia de toda la sealizacin entre la dos redes NGN con arquitectura
Softswitch, para compartir todos los servicios con los que cada una de ellas cuenta.
Los diferentes anlisis que se realizaron a la sealizacin 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 composicin del protocolo SIP y llegado el caso realizar alguna
modificacin de la trama SIP, despus de toda la investigacin de la sealizacin SIP se lleg a la
conclusin que el protocolo SIP/SDP no presenta ninguna modificacin en sus estructuras de tramas en
ninguno de sus mensajes de peticin 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 anlisis y solucin de posibles errores encontrados en el protocolo SIP mediante la
simulacin.
Se prob la solucin del NODO CAPTURA en un escenario totalmente distinto, la interoperabilidad del
fabricante AVAYA con el fabricante genrico, 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 modificacin de la sealizacin del mensaje de
81
peticin PRACK, permito la interoperabilidad de este fabricante con otros dispositivos de VoIP de otro
fabricante genrico.
Por ltimo se realiz algunos anlisis de QoS en el funcionamiento de la troncal SIP, generando trfico
SIP de mltiples conexiones a travs del escenario de interoperabilidad montado, dando unos resultados
muy favorables como se muestra en la tabla 5-1.
Despus de todo el anlisis que se le realizo a la sealizacin 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 lnea de trabajo futura seria realizar pruebas de sealizacin de
peticiones en paralelo en uno o varias redes conjuntamente, para as demostrar la interoperabilidad de toda
una solucin de redes que manejas el protocolo SIP.
Tambin habra que desplegar esta aplicacin en un entorno NGN basado en arquitecturas IMS.
82
BIBLIOGRAFIA
LIBROS Y PUBLICACIONES
[1] Alan B. Johnston, Artech House telecommunications library, SIP Understanding the session initiation
protocol Second edition, 2004
[2] KEAGY, Scott, Integracin de redes de voz y datos, tercera edicin, 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. Medicin de calidad del servicio en redes de prxima generacin (NGN) en
Colombia, Entregables 1 a 4, Centro de Investigacin de las Telecomunicaciones CINTEL, 2012.
[6] DAZ, 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.
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
83
[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 3rdGeneration Partnership Project (3GPP), http://www.ietf.org/rfc/rfc3455.txt
[15] UIT-T (Unin Internacional de Telecomunicaciones, Estandarizacin); Iniciativa de normalizacin
mundial de las redes de la prxima generacin.
[16] UIT-T (Unin Internacional de Telecomunicaciones, Estandarizacin Y.1540, Servicio de
comunicacin de datos con protocolo Internet - Parmetros 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 (Unin Internacional de Telecomunicaciones / Sector de normalizacin de las
telecomunicaciones). Recomendacin 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 trfico (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 sealizacin SIP (Consultado Enero
2013).
[25] https://sites.google.com/site/sipinspectorsite/ Emulador de tramas SIP (Consultado enero 2013).
84
ANEXOS
Anexos adjuntos en un CD.
85
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
IPTD
IP Transfer Delay
ITU
International Telecommunication Union
NGN
Next Generation Network
QoS
Quality of Service
86
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
87


BOGOT D.C.
MAYO DE 2013

Trabajo de profundizacin para optar por el ttulo de

Magister en Ingeniera Electrnica
Director:
LUIS CARLOS TRUJILLO ARBOLEDA
Ingeniero Electrnico, M.Sc.

BOGOT D.C.
MAYO DE 2013
2

MAESTRA EN INGENIERIA ELECTRNICA
RECTOR MAGNFICO:
P. JOAQUN SNCHEZ GARCA S. J.
DECANO ACADMICO:
Ing. JORGE SANCHEZ, Ph.D.
DECANO DEL MEDIO UNIVERSITARIO:
P. SERGIO BERNAL RESTREPO S. J.
DIRECTOR DE LA MAESTRA:
DIRECTOR DEL TRABAJO DE GRADO:
Ing. CESAR LEONARDO NIO. PH.D.

Ing. LUIS CARLOS TRUJILLO ARBOLEDA, MSc.
NOTA DE ACEPTACIN
Nota de aceptacin
______________________
______________________
______________________
_____________________
Presidente del Jurado
_____________________
Jurado
_____________________
Jurado
Bogot, Mayo de 2013
ARTCULO 23 DE LA RESOLUCIN No. 13 DE JUNIO DE 1946
La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de
grado. Slo velar porque no se publique nada contrario al dogma y la moral catlica y porque los
trabajos no contengan ataques o polmicas puramente personales. Antes bien, que se vea en ellos el
anhelo de buscar la verdad y la justicia.
Artculo 23 de la Resolucin No. 13, del 6 de julio de 1946,

por la cual se reglamenta lo concerniente a Tesis y Exmenes
de Grado en la Pontificia Universidad Javeriana.
DEDICATORIA
Agradezco a mi mam, a mis hermanos

Y en general a toda mi familia que me
Apoyo en todo m proceso de
Formacin acadmica.
William Fernando Snchez Pacheco
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.
Caractersticas 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 Peticin....................................................................................................... 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 descripcin de la sesin SDP) ........................ 36
2.3.
3.
PROBLEMAS GENERALES DE INTEROPERABILIDAD .................................................. 37
2.3.1.
Problemas especficos de interconexin del protocolo SIP ............................................... 38
2.3.2.
Problemas especficos de interconexin del protocolo SIP e SDP .................................... 39
ESPECIFICACIONES ................................................................................................................... 40
3.1
Red NGN ZTE-PUJ ............................................................................................................ 42
3.2
Red NGN ANKLA ............................................................................................................. 43
3.3
Infraestructura de Interconexin redes NGNs. .................................................................... 44
3.3.1
Nodo Captura .............................................................................................................. 44
3.3.2
Generador de trfico.................................................................................................... 46
3.3.3
Simulador trama SIP ................................................................................................... 47
3.3.3.4
Firewall ...................................................................................................................... 47
DESARROLLOS. .......................................................................................................................... 48
7
4.3
ANLISIS DEL PROTOCOLO SIP. ...................................................................................... 48
4.3.3
Anlisis del protocolo SIP ZTE-PUJ ............................................................................... 48
4.3.4
Anlisis del protocolo SIP ANKLA................................................................................. 54
4.3.5
Comparacin de las dos redes NGNs ............................................................................. 59
4.4
PRUEBAS DE INTEROPERABILIDAD ............................................................................... 59
4.4.3
Escenario de interoperabilidad ZTE-ANKLA .................................................................. 59
4.4.4
VPN y sus caractersticas 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 Descripcin de los Parmetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y
ANKLA67
4.5
METODOLOGA DE ANLISIS DE INTEROPERABILIDAD............................................ 67
4.5.3
Identificacin y reconocimiento ...................................................................................... 68
4.5.3.4
Llamada Simple Entre Dispositivos IP A Travs De Troncal SIP ................................. 69
4.5.3.5
Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones ...................... 70
4.6
TRAMA SIP ...................................................................................................................................... 71
4.6.3
Integracin Nodo Captura y Generador de Trfico .......................................................... 71
4.6.4
Emulacin de la trama SIP y Nodo Captura. .................................................................... 72
ANALISIS DE RESULTADOS ..................................................................................................... 73

5.3
CARACTERIZACION NODO CAPTURA ............................................................................ 73
5.3.3
Descripcin del funcionamiento Nodo Captura................................................................ 73
5.3.4
Caractersticas del hardware Nodo Captura ..................................................................... 74
5.3.5
Anlisis Nodo Captura .................................................................................................... 74
5.3.6
Emulacin 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
Parmetros 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
CONCLUSIONES ......................................................................................................................... 81
BIBLIOGRAFIA ........................................................................................................................... 83
8
ANEXOS ....................................................................................................................................... 85
ACRONIMOS ....................................................................................................................................... 86
LISTA DE FIGURAS
Figura 2-1. Evolucin de la Red Clsica a la NGN Simplificacin de la torre de Protocolos..17

Figura 2-2. Arquitectura de las redes de nueva generacin (NGN)..18
Figura 2-3. Separacin 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. Posicin de SIP dentro de la pila de protocolos.28
Figura 2-8. Flujo de mensajes de una Sesin SIP.28
Figura 2-9. Flujo de mensajes de una Sesin 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 bsica de interconexin las diferentes redes NGNs41
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. Comunicacin bsica del protocolo SIP de la red NGN ZTE-PUJ ...49
Figura 4-2. Comunicacin bsica del protocolo SIP de la red NGN ANKLA.....54
Figura 4-3. Estructura de un servidor Proxy SIP......61
Figura 4-5. Arquitectura PROXY de interconexin las diferentes redes NGNs de estudio63
Figura 4-6. Llamada saliente: Mensaje INVITE + SDP con timbrado local...64
10
Figura 4-7. Llamada saliente: Mensaje INVITE + SDP con conexin temprana de media....64
Figura 4-8. Diagrama bsico de la VPN las diferentes redes NGNs.......65
Figura 4-9. Diagrama bsico de NAT las diferentes redes NGNs...66
Figura 4-10. Configuracin VPN de la Red NGN ZTE-PUJ y la red NGN ANKLA68
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexin de usuarios las diferentes redes
NGNs...69
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexin de diferentes componentes de redes
NGNs...70
Figura 4-13. Generador de trfico SIP a travs de la troncal SIP de dos redes NGN72
Figura 4-14. Emulador de trfico SIP...72
Figura 5-1. Generacin de trfico SIP las diferentes redes NGNs..75
Figura 5-2. Traza de una de las pruebas de interconexin de bsqueda de llamada se sesin de las
diferentes NGNs..75
Figura 5-3. Diagrama de secuencia de la sealizacin SIP de una llamada de Softswitch Vs
Softswitch.76
Figura 5-4. Captura de traza de la sealizacin SIP de una llamada de Softswitch Vs Softswitch76
11
LISTA DE TABLAS
Tabla 2-1. Categoras de Respuesta SIP...33

Tabla 2-2. Cdigo 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 telefnicas IP (Protocolo SIP)..79
12
ANEXOS
Anexo 1. Sealizacin SIP en diversos escenarios.

Anexo 2. Cdigo fuente NODO CAPTURA.
Anexo 3. Archivos generados para medir QoS.
Anexo 4. Manual de instalacin NODOD CAPTURA.
Anexo 5. Manual de instalacin Generador de Trfico.
Anexo 6. Documentacin de interconexin redes NGNs.
Anexo 7. Emulaciones Trama SIP.
13
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 ms importante para la gran mayora 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 aparicin de una nueva generacin de arquitecturas de red (todo IP), emerge tambin un nuevo
portafolio de servicios, en los que se mezclan voz y datos; estar a la vanguardia de esta nueva generacin
de redes (NGN1), se convierte en un factor determinante de competitividad para los diferentes actores del
sector de las Telecomunicaciones y las Tecnologas de Informacin.
Al ser un mercado creciente encontramos mltiples operadores y fabricantes, que deben experimentar un
proceso de interconexin de elementos de red NGN, a travs de distintos protocolos y adems con otras
redes NGN, (alianza estratgica entre operadores y fabricantes) este escenario les origina numerosos
problemas de interconexin 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 Sesin), para la sealizacin en las redes NGN.
El protocolo SIP, es el que permite establecer, modificar y terminar sesiones multimedia; al ser el
protocolo determinado para la sealizacin de las redes NGNs, el problema est en que los diferentes
fabricantes de redes de Nueva Generacin implementan el protocolo SIP para la sealizacin de sus redes,
pero cada uno lo implementa con alguna restriccin o parmetro adicional, esto se hace debido a la
flexibilidad que tiene el RF3261 para no permitir la integracin de partes de diferentes fabricantes, esto
obliga a interactuar con su solo proveedor para la totalidad de la integracin de la red.
En este trabajo de grado disea e implementa una solucin de interconexin de dos redes NGN (Centro de
Tecnologas de Telecomunicaciones ZTE-PUJ Pontificia Universidad Javeriana y el
1
Redes de Nueva Generacin

Instituto Europeo de Normas de Telecomunicaciones
3
Telecomunicaciones e Internet Servicios convergentes y protocolos de red avanzada
2
14
Laboratorio
ANKLA). El desarrollo se bas en cuatro partes (la interconexin de las redes NGNs mediante una
conexin de internet VPN, un nodo captura que realiza el escucha de toda la sealizacin SIP, una
verificacin de su estructura y por ltimo se emplea un generador de trafico de VoIP para ver generar
grandes flujos de sealizacin con el protocolo SIP).
El objetivo general de este proyecto es; Disear e implementar una solucin de interconexin de redes
NGN mediante el protocolo SIP, para este fin se cumplieron los siguientes objetivos especficos:
Estudiar y analizar los parmetros del protocolo SIP en la interconexin redes NGN ZTE-PUJ y
ANKLA.
Definir e Implementar un mdulo basado en el protocolo SIP (software) que permita la

interconexin de redes NGN ZTE-PUJ y ANKLA.
Evaluar la funcionalidad y el desempeo del mdulo (software) del protocolo SIP, a travs de las
pruebas de operatividad de las redes NGN ZTE-PUJ y ANKLA.
El documento se organiza de la siguiente forma: en el MARCO TERICO, 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 interconexin de las dos redes ZTE-PUJ y ANKLA y se referencia la
descripcin de cada una de las redes NGN. En los DESARROLLOS, numeral 4, se explica cmo se
analiz el protocolo SIP en cada una de las redes NGN y como se implement la interconexin para
posteriormente realizar la verificacin, validacin de la interconexin. En el numeral 5, se muestran los
resultados obtenidos, y en el numeral 6 se concluye acerca de la puesta en marca de la interconexin y el
buen funcionamiento de la misma.
15
2. MARCO TEORICO
En el marco terico se hace un recuento de las diferentes arquitecturas y protocolos de comunicacin que
son necesarios para entender el contexto de interconexin de redes NGN.
2.1. REDES DE NUEVA GENERACION (NGN)
En Colombia se ha iniciado la migracin 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 comn 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 caracterstica 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 inalmbrico. Lo que
hace dos dcadas se intent conseguir con xito muy limitado mediante la Red Digital de Servicios
Integrados (RDSI), es decir, mltiples servicios a travs de un solo punto de acceso, est siendo
materializado hoy en da por las redes de nueva (o prxima) generacin (Next Generation Networks o
NGNs por sus siglas en ingls) con ncleo IP (Internet Protocol).
La definicin de la UIT para NGN es: Red basada en paquetes que permite prestar servicios de
telecomunicacin y en la que se pueden utilizar mltiples tecnologas de transporte de Banda Ancha
propiciadas por la QoS, y en la que las funciones relacionadas con los servicios son independientes de las
tecnologas 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 eleccin. Se soporta movilidad generalizada que
permitir la prestacin coherente y ubicua de servicios a los usuarios. [15].
16
Figura 2-1. Evolucin de la Red Clsica a la NGN Simplificacin 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 interconexin e integracin de nuevos servicios. Estos cuatro
niveles son los siguientes [4]:
Servicios: Esta interfaz es la encargada de la conexin lgica con los usuarios.
Control: Interfaz intermedia que permite la comunicacin 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 tecnologa usada puede ser en cable (fibra o cobre) o inalmbrica.
Tomado de Diseo de polticas ptimas en un entorno de convergencia de los medios de comunicacin y las telecomunicaciones
OSIPTEL
17
Figura 2-2. Arquitectura de las redes de nueva generacin (NGN)5
2.1.2.
Caractersticas de las redes NGN
El factor diferenciador de las redes NGNs es la separacin 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. Separacin de los servicios y el transporte en redes NGN6
Tomado de Telefnica, 2006

Tomado de UIT Y.2011
18
En primer lugar, hay un conjunto de funciones de transporte que se encargan nicamente del transporte de
la informacin digital de cualquier tipo entre dos puntos fsicamente separados. El transporte puede estar
formado por un conjunto complejo de redes, que constituyen las capas 1 a 3 en el modelo de referencia
bsico 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 telefona,
servicio web, etc. Los servicios pueden estar formados por un conjunto complejo de plataformas de
servicios fsicamente distribuidos, o, en el caso ms sencillo, nicamente las funciones de servicio entre
dos ubicaciones de usuarios extremo.
En segundo lugar existe un conjunto de funciones de aplicacin relacionadas con el servicio solicitado.
Los servicios pueden ser, por ejemplo, servicios de voz (incluido el servicio de telefona), servicios de
datos (no limitndose ste a los servicios basados en la web), o servicios de vdeo (no limitndose
tampoco a las pelculas y a los programas de televisin), o una combinacin de stos (por ejemplo,
servicios multimedia, como la telefona vdeo y los juegos).
Dado que existen muchas maneras de clasificar los servicios (por ejemplo, servicios en tiempo real/no en
tiempo real y servicios unidifusin/multidifusin/radiodifusin), en la figura 2-1 se proporciona un
ejemplo de lista de servicios (voz, datos y videos) que se prev ofrecern las redes de prxima generacin
[15].
Actualmente las arquitecturas funcionales de las redes NGN implementadas son::
SOFTSWITCH/MGC: Tambin es conocido como Call Agent o Media Gateway Controller

(MGC). Es el mecanismo que provee el control de provisin de servicio en la red. Est a cargo
del Control de llamadas, maneja el control de las Pasarelas de Medio (Acceso y/o Enlace) va
protocolo H.248. Realiza la funcin de una pasarela de sealizacin o usa una pasarela de
sealizacin para trabajar conjuntamente con la red de sealizacin PSTN N7. Provee conexin a
los servidores de Red inteligente/aplicaciones para proveer los mismos servicios que los
disponibles para los abonados TDM.
19
IMS/MGC: La arquitectura genrica de IMS (IP Multimedia Subsystem) soporta la comunicacin

entre equipos que utilizan SIP para la sealizacin y la administracin de sesiones, adems de los
protocolos Diameter y Megaco/H.248 para operaciones y manejo de recursos multimedia
aplicacin, quienes se encargan de: invocar los servicios, identificar qu sealizacin es requerida
y de qu forma los servicios interactan 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 descripcin 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 continuacin:
Telefona: NGN soporta la necesidad varios servicios de telefona existentes (ej, Llamada en
espera, llamada tripartita, reenvo 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 caractersticas de valor agregado.
Servicios multimedia: Permite que los usuarios interacten utilizando voz, video y/o datos.
Virtual Private Networks (VPNs): Mejora las capacidades de las empresas al permitir una
cobertura amplia, geogrficamente dispersa, al combinar las redes privadas existentes con
porciones de la red pblica.
Computacin pblica en la red: Provee servicios pblicos en la red para negocios y

consumidores.
Mensajera unificada: Soporta la entrega de mensajes de voz, correo electrnico, fax y

mensajera instantnea a travs de interfaces comunes.
Comercio electrnico: Permite a los consumidores la compra de bienes y servicios sobre la red.
Servicios para empresas y compras desde el hogar pertenecen a esta categora de servicios.
Servicios de Call Center: Un suscriptor puede realizar una llamada a un centro de contacto para
la adquisicin de nuevos productos o realizar consultas.
Juegos interactivos: Ofrece a los consumidores una forma para conocer y establecer sesiones de
juegos interactivos en lnea.
20
Realidad Virtual Distribuida: Se refiere a la tecnologa que genera representaciones de los

eventos del mundo real, personas, lugares, experiencias, etc.
Domtica: Con la llegada los electrodomsticos inteligentes y de las redes al hogar, estas
aplicaciones pueden monitorear y controlar los sistemas de entretenimiento caseros y otros
aparatos electrodomsticos.
Consultora: Involucra la publicidad, para proveer informacin 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 continuacin:
VoIP.
Web Browsing.
Chat.
Mensajera Instantanea.
WAP Browsing.
Mensajera 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 prxima generacin.
Es un dispositivo que provee control de llamada y servicios inteligentes para redes de conmutacin de
paquetes. Un Softswitch sirve como plataforma de integracin para aplicaciones e intercambio de
servicios. El Softswitch es capaz de transportar trfico de voz, datos y vdeo de una manera ms eficiente
21
que los equipos existentes, habilita al proveedor de servicio para soportar nuevas aplicaciones multimedia
integrando las existentes con las redes inalmbricas avanzadas para servicios de voz y Datos.7
Un Gateway Controller combinado con el media Gateway y el Signalling Gateway representan la mnima
configuracin de un Softswitch. El elemento controlador es frecuentemente conocido como Media
Gateway Controller (MGC). A continuacin 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 desconexin 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 sealizacin SS7 y los nodos
manejados por el Softswitch en la red IP.
MEDIA GATEWAY: Actualmente soporta Multiplexacin por divisin de tiempo (TDM) para
transporte de paquetes de voz al switch. Las aplicaciones de Codificacin de voz, Decodificacin
y compresin son soportadas, as como las interfaces de la Red telefnica pblica (PSTN) y los
protocolos CAS e ISDN.
MEDIA SERVER: Mejora las caractersticas funcionales del Softswitch, si es requerido soporta
Procesamiento Digital de Seales (DSP) as como la funcionalidad de la Respuesta de voz
interactiva (IVR).
FEATURE SERVER: Controla los datos para la generacin de la facturacin, usa los recursos y
los servicios localizados en los componentes del Softswitch.
SERVICES TARGETED: realiza funciones como traslacin de direcciones, enrutamiento, IVR,

emergencia, llamadas en espera entre otras.
Tomado de RIOS, Javier y GARCIA, Moraima, Softswitch, febrero 2004
22
SERVICE INTERFACE: Proporciona soporte para servicios suplementarios y clases de

servicios. Posee una arquitectura independiente de sealizacin, soporta protocolos como SIP,
H.323, SS7 e ISDN.
Un Softswitch puede contener uno o ms componentes, sus funciones pueden residir en un sistema o
expandirse a travs 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 genrica del IMS fue creada por 3GPP8 soporta la comunicacin entre equipos que utilizan
SIP para la sealizacin y la administracin de sesiones, adems de los protocolos SIP, SDP,
DIAMETER, RTP, RTCP, RSVP y DiffServ, para operaciones y manejo de recursos multimedia
aplicacin, quienes se encargan de: invocar los servicios, identificar qu sealizacin es requerida y de
qu forma los servicios interactan ente s.
La arquitectura de NGN IMS/MGC suministra acceso a cualquier servicio sin importar el tipo de medio,
usa el plano de control comn 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
3rd Generation Partnership Project es una colaboracin de grupos de asociaciones de telecomunicaciones.
23
necesita ninguna modificacin, ni ninguna nueva tecnologa 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 condicin de suscriptores
durante la duracin de la sesin de registro;
Control de la Sesin ejecuta el establecimiento de la llamada/sesin, modificacin y

terminacin;
Control de Servicio interacta con los Servidores de Aplicacin (Application Server) para el
soporte de servicios y aplicaciones;
Monitoreo de la llamada y generacin de registros de tarifacin;
Provee seguridad para la sesin.
Tomado de www.3gpp.org/
24
El Proxy CSCF es el primer contacto para que un mvil 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 mviles SIP y la red IMS;
Ejecuta una poltica 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
sealizacin 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
mltiplos 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 peticin SIP recibida de otra red en direccin al S-CSCF;
Obtener del HSS (Home Subscriber Subsystem) la direccin del S-CSCF;
Enrutar una peticin SIP o respuesta para la designacin ptima del MGW (Home Control of
roamers).
Enviar peticiones/respuestas SIP al I-CSCF en una red de otro operador para designacin ptima
de un Media Gateway (MGW), para terminacin de una llamada en la red pblica conmutada
(STFC).
BREAKOUT GATEWAY CONTROL FUNCTION (BGCF): El BGCF selecciona la red en la

cual el acceso a la red pblica 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 sealizacin de esta sesin a un BGCF o
MGCF (dependiendo de la configuracin) en la otra red. El objetivo final es minimizar el
recorrido de la llamada/sesin.
MEDIA GATEWAY CONTROL FUNCTION (MGCF): El MGCF provee la funcin de

interoperabilidad de la sealizacin entre los elementos de la red IMS y las redes legadas (STFC).
El MGCF controla un conjunto de MGWs a travs de la sealizacin H.248. La sealizacin
H.248
permite
el
establecimiento
de
recorridos
para
las
sesiones
interfuncionamiento (bajo la perspectiva de trfico) entre la STFC y la red IMS.

25
que
necesitan
MULTIMEDIA RESOURCE FUNCTION CONTROLLER (MRFC): El MFRC controla los

recursos de media del elemento Funcin de Recursos Multimedia Procesador (MRFP). Por
ejemplo, recursos necesarios para proveer tonos, anuncios y conferencia.
SIGNALING GATEWAY: Provee la conversin de sealizacin en ambas direcciones en la capa

de transporte entre SS7 y sealizacin basada en IP (por ejemplo ISUP/SS7 e ISUP/SCTP/IP).
POLICY DECISION FUNCTION (PDF): PDF es la funcin lgica que implementa la decisin
en relacin a la poltica 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 lgicas de
control (CSCF) acceden a los suscriptores. El HSS contiene los datos del usuario, que son pasados
al S-CSCF, y almacena la informacin temporaria con la localizacin 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
26
2.2. PROTOCOLO SIP (SESSION INITIATION PROTOCOL)
SIP es un protocolo especificado por la IETF en el RFC 3261[10], adems es aceptado como un protocolo
estndar por la organizacin 3GPP y forma parte de la arquitectura de NGN Redes de Nueva
Generacin. Adems SIP es usado globalmente como protocolo de sealizacin para VoIP.
Este protocolo se ubica en la capa aplicacin y permite a las terminales IP establecer, en rutar, modificar y
cerrar sesiones de comunicaciones a travs de redes IP; SIP por s mismo no garantiza ni reserva ancho de
banda para la sesin ni provee calidad servicio (QoS) y no define un mecanismo de entrega de los
paquetes que transportan la informacin de la sesin. SIP est diseado 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 direccin E-mail. Usa estas direcciones de
tipo correo electrnico 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 direccin, es decir por medio de una URL
SIP; logrando la independencia del dispositivo, y sin hacer distincin alguna entre voz y datos, telfono u
ordenador.
Para permitir establecer una sesin entre dos terminales, SIP provee cinco servicios de sealizacin:
Localizacin de los terminales
Invitacin a la sesin
Intercambio de informacin de media para establecer la sesin
Modificacin de sesiones existentes
Terminacin de sesiones
Como ya se dijo SIP es un protocolo presente en la capa de aplicacin diseado 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 parmetros de inicializacin de los flujos multimedia
SDP (protocolo de descripcin de sesin).
27
Figura 2-7. Posicin de SIP dentro de la pila de protocolos [1].
El protocolo SIP nicamente se utiliza para la sealizacin y no reserva recursos, y en consecuencia, no

puede asegurar la calidad de servicio. Una vez que la sesin est establecida, los participantes
intercambian directamente su trfico audio/video a travs del protocolo Real-Time Transport Protocol
(RTP).
En las figuras 2-8 y 2-9 se explica de manera sencilla cmo se lleva a cabo una sesin SIP entre dos
usuarios y se representan las funciones bsicas de SIP: localizacin del terminal, seal de la intencin de
un usuario de comunicarse, negociacin de los parmetros de la sesin a establecerse y terminacin de la
sesin una vez establecida.
Figura 2-8. Flujo de mensajes de una Sesin SIP [10].
28
Figura 2-9. Flujo de mensajes de una Sesin SIP con un analizador de protocolos.
De esta manera SIP por medio de mensajes de peticin y de respuesta provee la sealizacin necesaria
para el establecimiento y terminacin 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. Adems pueden conocer varias
29
alternativas para localizar a un agente de usuario, y pueden intentar cada una de ellas en un proceso de
bifurcacin que puede ser paralelo o secuencial.
El Servidor de Re direccionamiento (Redirect Server): este servidor acepta solicitudes SIP, traduce la
direccin 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 devolucin de una llamada, el Proxy Server tiene la capacidad de traducir el nmero del
destinatario recibido en el mensaje SIP, a un nmero 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 nmero 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 aplicacin sobre un equipo de usuario que emite
y recibe solicitudes SIP. Se materializa por un software instalado sobre un UserEquipment o UE (PC,
telfono IP). Los Clientes de agentes del usuario (UAC) envan 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 direccin SIP.
El Registrador (Registrar): se trata de un servidor quien acepta las solicitudes SIP REGISTER. SIP
dispone de la funcin de registro de los usuarios. El usuario indica por un mensaje REGISTER emitido al
registrador, la direccin donde se lo puede localizar (direccin IP). El registrador actualiza la base de
datos de localizacin. El registrador es una funcin 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 Peticin
Mtodos SIP
El RFC 3261[10] define seis solicitudes/requerimientos o mtodos SIP.
INVITE [RFC3261] usado para el establecimiento de una sesin entre UAs. Contiene
informacin 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 recepcin de una respuesta SIP.

30
BYE [RFC3261] permite la liberacin de una sesin 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 direccin SIP y
su direccin 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 mtodos SIP que soporta [10].
2.2.2.1. Extensiones del Protocolo SIP
SUBSCRIBE [RFC3265] utilizado para requerir notificacin 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 informacin de registro.
NOTIFY [RFC3265] utilizado para notificar un evento. Actualizaciones instantneas desde un

registrador a un cliente UA acerca de los usuarios que han cambiado la informacin 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
mtodo, es decir una transferencia a otra URL.
MESSAGE [RFC3428] permite la transferencia de mensajes instantneos. La mensajera

instantnea Instant Messaging o IM consiste en el intercambio de mensajes entre usuarios en
seudo tiempo real.
INFO [RFC2976] permite transferir informaciones de sealizacin durante la llamada (por

ejemplo: ISUP).
PRACK [RFC3311] definido para realizar una recepcin confiable de las respuestas temporales
de tipo 1XX.
UPDATE [RFC3311] permite a un terminal SIP actualizar los parmetros de una sesin
multimedia (flujo media y codecs). El mtodo UPDATE puede ser enviado antes de que la sesin
sea establecida.
31
2.2.2.2. Estructuras e mensajes.

Un mensaje SIP consta de las siguientes partes:
Lnea de inicio: indica el propsito del mensaje.
Cuerpo: proporcionan detalles del mensaje.
Lnea 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 lnea de inicio de una solicitud es el siguiente:
<Mtodo> <Solicitud-URI> <versin SIP>
<Mtodo> Es uno de los tipos de solicitudes SIP
<Solicitud-URI> Es el URL SIP u otro tipo de URL de la entidad que debera recibir el mensaje.
<versin SIP> Es actualmente SIP/2.0
INVITE sip:jdoe@company.com SIP/2.0
ACK sip:+14085551212@192.168.1.1;user=phone SIP/2.0
BYE tel:+1-408-555-1212;postd=p4199 SIP/2.0
2.2.3.
Mensajes de Respuesta
Despus de haber recibido e interpretado un requerimiento SIP, el destinatario de este requerimiento

devuelve una respuesta SIP.
El formato de lnea de inicio de una respuesta es el siguiente:
<VersinSIP> <Cdigo de estado> <Frase razn>
32
<VersinSIP> actualmente es SIP/2.0

<Cdigo de estado> y <Frase razn> se establecen a uno de los pares de los cdigo de Respuesta SIP
SIP /2.0 404 Not Found
SIP /2.0 180 Ringing
SIP /2.0 200 OK
Las respuestas SIP versin 2 estndar estn codificadas con tres dgitos de respuesta y una descripcin
textual. Las respuestas se clasifican en seis categoras, identificadas por el primer dgito el cual identifica a
que categora pertenece como se muestra en la siguiente tabla.
Tabla 2-1. Categoras de Respuesta SIP [1].
En la siguiente tabla se muestra la totalidad de los mensajes de respuesta de tres dgitos con su descripcin
[10].
33
CODIGO DESCRIPCIN DE LA RESPUESTA CODIGO DESCRIPCIN DE LA RESPUESTA

1XX
100
180
181
182
183
2XX
200
202
3XX
300
301
302
305
380
4XX
400
401
402
403
404
405
406
407
408
409
410
411
413
414
415
416
INFORMACION
Intentando
Ringing
La llamada est remitindose
En Cola
Progreso de la sesin
SUCESOS
OK
Aceptado
REDIRECCION
Opciones mltiples
Movido permanentemente
Movido temporal
Utilizar proxy
Servicio Alternativo
ERROR DEL CLIENTE
Respuesta mala
Sin autorizacion
Pago requerido
Prohibido
No encontrado
Mtodo no permitido
No aceptable
Se requiete autenticacin de Proxy
Se requiere lmite de tiempo
Conflicto
Hecho
Longitud requerida
Entidad solicitada demasiado grande
Solicitud-URI demasiado grande
Tipo de medio no soportado
Esquema URI no soportado
420
421
422
423
428
429
480
481
482
483
484
485
486
487
488
489
491
493
5XX
500
501
502
503
504
505
513
6XX
600
603
604
606
Extensin errnea
Extensin requerida
Sesin del temporizador de intervalos demasiado pequeo
Intervalo demasiado corto
Utilice token de autenticacin
Proporcionar identidad REFER
No disponible temporalmente
Circuito de llamada o transaccin no existe
Detectado un bucle
Demasiados saltos
Direccin incompleta
Ambiguo
Ocupado aqu
Solicitud terminada
No aceptable aqu
Terminacin de evento
Solicitud pendiente
Solicitar indescifrable
ERROR DEL SERVIDOR
Error al interior del servidor
No implementado
Gateway errneo
Servicio no disponible
Lmite de tiempo del gateway
Versin de SIP no soportada
Mensaje demasiado grande
ERROR GLOBAL
Ocupado completamente
Declinar
No existe en ninguna parte
No aceptable
Tabla 2-2. Cdigo de Respuesta SIP [1] [10].
2.2.4.
Cabecera SIP
La cabecera SIP representa un valor variable que es transportado a travs 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>
<Continuacin de valor de cabecera>
<Nombre cabecera> se los enumera en la tabla 3
<Valor cabecera> una o ms lneas de informacin.
<Continuacin de valor de cabecera> continuacin de la cabecera multilnea.
34

From: sip:102@2.0.0.1
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 lgicos, el
orden en el que se presentan estos grupos representan como deberan 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 fragmentacin 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.
NOMBRE DE CABECERA COMPLETO
Call-ID
Contact
Content-Encoding
Content-Length
Content-Type
From
Subject
To
Via
NOMBRE DE CABECERA ABREVIADO

i
m
e
l
c
f
s
t
v
Tabla 2-4. Abreviaturas de Nombre de Cabecera [1] [10].
35
2.2.5.
Cuerpo de los mensajes SIP (protocolo de descripcin de la sesin SDP)
Como se haba mencionado anteriormente el protocolo SIP es el encargado de establecer, modificar y

finalizar sesiones multimedia pero no de negociar parmetros (Codecs) entre los dos usuarios finales de
esto se encarga el protocolo SDP el cual se encuentra contenido en el protocolo SIP.
Protocolo de descripcin de la sesin (SDP)
SDP es el protocolo de descripcin de la sesin diseado para identificar los atributos de una sesin,
incluyendo informacin administrativa, sobre el programa y sobre los medios [12]. SDP especifica un
estricto orden de los atributos; este orden se basa en minimizar el tamao y complejidad del mensaje del
protocolo.
La tabla 2-5 especifica los atributos del protocolo SDP
TIPO SDP
DESCRIPCION
DESCRIPCION DE SESION
v=
Versin del protocolo
o=
Propietario-creador e identificador de sesin
s=
Nombre de la sesin
i=
*Informacin de la sesin
u=
*URI de descripcin
e=
*Direccin de e-mail
p=
Nmero de telfono
c=
b=
*Informacin de ancho de banda
<TIME_DESCR> Una o ms descripciones horarias
z=
*Ajustes de zona horaria
k=
a=
*Ninguna o ms lneas de atributos de sesin
<MEDIA_DESCR> *Ninguna o ms descripciones de los medios
DESCRIPCION DEL TIEMPO
t=
Tiempo en que la sesin est activa
r=
*Cero o ms repeticiones
DESCRIPCION DE MEDIOS
m=
Nombre de los medios y direccin del transporte
i=
*Ttulo de los medios
c=
b=
*Informacin del ancho de banda
k=
a=
*Ninguna o ms lneas de atributo
NOTA: *son opcionales
Tabla 2-5. Atributos de SDP [12]
36
2.3. PROBLEMAS GENERALES DE INTEROPERABILIDAD
Los problemas de interoperabilidad de las redes NGNs tanto en la arquitectura Softswitch e IMS
utilizando el protocolo SIP para la sealizacin pueden variar por varios motivos tal como:
Problemas de cdigo de respuesta: cuando un usuario final SIP fue movido y el usuario que
inicia la sesin 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 mxima de
los mensajes de SIP, la realidad es que los proveedores a menudo imponen lmites 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 cdigos de respuesta
especficos 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 semntico de la URI TEL, aunque con una
sintaxis diferente. Los usuarios SIP no tienen una forma real de saber cundo una URI pertenece a
un servidor SIP o a otro - el usuario presiona los botones numricos y pulse en "Enviar", y el
usuario SIP lo que puede hacer es enviar el solicitud a sip: [dgitos] @ [dominio local]. Adems,
muchos sistemas han sido diseados 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 parmetros URI: El problema de la interoperabilidad ms comunes en esta rea es

la colocacin de los parmetros TEL URI, por ejemplo, el "tgrp" y "contexto tronco" parmetros
de [RFC4904], y la "rn", "NPDI", y los parmetros "CIC" a partir de [RFC4694]. RFC 3261
seccin 19.1.6 est muy claro que todas las caractersticas de la telefnica de abonado, incluyendo
los parmetros, se coloca en la parte de userinfo de una SIP URI. Por lo tanto los parmetros de
Tel-URI se convierten en parmetros de usuario de SIP, parmetros SIP URI no.
Un ejemplo, por lo tanto, de una SIP URI que contiene algunos de los mencionados parmetros
11
URI (Uniform Resource Identifer / Identificador Uniforme de Recurso)
37
URI Tel-sera 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 especficos de interconexin 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 suscripcin de
manejo de respuesta. Por ejemplo, la UA enva una peticin 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 extensin, 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
extensin".
Por ejemplo, la etiqueta de opcin 100rel para apoyar PRACK, se inserta en la cabecera de una
peticin INVITE. Esto es fundamentalmente errneo en el uso real. El apoyo a PRACK no es
universal, en todo sentido, y la insercin de esta etiqueta en la cabecera que conduce a las
llamadas fallidas. Ningn usuario o el operador quieren una llamada fallida, a menos que sea
literalmente imposible de tener xito.
Desvi de llamada: Funciones especficas de facturacin, este es propietario del operador por lo
cual no son compatibles tanto de origen como destino.
Consulta de trasferencia de llamadas: Supuestos especficos de cada operador versus modelos

implementados, Por ejemplo, algunas aplicaciones y modelos de implementacin no son
compatibles con el de dilogo se referencia.
38
2.3.2.
Problemas especficos de interconexin del protocolo SIP e SDP
Oferta-INVITE a menos y Re-INVITE: Crea una invitacin, al ser negada reenva la invitacin
y no puede establecer una comunicacin por falta de parmetros en el protocolo SDP, por
ejemplo, que los dispositivos a enrutar las llamadas sobre la base del cdec, o la asignacin de
ancho de banda, o los dispositivos de transcodificacin que se envan no estn de acuerdo con lo
necesario.
Sealizacin: Funciones de pasarela de sealizacin, falta de parmetros entre proveedores un

dispositivo enva de una SDP, literalmente, no quiere que el otro extremo la reciba.
Peticin y respuesta SDP no coinciden: Un problema de interoperabilidad con frecuencia surge

cuando una oferta SDP contiene mltiples "m =" lneas de los medios de comunicacin, pero la
respuesta SDP no contiene el mismo nmero de lneas.
Medios compatibles Incompatibilidades: En la prctica, un nmero significativo de dispositivos

SIP slo soportan ciertos tipos de cdec.
39
3. ESPECIFICACIONES
En esta seccin se describen los componentes que se tuvieron en cuenta en la elaboracin de esta solucin
de interconexin de la red NGN ZTE-PUJ con arquitectura Softswitch/MGC y red NGN ANKLA con
arquitectura Softswitch/MGC.
DESCRIPCIN GENERAL
El trabajo de profundizacin consiste en el diseo e implementacin de una solucin de interconexin 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 investigacin los cuales se irn describiendo en el desarrollo del mismo.
Una caracterstica fundamental de la red NGN es la capacidad de suministrar una gran variedad de
servicios, incluidos voz, vdeo, audio y datos visuales, mediante servicios basados en sesin e interactivos
en los modos unidifusin, multidifusin y difusin; Basndose en la separacin de los servicios y
transporte como se describi en el numeral 2.1.2, la convergencia se centra en las tcnicas de integracin
de los diferentes protocolos de comunicacin para asegurar el inter funcionamiento de la red de transporte
con los servicios y las aplicaciones, para la interpretacin, generacin, distribucin y traduccin de la
sealizacin correspondiente y as poder realizar la integracin de los diferentes componentes de la
misma. La red NGN puede emplearse de manera coherente en cualquier instante o en cualquier lugar a
travs 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 comunicacin que tiene en cuenta las redes NGN
para las comunicaciones con sus diferentes dependencias y con la integracin con otras redes NGN.
Despus de tener en cuenta los diferentes protocolos de comunicacin de las redes NGN nos centraremos
en el protocolo SIP, el cual es el que nos permite realizar la interconexin en dos redes NGN mediante un
troncal SIP (canal de comunicacin con mltiples conexiones de sealizacin con el protocolo SIP), esto
se realiza para poder compartir servicios de voz, video y datos entre las dos redes.
40
Figura 3-1. Protocolos de la red NGN12
En la figura 3-2 se muestra el diagrama bsico de la interconexin entre red Red NGN ZTE-PUJ y
ANKLA.


CINTEL
Figura 3-2. Arquitectura bsica de interconexin las diferentes redes NGNs.
12
Tomado de Introduccin a los Protocolos NGN (ZTE)
41
3.1 Red NGN ZTE-PUJ
La plataforma del Centro de Tecnologas de Telecomunicaciones ZTE-PUJ se basa en una red de prxima
generacin marca ZTE, con arquitectura Softswitch/MGC de fabricacin China. Desde ella, se puede
proveer servicios: voz sobre IP, telefona tradicional/IP e Internet Banda ancha.
La arquitectura general de la red es la siguiente:
Nivel de servicios. Servidores de aplicacin tales como (Asterisk, Elastik, Open Source IMS,
Mobicents, Kamailio)
Nivel de control. Softswitch (control, servicios, gestin de llamadas)
Nivel de transporte. Core (conmutacin de paquetes).
Nivel de acceso. Inalmbrico, banda ancha, PSTN, ISDN, con equipos: UAM (MSAG), abonados
anlogos y ADSL (convierte seales de voz anloga a IP; IAD, concentrador de lneas USUARIO
Analgicas 8-24, conexin IP hacia el SS; SG, sealizacin 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
42
3.2 Red NGN ANKLA
El laboratorio ANKLA sigue una estructura de red NGN para la implementacin 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) versin 4.0 de Ericsson: Est conformado por un
Telephony Server (AXE), TSS Gateway Controller y un Media Gateway (MGW). Soporta
protocolos de sealizacin 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 travs de un Access Gateway (AGW), ANKLA cuenta con una
capacidad instalada de 60 abonados. Provee servicios suplementarios como reloj despertador,
lnea directa, llamada tripartita, identificadores de llamadas, marcacin abreviada y llamada en
espera.
Plataforma de servicios de Trpico: Est conformada por un servidor de aplicaciones (VAS) que
realiza las tareas de control y lgica del servicio en las diferentes aplicaciones instaladas, un
servidor de medios para la reproduccin de anuncios y procesamiento multimedia (VMS) y un
mdulo de reconocimiento de voz (ASR Nuance) encargado de las tareas de reconocimiento
automtico de voz y su correspondiente conversin a texto. Provee servicios de Portal de Voz
para la atencin de servicios de Call Center, mediante un IVR por reconocimiento de voz, y un
sistema de conversin numrica y distribucin de llamadas para la atencin del usuario
mediante operador.
Plataforma de comunicaciones unificadas: Conformada por dos servidores AsteriskNow y

Elastix para realizar la integracin de servicios entre usuarios Legacy (TDM) e IP, proveen
servicios de VoIP tales como videollamadas, IVR, y call center adems de integrar servicios de
mensajera instantnea, fax, videoconferencias, tarificacin y correo electrnico.
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 Sessin Control Function (P-CSCF).
Interrogating Call Sessin Control Function (I-CSCF).

43
Serving Call Sessin Control Function (S-CSCF).
Home Subscriber Server (HSS).
Servidores de aplicaciones SIP (SIP AS).
Figura 3-4. Arquitectura ANKLA14
3.3 Infraestructura de Interconexin redes NGNs.
Para la interconexin de las redes NGNs ZTE-PUJ y ANKLA se tuvieron en cuenta una serie de
herramientas de tipo software y hardware que sern descritas a continuacin.
3.3.1
Nodo Captura
El nodo captura es un sistema robusto, capaz de recolectar y encapsular enormes cantidades de

sealizacin SIP con capacidad de bsqueda instantnea, la cual nos da un anlisis de extremo a extremo
de la sealizacin 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
44
los posibles cambios en las tramas y realizar una correccin de la misma; el funcionamiento del nodo
captura est dividido en tres partes el primero es un proxy SIP (Kamailio) que recolecta toda la
sealizacin SIP que le enva el Capture Agent. La ventaja de este tipo de solucin es que vamos a
tener la posibilidad de ver todo ese tipo de trfico en un sitio web (WebHomer).
Kamailio es un servidor SIP de cdigo abierto que puede adoptar todas las entidades lgicas
conocidas en un entorno VoIP:
Servidor Registrador o Registrar Server
Servidor Proxy o Proxy Server
Servidor Redireccionador o Redirect Server
Servidor de Localizacin o Location Server
Capture Agent, est basado en el mdulo sipcapture (El mdulo 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 extrayndolas en archivos
PCAPs para mostrar el trfico y las estadsticas multiusuario, niveles de acceso.
Figura 3-5. Arquitectura Nodo Captura15
El Nodo Captura necesita de unos requisitos mnimos adicionales de software para su funcionamiento
como son los siguientes:
15
Tomado de http://www.sipcapture.org/
45
El Nodo Captura trabaja exclusivamente sobre ambientes Linux, necesita de un servidor web para la
publicacin de la interfaz grfica (WebHomer), una base de datos Mysql para que el servidor kamailio
guarde toda sealizacin SIP y servidor PHP para poder generar los reportes de sealizacin 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 trfico
El generador de trfico Distributed Internet Traffic Generator (D-ITG). Es una plataforma capaz de
producir trfico a nivel de paquetes con gran exactitud, replicando apropiadamente procesos estocsticos
tanto para IDT (Inter Departure Time), como para variables PS (Packet Size) aleatorias (exponencial,
uniforme, Cauchy, normal y Pareto). Soporta generacin de trfico IPv4 e IPv6 y es capaz de generar
trfico a nivel de red, transporte y aplicacin.
D-ITG, es el software seleccionado para el proyecto que permite implementar algunos protocolos en la
capa de aplicacin como: VoIP, Telnet, DNS, entre otros. En general, permite implementar protocolos
hasta en la capa de transporte, por lo que al modelar algn tipo de trfico para ser generado e inyectado
por el D-ITG en la red, es necesario abstraer el comportamiento estadstico de la capa de aplicacin 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 aplicacin que existen. Pero a nivel de los
sistemas de conmutacin 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 realizacin de una medida de QoS en una red de telecomunicaciones, para
cada servicio por ejemplo, la QoS de una llamada telefnica IP es necesario modelar el trfico de una
llamada telefnica IP real, de forma estadstica, y entregarle estos parmetros al D-ITG, para configurarlo
y modelar el trfico de una llamada telefnica IP. Posteriormente, ese trfico moldeado se inyecta a la red,
que se encarga de implementar todos los protocolos de esa comunicacin, hasta la capa de transporte.
46
3.3.3
Simulador trama SIP
SIP Inspector es una herramienta prctica 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 sealizacin 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 ms sobre el protocolo de sealizacin SIP, gracias a la incorporacin de esquemas para
los casos de UAC y de UAS.
3.3.3.4 Firewall
Un cortafuego (firewall en ingls) es una parte de un sistema o una red que est diseada 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 trfico 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 combinacin 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.
47
DESARROLLOS.
En esta seccin del documento se explica y documentan todos los desarrollos e implementaciones
realizadas para el cumplimiento de los objetivos del proyecto. Las cuales fueron un anlisis del
comportamiento y cabeceras de la sealizacin SIP en cada una de las redes NGN con arquitectura
Softswitch/MGC; se mont un escenario real para poder hacer un anlisis de la interoperabilidad entre la
Red NGN ZTE-PUJ y ANKLA.
4.3
ANLISIS DEL PROTOCOLO SIP.
El anlisis del protocolo SIP se realiz de manera detallada con una conexin bsica, observando y
analizando la trama de sealizacin en cada una de sus partes en la red NGN con arquitectura
Softswitch/MGC, para poder tener un punto de partida del sistema de sealizacin a nivel de troncal SIP y
poder llegar a la interconexin de las dos redes NGNs de diferente fabricante [1].
4.3.3
Anlisis del protocolo SIP ZTE-PUJ
segn el RFC 3261como se muestra en el anlisis de la siguiente sealizacin SIP.
48
Figura 4-1. Comunicacin bsica del protocolo SIP de la red NGN ZTE-PUJ
INVITE sip:102@172.22.0.34 SIP/2.0

To: "102"<sip:102@172.22.0.34>
From: "103"<sip: 103@172.22.0.34>;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-Length: 288
v=0
o=1033608424475 IN IP4 10.66.74.136
s=session SDP
49
c=IN IP4 172.22.034

t=0 0
a=ptime:20
a=rtpmap:18 G729/8000
a=rtpmap:34 H263/90000
NOTA: en la estructura el mensaje invite no se encuentra ningn tipo de modificacin o adicional en la

To:"102"<sip:102@172.22.0.34>;tag=a290601-31939
From:"103"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 23944 INVITE
Contact: <sip:102@172.22.0.34>
Content-Length: 115
50
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
a=ptime:20
NOTA: en la estructura el mensaje 183RING no se encuentra ningn tipo de modificacin o adicional en
SIP/2.0 200 OK
To:"102"<sip:102@172.22.0.34>;tag=a290601-31939
From:"103"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 23944 INVITE
Contact: <sip:102@172.22.0.34>
Content-Length: 115
v=0
o= ZTE 32 32 IN IP4 172.22.0.34
51
s=phone-call
c=IN IP4 10.52.31.237
t=0 0
a=ptime:20
ACK sip:172.22.0.34;lr SIP/2.0

To: "102"<sip:102@172.22.0.34>
From: "103"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 23944 ACK
Contact: <sip:#103@172.22.0.54:5060>
Max-Forwards: 70
Route: <sip:102@172.22.0.34>
BYE sip:102@172.22.0.54:5060 SIP/2.0

To: 103"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
52
From: "102"<sip:102@172.22.0.34>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 18927 BYE
Max-Forwards: 69
Content-Length: 0
SIP/2.0 200 OK
To: "#0*109316"<sip:103@172.22.0.34>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:102@172.22.0.34>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@172.22.0.54
CSeq: 18927 BYE
Max-Forwards: 69
Despus de haber analizado la trama de sealizacin SIP con el RFC 3261 de una comunicacin bsica de
la red NGN ZTE-PUJ con arquitectura Softswitch/MGC SIP no se encontr ningn tipo de modificacin
o adicin a la misma, el cual nos da un principio de interconexin sin presentar ningn problema.
53
4.3.4
Anlisis del protocolo SIP ANKLA
segn el RFC 3261 como se muestra en el anlisis de la siguiente sealizacin SIP.
Figura 4-2. Comunicacin bsica del protocolo SIP de la red NGN ANKLA
INVITE sip:0755526778086@10.41.6.1 SIP/2.0

To: "0755526778086"<sip:0755526778086@10.41.6.1>
From: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 INVITE
Contact: <sip:#0*109316@10.66.74.136:5060>
Max-Forwards: 70
User-Agent: ERICSSON MULTIMEDIA SIPPHONE/V1.0 04-01-10
54
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
a=ptime:20
a=rtpmap:18 G729/8000
a=rtpmap:34 H263/90000
NOTA: en la estructura el mensaje INVITE no se encuentra ningn tipo de modificacin o adicional en la

To:"0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
From:"#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 INVITE
Contact: <sip:0755526778086@10.41.6.1>
55
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
a=ptime:20
NOTA: en la estructura el mensaje 183 RING no se encuentra ningn tipo de modificacin o adicional en
SIP/2.0 200 OK
To:"0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
From:"#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 INVITE
Contact: <sip:0755526778086@10.41.6.1>
56
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
a=ptime:20
ACK sip:10.41.6.1;lr SIP/2.0

To: "0755526778086"<sip:0755526778086@10.41.6.1>
From: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 23944 ACK
Contact: <sip:#0*109316@10.66.74.136:5060>
Max-Forwards: 70
Route: <sip:0755526778086@10.41.6.1>

57
BYE sip:#0*109316@10.66.74.136:5060 SIP/2.0

To: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 18927 BYE
Max-Forwards: 69
Content-Length: 0
SIP/2.0 200 OK
To: "#0*109316"<sip:#0*109316@10.41.6.1>;tag=884a420a-7062206315162668
From: "0755526778086"<sip:0755526778086@10.41.6.1>;tag=a290601-31939
Call-ID: 072a13acfdc2669-884a420a@10.66.74.136
CSeq: 18927 BYE
Max-Forwards: 69
58
Despus de haber analizado la trama de sealizacin SIP con el RFC 3261 de una sealizacin bsica de
la red NGN ANKLA con arquitectura Softswitch/MGC no se encontr ningn tipo de modificacin o
adicin a la misma, el cual nos da un principio de interconexin sin presentar ningn problema.
4.3.5
Comparacin de las dos redes NGNs
Al realizar un estudio comparativo de la sealizacin SIP de las dos redes NGNs 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 tcnicas a tomarse en cuenta para la
interoperabilidad e interconexin de las dos redes NGN a travs de troncales SIP [7].
El uso del protocolo SIP permite la interconexin de equipos de mltiples fabricantes debido a su
estandarizacin y a la simplicidad del intercambio de mensajes [1].
4.4.3
Escenario de interoperabilidad ZTE-ANKLA
Uno de los mecanismos ms recientes para los servicios convergentes es la capacidad de acceso basado en
SIP, o de manera ms general, la conexin a redes NGNs mediante troncales SIP [7]. Estas capacidades
posibilitan el uso de implementaciones basadas en estndares abiertos de conectividad SIP, ya sea para
hacer ms 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 geogrfico de los carriers para atender nuevos
mercados a travs de una conectividad IP. La interconexin a travs de troncales SIP tiene algunas
ventajas para las redes NGN:
Reduce los costos y la complejidad de las implementaciones gracias a la consolidacin de la voz y

los datos sobre una sola red.
59
Permite hacer uso de otros servicios IP dependientes del tipo de transporte como: transferencia de
mensajes de audio, video conferencias, presencia, mensajera instantnea, etc.
Capacidad de expansin de los servicios de comunicaciones para satisfacer demandas no

contempladas.
Implementacin 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 aos, ha ido creciendo la aceptacin de la industria con respecto a SIP
como el protocolo primario de comunicacin IP entre sistemas, independientemente de la aplicacin.
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 conexin a Internet, incluso con otra red NGN. Desde esta red de
datos (red IP) se accede a travs de una troncal SIP a la red NGN con arquitectura Softswitch/MGC.
Con SIP versin 2, se han adicionado nuevas caractersticas que permiten al equipo comunicarse con redes
VoIP de mltiples fabricantes. Sin embargo, todava no existe una garanta de que todos los fabricantes,
interpreten e implementen los estndares de la misma forma [1].
Las troncales SIP proveen mayor flexibilidad en cuanto a la configuracin 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 direccin IP como direccin para enrutar un servicio.
Algunas configuraciones de red pueden requerir el uso de uno o ms servidores proxy de salida (por
ejemplo en presencia de un controlador de borde o si el proveedor de servicios usa mltiples nodos para
enrutar llamadas). Ver figura 4-3.
Dado el caso prctico de interoperabilidad de las redes NGNs de estudia se implement los Softswitchs
como servidores proxy.
60
Figura 4-3. Estructura de un servidor Proxy SIP16
En el RFC 2833 se define un mtodo estndar para transmitir dgitos de sealizacin entre dos usuarios
finales transmisin RTP. Esto permite una transmisin confiable de los paquetes entre usuarios finales
independientemente de la calidad del CODEC utilizado para la transmisin de la voz.
Con el fin de activar determinados escenarios de llamadas como transferencia de llamadas sobre troncales
SIP, el mtodo REFER el cual esta descrito en el RFC 3515. Luego que una llamada ha sido establecida
entre dos usuarios, se utiliza el mtodo SIP REFER para transferir la llamada. El mensaje REFER provee
la informacin de contacto a la otra parte (donde la llamada ser transferida).
El funcionamientos de la troncal SIP de realiza con las sesiones de la sealizacin SIP que normalmente
se establecen a travs de un servidor Proxy SIP. El servidor Proxy SIP se ubica en medio del camino de la
sealizacin y provee un servicio de bsqueda para los mensajes entrantes y salientes. Este servicio puede
ser una bsqueda DNS o una bsqueda en una base de datos de informacin de presencia, en la cual los
usuarios han registrado su localizacin y su estado de presencia. En cualquier caso el trabajo del servidor
proxy es encontrar a la persona que est siendo invitada a una sesin de media.
El siguiente ejemplo nos da una visin del funcionamiento del PROXY SIP.
El USUARIO A desea realizar una llamada desde su telfono IP hacia el telfono de USUARIO B, por lo
que levanta el auricular del telfono y marca. Este no conoce exactamente la localizacin de USUARIO B,
de manera que su telfono (usuario SIP) re direcciona el mensaje INVITE hacia el servidor proxy SIP.
16
Tomado de Softswitch Architecture for VoIP
61
El servidor proxy realiza una bsqueda del URI de USUARIO B y obtiene su direccin IP, entonces enva
el mensaje INVITE hacia el telfono de USUARIO B, aadindole al mismo un encabezado llamado
Via: el cual contiene la direccin 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 ms de un encabezado
Via:, se sabe que el paquete ha atravesado un servidor proxy. El telfono de USUARIO B responde con
un 180 Ringing enrutado hacia el USUARIO A a travs 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 enva un ACK directamente
hacia USUARIO B (sin pasar por el proxy). En este punto la sesin se encuentra establecida y se desarrolla
directamente entre los dos (usuarios SIP), hasta que se termine la sesin con los mensajes BYE y 200 OK.
El ejemplo solo contiene un servidor proxy para la sesin SIP, sin embargo tpicamente se tiene varios
servidores proxy en el camino de sealizacin, usualmente, al menos uno por sistema autnomo.
En la figura 4-3 se muestra la representacin de mensajes SIP dos servidores proxy SIP.
Los servidores proxy se encuentran usualmente estructurados en una topologa que el RFC 3261 define
como trapezoide SIP. Este trapezoide describe la forma en que la media y la sealizacin fluyen cuando:
17
Tomado de Softswitch Architecture for VoIP.
62
Dos usuarios SIP de una sesin 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 travs
de su servidor proxy.
En la figura 4-5 se realiza un diagrama de interconexin utilizando los diferentes Softswitch como
servidores proxy SIP para el intercambio de mensajes de sealizacin SIP con otras redes NGN; en este
caso se realiza entre el ZTE-PUJ) ANKLA


CINTEL
Figura 4-5. Arquitectura PROXY de interconexin las diferentes redes NGNs de estudio
En el intercambio de mensajes SIP desde los diferentes PROXY de cada red tambin 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 tpica, el usuario SIP enva el mensaje INVITE junto con una peticin de
establecimiento de sesin usando SDP. En este caso, el telfono de destino responde con un 180 Ringing
que permite escuchar un tono de confirmacin de timbrado en el telfono de origen. Cuando el auricular
del telfono se levanta en el otro extremo, ste enva un mensaje 200 OK con la confirmacin de uso de
SDP [7].
63
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 continuacin 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 conexin 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
64
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 enva un mensaje re-INVITE con una oferta SDP y con un
atributo sendonly (sesin unidireccional). El otro extremo de la troncal SIP puede seguir recibiendo
media. La direccin IP especificada en SDP seguir siendo vlida.
4.4.4
VPN y sus caractersticas de interoperabilidad.
La interconexin 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 informacin entre diferentes redes que estn situados en
diferentes reas geogrficas. Es una red de datos de gran seguridad que utilizando Internet como medio de
transmisin permite la transmisin de informacin confidencial entre las dos NGNs. Aunque Internet es
una red pblica y abierta, la transmisin de los datos se realiza a travs de la creacin de tneles virtuales,
asegurando la confidencialidad e integridad de los datos transmitidos. El diagrama bsico de interconexin
de las dos redes NGNs de estudio se muestra en la figura 4-8.
TRONCAL SIP
TRONCAL SIP
VPN SITE TO SITE

SOFTSWITCH
NGN ZTE
SOFTSWITCH
NGN ERICSSON
Figura 4-8. Diagrama bsico de la VPN las diferentes redes NGNs
Una Red Privada Virtual (VPN) conecta los componentes de una red sobre otra, por medio de la conexin
de los usuarios de distintas redes a travs de un "tnel" que se construye sobre Internet o sobre cualquier
otra red pblica, negociando un esquema de cifrado y autentificacin 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 estn implementadas con firewalls,
con routers para lograr esa encriptacin y autentificacin.
65
4.4.4.4 VPN Sitio a Sitio utilizando NAT
(Network Address Translation) Traduccin de Direcciones de Nombres es el proceso de cambiar una

direccin IP de una NGN (una direccin privada de la organizacin) por una direccin IP pblica
enrutable, es decir poseen la capacidad para esconder las direcciones privadas de una NGN.
Los pasos siguientes describen el proceso de comunicacin 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 direccin IP enrutable.
El firewall implementado con NAT reenva 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 direccin IP por el nmero original, este es enviado hacia el enrutador interno
para ser dirigido hacia su destino.
En la figura 4-9 se muestra el diagrama de interconexin utilizado para las redes NGNs 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.
NAT
172.22.0.48/28
192.168.0.0/24
TRONCAL SIP
SOFTSWITCH
NGN ZTE
172.22.0.48/28
ASA 5510
IP PUBLICA
200.3.153.91
TRONCAL SIP
VPN SITE TO SITE ASA 5505

IP PUBLICA
IPsec
190.25.130.245
SOFTSWITCH
NGN ERICSSON
192.168.0.0/24
Figura 4-9. Diagrama bsico de NAT las diferentes redes NGNs
4.4.4.5 Seguridad VPN IPSec
En la implementacin de la VPN para la interconexin de las diferentes redes NGNs ZTE-PUJ y

ANKLA, un factor muy importante es la seguridad con la que nuestros datos son trasportados a travs de
66
internet, por tal razn IPSec - Internet Protocol security el cual nos da una seguridad mejorada con
caractersticas tales como algoritmos de encriptacin ms fuertes y autenticacin ms comprensiva. IPSec
tiene dos modos de cifrado, tnel y transporte. El modo de tnel cifra el encabezado y la carga de cada
paquete, mientras que el mtodo de transporte slo encripta la carga o contenido de los paquetes. Slo
sistemas que son compatibles con IPSec pueden usar este protocolo. Tambin, todos los dispositivos
deben usar una clave comn o certificado y deben tener implementadas polticas de seguridad similares.
Para usuarios de acceso remoto de VPN hay paquetes de software que proveen cifrado y conexin en un
PC. IPSec soporta cifrado de 56 bits (single DES) o 168 bits (triple-DES).
4.4.4.6 Descripcin de los Parmetros de la VPN Sitio a Sitio de la Red NGN ZTE-PUJ y ANKLA
Despus de haber explicado los diferentes componentes a tener en cuenta en la interconexin de las
diferentes redes NGNs ZTE-PUJ y ANKLA, se decide crear un VPN sitio a sitio para el intercambio de
toda la sealizacin SIP y la media. Con esto las estas redes puedan compartir servicio y aplicaciones. Ver
figura 4-10.
VPN SITE TO SITE

NODO CAPTURA
* Ipsec authentication uses pre-shared

key: zte
*Tunnel Group Name: interconexion
*IKE group Encryption: DES / SHA
TRONCAL SIP
TRONCAL SIP
SOFTSWITCH
NGN ZTE
ASA 5510
IP PUBLICA
200.3.153.91
ASA 5510
IP PUBLICA
190.25.130.245
NAT
172.22.0.48/28
SOFTSWITCH
NGN ERICSSON
192.168.1.0/24
Figura 4-10. Configuracin VPN de la Red NGN ZTE-PUJ ANKLA
4.5
METODOLOGA DE ANLISIS DE INTEROPERABILIDAD
Despus de establecer la interconexin de las dos redes NGNs ZTE-PUJ y ANKLA mediante una VPN
sito a sitio para l envi de sealizacin SIP y media mediante una troncal SIP y utilizando los softswitch
como servidores PROXY para la conexin desde el interior de cada red con la otra NGN, se decide
implementar un elemento ms, el NODO CAPTURA para que estudie, analice y modifique de ser
67
necesario la sealizacin SIP que est pasando entre las dos redes NGNs y no presente inconvenientes de
interoperabilidad de las mismas.
4.5.3
Identificacin y reconocimiento
Para revisar los diferentes aspectos de interconexin e interoperabilidad de las diferentes redes NGNs
ZTE-PUJ y ANKLA se realizaron una serie de pruebas de telefona IP las cuales involucraron una serie de
componentes como fueron telfonos SIP, softphones SIP, telfonos analgicos tradicionales conectados a
la red SIP, un Proxy SIP (Softswitch) y el nodo captura para el anlisis de resultados.
Para realizar las pruebas, se accedi desde un cliente SIP de la primera red NGN a travs del Softswitch
(Servidor Proxy SIP) y enviando la sealizacin a travs 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
desempeo segn el resultado esperado de la prueba.
Este esquema de pruebas permite comprobar la interoperabilidad del NODO CAPTURA a travs de una
troncal SIP con algunos dispositivos necesarios para la conectividad y acceso a la red pblica mediante
SIP, incluyendo: servidor proxy SIP, gateways FXO, gateways FXS, telfonos analgicos, softphones SIP,
telfonos IP. Adems con esta implementacin se pueden probar los siguientes escenarios de
interoperabilidad:
Llamada simple entre dispositivos IP a travs de troncal SIP.
Llamada interna entre telfonos SIP.
Transferencia de llamadas usando el mtodo REFER (RFC 3515).
Escenarios de espera: espera unidireccional, espera mutua y desactivacin de espera.
Estados de presencia en dispositivos SIP.
Identificacin de llamadas CLIP (Calling Line Identification Presentation).
En primer lugar se estableci una conexin mediante de una VPN y l envi de sealizacin SIP y media a
travs 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 especfica la troncal, el mapeo
de direcciones IP, puertos a utilizarse, establecer el plan de numeracin y los nombres de dominio
utilizados en la red SIP, esto para evitar conflictos de nmeros y direcciones URI, finalmente establecer el
acceso externo mediante troncal SIP.
68
En el caso del servidor, se procedi a realizar los pasos necesarios para configurar los telfonos SIP y los
softphones.
Para constatar y/o depurar los procedimientos en las pruebas asociadas a la conmutacin 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 tambin es posible verificar los mensajes
asociados a los estados de presencia; y en el medio de las redes NGNs se configuro el Nodo Captura para
capturar toda la sealizacin SIP que se est enviando a travs 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 Travs De Troncal SIP
softphone IP de la red NGN ZTE-PUJ hacia un softphone SIP de la red NGN ANKLA a travs de la
troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el nmero de destino, en
el usuario SIP origen, debe recibir un mensaje INVITE desde la direccin del proxy, confirmando con el
timbrado del telfono; cuando la llamada es contestada el destino enva un mensaje 200 OK y se
establece la sesin a travs de paquetes RTP.


CINTEL
Figura 4-11. Arquitectura Proxy y Nodo Captura de interconexin de usuarios las diferentes redes NGNs
69
4.5.3.5 Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones
softphone IP de la red NGN ZTE-PUJ hacia un cliente SIP del servidor de aplicaciones de la red NGN
ANKLA a travs de la troncal SIP, atravesando el NODO CAPTURA. Para realizar esto se debe marcar el
nmero de destino, en el usuario SIP origen, se debe recibir un mensaje INVITE desde la direccin del
proxy, confirmando con el timbrado del telfono; cuando la llamada es contestada el destino enva un
mensaje 200 OK y se establece la sesin a travs de paquetes RTP.


CINTEL
Figura 4-12. Arquitectura Proxy y Nodo Captura de interconexin de diferentes componentes de redes NGNs
70
4.6

TRAMA SIP
Despus de realizar las pruebas con un solo usuario se implementaron otra serie de pruebas con un
generador de trfico SIP, para poner a prueba la capacidad de interoperabilidad con flujos de sealizacin
SIP ms grandes y observar el comportamiento del Nodo Captura.
4.6.3
Integracin Nodo Captura y Generador de Trfico
En la figura 4-13 se muestra la forma de inyectar el trfico emulado con el generador de trfico D-ITG en
la red NGNs, el cual pasa por el Nodo Captura para realizar un anlisis de grandes cantidades de
sealizacin SIP; y verificar segn el RFC 3261 la estructura de trama SIP, y poder medir la calidad de
servicio (QoS).
La configuracin utilizada para esta prueba fue instalar el equipo transmisor en la red ZTE-PUJ desde el
cual el D-ITG inyecta trfico en la red y un equipo receptor en la red ANKLA que lo toma y lo procesa
generando un archivo de registro, con los parmetros medidos en la transmisin realizada. Esta captura
contiene datos que determinan el comportamiento estadstico de la aplicacin, tales como: la tasa de
paquetes enviados (paquetes/segundo), el tamao de los paquetes (bytes/paquete), el byte DSCP (servicios
diferenciados), el TTL, los protocolos usados en la transmisin, los puertos, el ancho de banda, entre
otros. Estos parmetros son tomados como datos de entrada al software D-ITG, donde se usan para
modelar el comportamiento estadstico a nivel de transmisin de las aplicaciones ofrecidas por la NGN y
emular el comportamiento real de la aplicacin 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 tambin desde la red NGN ANKLA como transmisor hacia
la red NGN ZTE-PUJ como receptor.
71
Figura 4-13. Generador de trfico SIP a travs de la troncal SIP de dos redes NGN.
4.6.4
Emulacin 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 parmetros 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 trfico SIP.
72
ANALISIS DE RESULTADOS
Los resultados obtenidos se basan en el funcionamiento del Nodo Captura en los diversos escenarios, esto
se logr despus de hacer las diferentes pruebas de interoperabilidad especialmente evaluando la
sealizacin SIP y parmetros 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 NGNs
evaluando la sealizacin SIP.
5.3.3
Descripcin 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 versin 4, el cual es el encargado de almacenar en una base de datos, (Mysql)
toda la sealizacin SIP que le llega al nodo captura, el segundo de ellos es un agente captura que hace la
funcin de puerto de escucha y es el encargado de copiar, modificar y llevar toda la sealizacin 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 integracin de dos NGNs de diferentes fabricantes.
Ver anexo 2.
18
Calidad de Servicio
73
5.3.4
Caractersticas del hardware Nodo Captura
Para la implementacin e instalacin 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 versin 12.04 con todas sus actualizaciones sobre una
mquina que tena la siguientes caractersticas 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
Anlisis 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 diseo adecuado para la sealizacin 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 sealizacin SIP de la red redes NGN ZTE-PUJ y ANKLA; para esto se puso en
marcha el Nodo Captura y se le inyecto trfico por medio de generador de trfico, este nos permite medir
un trfico real (genera trfico que emula la sealizacin SIP y trfico 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 trfico 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 trfico enva el trfico en primer lugar al proxy de la red NGN ZTE-PUJ, despus al Nodo
Captura el cual realiza la funcin de escucha para poder evaluar la sealizacin SIP, despus al proxy
destino la red NGN ANKLA y por ultimo al receptor del generador de trfico de la red de destino en la
figura 5-2 podemos observar la sealizacin 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.
74
Figura 5-1. Generacin de trfico SIP las diferentes redes NGNs
Figura 5-2. Traza de una de las pruebas de interconexin de bsqueda de llamada se sesin de las diferentes NGNs
Despus de realizar un anlisis detallado de la sealizacin SIP que est pasando por el Nodo Captura no
encontramos ningn parmetro adicional o faltante en sus cabeceras de mensajes SIP, la cual se puede ver
en la figura 5-3.
75
Figura 5-3. Diagrama de secuencia de la sealizacin SIP de una llamada de Softswitch Vs Softswitch
Se realiza una exportacin a un analizador de protocolos (wireshark) para observar el comportamiento de

la sealizacin SIP entre las dos redes NGNs esto se hace para tener una segunda visualizacin de los
mensajes SIP el cual no nos arroja ningn comportamiento que no est contemplado en RFC 3162.
Figura 5-4. Captura de traza de la sealizacin SIP de una llamada de Softswitch Vs Softswitch
5.3.6
Emulacin Trama SIP para el Comportamiento del Nodo Captura.
Al no encontrase ningn tipo de alteracin en la trama SIP para la interoperabilidad de redes NGNs
acudimos a un emulador de trama SIP (Sip Inspector) para probar el funcionamientos del Nodo Captura en
la deteccin y modificacin de parmetros adicionales o faltantes en su sealizacin SIP (RFC 3261).
76
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 mxima de los mensajes de SIP, la realidad es que
los proveedores a menudo imponen lmites 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 cdigos de respuesta especficos 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 autentificacin a un proxy. Ver anexo 7.1.
5.3.6.5 Parmetros TEL-URI
El problema de la interoperabilidad ms comn es en esta rea, es la colocacin de los parmetros TEL

URI, por ejemplo, el "tgrp" y "contexto tronco" parmetros del [RFC4904], y la "rn", "NPDI", y los
parmetros "CIC" a partir del [RFC4694]. El RFC 3261 seccin 19.1.6 est muy claro que todas las
caractersticas de la telefona de abonado, incluyendo los parmetros, se coloca en la parte de user-info de
una SIP URI. Por lo tanto los parmetros de Tel-URI se convierten en parmetros de usuario de SIP,
parmetros SIP URI no.
Se realiz la comprobacin de la simulacin de un TEL-URI a travs del Nodo Captura dando como
resulta un envo de mensajes SIP, transparente para las entidades emisor y receptor. Ver anexo 7.2.
5.3.6.6 Invite Reinvite (Subscribe)

Crea una invitacin al ser negada reenva la invitacin y no puede establecer una comunicacin por falta
de parmetros en el protocolo SDP, por ejemplo, que los dispositivos a enrutar las llamadas sobre la base
del cdec, o la asignacin de ancho de banda, o los dispositivos de transcodificacin que se envan no
estn de acuerdo con lo necesario.
77
Se simulo un escenario evitando este tipo de problemas de interoperabilidad, dando como resultado un
envo de sealizacin SIP xito. Ver Anexo 7.3
5.3.6.7 Valor De Cabecera PRACK

SIP ofrece un medio para indicar el uso de extensin, 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 extensin".
Se emulo el escenario anterior dando como resultado un envo de sealizacin 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 telefona IP y centros de llamada; como lo describimos en la seccin 2.3, los problemas de
interoperabilidad que se presenta a nivel de protocolo SIP y SDP se manifiesta en la integracin de una
plataforma de un fabricante de telefona IP caso especfico AVAYA con otro fabricante de telefona IP
genrico; se prob la solucin de software denominado NODO CAPTURA en la interoperabilidad de las
plataformas mencionadas anteriormente.
La plataforma AVAYA en la implementacin del protocolo de sealizacin SIP presenta una
implementacin adicional en el mensaje de peticin PRACK, este mensaje no permite la interoperabilidad
de este fabricante con otros dispositivos de hardware de otro fabricante, en la implementacin del NODO
CAPTURA para probar su funcionamiento el modifica la sealizacin 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 extensin, los fabricantes caso especfico 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 extensin".
78
5.5
MEDICIONES DE QOS
Se realiza una serie de protocolos de prueba para poder medir la QoS, en este caso especfico se evalu
Telefona IP. Para las pruebas se us como base la configuracin 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 comunicacin fue en ambos sentidos (ida y vuelta) y no se us ninguna tcnica de
supresin de silencios.
Telefona IP se clasifica como Clase de QoS 0. Tiene como lmite superior para los parmetros 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 transmisin [18].
Primer escenario: Se realiz una sola llamada IP, de Softswitch Vs Softswitch que tena como
propsito obtener una medida de referencia, lo que era factible porque las NGNs carecan de
cualquier otro tipo de trfico. 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 simultneas 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 simultneas veinte llamadas.
La tabla 5-1. Muestra los resultados obtenidos en las cuatro pruebas realizadas.
TELEFONIA IP (SIP)
1 Llamada Softswitch Vs Softswitch
Parametro Limite Superior
Medicin
Diferencia
IPTD (ms)
100
0,1185
-99,8815
IPDV (ms)
50
0,107
-49,893
IPLR (%)
1,00%
0,00%
-1,00%
IPER
0,001
0
-0,001
CLASE QoS
0
0
0
1 llamada Asterisk Vs Softswitch

Medicin
Diferencia
10,8085
-89,1915
1,224
-48,776
0,00%
-1,00%
0
-0,001
0
0
10 llamadas Softswitch Vs Softswitch

Medicin
Diferencia
11,514
-88,486
1,897
-48,103
0,00%
-1,00%
0
-0,001
0
0
20 llamadas Asterisk Vs Softswitch

Medicin
Diferencia
15,614
-84,386
1,809
-48,191
0,00%
-1,00%
0
-0,001
0
0
Tabla 5-1. Mediciones de QoS para llamadas telefnicas IP (Protocolo SIP)
79
A continuacin se hace una descripcin 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 lmite 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
NGNs solo estn disponibles nicamente para el trfico 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 medicin anterior, alrededor de 100 y 10 veces,
respectivamente, siguen estando muy por debajo de los lmites establecidos. Los otros dos parmetros
evaluados, IPLR e IPER, no cambian de un escenario a otro. Los resultados, son altamente favorables,
algo que obedece a una razn fundamental: El nico trfico 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 transmisin de la red NGN.
El tercer escenario las llamadas simultneas ocupan un ancho de banda de aproximadamente 300 kb/s. Si
se compara el IPTD y el IPDV obtenidos en esta medicin, con los presentados en el escenario anterior, de
una llamada IP nica, se encuentra que no hay mucha diferencia. La conclusin que surge de esta
observacin es que, en este tipo de redes, la variacin en el valor de los parmetros de IPTD e IPDV no
depende de la cantidad de llamadas simultneas, sino de disponibilidad.
En el cuarto escenario se puede comparar con el tercer escenario debido a que los valores estn por debajo
del lmite, con la premisa de que las redes NGNs se encuentran disponibles exclusivamente para estas
pruebas.
80
CONCLUSIONES
El tema de compartir servicios y aplicaciones en las redes NGN nos pone a pensar en una interconexin de
redes NGN con arquitectura Softswitch y en el caso especfico ZTE-PUJ y ANKLA, este proceso conlleva
una serie de metodologas de interconexin y parmetros a tener en cuenta como son: la seguridad, la
sealizacin, la capacidad de trfico entre otras; como estamos en una redes NGN netamente acadmicas
nos permite experimentar diferentes soluciones y realizar una serie de pruebas a nuestra disposicin.
La interconexin se culmin con xito dando as al cumplimiento del objetivo general y a los objetivos
especficos; Dndonos cuenta que no se encontraron problemas de interoperabilidad generados por la
sealizacin (protocolo SIP), pero esta situacin se implement de un Nodo Captura que fuera capaz de
analizar y modificar la sealizacin SIP.
La interconexin 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 implementacin con xito del Protocolo SIP/SDP mediante
una troncal SIP, para la transferencia de toda la sealizacin entre la dos redes NGN con arquitectura
Softswitch, para compartir todos los servicios con los que cada una de ellas cuenta.
Los diferentes anlisis que se realizaron a la sealizacin 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 composicin del protocolo SIP y llegado el caso realizar alguna
modificacin de la trama SIP, despus de toda la investigacin de la sealizacin SIP se lleg a la
conclusin que el protocolo SIP/SDP no presenta ninguna modificacin en sus estructuras de tramas en
ninguno de sus mensajes de peticin 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 anlisis y solucin de posibles errores encontrados en el protocolo SIP mediante la
simulacin.
Se prob la solucin del NODO CAPTURA en un escenario totalmente distinto, la interoperabilidad del
fabricante AVAYA con el fabricante genrico, 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 modificacin de la sealizacin del mensaje de
81
peticin PRACK, permito la interoperabilidad de este fabricante con otros dispositivos de VoIP de otro
fabricante genrico.
Por ltimo se realiz algunos anlisis de QoS en el funcionamiento de la troncal SIP, generando trfico
SIP de mltiples conexiones a travs del escenario de interoperabilidad montado, dando unos resultados
muy favorables como se muestra en la tabla 5-1.
Despus de todo el anlisis que se le realizo a la sealizacin 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 lnea de trabajo futura seria realizar pruebas de sealizacin de
peticiones en paralelo en uno o varias redes conjuntamente, para as demostrar la interoperabilidad de toda
una solucin de redes que manejas el protocolo SIP.
Tambin habra que desplegar esta aplicacin en un entorno NGN basado en arquitecturas IMS.
82
BIBLIOGRAFIA
LIBROS Y PUBLICACIONES
[1] Alan B. Johnston, Artech House telecommunications library, SIP Understanding the session initiation
protocol Second edition, 2004
[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. Medicin de calidad del servicio en redes de prxima generacin (NGN) en
Colombia, Entregables 1 a 4, Centro de Investigacin de las Telecomunicaciones CINTEL, 2012.
[6] DAZ, 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.
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
83
[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 3rdGeneration Partnership Project (3GPP), http://www.ietf.org/rfc/rfc3455.txt
[15] UIT-T (Unin Internacional de Telecomunicaciones, Estandarizacin); Iniciativa de normalizacin
mundial de las redes de la prxima generacin.
[16] UIT-T (Unin Internacional de Telecomunicaciones, Estandarizacin Y.1540, Servicio de
comunicacin de datos con protocolo Internet - Parmetros 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 (Unin Internacional de Telecomunicaciones / Sector de normalizacin de las
telecomunicaciones). Recomendacin 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 trfico (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 sealizacin SIP (Consultado Enero
2013).
[25] https://sites.google.com/site/sipinspectorsite/ Emulador de tramas SIP (Consultado enero 2013).
84
ANEXOS
Anexos adjuntos en un CD.
85
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
IPLR
IPTD
IP Transfer Delay
ITU
International Telecommunication Union
NGN
Next Generation Network
QoS
Quality of Service
86
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
87

MIRAR DEFINIR TEMA SanchezPachecoWilliamFernando2013

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MIRAR DEFINIR TEMA SanchezPachecoWilliamFernando2013

Загружено:

Авторское право:

Доступные форматы

DISEO E IMPLEMENTACIN DE UNA SOLUCIN DE INTERCONEXIN DE REDES NGN

MEDIANTE EL PROTOCOLO SIP

ING. WILLIAM FERNANDO SANCHEZ PACHECO

PONTIFICIA UNIVERSIDAD JAVERIANA

DISEO E IMPLEMENTACIN DE UNA SOLUCIN DE INTERCONEXIN DE REDES NGN

ING. WILLIAM FERNANDO SANCHEZ PACHECO

Trabajo de profundizacin para optar por el ttulo de

PONTIFICIA UNIVERSIDAD JAVERIANA

PONTIFICIA UNIVERSIDAD JAVERIANA

P. JOAQUN SNCHEZ GARCA S. J.

Ing. JORGE SANCHEZ, Ph.D.

DECANO DEL MEDIO UNIVERSITARIO:

P. SERGIO BERNAL RESTREPO S. J.

Ing. CESAR LEONARDO NIO. PH.D.

Bogot, Mayo de 2013

ARTCULO 23 DE LA RESOLUCIN No. 13 DE JUNIO DE 1946

Artculo 23 de la Resolucin No. 13, del 6 de julio de 1946,

Agradezco a mi mam, a mis hermanos

William Fernando Snchez Pacheco

MARCO TEORICO ....................................................................................................................... 16

REDES DE NUEVA GENERACION (NGN)......................................................................... 16

Componentes de las redes NGN. ..................................................................................... 17

Caractersticas de las redes NGN..................................................................................... 18

Servicios y aplicaciones de las redes NGN ...................................................................... 20

Servicios de las redes NGN ..................................................................................... 20

Aplicaciones de las redes NGN................................................................................ 21

Arquitectura de Softswitch/MGC .................................................................................... 21

Arquitectura IMS/MGC .................................................................................................. 23

PROTOCOLO SIP (SESSION INITIATION PROTOCOL) ................................................... 27

Componentes de SIP ....................................................................................................... 29

Extensiones del Protocolo SIP ................................................................................. 31

Estructuras e mensajes. ............................................................................................ 32

Cabecera SIP .................................................................................................................. 34

Cuerpo de los mensajes SIP (protocolo de descripcin de la sesin SDP) ........................ 36

PROBLEMAS GENERALES DE INTEROPERABILIDAD .................................................. 37

Problemas especficos de interconexin del protocolo SIP ............................................... 38

Problemas especficos de interconexin del protocolo SIP e SDP .................................... 39

Red NGN ZTE-PUJ ............................................................................................................ 42

Red NGN ANKLA ............................................................................................................. 43

Infraestructura de Interconexin redes NGNs. .................................................................... 44

Nodo Captura .............................................................................................................. 44

Simulador trama SIP ................................................................................................... 47

ANLISIS DEL PROTOCOLO SIP. ...................................................................................... 48

Anlisis del protocolo SIP ZTE-PUJ ............................................................................... 48

Anlisis del protocolo SIP ANKLA................................................................................. 54

Comparacin de las dos redes NGNs ............................................................................. 59

PRUEBAS DE INTEROPERABILIDAD ............................................................................... 59

Escenario de interoperabilidad ZTE-ANKLA .................................................................. 59

VPN y sus caractersticas de interoperabilidad................................................................. 65

VPN Sitio a Sitio utilizando NAT................................................................................ 66

Seguridad VPN IPSec ................................................................................................. 66

METODOLOGA DE ANLISIS DE INTEROPERABILIDAD............................................ 67

Identificacin y reconocimiento ...................................................................................... 68

Llamada Simple Entre Dispositivos IP A Travs De Troncal SIP ................................. 69

Llamada Simple Entre Dispositivos IP hacia el servidor de aplicaciones ...................... 70

Integracin Nodo Captura y Generador de Trfico .......................................................... 71

Emulacin de la trama SIP y Nodo Captura. .................................................................... 72

ANALISIS DE RESULTADOS ..................................................................................................... 73

CARACTERIZACION NODO CAPTURA ............................................................................ 73

Descripcin del funcionamiento Nodo Captura................................................................ 73

Caractersticas del hardware Nodo Captura ..................................................................... 74

Anlisis Nodo Captura .................................................................................................... 74

Emulacin Trama SIP para el Comportamiento del Nodo Captura. .................................. 76

SIP campo y longitudes mensaje Proxy SIP. ................................................................ 77