PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO – CHI LE

ESCUELA DE INGENIERÍA ELÉCTRICA

ESTUDIO DE FACTIBILIDAD TÉCNICO ECONÓMICA DE TECNOL OGÍAS

SBC EN MODO SIP-TRUNK

RODRIGO ALONZO BUSTOS FUENTES

INFORME FINAL DEL PROYECTO

PRESENTADO EN CUMPLIMIENTO

DE LOS REQUISITOS PARA OPTAR

AL TÍTULO PROFESIONAL DE

INGENIERO CIVIL ELECTRÓNICO

DICIEMBRE 2010

ESTUDIO DE FACTIBILIDAD TÉCNICO ECONÓMICA DE TECNOL OGÍAS

SBC EN MODO SIP-TRUNK

INFORME FINAL

Presentado en cumplimiento de los requisitos

para optar al título profesional de

Ingeniero Civil Electrónico

otorgado por la

Escuela de Ingeniería Eléctrica

de la

Pontificia Universidad Católica de Valparaíso

Rodrigo Alonzo Bustos Fuentes

Profesor Guía Sr. Francisco Javier Alonso Villalobos Profesor Correferente Sr. Juan Misael González Zepeda

DICIEMBRE 2010

ACTA DE APROBACIÓN

La Comisión Calificadora designada por la Escuela de Ingeniería Eléctrica ha

aprobado el texto del Informe Final del Proyecto de Titulación, desarrollado entre

el primer semestre de 2010 y el segundo semestre de 2010, y denominado

ESTUDIO DE FACTIBILIDAD TÉCNICO ECONÓMICA DE TECNOL OGÍAS SBC EN MODO SIP-TRUNK

Presentado por el Señor

Rodrigo Alonzo Bustos Fuentes

Francisco Javier Alonso Villalobos

Profesor Guía

Juan Misael González Zepeda

Segundo Revisor

Raimundo Arturo Villarroel Valencia

Secretario Académico

Valparaíso, Diciembre 2010

Dedicado a mis padres, a mi nueva familia,

A mis amigos,

A todos mis mentores que han guiado mi camino.

ESTUDIO DE FACTIBILIDAD TÉCNICO ECONÓMICA DE TECNOLOGÍAS

SBC EN MODO SIP-TRUNK

Rodrigo Alonzo Bustos Fuentes

Profesor Guía Sr. Francisco Javier Alonso Villalobos

RESUMEN El presente documento, detalla el desarrollo de una solución de estilo

comercial dentro de la empresa Dimension Data. Para llevar a cabo esta tarea se

realizan tres etapas muy delimitadas. Como primera etapa, se realiza un

reconocimiento completo la tecnología SBC, abarcando equipamiento,

empresas, modelos de funcionamiento y aplicaciones asociadas. En este

proceso también se da cuenta, de forma paralela, del desarrollo del protocolo

SIP para telefonía IP. Esto se denomina “recopilación de datos”. La segunda

etapa fue realizar una serie de experiencias en laboratorio con el cometido de

efectuar un análisis técnico de las distintas capacidades adjudicadas a los

equipos SBC.

La tercera etapa se refiere a la aplicación de las capacidades, centrando

todos los esfuerzos en desarrollar el concepto de movilidad sin perder las

propiedades que presenta el protocolo SIP-Trunk. Es así como se estudia el

concepto de modo “access”. Se realiza también un desarrollo del modelo que

necesita este sistema, finalizando con un desarrollo práctico, en laboratorio, que

permitió crear un servicio a través del estudio previo sobre las capacidades de

los equipos SBC, que cumple con ciertos estándares para ser comercializado al

usuario. Junto con el desarrollo de una solución para aplicación comercial, se

debió realizar un estudio evaluativo con respecto al financiamiento del proyecto.

Su factibilidad técnica debe ir acompañada de una económica, por lo que se

realiza su desarrollo integrando, en este estudio, desde el diseño del sistema

hasta su aplicación con el usuario.

vi

ÍNDICE

INTRODUCCIÓN 1

CAPÍTULO 1

CONCEPTOS Y DESARROLLOS EN EL CAMPO DE LA TELEFONÍA IP 3

1.1 ARQUITECTURA EN REDES DE SERVICIOS VoIP. 3

1.2 COMPARACION SISTEMAS DE GATEWAYS Y ACTUALES SISTEMAS SBC. 5

1.3 PUNTOS FUERTES DEL PROYECTO 6

1.3.1 Integración 6

1.3.2 Escalabilidad 6

1.3.3 Redundancia 7

1.3.4 Movilidad 7

1.4 OBJETIVO DEL PROYECTO 8

CAPÍTULO 2

CARATERÍSTICAS Y BENEFICIOS DE SIP-TRUNK POR SOBRE OTROS PROTOCOLOS SEÑALIZACIÓN 10

2.1 DEFINICIÓN DE PROTOCOLO SIP 10

2.1.1 Entidades SIP 11

2.1.1.1 User Agent 11

2.1.1.2 SIP proxy server 12

2.1.1.3 Registrar Server 12

2.1.1.4 Redirect Server 13

2.1.2 Mensajes SIP 14

2.1.2.1 Métodos SIP 15

2.1.2.2 Respuestas SIP 16

2.2 FUNCIONAMIENTO DE PROTOCOLO SIP 17

2.2.1 Transacciones SIP 17

2.2.2 Diálogos SIP 18

2.2.3 Esquema de señalización de una llamada SIP 19

2.2.3.1 Registro 19

2.2.3.2 Invitación a sesión 20

2.2.3.3 Término de sesión 21

2.2.3.4 Registro de ruta 21

2.3 PROTCOLOS RTP/RTCP Y SDP 22

2.3.1 Protocolo RTP/RTCP 22

2.3.2 Protocolo SDP 23

2.4 COMPARACIÓN CON PROTOCOLOS MEGACO (MGCP), SCCP, H.323, IAX2 (IAX), Y SS7 26

2.5 PROTOCOLO SIP-TRUNK 30

vii

CAPÍTULO 3

ANTECEDENTES SOBRE EQUIPAMIENTO SESSION BORDER CONTROLLER (SBC) 33

3.1 DEFINICIÓN DE SESSION BORDER CONTROLLER 33

3.2 PRINCIPALES PROVEEDORES DE EQUIPOS SBC Y SUS VISIONES EMPRESARIALES 34

3.2.1 Acme Packet 34

3.2.2 Cisco 35

3.2.3 Juniper 37

3.2.4 Genband 38

3.2.5 Ditech 39

3.2.6 InGate 42

3.2.7 Audiocodes 43

3.2.8 Stratus Telecomunications 45

3.2.9 Sansay 47

3.2.10 Metaswitch 49

3.3 PRINCIPALES MODELOS DE EQUIPOS SBC 50

3.3.1 Acme Packet 3800 y 4250 51

3.3.2 Cisco CUBE y modulo SBC para Cisco 7600 series 54

3.3.3 Juniper MX Series 55

3.3.4 Genband S3 y S9 58

3.3.5 Ditech PeerPoint C100 59

3.3.6 InGate SIParator 19,50,55,90,95 63

3.3.7 Audiocodes Mediant 1000 MSBG 64

3.3.8 Stratus telecommunications ENTICE Session Controller 66

3.3.9 Sansay VSX 67

3.3.10 Metaswitch DC-SBC 68

CAPÍTULO 4

CONCEPTOS Y APLICACIONES DE LOS EQUIPOS CON PRESTACIONES DE SESSION BORDER CONTROLLER 70

4.1 IP MULTIMEDIA SUBSYSTEM (IMS) 70

4.1.1 Capa de conectividad 71

4.1.2 Capa de control 72

4.1.3 Capa de servicios y aplicaciones 72

4.1.4 Protocolos de la arquitectura IMS 73

4.1.5 Arquitectura IMS en 3GPP 75

4.1.6 Procedimiento de registro 76

4.1.7 Servicios y aplicaciones 78

4.2 MODO PEERING Y ACCESS 79

4.2.1 Modo “peering” 79

4.2.1.1 “Peering” público 81

4.2.1.2 “Peering” privado 82

4.2.2 Modo “Access” 82

4.3 INTEROPERABILIDAD E INTER-FUNCIONAMIENTO 84

viii

4.3.1 Concentración de tráfico 84

4.3.2 Convergencia de servicios 85

4.3.3 “Translation” 85

4.3.4 “Transcoding” 86

4.4 ALTA DISPONIBILIDAD 86

4.4.1 Capacidad 87

4.4.2 Redundancia 87

4.4.3 Medición de capacidad y redundancia 88

4.4.4 “Load Balancing” 89

4.5 LEAST COST ROUTING (LCR) 90

4.5.1 Ciclo del Least Cost-Routing 91

4.5.2 Impacto de la Portabilidad Numérica Móvil en ambiente LCR de VOIP 92

4.6 BILLING 93

4.6.1 “Call Detail Records” (CDRs) 94

4.6.2 Call Accounting 95

4.7 VIRTUALIZACIÓN 95

CAPÍTULO 5

PLANIFICACIÓN E IMPLEMENTACIÓN DE SERVICIOS 98

5.1 OBJETIVOS DE SERVICIOS EN PRUEBA 98

5.2 DIAGRAMA ESTRUCTURAL EN CUMPLIMIENTO A SERVICIOS PROPUESTOS 98

5.3 ALCANCES DEL TRABAJO EN LABORATORIO 100

5.4 LABORATORIO 101

5.4.1 Equipamiento Físico 101

5.4.2 Herramientas informáticas 102

5.4.3 Diagrama de interconexión 104

5.5 INTEROPERABILIDAD 105

5.6 INTER-FUNCIONAMIENTO 107

5.7 VIRTUALIZACIÓN 108

CAPÍTULO 6

PLAN DE PRUEBAS Y RESULTADOS EN RED TELEFÓNICA IP 110

6.1 PRUEBAS DE CONECTIVIDAD 110

6.2 PRUEBAS DE SEVICIOS DE TELEFONÍA IP 111

6.3 RESULTADOS DE PRUEBAS DE SERVICIOS DE TELEFONÍA IP 114

CAPÍTULO 7

SERVICIOS SIP EN MODO ACCESS: CONCEPTOS Y ESTRUCTRAS 120

7.1 CONCEPTO DE MODO ACCESS EN TELEFONÍA IP 120

7.2 PROPOSICIÓN DE INTEROPERABILIDAD ENTRE MODO ACCESS Y MODO PEERING: SOLUCIÓN DE MOVILIDAD. 121

7.3 DIAGRAMA ESTRUCTURAL DE SOLUCIÓN ACCESS E INTEGRACIÓN CON SIP-TRUNK. 122

ix

CAPÍTULO 8

SERVICIOS SIP EN MODO ACCESS: IMPLEMENTACIONES Y PRUEBAS 127

8.1 LABORATORIO: MODO ACCESS 127

8.1.1 Equipamiento Físico y de software: Modo “access” con “SIP-register” y “Peering” con “SIP-trunk” 127

8.1.2 Herramientas informáticas 128

8.2 DIAGRAMA DE INTERCONEXIÓN: MODO “ACCESS” 130

8.3 LABORATORIO: MODO “ACCESS/PEERING” VIRTUALIZADO 133

8.4 LABORATORIO: MODO “ACCESS/PEERING” DESVIRTUALIZADO 134

8.5 RESULTADOS Y COMENTARIOS DE SOLUCION INTEGRAL SIP ACCESS/PEERING 135

CAPÍTULO 9

EVALUACIÓN ECONÓMICA DEL PROYECTO 138

9.1 CARACTERÍSTICAS CONTEMPLADAS DENTRO DE LA EVALUACIÓN 138

9.2 ESCENARIO CONTEMPLADO PARA LA EVALUACIÓN 140

9.3 COSTOS Y BENEFICIOS EVALUADOS 141

9.4 RESULTADOS DE EVALUACIÓN COMERCIAL DE LA SOLUCIÓN 145

CONCLUSIONES 148

REFERENCIAS CITADAS 150

APÉNDICE A

INTEROPERABILIDAD E INTER-FUNCIONAMIENTO A-2

APÉNDICE B

LOAD BALANCING, LEAST COST ROUTING y VIRTUALIZACIÓN B-2

APÉNDICE C

MODO ACCESS/PEER C-2

x

GLOSARIO DE TÉRMINOS

• 3G (3rd Generation): tercera-generación de transmisión de voz y datos a través de telefonía móvil. • 3GPP (3rd Generation Partnership Project): acuerdo de colaboración en tecnología de telefonía móvil. • All-IP (Internet Protocol): término que se refiere a la evolución de la actual infraestructura de redes de telecomunicación y acceso telefónico. • Asterisk: es un programa de software libre (bajo licencia GPL) que proporciona funcionalidades de una central telefónica (PBX). • B2B (Back to Back): Concepto de equipos que son utilizados para transmitir mensaje, y filtrarlos si es necesario. • Blacklist: Lista de bloqueo a numeración previamente configurada en una PBX. • CAC (Call Admission Control): previene la sobresuscripción de redes VoIP al sistema como suerte de acuerdo para manejar el ancho de banda. • Call manager: Realiza un seguimiento de todos los componentes de la red interna VoIP. • Carrier grade o class: portadora de calidad asegurada. • Cluster: Pequeño grupo de algo. • CNAME (Canonical Name): Es un tipo de registro de recursos en el Domain Name System (DNS) que especifica que el nombre de dominio es un alias de otro. • Codecs: es un dispositivo o programa de ordenador capaz de codificar y / o decodificación de un flujo de datos digitales o señales. • Diameter: Es un protocolo de red para la autenticación de los usuarios que se conectan remotamente a la Internet a través de la conexión por línea conmutada. • DNS (Domain Name System): Es un sistema de nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado a internet o a una red privada. • DNS SRV (Domain Name System Service): Permite indicar los servicios que ofrece el dominio. • DoS (Denial of Service): es un ataque a un sistema de computadoras o red que causa que un servicio o recurso sea inaccesible a los usuarios legítimos. • DTMF (Dual Tone Multi-Frequency): En telefonía es el sistema de marcación por tonos, también llamado sistema multi-frecuencial. • E.164: es una recomendación de la UIT que asigna a cada país un código numérico (código de país) usado para las llamadas. • E1: Es un formato de transmisión digital con un servicio de 30 líneas telefónicas digitales para comunicaciones. • Firewall: Software utilizado en redes de computadoras para controlar las comunicaciones, permitiéndolas o prohibiéndolas.

xi

• Gatekeeper: Traduce números telefónicos a direcciones IP, utilizado normalmente en H.323. • Gateway: Se trata del enlace con la red telefónica tradicional, actuando de forma transparente para el usuario, también llamado así en telefonía IP. • Hard-IPphone: Teléfono IP con estructura física a la de un teléfono actual de la PSTN. • HTTP (Hypertext Transfer Protocol): Protocolo web para señalizar acciones de páginas en Internet. • IEEE 802.1Q: Permite a múltiples redes compartir de forma transparente el mismo medio físico. • IOS (Internetwork Operating System): Sistema operativo creado por Cisco Systems para programar y mantener equipos de interconexión de redes informáticas. • IPsec (Internet Protocol Security): Conjunto de protocolos cuya función es asegurar las comunicaciones sobre el IP. • IPv4 (Internet Protocol version 4): Primera versión del protocolo que se implementó extensamente, usa direcciones de 32 bits. • IPv6 (Internet Protocol version 6): Nueva versión de IP y diseñada para reemplazar a la versión 4, usa direcciones de 128 bits. • ISUP (ISDN (Integrated Services Digital Network) user part): Protocolo de circuitos conmutados, parte de la señalización SS7. • Linux Fedora: Sistema operativo de distribución gratis. • MMUSIC: • Multihoming: Se define como la conexión de un host o sitio a más de un ISP, en el caso de la telefonía IP a un ITSP. • OSI (Open Systems Interconnection): Modelo genérico de redes basado en modelo de capas. • Packetcable: Es un consorcio de la industria fundada por CableLabs con el objetivo de definir normas para la industria de la televisión por cable módem. Así llego a convertirse en una norma competente como IMS. • Peer-to-peer: Método de transferencia de datos de una red privada a otra. • Ping: Utilidad de administración de red usada para comprobar el enlace a una dirección especifica dentro de una red. • POP (Point Of Presence): Es un punto de demarcación artificial o punto de interconexión entre las entidades de comunicación. • PSTN (Public Switched Telephone Network): Es una red de comunicación diseñada primordialmente para la transmisión de voz, aunque pueda también transportar datos. • RedVoiss: Empresa chilena dedicada profesionalmente como ITSP. • RFC 1889: Hace referencia el protocolo RTP. • RFC 3015: Define el protocolo MEGACO. • RFC 3261: Actual definición de SIP. • RFC 3435: Define informalmente MGCP. • RFC 4458: Define el SIP voice-mail URI.

xii

• RFC 4480: Define Presencia y Mensajería Instantánea a través de SIP. • RFC 4566: Define el protocolo SDP • RFC 3903: Define una lista de peticiones de métodos SIP • RJ-45: Es una interfaz física comúnmente usada para conectar redes de cableado estructurado. • Roaming: Completa libertad de movimiento entre las áreas de cobertura de las diferentes empresas de telecomunicaciones. • RS-232: Es una interfaz que designa una norma para el intercambio serie de datos binarios entre un DTE (Equipo terminal de datos) y un DCE (Data Communication Equipment, Equipo de Comunicación de datos). • SIGTRAN (asociado a “Signaling Transport”): Es el nombre del grupo de trabajo de la IETF que ha desarrollado una serie de protocolos que permiten transportar señalización SS7 por redes IP. • SMTP (Simple Mail Transfer Protocol): Es un protocolo de la capa de aplicación. Protocolo de red basado en texto utilizado para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos. • Softphone: Teléfono IP emulado en un computador. • SONET (Synchronous Optical Network): Es un estándar para el transporte de telecomunicaciones en redes de fibra óptica. • SSH (Secure Shell): Sirve para acceder a máquinas remotas a través de una red. • SSH2 (Secure Shell version 2): Version 2 del protocolo SSH, reemplazando a su predecesor, actualmente muy usado. • STUN (Simple Traversal of UDP (User Datagram Protocol) through NATs (Network Address Translation)) Server: Servidor implementado con un protocolo de red del tipo cliente/servidor que permite a clientes NAT encontrar su dirección IP pública. • TCP/IP (Transmission Control Protocol/Internet Protocol): Familia de protocolos de Internet. Es un conjunto de protocolos de red en los que se basa Internet y que permiten la transmisión de datos entre redes de computadoras. • TELCO (Telephone Company): Es un nombre genérico utilizado para designar a una gran empresa de telecomunicaciones. • TELNET (ref. a Telecommunications Network): Es el nombre de un protocolo de red que sirve para acceder mediante una red a otra máquina para manejarla remotamente. • TLS (Transport Layer Security): Es un protocolo criptográfico que proporciona comunicaciones seguras por una red, comúnmente Internet. • UMTS: Es una de las tecnologías usadas por los móviles de tercera generación, sucesora de GSM • URI (Uniform Resource Identifier): Es una cadena corta de caracteres que identifica inequívocamente un recurso. • WAN (Wide Area Network): Son redes que se extienden sobre un área geográfica extensa.

xiii

• WEB GUI (Graphical User Interface): Consiste en proporcionar un entorno visual sencillo para permitir la comunicación con el equipo a configurar de forma remota. • ROI (Return On Investment): Es un porcentaje que se calcula en función de la inversión y los beneficios obtenidos para cuantificar la viabilidad de un proyecto. Se utiliza junto al VAN y a la TIR. • VAN (Valor Actual Neto): Es un procedimiento que permite calcular el valor presente de un determinado número de flujos de caja futuros, originados por una inversión. • TIR (Tasa Interna de Retorno): está definida como la tasa de interés con la cual el valor actual neto o valor presente neto (VAN o VPN) es igual a cero. Se utiliza para decidir sobre la aceptación o rechazo de un proyecto de inversión.

xiv

ACRÓNIMOS

AAA: Authentication, Authorization and Accounting ACL: Access Control List ADPCM: Adaptive Differential Pulse Code Modulation AKA: Authentication and Key Agreement ANSI: American National Standards Institute ARP: Address Resolution Protocol B2BUA: Back to Back User Agent BCP: Best Current Practice BFD: Bidirectional Forwarding Detection BGF: Border Gateway Function BGP: Border Gateway Protocol BRI: Basic Rate Interface CAC: Call Admission Control CAM: Content Addressable Memory CDR: Call Detail Record CLI: Command Line Interface CNG: Comfort Noise Generator CUBE: Cisco Unified Border Element CUCM: Cisco Unified Call Manager DHCP: Dynamic Host Configuration Protocol DSCP: Differentiated Service Code Point DNS: Domain Name System DoS: Denial of Service DSCP: Differentiated Services Code Point DTMF: Dual-Tone Multi-Frequency ETSI: European Telecommunications Standards Institute FCC: Federal Communications Commission FRR: Fast Re-Route FTP: File Transfer Protocol FXO: Foreign Exchange Office FXS: Foreign Exchange Station GENI: Global Environment for Network Innovations GRES: Graceful Routing Engine Switchover GSM: Groupe Special Mobile HA: High Aviability HDLC: High-Level Data Link Control HTTP: Hypertext Transfer Protocol HTTPS: Hypertext Transfer Protocol Secure IAD: Integrated Access Devices IBCF: Interconnection Border Control Function IBGF: Interconnection Border Gateway Function IETF: Internet Engineering Task Force IMS: IP Multimedia Subsystems

xv

IOS: Internetwork Operating System IPDC: Internet Protocol Datacast ISDN: Integrated Services Digital Network ISSU: In Service Software Upgrade ISUP: Integrated Services Digital Network User Part ITSP: Internet Telephony Service Providers ITU: International Telecommunication Union ITU-T: Telecommunication Standardization Sector IXP: Internet Exchanges Points L2TP: Layer 2 Tunneling Protocol LAN: Local Area Network LCR: Least Cost Routing MAC: Media Access Control MG: Media Gateway MGC: Media Gateway Controller MIB: Management Information Base MMUSIC: Multiparty Multimedia Session Control MNP: Movility Number Portability MSF: Multiservice Switching Forum MSX: Multi-protocol Session Exchange NAP: Network Access Point NAT: Network Address Translation NGN: Next Generation Networking NSF: National Science Foundation NSR: Non-Stop Routing OEM: Original Equipment Manufacturer OSI: Open System Interconnection OSPF: Open Shortest Path First PAT: Port Address Translation PBX: Private Branch Exchange PCM: Pulse Code Modulation PCSCF: Proxy Call Session Control Function POP: Point Of Presence PPP: Point to Point Protocol PPPoE: Point to Point Protocol over Ethernet PPTP: Point to Point Tunneling Protocol PRI: Primary Rate Interface PSTN: Public Switching Telfonic Network QoS: Quality of Service RADIUS: Remote Authentication Dial In User Service RAS: Registration, Admission and Status RFC: Request for Comments RIP: Routing Information Protocol RSVP: Resource Reservation Protocol RTP: Real Time Protocol

xvi

SAC: Session Admission Control SCCP: Skinny Call Control Protocol SCP: Services Code Point SFTP: Secure File Transfer Protocol SGCP: Simple Gateway Control Protocol SIGTRAN: Signaling Transport SIP: Session Initiation Protocol SLA: Service Level Agreement SMTP: Simple Mail Transfer Protocol SNMP: Simple Network Management Protocol SOAP: Simple Object Access Protocol SPX: Sequenced Packet Exchange SRTP: Secure Real-time Transport Protocol SS7: Signaling System No. 7 SSH: Secure Shell Subtel: Sub-secretaría de Telecomunicaciones TCAP: Transaction Capabilities Application Part TCP: Transmission Control Protocol TDM: Time Division Multiplex TISPAN: Telecoms & Internet converged Services & Protocols for Advanced Networks TLS: Transport Layer Security ToS: Type of Service UA: User Agent UAC: User Agent Client UAS: User Agent Server UDP: User Datagram Protocol UMTS: Universal Mobile Telecommunications System URI: Uniform Resource Identifier VAD: Voice Activity Detection VGA: Video Graphics Array VLAN: Virtual Local Area Network VoIP: Voice over IP VPLS: Virtual Private LAN Service VRRP: Virtual Router Redundancy Protocol WAN: Wide Area Network XML: Extensible Markup Language

xvii

LISTADO DE FIGURAS

Figura 2-1: Estructura protocolar para sistemas VoIP según modelo OSI 11

Figura 2-2: Estructura de protocolo de “Redirect Server”. 13

Figura 2-3: Estructura de trama mensaje SIP. 14

Figura 2-4: Ejemplo de transacción 18

Figura 2-5: Ejemplo de dialogo 19

Figura 2-6: Diálogo de registro 19

Figura 2-7: Diálogo de invitación a sesión 20

Figura 2-8: Diálogo de término de sesión 21

Figura 2-9: Diálogo de término de sesión con registro de ruta en “Proxy” 22

Figura 2-10: Opciones de atributos ofrecidos por SDP para sesion 24

Figura 2-11: Opciones de atributos ofrecidos por SDP de tiempo 24

Figura 2-12: Opciones de atributos ofrecidos por SDP de “media” 25

Figura 2-13: Mensaje “invite” común, enmarcado en rojo ejemplo de SDP 25

Figura 3-1: Vista frontal del equipo SBC Acme Packet serie 4000 53

Figura 3-2: Vista posterior del equipo SBC Acme Packet serie 4000 53

Figura 3-3: Vista Frontal de PeerPoint C100 de Ditech 62

Figura 3-4: Vista Frontal de Mediant 1000 MSBG de Audiocodes 66

Figura 4-1: Diagrama de Arquitectura IMS separada por Capas. 70

Figura 4-2: Procedimiento de registro en IMS. 76

Figura 4-3: Diagrama de ejemplo para modo “Peering” 79

Figura 4-4: Diagrama de ejemplo para modo Access 83

Figura 4-5: Diagrama de flujo sobre capacidad de redundancia 88

Figura 4-6: Diagrama de flujo sobre ciclo de un proceso LCR 91

Figura 5-1: Diagrama estructural de servicios 99

Figura 5-2: Diagrama de sistema físico, enlace de datos, y red del Laboratorio 104

Figura 5-3: Escenario de implementación de Interoperabilidad 106

Figura 5-4: Escenario de implementación de Inter-funcionamiento 107

Figura 5-5: Escenario de implementación de Virtualización 109

Figura 6-1: Diagrama explicativo para resolver pruebas de conectividad, orientado a SBC’s Acme Packet 111

Figura 6-2: Diagrama de pruebas para interoperabilidad 112

Figura 6-3: Diagrama de pruebas para inter-funcionamiento 112

Figura 6-4: Diagrama de pruebas para Virtualización 113

Figura 6-5: Diagrama de resultados para Interoperabilidad 114

Figura 6-6: Diagrama de resultados de señalización para Interoperabilidad 115

Figura 6-7: Diagrama de resultados para Inter-funcionamiento 116

Figura 6-8: Diagrama de resultados para virtualización completa 117

Figura 6-9: Diagrama de resultados para “Load Balancing” 118

Figura 6-10: Diagrama de flujo de proceso “Load Balancing” 118

Figura 6-11: Diagrama de resultados para Least Cost Routing 119

Figura 6-12: Diagrama de flujo de proceso Least Cost Routing 119

xviii

Figura 7-1: Estructura conceptual: modo “Access” 122

Figura 7-2: Diagrama de señalización SIP-register 123

Figura 7-3: Estructura conceptual: modo “access/peering” virtualizado 124

Figura 7-4: Estructura conceptual: modo “access/peering” direferenciado por interfaces físicas 125

Figura 8-1: “Smartphones” y “Softphones” usados para pruebas de interoperabilidad “Access/Peering” 128

Figura 8-2: Diagrama de sistema físico, enlace de datos, y red para implementación “Access” 130

Figura 8-3: Ejemplos de vistas de configuración de “SIP-clients”, en “softphones” y “smartphones” respectivamente. 132

Figura 8-4: Diagrama de sistema físico, enlace de datos, y red para implementación “Access/Peering” Virtualizados 133

Figura 8-5: Diagrama de sistema físico, enlace de datos, y red para implementación “access/peering” diferenciados por interfaces 135

Figura 9-1: Relación de ROI con Costos y Beneficios 139

Figura 9-2: Relación de VAN e Ingresos 139

Figura 9-3: Relación para determinar punto TIR en la curva VAN 139

Figura 9-4: Gráfico resumen de costos por items 142

Figura 9-5: Gráfico resumen de beneficios 144

Figura 9-6: Gráfico con resultados del ROI 145

Figura 9-7: Gráficos con resultados de indicadores de VAN y VAN acumulado 147

xix

LISTADO DE TABLAS

Tabla 2-1: Comparativa entre SIP y H.323 29

Tabla 9-1: Costos de inversión inicial y operación anual (en $US) [13] 141

Tabla 9-2: Resumen de Costos agrupados por ítems (en $US) [13] 142

Tabla 9-3: Tabla de Beneficios y proyección de ingresos [13] 143

Tabla 9-4: Items de beneficios 144

Tabla 9-5: Valores de resultados del ROI 145

Tabla 9-6: Flujos de caja del proyecto, valores de indicadores económicos 146

Tabla A-1: Lista de comandos de equipo Acme Packet para solución de interoperabilidad e interfuncionamiento A-2

Tabla A-1: Lista de comandos de equipo Acme Packet para solución de interoperabilidad e interfuncionamiento (continuación) A-3

Tabla A-1: Lista de comandos de equipo Acme Packet para solución de interoperabilidad e interfuncionamiento (continuación) A-4

Tabla A-2: Lista de comandos de equipo UC 520 para solución de interoperabilidad e interfuncionamiento A-5

Tabla B-1: Lista de comandos de equipo Acme Packet para solución de Load Balancing B-2

Tabla B-1: Lista de comandos de equipo Acme Packet para solución de Load Balancing (continuación) B-3

Tabla B-2: Lista de comandos de equipo Acme Packet para solución de LCR B-3

Tabla B-3: Lista de comandos de equipo Acme Packet para solución de Virtualización B-4

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de “Access/Peer” C-2

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de “Access/Peer” (continuación) C-3

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de “Access/Peer” (continuación) C-4

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de “Access/Peer” (continuación) C-5

INTRODUCCIÓN

Las actuales y aún vigentes redes de circuitos conmutados en Chile han

cumplido con un ciclo importante en las comunicaciones telefónicas, pero es

evidente la cantidad de antecedentes que muestran a esta tecnología ya en su

límite evolutivo, hablando en términos de escalabilidad, costos, eficiencia del

ancho de banda, y flexibilidad de la red.

La respuesta a las debilidades actuales de la red telefónica pública

conmutada (“PSTN”), posiblemente se encuentran en el desarrollo de la

“Telefonía IP”. El término de Telefonía IP se aplica a toda red de voz

paquetizada, soportada sobre redes de área amplia (“WAN”), las cuales cumplen

las veces de la “PSTN” en forma parcial y/o total.

Si se deja de lado las debilidades, y se presta atención a las ventajas de

convergencia que presenta la Telefonía IP, se habla de, una única red (IP),

gestión integrada de todos los servicios, soporte multiservicio, ó sea, una forma

eficiente de transporte.

Estos enunciados reafirman no sólo una mejoría en las tecnologías de la

información respecto de la telefonía, sino que también un cambio en el manejo

de redes de datos, video, y servicios digitales IP en general.

Gracias al avance tecnológico en el transporte de información a nivel

físico, es que se puede lograr el desarrollo de las posteriores capas, y esta área

no es la excepción. Es así como el tema de las tecnologías SBC amplía la visión

de realización de toda idea de convergencia, administración, soporte, y costo

sobre redes comunicaciones. Aún así, hay cosas que se deben rescatar de la

tecnología precedente. Teniendo lo anterior presente, el concepto de separar los

canales de datos de información y señalización entre el transmisor y el receptor

de estos datos, resulta fundamental en el cometido de los puntos enumerados en

el párrafo anterior. Es por ello que se toma bajo estudio la solución del protocolo

2

de señalización SIP en modo Trunk (“SIP-TRUNK”), por presentar características

evolutivas altas, aptas para mantenerse vigentes en el tiempo.

Sin embargo, no por ser la solución a analizar, se debe desechar otras

soluciones puestas ya en práctica, como el caso de protocolos VoIP como

H.323, IAX, IAX2, o hasta el mismo protocolo utilizado durante años SS7. Lo

mismo en cuanto a desarrollo de “hardware”, se debe fundamentar el cambio de

equipos para la Telefonía IP.

Así se espera tratar de forma acabada y útil, un estudio que encuentre la

mejor solución para distintas necesidades que requieran los negocios de servicio

en redes.

CAPÍTULO 1

CONCEPTOS Y DESARROLLOS EN EL CAMPO DE LA TELEFONÍA IP

1.1 ARQUITECTURA EN REDES DE SERVICIOS VoIP.

Los servicios de telefonía IP siempre están ligados a tres conceptos

medulares sobre su funcionamiento: Señalización, Control y “Media”, estos

conceptos no escapan a ningún tipo de sistema o configuración diseñados

