MIRAR DEFINIR TEMA SanchezPachecoWilliamFernando2013

174
DISEÑO E IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTERCONEXIÓN DE REDES NGN MEDIANTE EL PROTOCOLO SIP ING. WILLIAM FERNANDO SANCHEZ PACHECO PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA DEPARTAMENTO DE ELECTRÓNICA BOGOTÁ D.C. MAYO DE 2013

description

dacsacz

Transcript of 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

  • 2

    DISEO E IMPLEMENTACIN DE UNA SOLUCIN DE INTERCONEXIN DE REDES NGN

    MEDIANTE EL PROTOCOLO SIP

    ING. WILLIAM FERNANDO SANCHEZ PACHECO

    Trabajo de profundizacin para optar por el ttulo de

    Magister en Ingeniera Electrnica

    Director:

    LUIS CARLOS TRUJILLO ARBOLEDA

    Ingeniero Electrnico, M.Sc.

    PONTIFICIA UNIVERSIDAD JAVERIANA

    FACULTAD DE INGENIERA

    DEPARTAMENTO DE ELECTRNICA

    BOGOT D.C.

    MAYO DE 2013

  • 3

    PONTIFICIA UNIVERSIDAD JAVERIANA

    FACULTAD DE INGENIERA

    DEPARTAMENTO DE ELECTRNICA

    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: Ing. CESAR LEONARDO NIO. PH.D.

    DIRECTOR DEL TRABAJO DE GRADO: Ing. LUIS CARLOS TRUJILLO ARBOLEDA, MSc.

  • 4

    NOTA DE ACEPTACIN

    Nota de aceptacin

    ______________________

    ______________________

    ______________________

    _____________________

    Presidente del Jurado

    _____________________

    Jurado

    _____________________

    Jurado

    Bogot, Mayo de 2013

  • 5

    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.

  • 6

    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

  • 7

    TABLA DE CONTENIDO

    1. INTRODUCCION ......................................................................................................................... 14

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

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

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

    2.1.2. 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. 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

    3. 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

    4 DESARROLLOS. .......................................................................................................................... 48

  • 8

    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

    5 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

    6 CONCLUSIONES ......................................................................................................................... 81

    7 BIBLIOGRAFIA ........................................................................................................................... 83

  • 9

    8 ANEXOS ....................................................................................................................................... 85

    ACRONIMOS ....................................................................................................................................... 86

  • 10

    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

  • 11

    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

  • 12

    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

  • 13

    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.

  • 14

    1. INTRODUCCION

    En el contexto actual y mundial del sector de las telecomunicaciones, la voz y los datos como redes

    independientes, han dejado de ser la fuente de ingresos 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 Laboratorio

    1 Redes de Nueva Generacin

    2 Instituto Europeo de Normas de Telecomunicaciones

    3 Telecomunicaciones e Internet Servicios convergentes y protocolos de red avanzada

  • 15

    ANKLA). El desarrollo se bas en cuatro partes (la 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.

  • 16

    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].

  • 17

    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.

    4 Tomado de Diseo de polticas ptimas en un entorno de convergencia de los medios de comunicacin y las telecomunicaciones

    OSIPTEL

  • 18

    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

    5 Tomado de Telefnica, 2006 6 Tomado de UIT Y.2011

  • 19

    En primer lugar, hay un conjunto de funciones de transporte que se encargan nicamente del transporte de

    la 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.

  • 20

    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.

  • 21

    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

  • 22

    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.

    7 Tomado de RIOS, Javier y GARCIA, Moraima, Softswitch, febrero 2004

  • 23

    SERVICE INTERFACE: Proporciona soporte para servicios suplementarios y clases de

    servicios. Posee una arquitectura independiente de 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

    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.

    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

    8 3rd Generation Partnership Project es una colaboracin de grupos de asociaciones de telecomunicaciones.

  • 24

    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.

    9 Tomado de www.3gpp.org/

  • 25

    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 que necesitan

    interfuncionamiento (bajo la perspectiva de trfico) entre la STFC y la red IMS.

  • 26

    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

  • 27

    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).

  • 28

    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].

  • 29

    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

  • 30

    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.

  • 31

    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.

  • 32

    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:

    Es uno de los tipos de solicitudes SIP

    Es el URL SIP u otro tipo de URL de la entidad que debera recibir el mensaje.

    Es actualmente SIP/2.0

    A continuacin algunos ejemplos:

    INVITE sip:[email protected] SIP/2.0

    ACK sip:[email protected];user=phone SIP/2.0

    BYE tel:+1-408-555-1212;postd=p4199 SIP/2.0

    2.2.3. Mensajes de Respuesta

    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:

  • 33

    actualmente es SIP/2.0

    y se establecen a uno de los pares de los cdigo de Respuesta SIP

    A continuacin algunos ejemplos:

    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].

  • 34

    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:

    :

    se los enumera en la tabla 3

    una o ms lneas de informacin.

    continuacin de la cabecera multilnea.

    CODIGO DESCRIPCIN DE LA RESPUESTA CODIGO DESCRIPCIN DE LA RESPUESTA

    1XX INFORMACION 420 Extensin errnea

    100 Intentando 421 Extensin requerida

    180 Ringing 422 Sesin del temporizador de intervalos demasiado pequeo

    181 La llamada est remitindose 423 Intervalo demasiado corto

    182 En Cola 428 Utilice token de autenticacin

    183 Progreso de la sesin 429 Proporcionar identidad REFER

    2XX SUCESOS 480 No disponible temporalmente

    200 OK 481 Circuito de llamada o transaccin no existe

    202 Aceptado 482 Detectado un bucle

    3XX REDIRECCION 483 Demasiados saltos

    300 Opciones mltiples 484 Direccin incompleta

    301 Movido permanentemente 485 Ambiguo

    302 Movido temporal 486 Ocupado aqu

    305 Utilizar proxy 487 Solicitud terminada

    380 Servicio Alternativo 488 No aceptable aqu

    4XX ERROR DEL CLIENTE 489 Terminacin de evento

    400 Respuesta mala 491 Solicitud pendiente

    401 Sin autorizacion 493 Solicitar indescifrable

    402 Pago requerido 5XX ERROR DEL SERVIDOR

    403 Prohibido 500 Error al interior del servidor

    404 No encontrado 501 No implementado

    405 Mtodo no permitido 502 Gateway errneo

    406 No aceptable 503 Servicio no disponible

    407 Se requiete autenticacin de Proxy 504 Lmite de tiempo del gateway

    408 Se requiere lmite de tiempo 505 Versin de SIP no soportada

    409 Conflicto 513 Mensaje demasiado grande

    410 Hecho 6XX ERROR GLOBAL

    411 Longitud requerida 600 Ocupado completamente

    413 Entidad solicitada demasiado grande 603 Declinar

    414 Solicitud-URI demasiado grande 604 No existe en ninguna parte

    415 Tipo de medio no soportado 606 No aceptable

    416 Esquema URI no soportado

  • 35

    A continuacin algunos ejemplos:

    From: sip:[email protected]

    User-Agent: Cisco VoIP Gateway / IOS12.x / SIP enable

    Content-Type: application / sdp

    La siguiente tabla muestra las cabeceras SIP las mismas que se organizan en cuatro grupos 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.

    Tabla 2-4. Abreviaturas de Nombre de Cabecera [1] [10].

    NOMBRE DE CABECERA COMPLETO NOMBRE DE CABECERA ABREVIADO

    Call-ID i

    Contact m

    Content-Encoding e

    Content-Length l

    Content-Type c

    From f

    Subject s

    To t

    Via v

  • 36

    2.2.5. Cuerpo de los mensajes SIP (protocolo de 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

    Tabla 2-5. Atributos de SDP [12]

    TIPO SDP DESCRIPCION

    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

    Una o ms descripciones horarias

    z= *Ajustes de zona horaria

    k= *Clave de encriptacin

    a= *Ninguna o ms lneas de atributos de sesin

    *Ninguna o ms descripciones de los medios

    t= Tiempo en que la sesin est activa

    r= *Cero o ms repeticiones

    m= Nombre de los medios y direccin del transporte

    i= *Ttulo de los medios

    c= *Informacin de la conexin

    b= *Informacin del ancho de banda

    k= *Clave de encriptacin

    a= *Ninguna o ms lneas de atributo

    DESCRIPCION DE SESION

    DESCRIPCION DEL TIEMPO

    DESCRIPCION DE MEDIOS

    NOTA: *son opcionales

  • 37

    2.3. PROBLEMAS GENERALES DE INTEROPERABILIDAD

    Los problemas de interoperabilidad de las redes 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)

  • 38

    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.

  • 39

    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.

  • 40

    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.

  • 41

    -

    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.

    Figura 3-2. Arquitectura bsica de interconexin las diferentes redes NGNs.

    12 Tomado de Introduccin a los Protocolos NGN (ZTE)

    Red NGN (Centro de Tecnologas de

    Telecomunicaciones ZTE-PUJ)

    Pontificia Universidad Javeriana

    Red NGN (Laboratorio ANKLA)

    CINTEL

  • 42

    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

  • 43

    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).

    o Interrogating Call Sessin Control Function (I-CSCF).

  • 44

    o Serving Call Sessin Control Function (S-CSCF).

    o Home Subscriber Server (HSS).

    o Servidores de aplicaciones SIP (SIP AS).

    Figura 3-4. Arquitectura ANKLA14

    3.3 Infraestructura de 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

  • 45

    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/

  • 46

    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.

  • 47

    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.

  • 48

    4 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.

  • 49

    Figura 4-1. Comunicacin bsica del protocolo SIP de la red NGN ZTE-PUJ

    Estructura de un mensaje INVITE

    INVITE sip:[email protected] SIP/2.0

    Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a

    To: "102"

    From: "103";tag=884a420a-7062206315162668

    Call-ID: 072a13acfdc2669-884a420a@ 172.22.0.54

    CSeq: 23944 INVITE

    Contact:

    Max-Forwards: 70

    User-Agent: ZTE MULTIMEDIA SIPPHONE/V1.0 04-01-10

    Content-Type: application/sdp

    Content-Length: 288

    v=0

    o=1033608424475 IN IP4 10.66.74.136

    s=session SDP

  • 50

    c=IN IP4 172.22.034

    t=0 0

    m=audio 10000 RTP/AVP 0 4 8 18

    a=ptime:20

    a=rtpmap:0 PCMU/8000

    a=rtpmap:4 G723/8000

    a=rtpmap:8 PCMA/8000

    a=rtpmap:18 G729/8000

    m=video 10002 RTP/AVP 34

    a=rtpmap:34 H263/90000

    NOTA: en la estructura el mensaje invite no se encuentra 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

    Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a

    To:"102";tag=a290601-31939

    From:"103";tag=884a420a-7062206315162668

    Call-ID: [email protected]

    CSeq: 23944 INVITE

    Contact:

    Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE

    User-Agent: ZTE Softswitch/1.0.0

    Content-Type: application/sdp

    Content-Length: 115

  • 51

    v=0

    o= ERICSSON 32 32 IN IP4 10.41.6.1

    s=phone-call

    c=IN IP4 172.22.0.34

    t=0 0

    m=audio 4006 RTP/AVP 0

    a=ptime:20

    NOTA: en la estructura el mensaje 183RING no se encuentra 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

    Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a

    To:"102";tag=a290601-31939

    From:"103";tag=884a420a-7062206315162668

    Call-ID: [email protected]

    CSeq: 23944 INVITE

    Contact:

    Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE

    Record-Route:

    User-Agent: ZTE Softswitch/1.0.0

    Content-Type: application/sdp

    Content-Length: 115

    v=0

    o= ZTE 32 32 IN IP4 172.22.0.34

  • 52

    s=phone-call

    c=IN IP4 10.52.31.237

    t=0 0

    m=audio 4006 RTP/AVP 0

    a=ptime:20

    NOTA: en la estructura el mensaje 200 OK no se encuentra ningn tipo de modificacin o adicional en la

    estructura de su trama de sealizacin segn el RFC 3261.

    Estructura de un mensaje ACK

    ACK sip:172.22.0.34;lr SIP/2.0

    Via: SIP/2.0/UDP 172.22.0.54:5060;branch=z9hG4bK3af571e7266a

    To: "102"

    From: "103";tag=884a420a-7062206315162668

    Call-ID: [email protected]

    CSeq: 23944 ACK

    Contact:

    Max-Forwards: 70

    Route:

    NOTA: en la estructura el mensaje ACK 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 BYE

    BYE sip:[email protected]:5060 SIP/2.0

    Via: SIP/2.0/UDP 172.22.0.34:5060;branch=776249e9.0

    Via: SIP/2.0/UDP 172.22.0.34:5060;branch=4dcf5bd7

    To: 103";tag=884a420a-7062206315162668

  • 53

    From: "102";tag=a290601-31939

    Call-ID: [email protected]

    CSeq: 18927 BYE

    Max-Forwards: 69

    User-Agent: ZTE Softswitch/1.0.0

    Content-Length: 0

    NOTA: en la estructura el mensaje BYE no se encuentra ningn tipo de modificacin o adicional en la

    estructura de su trama de sealizacin segn el RFC 3261.

    Estructura de 200 OK

    SIP/2.0 200 OK

    Via: SIP/2.0/UDP 172.22.0.34:5060;branch=776249e9.0

    Via: SIP/2.0/UDP 172.22.0.34:5060;branch=4dcf5bd7

    To: "#0*109316";tag=884a420a-7062206315162668

    From: "0755526778086";tag=a290601-31939

    Call-ID: [email protected]

    CSeq: 18927 BYE

    Max-Forwards: 69

    NOTA: en la estructura el mensaje 200 OK no se encuentra ningn tipo de modificacin o adicional en la

    estructura de su trama de sealizacin segn el RFC 3261.

    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.

  • 54

    4.3.4 Anlisis del protocolo SIP ANKLA

    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 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

    Estructura de un mensaje INVITE

    INVITE sip:[email protected] SIP/2.0

    Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a

    To: "0755526778086"

    From: "#0*109316";tag=884a420a-7062206315162668

    Call-ID: [email protected]

    CSeq: 23944 INVITE

    Contact:

    Max-Forwards: 70

    User-Agent: ERICSSON MULTIMEDIA SIPPHONE/V1.0 04-01-10

    Content-Type: application/sdp

  • 55

    Content-Length: 288

    v=0

    o=#0*109316 3507761179 3608424475 IN IP4 10.66.74.136

    s=session SDP

    c=IN IP4 10.66.74.136

    t=0 0

    m=audio 10000 RTP/AVP 0 4 8 18

    a=ptime:20

    a=rtpmap:0 PCMU/8000

    a=rtpmap:4 G723/8000

    a=rtpmap:8 PCMA/8000

    a=rtpmap:18 G729/8000

    m=video 10002 RTP/AVP 34

    a=rtpmap:34 H263/90000

    NOTA: en la estructura el mensaje INVITE no se encuentra 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

    Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a

    To:"0755526778086";tag=a290601-31939

    From:"#0*109316";tag=884a420a-7062206315162668

    Call-ID: [email protected]

    CSeq: 23944 INVITE

    Contact:

  • 56

    Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE

    User-Agent: ERICSSON Softswitch/1.0.0

    Content-Type: application/sdp

    Content-Length: 115

    v=0

    o= ERICSSON 32 32 IN IP4 10.41.6.1

    s=phone-call

    c=IN IP4 10.52.31.237

    t=0 0

    m=audio 4006 RTP/AVP 0

    a=ptime:20

    NOTA: en la estructura el mensaje 183 RING no se encuentra 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

    Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a

    To:"0755526778086";tag=a290601-31939

    From:"#0*109316";tag=884a420a-7062206315162668

    Call-ID: [email protected]

    CSeq: 23944 INVITE

    Contact:

    Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,UPDATE

    Record-Route:

    User-Agent: ERICSSON Softswitch/1.0.0

  • 57

    Content-Type: application/sdp

    Content-Length: 115

    v=0

    o= ERICSSON 32 32 IN IP4 10.41.6.1

    s=phone-call

    c=IN IP4 10.52.31.237

    t=0 0

    m=audio 4006 RTP/AVP 0

    a=ptime:20

    NOTA: en la estructura el mensaje 200 OK no se encuentra ningn tipo de modificacin o adicional en la

    estructura de su trama de sealizacin segn el RFC 3261.

    Estructura de un mensaje ACK

    ACK sip:10.41.6.1;lr SIP/2.0

    Via: SIP/2.0/UDP 10.66.74.136:5060;branch=z9hG4bK3af571e7266a

    To: "0755526778086"

    From: "#0*109316";tag=884a420a-7062206315162668

    Call-ID: [email protected]

    CSeq: 23944 ACK

    Contact:

    Max-Forwards: 70

    Route:

    NOTA: en la estructura el mensaje ACK 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 BYE

  • 58

    BYE sip:#0*[email protected]:5060 SIP/2.0

    Via: SIP/2.0/UDP 10.41.6.1:5060;branch=776249e9.0

    Via: SIP/2.0/UDP 10.52.31.237:5060;branch=4dcf5bd7

    To: "#0*109316";tag=884a420a-7062206315162668

    From: "0755526778086";tag=a290601-31939

    Call-ID: [email protected]

    CSeq: 18927 BYE

    Max-Forwards: 69

    User-Agent: ERICSSON Softswitch/1.0.0

    Content-Length: 0

    NOTA: en la estructura el mensaje BYE no se encuentra ningn tipo de modificacin o adicional en la

    estructura de su trama de sealizacin segn el RFC 3261.

    Estructura de 200 OK

    SIP/2.0 200 OK

    Via: SIP/2.0/UDP 10.41.6.1:5060;branch=776249e9.0

    Via: SIP/2.0/UDP 10.52.31.237:5060;branch=4dcf5bd7

    To: "#0*109316";tag=884a420a-7062206315162668

    From: "0755526778086";tag=a290601-31939

    Call-ID: [email protected]

    CSeq: 18927 BYE

    Max-Forwards: 69

    NOTA: en la estructura el mensaje 200 OK no se encuentra ningn tipo de modificacin o adicional en la

    estructura de su trama de sealizacin segn el RFC 3261.

  • 59

    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.

  • 60

    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.

  • 61

    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 telfo