1 Fundamentos de Telefonía y Soporte de productos de Telefonía IFX Networks Enero 2009 Investigación y Desarrollo Sebastián Averbuj y Fernando Dorna

2 Objetivo Conocer el funcionamiento, arquitectura e ingenieria global de la implementacion y funcionamiento de la plataforma V3.

3 Agenda Plataforma V3. ¿Que es Hosted PBX? Componentes de la arquitectura y Funciones de cada uno de los Servidores. Servicios brindados con V3. Ingeniería Global de la solución.

4 Plataforma V3 V3 surgió como la nueva plataforma de VoIP de IFX en el año 2004, ya existía Vanguard y Hablanow como plataformas de voz que estaban destinadas a tomar el mercado masivo y de partners. La plataforma V3 con la que se brinda entre otros servicios como Hosted PBX o líneas corporativas, esta diseñada para ser totalmente redundante, cada servidor, dispositivo de acceso, switch o router interviniente esta redundado para obtener una muy alta disponibilidad de servicio.

5 La estructura de diseño nos permite brindar un servicio de telefonía hosteado altamente confiable y escalable y su diseño redundante permite obtener un 99.999 % de confiabilidad. Las características principales son: SOFTSWITCH NAT TRANSVERSAL CLUSTER VOICE APPLICATION CLUSTER PROVISIONING & BILLING     Interfaz XML para integrar sistemas de IFX con sistemas del Cliente Credit mngmt, acount mngmt, Fault mngmt, Sist. de Aprovisionamiento Maneja servicios como VoiceMail, Call Forwarding /Call pick up Enruta llamadas on net Soporte de protocolos SIP, MGCP y SCCP Resuelve problemática VOIP en entornos de IP Privadas Realiza enrutamiento de llamadas. ASR, Fallback Routing Soporte de protocolos H323, SIP, MGCP, IPDC y SS7

6 Estos son los tres pilares que componen el servicio de telefonía de IFX. Es necesaria la intervención de todos ellos para poder brindar el servicio en forma correcta. Componentes del Servicio de Telefonía

7 ¿Que es Hosted PBX? Hosted PBX es simplemente uno de los servicios que se ofrecen en V3, al igual que este, existen muchos otros servicios a brindar sobre la plataforma que están destinados a distintos segmentos y necesidades de los clientes. Hosted PBX es el producto nativo de la plataforma V3, pero debido a la flexibilidad que nos brinda esta, nos es posible brindar varios servicio y adaptar desarrollos propios a las necesidades o requerimientos del mercado.

8 Componentes de la Arquitectura Enero 2009 Investigación y Desarrollo Sebastián Averbuj y Fernando Dorna

9 Componentes de la Solución La siguiente sección describe y analiza como es el funcionamiento de cada uno de los servidores que componen la solución de la plataforma. Application Servers – Realizan el procesamiento y control de las llamadas, provee servicios avanzados de PBX. Database Agent – Administra y almacena los datos de clientes, rutas, servicios, pbx creadas, rutas, gateways, etc. Session Border Controller – son el punto de acceso para las redes externas, cumplen básicamente 2 funciones: º Brinda servicios de Firewall para proteger los servidores del inside, º Resuelve problemas de Transversal NAT realizando proxy de la señalización y el audio. Web Server – provee soporte para aplicaciones como webportal y voiss assistant. Streamers Servers– proveen funciones como reproducción de anuncios, grabación de mensajes. DTMF Proxy Servers - generan y traducen los tonos DTMF enviados en el fluyo RTP. Conference Server – provee servicios de conferencias Ad-Hoc y Meet-me. Rating System.TERAS – Lógica externa que realiza funciones de control de saldo y tasación de llamadas en tiempo real. Es un desarrollo inhouse.