actualmente. Estos tres conceptos son además complementarios en los objetivos

de la telefonía IP. Así cada sistema diseñado le da una jerarquía de importancia

distinta dependiendo de los objetivos específicos que se desean caracterizar por

sobre los demás desarrollos en el campo VoIP. Las definiciones más adecuadas

para cada concepto son las siguientes:

• Señalización: Este término alude a la manera correcta de dar conocer la

existencia de dos equipos terminales de telefonía IP dentro de una red

VoIP, expresar la intención de ocupar un medio por parte de uno de los

equipos terminales y luego la respuesta por parte del equipo peticionado

dentro de la red VoIP. Todo esto quiere decir que se alerta las estaciones

terminales y a los elementos de la red su estado y la responsabilidad

inmediata que tienen al establecer una conexión.

• Control: Término que sigue el tratamiento de la señal VoIP luego de la

señalización. La labor de este proceso establecer un estándar en la

calidad. Puntos importantes a destacar en el control de los servicios de

Telefonía IP están, la monitorización de la calidad de servicio y control de

la congestión, identificación de la fuente de señalización, sincronización

4

entre flujos de multimedia, e información de control escalable con el

cometido de no exceder lo necesario en ocupación de ancho de banda.

• “Media”: Proporciona funciones para redes de extremo a extremo

adecuadas para aplicaciones que transmiten datos en tiempo real, como

audio, vídeo, o datos provenientes de una simulación, sobre redes

“unicast” o “multicast”.

En la Figura 1-1 se aprecia el formato más básico del principio de

sistemas de telefonía IP, donde los anteriores conceptos trabajan en conjunto

para que el servicio de telefonía IP funcione de acuerdo a estándares

recomendados por grandes instituciones formadas por entendidos y expertos en

el tema de VoIP y en comunicaciones en general, es el caso de la IEEE e IETF.

Figura 1-1 Representación básica de un sistema de telefonía IP

5

1.2 COMPARACION SISTEMAS DE GATEWAYS Y ACTUALES SISTEMAS SBC.

Es claro que como muchas tecnologías, la telefonía IP ha mostrado

durante las últimas décadas un avance increíble en su evolución como sistema

de comunicación. Es cierto como se aprecia en la Figura 1-1 los “gateways”

cumplen una tarea muy importante en la traducción de llamadas desde la PSTN

a las redes IP, pero el control, la seguridad, y la calidad de las sesiones

realizadas sobre IP punto a punto, no son respaldas por “Gateway”, lo que se

traduce en puntos en contra para los sistemas VoIP. Es así que la idea de un

controlador diseñado no sólo para servir de pasarela entre el mundo PSTN y el

VoIP, se materializa en los “Session Border Controller” (SBC).

Se desarrolla una comparación conceptual entre ambos métodos. Los

SBC son una respuesta evolutiva en el camino hacia la telefonía IP sin tramos de

comunicación con telefonía convencional. La mayor ventaja es por supuesto el

costo de realizar una llamada netamente IP y una llamada hacia la PSTN, la

primera opción tiene un costo cero actualmente, por otra parte la capacidad de

realizar llamadas desde cualquier parte con una conexión a Internet, muy

atractivo para usuarios que viajan bastante, no necesitan de servicios externos

para compatibilizar un usuario VoIP al estar en una red mundial como lo es

Internet, con ello mismo la telefonía IP presenta más servicios extras sin cobrar

por ellos, por ejemplo; identificación de llamadas, servicio de llamada en espera,

servicio de transferencia de llamada. La principal razón de reconocer como

superior el sistema VoIP en todo el tramo de comunicación por sobre la telefonía

dual es la modularidad y escalabilidad, ósea, la capacidad de dar cada vez

mayor valor agregado al sistema por estar ligado a la red de datos (Internet), y la

facilidad de crear, trasladar o eliminar líneas de comunicación telefónica dentro

de estas redes.

6

1.3 PUNTOS FUERTES DEL PROYECTO

Dentro de las capacidades a desarrollar sobre el proyecto, existe una

fuerte tendencia a los conceptos genéricos de integración, escalabilidad,

redundancia, y movilidad. En estos puntos fuertemente aplicados en las actuales

tecnologías, pero aún con un gran campo de aplicación y evolución en

tecnologías renovadas, como es el caso de este proyecto, la telefonía.

1.3.1 Integración

Concepto base en el desarrollo de cualquier tecnología que sea

sustentable en el tiempo en el actual periodo tecnológico en desarrollo, todo

sistema actual apunta a ello. El significado de la integración es principalmente la

capacidad de un sistema de ser evolutivo, flexible, vigente, compatible con su

entorno presente y futuro de trabajo. Aplicar el concepto de integración es vital

en sistemas telefónicos, por el simple hecho de que es una tecnología usada por

más de cuatro décadas, y por lo tanto se producen fuertes dependencias

tecnológicas con el presente sistema telefónico. La idea de telefonía IP no es

una evolución de la telefonía conmutada actual, es más bien una revolución, es

por ello que el concepto de integración es tan fuerte, este ayuda a suavizar la

transformación de la técnica de comunicación telefónica a IP. El entender el

concepto de integración ayuda a la compresión sobre la cantidad de soluciones

que conlleva la telefonía IP en beneficio temporal a la actual telefonía

conmutada.

1.3.2 Escalabilidad

A partir de la integración, consecuentemente se derivan muchos otros

conceptos. La escalabilidad es un compromiso del sistema con el crecimiento del

7

sistema implementado, esto apunta a la habilidad para extender el margen de

operaciones, manejar el crecimiento continuo de trabajo de manera fluida, o bien

para estar preparado para hacerse más grande, sin perder calidad en los

servicios ofrecidos, es decir, realizar el diseño del sistema en función de un plan

previo de crecimiento. En aplicaciones telefónicas, este es un punto vital, por ser

un servicio de uso masivo. Se aprecia en sistemas telefónicos IP, que este

concepto es superado con respecto a la telefonía conmutada actual.

1.3.3 Redundancia

Es un concepto bastante amplio que abarca prácticamente todas las

capas de comunicaciones en redes. La referencia de este concepto apunta a la

redundancia física, se habla entonces de respaldo, alta disponibilidad (se dedica

un apartado en la sección 4.4 a este concepto), entre otros. Redundancia es una

estrategia que genera un factor conmutativo en el sistema, es decir, se refuerza

el sistema con más de un método idéntico o distinto de comunicación al original

diseñado en él. El concepto aplica en telefonía IP en aspectos de seguridad y

confiabilidad. Se toma entonces como un punto fuerte dentro del proyecto, al

momento de pensar en un diseño de sistema de alta demanda y flexible.

1.3.4 Movilidad

Para igualar las capacidades y tipos de servicios de la telefonía IP a la

actual telefonía conmutada, es que toma mucha importancia este concepto. Se

habla de movilidad cuando un sistema es capaz de funcionar en lugares donde

no existe su presencia física como tal, sino a través de un sistema externo se

logra acceso a él. Llevar esto a la telefonía actual es lo que se traduce en el

denominado GSM. El punto de este concepto que apoya al proyecto, viene de la

8

actual tecnología UTMS, que supera a la anterior generación GSM, y logra dar el

paso inicial a la movilidad en telefonía IP.

1.4 OBJETIVO DEL PROYECTO

Mediante el presente proyecto se pretende generar un documento que

contenga los aspectos fundamentales sobre la telefonía IP, principalmente en las

nuevas tecnologías “Session Border Controller” (SBC), el estándar de

señalización SIP y sus capacidades de troncal de multimedia. Focalizar luego en

aplicaciones de laboratorio, para terminar en un servicio de mejora al actual

sistema VoIP en SIP con SBC, es decir, analizar las capacidades de los SBC y

aplicar la investigación en la situación actual del sistema VoIP en el país. Se

desea por ultimo ver la factibilidad económica del sistema mejorado y concluir si

el desarrollo del proyecto es acompañado por una rentabilidad apropiada de

acuerdo con el sistema telefónico IP actual implementado. A continuación se

especifican los objetivos de manera más específica:

• Definir los protocolos que rigen los sistemas integrados de multimedia.

• Presentar distintas posibilidades de equipamiento dentro del mercado

“Session Border Controller”.

• A partir de los conceptos de capacidades, comprender distintas

aplicaciones realizadas en estos equipos, y saber definirlas.

• Obtener una planificación acondicionada a sistemas de migración a

Telefonía IP.

• Objetar como positiva la solución SIP-“Trunk” como “Carrier” global y

traductor entre la red PSTN actual y las redes emergentes de telefonía IP.

• Realizar una evaluación determinística de los anteriores objetivos, de

manera de validar el inter-funcionamiento y la interoperabilidad del

sistema.

9

• Realizar una implementación funcional de “Presencia” a través de IMS,

logrando una completa interactividad “peering-access” (empresa-

proveedor), esto es lo que proporciona modo “access” como parte de la

gran solución IMS.

• Desarrollar una evaluación económica del proyecto que refleje todo dato

necesario apuntando a un resultado tangible que sirva en la toma de

decisiones respecto al posterior desarrollo comercial de las soluciones

planteadas en el presente proyecto.

CAPÍTULO 2

CARATERÍSTICAS Y BENEFICIOS DE SIP-TRUNK POR SOBRE OTROS PROTOCOLOS SEÑALIZACIÓN

2.1 DEFINICIÓN DE PROTOCOLO SIP

Es un protocolo desarrollado por el grupo de trabajo MMUSIC del IETF

con la intención de ser el estándar para la iniciación, modificación y finalización

de sesiones interactivas de usuario donde intervienen elementos multimedia

como el video, voz, mensajería instantánea, juegos en línea y realidad virtual.

Actualmente está definido por la RFC 3261 [1], y se encuentra definido por

OSI en la capa de aplicación. En la figura 2-1 se muestra como es la forma de

interactuar de SIP en el medio VoIP.

Las características principales del protocolo son:

• Basado en texto.

• Sintaxis similar a HTTP o SMTP.

• Uso de URIs (con esquemas sip, sips y tel).

• Métodos básicos: “INVITE”, “ACK”, “BYE”, “CANCEL”, “REGISTER”,

“REFER”, “OPTIONS”.

• Los mensajes se agrupan en transacciones y llamadas.

• Generalmente, el cuerpo de los mensajes contiene descripciones de

sesiones de multimedia (SDP).

• Códigos de respuesta similares a los de HTTP (Ejemplo: 200 – OK).

• Localización basada en DNS.

• Cabeceras como método de ampliación.

11

Figura 2-1: Estructura protocolar para sistemas VoIP según modelo OSI

2.1.1 Entidades SIP

La configuración más simple para establecer una sesión SIP es utilizando

sólo dos agentes de usuario (“User Agents” o UA) conectados uno a otro. Los

elementos básicos de un sistema SIP son los UA y los servidores de Red. Estos

últimos pueden ser de diferentes tipos, “Proxies”, “Registrars” y “Redirect

Servers”. A menudo estos elementos son sólo entidades lógicas y comúnmente

se sitúan en el mismo lugar.

2.1.1.1 User Agent

El agente de usuario se conforma por el UAS (“User Agent Server”) y UAC

(“User Agent Client”), estas son las entidades finales que usa SIP para

contactarse de extremo a extremo entre dos terminales físicas en una misma red

12

o diferentes y definir las características de la sesión. Se entiende por terminal,

por ejemplo, un “softphone”, teléfonos celulares (SIP), “Hard-IPphones”, y

similares. El UAC es la parte del UA que se encarga de generar peticiones y

recibir respuestas a esas peticiones, mientras que el UAS tiene como tarea el

recibir peticiones y generar respuestas a las mismas [1]. Esto se ejemplifica en la

figura 2-4.

2.1.1.2 SIP proxy server

IP Proxy Server es aquel que realiza una petición a nombre de un UA

hacia otro Proxy u otro UA. La tarea más importante de un Proxy Server es

encaminar las invitaciones de sesión para llevarlas hasta el UA llamado, se

ejemplifica en la figura 2-7. Una invitación de sesión atravesará comúnmente un

conjunto de “Proxies” hasta encontrar a aquel que conozca la localización exacta

del UA buscado. Existen dos tipos de SIP Proxy Servers: “stateful” y “stateless”.

• “Stateful Proxy”: Este tipo de servidor crea un estado de petición y lo

mantiene hasta que la transacción finalice [1].

• “Stateless Proxy”: Sólo reenvía los mensajes SIP [1].

Los “proxies stateful” pueden desempeñar tareas mucho más complejas;

por ejemplo hacer retransmisiones como lo sería el caso del servicio “sígueme” ó

re-emitir un mismo mensaje SIP hacia dos “proxies” diferentes con el fin de

localizar a un usuario en específico.

2.1.1.3 Registrar Server

Cuando un usuario se conecta a la Red (ejecuta su “Softphone” en su PC

o enciende su “IP-phone”), este envía un mensaje “Register” hacia su “Proxy”

con el fin de que éste conozca su ubicación. La labor de un registrar “Proxy”

consiste en atender estos mensajes, autenticar y validar la cuenta contra una

13

base de datos interna o externa y registrar la localización actual del usuario, se

ejemplifica en la figura 2-6. Un “Registrar Server” es comúnmente sólo una

entidad lógica y la mayoría de las veces se localiza junto con el “Proxy SIP

Server”.

2.1.1.4 Redirect Server

Entidad que escucha peticiones y regresa (no reenvía mensajes)

respuestas que contienen la localización actual de un usuario en particular. Este

servidor escucha las peticiones y realiza la búsqueda en la Base de Datos

creada por el “Registrar Server”. Este tipo de Server contesta con mensajes SIP

de clase 3XX, se muestra un ejemplo de la estructura en la figura 2-2.

El usuario o “Proxy” que realizó la petición original extrae la información

de la respuesta y envía otra petición directamente al resultado de la búsqueda.

Figura 2-2: Estructura de protocolo de “Redirect Server”.

14

2.1.2 Mensajes SIP

SIP utiliza una serie de mensajes para señalizar las sesiones. El mensaje

se conforma de una línea inicial, el encabezado del mensaje y el cuerpo del

mensaje, se muestra en la figura 2-3 el formato de mensaje SIP.

La línea inicial contiene la versión del protocolo SIP, el método y

direcciones involucradas en la sesión para las peticiones, mientras que el estado

de la sesión para el caso de las respuestas.

El encabezado contiene información relacionada con la llamada en forma

de texto; por ejemplo: el origen y destino de la petición, el identificador de la

llamada y otros tipos de información adicional. Todos ellos son definidos a

continuación.

• “VIA”: Se usa para registrar (grabar) la ruta que ha recorrido la petición o

mensaje. En el caso de un mensaje INVITE, éste contendrá sólo un

campo VIA, el cual registrará el origen de la petición.

• “From”: Es la dirección del origen de la llamada.

Figura 2-3: Estructura de trama mensaje SIP.

15

• “To”: Es la dirección del destino de la llamada.

• “ID-Call”: Identifica mensajes que pertenecen a la misma llamada. Así es

por ejemplo un analizador de red que puede reconocer todos los

mensajes correspondientes a una llamada determinada.

• “Cseq”: Se inicia en un número aleatorio e identifica en forma secuencial a

cada petición.

• “Contact”: Contiene la IP y puerto en dónde el emisor de la petición

espera respuesta a su mensaje [2].

