memoria final sip-trunk en sbcdocshare03.docshare.tips/files/9203/92031778.pdf · 3.3 principales...
Post on 02-May-2018
222 Views
Preview:
TRANSCRIPT
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
top related