10 Application Servers. (AS0 y AS1) Los Application Servers (AS) o Call Agents son los encargados de manejar toda la señalización para establecer, mantener y finalizar sesiones multimedia, corren en servidores SUN V240 con Sistema Operativo Solaris 10. √ Los Application Servers interactúan con todos los servidores (SBCs, Streamers, DTMF Proxys) de la plataforma a través de un protocolo propietario de BroadSoft llamado SDCP (Simple Device Control Protocol) √ Poseen la inteligencia del enrutamiento y la capacidad de brindar los servicios avanzados de una PBX. √ Generan y almacenan los CDRs (Call Detail Record) y el envió de traps para el monitoreo mediante SNMP. √ Las funciones de control de la Señalización de los AS están diseñadas para soportar varios protocolos para el control de sesiones de voz y video, entre los que se encuentran: ● SIP. Session Initiation Protocol (RFC 3261) ● MGCP. Media Gateway Control Protocol (RFC 3435) ● SCCP. Skinny Client Control Protocol, propietario de Cisco.

11 Session Border Controllers. (SBC0 y SBC1) Los Session Border Controllers o Voice Proxy Firewalls son dispositivos que manejan las sesiones entrantes y salientes a la plataforma y controlan el acceso delimitando la frontera entre la red externa y la interna. Estos equipos tienen varias funciones que se explican a continuación: ● Funcionamiento es siempre en cluster 1+1. ● SBCs soportan múltiples protocolos de Señalización y control de comunicaciones voip (SIP, MGCP, SCCP) ● Política de BlackList. ● Solucionan la problemática del NAT transversal cuando intervienen firewalls. ● Actúan como proxy de la señalización y el RTP. ● Corren en servidores Intel TSRLT2 o TIGPRU2, con S.O. VxWorks que se encuentra cargado en una flash card

12 Base de Datos. (DB0) La Base de Datos es el centro de todo el repositorio de información de usuarios, servicios, rutas y clientes en la plataforma, interactúa continuamente con los Application Servers para consultas y como fuente de información, al igual que los AS, corre en servidores SUN V240 con Sistema Operativo Solaris 10. La base de datos utilizada es TimesTen de Oracle y posee las siguientes características: √ Infraestructura de Tiempo Real √ Baja latencia, puede manejar un alto volumen de datos, eventos y transacciones √ Alta performance y disponibilidad √ Usa tecnología de acceso a memoria para realizar el procesamiento en forma mucho mas dinámica y rápida √ Alto throughput y muy bajos tiempos de respuesta

13 Streamers Servers y DTMF Proxys. (SS y DP) ● Los Streamers Servers, son dispositivos que manejan el fluyo RTP para poder realizar funciones como la reproducción y grabación de anuncios, mensajes de voice mail, Do not Disturb o Music on Hold. ● Los DTMF Proxys son servidores que se encargan de detectar y traducir los tonos generados por dispositivos CPEs como teléfonos analógicos o IP Phones. Los DP detectan cualquier señal DTMF (Dual Tone Multi-Frecuency) enviada inband en el fluyo RTP que son codificados usando RFC 2833 o Cisco-RTP y luego enviados a los Application Servers para ser procesada. √ Ambos servidores funcionan en pares por redundancia N + 1 √ Se comunican con los Application Servers a través protocolo SDCP (Simple Device Control Protocol), propietario de BroadSoft √ Corren en servidores Intel TSRLT2 o TIGPRU2, con S.O. VxWorks que se encuentra cargado en una flash card

14 Web Server y Voice Mail Server. (WS0 y VM0) ● El web server corre en un Apache Tomcat y se encarga de proveer acceso a herramientas web como webportal y voiss assistant desde las cuales se puede interactuar con la plataforma de telefonía para realizar acciones como realizar y contestar llamadas, escuchar voice mails, configurar features clase 5 como call forward, do not disturb, virtual ring, etc. ● El Voice Mail Server realiza principalmente funciones de almacenamiento de los voice mails e interactúa con el web server y los Application Servers para poder revisar los mensajes de voz utilizando un teléfono, desde el webportal o directamente vía POP3 o IMAP. El voice mail server usa un servidor Stalker que provee una plataforma para el almacenamiento y redireccionamiento de e-mails en tiempo real. Una de las principales funciones de Stalker es actuar como un MTA (Mail Transfer Agent), el servidor acepta mensajes desde varios orígenes y los envía a diversos destinos locales o remotos.

