Fundamentos de Telefonía y

Soporte de productos de Telefonía

IFX Networks

Agosto 2008
Investigación y Desarrollo
Sebastián Averbuj y Fernando Dorna
 Objetivo

• Conocer el funcionamiento, arquitectura e

ingenieria global de la implementacion y
funcionamiento de la plataforma V3.
 Agenda
•Plataforma V3. ¿Que es Hosted PBX?

•Componentes de la arquitectura y Funciones

de cada uno de los Servidores.

•Servicios brindados con V3.

•Short Circuit. Funcionamiento.

•Ingeniería Global de la solución.

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

PROVISIONING & BILLING  Interfaz XML para integrar sistemas de IFX con sistemas del Cliente
Credit mngmt, acount mngmt, Fault mngmt, Sist. de Aprovisionamiento

VOICE APPLICATION
CLUSTER
 Maneja servicios como VoiceMail, Call Forwarding /Call pick up
Enruta llamadas on net
Soporte de protocolos SIP, MGCP y SCCP

NAT TRANSVERSAL
CLUSTER  Resuelve problemática VOIP en entornos de IP Privadas

SOFTSWITCH  Realiza enrutamiento de llamadas.

ASR, Fallback Routing
Soporte de protocolos H323, SIP, MGCP, IPDC y SS7
 Componentes del Servicio de Telefonía

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.
 ¿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.
 Componentes
de la
Arquitectura

Agosto 2008
Investigación y Desarrollo
Sebastián Averbuj y Fernando Dorna
 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.
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 V120 con Sistema Operativo Solaris 8.

√ Los Application Servers interactúan con todos los servidores (SBCs, Streamers, DTMF Proxys) de la plataforma a través de un
protocolo propietario de Genband 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.
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, con S.O. VxWorks que se encuentra cargado en una flash card
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 V120 con Sistema Operativo Solaris 8.
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
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
GENBAND
√ Corren en servidores Intel TSRLT2, con S.O. VxWorks que se encuentra cargado en una flash card
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.
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.
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.
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.
 Servicios
Brindados
en la
Plataforma
Agosto 2008
Investigación y Desarrollo
Sebastián Averbuj y Fernando Dorna
 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)
Hosted PBX
Servicios Residenciales
Interoffice
HablaShop
CallingCards
Hosted Call Center
 Short Circuit

Agosto 2008
Investigación y Desarrollo
Sebastián Averbuj y Fernando Dorna
 Short Circuit
El feature Short Circuit permite que el Session Border Controller de Genband pueda indicarle a dos endpoints que conecten el
stream RTP en forma directa sin la necesidad de pasar a través de ellos.

Short Circuit también permite que dos teléfonos que se encuentran detrás del mismo firewall puedan conectarse entre ellos en
forma directa sin pasar por el SBC.

Esta particularidad reduce la carga en los Session Border Controllers y el tráfico en los enlaces desde los clientes y la ubicación en
la que están alojados los SBCs.

Detalles del funcionamiento

Existen tres escenarios donde Short Circuit es soportado:

● Port Address Translation (PAT).

● Network Address Translation (NAT).

● Servicio Residential, sin firewall.

 Short Circuit con Port Address Translation
(PAT)

En este escenario, como se muestra aquí, cuando se da una implementación donde se este usando PAT detrás de un router o
firewall, la dirección publica del firewall es usada por todos los endpoints que se encuentran detrás.
Cada endpoint es identificado por un numero de puerto relacionado con la dirección IP, por ejemplo: 200.80.40.231:5334.

La señalización de la llamada va desde el firewall o router contra el Session Border Controller del M6 el cual le indica al gateway
que debe conectar el RTP de ambos teléfonos en forma directa usando las direcciones <IP: Port>.
 Short Circuit con Network Address Translation (NAT)

Cuando se da un escenario usando NAT detrás de un router o firewall, cada dispositivo tiene una dirección ip única del rango de la
LAN y además en el router o firewall se configura un mapeo estático de la ip privada a la ip publica con la que accederán al exterior
de la red.

En este tipo de escenarios hay que tener la certeza de que el firmware que esta usando el firewall o router esta aplicando en forma
correcta la función de NAT y no esta traduciendo la direcciones publicas por las locales, para poder ver esto se debe analizar la
señalización SIP de una llamada, puntualmente las direcciones que se muestran en el campo sip.contact dentro de la mensajeria
SDP.
 Residencial Short
Circuit

Short Circuit también puede ser implementado entre teléfonos residenciales que no se encuentren detrás de un firewall.

En este escenario, los Session Border Controllers que tienen visibilidad con ambos endpoints entre los que se realizara la
comunicación indican que el stream RTP se intercambie en forma directa ente ambos.
 Ingenieria
Global
de la
Solución
Agosto 2008
Investigación y Desarrollo
Sebastián Averbuj y Fernando Dorna
 Diagrama de Alto Nivel

En la actualidad, la
plataforma V3 se encuentra
distribuida entre Argentina y
USA.

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.
Overview M6
 Overview M6

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.
Visibilidad entre VRFs
Ingeniería en Detalle
Diagrama Global de Trafico
 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 CDRs.
2427 MGCP /usr/voiss/System/CDRFile.frf – cierre diario,
5060 y 5062 SIP escritura doble buffer
29051 control del RP Eventos: /usr/voiss/System/EventLog.txt
Errores: /usr/voiss/System/Errlog.log
TCP.
22 acceso SSH
1050 comunicación contra webportal
29042 sincronización entre CAs
29043 debug del CA
2000 SCCP
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]#
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 /]#
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
 Contactos
 Fernando Dorna
Systems Engineer
fdorna@ifxcorp.com
+54 11 5031 2405

 Sebastian Averbuj
Systems Engineer
saverbuj@ifxcorp.com
+54 11 5031 2422