El cuerpo del mensaje o carga útil: Lleva información (comúnmente SDP ó

ISUP en caso de una troncal hacia la PSTN.

Existen 2 tipos de mensajes SIP, los métodos o peticiones, y las

respuestas. Los métodos se emplean para iniciar alguna acción o para

información. Las respuestas se usan para confirmar que una petición fue recibida

y procesada, y contiene el estado del procesamiento.

2.1.2.1 Métodos SIP

Existen varios métodos en la señalización SIP, dependiendo del estado la

llamada. Los métodos más importantes y generalmente en uso son (todos

definidos en la RFC 3261) son definidos a continuación.

El método “INVITE” es usado con el fin de establecer una sesión entre

UAs. INVITE corresponde al mensaje ISUP IAM o al mensaje Q.931 SETUP y

contiene las informaciones sobre el que genera la llamada y el destinatario así

como sobre el tipo de flujos que serán intercambiados (voz, video, entre otros).

Cuando un UA que emitió el método SIP INVITE recibe una respuesta

final a la invitación (ejemplo: 200 OK), el confirma la recepción de esta respuesta

por medio de un método “ACK”. Una respuesta del tipo ocupado o con respuesta

16

es considerada como final, mientras una respuesta tipo “ringing” significa que el

destinatario ha sido avisado es una respuesta provisoria.

El método “BYE” permite la liberación de una sesión anteriormente

establecida. Corresponde al mensaje de liberación de los protocolos ISUP y

Q.931. Un mensaje BYE puede ser emitido por el que genera la llamada o el que

la recibe.

El método “REGISTER” es usado por una UA con el fin de indicar al

“Registrar” la correspondencia entre su Dirección SIP y su dirección de contacto

(ejemplo: dirección IP).

El método “CANCEL” es utilizado para pedir el abandono de la llamada en

curso pero no tiene ningún efecto sobre una llamada ya aceptada. De hecho,

solo el método “BYE” puede terminar una llamada establecida.

El método “OPTIONS” es utilizado para interrogar las capacidades y el

estado de un “User Agent” o de un servidor. La respuesta contiene sus

capacidades (ejemplo: tipo de “media” siendo soportado, idioma soportado) o el

hecho de que el UA sea indisponible [3].

2.1.2.2 Respuestas SIP

Los mensajes de respuesta son similares a los de peticiones, excepto por

la primera línea, la cual contiene la versión del protocolo y el código de la

respuesta (ej. 200 = Ok) y una frase que explica, en términos más humanos, la

razón de la respuesta. Los códigos de respuesta son enteros entre 100 y 699. El

primer dígito indica la clase.

Existen 6 clases de respuestas:

• 1XX: Provisionales (Petición fue recibida pero se desconoce aún el

resultado del procesamiento). El emisor detiene el envío de

retransmisiones después de recibir una respuesta de este tipo. Un

ejemplo es el código 180 = “ringing” ó 100 = “trying”.

17

• 2XX: Son respuesta finales positivas. La petición fue recibida y procesada

exitosamente. Por ejemplo 200 = “Ok” significa que el extremo llamado

aceptó la invitación a la sesión.

• 3XX: Son usados para re-direccionar llamadas. Dan información acerca

de la nueva localización de un usuario ó sobre un Proxy alterno que

pueda resolver satisfactoriamente alguna petición. El emisor del mensaje

de petición debe reenviar su petición a otro lado para que su petición sea

atendida.

• 4XX: Son respuestas finales negativas. Falla del lado del emisor, mala

sintaxis del mensaje, entre otros.

• 5XX: Falla del lado del servidor. Aparentemente la petición es válida pero

el “Proxy” es incapaz de procesarla. El emisor debe reintentar después.

• 6XX: La petición no puede ser atendida en ningún “Proxy”.

2.2 FUNCIONAMIENTO DE PROTOCOLO SIP

SIP es basado en arquitectura cliente/servidor similar al HTTP, legible por

humanos, con el que comparte muchos códigos de estado y sigue una estructura

de petición-respuesta, estas peticiones son generadas por un cliente y enviadas

a un servidor, que las procesa y devuelve la respuesta al cliente. El par petición-

respuesta recibe el nombre de transacción. Al igual que el protocolo HTTP, SIP

proporciona un conjunto de solicitudes y respuestas basadas en códigos. A

continuación se da detalle de los procesos de funcionamiento SIP.

2.2.1 Transacciones SIP

Una transacción SIP es una secuencia de mensajes entre dos elementos

de Red. Una transacción corresponde a una petición y todas las respuestas a

esa petición.

18

Figura 2-4: Ejemplo de transacción

De esta forma una transacción incluirá cero o mas respuestas

provisionales y una o más respuestas finales (en el caso de un mensaje INVITE,

recordar que este puede ser dividido por un Proxy, por lo tanto tendrá múltiples

respuesta finales. Las entidades SIP que almacenan el estado de las

transacciones son denominadas “Stateful". Lo hacen por medio del registro de

cada transacción a través de un identificador contenido en el encabezado VIA.

En la figura 2-4 se muestra un ejemplo los mensajes que pertenecen a una

misma transacción dentro de una conversación SIP.

2.2.2 Diálogos SIP

Un diálogo SIP es una conversación “peer-to-peer” entre dos UA, esto se

aprecia en la figura 2-5. Los diálogos son identificados usando los campos “Call-

ID”, “From” y “To”. Los mensajes con estos campos iguales pertenecerán al

mismo diálogo. El campo “Cseq”, del que se habla anteriormente, es utilizado

para ordenar los mensajes en un diálogo. De hecho el Cseq representa el

número de transacción. De forma breve se pude decir que un diálogo es una

secuencia de transacciones [2].

19

Figura 2-5: Ejemplo de dialogo

2.2.3 Esquema de señalización de una llamada SIP

Una vez analizados los conceptos de señalización, se procede a explicar

los procesos típicos de diálogos SIP, estos son: registro, invitación a sesión,

término de sesión, y registro de ruta.

2.2.3.1 Registro

Para que un usuario pueda ser llamado por otro, este debe registrarse

primero ante el “proxy”, así este método se muestra en la figura 2-6.

Figura 2-6: Diálogo de registro

20

El registro consiste en el envío de un mensaje “REGISTER” seguido de su

correspondiente respuesta “200 OK”. En esta primera instancia el usuario no

envía credenciales válidas recibirá por respuesta un mensaje 407 que indica que

son requeridas las credenciales de registro, con lo cual tendrá que reenviar el

mensaje de Registro pero con credenciales válidas [3].

2.2.3.2 Invitación a sesión

Una invitación inicia con el mensaje “INVITE” dirigido comúnmente al

“Proxy”. Éste responde con un “TRYING 100” para detener las retransmisiones y

reenvía las peticiones hacia el usuario llamado. Todas las respuestas

provisionales generadas por el usuario llamado son regresadas al usuario origen.

Por ejemplo “RINGING 180” que es un mensaje que se envía cuando el usuario

llamado es contactado y comienza a timbrar. Una respuesta “200 OK” es

generada en cuanto el usuario llamado descuelga el auricular [2]. Para

ejemplificar se muestra un diagrama en la figura 2-7, este explica de forma

gráfica el proceso.

Figura 2-7: Diálogo de invitación a sesión

21

Figura 2-8: Diálogo de término de sesión

2.2.3.3 Término de sesión

Una sesión es finalizada cuando uno de los usuarios envía el mensaje

“BYE” al otro extremo. El otro usuario confirma el final de la conversación

enviando por respuesta un mensaje “200 OK”, esto se ejemplifica en la figura 2-

8. La transacción para finalizar la sesión se realiza de un extremo a otro sin

pasar por el “Proxy” a menos que en el mismo se haya establecido un proceso

de Registro de ruta.

2.2.3.4 Registro de ruta

Existen situaciones en las que el Proxy requiere estar presente en la ruta

de todos los mensajes con fines de control del tráfico, o por ejemplo, cuando

existe un NAT. El “Proxy” o los “Proxies” logran esto por medio de la inserción

del campo “RECORD ROUTE” en los encabezados de los mensajes SIP. El

diagrama que muestra la figura 2-9, explica de forma secuencial el proceso.

22

Figura 2-9: Diálogo de término de sesión con registro de ruta en “Proxy”

2.3 PROTCOLOS RTP/RTCP Y SDP

Como se explica en la sección de introducción y en la definición del

protocolo SIP, este es sólo un protocolo pensado para enlazar en modo cliente –

servidor a dos dispositivos y/o usuarios y establecer un canal entre ellos, pero no

transportar la información ni mucho menos controlar cómo se transporta, es así

como SIP se respalda en RTP y SDP.

2.3.1 Protocolo RTP/RTCP

Son los protocolos usados para transportar flujos de medios en Telefonía

IP. Ambos fueron definidos en la RFC 1889. El primero para transportar flujos en

tiempo real y el segundo para monitorear la calidad de servicio, así como para

transportar información acerca de los participantes en la sesión.

Sus funciones son:

• Identificación del tipo de carga útil transportada (Codecs de Audio/Video)

• Verificar la entrega de los paquetes en orden (Marca de tiempo) y si

resulta necesario reordenar los bloques fuera de orden.

• Transporte de información de sincronización para la codificación y

decodificación.

23

• Monitoreo de la entrega de información.

RTP utiliza UDP para el transporte de la información y aprovecha la suma

de verificación del mismo, para ver concordancia integra de los datos. Es

importante resaltar que RTP no posee ningún método para garantizar la QoS ni

la entrega ordenada de paquetes. Por otro lado RTCP utiliza el mismo protocolo

que RTP para enviar paquetes de control hacia todos los participantes de una

sesión.

Los servicios que provee RTCP son los siguientes:

• Dar seguimiento a la calidad en la distribución de los datos, así como

mantener el control de los “codecs” activos.

• Transportar un identificador constante para la fuente RTP (CNAME)

• Anunciar el número de participantes por sesión con el fin de ajustar la tasa

de transmisión de datos [3].

2.3.2 Protocolo SDP

SDP, significa “Session Description Protocol” (Protocolo Descriptivo de

Sesión), es un formato para describir parámetros de inicialización de flujo de

medios. Ha sido publicado por la IETF como RFC 4566.

SDP está diseñado para transportar información de la sesión hacia los

destinatarios, así como información de los medios referentes a la misma. Éste

permite además asociar más de un flujo de medios a una misma sesión; por

ejemplo en una misma sesión puede existir un flujo para audio y uno más para

video o transferencia de documentos.

SDP es exclusivamente para propósitos de descripción y negociación de

los parámetros de sesión. No transporta el medio en sí. Fue pensado para

trabajar en conjunto con otros protocolos como SIP, Megaco ó HTTP. El

transporte de información acerca de los flujos de medios permite a los

24

destinatarios participar en la sesión si ellos soportan dichos flujos. Además, SDP

permite la negociación de los parámetros del flujo tales como la tasa de

muestreo de la señal, el tamaño de los paquetes, entre otros. En la figuras 2-10.

2-11 y 2-12 se muestran todas la opciones de SDP de información, por defecto u

opcionales (diferenciadas por un *).

La información que SDP incluye en sus paquetes de forma general es la

siguiente:

• La versión del protocolo

• El nombre de la sesión y su propósito

• El tiempo que la sesión esta activa

• Los medios relacionados con la sesión (Video, Audio y formatos para

Video o audio, entre otros).

• Las direcciones IP y los puertos pertinentes para el establecimiento de la

sesión.

• Los atributos específicos a la sesión o a los medio dentro de ella

• a= <atributo>, a=<atributo>:<valor>

Figura 2-10: Opciones de atributos ofrecidos por SDP para sesion

Figura 2-11: Opciones de atributos ofrecidos por SDP de tiempo

25

Figura 2-12: Opciones de atributos ofrecidos por SDP de “media”

Los mensajes SDP están codificados como texto plano (ISO 10646 UTF-

8), así se comprueba en la figura 2-13. Los nombres de campo y atributos usan

US-ASCII pero lo demás es ISO 10646. Se eligió el formato texto plano para

aumentar la “portabilidad” hacia sistemas basados en Web [3].

Figura 2-13: Mensaje “invite” común, enmarcado en rojo ejemplo de SDP

26

2.4 COMPARACIÓN CON PROTOCOLOS MEGACO (MGCP), SCCP, H.323, IAX2 (IAX), Y SS7

A continuación una breve descripción de cada protocolo y un tabla

comparativa demostrando sus fortalezas y debilidades dentro de parámetros

estándares para comunicación VoIP.

• SS7: El sistema de señalización de canal común numero 7 (es decir, SS7

o C7) es un estándar global para las telecomunicaciones definidas por el

sector de estandarización de las telecomunicaciones (ITU-T) de la unión

de telecomunicaciones Internacionales (ITU). El estándar define el

protocolo y los procedimientos mediante los cuales los elementos de la

PSTN intercambian información sobre una red digital para efectuar el

ruteo, establecimiento y control de llamadas. La definición de ITU para

SS7 permite variantes nacionales tales como el Instituto de Estándares

Nacionales Americanos (ANSI) y Bell Communications usados en

Norteamérica y el Instituto de Estándares de Telecomunicaciones

Europeos (ETSI) usado en Europa.

• MEGACO (MGCP): Es un protocolo de control de dispositivos, donde un

gateway esclavo (MG) es controlado por un maestro (MGC, también

llamado “Call Agent”).

MGCP, “Media Gateway Control Protocol”, es un protocolo interno

de VoIP cuya arquitectura se diferencia del resto de los protocolos VoIP

por ser del tipo cliente – servidor. MGCP está definido informalmente en la

RFC 3435, y aunque no ostenta el rango de estándar, su sucesor,

MEGACO está aceptado y definido como una recomendación en la RFC

3015 [2].

Está compuesto por:

� un MGC, “Media Gateway Controller”

� uno o más MG, “Media Gateway”

27

� uno o más SG, “Signaling Gateway”.

Un “Gateway” tradicional, cumple con la función de ofrecer

conectividad y traducción entre dos redes diferentes e incompatibles como

lo son las de Conmutación de Paquetes y las de Conmutación de

Circuitos. En esta función, el gateway realiza la conversión del flujo de

datos, y además realiza también la conversión de la señalización,

bidireccionalmente.

MEGACO separa conceptualmente estas funciones en los tres

elementos previamente señalados. Así, la conversión del contenido

multimedia es realizada por el MG, el control de la señalización del lado IP

es realizada por el MGC, y el control de la señalización del lado de la red

de Conmutación de Circuitos es realizada por el SG.

MEGACO introduce esta división en los roles con la intención de

aliviar a la entidad encargada de transformar el audio para ambos lados

de las tareas de señalización, concentrando en el MGC el procesamiento

de la señalización.

El control de calidad de servicio QoS se integra en el gateway GW

o en el controlador de llamadas MGC. Este protocolo tiene su origen en el

SGCP (de Cisco y Bellcore) e IPDC. Bellcore y Level3 plantearon el

MGCP a varios organismos.

• SCCP: “Skinny Client Control Protocol” es un protocolo propietario de

control de terminal desarrollado originariamente por Selsius Corporation.

Actualmente es propiedad de Cisco Systems, Inc. y se define como un

conjunto de mensajes entre un cliente ligero y el “Call Manager”. Ejemplos

conocidos de clientes ligeros son la serie Cisco 7900 de teléfonos IP

como el Cisco 7960, Cisco 7940 y el Cisco 7920 802.11b inalámbricos.

Skinny es un protocolo ligero que permite una comunicación eficiente con

un sistema Cisco “Call Manager”. El “Call Manager” actúa como un proxy

28

de señalización para llamadas iniciadas a través de otros protocolos como

H.323, SIP, RDSI o MGCP.

Un cliente skinny utiliza TCP/IP para conectarse a los “Call

Managers” en un cluster. Para el tráfico de datos (flujo de datos de audio

en tiempo real) se utiliza RTP/UDP/IP. SCCP es un protocolo basado en

estímulos y diseñado como un protocolo de comunicación para puntos

finales hardware y otros sistemas embebidos, con restricciones de

procesamiento y memoria significativas.

Cisco adquirió la tecnología SCCP cuando compró la empresa

Selsius a finales de los años 1990. Como una reminiscencia del origen de

los actuales teléfonos IP Cisco, el nombre por defecto de los teléfonos

Cisco registrados en un CallManager es SEP (Selsius Ethernet Phone)

seguido de su MAC.

• IAX2: Protocolo desarrollado por Digium, con el objetivo de permitir la

comunicación entre servidores Asterisk. Este protocolo ha sido

desarrollado para solucionar problemas de NAT (por ejemplo con H.323) y

mejorar el trunk entre sistemas basados en este protocolo (sólo se

reserva el ancho de banda necesario en cada comunicación, a diferencia

de otros como TDM/VoIP que reservan un determinado ancho de banda).

• H.323: El H.323 es una familia de estándares para las comunicaciones

multimedia sobre redes LAN. Está definido específicamente para

tecnologías LAN que no garantizan una calidad de servicio. El protocolo

de red más común en el cual se está implementando H.323 es IP. H.323

hace referencia a otras recomendaciones. La serie H.323 incluye

recomendaciones como: H.225 referente a paquetización y

Sincronización, H.245 relacionada a Control, H.261 y H.263 como

“codecs” de video, G.711, G.722, G.728, G.729 y G.723 como “codecs” de

audio y la serie T.120 de protocolos de datos [2].

29

Tabla 2-1: Comparativa entre SIP y H.323

Protocolo

Característica H.323 SIP

Codificación Binaria (ASN.1) Textual (SigComp)

Formato Series G.XXX y H.XXX, MPEG,

GSM

Tipos MIME – IANA

Ampliabilidad Campos reservados Métodos, cabeceras

Autenticación H.235 (puede usar TLS) Análogo a http

Localización Gatekeeper (puede usar DNS) DNS

Transporte TCP, UDP TCP, UDP, SCTP,

DCCP, etc.

Arquitectura Monolítica Modular

Implementación Costosa Más sencilla

Negociación de

parámetros

H.245 SDP

Vigencia En declive En auge

Numeración Número de teléfono URIs

IM No Si

Cantidad de estándares Amplia Reducida

Servicios H.450 SIP CGI/CPL

Seguridad Si SI

Conferencias multimedia Si No

QoS Gatekeepers Externo (RSVP)

30

Los estándares que se comparan en la tabla 2-1 son entre H.323 y SIP, ya

que SS7 es un protocolo predecesor que no viene al caso para comparar, si

toma mucha importancia en la implementación de los protocolos sucesores por

un tema de migración hacia ellos, por otra parte IAX2 no es un protocolo de

confiabilidad profesional o dicho de otra forma apoyado por alguna institución

que dicte recomendaciones de renombre mundial, como lo son IETF o ITU,

además de ser un protocolo muy vulnerable en cuanto a seguridad se refiera.

Por otra parte MEGACO es un protocolo complementario a H.323 y SIP, además

de ser un protocolo para controlar “media Gateway” y no señalización, y SCCP

queda descartado por ser un protocolo propietario, así que claramente no es

configurable en la variedad de equipos SBCs a tratar en este tema.

2.5 PROTOCOLO SIP-TRUNK

La definición de “SIP-Trunk” está completamente basada en SIP, excepto

por la propiedad de troncal. La definición de troncal telefónico es un concepto

antiguo que data de PSTN la cual trata de un circuito entre centrales telefónicas

de conmutación o de otro tipo equipos, a diferencia de los circuitos de bucle de

abonado que se extienden desde el intercambio de equipo de conmutación

telefónica para teléfonos de información individual o de inicio/termino de equipo.

Una definición global para SIP- Trunk es pues, una entidad SIP virtual en

un servidor (UAS, UAC o proxy) limitado por un conjunto predefinido de políticas

y normas que determinan la forma de procesar las solicitudes. El

comportamiento del troncal está condicionado a un contrato, un acuerdo entre el

cliente y el servidor, que siempre y cuando las solicitudes sean basadas en el

formato del contrato, entonces la petición recibe el tratamiento que se especifica.

SIP permite resolver a nivel de servidor, en el tratamiento que se aplica a

una solicitud SIP entrante. Como se transfieren las llamadas, como se

31

autentifica, si se conecta a la PSTN, si los encabezados se agregan o quitan, si

se termina la sesión, y así sucesivamente, son todas tratadas en la

discrecionalidad del servidor. Un troncal SIP se define como un particular

conjunto de la lógica de procesamiento de solicitudes, un sistema de

autenticación específico, así como una lógica de enrutamiento específicas,

además de adición y extracción de cabeceras determinadas.

Los siguientes son ejemplos de troncales SIP que pueden ser definidos en

un servidor SIP, mostrando así las funcionalidades y comportamientos de SIP-

Trunk:

• Interconexión PSTN/Troncal: Este es un troncal SIP que sería utilizado

por las empresas que se conectan a un proveedor de servicios. El troncal

utiliza la autenticación TLS mutua para determinar la identidad de interés

en la empresa. Las solicitudes se aceptan sólo si el resultante de

identidad coincide con un usuario de la empresa antes de la provisión;

todos los otros causan el cierre inmediato de la conexión TLS. Luego las

solicitudes entrantes son aceptadas por los terminales hacia la PSTN. El

URI de solicitud debe contener un número de teléfono en la parte de

usuario, y la parte de dominio contiene el dominio del proveedor. Los

números deben estar en formato E.164. El servidor utiliza configuración

de tablas de enrutamientos localmente para enviar la invitación a una

puerta de enlace PSTN basado en el número marcado [4].

• Filtrado Troncal: Este es un troncal SIP que puede ser proveído por un

"Session Border Controller" (SBC) u otro servidor de borde. Esta SIP-

Trunk se ejecuta a través de TCP y no es segurizado con TLS. La petición

URI puede estar basado en cualquier formato RFC oficial; la parte de

dominio representa el destino de las solicitudes no el servidor en sí. El

servidor examina la solicitud SIP y compara los encabezados en ella

frente a unos pre-configurados, con encabezados permitidos. Los

32

encabezados que no se encuentran en la lista son eliminados por el

servidor antes de que la solicitud se envíe [4].

• Troncal de correo de voz: Este es un troncal SIP que puede ser proveído

por un “Voicemail Server”. Se ejecuta a través de TCP y es segurizado

con TLS; los clientes deben presentar certificados de un conjunto

permitido. El URI de la solicitud debe tener el formato basado en las

convenciones de la RFC 4458 [4].

• Troncal de publicación: Este es un troncal SIP que puede salir en un

servidor presente. Es compatible con TLS sobre TCP solamente, y se

utiliza expresamente para PUBLICAR peticiones, la RFC3903 contiene los

documentos presentes. Sólo un cierto conjunto de extensiones de

documentos presentes cuentan con soporte, en particular, los documentos

necesitan cumplir con la RFC 4480 [4].

CAPÍTULO 3

ANTECEDENTES SOBRE EQUIPAMIENTO SESSION BORDER CONTROLLER (SBC)

3.1 DEFINICIÓN DE SESSION BORDER CONTROLLER

El “Session Border Controller” (SBC) es un equipo controlador de

sesiones optimizado para la interconexión entre redes VoIP de diferentes

dueños: corporaciones, ISPs o carriers con NGN. Con éste, las empresas podrán

pasar todo su tráfico telefónico en uno o más puntos de su red a múltiples

proveedores mediante un simple troncal SIP con capacidad de entregar hasta

miles de conversaciones simultáneas. Lo anterior permite un gran ahorro, la

eliminación de las tramas E1, mayor seguridad y una amplia disponibilidad de

oferentes para dirigir su tráfico por la alternativa más económica.

Al mismo tiempo en que los ISP y “Carriers” implementan redes de VoIP y

otros protocolos, aparecen desafíos que incluyen temas básicos de seguridad en

la red, compatibilizar señalizaciones entre diferentes redes e interoperabilidad en

un ambiente de múltiples proveedores.

“Session Border Controller” permite que los proveedores de VoIP públicos

y privados interconecten sus redes vía IP con las redes basadas en SIP y H.323

de los clientes VoIP corporativos, implementando una conexión segura, y

dejando en el pasado las antiguas tramas TDM de la red tradicional.

El SBC es un equipo que controla, con altos estándares de seguridad, el

tránsito de entrada y salida de todas las transmisiones de voz que viajan sobre

su red.

Este dispositivo tiene la capacidad de vigilar todas las comunicaciones

desde y hacia su red diferenciando que es voz y que no, evitando ataques que

puedan poner en peligro el servicio. Además, es escalable sin necesidad de

34

invertir en equipos, dado que puede trabajar con 250 hasta 10 mil sesiones

simultáneas con sólo una actualización de licencia.

3.2 PRINCIPALES PROVEEDORES DE EQUIPOS SBC Y SUS VISIONES EMPRESARIALES

Dentro de los principales proveedores de equipos SBC se encuentran:

Acme Packet, Cisco, Juniper, NexTone, Genband, Ditech, e InGate. Cada

empresa contempla una visión común con respecto a esta tecnología, y al mismo

tiempo reservan sus propios puntos de vista de cómo encajar los SBC en función

de un mejor desempeño de los actuales sistemas de telefonía IP.

3.2.1 Acme Packet

Tanto la gente de negocios como usuarios necesitan mucho más que un

correo electrónico, mensajería instantánea basada en texto y servicios de datos

para comunicarse entre sí. También necesitan servicios interactivos con

verdadera comunicación en tiempo real, como las llamadas de voz,

PBX/servicios Centrex, la presencia con voz instantánea o llamadas de

video/conferencias, colaboración multimedia, videoconferencias, educación a

distancia, el Cliente interactivo/”Supplier Relationship Management” (C/SRM),

multimedia para sitios de atención al cliente web y más.

Expuestas las necesidades de los clientes, Acme packet clasifica las

soluciones en cuatro grandes módulos:

• Empresa: Soluciones actualmente implementadas en Chile, en un formato

de demostración y prueba para grandes empresas nacionales, todo esto

con el protocolo SIP-trunk. Como idea principal de la solución, se da un

servicio telefónico IP a menor costo de normal, gracias a una mayor

eficiencia en el uso del ancho de banda con SIP-trunk.

35

• Movil: Solución que extiende la solución “Empresa” a una unificación

geográfica para el cliente, lo que se traduce a utilizar el servicio VoIP en

cualquier lugar físico con condiciones de conectividad razonables.

• Linea Fija: Solución que pretende escalar el mercado SBC a los

proveedores de servicio, dando un salto en el publico objetivo,

actualmente empresas, a usuario individuales.

• Capa más alta y aplicaciones para proveedores de servicio: Solución que

apunta a la integración total al mundo IP, en cuanto a servicios de

comunicación, lo que se denomina IMS (se explica en la sección 4.1), esto

brinda una infinidad de servicios agregados a las comunicaciones

telefónicas actuales.

Las soluciones de Acme Packet idealmente no cumplen todos sus

propósitos, aunque es el que se acerca más a la solución final. Las redes IP

actuales son incapaces de soportar estas comunicaciones. ¿Por qué?, debido a

que cualquier proveedor de servicios de red por sí solo no llega lo

suficientemente lejos y de manera global, Internet carece de la necesaria QoS y

de los mecanismos de contabilidad para ofrecer una calidad alta.

La entrega de alta calidad de voz interactiva, el vídeo y las

comunicaciones multimedia a través de las fronteras de la red IP representan

una gran oportunidad de ganancias para los proveedores de servicios. Esto es a

lo que Acme Packet apunta, dejar atrás el desarrollo aislado de la telefonía IP, y

convertir a Internet, en la red de telefonía IP más grande del mundo.

3.2.2 Cisco

El Cisco “Unified Border Element” facilita la conectividad sencilla y

rentable entre los independientes de comunicaciones unificadas, voz sobre IP

(VoIP) y redes de vídeo. “Cisco Unified Border” es un elemento integrado de

Cisco con IOS Software como aplicación que está diseñado para satisfacer las

36

necesidades de interconexión de comunicaciones unificadas, incluyendo las

funciones de controlador de sesión de borde, de las empresas y proveedores de

servicios por igual.

Interconexiones IP de extremo a extremo entre las redes de

comunicaciones unificadas proporcionan valiosos beneficios tales como:

• Preservación de los medios de contenidos de calidad.

• Apoyo a los nuevos servicios de comunicaciones unificadas que no son

compatibles con la multiplexación por división de tiempo (TDM).

• Baja latencia.

• Reducción de costes.

“Cisco Unified Border Element” versión 1.3 está disponible a partir de

Cisco IOS “Software Release” 12.4 (22) YB. Esta versión de “Cisco Unified

Border Element” cuenta con una serie de nuevas mejoras, incluyendo:

• Desvío automático de llamadas, con protocolo SIP, en caso de error de

troncal en el sitio del proveedor de servicios.

• Mayor control para la identificación de llamadas de una empresa y las

preferencias de llamadas y nombre para mostrar, para asegurar la

privacidad.

• Asegura las llamadas por Internet entre las organizaciones empresariales.

• Configuración simplificada para facilitar el “plug and play”, funcionalidad

para troncales SIP.

• Es más fácil para los desarrolladores, para crear aplicaciones SIP que

puedan estar bien comunicadas con la aplicación de comunicaciones

unificadas de la infraestructura existente.

También hay una serie de características únicas disponibles en todas las

versiones de “Cisco Unified Border Element”, incluyendo:

• Demarcación de red inteligente que soporta una amplia variedad de

interfaces físicas.

37

• Operación, Administración y Mantenimiento, las funciones estan en el

borde de las redes empresariales.

• Interoperabilidad con Cisco Unified Communications Manager.

• Conectar H.323 y SIP de voz y vídeo dentro de la empresa.

• Conectar H.323 de vídeo a través de Internet en la empresa.

• Media interfuncionamiento de doble tono multifrecuencia (DTMF) para fax,

módem, y transcodificación codec.

• Calidad de servicio (QoS) y administración de ancho de banda (QoS

marcado con el tipo de servicio [ToS], servicios diferenciados punto de

código [DSCP] y la ejecución de recursos de ancho de banda mediante

Protocolo de reserva [RSVP] y el “codec” de filtrado).

• Permite la adopción de los troncales de las comunicaciones unificadas a

través del apoyo concurrente de la red telefónica pública conmutada

(PSTN) pasarelas en la misma plataforma.

• Comunicaciones Unificadas en cuanto a la aplicación de políticas de

seguridad.

3.2.3 Juniper

Ofrece flexibilidad en el diseño y la máxima eficiencia posible gracias a la

ubicación de la red, independiente de la frontera de sesión de control y

señalización con respecto a las funciones de los medios de comunicación, lo que

permite una gran variedad de arquitecturas de implementación.

Elimina o reduce la necesidad de servicio de voz y dispositivos de

seguridad específicos, su capital asociado y los costes operativos. El MS-PIC y

el MS-DPC permiten asegurar un rendimiento a escala y aplicaciones de

seguridad dentro del “Session Border Control”, incluso cuando los servicios son

múltiples al mismo tiempo.

38

Se integra perfectamente con aplicaciones JUNOS para crear paquetes

de servicios convincentes.

Reduce los costos operativos mediante la aplicación de todos los servicios

desde una única versión de JUNOS en toda la infraestructura, en comparación

con cualificación independiente y los esfuerzos de integración necesaria para la

aplicación independiente de los SBC. También reduce el número de proveedores

para la gestión, el espacio y la energía necesaria, la complejidad del diseño,

gestión e integración.

Proporciona una solución para el futuro. Las aplicaciones de los SBC son

compatibles con los “routers MX 3D Universal” de Borde, que fueron

especialmente diseñada para apoyar las nuevas aplicaciones de gran ancho de

banda y las interfaces.

3.2.4 Genband

GENBAND ofrece tres familias de productos diseñados para ayudar a

nuestros clientes a evolucionar sus redes hacia el futuro “All-IP”. El portafolio

actual de GENBAND incluye la Serie G de gateways convergentes de baja,

media y alta capacidad; la Serie C para control de gateways; y nuestra Serie S

de soluciones basadas en seguridad, incluyendo los productos de Session

Boarder Controller (SBC) y Gateways de Seguridad.

Centrándose en las series de soluciones SBC se tiene:

• S3 Session Border Controller (SBC): El SBC S3 es un líder en el mercado,

“carrier grade”, con alto desempeño y que ofrece seguridad, forjamiento

de políticas, administración de sesiones e interoperación de señalización.

El SBC S3 se utiliza en los bordes de redes IP a IP, incluyendo tanto en

los bordes de interconexión como en los bordes de la red hacia las

empresas y hacia los suscriptores. Como una solución líder en

administración de sesiones para los proveedores de servicio, el SBC

39

habilita servicios basados en IP seguros y en tiempo real, incluyendo voz

y multimedia sobre redes fijas, móviles y de cable y soporta varias

arquitecturas incluyendo Pre-IMS, IMS, NGN, MSF, y redes PacketCable.

El set de funcionalidades de Intercambio de Sesiones Multiprotocolo

(MSX) permite el enrutamiento avanzado de sesiones IP, control de

políticas y soporte de la funcionalidad de selección del enrutamiento

menos costoso.

• S9 Session Border Controller (SBC): En la cima de su clase, el SBC S9 de

GENBAND de alto rendimiento, es masivamente escalable, con ancho de

banda de señalización de hasta 12Gbps, ancho de banda de medios de

hasta 24Gbps y hasta 150,000 sesiones concurrentes y 900 llamadas por

segundo. Está diseñado idealmente para operadores de redes que

quieren evitar los SBC que necesitan expandir sus servicios IP utilizando

un modelo de “pago conforme se crece”. El S9 ofrece seguridad “carrier

class”, comunicaciones en tiempo real para operadores fijos y móviles,

permitiendo nuevas ofertas de servicio, una rápida generación de ingresos

y ahorros en los costos de la red. Con extensas capacidades de

seguridad, forjamiento de políticas y de administración de sesiones. El

SBC S9 brinda a los proveedores niveles avanzados de funcionalidad,

flexibilidad y desempeño en los bordes de las redes IP.

3.2.5 Ditech

Los proveedores de servicios siguen ofreciendo nuevos servicios y

convergencia de sus redes IP, por ello necesitan una robusto Session Border

Controller (SBC) que sea compatible con los medios interactivos de las

comunicaciones del mañana a través de las nuevas fronteras de la red IP.

Proporcionar comunicaciones seguras a través de todo “NAT/Firewall” hacia y

desde cualquier dispositivo del usuario final se convierte en una necesidad.

40

“PeerPoint Ditech Networks” es reconocido como una solución líder para la

sesión de control de borde. La serie C100 “PeerPoint” posee características de

flexibilidad y una amplia interoperabilidad que permiten el despliegue de VoIP en

las redes sin requerir cambios en la red o en la configuración de los equipos a

los abonados VoIP. Esta versatilidad puede reducir considerablemente el costo

de entrega de servicios de banda ancha de VoIP.

• La ventaja de PeerPoint

El C100 PeerPoint tiene una amplia gama de implementaciones en el

mercado de SBC. Ya sea de acceso o interconexión, voz, vídeo o mensajería

instantánea, el C100 PeerPoint permite a los proveedores servicios superar sus

problemas de implementación de VoIP.

• Características del C100 PeerPoint incluyen:

o Optimización de los Caminos de Medios de Comunicación (MPO)

para diagnosticar la red en función de cada llamada y determinar el

momento de regenerar los flujos de medios, para permitir flujos

directos entre puntos finales.

o Una opción de implementación detrás de NAT de manera que no

hay una dirección IP pública que se revele en el lado peer.

o Una opción de “double home” de despliegue tanto para la medida

de fin de Network “Address Translation” (NAT) como para la

interconexión entre operadores.

41

o “Real Time Protocol” (RTP) de cifrado y “Transport Layer Security”

(TLS) de apoyo.

o Provisión para filtrar campos SIP desconocidos de cabecera de

protocolo.

o Seguimiento inteligente para marcar y controlar sospechosas

conexiones entrantes.

o Compatibilidad total con los principales proveedores.

El C100 es una opción PeerPoint para los prestadores de servicios y

compañías que requieren un SBC que resuelve sus problemas de producción

actual y los prepara para el futuro.

El éxito de cualquier servicio de voz o vídeo sobre IP depende de la

capacidad para hacer las conexiones correctas sin tener que redefinir o

comprometer la infraestructura de seguridad. El Session Border Controller (SBC)

de PeerPoint Ditech ayuda a las empresas y las compañías a conectar diversos

equipos, cortafuegos transversales, opera en ambientes NAT, reduce los costos

de ancho de banda, y evita la denegación de servicio (DoS).

Con más de 100 implementaciones en todo el mundo (originalmente

vendiendo como Jasomi), el PeerPoint Session Border Controller es reconocida

como la solución líder para la sesión de control gracias a un amplio conjunto de

prestaciones destinadas a hacer de VoIP una realidad en los entornos de

proveedores de servicios.

Los modos flexibles y la amplia interoperabilidad de PeerPoint C100

(SBC) permiten el despliegue en cualquier red sin requerir cambios a la red o la

configuración del equipo de los suscriptores de VoIP, reduciendo así el costo de

servicios de banda ancha de VoIP. Implementado en el borde de la red,

PeerPoint C100 es un elemento esencial para el acceso seguro del abonado y

los operadores de interconexión.

42

Ditech también está desarrollando un SBC de próxima generación para

aplicaciones de transporte.

3.2.6 InGate

Ingate SIParator es un dispositivo que se conecta a un servidor de

seguridad de red existente para permitir a la perfección comunicaciones SIP.

Mientras que los firewalls tradicionales bloquean tráfico SIP (incluyendo las

aplicaciones de misión crítica, como VoIP), SIParator resuelve el problema,

trabajando conjuntamente con sus soluciones de seguridad actuales. Ingate

SIParators están disponibles en una gama de modelos para satisfacer las

necesidades del mercado de toda la empresa [7].

• Ingate SIParator 19: Es una poderosa herramienta que ofrece a las

empresas pequeñas, sucursales y trabajadores a domicilio, soporte

completo para las comunicaciones IP basada en SIP. Con la SIParator 19,

estas empresas pueden aprovechar la misma productividad y ahorros en

el costo de la Voz sobre IP y otras comunicaciones basadas en IP, como

las grandes corporaciones.

• Ingate SIParator 50/55/65: Son herramientas poderosas para las

empresas que desean subir al siguiente nivel de la utilización de VoIP y

otras comunicaciones en tiempo real basado en IP, y para ello no sólo

dentro de la empresa, sino fuera de ella también, así . SIParators Ingate

están instalados en todo el mundo. Algunos escenarios comunes son las

conexiones de empresas a los proveedores de servicios de Internet de

telefonía (ITSP) a través de troncales SIP, el uso de conexiones a

usuarios remotos y oficinas sucursales con IP-PBX, y muchos más [7].

43

• Ingate SIParator 95: Ofrece a las empresas grandes una migración

controlada y asegurada a VoIP y otros tipos de comunicación en vivo,

basadas en SIP. Con la solución SIParator, incluso la mayor de las

empresas, con sucursales en todo el mundo y de trabajadores remotos,

puede aprovechar la productividad y los beneficios de ahorro de costes de

VoIP y otras comunicaciones basadas en IP, manteniendo al mismo

tiempo las inversiones actuales en tecnología de seguridad.

3.2.7 Audiocodes

A medida que los Proveedores de Servicios y Empresas otorgan mayor

importancia a los servicios “All-IP”, nuevos desafíos han surgido en materia de

interoperabilidad entre distintos sistemas VoIP. Por consiguiente, nuevas

necesidades han aparecido en el mercado, incluyendo SIP Trunk de Operador a

Empresa, conectividad de Empresa a Empresa, y conectividad Inter-Sucursales.

Todas estas necesidades requieren una mediación IP-IP, conversión SIP y

seguridad VoIP mejorada por parte de los Session Border Controllers (SBC) de

nivel empresarial.

Un SBC es un dispositivo B2BUA (Back to Back User Agent) que actúa

como servidor para la red interna y como cliente para las redes externas,

manejando todos los aspectos de una llamada VoIP, incluyendo: establecer y

desconectar una sesión, y crear una separación completa entre las redes. Esta

capacidad permite la incorporación de otras funciones tales como facturación,

invisibilidad de topología, control de admisión de llamadas y autorización, entre

otros.

La soludión de AudioCodes con respecto a SIP-Trunk se realiza en base a

la mediación IP-IP presentada en la versión 5.4 de Mediant 1000, que es la

primera de una larga lista de funciones SBC que han sido agrupadas en el

44

Mediant 1000-MSBG (Gateway de Negocio Multi Servicio). La versión 5.4 cuenta

con nuevas características, entre las que se encuentran:

• Normalización SIP-SIP: Permite la interconexión de dos sistemas SIP a

través de la normalización de distintas implementaciones de este

protocolo. El “Normalizador” actúa como servidor en un lado, terminando

las sesiones entrantes de una implementación SIP, y como cliente en el

otro lado, iniciando nuevas sesiones de otra implementación SIP.

• Topología de topología: Al actuar como un dispositivo B2BUA, los

usuarios externos no tienen visibilidad alguna sobre la topología de red

interna (por ejemplo: extremos, señalización y tráfico), proporcionando

así un alto nivel de seguridad. Además, dicho nivel de seguridad puede

ser aumentado gracias al cifrado de los campos de cabecera SIP

existentes en la red.

• Transcoding y conversión de medios: El Gateway puede convertir el

tráfico de voz entre dos redes separadas que utilizan distintos “codecs” o

las cargas útiles de los medios. Un ejemplo de ello sería el “transcoding”

entre WAN y LAN en el límite de una red empresarial (siempre que exista

un enlace troncal SIP) o la interconexión entre dos redes empresariales.

• Conversión de señalización: Conversión entre SIP <> SIP-TLS sobre TCP

o UDP (de cualquiera a cualquiera).

• Conectividad para diversos proveedores de servicios: Una empresa puede

utilizar diversos enlaces troncales SIP proporcionados por varios

proveedores de servicios, permitiendo así una selección dinámica del

proveedor con un costo de enrutamiento y redundancia del servicio

menores.

• Distribución balanceada de la carga y redundancia entre

Servidores/Softswitches: El “Media Gateway” permite la conectividad

simultánea hacia dos servidores (pertenecientes al mismo proveedor), así

como el desborde alternativo y la distribución balanceada de la carga

entre ambos.

45

• Supervivencia: Como dispositivo B2BUA, el Gateway proporciona una

capacidad de supervivencia autónoma y mantiene la conectividad interna

cuando el Softswitch central no está disponible. Este método de

supervivencia difiere del anteriormente presentado en la función SAS, ya

que el Gateway actúa como proxy (generalmente utilizado en entornos IP-

Centrex).

3.2.8 Stratus Telecomunications

Como todas las redes del mundo evolucionan hacia la propiedad

intelectual y en última instancia, un IMS como futuro, el SBC de Stratus

Telecomunicaciones de ENTICE (E-SC) resuelve los problemas críticos técnicos

de conectividad, seguridad y cumplimiento de las normas que son comunes a

todos los controladores de sesiones de una solución, es fácil de usar y

evoluciona a medida que evoluciona la red.

Con la solución ENTICE SC, se puede realizar “peer” directamente con los

proveedores de servicios utilizando SIP o H.323 y puede conectarse a la PSTN

utilizando cualquiera, ya sea SIP, H.323, H.248 y “gateways” con SIGTRAN. Si

existe necesidad de acceder a las aplicaciones basadas en SIP, como

conferencia y mensajería unificada o si es necesario para acceder directamente

a SCP externos a través de SS7, Stratus Telecom tiene una solución que

funciona a medida con el cliente. El E-SC proporciona conectividad e

interoperabilidad para el control de llamadas, el transporte y la aplicación de

capas de la red. Esta forma de conectividad allana el camino para una transición

sin problemas a las redes IMS.

Se puede aprovechar la solución Stratus Telecom SC para crear servicios

generadores de ingresos. El Stratus Telecom SC es una parte integral de todas

las soluciones ENTICE. El SC puede ser fácilmente integrado con otros

componentes para lograr rentabilidad con ENTICE: un alto crecimiento, las

46

soluciones altamente rentables, como VoIP residencial e IP Centrex. Debido a

que el SC es un componente integrado, el cliente no tendrá que pagar por doble

concesión de licencias, o sea, por sesión y por suscriptor como es común en

otras soluciones no integradas.

Por último, todas las soluciones ENTICE son flexibles, modulares y

altamente personalizables y programables, lo que significa que se puede generar

la solución que funcione para el cliente. Diseñado para ayudar a optimizar y

mejorar los servicios, el controlador de la sesión ENTICE incorpora más de 25

años de experiencia en telecomunicaciones de Stratus.

El controlador de la sesión ENTICE hace que sea fácil para el cliente

convertir los problemas diarios en cuanto a interoperabilidad en una oportunidad

de beneficio para el mañana.

Beneficios claves:

• Confiable, solución flexible, escalable y abierta a la interconexión de

diferentes redes IP con SIP, H.323, H.248, SS7 y SIGTRAN, entre otros.

• Disponible para todas las topologías de red, telefonía fija, móvil, cable.

• Sesión de control y la interoperabilidad de control de llamadas, el

transporte y la aplicación de capas.

• Lleva a cabo funciones críticas y una sesión de control ofrece un claro

camino a IMS.

• Captura de información por llamada para la facturación de mediación.

• Simple de usar.

• Estructuras básicas de servicios de extremo a extremo para generación

de ingresos.

• Disponible tolerancia a fallos de Stratus Technologies.

• Modular, personalizable y programable para proporcionar una solución

que funcione para el cliente.

47

3.2.9 Sansay

Fue fundada en junio de 2002 con el objetivo de desarrollar la más alta

calidad en sistemas de VOIP, más útil la infraestructura de las compañías y

proveedores de servicios en todo el mundo. Desde entonces, cientos de

proveedores de servicios han desplegado en todo el mundo Sansay soluciones,

y han sido nombrados en la lista Pulver dentro de las 100 empresas con mayor

crecimiento, junto con las principales compañías privadas en el sector de las

comunicaciones que tienen importantes implementaciones en el mundo de la

telefonía conmutada.

Los fundadores de Sansay fueron previamente co-fundadores y miembros

fundadores del equipo de “Nuera Communications”, una compañía que aún se

encuentra entre los jugadores más respetados en el mercado de infraestructura

de VoIP. En Nuera, el equipo fue responsable de la concepción hasta el

desarrollo y éxito en el mercado de los sistemas que alcanzaron puntuaciones

superiores en la industria, independiente-realizado, realizando pruebas

competitivas de los sistemas de paquetes de voz, en informes publicados desde

1997 hasta 2002.

Sansay ofrece un paquete completo de los sistemas de la gama VoIP que

son totalmente interoperables con las normas establecidas del VoIP. Se centran

en el tipo de clientes con alto volumen, las redes de VoIP de alta demanda.

El VSX es excelente en las aplicaciones de SIP Trunk, ya que puede

gestionar el Least Cost Routing y NAT Transversal como requisito. El VSX puede

manejar 100.000 grupos de enlace a los clientes SMB, sin importar si se

emplean las direcciones NAT o abiertos. Reducción de costes crítica, el

proveedor de servicios de Clase-5 disponen de servidores, no es necesario que

toque las llamadas de entrada y salida de los clientes SIP Trunk. Esto ahorra

enormemente en gastos de capital en dichas licencias. El VSX puede

48

proporcionar a las traducciones 8XX DID, las búsquedas CNAME, y 911 de

gestión de llamadas.

La amplia funcionalidad ubicada en el SBC Sansay VSX para VoIP,

permite un crecimiento flexible y la expansión de la infraestructura de red con

mínima inversión de capital. El VSX puede ubicarse en el centro o el borde de la

red de una compañía para gestionar el tráfico de VoIP entre SIP Proxies, UAs

SIP, gateways H.323, IP PBX y puertos H.323. Con el pleno control de admisión

de VoIP y de enrutamiento de llamadas dentro y fuera de la empresa a cualquier

IP PBX, el VSX también se puede utilizar para interconectar a las redes de otro

“carrier” de red.

El control XML simplifica la provisión de servicios para que los

proveedores puedan implementar rápidamente VSXs en muchos lugares que

ofrecen servicios de SIP Trunk en múltiples POPs. El VSX reduce gasto de

capital de la compañía para la apertura de nuevos mercados. Otros requisitos de

los equipos puede ser reducido con la solución Sansay, negando la necesidad

de crear más puertas de enlace VoIP y otros dispositivos, en que los POPs

manejan algunos procesos de llamadas de forma manual. El protocolo de

interconexión extensa Sansay crea una sola capa de enrutamiento para todas

las llamadas que permite a los operadores ponerse en el punto de enrutamiento

y maximizar los beneficios.

Otras ventajas Sansay incluyen:

• Inmediata cuenta de servicio utilizado, esto es sobre la marcha de los

servidores con actualizaciones de enrutamiento en la facturación.

• Las mayores tasas de terminación de llamadas con un máximo de 32

rutas alternas.

• Configuración de los clientes más rápida y flexible.

• Rápido aislamiento de problemas con las estadísticas detalladas del

cliente.

49

• Fácil uso de interfaz gráfica para administrador, basada en navegador

web.

La topología VSX esconde la red interna evitando cualquier ataque de

denegación de servicio (DoS), para optimizar la privacidad y el rendimiento de

forma simultánea. Reconocido en todo el sector por las capacidades avanzadas

de troncal, Sansay ayuda a los proveedores en su capital de inversión sobre el

legado de conmutadores TDM y los beneficios a medida que emigran a la

flexibilización de las infraestructuras IP.

3.2.10 Metaswitch

Es un proveedor líder de sistemas de soporte y soluciones de software

que están impulsando la migración de las redes de comunicaciones para abrir

las arquitecturas basadas en paquetes. Cientos de operadores de redes en todo

el mundo dependen de su Dirección de Sistemas de “carrier” para el control

fiable, escalables controles de sesiones, “media gateways” y

aplicaciones/soluciones en función de servidores para habilitar servicios

atractivos que generen ingresos. Los protocolos de la división de red desarrollan

un alto rendimiento, componentes de software portátil que se integran en los

productos de los principales fabricantes mundiales de equipos de

comunicaciones.

Las principales propuestas de servicio de Metaswitch son:

• El servidor de aplicaciones MetaSphere ofrece las funciones de llamada y

aplicaciones mejoradas para el legado, pre-IMS y redes IMS.

• CommPortal, es una suite de tecnologías de interfaz de usuario que

permiten a un abonado tener una universal experiencia de comunicación y

desarrollo de aplicaciones.

• MG Serie Universal “Media Gateway”, una serie de pasarelas que

permitan la interconexión entre redes IP y TDM.

50

• MR “Series Media Server”, es una plataforma de medios basado en DSP

que permite aplicaciones VoIP altamente escalable.

• VP “Series Integrated Softswitch” permite "una caja" del legado de las

antiguos sistemas switches hacia la migración con una ruta de

actualización perfecta a configuraciones distribuidas IMS.

• Red “MetaView” es un sistema de gestión que permite una administración

de redes completa que potencia a MetaSwitch.

MetaSwitch ha desarrollado una solución totalmente portátil Session

Border Controller (SBC-DC) de software diseñado especialmente para los

vendedores de sistemas. MetaSwitch amplía el patrimonio de VoIP y

enrutamiento IP que ofrecen los proveedores OEMs con una solución de SBC en

terreno dura que se despliega de inmediato, la entrega de costes es dramática

en cuanto a ahorro de tiempo de salida al mercado.

La solución DC-SBC ha sido aumentada para ofrecer soluciones flexibles

de IMS, para muchas de las funciones vitales en las redes IMS. Estas soluciones

están diseñadas de la misma manera que las DC-SBC, ya que son totalmente

portátiles a cualquier software y entorno de hardware.

• DC-SBC en IMS UNI: DC-SBC que ahora incluye soporte para el P-CSCF

y funciones BGF IMS e interfaces, ofrece toda la señalización necesaria,

CAC, interoperabilidad y características de seguridad necesaria para las

redes IMS.

• DC-SBC en IMS NNI: DC-SBC que apoya IBCF y funciones I-BGF IMS e

interfaces que permiten la interconexión entre los otros y no IMS IMS-

redes

3.3 PRINCIPALES MODELOS DE EQUIPOS SBC

Una vez conocida las ideas generales de cómo ofrecen sus productos los

distintos proveedores SBC, además de conocer cuál es su verdadera

51

especialidad dentro de esta rama, se centra el siguiente punto en

especificaciones, que aunque de manera gruesa, para dar una idea más técnica

de cómo se desarrolla esta tecnología, sin mencionar que se conocen ya de

manera más acabada la teoría que respaldan estos sistemas innovadores.

3.3.1 Acme Packet 3800 y 4250

Soporte de SCPs: SIP, H.323, interoperabilidad SIP/H.323, MGCP/NCS,

H.248, RTCP.

Control de sesión: completa en las áreas de seguridad,

aplicaciones/maximización de alcance del servicio, garantía de SLA (“Service

Level Agreement”).

DoS: Autoprotección contra capas 3 y 4, IPsec, protocolos de señalización

contra ataques de sobrecarga.

Administración: Aplicación NET-NET EMS y SAS, CLI, telnet, ssh, FTP,

XML, RADIUS, SNMP, syslog.

Interoperabilidad (probadas): Principales centralitas IP, plataformas de

comunicaciones unificadas, Servidores SIP, servidores de aplicación, gateways

de medio de comunicación, “softswitches”, elementos de IMS CSFC,

“gatekeepers” H.323.

• Capacidad para 4000 sesiones de señalización

• Alta disponibilidad (H.A.), redundancia 1:1, restablece estado

configuración y “media” para no tener perdida de servicio.

• QoS

• Encriptación: Opciones de sesión - Túnel IPsec y TLS, Opciones de

tráfico: IPsec y SRTP. 1000 túneles con llaves manuales, 5000 túneles

con IMS-AKA

• Entradas de rutas locales: 1.000.000 de rutas configurables

52

• Interfaces de red: 4 activas 10/100/1000 Mbps con interfaces Ethernet

• Rendimiento de sistema: 5 Gbps

Especificaciones Físicas/programables:

Chasis:

• 1U, para montaje en rack.

• Panel frontal: LED de estado para energía y H.A., “pinhole” para

restauración del sistema, interfaces de consola y almacenamiento local.

• Panel Trasero: Un unidad “slot” de interfaz de red (señalización, “media” e

interfaces de administración), una fuente de alimentación fija, escape de

aire de salida.

Memoria:

• 1 GB para la configuración activa y operación.

• 256 MB de memoria flash interna para almacenar archivos (sistema

operativo, configuración, “accounting”, “log”).

• Contenido de memoria direccionable (CAM): 128KB para ACL estática y

dinámica, reglas de control de “media” y entradas ARP.

• Una interfaz serial RS-232 con interfaz de consola RJ-45 (sólo por detrás

o delante de interfaz se puede utilizar en cualquier momento).

• Una interfaz de alarma con conector RJ-45.

• Panel de gestión de interfaces frontal.

• Una interfaz USB 2.0.

• Voltaje: 100-240 VAC entrada “autoranging” de ancho, con corrección de

factor de potencia.

• Frecuencia: 50/60 Hz.

• Corriente: 1,5 A a 115 VAC y 0,75 como máximo a 230 VAC.

De manera más gráfica se presenta en las figura 3-1 y 3-2, el “hardware”

que provee Acme Packet en su serie 4000 (modelo 4250).

53

Figura 3-1: Vista frontal del equipo SBC Acme Packet serie 4000

Figura 3-2: Vista posterior del equipo SBC Acme Packet serie 4000

54

3.3.2 Cisco CUBE y modulo SBC para Cisco 7600 series

Soporte de SCPs: SIP, H.323, interoperabilidad SIP/H.323, H.248, RTCP

Control de sesión: completa en las áreas de seguridad,

aplicaciones/maximización de alcance del servicio, garantía de SLA (“Service

Level Agreement”) a través de C.A.C. (Call Admission Control).

Seguridad: IPsec, SRTP, TLS

Administration: Cisco Configuration Assistant, CLI, telnet, ssh, FTP,

RADIUS, SNMP, syslog.

Interoperabilidad (probadas):

• H.323 to H.323 (incluyendo CUCM).

• H.323 to SIP (incluyendo CUCM).

• SIP to SIP (incluyendo CUCM).

• SIP to SIP (incluyendo llamadas con tele-presencia de cisco).

• Ofrecimiento tardío a temprano (“Delayed-Offer to Early-Offer”) de SIP

para llamadas de audio.

• Perfiles de configuración configurables para manipulación de mensajes

SIP.

• Transporte por TCP a UDP y viceversa

Características generales:

• Capacidad para 1000 sesiones de señalización como máximo (CUBE

1000).

• QoS: DSCP, “differentiated services code point” (ejemplo; dar prioridad a

los streams de video a medida que se transmiten por la red).

• Billing: CDRs estándares a través de AAA, SNMP, syslog.

• Codecs: G711 µ-law y a-law, G722, G723ar53, G723ar63, G723r53,

G723r63, G726r16, G726r24, G726r32, G728, G729, G729A, G729B,

G729AB y “Internet Low Bitrate Codec” (iLBC).

55

• “Transcoding”: entre cualquiera de las 2 familias de codecs de la siguiente

lista.

o G711 a-law and mu-law

o G.729, G.729A, G.729B, and G.729AB

o G.723 (5.3 and 6.3 kbps)

o iLBC

o G722

3.3.3 Juniper MX Series

Los routers de la serie MX son una gama de enrutadores “Ethernet” de

alto rendimiento, que funcionan como una plataforma universal de borde capaz

de soportar todo tipo de empresas, servicios móviles y residenciales. Con la

conmutación de gran alcance y características de seguridad, la serie MX ofrece

flexibilidad y confiabilidad para admitir servicios avanzados y aplicaciones. MX

Series “routers” trata por separado las funciones de control y de reenvío hasta

proporcionar un escalamiento máximo y capacidades de prestación de servicios

inteligentes. La Serie MX 3D Universal de enrutadores de borde están

optimizados para “Ethernet” y abordar una amplia gama de despliegues,

arquitecturas, densidades de puerto y de interfaces tanto para proveedor de

servicios como para los entornos empresariales. En ambos mercados, los

“routers” de la serie MX proporcionar escalabilidad, alta densidad de puertos de

conmutación y enrutamiento necesarios para usos tales como centros de datos.

Para los proveedores de servicio, MX “routers” series cumplen los requisitos de

“switchs” “ethernet carrier-grade” según lo definido por el “Metro Ethernet

Forum”. Desarrollado por Juno OS, la serie MX proporciona un entorno operativo

coherente (comprensible) que optimiza las operaciones de red y mejora la

disponibilidad, rendimiento y seguridad de todos los tipos de servicios de apoyo

en el borde de la red. Ofrece avanzadas características de enrutamiento en la

industria sin comprometer el rendimiento que maximiza la protección de la

56

inversión. Estas funciones incluyen la segmentación del tráfico y la virtualización

con MPLS, multidifusión de ultra baja latencia, así como la seguridad global y las

implementaciones de QoS para acelerar la entrega de aplicaciones sensibles al

tiempo y a servicios. La confiabilidad de “class-carrier” y características de alta

disponibilidad disponible en la serie MX incluyen reinicio elegante, sin parar el

enrutamiento, rápido re-enrutamiento (FRR), servicio unificado de actualización

de software (ISSU) y VPLS (“Virtual Private LAN Service”) “multihoming”.

Escalabilidad de interfaces: Excepto para el MX80, que no utiliza grandes

DPC o tarjetas MPC, cada chasis de la serie MX escala de tamaño con opciones

de 3, 6 o 12 “slots” que se pueden rellenar con “line cards” para acceso o

interfaces de red. Con hasta 12 “slots” de “line cards”, el “MX960 3D universal

Edge Router” soporta hasta 176 puertos de 10 GbE o 480 puertos Gigabit

Ethernet.

Desempeño de procesamiento de paquetes avanzado: cada “slot” de un

MX Series proporciona un “line-rate” de 120 Gbps en envío de paquetes.

Flexibilidad de servicio: Juniper se especializa bastante tanto en MPLS

como VPLS, y la serie “MX 3D Universal de Routers Edge” aprovecha el Junos

OS, que se despliega en los mayores proveedores de servicios (cerca de 600) y

una suerte de 100 clientes en el mundo empresarial. Los campos con eficacia

probada en Junos OS proporcionan características enriquecidas para la serie

MX, como la estabilidad y la amplitud de servicios que no suelen encontrarse en

las plataformas Ethernet.

QoS avanzado: La serie MX posee características QoS a nivel de

interfaz, lo que reduce costos y permite a los proveedores de servicios garantizar

que las aplicaciones y los servicios reciban el nivel adecuado de servicio sin

importar las condiciones del tráfico.

Alta disponibilidad: La serie MX ofrece una completa Junos OS como

sistema de ventaja continua, y así garantizar el funcionamiento ininterrumpido y

tiempo de actividad máximo. Así como la plataforma Carrier Ethernet soporta

57

ISSU, la serie MX puede ser actualizada con nuevas características de Junos

OS y versiones con un mínimo riesgo o tiempo de inactividad. La serie MX

también proporciona características tales como “Graceful Routing Engine

Switchover” (GRES), “Non-Stop routing” (NSR) activo, y Detección de

“Forwarding” Bidireccional (BFD) para proporcionar una recuperación rápida y la

convergencia de redes en el caso de enlace o fallos de nodo.

Simplicidad en la administración: Aprovechando las herramientas del

sistema operativo Junos tales como J-Web y “Junos Script”, la serie MX reduce

el tiempo y los gastos de provisión de nuevos servicios. La característica Commit

Scripts ofrece capacidades automatizadas de retroceso que prácticamente

eliminan la posibilidad de tiempo de inactividad basado en errores de

configuración humana. Con la interfaz gráfica de J-Web basada en la web, la

serie MX proporciona a los usuarios una manera fácil de usar herramientas para

administrar y gestionar routers.

VPNs de MX Series: Junos OS soporta una gran cantidad de variedad de

tipos de accesos seguros de la industria de VPN.

• VPN MPLS de capa 2: La serie MX ofrece soporte completo tanto para

LDP y BGP basado en VPLS, así como LDP y BGP basado en pseudo-

lineas. Con soporte para hasta 1 millón de direcciones MAC y 64.000

VLAN, la serie MX ofrece gran escalamiento para VPNs de Capa 2.

• MPLS VPN de nivel 3: Con el soporte para todos los tipos de VPN IPv4 e

IPv6, así como VPNs tal como 6PE y 6VPE, la serie MX amplía la gama

de las compañías de servicios que pueden ofrecer a los clientes. La serie

MX soporta VPN con funciones avanzadas de capa de aplicación, tales

como “Session Border Controller”, “Dynamic Application Awareness”,

“Intrusion Prevention System” y Servicios “Stateful Firewall”.

• VPN de carrier a carrier: La serie MX permite que un proveedor de

servicios de VPN proporcione servicio a un cliente que también es un

58

proveedor de servicios. Y este último proveedor de servicios suministre

Internet o servicios VPN para el cliente final.

• VPN inter-proveedores: Juniper soporta estándares basados en

“Interprovider VPNs”, habilitando a los clientes una fuente de conectividad

entre dos redes privadas virtuales en distintos sistemas autónomos (ASs).

Esta funcionalidad puede ser utilizada por un cliente VPN con conexiones

a varios proveedores de servicios de Internet (ISP), o diferentes

conexiones con el mismo ISP en varias regiones geográficas.

• VPNs basado en enrutador virtual: Con las capacidades de virtualización

del sistema operativo Junos, la serie MX se puede dividir en varias

instancias de enrutamiento virtual o lógico, cada uno en apoyo de una

VPN individual. Esto abre nuevas posibilidades para los servicios de VPN

o segmentación de la red de la empresa.

3.3.4 Genband S3 y S9

Seguridad de red IP: “Firewall” de control de acceso, incluyendo

“Pinholes” de Control de Señalización de “media”. NAT Transversal con y sin SIP

ALG habilitado. Topología oculta, Detección RTP de intrusos, “Blacklisting”, TLS.

Control de admisión a sesión (SAC). DoS y protección distribuida de DoS.

Funciones de interoperabilidad: B2BUA, H.323/SIP con AAA, H.323

versión 4 con versión 2. H.323 partida rápida y lenta. SIP sobre UDP/TCP/TLS.

SIP/Tel URI. SIP-T, SIP-I, soporte SIP para mensajería instantánea y presencia.

Soporte túneles H.245, H.225. Soporte para interfaz de recepción 3GPP (PCRF).

Detección de disponibilidad de un “endpoint”. Solapamiento de “realm” y

señalización de direcciones IP. Simultáneos peering con múltiples “Gatekeepers”

y “Gateways”.

Servicios de ruteo avanzados: “Least Cost Routing”. Translación de

número de llamada, bloqueo de llamada, detección y prevención de “loop” en

59

llamadas. Rastrear rutas de llamadas con determinadas rutas avanzadas por

parámetros dinámicos o estáticos. Flexibilidad de políticas para habilitar “Hosteo”

o Ruteo directo de “media” entre “endpoints” detrás del mismo NAT. Grupos

troncales de fuente y destino. Interfaz de DNS SRV. Servicio de particionado

para cliente y tipos de servicio.

“Transcoding” y Adaptación de “media”: “Transcoding” de Voz y

translación de DTMF, SIP info, SIP Notify, basado en RFC 2833. G.711/T.38

enlace de Fax.

Notificaciones SLA y administración: exhaustivos “Session Detail Records”

(SDRs) basados en grupos troncales, señalización, e información de protocolo.

Sobre 80 campos SDR, métricas de QoS, soporte RADIUS AAA. CLI, SNMP (v2,

v2c, v3), syslog, SSL, HTTPS, servicios “Web”

Cumplimiento de normas: Intercepción Legal (LI)/CALEA, priorizando

E911.

Desempeños: Sistema de Alta disponibilidad “active/standby” con

monitoreo de estado de señalización de llamadas y “media” sin pérdida de

servicio. La tasa de llamadas simultáneas soportadas es de 150 llamadas por

segundo (CPS), 100.000 subscripciones, capacidad de sesión en el mundo real

(PSTN) SIP-SIP asciende a 25000 llamadas concurrentes, y para H.323-H.323

asciende a 16000 llamadas activas.

Especificaciones de Hardware: Ethernet óptico o pares de cobre

10/100/1000. 6 interfaces de señalización o administración, 4 interfaces Ethernet

de “media”, 1 puerto serial para consola.

3.3.5 Ditech PeerPoint C100

Solución a problemas de NAT Transversal: Problema típico en sistemas

VoIP es el estar tras direccionamiento NAT y “firewalls” en general. PeerPoint

60

garantiza que los suscriptores pueden conectarse en cualquier lugar y en

cualquier momento, sin tener que reconfigurar su equipo.

• NAT transversal para “Far-end”:

o “Pinhole” remoto para mantenimiento de NAT.

o Mapeo de canales NAT remoto.

o Registro obligatorio.

• Optimización de “Media audit” y “Media path” (MPO).

• Termino de sesión automático (AST).

• Aplicación de QoS.

Seguridad: Protección al proveedor de servicios en los servidores de su

lado (“back-end”), de potenciales infractores. Debido a la situación en el borde

entre los servidores del lado “back-end” y los usuarios de internet, PeerPoint

permite el tráfico de multimedia a través de una validación con informes de

tráfico malicioso. Oculta la información topológica de la red interna, así lo que

queda a la vista es la capa de aplicación a través de los protocolos de

señalización.

• Seguridad de red en “core”:

o “Media” con estado firewall.

o Rango de puertos para “media” configurable.

o Protección contra tormenta de peticiones SIP*.

o Filtro para malformaciones de mensajes basados en arquitectura

B2BUA.

o Campos configurables para rechazar cabeceras desconocidas.

o Tasa de flujo de señalización limitable (TCP).

o Lista de control de acceso “Black/White” para flujo de señalización.

o Enrutamiento forzado de señalización de llamada configurable.

o Enrutamiento IP forzable, incluyendo forzamiento de puerto

ethernet.

o Inspección de paquetes RTP.

61

• Topología de red oculta:

o De la capa 3 a la 5.

o NAPT dual.

o Eliminación e inserción de cabeceras y campos de aplicaciones del

protocolo SIP (Rutas, VIA, entre otros).

• Encriptación

o Realización de políticas de encriptación.

o “Transcoding” de transporte forzado configurable (UDP, TCP, TLS).

o “Transcoding” de encriptación de “media” configurable (RTP a

SRTP, SRTP a RTP).

o SRTP a SRTP con registro de sesión.

“Peering”: Ayuda a los proveedores de servicios a reducir costos y así

lograr desarrollo en nuevos mercados, permitiendo así sin problemas la

interconexión con otros proveedores de VoIP. Por último, permite servicio de

SIP-trunk para clientes empresariales.

• “Inter-Carrier peering”:

o Enrutamiento forzado.

o Opción de “bypass” de “media”.

o Normalización de SIP URI *.

Interoperabilidad: Permite a una amplia gama de “end-points” y servidores

interactuar entre sí. Son interoperables con grandes proveedores como

Broadsoft, Cisco Systems, CopperCom, CounterPath Solutions, Grandsteam

Network, MetaSwitch, Polycom, Sylantro Systems, y muchos más.

• Detección de fallas basado en Protocolo de Redundancia de Ruteo Virtual

(VRRP).

• Redundancia de servidor remoto, “Load balancing”, y priorización (LCR).

62

Revisión de cuentas, Administración, y problemas de aislamiento: Gestión

de “media” y señalización, esto permite recoger datos forenses tales como

métricas de QoS, información del dispositivo remoto e información de calidad de

voz para ayudar a reconocer problemas de telefonía o para cumplir con los SLAs

con otros socios “peering”.

• CLI con seguridad (SSH2, SCP).

• Autenticación RADIUS.

• Múltiples niveles de privilegios en administración, lectura y escritura.

• Reportes externos:

o Estadísticas de Llamadas.

o Información NAT.

o 3 niveles de seguimientos de señalización *.

o Syslog.

o SNMP MIB Ditech *.

o SIP MIB *.

• Registros internos de señalización SIP como información forense.

(Nota: *= caracteristicas en desarrollo)

Este equipo está diseñado para prestaciones SBC, por ello mismo la

importancia de conocer su estructura física, esta se muestra en la figura 3-3.

Figura 3-3: Vista Frontal de PeerPoint C100 de Ditech

63

3.3.6 InGate SIParator 19,50,55,90,95

Especificaciones de Hardware: Ethernet con pares de cobre 10/100 (3 a 4

interfaces). Sin fuente de Poder redundante. Memoria Flash para sistema

operativo. Las dimensiones de físicas de estos equipos varias desde

228x146x44 hasta 430x485x88.

Administración: Revisión automática de nuevas versiones de software.

Tiene opciones de administración con WEB GUI (http y https), y CLI (ssh y

consola), monitoreo SNMP. Desde 16 a 256 Vlans configurables. Notificaciones

en HD interno en todas las series menos en la 19. Notificaciones a través PCAP

en todas las series. Posee Syslog y envío por e-mail. Autenticación externa a

través de servidor RADIUS tanto para GUI como para SIP. Soporta múltiples

ISPs. Posee Actualizaciones gratis de software [7].

Funcionalidades SIP: Posee SIP “proxy”, SIP “registrar”, SIP “traffic” a

direcciones IP privadas (NAT/PAT), “Setup” de SIP “connection” (SIP+RTP). El

retardo de “data” RTP en las interfaces 10 Mbps/100 Mbps es de 0.19/0.08 [ms]

respectivamente. El número de sesiones de voz RTP simultaneas varía desde 40

(SIParator 19) hasta 1500 (SIParator 90), y para sesiones de voz RTP

simultáneas encriptados (SRTP y TLS) varía desde 20 (SIParator 19) hasta 750

(SIParator 90). En cuanto a intentos de Llamadas en Horario Peak, los SIParator

soportan desde 3600 hasta los 234000 intentos. Tanto la función “Billing” como

la autenticación de “SIP users” desde un servidor RADIUS externo, todo esto

para el control de acceso y uso del servicio, están disponible en todos los

equipos SIParator. Todas estas funcionalidades cumplen con los requisitos de

“SIPconnect” [7].

Módulos adicionales: Se tiene el módulo SIP-Trunk principalmente, así se

tiene una conectividad de una IP-PBX a ITSPs SIP-trunk. Conectividad remota

SIP a través de “NAT-passering” incluyendo STUN-server). QoS en cuanto a

limitación y priorización de ancho de banda. Seguridad en el intercambio, ya sea

64

IDS/IPS para SIP, SRTP y TLS. “VoIP survival”, sería la redundancia de

información VoIP si la conexión a Internet falla.

3.3.7 Audiocodes Mediant 1000 MSBG

Especificaciones de Hardware: En cuanto a capacidades en PSTN, posee

6 “slots” para procesamiento de “hosting” de voz y módulos de terminales PSTN

(hasta 120 canales TDM-VoIP por “Gateway”). Posee módulos digitales, 1, 2 ó 4

expansiones E1/T1/J1 por módulo usando conectores RJ-48c con una opción de

PSTN de última instancia. Posee módulos análogos, 4 puertos FXO o FXS por

módulo usando conectores RJ-11, además de 4 puertos BRI por módulo. Módulo

de procesamiento de “media” soporta hasta 60 ramas de conferencias. Todo lo

anterior se aprecia en la figura 3-4. En cuanto a interfaces de red, posee un

puerto WAN las siguientes características: 10/100/1000Base-T, 1000Base-

SX/LX, T1 DSU/CSU, SHDSL*, ADSL2+*, E1 DSU/CSU*. En el lado LAN tiene 3

puertos 10/100/1000Base-T. Con una CPU Pentium M de 1.4 Ghz, 1 Gb o 2 de

RAM, Almacenamiento individual/dual en discos duros. Interfaces para actuar

como una plataforma de: 10/100/1000Base-T, USB, VGA, RS-232 (nota: * = aún

no implementado).

Procesamiento de “media”: En cuanto a codificación de voz se tiene;

G.711, G.726, G.723.1, G.729A, GSM-FR, iLBC, EG.711, G.722 *. Con una

dinámica de codificadores independiente por canal de voz. Cancelación de

“Echo” con G.165 y G.168-2002. “Buffer” de “Jitter” dinámico programable, VAD,

CNG. Posee Tonos DTMF y MF. Transporte IP de Voz por RTP/RTCP de

acuerdo a las RFC de la IETF 3550 y 3551, también tiene transporte de servicios

de Fax y Modem T.38, “bypass” automático a PCM o ADPCM y V.34.

Señalización: En cuanto a protocolos PSTN digitales posee CAS, ISDN

PRI, ISDN BRI. Por el lado análogo tiene FXS, “Caller-ID”, distinción de “ringing”,

indicación visual de mensaje en espera.

65

Ruteo de datos: DHCP/PPPoE/L2TP/PPTP para clientes accediendo a la

WAN y DHCP para Server accediendo a la LAN, VLAN. Ruteo estático y

dinámico (RIP, OSPF, BGP). PPP y HDLC. IPv6*.

Control y administración: En cuanto a protocolos de control se tiene SIP-

TCP, UDP, TLS y MSCML, Modo “Stand Alone Survivability” para continuidad del

servicio. Por el lado de la administración este equipo posee su propio

administrador (AudioCodes’ Element Management System). Y los métodos

clásicos tal como, un servidor WEB HTTP, Telnet, SNMP V2/V3, configuración

remota y descarga de software a través de TFTP, HTTP, HTTPS, DHCP y

BootP, RADIUS, Syslog (para eventos ,alarmas y CDRs).

IP/VoIP QoS: Sigue las recomendaciones IEEE 802.1p (ToS, DiffServ), e

IEEE 802.1Q (etiquetado VLAN). Configuraciones para; políticas, datos en cola,

reservación de ancho de banda. Realiza RTCP-X, con esto publica reportes

VoIP, es más bien un Administrador diseñado para VoIP según RFC 3611.

Seguridad: Por el lado de VoIP se tiene Session Border Controller, con

ello también conversión de cabecera SIP, “Translations” IP a IP en enrutamiento

de SIP/UDP/TCP/TLS, también “Translations” de RTP y SRTP, soporte SIP-trunk

con multi-ITSP (registrarse a ITSPs es invocado independientemente), ocultación

de topología, CAC, lista de llamadas “Black/White”, detección/prevención de

intrusión (NIDS), y mecanismos Anti SPIT/SPAM. La seguridad en cuanto a los

circuitos de datos se caracteriza con; IPsec hasta 8 enlaces (tales como ESF-

modo túnel, encriptación, autenticación, modo IKE, IPsec VPN), Protección DoS

de; tráfico fragmentado, peticiones mal formuladas, “Ping of death”, ataques

DoS, peticiones formuladas apropiadamente desde fuentes no autorizadas,

ataques DDoS, inundación de paquete SYN. También posee “Firewall” de

inspección de estado de paquetes, fragmentos maliciosos y conexiones falsas.

66

Figura 3-4: Vista Frontal de Mediant 1000 MSBG de Audiocodes

3.3.8 Stratus telecommunications ENTICE Session Controller

Seguridad: Acceso para control de Firewall, ocultación de topología,

control de admisión de sesión (SAC), DoS y su protección distribuida,tasa de

transacciones limitada, tasa de registrados limitada, Listas “Balck/White”.

Interoperabilidad e inter-funcionamiento: B2BUA (“Outbound Proxy Mode”:

OBP), “Firewall/NAT-T”, “Transcoding” (opcional), “Translation” de DTMF,

soporte SIP-T, políticas de codecs, soporte T.38, soporte SS7, SIGTRAN

(opcional), soporte H.248 (opcional), soporte de RADIUS AAA (opcional),

“Matching”/Manipulación de dígitos, soporte de registro de subscripciones

(opcional), Compatibilidad entre versiones 2,3, y 4 de H.323, pleno estado de

enrutamiento, soporte de “Tunneling” H.245, soporte de mensajes “Registration,

Admission and Status” (RAS) de H.225 para funcionalidades alternativas

“Gatekeepers”, “Peering” simultaneo con múltiples “Gatekeepers” y “Gateways”,

inicio de H.323 rápido y lento, Soporte a recursos de grupos de fuente y destino,

detección y prevención en “Loops” de llamadas.

Flexibilidad: Opción de separar la señalización y la “media”, arquitectura

distribuida en “Clusters”, planes de marcado local y global, “Roaming” del

“Endpoint”, particionado de servicio basado en clientes y ToS, soporte de

67

funciones de política distribuida para IMS (opcional), soporte para ENUM,

Aplicaciones de acceso entre SS7 y SIP basados en inter-funcionamiento.

Garantías SLA y CAC: Control de admisión basado en llamadas,

utilización y capacidad, Listas de rutas para enrutamiento avanzado por

parámetros dinámicos y estáticos, “Translation” de Pre/Inter/Post periodo de una

llamada, “Translation” y ocultación de un número de llamada, número de llamada

aleatorio, admisión y rechazo de una llamada, CDRs comprensibles, Soporte

para “SNMP trap”, calificaciones de QoS, RADIUS AAA, SOAP basado en

prestaciones.

Cumplimiento de normativa, servicios de acceso industrial: CALEA,

cumplimiento de servicios de emergencia, 800, LNP, ocultación de destino,

CNAM a través de SIP/SS7.

3.3.9 Sansay VSX

Características:

• Auto-aprendizaje de direcciones de puertos IP/UDP para los abonados

SIP.

• Protección de firewall completo para el Sistema de gestión de contenidos

(CMS), “softswitchs” o de características de servidores.

• “Load Balancing” para las llamadas entrantes a un máximo de 64

servidores de funciones.

• Soporte para miles de particiones de suscriptores para las aplicaciones

alojadas.

• Firewall y Network Address Translation (NAT), cerca y lejos del final (near-

end/far-end).

• Topología de red (IP) protegida y oculta en cuanto a los recursos.

• Protección de los activos de la red de ataques de denegación de servicio

(DoS).

68

• 125.000 suscriptores activos por chasis, más de 1 millón de suscritos por

“cluster” SPX.

• 25.000 sesiones por chasis, 300 llamadas por segundo es la tasa de

llamadas sostenida.

• Completamente redundante con software de balanceo de carga.

• Protocolo de “translation” para inter-funcionamiento SIP-H.323.

• CDRs o RADIUS para “accounting”/autenticación.

3.3.10 Metaswitch DC-SBC

Modularidad y escalabilidad: En cuanto a las funciones SBC e IMS

comparado con señalización y “media”, estas últimas no se desempeñan mucho

en el concepto de modularidad. Así SBC e IMS en estos equipos pueden ser

interconectadas entre sí como una solución completa o con licencias aparte

dependiendo de las prestaciones que requiera el cliente, no así la señalización y

la “media”, que son fundamentales en el servicio. Además si hablamos de

modularidad de hardware, este es un concepto aún más fuerte, ya que se habla

de independencia y despliegue de los módulos no solo dentro del equipo, sino

que además de un despliegue geográfico Todo esto da como consecuencia su

gran escalabilidad.

Detección y protección de DoS (Seguridad): ofrece funciones avanzadas

de Denegación de Servicio, con políticas CAC, “Blacklist” dinámicas de ataques,

que en extremo permite incluso evitar las prestaciones del servicio. En cuanto a

detección, esta puede identificar distintos tipos de ataques, y planear distintas

estrategias de protección según el tipo de ataque.

Habilitación de IMS: En la familia de soluciones para IMS que incluyen

DC-SIP, DC-Diameter, DC-Megaco/H.248, todos son compatibles con los

estándares 3GPP, ETSI, TISPAN, IETF y la UIT, basados en IMS. DC-SBC

puede ser utilizado para aplicaciones “user-network” y/o “network-network”, en

69

cuanto a seguridad necesaria, control de llamadas, creación de servicios y

funciones necesarias de accesibilidad para PCSCF, IBCF, BGF, y aplicaciones

IBGF.

Servicios: “Transcoding” de “media”, política de SLA, VPN de capa 3 (RFC

2547), inter-funcionamiento DTMF, políticas basadas en enrutamiento, evasión

de congestión de red, QoS basado en MPLS, intercepción legal de CALEA,

E911, Voz, Fax, “Modem” sobre puente “media” de IP, “Billing”; CDR, tiempos de

sesión, RADIUS.

Accesibilidad: “pinholing” de señalización y “media”, SIP, H.323,

direccionamiento IPv4 e IPv6, inter-funcionamiento de protocolos de

señalización, “Firewall/NAT Transversal, proposición de superposición de

direcciones, detección/corrección de protocolos defectuosos.

CAPÍTULO 4

CONCEPTOS Y APLICACIONES DE LOS EQUIPOS CON PRESTAC IONES DE SESSION BORDER CONTROLLER

4.1 IP MULTIMEDIA SUBSYSTEM (IMS)

La plataforma IMS es una arquitectura de “core” que permite la

comunicación entre servidores y clientes, y que abre una gran posibilidad a la

convergencia entre las redes móviles y fijas. Está compuesto por una

arquitectura unificada, ordenada en capas, que permite el manejo de los medios

a través de la red, independiente de su posición y que logra entregar la

integración necesaria para comunicar servicios Multimedia IP para las redes

cableadas e inalámbricas por igual [5].

Esta arquitectura define el control, ruteo y protocolo de servicios a través

de la red, independiente del dispositivo o del formato de los datos. Estos

servicios son soportados por los servidores de aplicaciones.

En la figura 4-1 se presenta la arquitectura IMS, identificando sus

componentes y la separación en tres capas que ésta posee:

Figura 4-1: Diagrama de Arquitectura IMS separada por Capas.

71

• Capa de Conectividad: Se compone de la capa de acceso y la capa de

transporte, la cual se encarga de la conectividad en los usuarios y entre

los distintos ISPs.

• Capa IMS: También es llamada la capa de Control, se preocupa de la

gestión y control de las comunicaciones.

• Capa de Servicios y Aplicaciones: Esta capa posee servidores de

aplicaciones y medios, los cuáles procesan y guardan los datos de la red

y generan servicios para los clientes [5].

4.1.1 Capa de conectividad

La capa de conectividad se compone de la capa de acceso y la capa de

transporte IP las cuales se muestran en la figura 4-1. Compuesta de switches,

routers, UEs, en la red de acceso, y en la de transporte de la red se destacan los

gateways hacia las redes PSTN e IP externas, y un servidor MRF.

El servidor MFR se preocupa de enviar y gestionar la transmisión RTP,

procesar, codificar y decodificar la información de audio y video, y gestionar las

videoconferencias de múltiples usuarios.

Un UE se comunica a través de la red IP con el S-CSCF que le fue

asignado, para que se gestione la comunicación, verificando el acceso a los

servicios, haciendo disponible los recursos de red y finalmente buscando y

estableciendo la conexión con el UE de destino.

Finalmente, el IMS – MGW permite la comunicación de voz entre la red IP

y la red PSTN, traduciendo la comunicación hacia y desde ambos lados.

72

4.1.2 Capa de control

La capa de control se compone del CSCF, BGCF y del MGCF. El primero

es un servidor que realiza la gestión para la comunicación en los UEs,

verificando, con el MRF, si es que se tiene recursos de red disponibles para la

comunicación y se comunica con el HSS para ver si es que el usuario tiene

permiso para ingresar a la red y para utilizar ciertos servicios.

Luego se tiene el BGCF, el cuál su única función es la de seleccionar en

su misma red el MGFC, y en una red externa, el BGCF de aquella red.

Finalmente, se tiene el MGFC, que es el encargado de enviar y traducir la

información de señalización y control desde la red IP a la red PSTN y viceversa.

De este modo controla al IMS-MGW y además determina el destino de las

llamadas originadas en la PSTN que tienen como destino la red IMS.

4.1.3 Capa de servicios y aplicaciones

En esta capa se encuentran el bloque HSS y los servidores de

aplicaciones (AS).

El HSS es un servidor que contiene la base de datos de todos los clientes

IMS y de todos los servicios que éstos tienen acceso. Este servidor es el

responsable de todo lo referente al usuario, su identificación, su numeración, su

dirección, su información de seguridad y su ubicación.

Los ASs son servidores de la red IMS que entregan servicios de valor

agregado a ésta. Normalmente se compone de aplicaciones SIP que ejecutan

aplicaciones y servicios IMS a través de la manipulación de la señalización SIP,

y la interfaz con otros sistemas.

73

4.1.4 Protocolos de la arquitectura IMS

Durante la especificación de IMS, 3GPP e IETF establecieron un acuerdo

de trabajo que ha ligado fuertemente el desarrollo del estándar de éste; quién ha

tenido que acelerar la estandarización de los protocolos IP emergentes que se

emplean en IMS, a la vez que realiza especificaciones a medida y exclusivas

para 3GPP. Se considera que IMS y 3G pueden ser los catalizadores para el

desarrollo comercial de los protocolos propuestos por la IETF, como es el caso

de IPv6 y SIP, principales protocolos de IMS.

• El control de sesión es realizado por el protocolo de control de llamada

IMS basado en SIP y SDP. La señalización de IMS se efectúa mediante el

protocolo SIP, que IETF diseñó para la gestión de sesiones multimedia en

Internet. A petición de 3GPP, IETF ha ido añadiendo al protocolo básico

extensiones y cabeceras privadas. SIP aporta las funciones para el

registro, establecimiento, liberación y mantenimiento de las sesiones IMS,

lo que incluye funciones de enrutamiento de sesiones e identificación de

usuarios y nodos, y también habilita todo tipo de servicios suplementarios.

Cabe mencionar que los mensajes del protocolo SDP se transfieren en

los mensajes SIP. El protocolo SDP, también diseñado por IETF, se

emplea para describir la sesión que se negocia con SIP. Mediante SDP,

los extremos de una sesión pueden indicar sus capacidades multimedia y

definir el tipo de sesión que se desea mantener. Además, con ellos,

deciden qué flujos multimedia compondrán la sesión, de manera que

establecerán a qué tipos de medios multimedia corresponden dichos flujos

(audio, video, entre otros) y qué “codecs” soportan y desean emplear para

cada flujo, así como la configuración específica de los “codecs”

anunciados. Mediante este intercambio de señalización se negocia la

QoS, tanto en el establecimiento como durante la sesión en curso, si es

necesario.

74

• El transporte de red es realizado mediante IPv6. IMS se ha definido desde

su origen como una red y un servicio fundamentado completamente sobre

IPv6. El subsistema GPRS 3G que proporciona acceso a dicha red IPv6

ha visto modificadas sus especificaciones para soportar el transporte de

datagramas IPv6 desde el terminal de usuario hasta IMS, así como otras

funciones tales como la configuración y la asignación de direcciones de

red. Por otro lado, el terminal IMS ha de soportar IPv6, y posiblemente

IPv4. La razón para que IPv6 sea un requisito básico es la previsión del

próximo despliegue paulatino de IPv6 en Internet. Por otro lado, además

de las ya conocidas ventajas inherentes a IPv6 como son la QoS, la

seguridad integrada y el mayor espacio de direccionamiento, el tráfico del

plano de usuario se transfiere directamente entre terminales siguiendo el

paradigma “peer-to-peer”. Por tanto, IPv6 simplifica el transporte de este

modelo de tráfico en las redes IPv4 privadas.

Además de SIP/SDP e IPv6, 3GPP emplea otros protocolos de la IETF

para la provisión de servicios IP multimedia, como son:

• Los protocolos RTP y RTCP, que se utilizan para el transporte de flujos IP

multimedia del plano de usuario.

• El protocolo COPS, se utiliza para el control de los recursos mediante el

uso de políticas de asignación de los mismos en función de los objetivos

marcados de calidad.

• El protocolo Diameter, es utilizado para aquellas acciones relacionadas

con la autorización, autenticación y tarificación.

• RSVP se usa para asegurar la QoS extremo a extremo, especialmente

cuando la conectividad IP requerida se extiende más allá de la red.

• El protocolo Megaco (H.248), es utilizado para el control remoto de los

“Media Gateways”.

75

4.1.5 Arquitectura IMS en 3GPP

La arquitectura IMS en 3GPP consta en la parte central por los servidores

CSCFs que usan el protocolo SIP para su comunicación. Este se divide en: P-

CSCF, S-CSCF e I-CSCF. Según la arquitectura IMS, estos servidores se

encuentran en la capa de control:

• P-CSCF: Es un servidor proxy SIP y es el primer contacto de un equipo

terminal con la plataforma IMS. Este acepta todos los requerimientos SIP

que se originan en el equipo terminal o van hacia él, los procesa

internamente o los reenvía a otro servidor. También posee funciones de

control y administración de recursos.

• S-CSCF: Es un servidor SIP que siempre reside en la red local del

suscriptor y provee servicios de control de sesión. Constituye el elemento

central de la red IMS en el plano de la señalización. Crea un enlace entre

la identidad pública del usuario (dirección SIP) y la dirección IP del

terminal. Usa el protocolo Diameter para interactuar con el HSS y extraer

desde ahí la dirección IP o perfil de usuario y vectores de autentificación

que permiten la creación del enlace. Todos los mensajes SIP originados

por el terminal o destinados hacia él pasan por el S-CSCF, aquí se

procesan los mensajes y se determinan las tareas subsiguientes a partir

del contenido de estos. Tal como un servidor proxy SIP, puede confiar los

mensajes SIP a otros servidores SIP o CSCFs. También puede

interactuar con los servidores de aplicación y reenviar mensajes SIP entre

ellos.

• I-CSCF: Es un servidor proxy SIP que constituye el enlace de la

plataforma IMS con redes externas. Este selecciona un S-CSCF para un

usuario y traspasa los mensajes SIP entre ellos. La selección del S-CSCF

se basa en las capacidades requeridas y las disponibles, y la topología de

la red. También puede ser usado para esconder información sobre la

76

estructura interna de la red, a través de la encriptación de parte de los

mensajes SIP.

En 3GPP, la plataforma IMS incluye muchas otras entidades funcionales.

El servidor HSS es la base de datos central que contiene la información

relacionada a un usuario. Si hay más de un HSS en la red, un SLF puede indicar

la dirección del usuario a los correspondientes servidores HSS. La MRF provee

los recursos multimedia a la red local y se divide en MRFC y MRFP, que se

comunican entre sí a través del protocolo Megaco/H.248. El servidor SIP BGCP

tiene la responsabilidad de escoger una red PSTN/CS adecuada si la sesión así

lo requiere. La interacción con la red de circuito conmutado se realiza a través

del MGCF y MGW.

4.1.6 Procedimiento de registro

El procedimiento de registro en IMS se representa en la figura 4-2.

Figura 4-2: Procedimiento de registro en IMS.

77

En primer lugar, como paso previo para acceder a IMS, el usuario debe

registrarse en el sistema. Mediante este proceso se activan las identidades

públicas que el usuario desea emplear en sus sesiones multimedia y se

establece el S-CSCF que le aportará el servicio. Para llevarlo a cabo, se emplea

la señalización SIP y un algoritmo de autorización/autenticación por defecto de

usuario a red, y viceversa, que recibe el nombre de IMS AKA (IMS con

autenticación y validación de claves).

A continuación, el usuario inicia el proceso enviando un mensaje SIP

REGISTER hacia el P-CSCF, que detecta que se trata de un mensaje no

protegido por ninguna asociación de seguridad previa; es decir, se trata de un

mensaje de registro inicial. En ese mensaje se encuentran la identidad privada

del usuario, almacenada en la ISIM, y las identidades públicas que desea

registrar para su posterior uso.

En esta fase, el P-CSCF envía el mensaje hacia un I-CSCF, que se

encarga de seleccionar un S-CSCF hacia el que reenvía la petición de registro.

Cuando el S-CSCF recibe el mensaje, comprueba que no se trata de un usuario

ya registrado y contacta con el HSS para obtener los vectores de autenticación,

necesarios para el algoritmo IMS AKA.

Posteriormente, para solicitar la autenticación, devuelve hacia el terminal

un mensaje SIP 401 “No autorizado”, en el que se incluyen ciertos números

generados aleatoriamente, así como las claves para el cifrado y protección de la

integridad de la señalización IMS, las cuales utilizara para generar el registro.

Por último, el usuario, en base al mensaje recibido comprueba la identidad

de la red IMS y genera un nuevo mensaje SIP REGISTER. Este segundo

mensaje contiene una respuesta formada a partir del algoritmo de autenticación

IMS AKA.

Cuando el mensaje llega al S-CSCF, el usuario es finalmente registrado

después de comprobar la veracidad de su identidad. Posteriormente, el S-CSCF

78

indica al HSS que aquel ha registrado al abonado satisfactoriamente y descarga

desde allí la suscripción IMS del usuario. El proceso finaliza con el asentimiento

SIP 200 OK enviado hacia el terminal.

4.1.7 Servicios y aplicaciones

Uno de los requerimientos de IMS es soportar rápidamente nuevas

aplicaciones y servicios IP. La OMA, Open Mobile Alliance (Alianza de

Estándares Abiertos en Telefonía Móvil) está definiendo diversas estructuras de

servicios y aplicaciones interoperables.

Para ello, trabaja en conjunto con 3GPP e IETF. Entre los servicios

desarrollados por OMA de acuerdo a los estándares 3G, se encuentran: “Push to

Talk”, es decir, apretando un botón para transmitir y liberándolo para recibir. Este

tipo de comunicación permite llamadas de tipo uno-a-uno o bien uno-a-varios

(llamadas de grupos), mensajería instantánea y “Presence Service”, es decir,

dentro de una red móvil verificar estado de presencia de un usuario con relación

a su terminal telefónico: 'Ocupado', 'Libre' o 'No alcanzable'. También con

relación a una presencia lógica, como es el caso del Messenger de Microsoft

cuando seleccionamos 'No disponible', 'Vuelvo enseguida' o 'Ausente'.

IMS ofrece una estructura escalable para el desarrollo de nuevas

aplicaciones y servicios. Primero, adopta servicios basados en IP, que son

sencillos de incorporar como servicios multimedia IP. Segundo, IMS se focaliza

en la señalización de servicios multimedia IP usando SIP. Tercero, solo se

especifican las capacidades y atributos de los servicios. Proveedores de

servicios pueden entregar servicios mejorados rápidamente sin espera de una

estandarización.

Diferentes servicios accedidos por distintos tipos de usuarios pueden

significar nuevos y variados requerimientos y características. Se espera que IMS

79

sea la base de los futuros servicios multimedia IP. Para ello la colaboración entre

estándares de comunicación vía celular y de Internet es esencial.

4.2 MODO PEERING Y ACCESS

Estos dos conceptos se introducen para tener un mayor entendimiento de

los tipos de redes que implementen y evalúen en laboratorio con el objetivo

principal de integración de tecnología para servicios VoIP / Datos / Multimedia /

Control.

4.2.1 Modo “peering”

En primer lugar un escenario “peering” típico es cuando participan dos

operadores de red que intercambian tráfico entre sí. Un ejemplo sería el

escenario de interconexión que se ilustra en la figura 4-3. Un “Gateway” de

origen (GW-A1) en el operador A de la red envía un INVITE que se dirige al

operador de SBC en el operador B de la red. Entonces el SBC envía el INVITE al

softswitch (SS-B).

VVVV VVVV

VVVV VVVV

(3) 3xx redir.

Figura 4-3: Diagrama de ejemplo para modo “Peering”

80

En una segunda etapa del proceso, el “softswitch” responde con una

redirección (3xx) mensaje de nuevo al SBC que apunta al Gateway terminal

adecuado (GW-B1) en el operador de red de B. Si el operador B no tuviera un

SBC, el mensaje de redirección iría al “Gateway” procedente del operador "A".

Después de recibir el mensaje de redirección, el SBC envía la invitación al

“Gateway” finalmente [3].

Desde la perspectiva del SBC es el operador A la red exterior, y el

operador B es la red interna. El operador B puede utilizar el SBC, por ejemplo,

para controlar el acceso a su red, proteger sus puertas y conmutadores de

software de uso no autorizado y ataques de denegación de servicio (DoS),

supervisar la señalización y el tráfico de los medios de comunicación. También

simplifica la gestión de la red, reduciendo al mínimo el número de ACL (“Access

Control List”) en la entrada del “Gateway”. Los “Gateway” ya no deben estar

expuestos a la red de otros pares, y pueden restringir el acceso (tanto los medios

de comunicación y señalización) al SBC. El SBC ayuda a garantizar que sólo los

medios de comunicación de sesiones autorizadas en el SBC lleguen a la puerta

de enlace [3].

Como definición más ortodoxa se tiene que el concepto de “peering” es la

interconexión voluntaria entre dos redes en Internet administrativamente

independientes, con el propósito de intercambiar tráfico entre usuarios de cada

una de las redes. La definición estricta significa "libre acuerdo" o "el remitente se

hace cargo", esto es, ninguna de las partes paga a la otra por el intercambio de

tráfico, sino que cada una deriva el crédito de sus propios clientes. La

comercialización y las presiones comerciales han llevado al uso rutinario de esta

palabra toda vez que hay un cierto acuerdo implicado, aunque no se trata de su

sentido técnico exacto. La frase “peering de libre acuerdo” se utiliza a veces para

reflejar esta realidad y para describir sin lugar a dudas que se trata de un

intercambio de información sin costo. El “peering” requiere la interconexión física

81

de las redes, un intercambio de la información de encaminamiento con el

protocolo de encaminamiento del Border Gateway Protocol (BGP) y, a menudo,

va acompañado por acuerdos que implican diversa formalidad que varía, del

simple “handshake” a conexiones más complejas. Así existen 2 tipos de

“peering”, público y privado.

4.2.1.1 “Peering” público

El “peering” público se logra a través de una tecnología de acceso de la

capa 2, generalmente llamada una tela compartida. En estas localizaciones,

interconexión múltiple de los portadores con unos o más portadores a través de

un solo puerto físico. Las localizaciones que miraban con fijeza públicas eran

conocidas históricamente como puntos de acceso de red (NAPs por sus siglas

en inglés), éstas son hoy Puntos de intercambio, o más comúnmente llamados

Puntos de Intercambio de Internet (“IXP” o “IX”). Muchos de los puntos más

grandes de intercambio del mundo pueden tener centenares de participantes, y

algunos abarcan múltiples edificios e instalaciones localizadas a través de una

ciudad [3].

Puesto que el "Peering" público permite a las redes interesadas

interconectarse con muchas otras redes a través de un solo puerto, se considera

a menudo ofrecer “menos capacidad” que un “peering” privado, pero a un

número más grande de redes.

Algunos “exchanges points”, particularmente en los Estados Unidos, son

proveídos por terceros (portadores neutrales comerciales). Estos operadores van

típicamente a las grandes longitudes a promover la comunicación.

82

4.2.1.2 “Peering” privado

Por otra parte un escenario “access” es la interconexión directa entre dos

redes solamente, a través de medios de la capa 1 o 2 que ofrece la capacidad

dedicada que no es compartida por ningún tercero. En el comienzo de la historia

del Internet, muchos “peering” privados ocurrieron a través de “telco” proveyendo

los circuitos de SONET entre las instalaciones individuales “carrier”-propietario.

Hoy, la mayoría de las interconexiones privadas ocurren en los denominados

“carrier hotel” (tipo de data center) o “carrier” neutral, donde un

“direct/crossconnect” puede estar proveyendo entre los participantes dentro del

mismo edificio, generalmente por un costo mucho más bajo que una Telco. La

mayor parte del tráfico en el Internet, especialmente tráfico entre las redes más

grandes, ocurre vía “peering” privado. Sin embargo, debido a los recursos

necesarios para la prestación de cada “peering” privado, muchas redes no están

dispuestos a proporcionar interconexión privada a "pequeñas" redes, o a

"nuevas" redes, que aún no han demostrado que proporcionarán un beneficio

mutuo [3].

4.2.2 Modo “Access”

En un escenario de acceso, presentado en la figura 4-4, el SBC se coloca

en la frontera entre la red de acceso (red exterior) y la red del operador (red

interna) para controlar el acceso a la red del operador, proteger sus equipos

(servidores de medios, servidores de aplicaciones, pasarelas, entre otros),

restringir el acceso no autorizado, los ataques DoS, supervisar la señalización y

el tráfico de los medios de comunicación. Además, como el SBC es un evaluador

de llamadas, puede ofrecer funciones de control de acceso para evitar sobre-

suscripción de los enlaces de acceso. Los extremos están configurados con el

SBC como su dirección de proxy de salida. El SBC enruta peticiones a uno o

más proxies en la red del operador [3].

83

Figura 4-4: Diagrama de ejemplo para modo Access

El SBC puede ser configurado en la red de acceso (esto es común cuando

el acceso a la red es una red de la empresa), o en la red de operador (esto es

común cuando la red de acceso es un residencial o una pequeña red de

empresa). A pesar desde donde el SBC se configura, siempre es administrado

por la organización de mantenimiento de la red del operador.

Algunos “endpoints” pueden estar detrás de NATs de empresa o

residencial. En los casos en que la red de acceso es una red privada, el SBC es

un NAT para todo el tráfico. Cabe señalar que el tráfico de SIP puede tener que

recorrer más de un NAT. El proxy usualmente realiza autenticación y/o

autorización de registro y llamadas de salida. El SBC modifica la petición

REGISTER de modo que las solicitudes posteriores a la dirección registrada de

récord se enrutan a la SBC. Esto se hace con un campo de “path” de la

cabecera, o modificando el punto de contacto en el SBC.

El escenario presentado en esta sección es de carácter general, y se

aplica también a otros entornos similares. Un ejemplo de una situación similar es

en la que una red de acceso es Internet abierto, y el operador de red es la red de

un proveedor de servicios SIP.

84

4.3 INTEROPERABILIDAD E INTER-FUNCIONAMIENTO

Estos dos conceptos básicamente aplican bajo una idea aún más fuerte,

la cual es la integración de sistemas. Suelen confundirse como si se trataran de

lo mismo, pero no lo es, aunque como ya se dijo estas ideas apuntan a lo mismo

en las redes.

Cuando se habla de interoperabilidad, se refiere a las funciones

protocolares de un sistema interconectado. Se realiza una integración de

servicios aplicadas en varias redes, dando la forma de una sola red.

Al Hablar de inter-funcionamiento, la integración se trata desde el punto

de vista de la red, los equipos, las interfaces, ancho de banda, “jitter”, módulos

de los equipos, entre otros. Todo ello debe tener una compatibilidad certera para

el desarrollo de servicios.

4.3.1 Concentración de tráfico

Dentro de la integración de sistemas, y más especifico en la

interoperabilidad de redes, se encuentra una de la mayores razones de elegir la

tecnología VoIP por sobre otras, es la cantidad de tipos de tráficos que se

pueden compatibilizar gracias a los esfuerzos de estandarización por parte de la

UIT e IETF. Es así como prácticamente todo tipo de tráfico es compatible entre

sí.

Para los equipos SBC esto no es ajeno, éstos pueden concentrar data,

voz, video, señalización, control, administración, registros, seguridad, pero al

mismo tiempo mantenerlos separados para no causar algún tipo de problema de

latencia, vulnerabilidad, incompatibilidad, disponibilidad.

Por último queda como algo concluyente, la facilidad con que se logra la

unificación de tráfico, gracias a la fiscalización de instituciones dedicadas al

85

tema, aunque claramente el ámbito de las comunicaciones es propicio para

lograr tareas de esta envergadura.

4.3.2 Convergencia de servicios

A diferencia del tráfico, los servicios son una idea más acabada de lo que

es un producto de red, ya perceptible por el usuario final. Por otra parte los

servicios generalmente son combinaciones de tráficos, o sea, los servicios

mejoran a medida que los tráficos son cada vez más unificados, entonces estos

se convierten en su materia prima.

Ejemplos típicos de convergencia de servicios se ven a diario, como los

planes actuales de telefónica celular integrando circuitos de voz a circuitos de

datos por un mismo canal, esto es mensajería instantánea, o también envió de

data a través de canales de CATV. Estos ejemplo son relativamente comunes en

la vida de las persona, lo que se está llevando a cabo para mejora la

convergencia de servicios, es agregar de manera integral el concepto de

movilidad, por ello todos los esfuerzos tanto en tráfico como en servicio en el

tema de ALL-IP.

4.3.3 “Translation”

En el capítulo 2, se trató el tema de los distintos tipos de protocolos de

señalización, sus características, ventajas y debilidades. Ahora la relación con el

concepto tratado, es la capacidad que tienen estos protocolos de inter-operar

entre ellos, de modo que logren compatibilidad, baja latencia, QoS, seguridad,

entre otros.

Gracias a este concepto es porque pueden coexistir las ITSP con las

PSTN, traduciendo protocolos como a SIP, H.323, MEGACO a SS7. Por otro

lado también logra la coexistencia entre los mismos protocolos de señalización.

86

El “Translation” para verlo de una manera más notoria, el discado

números telefónicos es distinta del lado ITSP al lado PSTN, de hecho las reglas

de marcado en telefonía IP son de mucha más flexibilidad que en PSTN

4.3.4 “Transcoding”

Una vez realizada la compatibilización de señalización, se encuentra

incompatibilidad entre códigos de transporte de la Voz. Una vez más todo lo

relacionado con respecto al “Transcoding” está completamente estandarizado.

La solución de “Transcoding” es mucho más fuerte en cuanto a cualidades

presentadas que el “Translation”, ya que la cantidad de “codecs” VoIP es mucho

mayor, por lo tanto es más complicada la estandarización, por lo que el

diseñador de la red debe tener en cuenta este factor en aspecto de

implementación.

4.4 ALTA DISPONIBILIDAD

Las soluciones de alta disponibilidad de las redes de VoIP abordan la

necesidad de que los usuarios puedan hacer y recibir llamadas en los horarios

de llamadas de máxima carga o durante el mantenimiento del dispositivo o por

alguna falla que presente. Además de la pérdida de productividad, tiempo de

inactividad de la red de voz a menudo resulta en pérdida de ingresos, clientes

descontentos, e incluso una posición en el mercado debilitado. Distintas

situaciones pueden tener dispositivos fuera de línea, que van desde el tiempo de

inactividad previsto para el mantenimiento hasta una falla catastrófica.

La alta disponibilidad no es una tecnología específica, sino una meta que

se basa en necesidades empresariales específicas. La complejidad de una

87

solución de alta disponibilidad está determinada por las necesidades de

disponibilidad de la empresa y por la cantidad de interrupciones del sistema que

puede ser tolerado por la empresa. Las soluciones de alta disponibilidad para

mejorar el servicio de la red VoIP, reducir los costos asociados con el tiempo de

inactividad mediante la prevención de apagones, y reducir el impacto de las

interrupciones cuando se produzcan. Hay dos elementos clave que contribuyen a

la disponibilidad en una red de VoIP: La capacidad y la redundancia. En estos

conceptos se debe profundizar ahora.

4.4.1 Capacidad

La capacidad es una medida del volumen de tráfico con la que se ha

diseñado una red a administrar. Las redes de voz son típicamente diseñadas

para una capacidad de carga máxima de destino, normalmente se mide en las

llamadas por segundo. Los objetivos de la capacidad de carga máxima son

específicos de cada negocio e industria, y se basará en la tasa de horas

ocupadas en llamadas. Por ejemplo, el tráfico durante la hora más ocupada en el

Día de la Madre puede ser la capacidad de carga máxima de destino para una

red de voz residencial.

4.4.2 Redundancia

Redundancia mide la capacidad adicional, que se usa sólo en el caso de

una falla en el equipamiento que se coloca en una red. Cuando un nodo principal

de una red de voz es bajado del sistema para mantenimiento o falla, un

dispositivo secundario superfluo puede hacerse cargo del procesamiento del

tráfico de voz.

88

4.4.3 Medición de capacidad y redundancia

Los ingenieros suelen usar la notación de n + k para describir la capacidad

de ingeniería (n) y redundancia (k) de los nodos en una solución de

disponibilidad. Se considera una red que distribuye a través de 3 SIP “proxies”,

cada uno valorado con una capacidad individual de 100 llamadas por segundo.

Asumiendo que los “proxies” pueden actuar juntos en diversas combinaciones

lógicas, hay varias opciones de solución para la capacidad de ingeniería (n) y

redundancia (k).

Por ejemplo, cada “proxy” podría desplegarse en una configuración

independiente resultando en una capacidad total (n = 3 nodos “proxy”) de 300

llamadas, sin embargo no habría ninguna redundancia (k = 0) ya que si un proxy

falla no se ha hecho ningún arreglo para uno de los otros “proxies” para recoger

el tráfico.

Dado que la redundancia es crítica, es más probable que el grupo

ingeniado sea un arreglo n + k de “2 + 1” para una capacidad de 200 llamadas

por segundo, esto se muestra en la figura.

Figura 4-5: Diagrama de flujo sobre capacidad de redundancia

89

En este escenario, el apoyo a la carga ofrecida de 200 llamadas por

segundo sólo requiere 2 de los 3 “proxies” para procesar la llamada. El tercer

“proxy” está disponible para ocupar el tráfico (100 llamadas por segundo) en el

caso de que uno de los 2 servidores “proxies” primarios falla.

Un tercer escenario sería la de ingeniar la agrupación de los tres “proxies”

para soportar una demanda de carga de 100 llamadas por segundo. Este

escenario sólo se requiere un “proxy” para manejar la carga ofrecida de 100

llamadas por segundo, por lo que la cuota adicional de dos “proxies” está

adicionando la capacidad redundante en caso de un fallo. Esto se conoce como

la capacidad de ingeniería y redundancia n + k de “1 + 2”.

Cuando se diseña una solución de ingeniería en alta disponibilidad de una

red de voz, se debe determinar los requisitos de capacidad (n) primero, y luego

añadir más nodos redundantes (k) para lograr la disponibilidad deseada.

4.4.4 “Load Balancing”

La idea de esta función, es la sobrecarga estadística que tiene una ruta de

llamado con respecto a otra, ya sea en base al equipamiento que reside en cada

una de las rutas para el correcto funcionamiento del sistema VoIP o por la

demanda que está conectada a estas rutas que podría no estar soportada por

alguna de ellas.

“Load Balancing” se puede utilizar para obtener redundancia y balanceo

de carga activa. Puede ser configurado con una redundancia “1+1”, usando

VRRP para negociar la titularidad activa de la dirección IP virtual del nodo

redundante. “Load Balancing” se utiliza normalmente cuando los dispositivos

redundantes no soportan nativamente VRRP por sí mismos.

90

La inteligencia para distribuir la carga y la conmutación por error deben

ser alojadas en dispositivos de la red. Cuando una llamada se realiza a través de

un nodo de alta disponibilidad en la red, la tecnología “Load Balancing” y la

redundancia se pueden colocar tanto en los saltos anteriores como en los saltos

redundantes.

Entre un UA SIP y su salida en los “proxies” SIP, “DNS SRV” o su “backup

proxy”, la inteligencia puede ser establecida en un UA que llama o un par de

“Load Balancers” redundantes o la inteligencia “VRRP Daemon” (VRRPD) puede

ser colocado en el proxy SIP. Con bajas tarifas de llamada (menos de 100

llamadas por segundo), la inteligencia VRRPD puesta en los proxies SIP es

preferible, debido bajos costos de implementación y flexibilidad para servir a los

extremos menos inteligentes, los “endpoints”.

4.5 LEAST COST ROUTING (LCR)

En las telecomunicaciones de voz, “Least Cost-Routing” (LCR) es el

proceso de selección de la ruta de tráfico de comunicaciones basado en el coste

de salida. Dentro de una compañía de telecomunicaciones, un equipo LCR

podría periódicamente (mensual, semanal e incluso diariamente) elegir entre

rutas de varios cientos de “carriers” o incluso por destinos en todo el mundo.

Esta función también podría ser automatizada mediante un dispositivo o

programa de software conocido como un “Least Cost Router”.

La idea de esta función, es mejora la disminución de costo por llamadas,

esto en base de dar rutas de costo-óptimo en relación a la compañía a la cual

pertenece. Todo esto reside en el SBC, usando información de Subtel, quien es

la entidad que designa bloques de numeración telefónica a las distintas

empresas telefónicas pertenecientes al PSTN en Chile. De esta manera se

aprovecha de dar esta información a RedVoiss, ruteando por un “Trunk” ciertos

91

números telefónicos pertenecientes a una compañía, y así con el resto de las

otras compañías.

4.5.1 Ciclo del Least Cost-Routing

El equipo LCR en una compañía podría seguir un ciclo de elección de

rutas, como se muestra en la figura 4-6:

Figura 4-6: Diagrama de flujo sobre ciclo de un proceso LCR

92

(1) Los compradores pueden negociar con sus proveedores y obtener una

lista de precios nuevos. (2) Los precios se cargan en el software para calcular y

comparar los costos de terminación. (3) Una ruta es elegida, Fijando el “cost-for-

pricing” (costo por fijación de precio), y los nuevos precios que vengan son

emitidos basados en el “cost-for-pricing” anterior. (4) Las nuevas rutas se aplican

en el switch y finalmente al volumen de tráfico y los márgenes son monitoreados

a través de informes del sistema de facturación (“Billing”). (5) Pérdida de toma de

tráfico y rutas irregulares son investigadas, y el sistema de facturación tiene su

datos o enrutamiento bien corregidos y la acción de fijación de precios se toma.

Los “carriers” firman acuerdos de interconexión con los demás

especificando los términos bajo los que realizan el negocio. Estos acuerdos

definen las condiciones de pago, métodos y procedimientos de solución ante

controversias, y el medio por el cual las compañías se informarán además de los

cambios de precios. El estándar de la industria se encuentra actualmente

estipulado con plazos de aviso de siete días para los aumentos de precios,

mientras que cuando el precio se reduce, se notifica el mismo día. Debido a que

los márgenes en el mercado del operador de “carrier” son extremadamente

pequeños, re-enrutar debido a aumentos de precios deben tomarse rápidamente

a un destino donde la ruta actual se va a aumentar de precio. Dado que el

aumento de precios en sí da un preaviso de siete días, que deberá emitirse

dentro de veinticuatro horas del incremento del coste para evitar pérdidas. Esto

puede ejercer una presión considerable en el equipo LCR de un “carrier”, que

debe procesar las ofertas de sus proveedores con rapidez y precisión.

4.5.2 Impacto de la Portabilidad Numérica Móvil en ambiente LCR de VOIP

La portabilidad numérica móvil afecta a las empresas de telefonía por

Internet, y “Least Cost-Routing”. La portabilidad numérica móvil es un servicio

que permite a los abonados conservar su número de teléfono móvil al cambiar

93

de proveedor de servicios (o el operador de telefonía móvil). Con la portabilidad

del número actualmente en auge en muchos países, los proveedores de LCR ya

no pueden basarse en el uso de sólo una parte del número de teléfono a marcar

para enrutar una llamada. En cambio, ahora se debe descubrir la actual red de

todos los números antes de enrutar la llamada. Por lo tanto, las soluciones de

LCR también tienen la necesidad de manejar MNP (“Movility Number Portability”)

al enrutar una llamada de voz. En países sin una base de datos central como

Reino Unido, podría ser necesario consultar en la red GSM sobre la red casera o

número de teléfono móvil a la que pertenece.

MNP realiza verificaciones importante para asegurar que la calidad de

servicio se cumpla; por manejo MNP se buscan antes enrutamiento para una

llamada y así asegurar que la llamada de voz realmente funcione, las compañías

de VoIP ofrecer a las empresas la fiabilidad necesaria que buscan en un

proveedor de telefonía por Internet.

En países como Singapur, uno de los países más recientes en

implementar NMP, se espera que abra las puertas a nuevas oportunidades de

negocio para proveedores de servicios no tradicionales de telecomunicaciones

como proveedores de banda ancha inalámbrica y de proveedores VoIP

En noviembre de 2008 la FCC de los Estados Unidos (Federal

Communications Commission) emitió una orden de ampliar las obligaciones de

portabilidad numérica a los proveedores de VoIP interconectado y las compañías

que apoyan a los proveedores de VoIP.

4.6 BILLING

Es una base de datos inserta en los “Session border controller”, para

realizar la función de facturización a pequeñas empresas, seguimientos de

problemas de facturización de servicios, eventuales utilizaciones no autorizadas

de los servicios pertinentes en la máquina SBC.

94

De acuerdo a la investigación desarrollada por el proyectista, sobre

equipos SBC en el capítulo 3, estos no pueden almacenar grandes cantidades

de información (no todos). Por ello existen 2 métodos para el traspaso de base

de datos a otros equipos con mejores prestaciones para ello. Estas son levantar

un servidor FTP, o levantar un servidor RADIUS. También se deben tener claros

los siguientes conceptos, presentados a continuación.

4.6.1 “Call Detail Records” (CDRs)

Un “Call Detail Record” (también conocido como registro de datos de

llamadas - CDR) es el registro informático producido por una central telefónica

con los detalles de una llamada que pasa a través de él. Es el equivalente

automatizado de tickets que fueron escritos en su momento por los operadores

para llamadas de larga distancia en una central telefónica manual.

Un CDR está compuesto por campos que describen el intercambio.

Algunos ejemplos de campos incluyen:

• El número que hace la llamada (el que llama).

• El número que recibe la llamada (abonado llamado).

• Cuando se inició la llamada (fecha y hora).

• Termino de la llamada (duración).

• El número de cargos por la llamada.

• El identificador del registro de intercambio telefónico.

• Un número de secuencia que identifica el registro.

• Dígitos adicionales en el número llamado, que utiliza para enrutar o cargar

la llamada.

• El resultado de la llamada (si fue respondida, ocupado, no existe, entre

otros).

• La ruta por la que la llamada entró en el intercambio.

• La ruta por la que la llamada dejo el intercambio.

95

• Tipo de llamada (voz, SMS, entre otros).

• Cualquier condición de falla encontrada.

Cada fabricante decide qué información de cambio se emite en las

entradas y cómo está configurada. Ejemplos:

• Enviar la fecha y hora del fin de la llamada en lugar de duración.

• Máquinas de sólo voz no puede enviar el tipo de llamada.

• Algunas PBX pequeñas no envían el interlocutor de la llamada.

4.6.2 Call Accounting

Un sistema de “Call Accounting” es un software o aplicación de hardware

que captura, registros, y los costos de los eventos de uso telefónico. A nivel

internacional, los sistemas de “Call Accounting” pueden ser referidos a un

sistema de registro de llamados. Los sistemas de “Call Accounting” detectan

llamadas entrantes y salientes, llamadas sin contestar, rutas de llamadas,

llamadas abandonadas, y otras actividades.

4.7 VIRTUALIZACIÓN

La virtualización de redes proporciona una forma poderosa de

implementar múltiples escenarios, cada una personalizada para un propósito

específico, al mismo tiempo, y sobre un plano común. La investigación en

virtualización de la red se centra en dos escenarios principales. En primer lugar,

se considera su papel en la gestión de múltiples experimentos de forma

simultánea en una instalación compartida, un laboratorio. Por ejemplo, la

iniciativa de NSF (National Science Foundation) y “GENI” (“Global Environment

for Network Innovations”) se centra en el diseño e implantación de una

96

instalación compartida, amplia área experimental para apoyar una gran gama de

investigaciones en la creación de redes y sistemas distribuidos. El proyecto

“VINI” es un paso en esa dirección, la experimentación con las nuevas rutas de

apoyo, reenvío y esquemas de direccionamiento en una instalación compartida,

construida con el propósito general de mejorar los procesos de red. En segundo

lugar, se considera que el papel de la virtualización es para el apoyo de múltiples

arquitecturas, y al mismo tiempo como una solución a largo plazo, para el futuro

de Internet. El proyecto “Cabo” explora las ventajas de ejecutar arquitecturas

personalizadas, así como la forma de un sistema virtualizado permite una

refactorización económica de un futuro de Internet en los proveedores de

infraestructura (que poseen y operan el equipo) y proveedores de servicios (que

arriendan componentes virtuales y ofrecen de servicios de “fin a fin” a los

usuarios). Los tres proyectos lidian con los retos técnicos de ofrecer un plano

virtualizado y programable que funcione a alta velocidad, el proyecto Cabo debe

abordar los nuevos retos de la construcción de un plano que pueda funcionar sin

ningún tipo de dependencia existente en Internet.

La virtualización permite que múltiples redes, cada una para un fin

determinado distinto, en forma concurrente coexistan sobre un sustrato común.

Uno de estos modelos para la gestión de estas redes virtuales es la creación de

una plataforma de “hosting” donde las empresas pueden desplegar servicios de

arriendo por parte de varios “routers” físicos. Al mismo tiempo, baja la barrera

para la innovación en la red, pero este modelo introduce nuevos problemas de

seguridad. En este trabajo el proyectista examina el cuestinamiento de la

responsabilidad en el establecimiento de servicios de redes virtuales alojadas.

Es decir, cómo un proveedor de servicios, puede conocer su software que se

ejecuta sin modificar el sistema que ya está establecido, y de que “router”

físicamente del proveedor de infraestructura, viene el reenvío de paquetes, como

se indica con la calidad del servicio prometido. En lugar de presentar una

especificación única de lo que cada “router” en Internet debe tener

implementado, en este trabajo se pretende dar dos enfoques posibles: uno que

97

detecta violaciones de la vigilancia del servicio y que evita que se produzca

violaciones en primer lugar. Para cada uno, se ofrece una descripción de

arquitectura que se puede lograr con la tecnología disponible hoy en día, las

limitaciones de esta arquitectura, y la posterior propuesta de una extensión que

supera las limitaciones.

A pesar de que se ve muy prometedor y ser más ampliamente utilizado

hoy en día, las redes virtuales se encuentran todavía en una fase temprana de

desarrollo. Las personas que constantemente encuentran nuevas formas de

conectarse con las comunidades, conjuntamente refunden su forma de pensar y

desarrollar soluciones sorprendentes a problemas complejos.

CAPÍTULO 5

PLANIFICACIÓN E IMPLEMENTACIÓN DE SERVICIOS

5.1 OBJETIVOS DE SERVICIOS EN PRUEBA

A través de la recabación de datos realizada como primera parte del

proyecto, se toman como objetivos técnicos específicos lograr los siguientes

puntos:

• Solución base de “Troncal SIP” interconectado a un Troncal PSTN, por

medio de un carrier VoIP proporcionado por RedVoiss, empresa

profesional dedicada al tema.

• Solución avanzada para empresas que ya poseen una estructura

telefónica IP, y desean una mejora de servicios, estar a la vanguardia, o

disminuir aún más sus costos gracias a SIP-Trunk.

• Solución experimental que da la existencia a costos diferenciales

variables desde origen o destino, este es uno de los fines en los equipos

SBC, la cual resulta una gran ventaja con respecto a la red pública

conmutada de telefonía.

• Solución virtualizada para empresas jerárquicas o fusionadas, que desean

mantener ciertas políticas en materia de costos comunicacionales.

5.2 DIAGRAMA ESTRUCTURAL EN CUMPLIMIENTO A SERVICIOS PROPUESTOS

Como una forma de mostrar de forma más tangible las estructuras típicas

representadas en sistemas telefónicos IP integrados, es que el punto de vista a

explicar será desde su ambiente nativo, “Internet”, así expuesto en la figura 5-1.

99

Los elementos básicos de un sistema Integrado basado en redes es siempre una

red privada (LAN), un nexo a la Internet (Red pública de datos), un “Router”,

“Firewall”, o cualquier tipo de control dependiendo de la red LAN que se

construya y la seguridad que necesite. Por último el proveedor de acceso y

servicios (WAN), el cual arrienda sus instalaciones para lograr la extensión

necesitada hacia los servidores donde se encuentra la información o servicio

externo deseado.

En el caso de servicios de Telefonía IP integrados, el orden es el mismo,

con salvedad en las estructuras interiores, pero a la vista de alguien externo se

ve idéntico a una red de datos, cumpliendo con un cometido de privacidad y

seguridad, todo gracias al concepto de dualidad y separación de

datos/señalización y servicios/”media”.

Figura 5-1: Diagrama estructural de servicios

100

5.3 ALCANCES DEL TRABAJO EN LABORATORIO

De acuerdo a los servicios propuestos para implementar, la cantidad de

equipos a necesitar no deja de ser menor, pero a nivel empresarial es posible de

solventar, aún así se logra realizar una gran cantidad de soluciones

correctamente implementadas, logrando ya un significativo avance de eficiencia

estructural en este tipo de sistemas.

• Interoperabilidad: Ligada completamente a la compatibilidad entre

software y protocolos con distintas proyecciones, se da uso a los

principales algoritmos de señalización y “media”, siendo el caso de:

o H.323

o SIP

o SCCP

o SIP-Trunk

o SIGTRAN

o SS7

Incluyendo por supuesto, a protocolos de conectividad como IEEE 802.1Q

• Inter-funcionamiento: Centrado en el hardware del sistema, esta etapa

relaciona los distintos equipos con sus funciones, mostrando el

desempeño final del conjunto. Dentro los usados para la demostración

implementada están:

o 2 equipos SBC, uno usado como nodo de borde y otro siendo una

PBX externa.

o Un Switch central, uniendo todas las Vlan’s

o Un Servidor Firewall, para el acceso

o 1 Servidor Virtual, conteniendo 2 CCM (4.x y 6.x)

o Softphone y Cellphone

• Virtualización: Concepto muy generalizado que involucra varias

implementaciones, con la finalidad de entregar mayor cantidad de

101

servicios de forma diferencial, en otras palabras, lograr desde filtrar y

controlar los servicios en el lado del cliente hasta brindar gran cantidad de

tipos de servicios ocupando la menor cantidad de equipamiento en el lado

del proveedor. En esta implementación se toma con importancia los

siguientes formatos:

o CCM 4.x, CCM 6.x

o PBX SIP-Trunk Asterisk

o Interfaces y servicios SBC en modo Virtualizado

• Telefonía Dual: Etapa de implementación más cercana al usuario, además

de ser la etapa más rápida de configuración, es el método más eficaz al

momento de realizar pruebas de primera necesidad, entre ellos tenemos:

o Softphone

o Cellphone

o Smartphone con y sin cliente SIP

o Teléfonos IP Cisco

5.4 LABORATORIO

Como primera medida dentro de la segunda instancia del proyecto, es el

reconocer las herramientas en el objetivo de la implementación. Este apartado,

contempla 3 conjuntos, equipamiento físico, herramientas informáticas, y

diagrama de interconexión.

5.4.1 Equipamiento Físico

El desarrollo de laboratorio en cuestión no está completamente

desarrollado por el proyectista, este es un esfuerzo de continuidad de varios

ingenieros y memoristas con el objetivo de generar vanguardia dentro de las

empresas dedicadas al rubro. De cualquier forma es trabajo del proyectista el

102

comprender a la perfección su forma de operar, es así como se da paso a una

descripción del funcionamiento.

El equipo que da vida al laboratorio de telefonía IP es un servidor basado

en Linux Fedora release 7 (Moonshine), bautizado con el nombre de “RAMIEL”,

encargado desde el manejo de VLAN, “Gateways”, “firewall”, hasta accesos

remotos de configuración, como VPN, accesos SSH2, telnet, y todo tipo de

tráfico hacia la red WAN pasa por él. 2 “Switches” encargados de separar por

VLANs las distintas experiencias, simulaciones de fallas, y demostraciones

realizadas. Un servidor HP Storage con prestaciones de Virtualización de

sistemas operativos, bautizado con el nombre de “CAIN”, conteniendo los “Cisco

Call Manager” 4.x y 6.x, dando el respaldo necesario como base de datos

telefónica en cuanto a codificación, caminos o rutas telefónicas, reglas de

translación numérica para la PSTN, protocolos de señalización y registro de

nexos, ya sean físicos o por software. Un servidor Linux Fedora release 10

(Cambridge), bautizado con el nombre de “URIEL” con prestaciones Asterisk,

para experimentar soluciones alternativas o comprobaciones más profundas en

cuanto al comportamiento de los sistemas de Telefonía IP. 3 marcas de equipos

SBC, Acme Packet(modelos 3800 y 4250), InGate (modelo SIParator 19), y

Cisco (modelo UC 500 series), estos son rotativos en el laboratorio, esto

depende de lo que se desea realizar en una demostración, para el caso de este

proyecto son el componente medular en estudio y análisis. Por último equipos

telefónicos o “end-point” Cisco, estos no se ocupan en esta etapa de proyecto,

pero se tienen pretensiones de hacerlo, a cambio de ellos se ocupan

“Softphones”, que serán explicados en el siguiente punto

5.4.2 Herramientas informáticas

Dentro de las aplicaciones necesarias y eficaces para empleo de

administración y desarrollo de pruebas se tiene:

103

• CLI (Command Line Interface): Su principal cometido es la configuración y

administración de equipos por distintos protocolos de acceso de

administrador, entre ellos están: telnet, SSH, SSH2, serial. Ejemplos de

ellos: Secure CRT, y Putty

• minicom: Aplicación Linux de administración remota por consola a equipos

con este tipo de interfaz.

• OpenVPN (Virtual Private Network): Software creado tanto para sistemas

operativos Windows como para Linux. Es un creador y administrador de

enlaces remotos seguros punto a punto a una red, necesario para el

operador que tiene equipos de su sistema en distintos puntos geográficos.

• Cisco VPN Client: Desarrollado por Cisco de forma propietaria, para un

mejor rendimiento en acceso remoto a sus equipos.

• IPtables: Aplicación Linux como firewall, muy importante al momento de

crear enlaces VPN

• Asterisk: Aplicación Linux que desarrolla una centralita PBX, ideal para

realizar pruebas de servicio VoIP

• Cisco IP communicator: Softphone desarrollado por Cisco, logra emular

un teléfono IP Cisco, con la gran salvedad que aporta cierta movilidad al

operador.

• Cisco Configuration Assistant (CCA): Software exclusivo para la Unified

Cisco (Ej.: UC 500 series), usado como interfaz gráfica de administración,

con un alto desempeño por facilitar las tareas al administrador de red.

• Wireshark: Excelente analizador de tráfico de red, abarcando la mayoría

de los protocolos usados para servicios integrados de red. Posee filtraje

de protocolos, herramientas exclusivas para trafico VoIP (gráfico de

señalización VoIP, gráficos para tráfico de voz).

• Winscp: Cliente SFTP gráfico para Windows que emplea SSH. Su función

principal es facilitar la transferencia segura de archivos entre dos sistemas

informáticos, el local y otro remoto que ofrezca servicios SSH.

104

• Conexión de escritorio remoto de Windows: Ideal para administrar equipos

con sistema operativo Windows de forma estándar y sencilla.

• VMware Workstation: Virtualizador de Sistema operativos completos

(interfaces, multimedia, red), facilita la necesidad de otro equipo PC para

el desarrollo de pruebas de terminal.

5.4.3 Diagrama de interconexión

Una vez conocidos los elementos y herramientas de red, se procede a la

descripción de relación en el sistema de implementación. En la figura 5-2 se

muestra el diagrama del laboratorio interconectado.

Figura 5-2: Diagrama de sistema físico, enlace de datos, y red del Laboratorio

105

Sistema está regido por VLANs, en el lado WAN obtienen su salida a un

Carrier SIP (RedVoiss) el cual realiza la interconexión con las tramas E1 de la

PSTN. En el lado LAN del laboratorio se tratan todos los equipos pensados en

una empresa que adquiere servicios telefónicos IP profesionales, asignando

VLANs internas para las interfaces de los equipos SBC y sus bases de datos

telefónicas resididas en los CCMs. Así también la configuración, administración y

pruebas se realizan a través de accesos VPN otorgados por el servidor

“RAMIEL”.

5.5 INTEROPERABILIDAD

Esta primera implementación cumple con 2 objetivos, cumplir con el

levantamiento estándar del laboratorio SBC y simular una falla real en un cliente

que adquiere un contrato demo con la empresa “Magenta”. El concepto de

interoperabilidad fue extensamente explicado en la etapa de recabación de

datos, en lo que se centra ahora esta implementación de interoperabilidad es ver

un completo manejo entre los protocolos H.323 [9] y SIP/SIP-Trunk, esto a nivel

crudo de señalización, y además verificar una activación del protocolo H.323

llamada “Media Termination Point” (MTP) [6] que provoca un comunicación de

“media” punto a punto completamente. El escenario de pruebas se muestra en la

figura 5-3. Para explicar la base de MTP, este tiene por función principal que

permitir la comunicación punto a punto entre terminales telefónicas IP, esto

significa que la “media” ya no se limita solo a ser controlada en el tramo inter-

“proxies”, en este caso entre el “Call Manager” y el SBC del proveedor, liberando

de esta forma recursos de los “proxies” en un ambiente de demanda, como lo es

SIP-Trunk.

106

Figura 5-3: Escenario de implementación de Interoperabilidad

A simple vista se entiende que es una implementación básica con

respecto a lo que puede entregar el laboratorio completo, lo que también da a

conocer que la implementación comercial de estos equipos, aún se encuentra en

una etapa inicial, lo que da mayor auge a la completación de implementaciones

experimentales para sacarlas al mercado. Se cuenta con un equipo SBC Acme

Packet 3800, un CCM 6.x por el lado “LAN” (CORE según Acme Packet),

siempre con el server “RAMIEL” para la administración y seguridad y acceso a

terminal de Softphone (Cisco IP communicator). Por el lado WAN (PEER según

Acme Packet) el carrier SIP-Trunk, interconectado a la PSTN, y un terminal

“Cellphone” [9].

107

5.6 INTER-FUNCIONAMIENTO

Esta implementación tiene como objetivo prevenir futuras

implementaciones en clientes que ya poseen algún tipo de tecnología en

telefonía IP, sea el caso de una Centralita IP Asterisk, o algún esquipo Gateway

VoIP Cisco como ejemplo el UC 500 Series [8]. Como un segundo objetivo se

toma el comprobar las capacidades propias de cada equipo por lograr

compatibilizar con el otro, en este caso entre el equipo UC 500 y el SBC Acme

Packet 3800. El escenario de pruebas se muestra en la figura 5-4.

Figura 5-4: Escenario de implementación de Inter-funcionamiento

108

5.7 VIRTUALIZACIÓN

Implementación de alta complejidad en definir. Al tratar este concepto, se

puede aplicar de distintas formas en todos los elementos del sistema, siguiendo

la definición de reutilizar una misma instancia de cualquier equipo para múltiples

propósitos de manera simultánea, sin verse afectados los servicios impuestos en

esta instancia del equipo en cuestión. Acotando este concepto a la

implementación, primero se trata el balance de carga como una manera de dar

rendimiento al ancho banda entregado por los proveedores, pensando en

sistemas con gran cantidad de tráfico de llamadas VoIP, y todo este tráfico debe

pasar por una sola interfaz WAN hacia los proveedores de servicios VoIP. Para

este propósito se fabrica un segundo camino habilitado con SIP-Trunk a través

del servidor Asterisk “URIEL”, Probar los distintos modos de balancear el ancho

de banda para un número determinado de llamadas simultáneas. Existe una

segunda implementación que cumple con características de virtualización, es el

denominado “Least Cost Routing”, es una de las implementaciones más

prometedoras como posible solución para bajar costos por llamada. La idea tras

esta implementación es filtrar las llamadas hacia la PSTN por un costo asociado

a la ruta escogida, por el horario en que se realiza la llamada, o por una cantidad

de números telefónicos específicos pertenecientes a la PSTN pertenecientes a la

empresa que recibe esta solución. Por último se realiza una implementación pura

de “Virtualización”, donde cada equipo tiene 2 rutas distintas usando la misma

interfaz física, ya sean Softphone’s, Call Manager’s, y SBC’s [6]. El escenario de

pruebas se muestra en la figura 5-5.

109

Figura 5-5: Escenario de implementación de Virtualización

CAPÍTULO 6

PLAN DE PRUEBAS Y RESULTADOS EN RED TELEFÓNICA IP

6.1 PRUEBAS DE CONECTIVIDAD

Como idea central de este apartado, es lograr esclarecer una operación

de “troubleshooting” (Solución de problemas) sólo de conectividad, en una forma

general a los distintos SBCs existentes.

• Paso 1: Probar conectividad (realizar “ping”) en el SBC, tanto en dirección

hacia la LAN como a la WAN.

• Paso 2: Si el “paso 1” resulta satisfactorio, no continuar. Revisar

configuración de VLANs si existen “switches” dentro de la red, Gateway

central al que apunta el SBC, configuraciones de rutas estáticas, de

interfaces físicas y de red en el SBC hasta estar completamente seguro

de ello, lo más probable es lograr por lo menos conectividad a la WAN, de

no ser así el proveedor de servicios tiene alguna falla.

• Paso 3: Verificar registro de datos en Teléfono IP o Softphone dentro del

Call Manager, esto es configurando el Teléfono con la IP del TFTP del

CCM, si no registra algún nexo revisar los dispositivos registrados en el

CCM, y en último caso registrar de manera manual la extensión con la

MAC de la interfaz del Teléfono a registrar.

• Paso 4: Revisar nuevamente conectividad de SBC tanto a LAN como a

WAN, y ver correcto registro de Teléfono en el CCM. Con esto revisado se

puede proceder a la revisión de la correcta señalización de servicios de

Telefonía IP.

En la figura 6-1 se encuentra un esquema representando el algoritmo que

pretende resolver problemas básicos de conectividad en el SBC.

Figura 6-1: Diagrama explicativo para resolver pruebas de conectividad,

orientado a SBC’s Acme Packet

6.2 PRUEBAS DE SEVICIOS DE TELEFONÍA I

De acuerdo a lo planteado en el capítulo de implementación, la

a realizar están orientadas a la correcta señalización de llamada, y correcto

establecimiento de “media”. Con lo anterior en mente es que el mejor método

para ello es la prueba de llamados desde un

PSTN. Siendo este el caso, a continuación se muestran diagramas

esclareciendo a que implementación se le realizan pruebas y

• Interoperabilidad: La orientación de las llamadas salientes y entrantes es

específicamente para analizar el comportamiento entre 2 protocolos con

distintas reglas de señalización, agregando la opción MTP para verificar la

correcta señalización en la interoperabilidad, ya que este es un factor

importante para una implementación comercial. Así el plan de pruebas se

divide en 2 etapas, mostradas en la figura 6

existencia o no de la opción MTP.

111

Diagrama explicativo para resolver pruebas de conectividad,

orientado a SBC’s Acme Packet

PRUEBAS DE SEVICIOS DE TELEFONÍA IP

De acuerdo a lo planteado en el capítulo de implementación, las pruebas

a realizar están orientadas a la correcta señalización de llamada, y correcto

. Con lo anterior en mente es que el mejor método

para ello es la prueba de llamados desde un “end-point” IP a un “end-point” de la

PSTN. Siendo este el caso, a continuación se muestran diagramas

esclareciendo a que implementación se le realizan pruebas y de qué forma.

Interoperabilidad: La orientación de las llamadas salientes y entrantes es

específicamente para analizar el comportamiento entre 2 protocolos con

distintas reglas de señalización, agregando la opción MTP para verificar la

n en la interoperabilidad, ya que este es un factor

importante para una implementación comercial. Así el plan de pruebas se

, mostradas en la figura 6-2 tomando como referencia la

existencia o no de la opción MTP.

111

pruebas

a realizar están orientadas a la correcta señalización de llamada, y correcto

. Con lo anterior en mente es que el mejor método

de la

PSTN. Siendo este el caso, a continuación se muestran diagramas

Interoperabilidad: La orientación de las llamadas salientes y entrantes es

específicamente para analizar el comportamiento entre 2 protocolos con

distintas reglas de señalización, agregando la opción MTP para verificar la

n en la interoperabilidad, ya que este es un factor

importante para una implementación comercial. Así el plan de pruebas se

tomando como referencia la

Figura 6-2: Diagrama d

• Inter-funcionamiento: El plan de pruebas

referencia a llamadas entrantes y salientes entre:

o PBX Cisco (UC 500) externa y SBC Acme Packet 3800

o PBX Cisco (UC 500) externa y la PSTN a través del

Packet 3800 como SIP

servicios de telefonía IP basado en señalización SIP.

Figura 6-3: Diagrama de pruebas para inter

Acme Packet

HACIA PSTN, desde PBX y

SBC

Llamadas Entrantes

Llamadas Salientes

112

Diagrama de pruebas para interoperabilidad

funcionamiento: El plan de pruebas, mostrado en la figura 6-3,

referencia a llamadas entrantes y salientes entre:

PBX Cisco (UC 500) externa y SBC Acme Packet 3800

PBX Cisco (UC 500) externa y la PSTN a través del SBC Acme

Packet 3800 como SIP-trunk designado por el proveedor de

servicios de telefonía IP basado en señalización SIP.

Diagrama de pruebas para inter-funcionamiento

Packet ��UC500

Llamadas Salientes

HACIA PBX SIP-Trunk, y SBC

Llamadas Entrantes

Llamadas Salientes

112

da

SBC Acme

trunk designado por el proveedor de

• Virtualización: Consta de varias pruebas simultá

considerando las 2 rutas SIP

o Pruebas de Horario, Costo,

separado, con elección a alguna de las 2 rutas (

Routing”).

o Pruebas de Horario, Costo,

conjunto, con elección a alguna de las 2 rutas (

Routing”).

o Pruebas de carga de ancho de banda en

llamadas simultáneas, en modo

ruta alternadamente entre las opciones)