15 Conference Server. El Convedia CMS-1000 es el dispositivo utilizado en la solución que realiza funciones de Media Server y Conference Server con una alta disponibilidad y performance. Posee diversas capacidades de procesamiento como la generación de anuncios, detección y generación de DTMF, transcoding, procesamiento de la voz y reproducción y grabación de mensajes. Es controlado por una lógica de servicio que reside en un Call Agent como un Softswitch o un Application Server, en nuestro caso los AS de V3. Soporta diversos protocolos como: √ SIP (Session Initiation Protocol) o MGCP (Media Gateway Control Protocol) √ Voice XML, MSML (Media Sessions Markup Language), MOML (Media Objets Markup Languages) √ Tiene la capacidad de manejar hasta 100 canales de voz simultáneos para conferencias programadas o ad-hoc.

16 IPIPGW El IP to IP gateway es una aplicación integrada de hardware y software propietarios de Cisco que realiza varias funciones de voz y video, nos ofrece una solución simple que provee demarcación entre redes para el interworking de la señalización y el media, traducción de direcciones y puertos, seguridad, tasación, calidad de servicio y administración de ancho de banda. Puntualmente el IP to IP usado es un Cisco 2821 con sistema operativo IOS que posee dos interfaces Gigabit Ethernet. Estas dos interfaces están conectadas (lógicamente) una al inside de la plataforma y la otra al outside de la misma para que las llamadas fluyan directamente hacia el IP to IP y este pueda enviarlas a la telco, cliente o ITSP destino.

17 TERAS. TElephony RAting System & Call Control System ● TERAS es un sistema desarrollado inhouse, basado en.NET + MS SQL Server, es el sistema de Rating Telefónico de IFX que permite autenticar y tasar servicios telefónicos de valor agregado como servicios de Hosted PBX o líneas corporativas. Todos los servicios son administrados por una cuenta asociada al servicio. Esta cuenta esta compuesta de los planes de pago (Plano, Prepago, Postpago). Debido a la arquitectura con la que se desarrollo TERAS y la flexibilidad de su funcionamiento es posible brindar varios tipos de servicios, entre ellos: √ EndPoints √ Dialtone √ CallingCards ● El sistema de control de llamadas es también un desarrollo inhouse, realizado íntegramente en lenguaje C que interactúa a través de una API con la plataforma V3 para manejar todas las transacciones y eventos que desde allí se originan y por otro lado interactuar con TERAS, en base a eso puede tomar decisiones de enrutamiento de las llamadas, bloqueos, colocar anuncios, etc El sistema de control de llamadas administra el ciclo de vida de una llamada saliente, ya sea on-net o hacia la PSTN, dentro de sus funciones están: ● Validación de usuario basada en el ANI o interactuando con esquemas de IVR, ● Validación del estado (activo/suspendido) de los usuarios y el saldo disponible, ● Reproducción de anuncios variados como advertencias de bajo crédito o crédito insuficiente, ● Cálculo de la duración máxima de la llamada en base a la lista de precios que tiene aplicada la cuenta, ● Generación de CDRs y modificación del balance de la cuenta una vez que la llamada fue finalizada, ● CDRs con los detalles de la liberación de cada llamada y remaining balance.

18

19 PROVISIONING SERVER El Provisioning Server es, al igual que TERAS, un desarrollo inhouse que se creo con la necesidad de poder hacer mas flexible, útil y rápida la configuración y aprovisionamiento de cada uno de los endpoints que se deben instalar. Íntegramente desarrollado en.NET y utilizando una base de datos MS SQL Server, el Provisioning System nos da la flexibilidad que necesitamos para poder hacer del aprovisionamiento un paso muy simple.

