INTEGRACIÓN DEL EQUIPO PASARELA DE MEDIOS UNIVERSAL

TRABAJO ESPECIAL DE GRADO

INTEGRACIÓN DEL EQUIPO PASARELA DE MEDIOS UNIVERSAL (UNIVERSAL MEDIA GATEWAY) A LA

ARQUITECTURA DE RED NGN DE CANTV.

Presentado ante la ilustre Universidad Central de Venezuela

Por el Br. Domenico W. Didonna Millán para optar al Título de Ingeniero Electricista

Caracas, 2016

TRABAJO ESPECIAL DE GRADO



Prof. Guía: Ing. María Lejed. Tutor Industrial: Ing. Miguel Zambrano.

Presentado ante la Ilustre Universidad Central de Venezuela

por el Br. Domenico W. Didonna Millán para optar al Título de Ingeniero Electricista.

Caracas, 2016

iii

iv

DEDICATORIA

A Dios, que me ha dado vida, salud y me guía a diario para que no me desvíe

del camino. A mi nonno que en paz descanse, que fue una gran influencia en mi vida,

un hombre tierno, amoroso y gentil que siempre tuvo una sonrisa para mí y que con

su historia de vida siempre me inspira y me da motivos para sentirme orgulloso.

A mis padres, que siempre me apoyaron y fueron pacientes en este largo

camino dándome ánimos y motivándome en esos momentos difíciles.

A mis hermanos, son ejemplos a seguir como estudiantes y profesionales y no

son solo hermanos, son amigos y compañeros dispuestos a tenderme una mano

cuando la necesito.

v

RECONOCIMIENTOS Y AGRADECIMIENTOS.

Agradezco a Dios, porque sin Él nada puedo. Por las bendiciones que derrama

sobre mí a diario y porque me lleva de su mano, en todo momento.

A mi madre Nubia Millán, que siempre me enseñó valores, me aconsejó y me

guió por el camino del bien y sobretodo porque me ama y me lo demuestra cada día

de mi vida. A mi padre Vitangelo Didonna, que siempre tuvo un consejo cuando me

veía decaído, por su ayuda, su disposición y la motivación que siempre me dio,

creyendo en mí aun cuando yo no lo hice.

A Giovanni Didonna, mi hermano y mi amigo, hombre al que admiro por su

bondad y su corazón generoso, gracias por estar ahí. A Karina Didonna, mi hermana

y mi amore, mi amiga que siempre estuvo a mi lado y que siempre quiere lo mejor

para mí. A Andreína Rodríguez, mi cuñada favorita porque siempre tiene una sonrisa

que contagia alegría y por ser una hermana mas y una gran bendición en la familia.

A José Gámez, Iuliam Gutiérrez, Oscar Oyarzabal, Jorge Flores, Erick

Sequera, Charli Crespo y Alejandra Moros mis amigos cercanos, mi familia. Sin ellos

no hubiera sido posible lograrlo.

A María Auxiliadora que siempre estuvo dispuesta a prestar su ayuda,

aconsejándome y regañándome cuando fue necesario. A mis maestros por sus

enseñanzas.

vi

Domenico W. Didonna Millán.



Profesor guía: Ing. María Lejed. Tutor industrial: Ing. Miguel Zambrano. Tesis.

Caracas. U.C.V. Facultad de Ingeniería. Escuela de Ingeniería Eléctrica.

Ingeniero Electricista. Opción: Comunicaciones. CANTV. 2015.

Palabras claves: VoIP, CANTV, UMG, SS7, SIP, NGN, IP.