Balancing).

o Pruebas de Horario, Costo, Pattern de números discados en

conjunto para dos rutas internas virtualizadas y con limitación de

rutas (Virtualización completa).

Figura 6-4: Diagrama de pruebas para Virtualización

113

Consta de varias pruebas simultáneas, siempre

o las 2 rutas SIP-Trunk para llamadas entrantes y salientes.

Pruebas de Horario, Costo, “Pattern” de números discados por

separado, con elección a alguna de las 2 rutas (“Least Cost

Pruebas de Horario, Costo, “Pattern” de números discados en

conjunto, con elección a alguna de las 2 rutas (“Least Cost

Pruebas de carga de ancho de banda en “media” para varias

llamadas simultáneas, en modo “Round-Robin” (llamada elegirá la

ruta alternadamente entre las opciones) para Acme Packet (Load

Pruebas de Horario, Costo, Pattern de números discados en

conjunto para dos rutas internas virtualizadas y con limitación de

rutas (Virtualización completa).

Diagrama de pruebas para Virtualización

113

neas, siempre

Trunk para llamadas entrantes y salientes.

de números discados por

Least Cost

de números discados en

Least Cost

para varias

” (llamada elegirá la

para Acme Packet (Load

Pruebas de Horario, Costo, Pattern de números discados en

conjunto para dos rutas internas virtualizadas y con limitación de

114

6.3 RESULTADOS DE PRUEBAS DE SERVICIOS DE TELEFONÍA IP

La entrega de resultados de pruebas, de acuerdo a la planificación se

desarrollo en base a posibles soluciones de mejora de servicios telefónicos IP

utilizando el potencial de los SBC’s. Se procede a la entrega de los resultados en

las categorías planificadas.

• Resultado de interoperabilidad: Se logra una correcta señalización entre

los canales H.323 y SIP-Trunk, ya sea con modo MTP o sin él, se muestra

de forma gráfica en las figura 6-5 y 6-6, dónde y cómo funcionan los

protocolos. En cuanto a la realización de la “media” (RTP/G.711u),

también es correcta. Se logra gran calidad de audio aún siendo un códec

más básico que G.729, esto con la idea de estandarizar todo a un códec

que se tiene en prácticamente todos los equipos de telefonía IP.

Figura 6-5: Diagrama de resultados para Interoperabilidad

H.3

23S

IP

C/M

TP

RTP

S/M

TP

RT

P

115

Figura 6-6: Diagrama de resultados de señalización para Interoperabilidad

• Resultado de inter-funcionamiento: Con algunas dificultades de

compatibilidad en cuanto a MTU de paquetes de señalización SIP

presentadas por parte de UC 500 Cisco, y solucionada por adaptación de

MTU presentada como opción en Acme Packet 3800. Se logra correcta

señalización (mostrada en la figura 6-7), desde y hacia UC 500 Series

(flechas verde y azul), y entre UC 500 Series y Acme Packet 3800 (flecha

roja) [8]

116

Figura 6-7: Diagrama de resultados para Inter-funcionamiento

• Resultado de Virtualización completa: Se logra separar dos líneas de

rutas con sus respectivas reglas de enrutamiento, numeración de discado

y extensiones, mostrado en la figura 6-8. Se consigue la limitación para

una línea de ruta si afectar en nada a la otra, de manera de obtener una

clasificación de permisos o credenciales para distintos grupos de nexos

dentro de una empresa [8].

117

Figura 6-8: Diagrama de resultados para virtualización completa

• Resultado de Load Balancing: Se logra una correcta distribución de ancho

de banda de 50% de llamadas pasadas por una ruta directa al proveedor

y el otro 50% de llamadas pasadas por una ruta creada por Servidor

Asterisk “URIEL” que finalmente llega al mismo proveedor, este resultado

es correcto según lo que implica el modo “Round-robin”, el cual distribuye

el ancho de banda alternadamente, dependiendo del porcentaje que se le

indique al configurar, en este caso 50%-50% de carga. Se muestra de

forma gráfica y de diagrama de flujo, como funciona el proceso, en las

figuras 6-9 y 6-10.

Ilim

ita

da

lim

ita

da

118

Figura 6-9: Diagrama de resultados para “Load Balancing”

Figura 6-10: Diagrama de flujo de proceso “Load Balancing”

Pa

th1

Pa

th2

119

• Resultado de Least Cost Routing: Correcta distribución de llamadas

filtradas tanto por discado de numeración, costo asociado, y horario.

Correcta señalización dependiendo de una misma ruta de inicio, y solo

siendo modificada en el tramo final de la ruta hacia el proveedor en la

WAN. Se muestra de forma gráfica el proceso en las figuras 6-11 y 6-12

Figura 6-11: Diagrama de resultados para Least Cost Routing

Figura 6-12: Diagrama de flujo de proceso Least Cost Routing

Co

nd

ició

n 1

Co

nd

ició

n 2

CAPÍTULO 7

SERVICIOS SIP EN MODO ACCESS: CONCEPTOS Y ESTRUCTRA S

7.1 CONCEPTO DE MODO ACCESS EN TELEFONÍA IP

Esta denominación reside en el despliegue de servicios proveídos por una

red “confiable” hacia dispositivos alojados en una red de acceso “no confiable”.

Desde el punto de vista de los “Session Border Controller” (SBC), la

configuración “SIP access” es designada como una concesión remota de

terminales, ya sean “Integrated Access Devices” (IADs), Clientes VoIP o

Teléfonos VoIP, integrados de forma segura, controlando el acceso a los

elementos de la red del proveedor de servicios tal como softswitches, proxies,

“media gateways”, servidores de aplicación, y un sin número de otras

aplicaciones escalables [10].

Las principales áreas funcionales a considerar en el diseño de

configuración de “SIP Access” se concentran en la “registro”. La mayoría de de

los “SIP User Agents” (UAs) en una red de acceso, son obligados a realizar una

secuencia de registro SIP con el cometido de presentar credenciales de

autenticación a un registrar, esto como medida base de seguridad propio del

protocolo SIP. La secuencia de registro crea un enlace de modo que las

llamadas de destino para terminar en un “end-point” pueden ser localizadas por

dirección de transporte (dirección IP y puerto SIP) [10].

Otro concepto importante que proporcionan los SBCs Acme Packet es el

SIP “Hosted NAT Traversal” (HNT), esta proporciona confiabilidad de una

manera persistente de tal forma que logra facilitar accesibilidad a SIP-UAs,

ubicados en redes de área local detrás de dispositivos de seguridad como NAT

“firewalls”. Ocultamiento de topología, es otro mecanismo por el cual un SBC

121

elimina información sensible con respecto a la topología de la red (por ejemplo,

direcciones IP) donde hay dispositivos vitales que no deben ser intervenidos, así

los datos provenientes de estos equipos no serán transmitidos directamente a

redes no fiables.

El SBC Acme Packet también funciona como un P-CSCF en arquitectura

IMS, teniendo como base el modo “access”. Aunque las características que

típicamente se encuentran en un P-CSCF están fuera del alcance del presente

proyecto [10].

7.2 PROPOSICIÓN DE INTEROPERABILIDAD ENTRE MODO ACCESS Y MODO PEERING: SOLUCIÓN DE MOVILIDAD.

Como etapa dos del presente proyecto se obtiene un estudio completo de

las facilidades mostradas por SIP-trunk alojadas en el SBC Acme Packet, la

desventaja de este es la poca movilidad, se limita a accesos remoto por vpn o

servidores Stun, lo que produce una cierta movilidad pero poca confiabilidad en

las comunicaciones, con este sacrificio logra un ancho de banda estable y

seguro conectado a un punto de proveedor ITSP.

La solución “access” por otra parte, siendo implementada en

“smartphones” a través de clientes SIP, logra movilidad total, e incluso

redundancia de rutas hacia el proveedor SIP-registrar/proxy, en este caso el

SBC, estas rutas son a través de 3G (UMTS) y Wi-Fi (IEEE 802.11).

Una vez presentadas la falencias de SIP-Trunk, y su complemento SIP-

register a través de modo “access”, se propone una solución integral, que por

una parte provee confiabilidad a llamadas hacia la PSTN, la cual es

completamente necesaria, y se reducen drásticamente las tarifas dentro de una

empresa, complementando la solución en modo “access” para realizar llamadas

entre dispositivos “smartphones” de la misma empresa con conectividad a WAN.

Por otro lado, se puede realizar e

como solución única, la respuesta a esto es que esa solución es poco factible

para los proveedores ITSP, ya que para lograr comunicar a la PSTN con SIP

register, el uso del ancho de banda se vuelve defic

trunk, sin mencionar el excesivo uso de equipamiento para lograr una cantidad

deseable de llamadas simultáneas como lo hace SIP

solución de “access” para uso interno de la empresa, lo cual no es menor.

7.3 DIAGRAMA ESTRUCTURAL CON SIP-TRUNK.

La forma de abordar este tema, es comenzar con un estudio de un diseño

eficiente, eficaz en su defecto

solución en modo “access”.

De acuerdo al diagrama

estar en cualquier parte que tenga acceso a la Red WAN pública, y tendrá

comunicación SIP a través de un puerto

del SBC, logrando liberar “media

protegido por este nodo de borde, ya sean registrados por SCCP o SIP.

Figura 7-1: Estructura

122

de realizar el cuestionamiento de usar modo “access

como solución única, la respuesta a esto es que esa solución es poco factible

para los proveedores ITSP, ya que para lograr comunicar a la PSTN con SIP

register, el uso del ancho de banda se vuelve deficiente, en comparación a SIP

trunk, sin mencionar el excesivo uso de equipamiento para lograr una cantidad

neas como lo hace SIP-Trunk, por ello se toma la

ccess” para uso interno de la empresa, lo cual no es menor.

DIAGRAMA ESTRUCTURAL DE SOLUCIÓN ACCESS E INTEGRACIÓ

La forma de abordar este tema, es comenzar con un estudio de un diseño

eficaz en su defecto, de un diagrama solamente enfocado en

mostrado en la figura 7-1 el cliente SIP puede

estar en cualquier parte que tenga acceso a la Red WAN pública, y tendrá

comunicación SIP a través de un puerto UDP habilitado en la interfaz “access

media” con cualquier teléfono registrado en la red LAN

protegido por este nodo de borde, ya sean registrados por SCCP o SIP.

1: Estructura conceptual: modo “Access”

122

ccess”

como solución única, la respuesta a esto es que esa solución es poco factible

para los proveedores ITSP, ya que para lograr comunicar a la PSTN con SIP-

iente, en comparación a SIP-

trunk, sin mencionar el excesivo uso de equipamiento para lograr una cantidad

r ello se toma la

ÓN

La forma de abordar este tema, es comenzar con un estudio de un diseño

enfocado en la

el cliente SIP puede

estar en cualquier parte que tenga acceso a la Red WAN pública, y tendrá

ccess”

n cualquier teléfono registrado en la red LAN

En la figura 7-2 se muestra

“register” desde el lado de acceso

llamada.

Figura 7-2: Diagrama de señalización SIP

123

2 se muestra el protocolo ejecutado en SIP para realizar el

desde el lado de acceso, y su posterior establecimiento de una

Diagrama de señalización SIP-register

123

el protocolo ejecutado en SIP para realizar el

, y su posterior establecimiento de una

La idea de “register” es generar una instancia de autenticación constante,

como primera medida de seguridad en servicios de modo

tiene un ciclo de 130 segundos

modificar es tiempo de acuerdo a las necesidades de seguridad y la capacidad

de la red de no producir latencia por ocupación innecesaria de ancho de banda.

Logrando reproducir el sistema en modo “a

construir una estructura SIP-

Virtualización, característica también comprobada só

conseguir una integración completa d

la telefonía IP. La figura 7-3,

proyecto.

Figura 7-3: Estructura conceptual: modo

124

es generar una instancia de autenticación constante,

seguridad en servicios de modo “access”, este proceso

tiene un ciclo de 130 segundos de lapso entre cada “register”, siendo posible

modificar es tiempo de acuerdo a las necesidades de seguridad y la capacidad

de la red de no producir latencia por ocupación innecesaria de ancho de banda.

reproducir el sistema en modo “access”, y sabiendo también

-trunk, el siguiente paso es a través de la

cterística también comprobada sólo en ambiente SIP-trunk,

conseguir una integración completa de los dos métodos protocolares de SIP para

3, estructura conceptualmente la pretensión del

Estructura conceptual: modo “access/peering” virtualizado

124

es generar una instancia de autenticación constante,

, este proceso

, siendo posible

modificar es tiempo de acuerdo a las necesidades de seguridad y la capacidad

de la red de no producir latencia por ocupación innecesaria de ancho de banda.

, y sabiendo también

a través de la

trunk,

e los dos métodos protocolares de SIP para

estructura conceptualmente la pretensión del

Como se observa, la idea es lograr a través de una s

servicios, siendo separados por puertos distintos pero con una misma dirección

IP. Esto según la empresa Acme Packet es posible por parte de su serie de

equipos SBC, por lo tanto la resolución de esta práctica se basa en las

capacidades de los equipos adyacentes en cuanto a virtualización y el grado de

control que se tiene con ellos, ya sea en el lado LAN o empresa, como la WAN o

ITSP [11].

Como una última práctica, se desarrolla un esquema con un mismo

objetivo al anterior, o sea, la solución integral que reemplaza y mejora la actual

solución presentada por las empresas proveedoras que conforman la PSTN,

pero con la salvedad que se centra más en la disponibilidad y eficacia por sobre

la eficiencia y economía. En la figura 7

una solución más segura y aplicable

Figura 7-4: Estructura conceptual: modo

125

Como se observa, la idea es lograr a través de una sola ruta física, ambos

servicios, siendo separados por puertos distintos pero con una misma dirección

IP. Esto según la empresa Acme Packet es posible por parte de su serie de

equipos SBC, por lo tanto la resolución de esta práctica se basa en las

des de los equipos adyacentes en cuanto a virtualización y el grado de

control que se tiene con ellos, ya sea en el lado LAN o empresa, como la WAN o

Como una última práctica, se desarrolla un esquema con un mismo

la solución integral que reemplaza y mejora la actual

solución presentada por las empresas proveedoras que conforman la PSTN,

pero con la salvedad que se centra más en la disponibilidad y eficacia por sobre

En la figura 7-4 se presenta el esquema que explica

una solución más segura y aplicable [11].

Estructura conceptual: modo “access/peering” direferenciado por

interfaces físicas

125

ola ruta física, ambos

servicios, siendo separados por puertos distintos pero con una misma dirección

IP. Esto según la empresa Acme Packet es posible por parte de su serie de

equipos SBC, por lo tanto la resolución de esta práctica se basa en las

des de los equipos adyacentes en cuanto a virtualización y el grado de

control que se tiene con ellos, ya sea en el lado LAN o empresa, como la WAN o

Como una última práctica, se desarrolla un esquema con un mismo

la solución integral que reemplaza y mejora la actual

solución presentada por las empresas proveedoras que conforman la PSTN,

pero con la salvedad que se centra más en la disponibilidad y eficacia por sobre

senta el esquema que explica

direferenciado por

126

Lo que muestra el cuarto diagrama para la tercera práctica, es una

solución más sencilla, que sin duda ocupa más recurso, pero presenta mayor

seguridad y confiabilidad al cliente. Trata de establecer ambos servicios,

“access” y SIP-Trunk, en 2 distintas interfaces físicas, con esto no se interfiere

con el normal funcionamiento de SIP-Trunk y con su principal objetivo dar

confiabilidad y seguridad al cliente al cual se le está proveyendo el servicio de

telefonía IP con el mismo o mejor desempeño que la actual PSTN [12].

CAPÍTULO 8

SERVICIOS SIP EN MODO ACCESS: IMPLEMENTACIONES Y PR UEBAS 8.1 LABORATORIO: MODO ACCESS

Como primera medida dentro de la tercera etapa del proyecto, es el

reconocer las herramientas en el objetivo de implementación. Este apartado,

contempla 3 conjuntos, equipamiento físico, herramientas informáticas, y

diagrama de interconexión. En etapas anteriores del proyecto se da a conocer de

forma detalla todo el laboratorio de interoperabilidad de telefonía IP. Esta vez

solo se da a conocer el equipamiento y funcionalidad más relevante para la

implementación en modo “access”.

8.1.1 Equipamiento Físico y de software: Modo “access” con “SIP-register” y “Peering” con “SIP-trunk”

El núcleo de toda implementación en modo “access” es claramente

desarrolla por el equipo que introduce este tema, el SBC Acme Packet 4250 en

esta ocasión. Por otra parte, la base de datos telefónica será implementada en

un Cisco Call Manager Virtualizado en un servidor HP, en este equipo serán

configurados tanto el SIP-trunk interno como los UAs registrables. También es

muy importante la implementación del SIP-trunk externo que será la ruta de

llamadas hacia la PSTN. Todo lo anterior en acción para el desarrollo del

laboratorio “peering” e implementación base de telefonía IP, ahora por el lado de

“access”, lo más importante son los distintos equipos “Smartphone” o

“Softphones” a ocupar para demostrar una cierta variedad de compatibilidades

en el sistema “access”, los equipos y software a probar son los siguientes (estos

también se muestran en la figura 8-1 de forma correspondiente).

128

Figura 8-1: “Smartphones” y “Softphones” usados para pruebas de

interoperabilidad “Access/Peering”

• iPhone 3GS

• Blackberry 8900

• Nokia N78

• SDK Android

• X-Lite

• Bría

8.1.2 Herramientas informáticas

Dentro de las aplicaciones necesarias y eficaces para empleo de

administración y desarrollo de pruebas se tiene:

129

• CLI (Command Line Interface): Su principal cometido es la configuración y

administración de equipos por distintos protocolos de acceso de

administrador, entre ellos están: telnet, ssh, puerto consola. Ejemplos de

ellos: Secure CRT, y Putty

• minicom: Aplicación Linux de administración remota por consola a equipos

con este tipo de interfaz.

• OpenVPN (Virtual Private Network): Software creado tanto para sistemas

operativos Windows como para Linux creador y administrador de enlaces

remotos seguros punto a punto a una red, necesario para el operador que

tiene equipos de su sistema en distintos puntos geográficos.

• Cisco VPN Client: Desarrollado por Cisco de forma propietaria, para un

mejor rendimiento en acceso remoto a sus equipos.

• IPtables: Aplicación Linux como firewall, muy importante al momento de

crear enlaces VPN.

• Asterisk: Aplicación Linux que desarrolla una centralita PBX, ideal para

realizar pruebas de servicio VoIP

• Cisco IP communicator: Softphone desarrollado por Cisco, logra emular

un teléfono IP Cisco, con la gran salvedad que aporta movilidad al

operador.

• Cisco Configuration Assistant (CCA): Software exclusive para la Unified

Cisco (Ej.: UC 500 series), usado como interfaz gráfica de administración,

con un alto desempeño por facilitar las tareas al operador de red.

• Wireshark: Excelente analizador de tráfico de red, abarcado la mayoría de

los protocolos usados para servicios integrados de red. Posee filtraje de

protocolos, herramientas exclusivas para tráfico VoIP (gráfico de

señalización VoIP, gráficos para tráfico de voz).

• Winscp: Cliente SFTP gráfico para Windows que emplea SSH. Su función

principal es facilitar la transferencia segura de archivos entre dos sistemas

informáticos, el local y otro remoto que ofrezca servicios SSH.

130

• Conexión de escritorio remoto de Windows: Ideal para administrar equipos

con sistema operativo Windows de forma estándar y sencilla.

• VMware Workstation: Virtualizador de Sistema operativos completos

(interfaces, multimedia, red), facilita la necesidad de otro equipo PC para

el desarrollo de pruebas de terminal.

8.2 DIAGRAMA DE INTERCONEXIÓN: MODO “ACCESS”

Una vez conocidos los elementos y herramientas de red, se procede a la

descripción de relación en el sistema de implementación, en la figura 8-2 se

muestra el diagrama del Laboratorio interconectado para esta implementación

[10].

Figura 8-2: Diagrama de sistema físico, enlace de datos, y red para

implementación “Access”

131

Sistema está regido por VLANs. En el lado LAN del laboratorio se tratan

todos los equipos pensados en una empresa que adquiere servicios telefónicos

IP profesionales, estos equipos a su vez toman acceso desde la WAN,

asignando VLANs internas privadas para las interfaces de los equipos SBC y sus

bases de datos telefónicas resididas en los CCMs. Así también la configuración,

administración y medición de pruebas se realizan a través de accesos VPN

otorgados por el servidor “RAMIEL”.

Como comienzo en el levantamiento de la red y configuración del servicio

de telefonía IP, se realiza la interconexión configurando primeramente en el

switch las respectivas VLANs para la conectividad hacia el interior y exterior de

la empresa, luego se realiza la configuración de conectividad en el SBC en sus 2

interfaces existentes para este laboratorio, comprobando al final que exista una

correcta comunicación entre los dispositivos adyacentes. Se realiza en una

segunda parte la configuración respecto a los servicios access en el SBC, y una

posterior configuración de cuentas SIP dentro del CCM para realizar “registers”

desde UAs en la red WAN. Estos últimos deben tener instalados Clientes SIP

genéricos para poder introducir los respectivos datos de la cuenta habilitada

dentro del CCM, clientes SIP como: iSIP para iPhone, Blackvoib para Blackberry,

Fring para Nokia (N78), SIPdroid para sistemas Android, X-lite y Bria.

Los campos importantes a configurar dentro de un cliente genérico SIP

(existen también propietarios, que solo sirven con un solo proveedor, o sea,

están auto-configurados) son:

• Username: este es el número asignado al “end-point”, configurado

previamente en el CCM, puede ser un número o un DNS asociado a un

servidor.

• Domain: puede ser una dirección IP o enmascarada con un nombre DNS,

esta dirección corresponde al servidor de base de datos de telefonía IP,

en este caso el CCM. Si en el equipo SBC llegara a estar configurado con

SIP-NAT, entonces este actuará como proxy dando un sufijo al dominio

132

correcto donde se encuentra el CCM (esta previamente configurado el

sufijo en el SBC).

• Authorization username: Nombre de cuenta de autorización, este debe

coincidir completamente con el configurado en el CCM.

• Password: También configurado previamente en el CCM en el campo

“Digest credentials” de los “end-users”.

• Port: Por defecto es el puerto 5060 para señalización SIP.

• Protocol: Por lo general se usa UDP, pero de todas maneras se puede

usar TCP.

• Server/Proxy: Es opcional, si no se tiene configurado los campos SIP-NAT

dentro del SBC es obligatorio (Se entra más en detalle en los párrafos

posteriores).

En la figura 8-3, una muestra con “screenshot” de las opciones que ofrece

Bría (“softphone” gratuito) y SIpdroid en SDK android.

Figura 8-3: Ejemplos de vistas de configuración de “SIP-clients”, en “softphones”

y “smartphones” respectivamente.

133

8.3 LABORATORIO: MODO “ACCESS/PEERING” VIRTUALIZADO

En la búsqueda de la solución más integral posible, se trata de converger

los conceptos de “access” y “peering” dentro de dos instancias virtualizadas. De

forma conceptual se forzará a la interfaz donde está ambientado el SIP-trunk,

para dar paso a telefonía IP bajo SIP-register, esto según las practicas de Acme

Packet es realizable por parte de su equipamiento SBC, por lo tanto queda por

demostrar la capacidad de los equipos adyacentes por lograr esta instancia de

virtualización. En la figura 8-4 se muestra el diagrama técnico de la red

implementada para la solución deseada[11].

Figura 8-4: Diagrama de sistema físico, enlace de datos, y red para

implementación “Access/Peering” Virtualizados

134

De acuerdo con el plan de implementación desarrollado, el SBC tendrá

configurada sólo dos interfaces para lograr comunicación por los métodos

existentes en SIP, “SIP-Register” y “SIP-Trunk”, para ello el SBC presenta la

capacidad de enviar “media” de distintos métodos a través de una misma

dirección IP pero por distintos puertos, por defecto el puerto SIP es 5060, pero

está permitido señalizar por puertos que estén en el rango de 1025-65535 para

UDP y TCP, siempre y cuando no estén ocupados de forma personalizada por el

sistema implementado en cuestión. Se configura el CCM para que reciba por el

puerto 5061 SIP-Trunk y por 5060 SIP-Register, el proveedor ITSP no se puede

controlar para que envíe señalización por métodos SIP-Trunk en un puerto

distinto del 5060, se propone configurar los SIP-client para que señalicen por

métodos SIP-register por un puerto distinto del 5060 [11].

8.4 LABORATORIO: MODO “ACCESS/PEERING” DESVIRTUALIZADO

Como ultima evolución en la solución al servicio final deseado, se da un

perfil de mayor confiabilidad y seguridad. Para ello se instalan 2 interfaces

adicionales donde se implementa la solución modo “access”, dejando de esta

forma libre paso a la señalización SIP-Trunk por otra interfaz no compartida. De

esta forma, toda la señalización SIP (SIP-trunk y SIP-register) irá por puertos

5060 pero por distintas interfaces, “ethernet” en este caso.

En esta configuración se deben tomar menos precauciones, en cuanto a

pérdidas de tráfico, bloque de servicios, congestionamiento de tráfico, Seguridad

tipo DoS con frecuencia. Por otra parte se deben ocupar mayor cantidad de

recursos en la red, sin mencionar la activación de 2 canales SIP por parte del

proveedor, si se desea realizar llamadas a la PSTN a través de “smartphones”

registrados en modo “access”. Sin embargo esta implementación es la más

completa, abarcando casi en su totalidad los servicios que presentan las

empresas pertenecientes a la PSTN. En la figura 8-5 se presenta el diagrama.

135

Figura 8-5: Diagrama de sistema físico, enlace de datos, y red para

implementación “access/peering” diferenciados por interfaces

El diagrama técnico de la figura 8-5, es desarrollado como solución

definitiva a la realización de un producto comercial en el presente proyecto. Si

bien exige una mayor disponibilidad de recursos de la red, esta solución asegura

una implementación con estándares comerciales por parte del diseño, resta

entonces verificar la confiabilidad de los clientes SIP alojados en “Smartphones”

y “Softphones”.

8.5 RESULTADOS Y COMENTARIOS DE SOLUCION INTEGRAL SIP ACCESS/PEERING

Las secciones 8.2, 8.3, y 8.4, dan a conocer todo el ambiente en cual se

procede a buscar resultados.

136

La resolución al problema toma sin duda una forma evolutiva, al

desarrollar una teoría de forma empírica con respecto al comportamiento del

direccionamiento telefónico IP en los sistemas SBC, e incluso en el equipamiento

ajeno al sistema, que proveen el servicio. Así también se presentan las

soluciones encontradas respectivamente, de forma evolutiva y empírica.

Solución modo access nativo:

• La implementación es efectiva.

• Se logran llamadas entre “end-points” pertenecientes al “cluster” del

laboratorio, y llamadas entre “end-point” “access” y “end-point” alojados en

la LAN de la red del laboratorio.

• Solución incompleta, es parte del proceso para lograr la solución

comercial base definitiva para movilidad en telefonía IP.

Observaciones: Esta implementación se ciñe completamente a las

recomendaciones de las prácticas realizadas por Acme Packet, las “Best Current

Practice” (BCP).

Solución modo “access/peering” virtualizado:

• La implementación no es efectiva. Las razones de su no efectividad es por

una parte la no aceptación de métodos “registers” a través de un SIP-

trunk en el CCM 6.x, y en este sentido el SBC acme packet no logra

apuntar distintos métodos por distintos puertos y la misma dirección IP.

• Según Acme packet esto es posible, aún así a la vista del proyecto no es

una medida por la cual se arriesgue a una implementación comercial.

Observaciones: Se encuentran nuevas formas de poder realizar esta práctica,

queda entonces pendiente para trabajos futuros.

Solución modo access/peering diferenciado por interfaces físicas:

• La implementación es efectiva.

• Se logran llamadas simultaneas entre end-points IP (ya sea que se

encuentren dentro de la red del laboratorio de pruebas u ocupen métodos

137

register a través de modo access) y end-points IP (Pertenecientes a la red

del laboratorio) con end-points PSTN.

Observaciones: La configuración no se ciñe a ninguna recomendación de

práctica proporcionada por Acme Packet. La solución técnica es deducida dentro

del proyecto. El problema era generado por definición de accesos redundantes

que no permitían el registro normal de los end-points alojados en la red pública

WAN, estos accesos redundantes eran ocasionados por la configuración de SIP-

NAT realizada en el SBC, como método de seguridad. Una vez localizado el

problema, se procede a dar solución al problema de redundancia con

diferenciación de rutas con comandos de filtro de direccionamiento IP [10].

CAPÍTULO 9

EVALUACIÓN ECONÓMICA DEL PROYECTO 9.1 CARACTERÍSTICAS CONTEMPLADAS DENTRO DE LA EVALUACIÓN

Para realizar una evaluación económica, el primer paso es acotar las

variables a evaluar con la primicia de que éstas deben afectar la economía del

proyecto de una manera sustancial.

Así la evaluación se dividirá en cinco etapas para la obtención de una

herramienta óptima desde el punto de vista comercial. A continuación se

presentan estas etapas.

• Parámetros: Deben ser influyentes económicamente en el presente

proyecto.

• Costos: De los parámetros influyentes, se configuran en conjuntos y

cantidades de una forma numérica, para cuantificar la influencia en el

proyecto de una forma relacional, ya no en forma bruta, como en la etapa

de “Parámetros”.

• Beneficios: Al igual que los costos, estos son sacados de los

“Parámetros”, relacionados en conjuntos y cantidades de una forma

numérica, pero con la diferencia de que estos son para cuantificar de

forma positiva el proyecto, esto es, la forma en que mejora el entorno del

sistema inicial, al implementar el proyecto como una mejora a él.

• ROI: Primer y más importante cuantificador, el cual basa su modelo en los

tipos de costos, estos son los de inversión inicial, y gastos operacionales

anuales, y estos a su vez relacionados con los ahorros de beneficios

anuales que presenta el proyecto. Estos se muestran relacionados en la

figura 9-1.

139

��� =����� �� � − ��

��%

Figura 9-1: Relación de ROI con Costos y Beneficios

• Flujo de caja: Herramienta de medición complementaria al ROI,

contemplando dentro de su medición índices económicos como el VAN, y

el VAN acumulado, ambos para saber cuándo se recupera la inversión

inicial y cuando el sistema es autosustentable comercialmente, en la

figura 9-2 se muestra la relación del VAN. Por otra parte se tiene el TIR

para medir la rentabilidad del proyecto, ello lo hace en porcentaje

complementando el indicador VAN. LA relación del TIR se muestra en la

figura 9-3.

00 (1 )

Nt

tt

FVAN I

i=

=− ++∑

Figura 9-2: Relación de VAN e Ingresos

0

0(1 )

Nt

tt

F

TIR=

=+∑

Figura 9-3: Relación para determinar punto TIR en la curva VAN

140

9.2 ESCENARIO CONTEMPLADO PARA LA EVALUACIÓN

De acuerdo con lo contemplado a lo largo del proyecto, la solución más

innovadora y por lo demás la de mayor acercamiento a un producto comercial,

es la solución demo de “SIP-trunk/register diferenciado por interfaces físicas”. Se

habla de una solución que abarca un mercado empresarial que realiza grandes

inversiones en comunicaciones, y además que las realiza mucho en terreno,

ejemplo de ello serían las empresas mineras, clínicas, empresas de periodismo,

y un sin número de otros rubros, donde lo que ellos necesitan es tener completa

comunicación a un bajo costo y además de calidad, con una la idea de que el

costo sea el mismo o parecido desde su empresa o en terreno, e incluso de

costo cero entre sus pares dentro de la empresa. Dicho esto, el escenario

contemplado a evaluar, contiene los siguientes parámetros.

• Hardware: Switch Multilayer, CUCM 6.x o superior, SBC Acme Packet

3800 o 4250, teléfonos duales (para este caso son iPhone 3G), Cableado

Ethernet.

• Licencias: Licencia base de Acme Packet SIP, H323, IWF, ACP, Routing,

PAC, ENUM, licencia CUCM 6.0, Licencia Third-Party Device (10

unidades por licencia).

• Recursos humanos (RRHH): Ingeniero en terreno, ingeniero en sistema,

capacitación de sistema para cliente.

• Software: iSIP.

• Parámetros de llamadas: Valor de minuto llamadas locales, nacionales,

internacionales, celulares, número de llamadas promedio locales,

nacionales, internacionales y celulares.

141

9.3 COSTOS Y BENEFICIOS EVALUADOS

La forma de abordar la gran cantidad de equipamiento, software y

herramientas en general en una propuesta comercial, es mostrando todas los

“ítems” posibles en una tabla programada para habilitar o no los costos y

beneficios de dicho ítem. Para ellos se usa la herramienta de macros en el

software Excel, estos macros son previamente programados para poder realizar

cualquier tipo de configuraciones en el sistema, desde el punto de vista

comercial. En las tablas 9-1, 9-2 y figura 9-4, se presenta la cuantificación

respecto a los “ítems” de “Costos” y “Beneficios” de una configuración en

particular para un cliente ficticio.

Tabla 9-1: Costos de inversión inicial y operación anual (en $US) [13]

Item PARAMETROS Min Local CantidadCosto de Inversión

(US$)Costos de Operación

Anual (US$)Comentario

HARDWARE Switch Multilayer Cisco Catalyst 3560 24 10/100 + 2 SFP 1 4.990,00$ SOPORTE SHARED SUPP SDS, Cat 3560 24 10/100 w/2 SFP Enhanced 1 124,00$ HARDWARE Unified CM BE, 7828-I4 appliance, 50 seats 1 9.995,00$ HARDWARE Acme Packet 4250 1 5.000,00$ LICENCIA License Acme Packet 4250 1 3.000,00$ CELULAR Iphone 3GS 30 28.799,40$ INSTALACION Cableado e instalaciones para equipos de red 1 100,00$ SOFTWARE iSIP 30 119,70$ LICENCIA License CM 6.0 7815 Appliance, 500 seats 1 3.995,00$ LICENCIA Unified CM Third-Party Device License - 10 units 3 1 .500,00$ LICENCIA DLU por Telefono SIP 30 4.500,00$

RRHH Hora Field Engineer 33 2.772,00$

Horas instalación y configuracion de equipos + horas configuracion cliene SIP por usuario

RRHH Hora System Engineer 15 1 .890,00$ Horas para ingeniería de planificación

RRHH Hora Personal de capacitación al cliente 44 3.696,00$

Horas capacitación al cliente en uso registro de UA en CUCM y Horas capacitación al cliente en uso Cliente SIP por usuario

LLAMADAS Min Local 316559,6 5.698,07$ LLAMADAS Min Larga distancia nacional 2132,6133 149,28$ LLAMADAS Min Larga distancia internacional 2751 ,0667 434,67$ LLAMADAS Min celular 50916,747 9.165,01$

Margen de Ganancia sobre el costo de inversión 0 10.572,17$ 0 -$

Mantención 0 -$ Mantención red cableada, cables y puntos de red 0 -$ 1 .200,00$ Mantención equipos de red 0 -$ 4.796,40$

0 -$ - Total 81.053,27$ 21.443,44$

142

Tabla 9-2: Resumen de Costos agrupados por ítems (en $US) [13]

HARDWARE 19985SOFTWARE 119,7LICENCIAS 12995RRHH 8358SOPORTE 124INSTALACION 100CELULAR 28799,4* No Considera el margen de ganancia

Resumen de Costos de Inversion

En el punto anterior se explica las relaciones conceptuales que materializa

esta planilla, conteniendo todos los costos iniciales de inversión, así como

también contempla los costos anuales de operación, logrando una visión inicial

del proyecto y como se mantiene en el tiempo, formando la base de la inversión

sin tener que enfrentar problemas indeseados de financiamiento mientras se

ejecuta el proyecto.

Figura 9-4: Gráfico resumen de costos por items

28%

0%19%

12%

0%

0%

41%

Resumen de Costos del Proyecto

HARDWARE

SOFTWARE

LICENCIAS

RRHH

SOPORTE

INSTALACION

CELULAR

143

También se deben proyectar los beneficios del sistema, en la tabla 9-3 se

muestra dicha proyección de acuerdo a lo propuesto en la tabla 9-1, que

básicamente muestra los insumos del proyecto, esto también se resume en 3

grandes ítems en la tabla 9-4, capital, trabajo, e ingreso operacional.

Tabla 9-3: Tabla de Beneficios y proyección de ingresos [13]

Cantidad Anual Descripción Ingreso / Reducción de Costo Anual (US$) Comentarios

Ahorro en LlamadasEl uso de un Cliente SIP permite cambiar las llamadas de celular por llamadas de extensiones porduciendo reduccion en los costos de las llamadas realizadas.

268221,6 Min Local $ 31.852,95 0 Min Larga distancia nac ional $ - 7,2 Min Larga distancia internacional $ -

21744 Min Celular $ 97,93 Min Celular empresa $ 3.095,35

Calidad de servicioLa configurac ión de QoS perm ite administrar mejor el ancho de banda y por ende se pueden considerar una disminucion de fallas de red que sufren los usuarios y que debe solucionar un Ingeniero de Soporte en dos horas: 10 fallas/mes*SE*2

0 Adm inis tracion de ancho de banda wireless $ -

Convergencia de Servicio

La utilizacion de un unico numero de contacto perm ite hacer uso mas eficiente de las llamadas , ya que todas las llamadas entrantes y salientes son a traves del m ismo aparato. Tambien considera ahorro en tiempo de localizac ion del usuario. Este benefic io considera 0,25 horas de ahorro diarias de tiempo de un empleado segun selecc ion

Administracion número único20 Hora profesional $ 25.200,00 Hora Hombre

Hora Proyect Manager $ - Hora Hombre Hora Personal de capacitación al cliente $ - Hora Hombre Hora Support Engineer $ - Hora Hombre Hora Senior Engineer $ - Hora Hombre Hora System Engineer $ - Hora Hombre Hora Field Engineer $ - Hora Hombre

ProductividadExiste un beneficio por aumento de la productividad que se cons igue con el uso de un telefono dual, que perm ite realizar llamadas mas efic ientes, ademas de consultar correo y agendas de manera. Se considera para este beneficios un ahorro de 0,25 RRHH diarias de un empleado segun seleccion.

20 Hora profesional $ 25.200,00 Hora Hombre Hora Proyect Manager $ - Hora Hombre Hora Personal de capacitación al cliente $ - Hora Hombre Hora Support Engineer $ - Hora Hombre Hora Senior Engineer $ - Hora Hombre Hora System Engineer $ - Hora Hombre Hora Field Engineer $ - Hora Hombre

Equipam iento Telefonia FijaEste benefic io considera el ahorro producto a la dism inuc ion de los costos de los equipos duales en comparac ion con un telefono IP fijo según sea el telefono fijo al cual el telefono dual reemplaza. Se calcula como la diferencia de precios solo cuando este produce un ahorro en costos.

Cisco IP Phone 791 1G                     $ - Telefonía Fija Cisco IP Phone 7941                        $ - Telefonía Fija Cisco Unified IP Phone 7942              $ - Telefonía Fija Cisco IP Phone 7961                        $ - Telefonía Fija Cisco Unified IP Phone 7962                $ - Telefonía Fija 7914 IP Phone Expansion Module              $ - Telefonía Fija

5 IP Conferece Station, Spare                 $ 5.970,00 Telefonía Fija25 Cisco IP Conference Station 7937 Global     $ 32.350,00 Telefonía Fija

Garantia $ - Telefonía Fija

FIN FINTotal 123.766,23$

144

Tabla 9-4: Items de beneficios

Item Ingresos / Reducción de costos por ItemCapital 38.320,00$ Trabajo 50.400,00$ Ingreso Operacional 31 .950,88$

Se presenta gráficamente en la figura 9-5, donde se concentra la mayor

fuente de beneficios, esto para tener una visión más completa de donde poner

los esfuerzos en seguir mejorando el proyecto.

32%

42%

26%

Ingresos / Reducción de costos por Item

Capital Trabajo Ingreso Operacional

Figura 9-5: Gráfico resumen de beneficios

145

9.4 RESULTADOS DE EVALUACIÓN COMERCIAL DE LA SOLUCIÓN

Como se explica en la sección 9.1 del presente proyecto, a continuación

se exponen los resultados de los indicadores finales de la evaluación del

proyecto, estos son el ROI, VAN, VAN acumulado y TIR. En primer lugar la tabla

9-5 muestra por extensión los resultados del indicador ROI.

Tabla 9-5: Valores de resultados del ROI

Item Valor

Costo Inversión Inicial 81 .053,27$

Costo Operacional Anual 21 .443,44$

Ahorro Operacional Anual 123.766,23$

Años desde la inversión Porcentaje recuperado de la inversión

Ganancias acumuladas (US$)

1 126% 21 .269,52$ 2 252% 123.592,31$ 3 379% 225.915,10$ 4 505% 328.237,89$ 5 631% 430.560,68$

Figura 9-6: Gráfico con resultados del ROI

0%

100%

200%

300%

400%

500%

600%

700%

1 2 3 4 5

Po

rce

nta

je r

ecu

pe

rdo

%

Periodo [años]

Porcentaje recuperado de la inversión

146

Como se aprecia en la gráfico 9-6, el porcentaje de inversión utilizado en

el proyecto es recuperado antes de cumplir el primer año de implementación en

clientes. Se habla entonces, de un proyecto seguro, sin embargo, no se debe

despreciar en ningún caso el costo de oportunidad en contra, que apoya a la

telefonía conmutada actual, con una trayectoria de muchos años. Por otra parte

este método solo proyecto el bien recuperado de manera estática, no así el

indicador VAN, calculado a continuación a través de la tabla 9-6.

Tabla 9-6: Flujos de caja del proyecto, valores de indicadores económicos

Flujo por Año [US$] 0 1 2 3 4 5

(+) Ingresos 123.766,2 123.766,2 123.766,2 123.766,2 123.766,2

Ahorro Operacional Fijo 0,0 0,0 0,0 0,0 0,0 Ahorro Operacional Anual 123.766,2 123.766,2 123.766,2 123.766,2 123.766,2(-) Costos de Operación 21.443,4 21.443,4 21.443,4 21.443,4 21.443,4

Costo Operacional Anual 21 .443,4 21 .443,4 21 .443,4 21 .443,4 21 .443,4(-) Depreciaciones 6.661,7 6.661,7 6.661,7 0,0 0,0

Hardware (3 años lineales) 6.661 ,7 6.661 ,7 6.661 ,7 0,0 0,0(+) Pérdidas de ejercicio anterior 0,0 0,0 0,0 0,0 0,0

(=) Utilidad Antes de Impuestos 95.661,1 95.661,1 95.661,1 102.322,8 102.322,8

(-) Impuesto (17%) 16.262,4 16.262,4 16.262,4 17.394,9 17.394,9

(=) Utilidades Despues de Impuestos 79.398,7 79.398,7 79.398,7 84.927,9 84.927,9

(+) Depreciaciones 6.661,7 6.661,7 6.661,7 0,0 0,0

(-) Pérdidas de ejercicio anterior 0,0 0,0 0,0 0,0 0,0

(=) Flujo de Caja Operacional 0 86.060 86.060 86.060 84.928 84.928

(-) Inversion Inicial (considera margen de 15%) 70.481,1

Hardware 19985 Software 119,7 Soporte 124 Instalación 100 RRHH 8358 Licencia 12995 Celular 28799,4(+) Valor Residual de los Activos

(-) Capital de Trabajo

(+) Recuperacion Capital de Trabajo

(=) Flujo de Capitales -70.481 0 0 0 0 0

(=) Flujo de Caja Privado -70.481 86.060 86.060 86.060 84.928 84.928

VAN i (Tasa de Desc. de 15% Real Anual) -70.481 66.200 50.923 39.172 29.736 22.874

VAN acumulado -70.481 -4.281 46.643 85.814 115.550 138.423

Tasa de Descuento 30%

VAN 138.423 US $TIR 120%

PAYBACk 2 años

147

Como se explica en el párrafo anterior, el tipo de proyección que genera el

VAN es dinámico, lo que da un acercamiento más real a lo que pase con el

proyecto en los próximos años. Así el VAN indica cómo evoluciona el flujo de

cajas en función del tiempo, luego se realiza una suerte de sumatoria

promediada para ajustar el VAN acumulado, y dar cuenta de flujos efectivos

positivos al primer años, todo esto se muestra en la figura 9-7.

Figura 9-7: Gráficos con resultados de indicadores de VAN y VAN acumulado

-80.000

-60.000

-40.000

-20.000

0

20.000

40.000

60.000

80.000

0 1 2 3 4 5

US

$

Periodo

VAN i

-100.000

-50.000

0

50.000

100.000

150.000

0 1 2 3 4 5

US

$

Periodo

VAN acumulado

CONCLUSIONES

En el presente proyecto de memoria se logra uno de los objetivos

principales de realizar una recopilación detalla y relevante de información sobre

tecnologías SBC y su interoperabilidad con respecto al protocolo SIP-Trunking.

Dentro de los objetivos más específicos, se tiene un gran respaldo técnico

para la implementación del protocolo SIP como solución unificadora, por el gran

hecho de formar gran parte de la arquitectura IMS, otro gran logro que va en flujo

de la visión de este proyecto.

Se logra explicar conceptos más abstractos como interoperabilidad e inter-

funcinamiento, y darle un sentido de aplicación apuntado al Control de Sesiones

de Borde en VoIP.

Se logra un ceñimiento a la planificación inicial, cumpliendo con cada

parte de ella, adaptando a cada objetivo deseado su sistema correspondiente.

Se concreta en varias instancias dentro de los equipos del sistema (CCM,

SBC, Softphone), el concepto de Virtualización, dejando en claro que con pocos

elementos de red se logra una gran eficiencia.

Sin duda la etapa de configuración SIP-trunk es la más sencilla, debido a

su falta de registro permanente del usuario, esto en cuanto a administración,

configuración y escalabilidad.

Se logra una comprensión conceptual del sistema que en un principio está

limitado a desarrollarse de forma fija y convencional, a un sistema expandido en

movilidad, logrando ideas innovadoras para futuras implementaciones

comerciales.

El procedimiento utilizado en la búsqueda de la solución del proyecto, es

un completo éxito al traspasarlo a la etapa de implementación práctica,

mejorando así los tiempos de resolución y desarrollo de ingeniería respecto del

mismo proyecto.

149

En el ámbito comercial, se demuestra que se está en presencia de una

propuesta de negocio muy rentable, además de presentar una respuesta rápida

en ingresos por implementación comercial.

Lo más importante de la propuesta es que no es la realización desde cero

de los proyectos realizados hasta ahora en Dimension DATA respecto de esta

tecnología emergente, sino que aprovechan la modularidad del sistema,

agregando la solución Access la solución base actual implementada

comercialmente, se le da un valor agregado muy sustancial.

REFERENCIAS CITADAS

[1] Trans-European Research and Education Networking Asociation – TERENA

“IP Telephony cookbook” Marzo 2004.

[2] Black, Uyless “Internet Telephony” – Call Processing Protocols Prentice Hall

Series in Advanced Communications technologies E. U. – 2001.

[3] SIPPING Working “Group Requirements from Session Initiation Protocol (SIP)

Session Border” - draft-ietf-sipping-sbc-funcs-09.txt - Febrero 18, 2010.

[4]SIPPING Working “What is a Session Initiation Protocol (SIP) Trunk Anyway?”

- Draft-rosenberg-sipping-siptrunk-00

[5] Eric Keller “Accountability in Hosted Virtual Networks” Princeton University.

[6] Acme Packet Page https://support.acmepacket.com/

[7] Ingate SIP Trunking Workship “SIP Trunking – The Service Provider

Perspective Session” Febrero 2, 2009

[8] Cisco Page http://www.cisco.com/

[9] H.323 Interworking - draft-agrawal-sip-h323-interworking-reqs-05.txt - Junio 28, 2003.

[10] Acme Packet Support “520-0005-04 BCP - SIP Access Configuration.pdf”

[11]Acme Packet Support “520-0020-00 BCP Access Peering Hybrid

Configuration.pdf”

[12] Acme Packet Support “6.1.0_ACLI_Configuration_Guide.pdf”

[13] Camila Troncoso “ROI Telefonía Dual y QoS.xml” 2010

APÉNDICE A

INTEROPERABILIDAD E INTERFUNCINAMIENTO

A-2

APÉNDICE A

INTEROPERABILIDAD E INTER-FUNCIONAMIENTO

ACME PACKET 3800

Tabla A-1: Lista de comandos de equipo Acme Packet para solución de

interoperabilidad e interfuncionamiento

Comando Modo Descripción

h323-config acmesystem(session-router)# Activa una sesión H.323.

h323-stack acmesystem(h323)# Activa una pila de configuración H.323 en

una interfaz.

realm-id nombre de realm acmesystem(h323-stack)# Asocia realm con interfaz H.323.

local-ip número ipv4 o ipv6 acmesystem(h323-stack)# Asocia ip de realm a interfaz H.323.

terminal-alias "h323-ID=nombre de

realm"

acmesystem(h323-stack)# Asocia Id de H.323 a realm.

call-start-fast disabled acmesystem(h323-stack)# Modo de señalización rapida en H.323.

call-start-slow enabled acmesystem(h323-stack)# Modo de señalización lenta en H.323.

media-profiles "telephone-event PCMU" acmesystem(session-router)# Habilita al SBC con media G.711.

iwf-config acmesystem(session-router)# Habilita la interoperabilidad.

media-profiles "telephone-event

PCMU"

acmesystem(iwf-config)# Asocia el perfil de media a la

interoperabilidad en funcionamiento.

host-routes acmesystem(system)# Habilita rutas estaticas a nivel ip,

generalemte para establecer

administración del equipo, o para agregar

un equipo que esta fuera de la

numeración de red del gateway del SBC.

dest-network número ipv4 o ipv6 acmesystem(host-routes)# Establece ruta estatica a red.

netmask número ipv4 o ipv6 acmesystem(host-routes)# Establece mascara de ruta estatica.

gateway número ipv4 o ipv6 acmesystem(host-routes)# Establece nodo gateway para unirse a red

deseada.

local-policy acmesystem(session-router)# Habilita sesión de politica de envio

servicios telefónicos IP, es como una ruta

estatica de VoIP.

from-address valor numérico acmesystem(local-policy)# Establece filtro de origen de llamadas con

un prefijo numerico o pattern, sin filtro se

escribe *.

to-address valor númerico acmesystem(local-policy)# Establece filtro de destino de llamadas

con un prefijo numerico o pattern, sin

filtro se escribe *.

source-realm nombre de realm acmesystem(local-policy)# Asocia Realm al local policy

A-3

Tabla A-1: Lista de comandos de equipo Acme Packet para solución de

interoperabilidad e interfuncionamiento (continuación)

Comando Modo Descripción

next-hop número ipv4 o ipv6 acmesystem(local-policy)# Ruta estatica VoIP luego de ser filtrado el

metodo sip empleado en el real asociado.

realm nombre de realm acmesystem(local-policy)# Realm asociado al destino de la ruta

estatica.

app-protocol SIP o H.323 acmesystem(local-policy)# Protocolo establecido en el segmento

donde trabaja el local-policy.

media-profile acmesystem(session-router)# Habilita un perfil de media

name "telephone-event" acmesystem(media-profile)# Palabra clave para G.711, recomendado

por acme packet

media-type audio, video, data acmesystem(media-profile)# Tipo de media.

payload-type 101 acmesystem(media-profile)# Valor estandar para realizar el peering

media con el equipo proveedor de

servicios.

transport RTP/AVP acmesystem(media-profile)# Protocolo usado para media.

parameters 0-15 acmesystem(media-profile)# Parametro estandar para comunicacion

con el core (call manager).

media-manager acmesystem(media-manager)# Habilita administración de media.

network-interface acmesystem(system)# Habilita interfaz a nivel de red.

name nombre de interfaz acmesystem(network-interface)# Nombre para asociar a interfaz a nivel

físico.

ip-address número ipv4 o ipv6 acmesystem(network-interface)# IP de interfaz física asociada.

netmask número ipv4 o ipv6 acmesystem(network-interface)# Mascara de red de interfaz física

asociada.

gateway número ipv4 o ipv6 acmesystem(network-interface)# Gateway asociado a intterfaz física,

generalmente en el mismo segmento IP.

hip-ip-list número ipv4 o ipv6 acmesystem(network-interface)# Habilita identificación de host, es decir

realizar ping.

icmp-address número ipv4 o ipv6 acmesystem(network-interface)# Habilita protocolo en la interfaz donde el

ip esta asociado, tambien para realizar

ping entre equipos.

phy-interface acmesystem(system)# Habilita interfaz a nivel físico.

name nombre de interfaz acmesystem(phy-interface)# Nombre de interfaz a nivel físico.

operation-type Media, Control,

Maintenance

acmesystem(phy-interface)# Tipo de tráfico que prevalecera en la

interfaz.

port 0,1,2,3 acmesystem(phy-interface)# Asocia perfil de interfaz física a conexión

ethernet del equipo, el numero depende

del modelo SBC, para modelo Acme

Packet 4250 son 4 puertos por slot.

slot 0,1 acmesystem(phy-interface)# Asocia perfil de interfaz física a grupo de

conexiónes ethernet del equipo, el

numero depende del modelo SBC, para

modelo Acme packet 4250, son 2 slot por

equipo.

A-4

Tabla A-1: Lista de comandos de equipo Acme Packet para solución de

interoperabilidad e interfuncionamiento (continuación)

Comando Modo Descripción

realm-config acmesystem(media-manager)# Habilita un realm, el cual cumple la tarea

de unir todo los perfiles asociados a el en

las diferentes capas.

identifier nombre de realm acmesystem(realm-config)# Nombre del realm.

addr-prefix número ipv4 o ipv6 acmesystem(realm-config)# IP del realm.

network-interfaces nombre de interfaz acmesystem(realm-config)# Nombre de interfaz donde se asocia el

realm.

mm-in-realm disabled acmesystem(realm-config)# Habilita acomplamiento de realms

virtuales.

mm-in-network enabled acmesystem(realm-config)# Habilita acomplamiento de otras redes en

el mismo realm.

mm-same-ip enabled acmesystem(realm-config)# Habilita acomplamiento de otras

interfaces del SBC en el mismo realm.

mm-in-system enabled acmesystem(realm-config)# Habilita acomplamiento de otros SBC's en

el mismo realm.

sip-config acmesystem(session-router)# Habilita protocolo SIP en el SBC.

sip-interface acmesystem(session-router)# Pre-habilita protocolo SIP en un realm.

realm-id nombre de realm acmesystem(sip-interface)# Asocia interfaz a real a nivel de servicio

VoIP, con protocolo SIP.

sip-port acmesystem(sip-interface)# Habilita SIP en la interfaz a nivel de red.

address número ipv4 o ipv6 acmesystem(sip-port)# Direccion IP asociada a la interfaz física

donde existirá trafico SIP.

port 1025-65535 acmesystem(sip-port)# Puerto asociada a la interfaz física donde

existirá trafico SIP. Por defecto 5060

transport-protocol UDP. TCP acmesystem(sip-port)# Tipo de tranporte para SIP, por lo genral

es UDP.

allow-anonymous all, agent only, real-

prefix, registered, register-prefix

acmesystem(sip-port)# Filtro a traves del método de señalización

SIP, u origen del tráfico (realm).

steering-pool acmesystem(media-manager)# Habilita pool de puertos RTP, para media.

ip-address número ipv4 o ipv6 acmesystem(steering-pool)# Dirección asociada a interfaz para media.

start-port 0-65535 acmesystem(steering-pool)# Puerto de inicio de rango del pool.

end-port 0-65535 acmesystem(steering-pool)# Puerto de termino de rango del pool.

realm-id nombre de realm acmesystem(steering-pool)# Realm asociado a pool de media.

network-interface nombre de interfaz acmesystem(steering-pool)# Interfaz asociada a pool de media, a nivel

físico.

system-config acmesystem(system)# Habilita sistema SBc, base de toda

configuración

hostname nombre acmesystem(system-config)# Identificador secundario de SBC,

opcional.

default-gateway número ipv4 o ipv6 acmesystem(system-config)# Dirección IP, donde converge todo el

direccionamiento por defecto.

A-5

UC 520

Tabla A-2: Lista de comandos de equipo UC 520 para solución de

interoperabilidad e interfuncionamiento

Comando Modo Descripción

voice service voip UC520(config)# Modo de conf. VoIP.

allow-connections h323 to h323, h323

to sip, sip to h323, sip to sip

UC520(conf-voi-serv)# Habilita tipo de interoperabilidad.

voice class codec 1-10000 UC520(config)# Habilita lsita de codec VoIP

codec preference 1-24 nombre de

codec.

UC520(config-class)# Asocia codecs a lista, ej: g711ulaw.

voice translation-rule 1-1073471823 UC520(config)# Habilita lista reglas de discado telefónico.

Reglas 1111, 2222 y 1112, son

estandares de la configuración.

rule 1-15 // + 0-9 ^ UC520(cfg-translation-rule)# Establece numero de regla por prioridad,

y usa un lenguaje proio del IOS para

desarrollar la regla a partir del leguaje

señalado.

voice translation-profile nombre UC520(config)# Habilita perfil para asociar distintas listas

de translations rules.

translate calling, called 1-1073471823 UC520(cfg-translation-profile)# Asocia distintas reglas de discado

dial-peer voice 1-1073471823 voip UC520(config)# Habilita una lista de política VoIP.

destination-pattern número o prefijo

telfónico IP

UC520(config-dial-peer)# Direcciona a través de un filtro de

discado, al teléfono o grupo de teléfonos

con los que que se desea establecer

llamadas.

b2bua UC520(config-dial-peer)# Habilita el tipo de sesión entre los

terminales VoIP, se usa este por defecto,

por tratarse de una IOS de SBC.

session protocol sipv2, cisco UC520(config-dial-peer)# Establece el tipo de protocolo VoIP en el

tramo de destino.

session target ipv4:x.x.x.x UC520(config-dial-peer)# Asocia pattern telefónico a dirección IP.

codec nombre de codec UC520(config-dial-peer)# Asocia codec a pattern en configuración

APÉNDICE B

LOAD BALANCING, LEAST COST ROUTING y VIRTUALIZACIÓN

B-2

APÉNDICE B

LOAD BALANCING, LEAST COST ROUTING y VIRTUALIZACIÓN

ACME PACKET 4250 (LOAD BALANCING)

Tabla B-1: Lista de comandos de equipo Acme Packet para solución de Load

Balancing

Comando Modo Descripción

local-policy acmesystem(session-router)# Habilita sesión de politica de envio

servicios telefónicos IP, es como una ruta

estatica de VoIP.

from-address valor numérico acmesystem(local-policy)# Establece filtro de origen de llamadas con

un prefijo numerico o pattern, sin filtro se

escribe *.

to-address valor númerico acmesystem(local-policy)# Establece filtro de destino de llamadas

con un prefijo numerico o pattern, sin

filtro se escribe *.

source-realm nombre de realm acmesystem(local-policy)# Asocia Realm al local policy

next-hop SAG: nombre de grupo session

agent

acmesystem(local-policy)# Ruta estatica VoIP luego de ser filtrado el

metodo sip empleado en los realms

asociados, a balance de carga, a traves de

session agents.

realm nombre de realm acmesystem(local-policy)# Realm asociado al destino de la ruta

estatica.

app-protocol SIP o H.323 acmesystem(local-policy)# Protocolo establecido en el segmento

donde trabaja el local-policy.

session-agent acmesystem(session-router)# Habilita session-agenta, este sirve como

nexo dinamico, en situaciones de

redundancia, generando algoritmos de

elección a nivel de servicios VoIP.

hostname nombre acmesystem(session-agent)# Nombre que asocia realm con el session

agent.

ip-address número ipv4 o ipv6 acmesystem(session-agent)# Dirección Ip asociada entre realm y

session agent.

port 1025-65535 acmesystem(session-agent)# Puerto de seañalización asociado entre

realm y session agent.

app-protocol H.323, SIP acmesystem(session-agent)# Establece protocolo de señalización

asociado entre realm y session agent.

transport-method TCP, UDP acmesystem(session-agent)# Establece tipo de transporte asociado

entre realm y session agent.

B-3

Tabla B-1: Lista de comandos de equipo Acme Packet para solución de Load

Balancing (continuación)

ACME PACKET 4250 (LEAST COST ROUTING)

Tabla B-2: Lista de comandos de equipo Acme Packet para solución de LCR

Comando Modo Descripción

session-group acmesystem(session-router)# Habilita un session grupo, el cual asocia

los distintos session-agent para porder

realizar el proceso de elección

redundante a través del los algoritmos

presentados por los session-agent.

group-name nombre acmesystem(session-group)# Nombre que asocia el grupo con el local-

policy que establece la ruta estatica los

caminos redundantes

app-protocol H.323, SIP acmesystem(session-group)# Establece el protocolo de señalización

asociado al grupo de session-agent

strategy hunt, roundrobin, least busy,

Proportional distribution, Lowest

sustained rate

acmesystem(session-group)# establece el algoritmo de elección

redundante para el grupo en

configuración

dest nombre de sessions agents acmesystem(session-group)# Asocia una selección de sessions agents a

el grupo que contiene una estrategia de

elección redundante.

Comando Modo Descripción

local-policy acmesystem(session-router)# Habilita sesión de politica de envio

servicios telefónicos IP, es como una ruta

estatica de VoIP.

from-address valor numérico acmesystem(local-policy)# Establece filtro de origen de llamadas con

un prefijo numerico o pattern, sin filtro se

escribe *.

to-address valor númerico acmesystem(local-policy)# Establece filtro de destino de llamadas

con un prefijo numerico o pattern, sin

filtro se escribe *.

source-realm nombre de realm acmesystem(local-policy)# Asocia Realm al local policy

next-hop número ipv4 o ipv6 acmesystem(local-policy)# Ruta estatica VoIP luego de ser filtrado el

metodo sip empleado en el real asociado.

realm nombre de realm acmesystem(local-policy)# Realm asociado al destino de la ruta

estatica.

app-protocol SIP o H.323 acmesystem(local-policy)# Protocolo establecido en el segmento

donde trabaja el local-policy.

start-time 0000 - 2400 acmesystem(local-policy)# Filtra ruta estatica VoIP, por horario.

end-time 0000 - 2400 acmesystem(local-policy)# Filtra ruta estatica VoIP, por horario.

cost valor numérico acmesystem(local-policy)# Filtra ruta estatica VoIP, por csoto

asociado, previamente calculado por

algún estandar establecido, o medido con

alguna variable en al red.

B-4

ACME PACKET 4250 (VIRTUALIZACIÓN)

Tabla B-3: Lista de comandos de equipo Acme Packet para solución de

Virtualización

Comando Modo Descripción

local-policy acmesystem(session-router)# Habilita sesión de politica de envio

servicios telefónicos IP, es como una ruta

estatica de VoIP.

from-address valor numérico acmesystem(local-policy)# Establece filtro de origen de llamadas con

un prefijo numerico o pattern, sin filtro se

escribe *.

to-address valor númerico acmesystem(local-policy)# Establece filtro de destino de llamadas

con un prefijo numerico o pattern, sin

filtro se escribe *.

source-realm nombre de realm acmesystem(local-policy)# Asocia Realm al local policy

next-hop número ipv4 o ipv6 acmesystem(local-policy)# Ruta estatica VoIP luego de ser filtrado el

metodo sip empleado en el real asociado.

realm nombre de realm acmesystem(local-policy)# Realm asociado al destino de la ruta

estatica.

app-protocol SIP o H.323 acmesystem(local-policy)# Protocolo establecido en el segmento

donde trabaja el local-policy.

hostname nombre acmesystem(session-agent)# Nombre que asocia realm con el session

agent.

ip-address número ipv4 o ipv6 acmesystem(session-agent)# Dirección Ip asociada entre realm y

session agent.

port 1025-65535 acmesystem(session-agent)# Puerto de seañalización asociado entre

realm y session agent.

app-protocol H.323, SIP acmesystem(session-agent)# Establece protocolo de señalización

asociado entre realm y session agent.

transport-method TCP, UDP acmesystem(session-agent)# Establece tipo de transporte asociado

entre realm y session agent.

mm-in-realm disabled acmesystem(realm-config)# Habilita acomplamiento de realms

virtuales.

APÉNDICE C

MODO ACCESS/PEER

C-2

APÉNDICE C

MODO ACCESS/PEER

ACME PACKET 4250

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de

“Access/Peer”

Comando Modo Descripción

media-profiles "telephone-event PCMU" acmesystem(session-router)# Habilita al SBC con media G.711.

iwf-config acmesystem(session-router)# Habilita la interoperabilidad.

media-profiles "telephone-event PCMU" acmesystem(iwf-config)# Asocia el perfil de media a la

interoperabilidad en funcionamiento.

host-routes acmesystem(system)# Habilita rutas estaticas a nivel ip,

generalemte para establecer

administración del equipo, o para agregar

un equipo que esta fuera de la

numeración de red del gateway del SBC.

dest-network número ipv4 o ipv6 acmesystem(host-routes)# Establece ruta estatica a red.

netmask número ipv4 o ipv6 acmesystem(host-routes)# Establece mascara de ruta estatica.

gateway número ipv4 o ipv6 acmesystem(host-routes)# Establece nodo gateway para unirse a red

deseada.

local-policy acmesystem(session-router)# Habilita sesión de politica de envio

servicios telefónicos IP, es como una ruta

estatica de VoIP.

from-address valor numérico acmesystem(local-policy)# Establece filtro de origen de llamadas con

un prefijo numerico o pattern, sin filtro se

escribe *.

to-address valor númerico acmesystem(local-policy)# Establece filtro de destino de llamadas

con un prefijo numerico o pattern, sin

filtro se escribe *.

source-realm nombre de realm acmesystem(local-policy)# Asocia Realm al local policy

C-3

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de

“Access/Peer” (continuación)

Comando Modo Descripción

next-hop número ipv4 o ipv6 acmesystem(local-policy)# Ruta estatica VoIP luego de ser filtrado el

metodo sip empleado en el real asociado.

realm nombre de realm acmesystem(local-policy)# Realm asociado al destino de la ruta

estatica.

app-protocol SIP o H.323 acmesystem(local-policy)# Protocolo establecido en el segmento

donde trabaja el local-policy.

media-profile acmesystem(session-router)# Habilita un perfil de media

name "telephone-event" acmesystem(media-profile)# Palabra clave para G.711, recomendado

por acme packet

media-type audio, video, data acmesystem(media-profile)# Tipo de media.

payload-type 101 acmesystem(media-profile)# Valor estandar para realizar el peering

media con el equipo proveedor de

servicios.

transport RTP/AVP acmesystem(media-profile)# Protocolo usado para media.

parameters 0-15 acmesystem(media-profile)# Parametro estandar para comunicacion

con el core (call manager).

media-manager acmesystem(media-manager)# Habilita administración de media.

network-interface acmesystem(system)# Habilita interfaz a nivel de red.

name nombre de interfaz acmesystem(network-interface)# Nombre para asociar a interfaz a nivel

físico.

ip-address número ipv4 o ipv6 acmesystem(network-interface)# IP de interfaz física asociada.

netmask número ipv4 o ipv6 acmesystem(network-interface)# Mascara de red de interfaz física

asociada.

gateway número ipv4 o ipv6 acmesystem(network-interface)# Gateway asociado a intterfaz física,

generalmente en el mismo segmento IP.

hip-ip-list número ipv4 o ipv6 acmesystem(network-interface)# Habilita identificación de host, es decir

realizar ping.

icmp-address número ipv4 o ipv6 acmesystem(network-interface)# Habilita protocolo en la interfaz donde el

ip esta asociado, tambien para realizar

ping entre equipos.

phy-interface acmesystem(system)# Habilita interfaz a nivel físico.

name nombre de interfaz acmesystem(phy-interface)# Nombre de interfaz a nivel físico.

operation-type Media, Control,

Maintenance

acmesystem(phy-interface)# Tipo de tráfico que prevalecera en la

interfaz.

port 0,1,2,3 acmesystem(phy-interface)# Asocia perfil de interfaz física a conexión

ethernet del equipo, el numero depende

del modelo SBC, para modelo Acme

Packet 4250 son 4 puertos por slot.

slot 0,1 acmesystem(phy-interface)# Asocia perfil de interfaz física a grupo de

conexiónes ethernet del equipo, el

numero depende del modelo SBC, para

modelo Acme packet 4250, son 2 slot por

equipo.

C-4

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de

“Access/Peer” (continuación)

Comando Modo Descripción

realm-config acmesystem(media-manager)# Habilita un realm, el cual cumple la tarea

de unir todo los perfiles asociados a el en

las diferentes capas.

identifier nombre de realm acmesystem(realm-config)# Nombre del realm.

addr-prefix número ipv4 o ipv6 acmesystem(realm-config)# IP del realm, en caso de modo access con

SIP-NAT se debe asociar al ip de realm

destino.

network-interfaces nombre de interfaz acmesystem(realm-config)# Nombre de interfaz donde se asocia el

realm.

mm-in-realm disabled acmesystem(realm-config)# Habilita acomplamiento de realms

virtuales.

mm-in-network enabled acmesystem(realm-config)# Habilita acomplamiento de otras redes en

el mismo realm.

mm-same-ip enabled acmesystem(realm-config)# Habilita acomplamiento de otras

interfaces del SBC en el mismo realm.

mm-in-system enabled acmesystem(realm-config)# Habilita acomplamiento de otros SBC's en

el mismo realm.

sip-config acmesystem(session-router)# Habilita protocolo SIP en el SBC.

sip-interface acmesystem(session-router)# Pre-habilita protocolo SIP en un realm.

realm-id nombre de realm acmesystem(sip-interface)# Asocia interfaz a real a nivel de servicio

VoIP, con protocolo SIP.

sip-port acmesystem(sip-interface)# Habilita SIP en la interfaz a nivel de red.

address número ipv4 o ipv6 acmesystem(sip-port)# Direccion IP asociada a la interfaz física

donde existirá trafico SIP.

port 1025-65535 acmesystem(sip-port)# Puerto asociada a la interfaz física donde

existirá trafico SIP. Por defecto 5060

transport-protocol UDP. TCP acmesystem(sip-port)# Tipo de tranporte para SIP, por lo genral

es UDP.

allow-anonymous all, agent only, real-

prefix, registered, register-prefix

acmesystem(sip-port)# Filtro a traves del método de señalización

SIP, u origen del tráfico (realm).

steering-pool acmesystem(media-manager)# Habilita pool de puertos RTP, para media.

ip-address número ipv4 o ipv6 acmesystem(steering-pool)# Dirección asociada a interfaz para media.

start-port 0-65535 acmesystem(steering-pool)# Puerto de inicio de rango del pool.

end-port 0-65535 acmesystem(steering-pool)# Puerto de termino de rango del pool.

realm-id nombre de realm acmesystem(steering-pool)# Realm asociado a pool de media.

network-interface nombre de interfaz acmesystem(steering-pool)# Interfaz asociada a pool de media, a nivel

físico.

system-config acmesystem(system)# Habilita sistema SBc, base de toda

configuración

C-5

Tabla C-1: Lista de comandos de equipo Acme Packet para solución de

“Access/Peer” (continuación)

Comando Modo Descripción

hostname nombre acmesystem(system-config)# Identificador secundario de SBC,

opcional.

default-gateway número ipv4 o ipv6 acmesystem(system-config)# Dirección IP, donde converge todo el

direccionamiento por defecto.

sip-nat acmesystem(session-router)# Habilita NAT para una interfaz SIP.

realm-id nombre de realm acmesystem(sip-nat)# Asocia Realm al SIP-NAT

domain-suffix número ipv4 o ipv6 acmesystem(sip-nat)# Establece la ruta estática a nivel VoIP sin

necesidad de local-policy, protegiendo el

la red interior (core) empresarial, con las

cualidades de NAT

ext-proxy-address número ipv4 o ipv6 acmesystem(sip-nat)# Valor exigido por la configuración SIP-

NAT, puede ser cualquier ip que este

fuera del rango ocupado, amenos que se

posea dentro de la red un servidor proxy

externo, en tal caso poner ese IP.

ext-address número ipv4 o ipv6 acmesystem(sip-nat)# IP de interfaz externa a la red

empresarial, que acepta método register,

para registrar un teléfono SIP

ext-proxy-port 1025-65535 acmesystem(sip-nat)# Valor de puerto establecido externo a la

red de la empresa

headers Call-ID Contact f From i Join m r

Record-Route Refer-To Replaces Reply-To

Route t To v Via

acmesystem(sip-nat)# Cabecera estandar para establecer la

regla de "nateo" a nivel VoIP