20 El login en el Provisioning Server se realiza desde: http://prov.telco-carrier.com, desde allí se puede hacer el autoaprovisionamiento en forma automática, para ello debemos tener acceso web contra el endpoint y contra el provisioning server. Si el endpoint esta dado de alta en forma correcta en el sistema, mediante un pedido HTTP el Provisioning le enviara la información de la configuración al equipo validándose por la mac address del endpoint.http://prov.telco-carrier.com

21 ABMs en el Provisioning El sistema cuenta con una estructura que nos permite poder realizar la configuracion de muchos parámetros en los endpoints, desde usuario/password de registracion, hasta la activación de servicios avanzados, TOS, DTMF Method, etc. Todos estos cambios se realizan en forma directa sobre “Templates” definidos en el sistema, es por ello que cada dispositivo homologado posee un template en el Provisioning Server que hace referencia a distintas variables que se completan a mano por el operador, estas variables son básicamente los datos de usuario/password de registracion de las líneas.

22 Descripción de las opciones y funciones en el Provisioning Server, El sistema nos da la flexibilidad de poder configurar: √ Servicios: Se define el nombre y el SIP Server contra el cual señalizaran los endpoints; √ Clientes: Se define el cliente, es información pasiva, no hace al funcionamiento del servicio; √ Reportes: Se pueden listar y exportar reportes de cada uno de los endpoints creados, por servicio y por cliente.

23 Como funciona el dial-plan en los gateways Como en todos los gateways de voip, el dial-plan hace referencia al modo de discado que se puede definir, la utilidad de esto es acotar la posibilidad y disminuir el time-out a la hora de realizar una llamada. La gran parte de los equipos de voip que están implementados en la plataforma V3 son Linksys/Sipura y estos equipos manejan un dial-plan particular que se explicara a continuación. El método que se usa es el de acotar los posibles números discados, por ejemplo, √ Las llamadas locales en Santiago son del tipo: 2 - 9 + 6 dígitos Ejemplo: 2335000 Por lo que en el dial-plan esa entrada se contemplaría de la siguiente forma: [2-9]xxxxxx √ Otro ejemplo es el discado a números móviles: 09 + 7,8,9 + 7 dígitos Ejemplo: 09 93214567 Por lo que en el dial-plan esa entrada se contemplaría de la siguiente forma: 09[789]xxxxxxx √ Otra cosa importante a considerar es el uso de timers y otros caracteres especiales, por ejemplo: * El uso de la, (coma) es para que el equipo genere un tono de discado directamente. Esto se usa para simular el tono que entrega una PBX convencional luego de que se marca un digito para realizar una llamada saliente. Ej.: 9, 2335000 * El uso de caracteres como S tienen como función agregar o disminuir el time out que se generara para realizar la llamada, y el motivo de su utilización es para diferenciar algunos strings que pueden llegar a ser similares. Ej: 9, 2xxxxxxS1 * Otros caracteres utilizados son: * como *xx para el uso de *09 (acceso al voice mail) || son utilizados para separar cada una de los strings, Ej: (9, [2-9]xxxxxx|9, 09[789]xxxxxxx|0S0) [ ] son utilizados para agrupar dígitos comunes. Ej: [789]xxxxxxx ( ) se utilizan en el inicio y fin de la cadena completa que forma parte del dial-plan.

24 Servicios Brindados en la Plataforma Enero 2009 Investigación y Desarrollo Sebastián Averbuj y Fernando Dorna