Resumen. CANTV se plantea la incorporación del equipo Pasarela de Medios Universal (UMG: Universal Media Gateway) para ofrecer el servicio de VoIP (VoIP a sus clientes; teniendo como objetivo la propuesta y prueba del equipo en la red, al igual que realizar un protocolo de pruebas que sirva como guía para el equipo técnico al momento de realizar la puesta en marcha de este servicio, permitiendo verificar que el equipo realice sus funciones de manera correcta y así evaluar las ventajas que ofrece el mismo a la red, para que el servicio se preste de manera efectiva y segura.

Para lograr los objetivos planteados se realizó primero una investigación documental para evaluar las opciones y luego realizar una propuesta de arquitectura de red para el servicio. Una vez que se tuvieron todos los elementos de la red conectados, se procedió a realizar el protocolo de pruebas evaluando las funciones que debe realizar el equipo y verificando que las mismas fueran ejecutadas de manera correcta.

Se obtuvo como resultado una arquitectura de red para el servicio y un protocolo de pruebas enfocados en el UMG, lo que permitió evaluar el funcionamiento del equipo en la red y obtener las ventajas en funcionalidad que nos brinda el equipo; concluyendo que es un equipo que se ajusta a las necesidades de la red para el servicio de voz sobre IP.

vii

ÍNDICE GENERAL.

INTRODUCCIÓN. ....................................................................................................... 1

CAPÍTULO I. ................................................................................................................ 2

1.- PLANTEAMIENTO DEL PROBLEMA. ............................................................... 2

1.1.- Planteamiento del problema. ............................................................................. 2

1.2. OBJETIVOS. ...................................................................................................... 3

1.2.1.- Objetivo General. ....................................................................................... 3

1.2.2.- Objetivos Específicos. ................................................................................ 3

1.3.- LIMITACIONES. ............................................................................................. 3

CAPÍTULO II. .............................................................................................................. 4

2.- MARCO TEÓRICO. ............................................................................................... 4

2.1.- Red Pública de Telefonía Conmutada. .............................................................. 4

2.1.1.- Elementos que componen la red PSTN. ..................................................... 4

2.1.1.1.- Conmutación. ....................................................................................... 4

2.1.1.2.- Señalización. ........................................................................................ 4

2.1.1.3.- Transmisión. ........................................................................................ 5

2.1.1.4.- Gestión. ................................................................................................ 5

2.1.1.5.- Datos. ................................................................................................... 5

2.1.1.6.- Equipos terminales. .............................................................................. 5

2.1.1.7.- Servicios. ............................................................................................. 5

2.1.2.- Señalización MFC-R2. ............................................................................... 6

2.1.3.- Señalización SS7. ....................................................................................... 6

2.1.3.1.- Punto de Conmutación de Servicio (Service Switching Point). .......... 7

2.1.3.2.- Punto de Transferencia de Señal (Signal Transfer Point). ................... 7

2.1.3.3.- Punto de Control de Servicio (Service Control Point). ........................ 7

2.2.- Voz sobre IP. ..................................................................................................... 7

viii

2.2.1.- Protocolos de VoIP. .................................................................................... 8

2.2.1.1.- Protocolo de Iniciación de Sesión (SIP: Session Initiation Protocol). . 8

2.2.1.1.1.- Mensajes SIP. ................................................................................ 9

2.2.1.1.2.- Troncal SIP. ................................................................................ 10

2.2.1.2.- H.323. ................................................................................................ 10

2.2.1.3.- H.248/MEGACO. .............................................................................. 11

2.2.1.4. - RTP (Real-time Transport Protocol) / RTCP. .................................. 12

2.2.1.5.- Protocolo de Descripción de Sesión (SDP: Session Description Protocol). .......................................................................................................... 12

2.2.1.6.- UIT-T G.711. ..................................................................................... 13

2.2.1.7.- UIT-T G723.1. ................................................................................... 13

2.2.1.8.- UIT-T G 729. ..................................................................................... 13

2.2.1.9.- Calidad de Servicio (QoS: Quality of Service). ................................. 14

2.3.- Normativas asociadas a voz sobre IP. ............................................................. 15

2.4.- Redes de Próxima Generación (NGN: Next Generation Network). ............... 15

2.4.1.- Elementos que conforman una red NGN.................................................. 16

2.4.1.1.- Controlador de Pasarela de Medios MGC (SoftSwitch). ................... 16

2.4.1.2.- ATA o teléfonos IP. ........................................................................... 16

2.4.1.3.- Controlador de Sesión de Borde (SBC: Session Border Controller). 17

2.4.1.4. – Pasarela de medios “Media Gateway”. ............................................ 17

2.4.1.5.- Pasarela de Señalización “Signaling Gateway”. ................................ 17

2.5.- Red MetroEthernet. ......................................................................................... 18

2.5.1.- Multiprotocol Label Switching. (MPLS). ................................................ 18

2.5.2.- Servicios de LAN Privada Virtual (VPLS: Virtual Private LAN Services). ............................................................................................................................. 19

2.5.3.- Virtual LAN (VLAN). ............................................................................... 19

2.5.4.- Red Privada Virtual (VPN: Virtual Private Network). ............................. 19

CAPÍTULO III. ........................................................................................................... 20

3.- METODOLOGÍA. ................................................................................................. 20

3.1.- Fase I. .............................................................................................................. 20

ix

3.2.- Fase II. ............................................................................................................. 20

3.3.- Fase III ............................................................................................................ 20

3.4.- Fase IV. ........................................................................................................... 21

CAPITULO IV. ........................................................................................................... 22

4.-PROPUESTA DE INCORPORACIÓN DEL EQUIPO UMG Y CONFIGURACIÓN DE LA RED NGN DE CANTV. .............................................. 22

4.1.- Arquitectura de la red NGN de CANTV. ....................................................... 22

4.1.1.- Capa de Control. ....................................................................................... 22

4.1.2.- Capa de Acceso. ....................................................................................... 22

4.1.3.- Capa de Distribución. ............................................................................... 23

4.2.- Arquitectura de la red de CANTV con la incorporación del equipo UMG para el servicio de voz sobre IP (VoIP). .......................................................................... 24

4.3.- Terminales empleados durante las pruebas. .................................................... 29

4.4.- Funciones de procesamiento de voz y codificadores. ..................................... 30

4.4.1.- Soporte de codificador G.711A ................................................................ 30

4.4.2.- Soporte del codificador G.723. ................................................................. 31

4.4.3.- Soporte de codificador G.729. .................................................................. 33

CAPÍTULO V. ............................................................................................................ 35

5.- PROTOCOLO DE PRUEBAS DE LA RED ENFOCADO EN EL UMG. .......... 35

5.1.- Protocolo de pruebas utilizado en la red NGN de CANTV para el servicio de voz sobre IP. ............................................................................................................ 35

5.1.1.- Prueba de interconexión y control (H.248) entre el equipo UMG 8900 SS160 y el controlador MGC MSoftX3000. ....................................................... 35

5.1.2.- Prueba de interacción y monitoreo constante (Heartbeat) entre el UMG 8900 SS160 y el MGC MSoftX3000. .................................................................. 35

5.1.3.- Pruebas de llamadas completadas de manera exitosa. .............................. 36

5.1.4.- Pruebas de llamadas no atendidas. ........................................................... 37

5.1.5.- Pruebas de llamadas con la línea ocupada. ............................................... 37

5.1.6.- Pruebas de llamadas en las que el usuario que es llamado cuelga. .......... 38

CAPÍTULO VI. ........................................................................................................... 39

6.- ANÁLISIS Y DISCUSIÓN DE RESULTADOS. ................................................. 39

x

6.1.- Resultado de las pruebas del protocolo. .......................................................... 39

6.1.1.- Pruebas de la red. ...................................................................................... 40

6.1.1.1.- Prueba de interconexión y control del UMG 8900 SSM160 y el MGC MSoftX3000. .................................................................................................... 40

6.1.1.2.-Prueba de interacción y monitoreo entre el UMG 8900 SSM160 y el MGC MSoftX3000. ......................................................................................... 40

6.1.2.- Pruebas de llamadas entre terminales usando el UMG 8900 SSM 160 como tándem. ....................................................................................................... 41

6.1.2.1.- Prueba de llamada entre terminales con señalización R2, completada y colgada por el usuario que inicia la llamada. ................................................ 41

6.1.2.2.- Prueba de llamada entre terminales con señalización SIP, completada y colgada por el usuario que inicia la llamada. ................................................ 43

6.1.2.3.- Prueba de llamada entre terminales con señalización SS7, completada y colgada por el usuario que inicia la llamada. ................................................ 43

6.1.2.4.- Prueba de llamada entre terminales con señalización SS7 y SIP, completada y colgada por el usuario que inicia la llamada (SS7).................... 44

6.1.2.5.- Prueba de llamada entre terminales con señalización SS7 y R2, completada y colgada por el usuario que inicia la llamada (SS7).................... 45

6.1.2.6.- Prueba de llamada entre terminales con señalización SIP y R2, completada y colgada por el usuario que inicia la llamada (SIP). ................... 46

6.1.2.7.- Prueba de llamada entre terminales con señalización SIP y SS7, completada y colgada por el usuario que inicia la llamada (SIP). ................... 47

6.1.2.8.- Prueba de llamada entre terminales con señalización R2 y SS7, completada y colgada por el usuario que inicia la llamada (R2). .................... 47

6.1.2.9.- Prueba de llamada entre terminales con señalización R2 y SIP, completada y colgada por el usuario que inicia la llamada (R2). .................... 48

6.1.2.10.- Prueba de llamadas entre terminales con señalización R2, en las que el usuario llamado no atiende. .......................................................................... 48

6.1.2.11.- Prueba de llamadas entre terminales con señalización SS7, en las que el usuario llamado no atiende. ................................................................... 48

6.1.2.12.- Prueba de llamadas entre terminales con señalización SIP, en las que el usuario llamado no atiende. .......................................................................... 49

xi

6.1.2.13.- Prueba de llamada entre terminales con señalización SS7 y SIP, el usuario llamado (SIP) no atiende. .................................................................... 49

6.1.2.14.- Prueba de llamada entre terminales con señalización SS7 y R2, el usuario llamado (R2) no atiende. ..................................................................... 50

6.1.2.15.- Prueba de llamada entre terminales con señalización SIP y R2, el usuario llamado (R2) no atiende. ..................................................................... 50

6.1.2.16.- Prueba de llamada entre terminales con señalización SIP y SS7, el usuario llamado (SIP) no atiende. .................................................................... 50

6.1.2.17.- Prueba de llamada entre terminales con señalización R2 y SS7, el usuario llamado (SS7) no atiende. ................................................................... 51

6.1.2.18.- Prueba de llamada entre terminales con señalización R2 y SIP, el usuario llamado (SIP) no atiende. .................................................................... 51

6.1.2.19.- Prueba de llamada entre terminales con señalización R2, el usuario al que se está llamando está ocupado. .............................................................. 51

6.1.2.20.- Prueba de llamada entre terminales con señalización SS7, el usuario al que se está llamando está ocupado. .............................................................. 51

6.1.2.21.- Prueba de llamada entre terminales con señalización SIP, el usuario al que se está llamando está ocupado. .............................................................. 52

6.1.2.22.- Prueba de llamada entre terminales con señalización SS7 y SIP, el usuario llamado (SIP) está ocupado. ................................................................ 52

6.1.2.23.- Prueba de llamada entre terminales con señalización SS7 y R2, el usuario llamado (R2) está ocupado. ................................................................. 53

6.1.2.24.- Prueba de llamada entre terminales con señalización SIP y R2, el usuario llamado (R2) está ocupado. ................................................................. 53

6.1.2.25.- Prueba de llamada entre terminales con señalización SIP y SS7, el usuario llamado (SS7) está ocupado. ............................................................... 53

6.1.2.26.- Prueba de llamada entre terminales con señalización R2 y SS7, el usuario llamado (SS7) está ocupado. ............................................................... 54

6.1.2.27.- Prueba de llamada entre terminales con señalización R2 y SIP, el usuario llamado (SIP) está ocupado. ................................................................ 54

6.1.2.28.- Prueba de llamada entre terminales con señalización R2, completada y donde cuelga el usuario que es llamado. ....................................................... 54

6.1.2.29.- Prueba de llamada entre terminales con señalización SIP, completada y donde cuelga el usuario que es llamado. ................................... 54

xii

6.1.2.30.- Prueba de llamada entre terminales con señalización SS7, completada y donde cuelga el usuario que es llamado. ................................... 55

6.1.2.31.- Prueba de llamada entre terminales con señalización SS7 y SIP, completada y donde cuelga el usuario que es llamado (SS7). ......................... 55

6.1.2.32.- Prueba de llamada entre terminales con señalización SS7 y R2, completada y donde cuelga el usuario que es llamado (R2). ........................... 55

6.1.2.33.- Prueba de llamada entre terminales con señalización SIP y R2, completada y donde cuelga el usuario que es llamado (R2). ........................... 56

6.1.2.34.- Prueba de llamada entre terminales con señalización SIP y SS7, completada y donde cuelga el usuario que es llamado (SS7). ......................... 56

6.1.2.35.- Prueba de llamada entre terminales con señalización R2 y SS7, completada y donde cuelga el usuario que es llamado (SS7). ......................... 56

6.1.2.36.- Prueba de llamada entre terminales con señalización R2 y SIP, completada y donde cuelga el usuario que es llamado (SIP). .......................... 57

6.2.- Ventajas de la incorporación del equipo UMG a la red NGN de CANTV. .... 57

6.3.- Desventajas de la incorporación del equipo UMG a la arquitectura de red NGN de CANTV. .................................................................................................... 58

CONCLUSIONES. ..................................................................................................... 59

RECOMENDACIONES. ............................................................................................ 60

REFERENCIAS BIBLIOGRÁFICAS. ....................................................................... 61

BIBLIOGRAFÍA. ....................................................................................................... 63

ANEXOS. ................................................................... Error! Bookmark not defined.

xiii

ÍNDICE DE FIGURAS.

Figura 1. Solicitudes y respuestas SIP de una llamada. .............................................. 10

Figura 2. Diagrama genérico de una red NGN. .......................................................... 16

Figura 3. Red MetroEthernet del laboratorio de CANTV. ......................................... 18

Figura 4. Diagrama lógico de la red NGN de CANTV. .............................................. 23

Figura 5. Diagrama de la arquitectura de red para el servicio VoIP. .......................... 24

Figura 6. Acceso del cliente CPA IP al nodo de servicio. .......................................... 26

Figura 7. Esquema general de conectividad y flujo del tráfico CPA-IP. .................... 27

Figura 8. Diagrama de conexiones para el equipo UMG. ........................................... 28

Figura 9. Diagrama de conexión del UMG para el protocolo de pruebas................... 29

Figura 10. Negociación del codificador PCMA (G.711A) en el mensaje de Invitación (Invite). ........................................................................................................................ 30

Figura 11. Se acepta el codificador PCMA (G.711A) y se inicia la llamada. ............ 31

Figura 12. Negociación del codificador G.723 en el mensaje de Invitación (Invite). 32

Figura 13. Aceptación del codificador G.723 e inicio de la llamada. ......................... 32

Figura 14. Negociación del codificador G.729 en el mensaje de Invitación (Invite). 33

Figura 15. Aceptación del codificador G.729 e inicio de la llamada. ......................... 34

Figura 16. Intercambio de mensajes tipo H.248 entre el UMG y el MSoftX3000. .... 42 Figura 17. Mensajes entre terminales R2, llamada completada y finalizada por el terminal que inicia la llamada. .................................................................................... 42 Figura 18. Mensajes entre terminales SIP, llamada completada y finalizada por el terminal que inicia la llamada. .................................................................................... 43 Figura 19. Mensajes entre terminales SS7, llamada completada y finalizada por el terminal que inicia la llamada. .................................................................................... 44 Figura 20. Mensajes SS7, llamada completada entre SS7 y SIP. ............................... 44

Figura 21. Mensajes SIP, llamada completada entre SS7 y SIP. ................................ 45

Figura 22. Mensajes SS7. Llamada completada entre SS7 y R2. ............................... 45

Figura 23. Mensajes R2, llamada completada entre SS7 y R2. .................................. 46

Figura 24. Mensajes SIP, llamada completada entre SIP y R2. .................................. 46

Figura 25. Mensajes R2, llamada completada entre SIP y R2. ................................... 47

Figura 26. Mensajes entre terminales SS7, llamada no atendida. ............................... 48

Figura 27. Mensajes entre terminales SIP, llamada no atendida................................. 49

Figura 28. Mensajes SIP, llamada entre SIP y R2 no atendida por R2. ...................... 50

Figura 29. Mensajes entre terminales SS7, el usuario llamado está ocupado. ............ 52

Figura 30. Mensajes SS7, llamada entre SS7 y SIP con SIP ocupado. ....................... 52

Figura 31. Mensajes SIP, llamada entre SS7 y SIP con SIP ocupado. ....................... 53

Figura 32. Mensajes entre terminales SS7 donde cuelga quien es llamado. ............... 55

xiv

ACRÓNIMOS.

ACM: Address Complete Message / Mensaje de Dirección Completa.

ANM: Answer Message / Mensaje de Respuesta.

ATA: Analog Telephone Adapter / Adaptador de Teléfono Analógico.

BFD: Bidirectional Forwarding Detection / Detección de Reenvío Bidireccional.

CANTV: Compañia Anónima Nacional Teléfonos de Venezuela.

CPA: Central Privada Automática.

HTTP: Hypertext Transfer Protocol / Protocolo de Transferencia de Hipertexto.

IAM: Initial Address Message / Mensaje de Dirección Inicial.

IETF: Internet Engineering Task Force.

IP: Internet Protocol / Protocolo de Internet.

ISP: Internet Service Provider / Proveedor de Servicios de Internet.

LAN: Local Area Network / Red de Área Local.

LMT: Local Maintenance Terminal / Terminal de Mantenimiento Local.

ME: MetroEthernet.

MEGACO: Media Gateway Control Protocol / Protocolo de Control de Pasarela de Medios.

MFC-R2: Multifrecuency R2 / R2 multifrecuencia.

MPLS: MultiProtocol Label Switching / Multiprotocolo de Conmutación de Etiquetas.

NAT: Network Address Traslation / Traslación de Dirección de Red.

NGN: Next Generation Network / Red de Próxima Generación.

PBX: Private Branch Exchange / Ramal Privado de Comunicación Automática.

PSTN: Public Switched Telephone Network / Red Telefónica Conmutada.

QoS: Quality of Service / Calidad de Servicio.

xv

REL: Release / Liberación.

RLC: Release Complete / Liberación Completa.

RTCP: Real-time Transport Control Protocol / Protocolo de Control de Transporte en Tiempo Real.

RTP: Real-time Transport Protocol / Protocolo de Transporte en Tiempo Real.

SBC: Session Border Controller / Controlador de Sesión de Borde.

SCP: Service Control Point / Punto de Control de Servicio.

SDP: Session Description Protocol / Protocolo de Descripción de Sesión.

SIP: Session Initiation Protocol / Protocolo de Inicio de Sesión.

SOFTSWITCH: Software switch / Conmutador de Software.

SS7: Signaling System 7 / Sistema de Señalización 7.

SSP: Service Switching Point / Punto de Conmutación de Servicio.

STP: Signal Transfer Point / Punto de Transferencia de Señal.

SUS: Suspend / Suspender.

UA: User Access / Punto de Acceso de Usuario.

UDP: User Datagram Protocol.

UIT: Unión Internacional de Telecomunicaciones.

UIT-T: Unión Internacional de Telecomunicaciones – Sector de Normalización de las Telecomunicaciones.

UMG: Universal Media Gateway / Pasarela de Medios Universal.

VLAN: Virtual Local Area Network / Red de Área Local Virtual.

VoIP: Voice over Internet Protocol / Protocolo de Voz sobre Internet.

VPLS: Virtual Private LAN Service / Servicio de Red de Área Local Virtual Privada.

VPN: Virtual Private Network / Red Privada Virtual.

1

INTRODUCCIÓN.

El presente trabajo de grado se desarrolló en la Compañía Anónima Nacional de Teléfonos de Venezuela CANTV, ente adscrito al Ministerio del Poder Popular para la Educación Universitaria, Ciencia y Tecnología, la cual es la primera compañía de telecomunicaciones en Venezuela que tiene como objetivo principal fomentar la inclusión social y la disminución de la brecha al acceso de tecnologías digitales, facilitando así el alcance de todos los servicios de telecomunicaciones. CANTV se encarga de proveer a nivel nacional servicios de telefonía, internet, televisión digital abierta, entre otros.

Para prestar cada día mejor y mayor variedad de servicios a sus usuarios la empresa realiza constantes inversiones en nuevas tecnologías y equipos que permitan un mejor funcionamiento de la red con el fin de cumplir con los más altos estándares de eficiencia. En la búsqueda de expandir los servicios que ofrece CANTV, se están realizando las pruebas y estudios a los equipos para la tecnología Voz sobre IP (VoIP) con la finalidad de ofrecer el servicio, de manera que aprovechando los equipos y la arquitectura que posee la empresa se puedan integrar los equipos a la red existente, para así dar inicio al servicio para sus usuarios.

El presente proyecto tiene como finalidad realizar un planteamiento a CANTV para la posterior puesta en marcha del servicio de VoIP. El trabajo está estructurado en seis (6) capítulos presentado de la siguiente forma: en el capítulo I el planteamiento del problema y los objetivos a lograr. En el capítulo II se describen los principales conceptos y protocolos para el servicio de VoIP. En el capítulo III se especifica la metodología de trabajo en cada una de las etapas realizadas. En el capítulo IV se detalla la arquitectura propuesta para el servicio incluyendo su configuración. En el capítulo V se detalla el protocolo de pruebas realizado y en el capítulo VI que se presentan el análisis de los resultados obtenidos.

Finalmente se presentan las conclusiones, recomendaciones, bibliografías y anexos derivados de la investigación, los cuales complementan y desarrollan el contenido del trabajo.

2

CAPÍTULO I.

1.- PLANTEAMIENTO DEL PROBLEMA.

1.1.- Planteamiento del problema.

CANTV está realizando los estudios y pruebas a los equipos con los que actualmente cuenta en su arquitectura de red, con la finalidad de ofrecer el servicio de VoIP, integrando el equipo Pasarela de Medios Universal (UMG: Universal Media Gateway) para la gestión de las llamadas. Para esto se necesita realizar el protocolo de prueba para la solución de VoIP enfocado en la integración del UMG.

Para la implementación de este nuevo servicio, es necesario plantear la configuración de la red con la inclusión del equipo UMG para la aplicación de Voz sobre IP de manera de optimizar la gestión de las llamadas así como el funcionamiento general de la red, prestando así un mejor servicio a los usuarios. Para esto es imprescindible conocer todos los equipos que conforman la red y tener la configuración de cada uno de ellos, que es dada por el proveedor del equipo; para así poder realizar el protocolo de prueba que permita probar el funcionamiento de la red y de la aplicación.

Dado que la tecnología ha sido escogida por la compañía, es necesario conocer los equipos a utilizar, la ubicación y la configuración de los mismos en la arquitectura de red para el planteamiento de la inclusión del UMG a dicha red y de esta manera obtener una respuesta óptima del mismo y de este modo garantizar el pleno funcionamiento de la aplicación por medio del protocolo de prueba.

Por lo tanto se requiere saber la configuración de cada elemento de los que conformarán la red que son:

• Controlador de Pasarela de Medios (Soft Switch).

• Controlador de Sesión de Borde (SBC: Session Border Controller).

• Adaptador de Teléfonos Analógicos (ATA) o teléfono IP.

• Pasarela de Medios Universal (UMG: Universal Media Gateway).

3

Para la implementación del servicio de Voz sobre IP, CANTV busca aprovechar la infraestructura y los equipos existentes, colocando una configuración que se adapte a la solución que se va a plantear.

1.2. OBJETIVOS.

1.2.1.- Objetivo General.

Integración del equipo Pasarela de Medios Universal (Universal Media Gateway) a la arquitectura de red NGN de CANTV.

1.2.2.- Objetivos Específicos.

1. Investigar las especificaciones técnicas de los equipos a utilizar en la arquitectura actual de red de CANTV para Voz sobre IP.

2. Proponer la arquitectura de red para CANTV, de la solución de Voz sobre IP, integrando el equipo UMG.

3. Diseñar el protocolo de prueba para comprobar el buen funcionamiento de los equipos y de la red, enfocado en el equipo UMG.

4. Determinar las ventajas de la incorporación del equipo UMG a la red para prestar el servicio de Voz sobre IP.

5. Elaborar un informe técnico con las características y especificaciones del protocolo de prueba utilizado en la red NGN de CANTV para el servicio de Voz sobre IP.

1.3.- LIMITACIONES.

Solo se trabajó con el servicio de CPA-IP (Central Privada Automática sobre el protocolo IP) que es uno de los distintos servicios de VoIP que se pueden ofrecer, limitando el trabajo a la arquitectura de red establecida por CANTV para dicho servicio.

4

CAPÍTULO II.

2.- MARCO TEÓRICO.

2.1.- Red Pública de Telefonía Conmutada.

La Red Pública de Telefonía Conmutada, mejor conocida como la PSTN por sus siglas en inglés (Public Switched Telephone Network) , es una red pública en la que cualquier abonado puede suscribirse al operador de red, y éste a su vez debe completar las llamadas del abonado. Esta red es telefónica ya que está diseñada para conectar solo circuitos de voz entre dos terminales. Es conmutada debido a que los circuitos de voz se establecen mediante centrales telefónicas que conmutan los recursos de la red para prestar conexiones temporales a sus usuarios.

2.1.1.- Elementos que componen la red PSTN.

2.1.1.1.- Conmutación.

Los elementos de la conmutación se encargan de establecer una trayectoria de comunicación entre 2 abonados. Las centrales telefónicas son las principales encargadas de este proceso, apoyándose en equipos periféricos que aportan inteligencia o servicio a la red básica y le proporcionan información sobre el estado de la red.

2.1.1.2.- Señalización.

Es la manera a través de la cual las centrales telefónicas se comunican entre sí y con los equipos terminales de los abonados. En Venezuela CANTV maneja la señalización N°7 (SS7) para la comunicación entre centrales, y para la comunicación con equipos terminales se usa la señalización MFCR2.

5

2.1.1.3.- Transmisión.

Es el medio físico a través del cual se desplazan las señales portadoras de voz y datos por la red. El medio físico puede ser el espacio libre, fibra óptica, cable coaxial, satélite, etc.

2.1.1.4.- Gestión.

Los elementos de gestión mantienen vigilancia constante sobre los elementos de la red: proporcionan mecanismos automatizados y centralizados para configurar los elementos de la red; optimizan el manejo de los recursos de transmisión y administración, además de hacer eficiente el mantenimiento preventivo y reactivo de la red.

2.1.1.5.- Datos.

Los datos, como elemento de telecomunicación, proveen visibilidad a los equipos instalados en la red desde un punto central llamado centro de control. Este centro de control tiene el poder de comando de los equipos electrónicos, recolecta información de comportamiento de equipos de red, transmite los registros de las llamadas telefónicas desde las centrales hasta las plataformas de facturación y procesamiento.

2.1.1.6.- Equipos terminales.

Los equipos terminales son propiedad de los abonados: van desde equipos telefónicos, fax, conmutadores residenciales hasta telefonías privadas PBX (Private Branch Exchange).

2.1.1.7.- Servicios.

6

Los servicios son dirigidos a mercados específicos, para solventar necesidades de comunicación. Los servicios de telecomunicaciones típicos prestados por las operadoras son: larga distancia nacional e internacional, asistencia por operadora, tarjetas telefónicas de prepago e Internet.

2.1.2.- Señalización MFC-R2.

Es un sistema de señalización utilizado principalmente para medios de transmisión digital como por ejemplo enlaces E1, que tiene treinta y dos (32) canales de los cuales treinta (30) son de voz y dos (2) son de señalización. Este sistema de señalización consiste de señales de registro y señales de línea, y está completamente definido en las recomendaciones de la UIT Q.400-Q.490 [1].

El direccionamiento telefónico es enrutado mediante un conjunto de tonos, mientras que la señalización de canal es enviada en el intervalo de tiempo 16. En este intervalo de tiempo se transfieren los bits ABCD del canal de voz mediante los cuales se ejecuta el control de la llamada. En una conversación se tienen dos (2) partes operando, una donde se origina la llamada a la cual se refiere la señalización hacia adelante y otra donde se recibe la llamada, o lado receptor a la cual se relacionan las señalizaciones hacia atrás.

2.1.3.- Señalización SS7.

El sistema de señalización N°7 o SS7 por sus siglas en inglés (Signaling System 7) es un protocolo de señalización definido por la UIT-T en sus recomendaciones Q.700-Q799 [2]. Su principal característica es que separa la señalización y los datos de voz y video, y los transmite a través de enlaces distintos. Se requiere un enlace utilizado únicamente para la señalización y un enlace para los datos, por lo que se considera un protocolo de señalización fuera de línea o de banda ya que no comparte un único enlace para ambos. Es considerado un sistema de señalización por canal común, ya que por un mismo canal de señalización se puede enviar y recibir la señalización de múltiples llamadas.

Para el establecimiento de una estructura de red capacitada para el soporte de SS7 se necesitan 3 tipos de puntos de señalización y se definen a continuación:

7

2.1.3.1.- Punto de Conmutación de Servicio (Service Switching Point).

Los Puntos de Conmutación de Servicio (Service Switching Point) o SSP, son puntos de control de dirección de la red. Por lo general en una red telefónica estos representan las centrales telefónicas, que deben estar equipadas con software SS7 y con enlaces de terminación de la señalización. Su función básica es conmutar las llamadas.

2.1.3.2.- Punto de Transferencia de Señal (Signal Transfer Point).

Los Puntos de Transferencia de Señal (Signal Transfer Point) o STP, son puntos de transferencia de señales donde se reciben y enrutan los mensajes de señalización hacia el destino adecuado. Son conmutadores de paquetes que se encargan del establecimiento y control de los enlaces en la red.

2.1.3.3.- Punto de Control de Servicio (Service Control Point).

Los Puntos de Control de Servicio (Service Control Point) o SCP constituyen una base de datos de información de operación, mantenimiento y servicios suplementarios. En ellos se concentra la inteligencia de la red y se encargan de la gestión y el mantenimiento de la misma.

2.2.- Voz sobre IP.

La tecnología VoIP permite la transmisión de la voz previamente procesada y encapsulada en paquetes IP para luego poder ser transmitidas sobre redes de datos como Internet sin necesidad de disponer de una infraestructura telefónica convencional, logrando así una convergencia de la transmisión de voz y datos, lo que permite tener una única red homogénea en la que se envía todo tipo de información ya sea voz, video y datos.

8

2.2.1.- Protocolos de VoIP.

2.2.1.1.- Protocolo de Iniciación de Sesión (SIP: Session Initiation Protocol).

Es un protocolo de control de la capa de aplicación que se encarga de establecer, modificar y terminar sesiones multimedia (conferencias) como llamadas telefónicas por Internet definido en el RFC 3261 [3]. SIP también puede invitar a un usuario a una sesión ya existente, como una conferencia de multidifusión.

SIP soporta cinco fases de establecimiento y finalización de comunicaciones multimedia, que son:

� Ubicación de Usuario (User Location): determina el sistema final que será utilizado para la comunicación.

� Disponibilidad de Usuario (User Availability): determina la disponibilidad del usuario que es llamado para establecer la llamada.

� Capacidad de Usuario (User Capability): determina los parámetros de la media que serán utilizados.

� Configuración de Sesión (Session Setup): “Repicando (ringing)” establece los parámetros de la sesión de llamada.

� Manejo de Sesión (Session Management): se encarga de la modificación y finalización de las sesiones.

SIP no es un sistema vertical de comunicaciones integral. SIP es un componente que puede ser utilizado con otros protocolos de la IETF para construir una arquitectura multimedia completa. SIP fue diseñado con el concepto de (Caja de herramientas) “tool box”, es decir, se vale de las funciones aportadas por otros protocolos, que da por hechas y no vuelve a desarrollar. El protocolo SIP se concentra en el establecimiento, modificación y terminación de las sesiones, y se complementa con otros protocolos como por ejemplo: SDP, RTP, MEGACO, etc. SIP tiene que trabajar en conjunto con estos otros protocolos para proveer servicios completos a los

9

usuarios, sin embargo el funcionamiento básico con el que opera SIP no depende de ninguno de estos protocolos.

2.2.1.1.1.- Mensajes SIP.

SIP es un protocolo textual que usa una semántica semejante a la del protocolo HTTP, definiendo la comunicación a través de dos tipos de mensajes mostrados en la Figura 1 que son:

• Solicitudes o métodos: las peticiones SIP son caracterizadas por la línea inicial del mensaje que contiene el nombre del método, el identificador del destinatario de petición y la versión del protocolo SIP. Existen seis (6) métodos básicos SIP que describen las peticiones de los clientes, que son:

� INVITE: Permite invitar a un usuario o servicio para participar una sesión o para modificar parámetros de una sesión existente.

� ACK: Confirma el establecimiento de una sesión.

� OPTION: Solicita información sobre las capacidades de un servidor.

� BYE: Indica la finalización de una sesión.

� CANCEL: Cancela una petición pendiente.

� REGISTER: Registrar a un usuario.

• Respuesta o códigos de estado: después de la recepción e interpretación del mensaje de solicitud SIP, el receptor del mismo responde con un mensaje, el código de la respuesta está compuesto por tres dígitos que permiten clasificar los diferentes tipos existentes, siendo el primer digito el que define la clase de respuesta, como se muestra a continuación:

� 1xx.- Mensajes provisionales.

� 2xx.- Respuestas de éxito.

� 3xx.- Respuestas de redirección.

� 4xx.- Respuesta de fallo de método.

10

� 5xx.- Respuesta de fallos de servidor.

� 6xx.- Respuesta de fallos globales.

Figura 1. Solicitudes y respuestas SIP de una llamada.

Fuente: RFC 3261. [3].

2.2.1.1.2.- Troncal SIP.

Una troncal SIP es un servicio ofrecido por un proveedor de servicios de telefonía por Internet ITSP (Internet Telephony Service Provider) que permite a los usuarios, usar servicios VoIP por fuera de la red de la compañía a través de la conexión a Internet. La clave de éxito de un emplazamiento de una troncal SIP está en la interoperabilidad.

2.2.1.2.- H.323.

11

Es una recomendación de la ITU-T H.3232 [4], que describe los protocolos usados para proveer sesiones de comunicación de voz y video sobre redes paquetizadas. Se utiliza generalmente para comunicaciones de voz sobre IP y para videoconferencias basadas en IP. Entre los elementos que conforman una topología clásica de una red basada en H.323 se encuentran:

• Portero: se encarga de realizar el control de llamadas en una zona. También ofrece servicio de directorio, control de consumo de recursos, control de admisión de terminales, traduce direcciones, procesa la autorización de llamadas al igual que puede encaminar la señalización.

• Pasarela: permite el acceso a otras redes, de manera que se encarga de convertir los datos y traducir la señalización.

Una llamada establecida bajo el protocolo H.323 se desarrolla de la siguiente manera:

� Establecimiento: el terminal que ejecuta la llamada se registra en el portero, luego se envía un mensaje para iniciar una llamada H.323. El terminal llamado responde con un mensaje advirtiendo el intento de establecer una llamada, luego de lo cual este terminal debe registrarse con el portero utilizando el protocolo hasta esperar que se dé inicio a la conexión.

� Señalización de control: en esta fase se abre una negociación, para decidir mediante el intercambio de mensajes entre los terminales quien será el maestro y quien el esclavo, al igual que se definirán las capacidades de los participantes y los codificadores de audio a utilizar.

� Audio: los terminales inician la comunicación mediante el protocolo RTP/RTCP.

� Desconexión: en esta fase cualquiera de los participantes puede iniciar el proceso de finalización de llamada.

2.2.1.3.- H.248/MEGACO.

Es un estándar de comunicación entre pasarelas de medios, denominado MEGACO por la IETF y H.248 por la ITU-T en su recomendación ITU-T H.248.1 [5], mediante el cual un Controlador de Pasarela de Medios (MGC: Media Gateway Controller) puede controlar a uno o más pasarelas de medios de acceso (MGW). Un punto importante de este protocolo es que, el estándar es utilizado solo en la comunicación entre el MGC y el MGW, ya que para la comunicación entre 2 MGC se

12

usa H.323 o SIP. Este protocolo permite intercambiar transacciones entre las 2 entidades, y cada transacción se expresa por el envío de un requerimiento denominado “transactionRequest” de parte de una de las entidades con un conjunto de instrucciones, y de una respuesta denominada transactionReply como respuesta por parte de la otra entidad con el conjunto de respuestas correspondientes.

2.2.1.4. - RTP (Real-time Transport Protocol) / RTCP.

Es un protocolo de transporte en tiempo real definido en el RFC 3550 [6], que proporciona servicios de entrega punto a punto de datos con características de tiempo real como audio y video interactivos. La principal tarea de RTP es el monitoreo de la tasa de entrega de datos. La mayoría de las aplicaciones utilizan el protocolo RTP sobre el protocolo de transporte no orientado a conexión UDP (User Datagram Protocol) con el fin de aprovechar los servicios de multiplexación y verificación de datos. Es importante destacar que RTP no ofrece garantías sobre la calidad del servicio ni sobre el retraso de la entrega de datos, estos deben ser proporcionados por la red.

RTP utiliza los servicios de RTCP para monitorear la calidad de servicio y proporciona información acerca de los participantes en una sesión de intercambio de datos. La principal función de RTCP es proporcionar una retroalimentación útil para mantener una calidad de distribución adecuada.

2.2.1.5.- Protocolo de Descripción de Sesión (SDP: Session Description Protocol).

Protocolo de descripción de sesión (SDP: Session Description Protocol), es un protocolo que se encarga de describir sesiones de comunicación multimedia definido en el RFC 4566 [7], cubriendo aspectos como anuncio de sesión, invitación a sesión, tipo de codificación y negociación de distintos parámetros. SDP no se encarga de entregar los contenidos propiamente dichos sino de entablar una negociación entre las entidades que intervienen en la sesión como tipo de contenido, formato, y todos los demás parámetros asociados. Este conjunto de parámetros se conoce como perfil de sesión.

13

2.2.1.6.- UIT-T G.711.

Es un estándar de compresión para audio compuesto, definido en la recomendación UIT-T G.711 [8] utilizado principalmente en telefonía que representa la modulación de códigos de pulsos comprimidos de ocho (8) bits PCM, muestras para señales de frecuencias de voz, grabadas a una velocidad de 8000 muestras por segundo, generando así una corriente de 64kbits/s.

Existen dos algoritmos de codificación que definen principalmente el estándar, el algoritmo ley-µ usado en Norte América y Japón, y el algoritmo ley-a que se usa en Europa y el resto del mundo, y que fue diseñado para disminuir el nivel de procesamiento necesario para el mismo, facilitando su aplicación. El número de valores cuantificados viene dado por la ley de codificación usada, al transmitir en serie las señales de carácter de manera consecutiva se transmite primero el bit de polaridad y el bit menos significativo, es decir el bit 8 en último lugar.

2.2.1.7.- UIT-T G723.1.

Es un estándar de compresión de audio de tipo banda angosta, creado como una extensión de la norma G.721, usa modulación por código de pulsos adaptativos diferenciales (ADPCM: Adaptative Differential Pulse Code Modulation) que codifica los datos de voz en cadenas de 30 ms de duración (240 muestras en total por trama).

Cada trama puede ser de 20 o 24 bytes, lo que hace que se tenga una tasa de transmisión de 5,3kbits/s o de 6,4kbits/s con una frecuencia de muestreo de 8KHz, convirtiendo la señal en una cadena lineal de 16 bits PCM. La velocidad de 6,4kbits/s tiene una mejor calidad, mientras que la de 5,3kbits/s posee buena calidad y permite un poco mas de flexibilidad a los diseñadores de sistemas. Esta descrito en la recomendación UIT-T G.723.1 [9]

2.2.1.8.- UIT-T G 729.

Es un algoritmo de compresión de datos de audio para voz, que comprime los paquetes de audio digitalizado en trozos de 10 milisegundos, muestreando a 8KHz y convirtiendo las muestras en cadenas lineales de 16 bits PCM. Es utilizado

14

mayormente para aplicaciones de VoIP por sus bajos requisitos de ancho de banda. Opera a una tasa de 8kbits/s generalmente, aunque también se manejan otras tasas de 6,4kbits/s y de 11,8kbits/s dependiendo de si se necesita una mayor o menor calidad en la conversación. Para su codificación hace uso de un código algebraico de excitación lineal predictivo con estructura conjugada (CS-ACELP: Conjugate Structure – Algebraic Code Excited Linear Prediction). También tiene un esquema de compresión del silencio, el cual tiene un módulo para detectar la actividad de la voz, como otros módulos que ayudan al mejoramiento de la calidad de la voz y un menor uso del ancho de banda. Descrito en la recomendación UIT-T G.729 [10].

A continuación se muestra una tabla resumen con los codificadores antes explicados y sus principales características:

Tabla 1. Características de los codificadores.

Codificador Velocidad de

muestreo (KHz)

N° de bits por

muestra

Duración de la

trama (ms)

Velocidad de

transmisión

(kbits/s)

G.711 8 8 64

G.723 8 16 30 5,3 / 6,4

G.729 8 16 10 6,4 / 8 / 11,8

2.2.1.9.- Calidad de Servicio (QoS: Quality of Service).

Calidad de servicio (QoS por sus siglas en ingles), es una tecnología de red que utilizan algunas organizaciones para ofrecer una experiencia al usuario final óptimas para la comunicación de audio y video. Se encarga de priorizar el ancho de banda disponible en función de las necesidades del usuario y basándose en una serie de criterios que clasifican el tráfico. Cuantitativamente mide la calidad de los servicios considerando varios aspectos del servicio de red, tales como tasas de errores, ancho de banda, rendimiento, retraso en la transmisión, disponibilidad, retraso de variable (jitter), etc.

15

2.3.- Normativas asociadas a voz sobre IP.

Las normativas asociadas al servicio en estudio han sido tema de discusión en muchos lugares, ya que por un ser un servicio que se presta sobre el protocolo IP y se transporta por medio de datos sobre la Internet hay quienes alegan que no es un servicio de voz lo que prestan sino un servicio de datos y que en la mayoría de los casos se ha apegado a la normativa de la voz analógica, y a los parámetros que establecen cada uno de los protocolos con los que se trabaja en el servicio.

En Venezuela el servicio está normado por CONATEL, como todos los servicios en telecomunicaciones y establece que debe regirse bajo los parámetros de calidad del servicio de voz analógico y si se va a proveer el servicio se debe registrar debidamente bajo las normativas ya establecidas para el servicio antes mencionado.

2.4.- Redes de Próxima Generación (NGN: Next Generation Network).

Es una red que basada en la transmisión de paquetes IP, que permite el manejo de múltiples servicios como voz, video y datos donde la transmisión de los paquetes de la capa de control se procesa de forma separada a los paquetes de la capa de transporte. De manera que se podría definir como una red con un sistema integrado que ofrece a sus usuarios flexibilidad y escalabilidad en la red permitiendo una mayor oferta de servicios a menor costo, proporcionar distintos anchos de banda a sus usuarios con una mayor calidad de servicio.

16

Figura 2. Diagrama genérico de una red NGN.

Fuente: Propia.

2.4.1.- Elementos que conforman una red NGN.

2.4.1.1.- Controlador de Pasarela de Medios MGC (SoftSwitch).

Es el principal dispositivo en la capa de control dentro de una arquitectura NGN, se basa en una combinación de software y hardware que se encarga de enlazar las redes de paquetes y las redes tradicionales, las cuales desempeñan funciones de control de llamadas tales como conversión de protocolos, autorización, contabilidad y administración de operaciones. Es la pieza central en la red de telefonía IP, puede manejar inteligentemente las llamadas en la plataforma de servicio de los proveedores de servicio de Internet (ISP).

2.4.1.2.- ATA o teléfonos IP.

17

Es el equipo terminal de toda red de VoIP, ya que es la que conecta al emisor con el receptor a través de la red permitiendo realizar llamadas basadas en el protocolo IP; el ATA es un dispositivo o adaptador donde se conectan uno o más equipos analógicos para realizar la conversión a la red digital y de esta manera conectarse a la red IP.

2.4.1.3.- Controlador de Sesión de Borde (SBC: Session Border Controller).

Es un equipo de control y seguridad de la red, que se implementa en el borde de la red IP, entre la red privada y pública. Tiene funciones como control de admisión de llamadas, calidad de servicio, ocultamiento de topología, Traslación de Dirección de Red (NAT) trasversal, seguridad ante ataques, asegura la interconexión de los usuarios y la calidad de la voz, entre otras funciones.

2.4.1.4. – Pasarela de medios “Media Gateway”.

Es un equipo que sirve de puente entre la red PSTN y la red IP para ambos lados de origen y terminal de la llamada, existen dos tipos de media Gateway del lado de la línea y del lado de la troncal. Estos equipos se encargan de hacer la traducción entre los datos de paquetes VoIP y las troncales de voz analógica o digital, y entre las interfaces de teléfonos analógicos y digitales.

Una pasarela de medios proporciona las funciones de mapeo de medios e interconexión entre la red IP y las redes de conmutación de circuitos. Estas funciones incluyen mecanismos de compresión, supresión de silencios y cancelación de eco, según se requiera. Una pasarela de medios también tiene que ser capaz de manejar H.323 o SIP del lado de VoIP y el esquema de señalización necesario del lado de la línea o troncal.

2.4.1.5.- Pasarela de Señalización “Signaling Gateway”.

Es el componente de la red responsable de transferir los mensajes de señalización correspondientes al establecimiento de llamadas, facturación, ubicación

18

entre otros. En la red NGN sirven de enlace entre los nodos que usan distintos tipos de comunicación y transporte de mensajes.

2.5.- Red MetroEthernet.

La red ME es una red de transporte que utiliza topología de anillos, está estructurada por conmutadores MPLS que permiten construir VPNs (Virtual Private Network) en capa 2. Esto permite a los clientes ver su red como una LAN (Local Area Network); a diferencia de las VPNs de capa 3 el cliente puede utilizar un direccionamiento IP/Enrutamiento propio a conveniencia, manteniendo el control del mismo.

La red metro Ethernet provee calidad de servicio (QoS) para la diferenciación del tráfico a nivel de capa 2 en las VPNs. En la figura 2 se muestra la red MetroEthernet del laboratorio de CANTV.

Figura 3. Red MetroEthernet del laboratorio de CANTV.

Fuente: Propia.

2.5.1.- Multiprotocol Label Switching. (MPLS).

Switch ME

Switch ME

Switch ME

Switch ME

RED ME

VPLS

19

Es un mecanismo mejorado de transmisión de paquetes que utiliza información almacenada en etiquetas anexadas a los paquetes IP, etiquetando los paquetes en base a criterios de prioridad y/o calidad (QoS), caracterizándose por:

• Combina mecanismos de conmutación de paquetes capa 2 con mecanismos de enrutamiento de capa 3.

• La decisión de transmisión de los paquetes, se basa en una etiqueta, en vez de realizar una decisión de enrutamiento de capa 3 más compleja.

• Ofrece QoS, independientemente de la red sobre la que se implemente.

2.5.2.- Servicios de LAN Privada Virtual (VPLS: Virtual Private LAN Services).

Servicio privado de LAN virtual que corresponde a un requerimiento de compartir servicios entre tres o más puntos/localidades.

2.5.3.- Virtual LAN (VLAN).

Es un método de crear redes lógicamente independientes dentro de una misma red física. Varias VLANs pueden coexistir en un único conmutador físico o en una única red física. Son útiles para reducir el tamaño del dominio de difusión y ayudan en la administración de la red separando segmentos lógicos de una red de área local.

2.5.4.- Red Privada Virtual (VPN: Virtual Private Network).

Es una tecnología que permite crear una conexión segura de una red a otra a través de una red pública o no controlada como internet; cuando un dispositivo está conectado a una VPN actúa como si estuviese en la misma red, por lo tanto todo el tráfico se envía de forma segura a través de la VPN. Esto se realiza estableciendo una conexión virtual punto a punto mediante el uso de conexiones dedicadas, cifrado o la combinación de ambos métodos.

20

CAPÍTULO III.

3.- METODOLOGÍA.

3.1.- Fase I.

Se realizó una fase analítica, según la autora Hurtado de Barrera, J. en su tercera edición del libro “GUÍA PARA LA COMPRENSIÓN HOLÍSTICA DE LA CIENCIA” [10], la define de la siguiente manera: “…El investigador lee, revisa las teorías y los estudios previos y analiza los planteamientos relacionados con su evento.”; en esta etapa se recopiló información sobre los equipos a utilizar, su función en la red, especificaciones técnicas y configuraciones, protocolos utilizados en el servicio de voz sobre IP y el funcionamiento de los mismos, y documentación de la red que se tenía en el laboratorio para la realización de las pruebas.

3.2.- Fase II.

En esta fase se realizó una investigación experimental. La autora María Eugenia Bautista en el libro “Manual de Metodología de Investigación” [11] define este tipo de investigación de la siguiente manera: “La investigación experimental tiene como propósito poner a prueba hechos e hipótesis.”, en esta fase se corrieron distintas pruebas para verificar el funcionamiento de la red, comprobando la interconexión de los equipos, de manera de asegurar que las llamadas estaban siendo enrutadas por los equipos correspondientes, y que las configuraciones de los equipos estuvieran correctas para así poder comprobar el funcionamiento del UMG en la solución de la red para el servicio de VoIP.

3.3.- Fase III

Se realizó una fase interactiva, según la autora Hurtado de Barrera, J. en su tercera edición del libro “GUÍA PARA LA COMPRENSIÓN HOLÍSTICA DE LA CIENCIA” [10], la define de la siguiente manera: “Consiste en la puesta en práctica del diseño de investigación y la recolección de datos…” en esta etapa fue probada la

21

arquitectura de red con la inclusión del equipo UMG, se procedió a colocarlo como solución para el servicio de VoIP.

3.4.- Fase IV.

En esta etapa se realizaron dos tipos de fases definidas la autora Hurtado de Barrera, J. en su tercera edición del libro “GUÍA PARA LA COMPRENSIÓN HOLÍSTICA DE LA CIENCIA” [9], la primera fase fue interactiva y la segunda fase fue confirmatoria, donde se realizó el protocolo de pruebas de manera de verificar que el UMG cumpla con sus funciones de gestionar y direccionar las llamadas en la red para el servicio de VoIP.

22

CAPITULO IV.

4.-PROPUESTA DE INCORPORACIÓN DEL EQUIPO UMG Y CONFIGURACIÓN DE LA RED NGN DE CANTV.

4.1.- Arquitectura de la red NGN de CANTV.

La empresa CANTV cuenta con una red NGN estructurada en una capa de control, una de acceso y una de distribución. Cada una de las capas está conformada por distintos equipos que se detallarán a continuación:

4.1.1.- Capa de Control.

En esta capa se lleva a cabo la mayor parte de la inteligencia de la red, se establecen las rutas para voz, datos y señalización. Esta capa está conformada por un único equipo que es el Softswitch, el principal dispositivo de red que se encarga de la asignación de rutas, recursos, llevar contabilidad, facturación y administración de operaciones.

El equipo con el que cuenta CANTV es el equipo Huawei modelo MGC MsoftX300.

4.1.2.- Capa de Acceso.

Esta capa sirve como enlace entre las redes paquetizadas IP y las redes conmutadas de telefonía, además de servir como puerta de acceso a la red. En esta capa se encuentran 2 tipos de equipos, la pasarela de medios universal que es el puente entre la PSTN y la red IP y una unidad de acceso universal, que permite la conexión de terminales analógicos, PBX y terminales de telefonía IP dando acceso a múltiples servicios, aunque está configurado solo para los servicios de voz de acuerdo con los requerimientos de CANTV.

El equipo pasarela de medios universal es una unidad de Huawei modelo Mini UMG8900. La unidad de acceso universal es de Huawei modelo UA5000.

23

4.1.3.- Capa de Distribución.

En la capa de distribución se lleva a cabo el transporte de los paquetes una vez hayan sido asignados los recursos por el Softswitch y está conformada por una red de conmutadores multiprotocolo MPLS que combina mecanismos de conmutación de paquetes capa dos con mecanismos de enrutamiento capa tres para optimizar la transmisión de los mismos. La red MPLS está conformada por dos pares de conmutadores de marca Alcatel modelo S9800, un par de ellos establecidos en modo activo y el otro par en modo pasivo, dando redundancia y confiabilidad a la red haciéndola más robusta.

Adicionalmente a los equipos mencionados, se tiene conectada a la red MPLS una computadora que sirve como Terminal de Mantenimiento Local (LMT) a través de la cual se realiza el monitoreo de la red y de los equipos que la conforman.

El diagrama lógico de la red se muestra en la figura a continuación:

Figura 4. Diagrama lógico de la red NGN de CANTV.

Fuente: Propia.

24

4.2.- Arquitectura de la red de CANTV con la incorporación del equipo UMG para el servicio de voz sobre IP (VoIP).

El servicio de VoIP que CANTV tiene planeado ofrecer a sus clientes es el de Central Privada Automática sobre el protocolo IP (CPA-IP) y se trabajó la arquitectura de red que tiene estructurada CANTV para dicho servicio.

El servicio CPA-IP consiste en brindar a los clientes empresariales troncales de voz sobre el protocolo IP para la conexión de sus centrales telefónicas a los servicios de voz ofrecidos por CANTV. Se propone la arquitectura de red en la que el cliente tenga acceso al servicio a través de la Red de Acceso y de Transporte MetroEthernet de CANTV haciendo uso de los servicios MetroEthernet definidos, dependiendo del caso. Luego se agregan los clientes en capa 3 y se interconecta con los equipos del Controlador de Sesión de Borde (SBC) a través de los enrutadores de servicio. El SBC se encarga de aportar seguridad a la conexión y envía la señalización y contenido al elemento correspondiente de la capa de control de la NGN, en este caso el Softswitch MGC MSoftX3000, de ahí pasa al nodo de acceso pasarela de medios universal UMG que se encarga de enlazar con los equipos terminales. Una ejemplificación se muestra a continuación en la figura 5.

Figura 5. Diagrama de la arquitectura de red para el servicio VoIP.

Fuente: Propia.

25

Para el servicio de VoIP se requiere un equipo UMG que sirva de puente entre la red PSTN y la red paquetizada MPLS. Para poder ofrecer dicho servicio CANTV planea incorporar a la red NGN y utilizar como pasarela de medios el equipo UMG de marca Huawei modelo UMG8900-SSM160, que amplía las prestaciones y capacidades del antiguo UMG con el que contaba la empresa, el equipo modelo MiniUMG 8900 que se encuentra descontinuado y fuera de inventario. El equipo MiniUMG 8900 pasará a formar parte de una red en el laboratorio de arquitectura de redes de CANTV para su uso en pruebas, mas no se usará para prestar servicio a los clientes. En el nuevo UMG se instalarán un par de tarjetas de cada tipo, en configuración activo/pasivo para ofrecer redundancia a la red sin necesidad de instalar un segundo equipo para ello. El UMG se encargará de enrutar el tráfico de voz y señalización de las llamadas, haciendo uso de los distintos protocolos existentes.

Se instalarán 2 nodos de servicio CPA-IP, uno en Caracas y el otro en el interior del país en la ciudad de Barquisimeto. Cada nodo de servicio está conformado por una pareja de enrutadores de servicio en configuración activo/pasivo y una pareja de equipos SBC también en configuración activo/pasivo. Cada cliente estará asociado a un solo nodo de servicio, cada nodo de servicio va a permitir el acceso a múltiples clientes siguiendo un criterio de distribución geográfica en el cual los clientes ubicados físicamente en las regiones capital y oriental serán atendidos por el nodo de servicio CPA IP de Caracas y los clientes ubicados en las regiones occidental, centro occidental y central serán atendidos por el nodo de servicio de Barquisimeto.

Los clientes tendrán acceso al nodo de servicio mediante la conexión del conmutador de acceso del cliente al conmutador de la red MetroEthernet, que se encargará de enviar los paquetes de información al enrutador de servicio CPA IP. En la figura 6 se puede observar un esquema de la arquitectura para el acceso del cliente.

26

Figura 6. Acceso del cliente CPA IP al nodo de servicio.

Fuente: Propia.

La interconexión de clientes CPA-IP a la red NGN de CANTV se realizará a través de una troncal SIP que se establecerá entre los equipos SBC y la CPA, de igual forma los equipos SBC se conectan a la capa de control de la red (Softswitch) a través de troncales SIP en los cuales se otorgarán los recursos para el establecimiento de la llamada. Un esquema de conectividad general se observa en la siguiente figura:

27

Figura 7. Esquema general de conectividad y flujo del tráfico CPA-IP.

Fuente: Propia.

Una vez que se estructuró la arquitectura de red para el servicio CPA IP, se procedió a realizar una arquitectura de red para llevar a cabo las pruebas del equipo UMG y asegurar su correcto funcionamiento una vez se incorpore a la NGN. Este diseño permitió realizar las pruebas de compatibilidad del equipo con los distintos protocolos de señalización y codificación, asegurando así la interconexión con los demás equipos existentes.

El equipo UMG estará conectado a una central para el acceso a la PSTN, la conexión con la misma se hará a través de enlaces E1 eléctricos. En la central se crearon dos troncales, una troncal R2 y una troncal SS7 para poder probar el manejo,

28

la interconexión e interacción de ambas tecnologías a través del equipo. También se debe tener conexión al Softswitch a través de la red MPLS, mediante interfaces Ethernet haciendo uso del protocolo H.248 para el manejo de la señalización de las llamadas y comunicación entre la pasarela de medios y el controlador.

Por último se necesita conexión a la unidad de acceso universal (UA: Universal Access) que permite el acceso a los servicios de voz a los terminales SIP. La conexión al UA se realiza a través de la red MPLS mediante interfaces Ethernet. El esquema de conexiones del equipo UMG se pueden observar a continuación:

Figura 8. Diagrama de conexiones para el equipo UMG.

Fuente: Propia.

De esta manera se podrán realizar todas las pruebas correspondientes al manejo de las distintas tecnologías y protocolos por parte del UMG. El esquema de la red configurada para dichas pruebas se presenta a continuación en la figura 9.

29

Figura 9. Diagrama de conexión del UMG para el protocolo de pruebas.

Fuente: Propia.

Una vez esquematizada la red y el diagrama de conexiones necesarios para el funcionamiento e incorporación del equipo UMG se procedió a la verificación de las funciones de procesamiento de voz y codificadores (codificadores G.711, G.723 y G.729), asegurando el soporte de los distintos algoritmos de compresión y codificación de las señales de voz generadas durante una llamada.

4.3.- Terminales empleados durante las pruebas.

Para las pruebas del equipo pasarela de medios universal se necesitaron dos tipos de terminales, terminales analógicos para realizar las pruebas correspondientes a la señalización MFC R2 y SS7 y terminales que permitan la señalización SIP.

Los terminales usados para las señalizaciones R2 y SS7 fueron teléfonos que estaban conectados a la PSTN y forman parte de la red interna de CANTV. En este caso fueron terminales marca SENDTEL modelo Sendtel SPK310.

Para la señalización SIP se usaron 2 terminales propiedad del laboratorio de arquitectura de redes de CANTV, conectados a la unidad de acceso universal (UA5000) para que les permita el acceso a los servicios de voz sobre redes IP. En esta caso los equipos utilizados fueron teléfonos marca SIEMENS modelo Euroset 3020.

30

4.4.- Funciones de procesamiento de voz y codificadores.

4.4.1.- Soporte de codificador G.711A

Para asegurar que el equipo UMG es capaz de procesar llamadas haciendo uso del codificador G.711A se configuró el equipo MGC MSoftX3000 deshabilitando cualquier otro tipo de procesamiento de llamadas, forzando de esta manera al uso de forma exclusiva del codificador antes citado. Para comprobar el funcionamiento correcto de los equipos bajo la condición establecida, se procedió a realizar una llamada entre un usuario conectado a la PSTN y un usuario SIP y se analizaron los paquetes capturados, mostrando la negociación del codificador y el establecimiento de la llamada de manera exitosa. La captura de los paquetes se muestra a continuación:

Figura 10. Negociación del codificador PCMA (G.711A) en el mensaje de Invitación (Invite).

Fuente: Propia.

31

Figura 11. Se acepta el codificador PCMA (G.711A) y se inicia la llamada.

Fuente: Propia.

4.4.2.- Soporte del codificador G.723.

Al igual que en el caso del codificador G.711A se configuró el equipo MGC MSoftX3000 habilitando solo el codificador G.723, anulando cualquier otro tipo de codificación posible. Una vez configurado se procedió a realizar una llamada desde un terminal conectado a la PSTN hacia un terminal SIP y se analizaron los paquetes capturados para verificar que el proceso se llevó a cabo de manera exitosa. A continuación se muestran las capturas de los paquetes que permiten observar la negociación y establecimiento del codificador G.723.

32

Figura 12. Negociación del codificador G.723 en el mensaje de Invitación (Invite).

Fuente: Propia.

Figura 13. Aceptación del codificador G.723 e inicio de la llamada.

33

4.4.3.- Soporte de codificador G.729.

Se configuró el equipo MGC MsoftX3000 para que solo permitiera el uso del codificador G.729, anulando la posibilidad de cualquier otro tipo de codificación de la señal de voz. Una vez configurado se procedió a realizar una llamada desde un terminal conectado a la PSTN hacia un terminal SIP y se analizaron los paquetes capturados para verificar que el proceso se llevó a cabo de manera exitosa. A continuación se muestran las capturas de los paquetes que permiten observar la negociación y establecimiento del codificador G.729.

Figura 14. Negociación del codificador G.729 en el mensaje de Invitación (Invite).

Fuente: Propia.

34

Figura 15. Aceptación del codificador G.729 e inicio de la llamada.

Fuente: Propia.

35

CAPÍTULO V.

5.- PROTOCOLO DE PRUEBAS DE LA RED ENFOCADO EN EL UMG.

5.1.- Protocolo de pruebas utilizado en la red NGN de CANTV para el servicio de voz sobre IP.

5.1.1.- Prueba de interconexión y control (H.248) entre el equipo UMG 8900 SS160 y el controlador MGC MSoftX3000.

• Objetivo de la prueba: verificar que la interconexión entre los equipos mencionados es realizada de manera correcta.

• Procedimiento:

� Conectar los equipos como se indica en el capítulo IV. � Acceder al Terminal de Mantenimiento Local (LMT) y rastrear los

mensajes intercambiados entre los equipos UMG y MSoftX3000. � Desactivar de manera lógica el UMG y posteriormente reactivarlo. � Verificar el estado del enlace una vez se haya reactivado el equipo.

• Resultados esperados:

� El equipo UMG debe mostrar un mensaje de des registro para el MGC

MSoftX3000. � Se debe mostrar un estatus de fuera de servicio del UMG. � El equipo UMG debe mostrar un mensaje de registro en el MGC

MSoftX3000. � Se debe mostrar un estatus que indique que el UMG está trabajando de

manera correcta.

5.1.2.- Prueba de interacción y monitoreo constante (Heartbeat) entre el UMG 8900 SS160 y el MGC MSoftX3000.

36

• Objetivo de la prueba: verificar que el equipo UMG y el MGC MSoftX3000 están en constante comunicación y monitoreo entre ellos.

• Procedimiento:

� Verificar que los equipos estén conectados como se indica en el capítulo IV.

� Acceder al terminal de mantenimiento local y rastrear los mensajes intercambiados entre el UMG y el MSoftX3000.

� Desconectar y conectar de manera lógica el equipo UMG del MSoftX3000.


� El UMG envía un mensaje de pulso periódicamente hacia el MGC MSoftX3000.

� Cuando se desconecta el UMG se pierde la señal del pulso y al conectarlo de vuelta se establece el pulso nuevamente.

5.1.3.- Pruebas de llamadas completadas de manera exitosa.

• Objetivo de la prueba: verificar que cuando se realicen llamadas usando al UMG como tándem se completen las mismas de manera exitosa, negociando las tecnologías de señalización correspondientes a cada caso.

• Procedimiento:

� Conectar los equipos como se indica en el capítulo IV. � Acceder al Terminal de Mantenimiento Local y rastrear los

mensajes intercambiados entre el UMG y los equipos terminales. � Realizar llamadas haciendo uso de terminales que operen con cada

uno de los distintos protocolos de señalización.


37

� Que se completen de manera exitosa todas las llamadas realizadas usando el equipo UMG como tándem.

� Visualizar los mensajes enviados durante el establecimiento de las llamadas.

5.1.4.- Pruebas de llamadas no atendidas.

• Objetivo de la prueba: verificar que cuando un usuario reciba una llamada usando al UMG como tándem no atienda, se reciban los mensajes de forma correcta y se pueda finalizar la llamada.

• Procedimiento:





� Que no se atiendan las llamadas realizadas usando el equipo UMG como tándem.

� Visualizar los mensajes enviados durante el intento de establecimiento de las llamadas.

5.1.5.- Pruebas de llamadas con la línea ocupada.

• Objetivo de la prueba: verificar que cuando un usuario tenga la línea ocupada y reciba una llamada usando al UMG como tándem se reciban los tonos de línea ocupada de manera correcta y se pueda finalizar la llamada.

• Procedimiento:

� Conectar los equipos como se indica en el capítulo IV.

38

� Acceder al Terminal de Mantenimiento Local y rastrear los mensajes intercambiados entre el UMG y los equipos terminales.

� Realizar llamadas haciendo uso de terminales que operen con cada uno de los distintos protocolos de señalización.


� Que la línea a la que se está llamando esté ocupada y no se atienda la llamada.

� Visualizar los mensajes enviados durante el intento de establecimiento de las llamadas.

5.1.6.- Pruebas de llamadas en las que el usuario que es llamado cuelga.

• Objetivo de la prueba: verificar que cuando se realicen llamadas usando al UMG como tándem se completen las mismas de manera exitosa, que el usuario que es llamado cuelgue y descuelgue sin que se caiga la llamada.

• Procedimiento:





� Que se completen de manera exitosa todas las llamadas realizadas usando el equipo UMG como tándem y no se caiga la llamada si el usuario llamada cuelga.

� Visualizar los mensajes enviados durante el establecimiento de las llamadas.

39

CAPÍTULO VI.

6.- ANÁLISIS Y DISCUSIÓN DE RESULTADOS.

6.1.- Resultado de las pruebas del protocolo.

Tabla 2. Resumen de las pruebas realizadas.

Tipo de prueba Número de la prueba Terminal que llama Terminal llamado

Prueba de interconexión y control entre el UMG y el MGC

6.1.1.1 NA NA

Prueba de interacción y

monitoreo entre el UMG y el

MGC

6.1.1.2 NA NA

Prueba de llamada

completada, colgada por el usuario que

llama

6.1.2.1 R2 R2 6.1.2.2 SIP SIP 6.1.2.3 SS7 SS7 6.1.2.4 SS7 SIP 6.1.2.5 SS7 R2 6.1.2.6 SIP R2 6.1.2.7 SIP SS7 6.1.2.8 R2 SS7 6.1.2.9 R2 SIP

Prueba en las que el usuario llamado no

atiende

6.1.2.10 R2 R2 6.1.2.11 SS7 SS7 6.1.2.12 SIP SIP 6.1.2.13 SS7 SIP 6.1.2.14 SS7 R2 6.1.2.15 SIP R2 6.1.2.16 SIP SS7 6.1.2.17 R2 SS7 6.1.2.18 R2 SIP

Pruebas en las 6.1.2.19 R2 R2

40

que el usuario llamado no

atiende

6.1.2.20 SS7 SS7 6.1.2.21 SIP SIP 6.1.2.22 SS7 SIP 6.1.2.23 SS7 R2 6.1.2.24 SIP R2 6.1.2.25 SIP SS7 6.1.2.26 R2 SS7 6.1.2.27 R2 SIP

Prueba de llamada

completada, colgada por el usuario que es

llamado

6.1.2.28 R2 R2 6.1.2.29 SS7 SS7 6.1.2.30 SIP SIP 6.1.2.31 SS7 SIP 6.1.2.32 SS7 R2 6.1.2.33 SIP R2 6.1.2.34 SIP SS7 6.1.2.35 R2 SS7 6.1.2.36 R2 SIP

6.1.1.- Pruebas de la red.

6.1.1.1.- Prueba de interconexión y control del UMG 8900 SSM160 y el MGC MSoftX3000.

Teniendo los equipos configurados como se indica en el capítulo IV, se procedió a verificar que el UMG estuviera registrado en el MGC MSoftX3000. Una vez que se corroboró lo anterior, se desconectó de manera lógica el UMG y se observó una alarma en el LMT, a continuación se conectó el UMG nuevamente de manera lógica y se verificó que la alarma fue aclarada y el equipo se volvió a registrar de manera exitosa.

6.1.1.2.-Prueba de interacción y monitoreo entre el UMG 8900 SSM160 y el MGC MSoftX3000.

41

Con la configuración especificada en el capítulo IV, se procedió a interrumpir la comunicación entre el UMG y el MSoftX3000 y se observó una alarma en el LMT que indicaba la falla en el mensaje de interacción y monitoreo constante (Heartbeat). Una vez que se restableció la comunicación entre ambos equipos se aclaró la alarma generada en el LMT.

6.1.2.- Pruebas de llamadas entre terminales usando el UMG 8900 SSM 160 como tándem.

6.1.2.1.- Prueba de llamada entre terminales con señalización R2, completada y colgada por el usuario que inicia la llamada.

Para las pruebas se usaron 2 equipos terminales conectados a la central telefónica de CANTV, pertenecientes a la PSTN. Uno de ellos con terminación 1812 y el otro con terminación 6249. Se realizó una configuración en el MGC MSoftX3000 para que ambos usaran la troncal R2 como vía de comunicación y señalización durante la llamada. Se observa en primer lugar el intercambio de mensajes H.248 entre el UMG y el controlador MSoftX3000 que mediante esta vía asigna los recursos necesarios para la señalización en todos los escenarios. Por otra parte se puede ver el registro de mensajes con señalización R2 entre los terminales y el equipo UMG, la llamada se realiza de manera exitosa y se finaliza cuando cuelga el terminal que inició la llamada.

42

Figura 16. Intercambio de mensajes tipo H.248 entre el UMG y el MSoftX3000.

Fuente: Propia.

Figura 17. Mensajes entre terminales R2, llamada completada y finalizada por el terminal que inicia la llamada.

Fuente: Propia.

43

6.1.2.2.- Prueba de llamada entre terminales con señalización SIP, completada y colgada por el usuario que inicia la llamada.

Para esta prueba se utilizaron 2 equipos conectados al UA como se indica en el capítulo IV. Ambos terminales usan señalización SIP y se configuraron para que usaran el UMG como tándem. La llamada se realizó de manera exitosa y se finalizó cuando el equipo que inició la llamada colgó.

Figura 18. Mensajes entre terminales SIP, llamada completada y finalizada por el terminal que inicia la llamada.

Fuente: Propia.

6.1.2.3.- Prueba de llamada entre terminales con señalización SS7, completada y colgada por el usuario que inicia la llamada.

Al igual que en la prueba 6.1.2.1, se utilizaron los 2 teléfonos registrados en la central telefónica de CANTV pero en esta ocasión se configuraron para que ambos terminales usaran la troncal SS7 como medio de comunicación. Al igual que en la prueba anterior, se obtienen los mensajes H.248 entre el UMG y su controlador y también se obtuvieron los mensajes SS7 entre los terminales.

44

Figura 19. Mensajes entre terminales SS7, llamada completada y finalizada por el terminal que inicia la llamada.

Fuente: Propia.

6.1.2.4.- Prueba de llamada entre terminales con señalización SS7 y SIP, completada y colgada por el usuario que inicia la llamada (SS7).

Se configuró uno de los teléfonos pertenecientes a la PSTN para que usara la troncal SS7 y desde este se llamó a un terminal SIP conectado al UA como se indica en el capítulo IV. Como en esta prueba se necesitaron 2 tipos de señalizaciones distintas para que existiera la comunicación entre ambos terminales, se filtraron los mensajes en el LMT para que se mostraran por separado cada tipo de señalización siendo más sencilla la visualización de los mismos. Al igual que en las pruebas anteriores, la llamada se realizó de manera satisfactoria y se finalizó cuando colgó el terminal que inició la llamada (SS7).

Figura 20. Mensajes SS7, llamada completada entre SS7 y SIP.

Fuente: Propia.

45

Figura 21. Mensajes SIP, llamada completada entre SS7 y SIP.

Fuente: Propia.

6.1.2.5.- Prueba de llamada entre terminales con señalización SS7 y R2, completada y colgada por el usuario que inicia la llamada (SS7).

Se configuró uno de los teléfonos de la central de CANTV en la troncal SS7 y el otro en la central R2, se realizó la llamada desde el terminal SS7 hacia el R2 y se culminó la llamada cuando colgó el terminal que inició la llamada (SS7). Al igual que en la prueba 6.1.2.4 se filtraron los mensajes de cada tipo para verlos por separado y que fuera más sencillo observarlos.

Figura 22. Mensajes SS7. Llamada completada entre SS7 y R2.

Fuente: Propia.

46

Figura 23. Mensajes R2, llamada completada entre SS7 y R2.

Fuente: Propia.

6.1.2.6.- Prueba de llamada entre terminales con señalización SIP y R2, completada y colgada por el usuario que inicia la llamada (SIP).

Se realizó una llamada entre un terminal conectado y registrado en la UA y un terminal conectado a la PSTN, configurado para que usara la troncal R2. La llamada se inicia desde el terminal SIP, el terminal R2 atiende y la llamada es exitosa. La llamada finaliza cuando el terminal SIP cuelga. Al igual que en las pruebas 6.1.2.4 y 6.1.2.5 se filtraron los mensajes por tipos para observarlos por separado.

Figura 24. Mensajes SIP, llamada completada entre SIP y R2.

Fuente: Propia.

47

Figura 25. Mensajes R2, llamada completada entre SIP y R2.

Fuente: Propia.

6.1.2.7.- Prueba de llamada entre terminales con señalización SIP y SS7, completada y colgada por el usuario que inicia la llamada (SIP).

Se configuró de la misma manera que la prueba 6.1.2.4, con un terminal SIP y uno SS7 con la diferencia que en esta ocasión se inició la llamada desde el terminal SIP, la llamada tuvo éxito y finalizó cuando el terminal SIP colgó. Los resultados obtenidos fueron los mismos.

6.1.2.8.- Prueba de llamada entre terminales con señalización R2 y SS7, completada y colgada por el usuario que inicia la llamada (R2).

Se procedió de la misma manera que en la prueba 6.1.2.5, con la diferencia que esta la llamada se inició y se finalizó desde el terminal R2. Los resultados obtenidos fueron los mismos.

48

6.1.2.9.- Prueba de llamada entre terminales con señalización R2 y SIP, completada y colgada por el usuario que inicia la llamada (R2).

Se procedió de la misma manera que en la prueba 6.1.2.6, con la diferencia que esta la llamada se inició y se finalizó desde el terminal R2. Los resultados obtenidos fueron los mismos.

6.1.2.10.- Prueba de llamadas entre terminales con señalización R2, en las que el usuario llamado no atiende.

Se procedió de la misma manera que en la prueba 6.1.2.1, con la diferencia que la llamada no fue atendida y no se pudo completar. Los resultados obtenidos fueron los mismos.

6.1.2.11.- Prueba de llamadas entre terminales con señalización SS7, en las que el usuario llamado no atiende.

Se procedió de la misma manera que en la prueba 6.1.2.2 con la diferencia que en este caso la llamada no fue atendida y no se pudo completar. Se observan diferencias en los mensajes recibidos, por ejemplo no se recibe ningún mensaje ANM (Answer Message) ya que el teléfono no es atendido en ningún momento y no se establece la llamada.

Figura 26. Mensajes entre terminales SS7, llamada no atendida.

Fuente: Propia.

49

6.1.2.12.- Prueba de llamadas entre terminales con señalización SIP, en las que el usuario llamado no atiende.

Se procedió de la misma manera que en la prueba 6.1.2.3 con la diferencia que en este caso la llamada no fue atendida y no se pudo completar. Se observan diferencias en los mensajes recibidos, se puede ver un mensaje 480 “temporarily unavailable” que indica que el usuario no se encuentra disponible.

Figura 27. Mensajes entre terminales SIP, llamada no atendida.

Fuente: Propia.

6.1.2.13.- Prueba de llamada entre terminales con señalización SS7 y SIP, el usuario llamado (SIP) no atiende.

Se procedió de la misma manera que en la prueba 6.1.2.4 con la diferencia que en este caso la llamada no fue atendida por el terminal SIP y no se pudo completar. Los mensajes SIP recibidos tienen la diferencia que contienen el mensaje 480 y los mensajes SS7 no muestran el mensaje ANM que indica que el usuario atiende la llamada.

50

6.1.2.14.- Prueba de llamada entre terminales con señalización SS7 y R2, el usuario llamado (R2) no atiende.

Se procedió de la misma forma que en la prueba 6.1.2.5 con la diferencia que en este caso la llamada no fue atendida por el terminal R2. Los mensajes R2 recibidos son los mismos, y la diferencia en los mensajes SS7 es que no se observa el ANM que indica que el usuario atiende la llamada.

6.1.2.15.- Prueba de llamada entre terminales con señalización SIP y R2, el usuario llamado (R2) no atiende.

Se procedió de la misma forma que en la prueba 6.1.2.6 con la diferencia que en este caso la llamada no fue atendida por el terminal R2. Los mensajes R2 recibidos son los mismos, y la diferencia en los mensajes SIP es que se recibe un mensaje 487 “request cancelled” que indica que el tiempo de espera se terminó.

Figura 28. Mensajes SIP, llamada entre SIP y R2 no atendida por R2.

Fuente: Propia.

6.1.2.16.- Prueba de llamada entre terminales con señalización SIP y SS7, el usuario llamado (SIP) no atiende.

Se procedió de la misma forma que en la prueba 6.1.2.13 con la diferencia que en este caso la llamada no fue atendida por el terminal SS7. Los mensajes recibidos son iguales.

51

6.1.2.17.- Prueba de llamada entre terminales con señalización R2 y SS7, el usuario llamado (SS7) no atiende.

Se procedió de la misma forma que en la prueba 6.1.2.14 con la diferencia que en este caso la llamada no fue atendida por el terminal SS7. Los mensajes recibidos son iguales.

6.1.2.18.- Prueba de llamada entre terminales con señalización R2 y SIP, el usuario llamado (SIP) no atiende.

Se procedió de la misma forma que en la prueba 6.1.2.15 con la diferencia que en este caso la llamada no fue atendida por el terminal SIP. Los mensajes recibidos son iguales.

6.1.2.19.- Prueba de llamada entre terminales con señalización R2, el usuario al que se está llamando está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.10 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. Los resultados son los mismos, no se encuentran diferencias en los mensajes recibidos.

6.1.2.20.- Prueba de llamada entre terminales con señalización SS7, el usuario al que se está llamando está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.11 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. Los resultados son parecidos pero en esta prueba no se recibió ningún mensaje ACM (Address Complete Message) ya que apenas se intenta localizar al usuario se recibe un tono de ocupado y no se puede dar inicio a la llamada.

52

Figura 29. Mensajes entre terminales SS7, el usuario llamado está ocupado.

Fuente: Propia.

6.1.2.21.- Prueba de llamada entre terminales con señalización SIP, el usuario al que se está llamando está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.12 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. Los resultados son iguales, se recibe el mensaje 480 “temporarily unavailable” que indica que el usuario al que se está llamando no está disponible.

6.1.2.22.- Prueba de llamada entre terminales con señalización SS7 y SIP, el usuario llamado (SIP) está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.13 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. En este caso, en los mensajes SS7 solo se recibe un mensaje IAM (Initial Address Message) con la información de los terminales y posteriormente se recibe el mensaje tipo REL (Release) y RLC (Release Complete) para liberar los recursos ya que la llamada no se puede completar. En los mensajes SIP se recibe un mensaje 486 “Busy here” que indica que el usuario al que se está llamando está ocupado.

Figura 30. Mensajes SS7, llamada entre SS7 y SIP con SIP ocupado.

53

Fuente: Propia.

Figura 31. Mensajes SIP, llamada entre SS7 y SIP con SIP ocupado.

Fuente: Propia.

6.1.2.23.- Prueba de llamada entre terminales con señalización SS7 y R2, el usuario llamado (R2) está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.14 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. Los resultados son iguales, se reciben los mismos mensajes en ambas señalizaciones.

6.1.2.24.- Prueba de llamada entre terminales con señalización SIP y R2, el usuario llamado (R2) está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.15 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. En este caso, como el usuario llamado tenía configurado el servicio de contestadora no fue posible establecer el escenario y observar los mensajes.

6.1.2.25.- Prueba de llamada entre terminales con señalización SIP y SS7, el usuario llamado (SS7) está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.16 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. Loa resultados son los mismos para la señalización SS7 y para SIP existe la diferencia que se recibe el mensaje 486 “busy here” que indica que el terminal se encuentra ocupado.

54

6.1.2.26.- Prueba de llamada entre terminales con señalización R2 y SS7, el usuario llamado (SS7) está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.17 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. Los resultados obtenidos son iguales, se reciben los mismos mensajes.

6.1.2.27.- Prueba de llamada entre terminales con señalización R2 y SIP, el usuario llamado (SIP) está ocupado.

Se procedió de la misma forma que en la prueba 6.1.2.17 con la diferencia que en este caso el usuario al que se está llamando se encuentra ocupado y no atiende. Los resultados obtenidos son iguales para la señalización R2 y para SIP se obtiene el mensaje 486 “busy here”.

6.1.2.28.- Prueba de llamada entre terminales con señalización R2, completada y donde cuelga el usuario que es llamado.

Se procedió de la misma forma que en la prueba 6.1.2.1 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los resultados obtenidos en esta prueba son los mismos.

6.1.2.29.- Prueba de llamada entre terminales con señalización SIP, completada y donde cuelga el usuario que es llamado.

Se procedió de la misma forma que en la prueba 6.1.2.2 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los mensajes obtenidos son los mismos.

55

6.1.2.30.- Prueba de llamada entre terminales con señalización SS7, completada y donde cuelga el usuario que es llamado.

Se procedió de la misma forma que en la prueba 6.1.2.3 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. En esta caso se observa una diferencia con los mensajes recibidos, se ve un mensaje SUS (Suspended Message) que se refiere a un mensaje de suspensión que es enviado por el terminal llamado cuando cuelga e indica que la conexión aun se mantiene, una vez descuelga se reanuda la llamada.

Figura 32. Mensajes entre terminales SS7 donde cuelga quien es llamado.

Fuente: Propia.

6.1.2.31.- Prueba de llamada entre terminales con señalización SS7 y SIP, completada y donde cuelga el usuario que es llamado (SS7).

Se procedió de la misma forma que en la prueba 6.1.2.4 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los resultados obtenidos son iguales, observándose los mismos tipos de mensajes en ambas señalizaciones.

6.1.2.32.- Prueba de llamada entre terminales con señalización SS7 y R2, completada y donde cuelga el usuario que es llamado (R2).

56

Se procedió de la misma forma que en la prueba 6.1.2.5 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los resultados obtenidos son obtenidos son iguales para R2, en el caso de SS7 se ve una diferencia ya que se recibe un mensaje SUS que indica la suspensión del servicio cuando el terminal llamado cuelga, una vez descuelga se reanuda la llamada.

6.1.2.33.- Prueba de llamada entre terminales con señalización SIP y R2, completada y donde cuelga el usuario que es llamado (R2).

Se procedió de la misma forma que en la prueba 6.1.2.6 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los resultados obtenidos son los mismos, se reciben los mismos tipos de mensajes para ambas señalizaciones.

6.1.2.34.- Prueba de llamada entre terminales con señalización SIP y SS7, completada y donde cuelga el usuario que es llamado (SS7).

Se procedió de la misma forma que en la prueba 6.1.2.7 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los resultados son similares, en los mensajes SIP no se observa el mensaje 487 “request cancelled”. En los mensajes SS7 se observa un mensaje SUS que indica la suspensión del servicio cuando el usuario llamado cuelga, y al descolgar se reanuda la llamada.

6.1.2.35.- Prueba de llamada entre terminales con señalización R2 y SS7, completada y donde cuelga el usuario que es llamado (SS7).

Se procedió de la misma forma que en la prueba 6.1.2.8 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los resultados obtenidos fueron los mismos.

57

6.1.2.36.- Prueba de llamada entre terminales con señalización R2 y SIP, completada y donde cuelga el usuario que es llamado (SIP).

Se procedió de la misma forma que en la prueba 6.1.2.9 con la diferencia que en este caso el usuario al que se está llamando cuelga, luego descuelga y la llamada se mantiene hasta que el usuario que llama cuelga. Los resultados obtenidos fueron los mismos.

6.2.- Ventajas de la incorporación del equipo UMG a la red NGN de CANTV.

Incorporar el UMG 8900 SSM160 a la arquitectura de red NGN de CANTV para el servicio de Voz sobre IP aporta ventajas principalmente a nivel de interacción entre distintas tecnologías y tipos de señalización. CANTV ya cuenta con un UMG, pero la dedicación del nuevo equipo al servicio CPA IP permite algunas ventajas entre las que se encuentran:

• Permite conectividad e interacción entre equipos que trabajen con distintos tipos de señalización, funciona con los múltiples estándares existentes en la PSTN y en los servicios IP.

• Permite tener redundancia en la red sin la necesidad de un segundo equipo, reduciendo los costos y el espacio físico necesario de la red. El equipo trabaja con pares de tarjetas de red de modo activo/pasivo, por lo que si la tarjeta activa presenta alguna falla la tarjeta en estado pasivo se activa permitiendo de esta manera que no hayan interrupciones en el servicio.

• Permite la codificación de las señales de voz con distintos tipos de codificadores, facilitando la negociación entre los equipos enlazados con el UMG.

• Permite manejar la señalización y los paquetes de media de manera separada, optimizando el uso de la red ya que el contenido de media se envía de manera directa entre usuarios y la señalización van hacia el controlador de red.

58

• Permite la implementación de nuevos y mejorados servicios sin la necesidad de remplazar equipos, aporta una solución a la red de manera que no sea necesario modificar el esquema de la misma ni suplantar los equipos ya existentes.

• Permite aumentar el número de clientes que pueden usar el servicio, dando una mayor rentabilidad a la empresa.

6.3.- Desventajas de la incorporación del equipo UMG a la arquitectura de red NGN de CANTV.

Incorporar el UMG a la arquitectura de red NGN de CANTV para proveer el servicio de Voz sobre IP tiene algunas desventajas, entre ellas se encuentran:

• El UMG es dependiente de un controlador de red, en este caso el MSoftX3000 para asignar los recursos necesarios para el establecimiento de una llamada. Tal dependencia indica que si el controlador falla puede afectar el funcionamiento de la red aun si el UMG se encuentra en estado funcional.

• La tecnología y arquitectura de red con el esquema de maestro/esclavo entre el UMG y el controlador está evolucionando de forma rápida hacia una arquitectura en la que se tenga un solo equipo que realice ambas funciones, por lo que su vigencia puede ser un tanto limitada.

59

CONCLUSIONES.

La incorporación del UMG a la red NGN de CANTV para prestar el servicio de VoIP resulta beneficiosa para la empresa, ya que le proporciona versatilidad e interoperabilidad a la red de datos, flexibilidad por la gran cantidad de funciones y protocolos que maneja el equipo. Facilita la interconexión de distintas tecnologías de señalización, lo que se traduce en ingresos económicos y un mayor abanico de opciones para los clientes.

El equipo permite trabajar en la red de datos existentes para la transmisión de voz, sin tener que invertir en una estructura dedicada para prestar el servicio ni tener que sustituir parte de los equipos que posee la empresa actualmente. El UMG permite tener redundancia en la red, aportando robustez a la arquitectura y facilitando un mejor servicio a los clientes.

El servicio CPA IP ofrece una alternativa a las empresas a los servicios de telefonía tradicional, permitiendo el acceso a una red inteligente que es robusta, ofrece seguridad a sus clientes y disponibilidad. Esto representa una gran ventaja para aquellos clientes que necesitan o hacen uso de llamadas internacionales, siendo la CPA IP una alternativa óptima.

El protocolo de pruebas realizado en el Laboratorio de Redes de CANTV para la incorporación del UMG en la red de la empresa, se realizó enfocado en los distintos protocolos de señalización existentes en los equipos que maneja actualmente, de manera que al momento de la implementación del equipo y la puesta en marcha del servicio el cuerpo técnico que se encarga de esto tenga una guía de los puntos a probar para verificar el buen funcionamiento del equipo en la red. El protocolo de pruebas permite verificar el buen funcionamiento del equipo antes de ser incorporado a la red, disminuyendo las posibilidades de error a causa de alguna incompatibilidad. Las pruebas realizadas verifican la interoperabilidad del mismo, trabajando con un amplio abanico de protocolos de señalización y distintos tipos de codificación existentes, pudiendo adaptarse a las necesidades de la red, los equipos que la conforman y los clientes que hagan uso del servicio.

60

RECOMENDACIONES.

Para la incorporación del equipo UMG a la red NGN de CANTV para el servicio de VoIP se realizan las siguientes recomendaciones:

• Realizar la arquitectura de red detallada en el capítulo IV del presente trabajo de grado, de manera que se asegure el buen funcionamiento del equipo al momento de integrarlo a la red. Realizando la arquitectura detallada en el capítulo 4 se asegura la compatibilidad con los distintos protocolos necesarios para prestar el servicio de VoIP.

• Realizar un plan de mercadeo para proveerle a los clientes el servicio de VoIP, haciendo promoción al servicio y demostrando a los clientes las bondades y los posibles beneficios del mismo para las empresas.

• Realizar las pruebas para la implementación del servicio de VoIP al usuario particular y no solo a empresas como representa el servicio CPA-IP, buscar la forma de integrar el servicio para que cualquier usuario pueda tener acceso al mismo.

61

REFERENCIAS BIBLIOGRÁFICAS.

[1] UIT-T Q400-Q490 Especificaciones del Sistema de Señalización R2.

https://www.itu.int/rec/T-REC-Q.400-Q.490/es

[2] UIT-T Q700-Q790 Especificaciones del Sistema de Señalización N° 7.

https://www.itu.int/rec/T-REC-Q.700-199303-I/es

[3] RFC 3261 SIP: Session Initial Protocol.

https://www.ietf.org/rfc/rfc3261.txt

[4] UIT-T H.323 Packet-based Multimedia Communications System

https://www.itu.int/rec/T-REC-H.323/es

[5] ITU-T H.248.1 Gateway Control Protocol: Version 3

https://www.itu.int/rec/T-REC-H.248.1/es

[6] RFC 3550 RTP: A Transport Protocol for Real-Time Applications.

https://www.ietf.org/rfc/rfc3550.txt

[7] RFC 4566 SDP: Session Description Protocol.

https://tools.ietf.org/html/rfc4566

[8] UIT-T G.711 Modulación por Impulsos Modificados (MIC) de Frecuencias Vocales.

https://www.itu.int/rec/T-REC-G.711/es

[9] UIT-T G.723.1 Codificador de Voz de Doble Velocidad Para la Transmisión en Comunicaciones Multimedia a 5,3 y 6,3 kbit/s.

https://www.itu.int/rec/T-REC-G.723.1/es

62

[10] UIT-T G.729 Coding of Speech at 8 kbit/s Using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)

https://www.itu.int/rec/T-REC-G.729/es

63

BIBLIOGRAFÍA.

Veroes, Carlos. Mejora e implementación del sistema para gestionar alarmas para el monitoreo y control de la red NGN HUAWEI de CANTV. Caracas: Universidad Central de Venezuela, 2008.

Arquitectura de Redes Servicio Central Privada Automatica (CPA) sobre IP. Version 01. Arquitectura de Redes/CANTV. Caracas, 2011.

Interfaz de acceso para Centrales Privadas Automáticas (CPA). Gerencia de Planificación de Redes/CANTV. Caracas, 2006.

Plan nacional de señalización de la red de conmutación de CANTV. Version 01. Gerencia de Planifiación de Redes/ CANTV. Caracas, 2004.

64

Documents

INTEGRACIÓN DEL EQUIPO PASARELA DE MEDIOS UNIVERSAL