25 Servicios Brindados en V3 La plataforma nos da una gran flexibilidad, esto sumado a la posibilidad que nos ofrece a través de una API de interactuar con lógicas o sistemas externos hace que la diversidad de productos y desarrollos a ofrecer sea muy grande. Los servicios brindados en la plataforma se detallan a continuación: 1º Hosted PBX. Este servicio es el nativo, a través de la creación de PBX virtuales en V3 se brinda este servicio con el que se ofrecen todas las funcionalidades básicas de una central tradicional y además muchos features nuevos como la integración y la movilidad. Ej: CaribeVision (USA), Karibel (Chile) 2º Telefonía Residencial. Los servicios residenciales apuntan al segmento masivo, cada cliente dispone de una línea independiente. Ej: PRIMA (Argentina) 3º HablaShop. El servicio de HablaShop se basa en la utilización de una web desde la que se pueden monitorear/administrar cada una de las cabinas de un locutorio. El operador puede ver el detalle de llamadas y el precio asociado a las comunicaciones realizadas en tiempo real. Ej: DavidR (Panamá) 4º Calling Cards. Este servicio al igual que la telefonía residencial también esta destinado al segmento masivo. En este caso las llamadas son validadas por un lógica de control en la que se verifica si el PIN es valido y si el cliente posee el saldo suficiente para llamar al destino marcado. Ej: Salcobrand (Chile) 5º Hosted CallCenter. HCC es una aplicación web que permite monitorear el estado de todos los agentes definidos en el Call Center, a través de la API podemos verificar y mostrar cada uno de los eventos de las llamadas que están ingresando al Call Center. Ej: CCC Soporte (Colombia)

26 Hosted PBX

27 Servicios Residenciales

28 Interoffice

29 HablaShop

30 CallingCards

31 Hosted Call Center

32 Ingenieria Global de la Solución Enero 2009 Investigación y Desarrollo Sebastián Averbuj y Fernando Dorna

33 Diagrama de Alto Nivel En la actualidad, la plataforma V3 se encuentra distribuida entre Argentina, USA y Panama. En cada POP existe un par de SBCs (Session Border Controllers) que son el punto de conexión entre los clientes y el M6. Según la ubicación física del cliente se opta por uno u otro acceso. Una de las funciones de los SBCs es la de “topology hiding” que consiste en ocultar toda la infraestructura de la solución detrás de un sola dirección IP.

34 Overview M6

35 En un principio, USA sólo disponía de un par de SBCs para brindar servicio a los clientes de la zona norte (los SBCs generalmente poxean audio, a no ser que se active el feature “short- circuit”). Luego, y por conveniencia, se instalaron los siguientes componentes: *Server de conferencias (Convedia CMS-1000). *IP2IPGW (cisco 2821) para interfacear con los carriers de telefonía. *Streamer/DTMF Proxy

36 Visibilidad entre VRFs

37 Ingeniería en Detalle

38 Diagrama Global de Trafico

39 ANEXO I Procesos VOISS. START / STOP: [root@v3as0 /]# cd /etc/rc3.d [root@v3as0 rc3.d]# ls -ltr *voiss lrwxrwxrwx 1 root other 22 Jul 15 2004 S99voiss -> /etc/init.d/voiss.init* [root@v3as0 rc3.d]# Verificando que esté corriendo: [admin@v3as0 admin]$ ps -ef | grep voiss voiss 15804 260 0 Sep 18 ? 92:21 /usr/voiss/bin/voiss root 15805 260 0 Sep 18 ? 0:00 /usr/voiss/bin/voiss root 260 1 0 Sep 13 ? 0:00 /usr/voiss/bin/voiss UDP. 161 y 162 SNMP 2427 MGCP 5060 y 5062 SIP 29051 control del RP TCP. 22 acceso SSH 1050 comunicación contra webportal 29042 sincronización entre CAs 29043 debug del CA 2000 SCCP CDRs. /usr/voiss/System/CDRFile.frf – cierre diario, escritura doble buffer Eventos: /usr/voiss/System/EventLog.txt Errores: /usr/voiss/System/Errlog.log

40 TimesTen DataBase. START / STOP: [root@v3db0 /]# cd /etc/rc2.d [root@v3db0 rc2.d]# ls -ltr *tt* lrwxrwxrwx 1 root other 21 Aug 10 06:21 S90tt_ifx_v3 -> /etc/init.d/tt_ifx_v3* [root@v3db0 rc2.d]# Verificando que esté corriendo: [root@v3db0 rc3.d]# ps -ef | grep Times root 192 189 0 Aug 10 ? 0:01 /opt/TimesTen/ifx_v3/bin/timestensubd -verbose -id 2 -facility user root 190 189 0 Aug 10 ? 0:01 /opt/TimesTen/ifx_v3/bin/timestensubd -verbose -id 0 -facility user root 189 1 0 Aug 10 ? 0:08 /opt/TimesTen/ifx_v3/bin/timestend -initfd 13 root 191 189 0 Aug 10 ? 0:01 /opt/TimesTen/ifx_v3/bin/timestensubd -verbose -id 1 -facility user root 193 189 0 Aug 10 ? 1:04 /opt/TimesTen/ifx_v3/bin/timestensubd -verbose -id 3 -facility user root 194 189 0 Aug 10 ? 0:01 /opt/TimesTen/ifx_v3/bin/ttcserver -verbose -id 4 -p 15102 -facility user DB Agent Software. START / STOP: [root@v3db0 rc2.d]# cd /etc/rc3.d [root@v3db0 rc3.d]# ls -ltr S*apa* lrwxrwxrwx 1 root other 24 Aug 10 06:35 S98apache -> /etc/init.d/apachetomcat* [root@v3db0 rc3.d]# Verificando que esté corriendo: [root@v3db0 rc3.d]# ps -ef | grep java root 274 1 0 Aug 10 ? 193:44 /usr/j2sdk1.4.2_06/bin/java -server -Xmx512M -Xms384M -Xrs -XX:+UseParallelGC - [root@v3db0 rc3.d]#

41 UDP -123 ya que actúa como NTP server para el resto de los equipos TCP -29047 conexiones locales para administración de opciones de la DB -29044 conexiones desde ambos CAs para sincronizar información. -80 Para Admin GUI -22 acceso al server via SSH -15100 y 151022 para TT DB Logs útiles Errores de TimesTen: /var/adm/syslog/syslog.log Provisionamiento: /usr/voiss/dbagent/serviceslog Errores DB Agent: /usr/voiss/dbagent/dbagentlog Apache Tomcat. START / STOP: [[root@v3ws0 /]# cd /etc/rc3.d [root@v3ws0 rc3.d]# ls -ltr S*apa* lrwxrwxrwx 1 root other 24 Aug 10 09:05 S98apache -> /etc/init.d/apachetomcat* [root@v3ws0 rc3.d]# Verificando que esté corriendo: [root@v3ws0 /]# ps -ef | grep java root 251 1 0 Aug 10 ? 8:26 /usr/j2sdk1.4.2_06/bin/java -server -Xmx512M -Xms384M -Xrs -XX:+UseParallelGC - [root@v3ws0 /]#

42 Stalker (mail server) START / STOP: [root@v3vm0 /]# cd /etc/rc2.d [root@v3vm0 rc2.d]# ls -ltr S*Commu* lrwxrwxrwx 1 root other 24 Aug 10 09:35 S88CommuniGate ->../init.d/STLKCGPro.init* [root@v3vm0 rc2.d]# Verificando que esté corriendo: [root@v3vm0 rc2.d]# ps -ef | grep CG root 175 1 0 Aug 10 ? 11:19 /opt/CommuniGate/CGServer --Base /var/CommuniGate --Daemon [root@v3vm0 rc2.d]# TCP. 22 acceso SSH 25 SMTP 143 IMAP 1050 comunicación con v3ws0 8010 Stalker Admin

43  Fernando Dorna Director I+D [email protected] +54 11 5031 2405  Sebastian Averbuj Systems Engineer [email protected] +54 11 5031 2422 Contactos