Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Universidad Simón Bolívar
Universidad Simón Bolívar
por
Octubre, 2009
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS DE POSTGRADO
COORDINACIÓN DE POSTGRADO EN INGENIERÍA ELECTRÓNICA
ESPECIALIZACIÓN EN TELEMÁTICA
ESPECIALISTA EN TELEMÁTICA
Octubre 2009
ii
__________________________________
Profa. Vidalina De Freitas
Presidente
__________________________________
Profa. Mónica Huerta
Miembro Principal
__________________________________
Prof. Wilmer Pereira
Miembro principal – Tutor
DEDICATORIA
A mis padres y muy especialmente a mi esposo, quienes con amor y paciencia cedieron gran
parte del tiempo que les correspondía de mí, para que hiciera posible este trabajo.
iv
AGRADECIMIENTOS
A Dios por guiarme todo el tiempo y traerme devuelta al camino cada vez que quería
abandonar.
A mi hermanita linda que pacientemente esta esperando que termine para poder compartir con
la nueva bendición de la familia.
A Maria Miguelina, por toda la orientación, solidaridad y amistad prestada para culminar este
trabajo… ahora te toca a ti, amiga!
A todas las personas que sin saberlo fueron fuente de inspiración y me ayudaron a concretar
este trabajo.
v
RESUMEN
Servinave, C.A. es una empresa de servicios dedicada al agenciamiento naviero y consta de
una oficina central y siete sucursales ubicadas geográficamente en estados distintos. El
sistema de comunicación de voz que utiliza la empresa es telefonía convencional a través de
centrales telefónicas básicas cuyos modelos, en general, ya están descontinuados. Con el
auge de Internet se han desarrollado muchas aplicaciones, modelos, servicios y tecnologías,
entre ellas tenemos, Voz sobre IP, tecnología ésta que se desea aprovechar para diseñar una
solución de Telefonía IP basada en software libre, que le permita a Servinave, C.A., desde el
punto de vista técnico, actualizar la plataforma de telefonía e integrar la infraestructura del
cableado de voz y datos, garantizando un servicio confiable, seguro, portable, de calidad y
fácil gestión que simplifique las comunicaciones de la empresa con sus sucursales y clientes.
Desde el punto de vista económico, se espera una reducción en los costos, manteniendo la
calidad de servicio igual o superior a la acostumbrada y la generación de nuevos servicios, a
un costo de inversión razonable. En otras palabras, converger ambas formas de tráfico sobre
una sola red para restar gastos y complejidad. Este diseño trabajará con una distribución del
Sistema Operativo GNU/ Linux y con el software de PBX Asterisk, por ser sistemas de
fuente abierta ampliamente aceptados en el mercado. La investigación está enmarcada en la
modalidad de proyecto factible, y las etapas que se van a seguir van desde la formación en la
plataforma Asterisk, diagnóstico de la situación actual, identificación de los componentes de la
red convergente deseada hasta culminar con el diseño de la propuesta.
Palabras claves: PBX, VoIP, Telefonía IP, Convergencia de Redes, Software Libre.
vi
ÍNDICE GENERAL
Pág.
APROBACIÓN DEL JURADO ……………………………………………………………….ii
DEDICATORIA........................................................................................................................ iii
AGRADECIMIENTOS..............................................................................................................iv
RESUMEN ..................................................................................................................................v
ÍNDICE DE TABLAS.................................................................................................................x
ÍNDICE DE FIGURAS ............................................................................................................ xii
LISTA DE SÍMBOLOS Y ABREVIATURAS ....................................................................... xii
INTRODUCCIÓN.......................................................................................................................1
CAPÍTULO I: EL PROBLEMA .................................................................................................3
1.1 Planteamiento del Problema...............................................................................................3
1.2 Justificación.......................................................................................................................4
1.3 Objetivos del Trabajo .........................................................................................................6
1.3.1 Objetivo General………………………..……..…………………………………...6
1.3.2 Objetivo Específicos………………………………………………………………..6
CAPÍTULO II: MARCO TEÓRICO...........................................................................................7
2.1 Redes Conmutadas .............................................................................................................7
2.1.1 Conmutación de Circuitos………………………………………………………….7
2.1.2 Conmutación de Paquetes…………………………………………………………..8
2.2 Descripción General de la Red Telefónica Convencional ...............................................10
2.2.1 Señalización……………………………………………………………………….12
2.2.1.1 Señalización Abonado a Red………………………………………………...13
2.2.1.2. Señalización entre Centrales……………………………...………………....15
2.3 Redes IP…………………………………………………………………………………15
2.4 Voz Sobre IP (VoIP)………………………………...…………………………………..18
2.5 Telefonía IP ......................................................................................................................19
vii
ÍNDICE DE TABLAS
Tablas Pág.
1. 1 Equipamiento de Telefonía de Servinave.............................................................................4
2. 1 Comparación de Técnicas de Conmutación ......................................................................10
2. 2 Indicadores de QoS para VoIP ..........................................................................................28
2. 3 Ejemplo de una Solicitud SIP............................................................................................44
2. 4 Ejemplo de Mensaje de Respuesta ....................................................................................45
2. 5 Cálculo Consumo de Ancho de banda por CODEC.........................................................55
2. 6 Fórmulas para Cálculos de Consumo por CODECs.........................................................55
2. 7 Resumen de la Sobrecarga Generada por Encabezados ....................................................56
2. 8 Desglose de la Sobrecarga de la Cabecera Ethernet........................................................57
4. 1Respuesta de las Entrevistas ...............................................................................................72
4. 2 Líneas Contratadas ............................................................................................................73
4. 3 Distribución de Teléfonos por Oficina ..............................................................................74
4. 4 Resumen de llamadas desde Oficina Caracas...................................................................75
4. 5 Resumen de llamadas desde Oficina Puerto Cabello .......................................................75
4. 6 Resumen de llamadas desde Oficina La Guaira ..............................................................75
4. 7 Resumen de llamadas desde Oficina Maracaibo ............................................................76
4. 8 Resumen de llamadas desde Oficina Valencia ................................................................76
4. 9 Resumen de llamadas desde Oficina Cumaná.................................................................76
4. 10 Resumen de llamadas desde Oficina Puerto La Cruz....................................................77
4. 11 Resumen de llamadas desde Oficina Punto Fijo ...........................................................77
4. 12 Características de los Switches de Servinave, C.A. ........................................................78
4. 13 Protocolos Activos en la Red Lan/Wan...........................................................................79
4. 14 BHT de CCS, La Guaira y Puerto Cabello....................................................................82
4. 15 Cantidad de Canales por Oficina ....................................................................................82
xi
ÍNDICE DE FIGURAS
Figuras Pág
2. 1 Jerarquía de nodos de conmutación...................................................................................11
2. 2 Señalización de una llamada de voz ..................................................................................14
2. 3 Modelo de Referencia OSI ................................................................................................16
2. 4 Comparación entre las arquitecturas OSI y TCP/IP ..........................................................18
2. 5 Proceso de conversión de una señal ..................................................................................20
2. 6 Fuentes de retraso en la red ...............................................................................................27
2. 7 Pila de protocolos H323 ....................................................................................................30
2. 8 Elementos funcionales de un terminal H.323....................................................................31
2. 9 Establecimiento de una llamada en H.323 ........................................................................33
2. 10 SIP y RTP Viajan por Caminos Diferentes ...................................................................36
2. 11 Pila de Protocolos SIP .....................................................................................................37
2. 12 UAS y UAC.....................................................................................................................39
2. 13 Servidor de Registro ........................................................................................................41
2. 14 Servidor de redirección....................................................................................................41
2. 15 Solicitudes y respuestas SIP ............................................................................................42
2. 16 Proceso de una llamada SIP.............................................................................................47
2. 17 Proceso de una llamada IAX ...........................................................................................50
2. 18 Arquitectura de Asterisk..................................................................................................60
2. 19 Flujo de una llamada generada por un SIP UA ...............................................................62
4. 1 Calculadora de Ancho de banda ........................................................................................84
4. 2 Flujo de llamada atendida por el IVR.............................................................................100
4. 3 Esquema de Interconexión de la Propuesta .....................................................................101
4. 4 Esquema de Interconexión de la Prueba Piloto ...............................................................102
4. 5 Salida Dmesg..................................................................................................................108
xiii
INTRODUCCIÓN
Hoy en día es posible que una conversación telefónica se pueda sostener entre dos puntos,
ocupando una porción del ancho de banda de la red de datos privada o hacia internet. La voz
entonces se convierte en paquetes y pasa a denominarse Voz sobre IP (VoIP).
Todo esto implica un cambio en la forma de comunicarnos. Las grandes compañías más
cercanas a las telecomunicaciones como Cisco, Siemens, Alcatel, 3Com, Nortel, Avaya, entre
otras, lo saben y por ello buscan actualizar sus sistemas para conseguir acercar la VoIP a sus
clientes mediante la transición paulatina de los sistemas que ya conocen.
Internet simboliza, más que cualquier otro fenómeno, la naturaleza evolutiva de las
telecomunicaciones. VoIP, es una de las grandes tendencias y a la vez una amenaza, y en
algunos casos realidades, que están sintiendo las compañías prestadoras de servicio sobre el
rumbo que están tomando el negocio de las comunicaciones, pues ya no parece necesario tener
una “línea telefónica” y sí una “línea de datos”.
Este trabajo se estructuró en cuatro capítulos que mostraran cómo se diseñó una solución de
Telefonía IP para una empresa de servicios de agenciamiento navieros que busca modernizar
su plataforma telefónica. En el capítulo I se proporciona una visión del problema que
enfrenta Servinave, los objetivos que se persiguen y que justifican el uso de la tecnología de
2
VoIP. En el capítulo II, se hace una exposición de toda la base teórica que soporta el diseño
realizado mediante la metodología definida en el capítulo III. La descripción de cómo se llevo
a cabo este diseño, conjuntamente con el resultado de la prueba piloto, fue realizado en el
capítulo IV. Para finalizar, se presentan las conclusiones obtenidas y algunas recomendaciones
necesarias que deben ser consideradas en la implementación de la solución.
3
CAPITULO I
EL PROBLEMA
Servinave, C.A. es una empresa naviera constituida por 120 empleados distribuidos en una
oficina central, ubicada en Caracas, y siete sucursales, ubicadas geográficamente en estados
distintos, a saber: Valencia, Puerto Cabello, La Guaira, Maracaibo, Puerto La Cruz, Cumaná y
Punto Fijo. Tanto en el entorno central como en las sucursales, las redes de voz y datos están
completamente separadas, sin puntos comunes de conexión. Esta situación ha llevado a la
contratación de servicios de manera separada y a la necesidad de mantener procedimientos de
gestión y administración igualmente separados.
Existe una variedad de aparatos telefónicos, la mayoría analógicos. La marca de éstos varia
entre la marca del propietario de la central y marcas genéricas. La marca de los digitales si
son de la marca propietaria de la central y están destinados para los cargos de supervisor
únicamente. Por razones económicas, no todos los puestos cuentan con aparatos telefónicos.
4
Los servicios y facilidades con que cuentan las centrales telefónicas son mecanismos que van
a convertir la central telefónica en una herramienta mucho más versátil. El inconveniente con
las centrales telefónicas propietarias es el hecho de que si se requiere de alguna de estas
facilidades, que no vienen incluidas en el licenciamiento de la solución, el costo por cada una
resulta algo elevado. Por otra parte, si los modelos de las centrales son descontinuadas por el
fabricante, nadie garantiza la asistencia técnica de las mismas, lo que obliga a pensar en
actualizar la plataforma de telefonía de un momento a otro.
1.2 Justificación
Cada día las empresas van demandando más y mejores servicios de comunicación,
independientemente de su tamaño. El auge de Internet ha traído grandes avances y muchas
posibilidades de servicios y aplicaciones a costos moderados, al poder reutilizar
infraestructura existente para datos, Internet en sí , y transmitir voz sobre ella. La Voz sobre IP
(VoIP, Voice over IP) es una tecnología que permite la transmisión de la voz a través de redes
IP en forma de paquetes de datos. La Telefonía IP es una aplicación inmediata de esta
5
tecnología, de forma que permite la realización de llamadas telefónicas corrientes sobre redes
IP utilizando un PC, gateways y teléfonos estándares.
La Telefonía IP es una tendencia mundial, a tal punto que se estima que sustituya a la
telefonía convencional en mediano plazo. Esta tendencia responde a que está basada en una
tecnología en constante evolución que está apoyada en estándares universales adoptados por
multitud de fabricantes, evitando así el empleo de PBX tradicionales basadas en sistemas
propietarios que obligan a actualizaciones costosas al ser incompatibles con otras marcas.
La virtualidad de las líneas telefónicas IP hace que el riesgo de obsolescencia que sufren las
redes de telefonía tradicional de una empresa por falta de funcionalidad o necesidad de
ampliación de líneas o extensiones desaparezca. El acceso al servicio telefónico a través de un
acceso a Internet, no sólo reduce los costos de tráfico sino que hace posible el uso de la línea
personal desde cualquier punto en el que exista una conexión a Internet, lo que permite
movilidad a los ejecutivos de la empresa y en general a cualquier empleado que requiera
desplazarse entre las distintas sucursales.
Diseñar una solución de telefonía IP para la empresa Servinave, C.A., basada en el software
libre Asterisk, que cumpla con todas las funcionalidades de una central telefónica y aproveche
la tecnología Voz sobre IP, con la finalidad de lograr una comunicación práctica, sencilla y
rentable, manteniendo la calidad de servicio igual o superior a la acostumbrada.
CAPITULO II
MARCO TEÓRICO
Una red conmutada es un conjunto de nodos interconectados entre sí, a través de medios de
transmisión, donde la información se transfiere encaminándola del nodo de orígen al nodo
destino mediante conmutación entre nodos intermedios. Se entiende por conmutación en un
nodo, a la conexión física o lógica, de un camino de entrada al nodo con un camino de salida
del nodo, con el fin de transferir la información que llegue por el primer camino al segundo.
La conmutación se divide en :
• Conmutación de paquetes.
• Conmutación de circuitos
Una comunicación mediante circuitos conmutados posee tres etapas bien definidas:
1. Establecimiento del circuito: Cuando un usuario quiere obtener servicios de red para
establecer una comunicación se deberá establecer un circuito entre la estación de origen y
8
En una red de conmutación por circuitos, la capacidad del canal se reserva al establecer el
circuito y se mantiene durante el tiempo que dure la conexión, incluso si no se transmiten
datos. Es aquí donde radica su ineficiencia, aun cuando es altamente confiable.
La diferencia con el método datagramas estriba en que cada nodo no necesita realizar una
decisión de encaminamiento para cada paquete, sino que se realiza una sola vez la decisión por
cada conexión. Otras diferencias se pueden apreciar en la tabla 2.1.
10
PAQUETES PAQUETES
Característica CIRCUITOS MEDIANTE MEDIANTE
DATAGRAMAS CIRCUITOS
VIRTUALES (C.V.)
No hay reserva de recursos No hay reserva de No hay reserva de
recursos recursos
Utilización de los No existen bits suplementarios Existencia de bits Existencia de bits
recursos de la red en la transmisión una vez suplementarios en cada suplementarios en cada
(ancho de banda) establecido el circuito paquete paquete (menos que en
datagramas) , además de
los mensajes de
establecimiento y cierre
Complejidad de los Conmutadores simples Necesidad de memoria de Necesidad de memoria
nodos almacenamiento de almacenamiento más
numeros de C.V.
Latencia Adecuado para las Poco adecuado para las Poco adecuado para las
aplicaciones interactivas aplicaciones interactivas aplicaciones interactivas
Robustez La comunicación finaliza Se buscan rutas La comunicación
alternativas finaliza
Tabla 2. 1 Comparación de Técnicas de Conmutación
El objetivo de una central de conmutación es establecer el enlace entre dos abonados, uno
llamante otro llamado, que desean comunicarse; para ello debe disponer de los medios físicos,
funciones y señalización necesarios para alcanzarlo con efectividad.
Cada vez que el abonado utiliza la línea telefónica se intercambian un conjunto de señales con
la CO. Estas señales se transmiten haciendo uso de un protocolo conocido como Señalización.
Para la transmisión por medio de la red se utilizan diferentes tipos de modulación y
multilplexado. La información de varios abonados puede ser multiplexada en tiempo (TDM)
donde cada abonado transmite en una ranura de tiempo asignada (time slot); o bien
multiplexada en frecuencia (FDM) donde cada abonado transmite a una frecuencia
determinada. La modulación de la voz se hace mediante portadoras de 64 Khz y la misma
puede ser analógica ó digital.
En un principio, la red de telefonía fue creada para transmitir la voz humana. Tanto por la
naturaleza de la información a transmitir, como por la tecnología disponible para la época, fue
creada de tipo analógico. Hoy en día, la voz solo viaja en forma analógica desde el teléfono
del usuario a la central (el denominado bucle de abonado). Allí es digitalizada y viaja en
forma binaria por el sistema telefónico hasta la central del otro abonado, donde es vuelta a
convertir en señal analógica antes de enviarla al teléfono del otro abonado. El proceso de
comunicación entre centrales totalmente digital se basa en el protocolo SS7 (sistema de
señalización 7).
2.2.1 Señalización
Una interfaz FXS proporciona alimentación eléctrica, señalización de llamada (ring) y tono al
dispositivo terminal. Estas interfaces son las que permiten conectar un teléfono analógico
convencional a un router o central de telefonía IP.
Una interfaz FXO es la interfaz que permite conectar un dispositivo terminal a un servicio de
telefonía como el servicio de telefonía pública (PSTN) o una PBX. Envía al sistema telefónio
una señal de colgado o descolgado (cierre de bucle).
FXS y FXO son siempre pares que se corresponden mutuamente: una interfaz FXS se conecta
en el otro extremo de la línea a una interfaz FXO.
Los métodos de señalización utilizados por las interfaces FXS/FXO son los siguientes:
El procesamiento de una llamada de voz se puede describir como sigue (ver figura 2.2):
Es el conjunto de señales que intercambian las centrales telefónicas. Existen dos modos
diferentes de enviar la señalización:
• Canal Aasociado: La señalización se transmite por los mismos canales que las señales
de voz. Cada canal de voz tiene asociado su canal de señalización. Ejemplo el
protocolo E&M (recEive & transMit o Ear & Mouth).
• Canal Común: La señalización se transmite por un canal diferente al empleado por las
señales de usuario. Constituye una red independiente y especializada de señalización.
Ejemplo Sistema de Señalización Número 7 (SS7).
2.3 Redes IP
Las normas que gobiernan la operación de unidades funcionales para llevar acabo la
comunicación se les llama Protocolos (Stallings, 2004). Cuando se precisa describir la
estructura y función de los protocolos de comunicaciones se suele recurrir a un modelo de
arquitectura desarrollado por la ISO (International Standards Organization) denominado
Modelo de Referencia OSI (Open Systems Interconnect).
El modelo OSI esta constituido por siete capas que definen las funciones de los protocolos de
comunicaciones (ver figura 2.3) . Cada capa del modelo representa una función realizada
cuando los datos son transferidos entre aplicaciones cooperativas a través de una red
intermedia. En una capa no se define un único protocolo sino una función de comunicación de
datos que puede ser realizada por varios protocolos. Cada protocolo se comunica con su igual
en la capa equivalente de un sistema remoto y solo ha de ocuparse de la comunicación con su
gemelo, sin preocuparse de las capas superior o inferior. Sin embargo, también debe haber
16
acuerdo en cómo pasan los datos de capa en capa dentro de un mismo sistema, pues cada capa
está implicada en el envío de datos.
El modelo OSI es utilizado como marco de referencia teórico para describir la funcionalidad
de los dispositivos y protocolos que hacen funcionar una red, sin embargo, en la práctica,
Internet y en general todas las redes IP, trabajan bajo el modelo TCP/IP.
El modelo TCP/IP es la base de Internet, y sirve para enlazar sistemas heterogéneos sobre
redes de área local (LAN) y área extensa (WAN). Este modelo es una suite de protocolos
llamado así por sus dos protocolos primarios: IP (Internet Protocol) y TCP (Transmission
Control Protocol).
TCP se diseñó específicamente para proporcionar un flujo de bytes confiable a través de una
red no confiable. El protocolo IP no ofrece ninguna garantía de que los datagramas se
entregarán adecuadamente, por lo que es responsabilidad del TCP terminar de temporizar y
retransmitirlos, según se necesite. Los datagramas que sí llegan pueden hacerlo
desordenadamente; también es responsabilidad del TCP reensamblarlos en mensajes con la
secuencia adecuada. En pocas palabras, TCP debe proveer la confiabilidad que el protocolo
IP no proporciona. TCP es el protocolo más utilizado para el nivel de transporte en Internet,
pero además de éste existen otros protocolos que pueden ser más convenientes en
determinadas ocasiones. Tal es el caso de UDP (User Data Protocol, protocolo de datos de
usuario). UDP ofrece a las aplicaciones un mecanismo para enviar datagramas IP en bruto
encapsulados sin tener que establecer una conexión. Muchas aplicaciones cliente-servidor que
tienen una solicitud y una respuesta usan UDP en lugar de establecer y luego liberar una
conexión.
A diferencia del modelo OSI, TCP/IP está constituido por las cinco capas siguientes (ver
figura 2.4 ):
En general, Voz sobre IP, también llamada VozIP, VoIP o Voz sobre Protocolo de Internet, es
una tecnología que permite transmitir en tiempo real, señales de voz través de redes de datos
empleando el protocolo IP. Esto significa que, aprovechando la infraestructura desplegada
para la transmisión de datos, se envía la señal de voz digitalizada en paquetes, en lugar de
enviarla a través de circuitos utilizables sólo para telefonía (como una compañía telefónica
convencional o PSTN).
En una llamada telefónica tradicional, la central telefónica establece una conexión permanente
entre los interlocutores, para transmitir las señales de voz. En una llamada telefónica por IP,
los paquetes de datos, que contienen la señal de voz digitalizada y comprimida, se envían a
través de la red IP (Internet/Intranet) a la dirección IP del destinatario. Cuando éstos llegan a
su destino son ordenados y convertidos de nuevo en señal de voz .
La VoIP hace uso de los CODECs para que la voz pueda ser digitalizada y comprimida.
19
2.5 Telefonía IP
Muchas veces los términos de VoIP y Telefonía IP son referenciados como un mismo
concepto, pues aun no existe una definición oficial que los distinga, quedando a juicio de los
investigadores su interpretación.
Para propósitos de esta tesis, ambos términos VoIP y Telefonía IP, serán referenciados
indistintamente como VoIP, ya que ambos permiten la realización de llamadas telefónicas
ordinarias sobre redes IP u otras redes de paquetes utilizando un PC, un teléfono IP, gateways
y/o teléfonos estándares.
2.6 CODEC
La señal de voz es una señal analógica, es decir, continua tanto en el tiempo como en
amplitud. Este tipo de señales deben ser convertidas para poder transmitirse por sistemas
digitales (redes IP). Los algoritmos que permiten convertir señales analógicas a digitales se
conocen como CODEC (codificador-decodificador).
Cualquier técnica de compresión por lo regular introduce una cierta pérdida de calidad
respecto al audio no comprimido, aunque en algunos casos dicha pérdida es difícil de percibir.
En general, a mayor compresión menor calidad. La ITU-T normaliza los esquemas de
codificación CELP, MP-MLQ, PCM Y ADPCM en sus recomendaciones de la serie G.
20
La salida del codec es una secuencia de datos que se convierte en paquetes IP y se transporta a
través de la red IP hasta su nodo destino; el nodo destino debe utilizar los mismos estándares,
así como parámetros comunes, para poder realizar el proceso inverso, pues si no, el resultado
es una comunicación inteligible.
• Muestreo (sampling)
• Cuantificación (quantization)
• Codificación (codification)
2.6.1.1 Muestreo
Según el teorema de Nyquist-Shannon, la cantidad de veces que se debe medir una señal para
no perder información debe ser al menos el doble de la frecuencia máxima que alcanza dicha
señal. Partiendo de que las señales telefónicas de frecuencia vocal ocupan la Banda de 300 a -
21
3.400 Hz, se han de muestrear a una frecuencia igual o superior a 6.800 Hz (2 x 3.400 -
frecuencia máxima -). En la práctica, sin embargo, se suele tomar una frecuencia de muestreo
o sampling rate 8.000 Hz. Es decir, se toman 8.000 muestras por segundo que corresponden a
una separación entre muestras de:
Por lo tanto, dos muestras consecutivas de una misma señal están separadas 125 µs que es el
periodo de muestreo.
2.6.1.2 Cuantificación
2.6.1.3 Codificación
El G.711, También es conocido como señal digital de nivel 0 (DS0) o Modulación de Pulsos
Codificados (PCM), no usa ninguna compresión y es el mismo codec utilizado por la PSTN.
Tiene la menor latencia (no hay necesidad de compresión), lo cual se traduce como menor
procesamiento o menor consumo de CPU. Este codec tiene dos versiones conocidas como
ulaw, usado en USA y Japón, correspondiente al estándar T1 y alaw, usado en Europa y el
resto de los países, correspondiente al estándar E1. El codec G711 provee muy buena
calidad de voz, pero consume mucho ancho de banda.
G.723.1 (Es totalmente diferente de G.723) es uno de los CODEC requeridos por su
compatibilidad con H.323 (entre otros). Su uso esta limitado por patentes y requiere de
licencia para ser usado en aplicaciones comerciales, lo que significa que si bien se puede
conmutar dos llamadas G.723.1 por Asterisk, no se permiten decodificarlos sin una licencia.
Tiene gran capacidad de compresión pero hace uso intenso de la CPU para lograrlo.
Es un codec basado en tecnología ADPCM con buena calidad y baja carga de procesador.
Normalmente se usa en modo 32 kbit/s, ya que es la mitad del ratio de G.711. Se usa
principalmente en troncales internacionales en la red de telefonía. También es el Codec
estándar usado en teléfonos inalámbricos DECT. Reemplaza a los codecs G.721 y G.723.
transportar las mismas señales. Para habilitar canales G.729 en Asterisk hay que comprar una
licencia por cada canal. Existen variaciones de G.729 , a saber:
2.6.2.5 iLBC
iLBC, "Internet Low Bit rate Codec" fue desarrollado por Global IP Sound (GIPS). Es un
codec capaz de enfrentar la eventualidad de que se pierdan tramas, lo cual ocurre cuando se
pierde la conexión o se retrazan los paquetes. Usa una codificación de predicción-lineal y
bloques-independientes (LPC). Se permite usar iLBC sin pagar licencia, sin embargo, el
dueño de la patente de iLBC, Global IP Sound (GIPS), quiere saber siempre cuando se lo usa
en una aplicación comercial. La forma de hacer esto es descargando e imprimiendo una copia
de la licencia de iLBC, firmando y devolviéndolo.
2.6.2.6 GSM
GSM (Global System for Mobile communications) es un sistema de telefonía celular popular
fuera de los Estados Unidos. GSM incluye un codec y usualmente se refiere como GSM
cuando se discuten codecs. La velocidad máxima del codec de voz GSM se llama RPE-LTP
(Regular Pulse Excitation Long-Term Prediction). Este codec usa la información de muestras
anteriores (esta información no cambia rápidamente) para poder predecir la muestra actual. La
señal de voz esta dividida en bloques de 20 ms. Estos bloques son a su vez enviados al codec
de voz, el mismo que tiene una velocidad de 13kbps, para poder obtener bloques de 260 bits.
24
2.6.2.7 SPEEX
El proyecto Speex tiene como objetivo crear un códec libre para voz, sin restricciones de
ninguna patente de software. Speex está sujeto a la Licencia BSD y es usado con el contenedor
Ogg de la Fundación Xiph.org. Las metas en el diseño eran permitir buena calidad en la voz y
bajo bit-rate (desafortunadamente no al mismo tiempo). Buena calidad también significaba
tener soporte para wideband (frecuencia de muestreo de 16 kHz) además de narrowband
(calidad de teléfono, frecuencia de muestreo de 8 kHz). Speex es un Codec Variable BitRate
(VBR), lo que significa que es capaz de dinámicamente modificar su tasa para responder a las
condiciones cambiantes de la red. Es ofrecido en las versiones de banda estrecha y de banda
ancha. Speex hace uso intenso de la CPU.
Cada codec cuenta con una cantidad de parámetros que lo caracterizan o describen y a la vez
hacen posible la estimación del ancho de banda de las comunicaciones de voz sobre la red IP.
Estos parámetros son:
En las redes de datos el retardo, la alteración del orden de llegada o la pérdida de paquetes no
son un inconveniente, ya que el sistema final tiene una serie de procedimientos de
recuperación de la información original; pero para la transmisión de voz y el video estos
factores son altamente influyentes, por lo tanto se requieren redes y protocolos que ofrezcan
un alto grado calidad de servicio (QoS, por sus siglas en inglés Quality of Service).
satisfacción está relacionado con la percepción del usuario sobre aspectos objetivos y
subjetivos de la prestación del mismo.
En otras palabras, se podría decir que QoS es un conjunto de parámetros de performance que
aseguran al usuario de un servicio niveles aceptables de calidad. Como distintos tipos de
servicio mantienen características particulares, cada uno tendría su propia QoS.
Los servicios en tiempo real como la voz y el video, necesitan tiempos de espera predecibles
para evitar el fenómeno de saltos en imagen o interrupciones de sonido. En este sentido, los
principales parámetros que afectan la QoS de estos servicios son:
Mide el tiempo que tarda un paquete en viajar de un punto a otro. En VoIP, mide el tiempo
que tarda en llegar la voz de la persona que habla hasta el oído de la persona que escucha. La
recomendación ITU-T G.114 sugiere 150 ms como máximo retardo deseado en un sentido,
para considerar buena calidad de voz.
• Retraso por Colas / Buffering: Es el tiempo que deben esperar los paquetes en el
buffer de salida de la interface del router para ser transmitidos.
• Retraso de Serialización: Es un retardo fijo dependiente de los relojes del muestreo
de la voz, o de las tramas de red, está relacionado directamente a la tasa del reloj de la
transmisión .
• Retraso de Propagación: Es el tiempo requerido por la señal óptica o eléctrica para
viajar a través a lo largo de un medio de transmisión y es una función de la distancia
geográfica.
• Buffer de Reproducción: Cuando un paquete, celda o trama llega al router destino, las
cabeceras de los protocolos son retiradas (despaquetización) y las muestras son
almacenadas en el buffer de reproducción. Este debe ser lo suficientemente grande
como para reproducir suavemente el audio, sin alterar la calidad de voz. La cantidad
de retraso introducida por este factor en un tiempo determinado depende del número de
muestras que estén en el buffer en ese momento.
2.7.2 Jitter
basado en las horas de llegada entre paquete y paquete de los paquetes exitosos. Para una alta
calidad de voz, el promedio de las horas de llegada entre los paquetes en el receptor debería
ser casi igual a la diferencia entre los paquetes en el transmisor y el estándar de desviación
debería ser bajo. El jitter buffer (el buffer mantiene paquetes entrantes por una determinada
cantidad de tiempo) es usado para neutralizar los efectos de las fluctuaciones de la red y crear
un fácil flujo de paquetes en la recepción.
Término utilizado para indicar la pérdida de paquetes durante una transmisión sobre una red
IP. Puede suceder debido a una alta latencia en la red o por congestión en los router o switches
incapaces de procesar la información.
2.7.4 Eco
El eco se define como una reflexión retardada de la señal acústica original. El eco es
especialmente molesto cuanto mayor es el retardo y cuanto mayor es su intensidad, con lo cual
se convierte en un problema en VoIP. El eco es problema en una red de paquetes de voz
cuando el retardo completo en la red es mayor que 50 msg, entonces se deben aplicar técnicas
de cancelación de eco.
En este caso hay dos posibles soluciones para evitar este efecto:
29
• Supresores de eco: Consiste en evitar que la señal emitida sea devuelta convirtiendo
por momentos la línea full-duplex en una línea half-duplex de tal manera que si se
detecta comunicación en un sentido se impide la comunicación en sentido contrario. El
tiempo de conmutación de los supresores de eco es muy pequeño. Impide una
comunicación full-duplex plena.
• Canceladores de eco: Es el sistema por el cual el dispostivo emisor guarda la
información que envía en memoria y es capaz de detectar en la señal de vuelta la
misma información (tal vez atenuada y con ruido). El dispositivo filtra esa información
y cancela esas componentes de la voz. Requiere mayor tiempo de procesamiento.
Las recomendaciones G.164 (supresores de eco), G.165 y G.168 de la UIT proporcionan unos
métodos de medida y límites en los niveles y retardos de eco que se deberían seguir con
criterio de cumplimiento mínimo.
Al igual que ocurre en cualquier red, las redes de voz sobre paquetes requieren una serie de
protocolos que especifiquen las funcionalidades y servicios que este tipo de redes deben
proveer en todas sus dimensiones. Estos protocolos están clasificados en tres grupos, según la
función que realicen dentro de las fases de establecimiento de la llamada, a saber: (Huidobro y
Roldan, 2006):
Las comunicaciones H.323 se realizan entre los siguientes elementos del sistema:
31
• Terminales
• Gateway
• Gatekeeper
• Unidad de Control Multipunto (MCU)
2.8.1.1.1 Terminales
• Interfaz de Red: Una interfaz Ethernet que puede utilizar TCP o UDP.
• Canal de Datos: Soporta aplicaciones tales como acceso a base de datos, transferencia
de archivos y conferencias audiográficas (estándar T.120).
Interconectan a una red H.323 con otra red que no lo sea (por ejemplo PSTN). Sus funciones
básicas son la traducción de protocolos de establecimiento y liberación de llamadas y la
conversión de formatos de la información entre los diferentes tipos de redes. Son elementos
opcionales cuando las comunicaciones multimedia se establecen entre los equipos de una
misma red local. Las funciones se pueden resumir en:
• Conversión de la señalización de la llamada
• Conversión de la señalización de medios
• Conversión de medios
2.8.1.1.3 Gatekeeper
Son dispositivos que permiten que dos o más terminales (o gateways) realicen conferencias
con sesiones de audio y video. Se encargan de merzclar los flujos de audio y video y distribuir
dichos flujos entre todos los participantes.
Una llamada H.323 se ejemplifica en la figura 2.9 y se caracteriza por las siguientes fases:
33
2.8.1.2.1 Establecimiento
2.8.1.2.3 Audio
2.8.1.2.4 Desconexión
El protocolo SIP (Session Initiation Protocol) fue desarrollado por el grupo MMUSIC
(Multimedia Session Control) del IETF, definiendo una arquitectura de señalización y control
para VoIP. Inicialmente fue publicado en febrero del 1996 en la RFC 2543, ahora obsoleta con
la publicación de la nueva versión RFC 3261 que se publicó en junio del 2002.
De acuerdo al RFC 3261, SIP es definido como “Un protocolo de control de señalización de
la capa de aplicación que se utiliza para establecer, mantener y terminar sesiones
multimedia”. Las sesiones multimedia incluyen la telefonía Internet, las conferencias y otras
aplicaciones similares que proporcionan medios como audio, video y datos.
mensajes recibe el nombre de Transacciones SIP entre el Cliente y el Servidor SIP. Las
conexiones SIP se establecen conforme al Modelo de conexión Cliente/Servidor (TCP/UDP).
SIP logra que dos extremos se conecten, acuerden una forma de comunicarse y lo hagan,
realmente no define, limita, establece o circunscribe las sesiones multimedia a tráfico de video
y voz solamente; puede ser cualquier otro tipo de sesión como juegos, por ejemplo.Tal como
se muestra en la figura 2.10, en las sesiones estrictamente de VoIP, SIP utiliza dos canales:
SIP Trabaja en sintonía con otros protocolos, pero con independencia de los mismos (ver
figura 2.11):
• Utiliza por defecto el protocolo de transporte UDP, puerto 5060 (aunque el estándar no
limita SIP a usar solo UDP; puede también usar TCP).
• Utiliza un protocolo llamado SDP (Session Description Protocol) en el proceso de
establecimiento de sesiones, que le permite administrar la descripción de medios y
negociación de CODECS, además de conocer cuáles puertos IP se usan para la
transmisión de medios.
37
• Para el manejo de stream o flujos de datos utiliza RTP/RTCP (Real time Transport
Protocol / RTP Control protocol)
• Simplicidad: SIP emplea mensajes de texto plano y con formato http 1.1, lo que facilita
los problemas de integración con otras aplicaciones.
• Eficiencia: SIP es muy eficaz en términos de tiempo de conexión de la llamada ya que
toda la información que se pide para el establecimiento de la llamada se incluye en el
mensaje inicial.
• Flexibilidad: Dado que SIP utiliza SDP Session Description Protocol, se puede utilizar
cualquier tipo de codec.
• Escalabilidad: Los servidores no mantienen la información del estado de las sesiones
UDP, con lo cuál se puede manipular muchos clientes por servidor.
• Soporte de Movilidad: El protocolo prevé que un mismo usuario pueda estar en
diferentes tipos de terminales.
SIP soporta cinco facetas para establecer y terminar las comunicaciones multimedia:
38
1. Localización del usuario: Determinación de los sistemas finales a ser usados para la
comunicación.
2. Disponibilidad del usuario: Determinación de la voluntad del receptor de la llamada de
participar en las comunicaciones.
3. Capacidad del usuario: Determinación del medio y sus parámetros.
4. Establecimiento de la sesión: repique, negociación de parámetros entre los
participantes de una sesión.
5. Gestión de la sesión: Transferencia, terminación de sesiones y modificación de los
parámetros de la sesión desde el propio “user agent”.
• Agentes de usuario
• Servidores de red.
Los terminales que utilizan SIP para encontrar a otro terminal y negociar las características de
la sesión se llaman UA (User Agent - Agentes de Usuario). Los agentes de usuario
generalmente, residen en la computadora del usuario en forma de una aplicación (también
pueden ser agentes de usuario los teléfonos celulares, Gateways de PSTN, PDAs, sistemas
IVR, entre otros).
Los agentes de usuario a menudo son referidos como UAS (User Agent Server - Agente de
Usuario Servidor) y UAC (User Agent Client - Agente de Usuario Cliente).
UAS y UAC son las entidades lógicas y cada agente de usuario contiene un UAC y UAS.
UAC es la parte del agente de usuario que envía los pedidos y recibe respuestas. UAS es la
parte del agente de usuario que recibe los pedidos y envía las respuestas.
39
Debido a que un agente de usuario contiene tanto un UAC como un UAS, pueden
comportarse como uno u otro dependiendo de la situación. Por ejemplo, un agente de usuario
que realiza una llamada, se comporta como UAC cuando envía mensaje de INVITE y recibe
las respuestas a ese pedido. Un agente de usuario llamado, se comporta como un UAS cuando
recibe el mensaje de INVITE y envía las respuestas. Pero esta situación cambia cuando la
parte llamada decide enviar un mensaje BYE para terminar la sesión. En este caso, el agente
de usuario llamado se comporta como UAC (enviando un BYE) y el agente de usuario
llamante se comporta como UAS (ver figura 2.12).
Los B2BUA se emplean en aquellas funciones donde es preciso controlar el saldo remanente
del usuario o el tiempo que le queda de conversación, como es el caso de los centros de
comunicaciones y de los sistemas de llamadas prepagadas.
Un B2BUA es una entidad lógica que recibe una solicitud, la procesa como si fuese un
Servidor Agente de Usuario (UAS) y, para determinar cómo contestar al mensaje de solicitud,
actúa como un Cliente Agente de Usuario (UAC) y genera mensajes de solicitud. El B2BUA
debe seguir el estado de la llamada para lo cual ha de dialogar mediante solicitudes y
40
respuestas con los UA que intervienen en la llamada. El B2BUA controla la llamada mucho
mejor que un proxy que ni puede desconectar la llamada ni cambiar los mensajes
2.8.2.1.2 Servidores
Se dividen conceptualmente en tres tipos, pero pueden estar físicamente en una única
máquina; la división de éstos puede ser por motivos de escalabilidad y rendimiento:
1) Servidores Proxy (Proxy Server): Es una entidad intermedia que actúa como cliente y
servidor con el propósito de establecer llamadas entre los usuarios. Son aplicaciones que
reciben los pedidos de los clientes SIP e inician nuevas peticiones hacia los agentes de
usuario de destino. Los servidores Proxy retransmiten solicitudes y deciden a qué otro
servidor deben remitir, alterando los campos de la solicitud en caso necesario. Existen dos
tipos de servidores Proxy : Statefull Proxy y Stateless Proxy.
a) Statefull Proxy: mantienen el estado de las transacciones durante el procesamiento de
las peticiones. Permite división de una petición en varias (forking), con la finalidad de
la localización en paralelo de la llamada y obtener la mejor respuesta para enviarla al
usuario que realizó la llamada.
b) Stateless Proxy: no mantienen el estado de las transacciones durante el procesamiento
de las peticiones, únicamente reenvían mensajes. Consume menos recursos, pero no es
aplicable en todas las situaciones.
2) Servidores de Registro (Registrar Server): Es un servidor que acepta peticiones de registro
de los usuarios y guarda la información de estas peticiones para suministrar un servicio de
localización y traducción de direcciones en el dominio que controla, es decir, el mapeo
entre direcciones SIP y direcciones IP. Se pueden o no aceptar y/o rechazar peticiones de
registro; todo basado en políticas de acceso y seguridad con contraseñas. También se les
denomina servidores de localización (Location Server LS), pues son utilizados por los
servidores proxy y de redirección para obtener información respecto a la localización o
localizaciones posibles de la parte llamada. Los LS pueden estar externos a la red SIP y
puede que emplee un protocolo alternativo para comunicarse con los otros servidores
(LDAP, TRIP, entre otros) (ver figura 2.13).
41
Las entidades SIP identifican a un usuario con las SIP URI (Uniform Resource Identifiers)
definido en el RFC3286: Uniform Resource Identifier (URI): Generic Syntax.
42
Una SIP URI tiene un formato similar al del e-mail, consta de un usuario y un dominio
delimitado por una @, es decir usuario@host, donde Usuario es el nombre de usuario o
número telefónico y Host puede ser alguno de los siguientes casos:
2.8.2.3 Mensajes
Los componentes SIP se comunican entre sí mediante una serie de mensajes, los cuales son
solicitudes (métodos) y las respuestas (códigos de estado) (verfigura 2.15).
Las solicitudes SIP son caracterizadas por la línea inicial del mensaje, llamada Request-Line,
que contiene el nombre del método, el identificador del destinatario de la petición (Request-
URI) y la versión del protocolo SIP. Existen seis métodos básicos SIP que describen las
peticiones de los clientes:
1) INVITE: Permite invitar un usuario o servicio para participar en una sesión o para
modificar parámetros en una sesión ya existente.
2) ACK: Confirma el establecimiento de una sesión.
3) OPTION: Solicita información sobre las capacidades de un servidor.
4) BYE: Indica la terminación de una sesión.
5) CANCEL: Cancela una petición pendiente.
6) REGISTER: Registrar al User Agent.
Sin embargo, existen otros métodos adicionales que pueden ser utilizados, ubicados en otros
RFCs como los métodos INFO, SUBSCRIBER,entre otros.
Donde SP es el carácter espacio y CRLF es la secuencia retorno del carro y nueva línea (ver
tabla 2.3) .
44
Donde SP es el carácter espacio y CRLF es la secuencia retorno del carro y nueva línea (ver
tabla 2.4)
• Reason-Phrase: Explicación textual muy breve del Status-Code, para ser interpretada
por humanos.
SIP/2.0 200 OK
Version SIP SIP/2.0
Status-Code: 200
Reason-Phrase OK
Las cabeceras se utilizan para transportar información necesaria a las entidades SIP;
especifican información como: el llamante, el llamado, el camino o ruta del mensaje, el tipo y
longitud del cuerpo del mensaje, entre otros. Existen campos que se emplean en todos los
mensajes y otros que se utilizan únicamente en situaciones muy concretas. A continuación, se
detallan los campos:
• Via: Indica el transporte usado para el envío e identifica la ruta del request, por ello
cada proxy añade una línea a este campo.
• From: Indica la dirección del origen de la petición.
• To: Indica la dirección del destinatario de la petición.
• Call-Id: Identificador único para cada llamada y contiene la dirección del host. Debe
ser igual para todos los mensajes dentro de una transacción.
• Cseq: Se inicia con un número aleatorio e identifica de forma secuencial cada petición.
• Contact: Contiene una (o más) dirección que pueden ser usada para contactar con el
usuario.
• User Agent: Contiene el cliente agente que realiza la comunicación.
46
Tal como se puede apreciar en la figura 2.16, en una llamada SIP hay varias transacciones SIP.
Una transacción SIP se realiza mediante un intercambio de mensajes entre un cliente y un
servidor. Consta de varias peticiones y respuestas y para agruparlas en la misma transacción
esta el parámetro CSeq.
• Las dos primeras transacciones corresponden al registro de los usuarios. Los usuarios
deben registrarse para poder ser encontrados por otros usuarios. En este caso, los
terminales envían una petición REGISTER, donde los campos from y to corresponden
al usuario registrado. El servidor Proxy, que actúa como Register, consulta si el usuario
puede ser autenticado y envía un mensaje de OK en caso positivo.
• La siguiente transacción corresponde a un establecimiento de sesión. Esta sesión
consiste en una petición INVITE del usuario al proxy. Inmediatamente, el proxy envía
48
IAX (Inter Asterisk Exchange) es protocolo desarrollado por DIGIUM y aprobado por la
IETF en febrero 2009, con el RFC 5456. Es un estándar abierto que, aunque originalmente fue
diseñado para comunicación entre centrales Asterisk (de aquí deriva su nombre), soporta
muchos otros proyectos de comunicación fuente abierta, así como distintos proveedores de
hardware.
El protocolo IAX se refiere generalmente al IAX2, la segunda versión del protocolo IAX. El
protocolo original ha quedado obsoleto en favor de esta versión. En tal sentido, se emplea IAX
o IAX2 indistintamente para referirse siempre a ésta ultima versión.
De acuerdo a Goncalvez (2007), los objetivos de diseño para IAX se derivan de la experiencia
con los protocolos de VoIP existentes como SIP y MGCP (Media Gateway Control Protocol )
para control, y RTP para la transmisión de datos multimedia, resumiendo como los objetivos
de diseño primarios para el mencionado protocolo los siguientes puntos:
1) Minimizar el uso de ancho de banda tanto para control como para datos multimedia,
con especial énfasis en las llamadas de voz individuales.
49
IAX es un protocolo de media y señalización “par-a-par“ (peer to peer o P2P) que implementa
codificación binaria, en lugar de una codificación basada en Texto/ASCII como en SIP, lo
cual contribuye a la rapidez de procesamiento de los mensajes/paquetes en el protocolo y
además hace que el protocolo consuma marginalmente un menor ancho de banda.
IAX usa sólo un par de flujos donde voz y datos coexisten (utiliza solamente el puerto 4569
para transmitir tanto la señalización como los datos). Esta forma de enviar tanto las
conversaciones como la señalización por el mismo canal se conoce como inband, en contraste
con el método que usa SIP, el outofband. La idea de enviar la señalización dentro del canal de
voz (inband) obliga a separar los paquetes de voz de los paquetes de señalización. Aunque este
diseño requiere más gasto de procesamiento (CPU) ofrece mejores propiedades en presencia
de cortafuegos y NAT.
Otra característica de IAX es que soporta TRUKING; es decir, un solo enlace puede enviar
datos y señalización de varios canales. Cuando se hace TRUKING, un solo paquete IP puede
contener información de varias llamadas lo cual supone un importante ahorro de ancho de
banda, ya que hay una disminución en la tasa de bits de los paquetes debido a que ya no es
necesario enviar varias veces la cabecera IP .
Los mensajes o tramas que se envían en IAX son binarios y por tanto, cada bit o conjunto de
bits tiene un significado. Existen dos tipos de mensajes principalmente:
confirmando que ha recibido ese mensaje. Estas tramas son las únicas que deben ser
respondidas explícitamente.
Las tramas M o mini frames para mandar la información con la menor información posible en
la cabecera. Estas tramas no tienen porque ser respondidas y si alguna de ellas se pierde se
descarta.
En la figura 2.17 se puede apreciar los pasos para establecer una llamada a través del
protocolo IAX:
La estrategia escogida para este tipo de aplicación consiste en dar preferencia a la continuidad
sobre la fiabilidad, en otras palabras, admitir la pérdida de paquetes abandonándolos para
salvaguardar la continuidad del flujo. El protocolo UDP es más utilizado en la telefonía IP, en
lugar del protocolo TCP. El protocolo UDP funciona en un modo sin conexión, es decir,
enviando datagramas procesados independientemente por la red, que pueden tomar rutas
diferentes y ser recibidos en un orden diferente. El protocolo UDP no tiene corrección de
errores (por lo que no es fiable) y su función principal consiste en distinguir entre los
diferentes servicios de aplicación, encaminándolos hacia el módulo de procesamiento de
software de recepción adecuado, mediante la atribución de un número de puerto a cada
aplicación. Por lo general, el protocolo UDP se utiliza como protocolo subyacente para el RTP
(protocolo de transporte en tiempo real).
Este protocolo define un formato de paquete para llevar audio y video a través de internet.
Está descrito en RFC3550. Este protocolo no usa un puerto UDP determinado, la única regla
que sigue es que las comunicaciones UDP se hacen vía un puerto impar y el siguiente puerto
par sirve para el protocolo de control RTP (RTCP). RTP y RTCP se definen dentro del mismo
estándar.
RTCP es un protocolo que permite mantener información de control sobre una sesión RTP. Se
fundamenta en el envío periódico de paquetes de control a todos los participantes de una
53
sesión RTP, utilizando el mismo mecanismo de distribución empleado para los paquetes de
streaming RTP. Se utiliza un canal distinto al de cada canal RTP de la sesión (se utiliza otro
puerto UDP). RTCP fue diseñado para trabajar en conjunto con RTP.
1) Informes de emisor (sender reports): Permiten al emisor activo en una sesión informar
sobre estadísticas de recepción y transmisión.
2) Informes de receptor (receiver reports): Los utilizan los receptores que no son emisores
para enviar estadísticas sobre la recepción.
3) Descripción de la fuente: Contiene los CNAMEs y otros datos que describen la
información de los emisores.
4) Paquetes de control específicos de la aplicación. Varios paquetes RTCP pueden ser
enviados en un mismo mensaje UDP.
54
2.8.4.3 Protocolo de Flujo de Datos en Tiempo Real RTSP (Real Time Streaming
Protocol)
Una vez que la aplicación cliente ha recibido suficientes paquetes comienza la reproducción y
simultáneamente, puede estar descomprimiendo uno y reproduciendo otro. Asimismo, un
servidor mantiene información de estado de cada cliente que esté conectado a él.
Es común denominar ancho de banda a la cantidad de datos que se pueden transmitir en una
unidad de tiempo. Huidobro y Roldán (2006) lo definen como la capacidad de transmisión
de un canal de comunicaciones, medido en hercios en las comunicaciones analógicas y en
bits por segundo (bps) en las comunicaciones digitales.
Ganzábal (2008), explica que encontrar el ancho de banda en VoIP radica en encontrar los
parámetros:
Estos dos parámetros, tanto la tasa de paquetes como el tamaño de paquete dependen del
codificador que se utilice. El tamaño total del paquete depende además, del tamaño del
encabezado de cada uno de los protocolos intervinientes. Estos son RTP, UDP, IP y el
protocolo de nivel de enlace utilizado (Frame Relay, Ethernet, entre otros).
BITS
RATE Tt Tt PAYLOAD TAMAÑO BW Tla RETARDO
CODEC (kbps) (bytes) (ms) (bytes) PPS paquete (bps) (ms) (ms)
G.711 64 160 20 160 50 200 80.000 - 20
48 60 10 60 100 100 80.000 0 10
56 70 10 70 100 110 88.000 0 10
G.722 64 80 10 80 100 120 96.000 0 10
16 20 10 20 100 60 48.000 1,5 11,5
24 30 10 30 100 70 56.000 1,5 11,5
32 40 10 40 100 80 64.000 1,5 11,5
G.726 40 50 10 50 100 90 72.000 1,5 11,5
6,4 16 20 16 50 56 22.400 5 25
8 20 20 20 50 60 24.000 5 25
G.729 11,8 30 20 30 50 70 27.800 5 25
GSM 13,3 17 10 17 100 57 45.300 - 10
13,33 50 30 50 33 90 23.997 - 30
iLBC 15,2 38 20 38 50 78 31.200 - 20
5,95 15 20 15 50 55 21.950 - 20
8 20 20 20 50 60 24.000 - 20
11 28 20 28 50 68 27.000 - 20
15 38 20 38 50 78 31.000 - 20
18,2 46 20 46 50 86 34.200 - 20
Speex 24,6 62 20 62 50 102 40.600 - 20
Tabla 2. 5 Cálculo Consumo de Ancho de banda por CODEC
Las fórmulas empleadas para realizar los cálculos presentados en la tabla 2.5 se resumen en la
tabla 2.6.
DESCRIPCIÓN FÓRMULAS
Tamaño de la Trama (en Tt (bytes)= Codec bit rate * Tt (ms)
bytes) 8 bits/bytes * 1000 ms/s
Tamaño Total del Paquete TTP= (Cabecera Capa2)+(Cabecera IP/UDP/RTP)+(tamaño payload de voz)
Paquetes por Segundo PPS= Codec bit rate / tamaño payload de voz
Ancho de Banda BW= TTP * PPS
Tabla 2. 6 Fórmulas para Cálculos de Consumo por CODECs
Los paquetes generados por el CODEC no se transmiten directamente por la red, sino que
viajan con el añadido de cabeceras empleadas por los protocolos de las diferentes capas. Esos
bits adicionales de control también consumen ancho de banda y, por ello, se deben tener en
56
cuenta. En la tabla 2.7 se resumen algunas de las sobrecargas que se van agregando al
paquete IP según el protocolo.
2.9.1 Retardo
Uno de los parámetros que va a determinar la calidad de voz es el retardo que sufran los
paquetes. Para realizar el cálculo, se deben sumar todas las contribuciones al retardo. Una vez
obtenidos estos valores, se procede a comprobar si superan o no el umbral aconsejable. Cabe
destacar lo siguiente:
La recomendación G.114 de la ITU-T establece como limite los 150ms o 200 ms ( en una vía).
Si se supera este valor, la voz de los interlocutores tenderá a solaparse y la conversación se
58
tornará inteligible. Asimismo, hay que tener en cuenta también que aunque aumentar la carga
útil reduce el ancho de banda global, también aumenta en general el retardo.
El retardo siempre está presente, solo que en una conversación telefónica convencional es tan
pequeña que el oído humano no lo aprecia.
Otro factor que suele sumarse al cálculo es el aumento de ancho de banda debido al envío de
mensajes de RTCP (Real-Time Transport Control Protocol). En la RFC3550 donde se definen
los protocolos RTP y RTCP, recomienda reservar un ancho de banda de un 5% más para el
envío del RTCP.
2.10 Asterisk
Con el acrónimo PBX (siglas en inglés de Private Branch Exchange) se conoce a los
diferentes tipos de centrales telefónicas de uso privado o utilizadas en las empresas. Las
59
centrales telefónicas tienen conexión directa a la PSTN y permiten conmutar llamadas entre
usuarios de la empresa en líneas locales y compartiendo líneas externas.
Asterisk actúa como middleware entre los servicios de VoIP (IAX, SIP, MGCP, H.323),
canales de telefonía (como Zaptel, T1, PRI, E1, FXO, FXS, VoIP, VoFR, RDSI, módem,
Internet Phone Jack, etc.), y las aplicaciones (como correo de voz, conferencias, directorios,
reproductores de MP3, entre otras).
Asterisk es una PBX completa en software que puede interoperar con casi todos los
estándares de telefonía del mercado, tanto los tradicionales (TDM) con el soporte de puertos
de interfaz analógicos (FXS y FXO) y RDSI (básicos y primarios), así como los de telefonía
IP (SIP, H.323, MGCP, SCCP/Skinny). Esto le permite conectarse a las redes públicas de
telefonía tradicional e integrarse con centrales tradicionales (no IP) u otras centrales IP.
Asterisk fue diseñado de forma modular, de manera de que cada usuario puede seleccionar las
partes que requiere utilizar (ver figura 2.18), haciéndolo un sistema escalable y extensible;
escalable porque se van habilitando o deshabilitando módulos según los recursos y las
necesidades; y extensible porque para programar un nuevo módulo no es necesario conocer
todo el código de Asterisk (Gómez y Gil, 2008).
60
• Core: Es el núcleo de Asterisk, que contiene las funciones más básicas y posibilita la
carga de módulos. Entre sus funciones se tiene:
Si se deseara únicamente instalar Asterisk para servicios puramente VoIP, la parte del
diagrama que se refiere a canal ZAP (El módulo que da soporte al hardware de Asterisk
llamado Zaptel, cambio de nombre a DAHDI ) desaparecería. Sin embargo, normalmente es
necesario conectarse a redes tradicionales como la red telefónica pública conmutada (PSTN)
y el canal ZAP contiene los drivers para el funcionamiento de tarjetas telefónicas PCI que
permitirán esta interconexión.
Los canales SIP, IAX y ZAP (asi como otras entidades en el sistema) tienen acceso a su
archivo de configuración a través de Asterisk . El flujo general de una llamada generada por
un SIP UA (SIP User Agent) se puede apreciar (de forma bastante simplificada) en la figura
2.19.
62
Para que una llamada pueda realizarse, el UA (user agent) debe estar debidamente registrado.
Una vez registrado, el UA puede proceder a solicitar el inicio de una llamada enviando un
número. Esta petición es recibida por el módulo correspondiente de Asterisk (canales
chan_zap, chan_sip, chan_iax, chan_xxx), quien a su vez revisa el archivo de configuración
correspondiente (archivos zapata.conf, sip.conf, iax.conf ) para autorizar la llamada y decidir a
que contexto (agrupaciones lógicas de extensiones) del plan de marcado se delegará el ruteo
de la llamada.
1. Digium Asterisk Hardware Device Interface DAHDI: Son los módulos del kernel para
hacer funcionar las tarjetas de comunicación analógicas y digitales. Además contiene
varias utilidades de configuración y diagnóstico. El módulo que da soporte al hardware de
Asterisk llamado Zaptel, cambió de nombre a DAHDI, porque una empresa tiene los
derechos de la marca Zaptel. DAHDI solo es compatible con versiones de Asterisk 1.4.22
63
CAPITULO III
METODOLOGÍA
Se considera que es un Proyecto Factible debido a que en él se plantea una solución posible o
viable a la problemática que enfrenta la Empresa Servinave,C.A.
• Entrevistas
:
o Se entrevistaron a los Gerentes principales de las sucursales para poder definir
los requerimientos del proyecto por oficina.
o Se entrevistó al personal técnico responsable de la red de voz y datos para
conocer y obtener la documentación de la infraestructura desplegada, asi como
conocer el plan de marcación que actualmente tienen las PBX instaladas.
Actividades
• Revisión bibliográfica.
• Identificación de las funcionalidades necesarias por cada sucursal/principal.
• Revisión de la infraestructura actual.
o Red de Telefonía
66
Actividades
Actividades
• Definición de la infraestructura
• Dimensionamiento y selección del hardware y software
• Estimación de costos
• Diseño del plan de discado (dialplan)
Actividades
• Definición de la prueba
• Creación de VLANs
• Instalación y configuración en los servidores Asterisk de
o GNU/Linux CentOS
o Servicios de telefonía
67
o Tarjetas de telefonía
o Configuración de Asterisk
• Configuración de los terminales de voz
• Pruebas
• Revisión y ajustes de los parámetros definidos en el diseño
• Conclusiones
Actividades
CAPITULO IV
DESARROLLO
En el presente capítulo se exponen todos los aspectos relacionados con el desarrollo del
diseño de la solución. Cabe destacar que, antes de iniciar esta exposición, se presenta una
breve descripción de la Empresa para la que se está realizando este diseño.
La oficina principal se encuentra ubicada en Caracas y las sucursales están ubicadas en los
principales puertos, a saber: Puerto Cabello, La Guaira, Maracaibo, Cumaná, Punto Fijo,
Puerto La Cruz y Valencia (oficina comercial).
El proceso operativo se lleva a cabo principalmente en los puertos mientras que el proceso
administrativo y comercial se encuentra en la oficina principal. Esto genera una constante
comunicación entre los puertos y oficina principal, así como de la oficina principal con los
clientes (informar arribos y estatus de cargas) y las líneas representadas (itinerarios y
Manifiestos de cargas). Es importante resaltar que las líneas representadas no se encuentran en
Venezuela, por lo que las llamadas internacionales también son muy frecuentes.
1. Planificación del servicio: En esta parte del proceso se realiza toda la logística
determinando qué le corresponde.
2. Elaboración y recepción de anticipo: La empresa realiza una factura pro forma, que indica
todos los posibles gastos que tendrá el barco y sus respectivos costos, y en base a esto la
línea realiza la transferencia de fondos a la empresa.
3. Cancelación de pagos previos Capitanía, Terminal, Ochina y Lanchaje: Se realizan los
pagos a los entes gubernamentales encargado de prestar estos servicios y los pagos
correspondientes a impuestos.
4. Solicitud de muelle: Se indica a la capitanía de puerto cinco días antes de la llegada del
barco y se solicita un muelle para que el buque atraque.
5. Elaboración del prospecto de buque: Con la información suministrada por la capitanía de
puerto, donde se indica el muelle a ser utilizado, la fecha en que se espera el atraque del
buque y la hora, se elabora un documento que es enviado a la línea para su conocimiento.
6. Solicitud de visitas al buque por parte de entes gubernamentales: El visitador de buque
avisa a la guardia nacional y entes gubernamentales para que se realice la visita al buque,
con la finalidad de dar el visto bueno al mismo y autorizar el atraque.
7. Transmisión de los manifiestos de carga: Cuarenta y ocho horas antes de la llegada del
barco o a más tardar antes de su salida, se deben presentar los conocimientos de la carga de
importación que trae el buque a través del sistema online del Seniat (SIDUNEA). La
transmisión extemporánea genera multas.
8. Amarre o conexión para el atraque del buque: Se amarra el buque a la unidad que remolca
el buque hasta el muelle.
9. Atención del Buque: Esta es la parte central del proceso, incluye el amarre y desamarre
del buque al muelle, prestar provisiones para la tripulación del barco, atención médica,
custodia del buque, suministro de combustible, lancha, remolcador, agua fresca,
recolección de basura, migración, embarque y desembarque, entre otros.
10. Solicitud de despacho de buque para el zarpe: Se debe ir a la capitanía de puerto y solicitar
el permiso de zarpe, documento que indica que el buque no tiene problemas para zarpar.
11. Desamarre o Desconexión para el zarpe del buque: Es el proceso por el cual se sueltan los
amarres del buque para permitir el zarpe del mismo.
70
12. Cancelación de pagos a terceros: En las oficinas se genera el pago a los proveedores de
servicios que son utilizados para realizar las operaciones del buque, así como el personal
contratado de manera temporal para tal fin.
13. Facturación: Mediante un sistema computarizado se elaboran las facturas las cuales son
asentadas y enviadas al departamento de contabilidad para su control y elaboración de
informes y balances mensuales.
14. Elaboración y Envío de Estado de Cuenta: Se elaboran los estados de cuenta mediante un
sistema automatizado, lo que incluye entrada y verificación de datos. Luego se envían a las
líneas para su control.
Al finalizar las actividades que conforman esta fase se logro tener un diagnóstico de la
situación actual. Las actividades realizadas fueron las siguientes:
En esta actividad se obtuvieron las bases teóricas necesarias para realizar el Trabajo. Se basó
principalmente en la búsqueda de información referente al tema estudiado.
Las principales fuentes de información fueron documentos bibliográficos, los cuales provienen
de diferentes fuentes, libros, revistas, e Internet. Sin embargo, es importante mencionar que
parte de la información y de los conocimientos necesarios se obtuvieron de cursos técnicos
tomados en el área de Asterisk , Linux , VoIP y telefonía IP. Otra fuente de referencia
importante consultada fue la experiencia de otras empresas de la Organización en instalaciones
similares que, aunque tienen realidades y tecnologías diferentes, sirvieron como guía.
Para conocer las funcionalidades requeridas por las oficinas, tanto principal como sucursales,
se entrevistó, en cada una, a la persona responsable de su administración. La entrevista
constaba de las siguientes preguntas:
1. Actualmente, ¿Existe algún tipo de problema con las líneas telefónicas o con la PBX?
2. ¿Piensa Ud. que cuentan con suficientes líneas telefónicas?
3. ¿Con qué facilidades telefónicas cuentan actualmente?
4. ¿Qué otras facilidades telefónicas cree Ud. que la oficina requiere?
5. ¿Han recibido quejas de los clientes o de otras sucursales acerca de que nunca atienden el
teléfono?
• Se detectó que la Empresa hace uso bastante básico de las funcionalidades de una central
telefónica.
• La mayoría de las facilidades que solicitan las ofrece Asterisk como parte de su
funcionalidad básica.
• La cantidad de líneas con que cuenta cada oficina es suficiente.
Basado en lo anterior, se definen las siguientes funcionalidades para todas las oficinas (como
mínimo):
• Que la llamada sea redirigida a través de la red de datos cuando se desee llamar a una
de las sucursales.
• Que cada extensión tenga asignado su correspondiente voicemail .
• Que las llamadas entrantes sean atendidas por un IVR y éste las distribuya según las
opciones seleccionadas.
• Poder ver el identificador del llamante (Caller Id).
OFICINA PREGUNTA
1 2 3 4 5
Caracas NO SI PBX CALLER ID de llamadas externas NO
IVR Poder llamar por la red privada a las sucursales (para
Buzón de voz minimizar gastos)
Directos Poder controlar el gasto telefónico de las sucursales
Puerto NO SI PBX básica Ninguna en particular NO
Cabello
La Guaira NO SI PBX básica Ninguna en particular NO
Maracaibo NO SI PBX básica Ninguna en particular NO
Valencia NO SI LINEA Poder transferir llamadas entre la ellos NO
DIRECTAS Controlar el acceso a la PSTN
Cumaná NO SI PBX básica Ninguna en particular NO
Puerto La NO SI PBX básica Ninguna en particular NO
Cruz
Punto Fijo NO SI LINEA Que cada uno tenga una extensión. NO
DIRECTAS Controlar el acceso a la PSTN
Poder transferir entre ellos llamadas
Tabla 4. 1Respuesta de las Entrevistas
En líneas generales, tanto en la oficina central como en las sucursales, las redes de voz y datos
son totalmente independientes, sin puntos comuns de conexión. A continuación se describen
cada una de ellas.
OFICINA Nº Líneas
CARACAS 31
PUERTO CABELLO 18
LA GUAIRA 17
MARACAIBO 11
VALENCIA 5
CUMANÁ 4
PUERTO LA CRUZ 4
PUNTO FIJO 2
Tabla 4. 2 Líneas Contratadas
Existe una variedad de aparatos telefónicos, la mayoría analógicos. La marca de éstos varía
entre la marca del propietario de la central y marcas genéricas. Por razones económicas, no
todos los puestos cuentan con aparatos telefónicos (ver tabla 4.3).
74
Modelos de Teléfonos
OFICINA
ANALÓGICOS DIGITALES FAX
Caracas 2 48 2
Puerto Cabello 22 21 2
La Guaira 16 2 3
Maracaibo 14 1 2
Valencia 5 1
Cumaná 5 1
Puerto la Cruz 4 1
Punto Fijo 2 1
Tabla 4. 3 Distribución de Teléfonos por Oficina
Actualmente, en las oficinas donde hay central telefónica, los servicios de la central que están
configurados y en uso son los básicos y los servicios de fax son prestados a través de equipos
tradicionales. Solo la oficina de Caracas cuenta además con servicio de IVR (Interactive voice
response) y buzón de voz. Los usuarios son autorizados o restringidos a realizar llamadas a
celulares, LDN y LDI de acuerdo a las funciones del cargo. Las llamadas a otras sucursales
están autorizadas para todos los usuarios, mediante la configuración de números abreviados.
Finalmente, ninguna de las oficinas posee un contrato de mantenimiento para la PBX. En las
oficinas donde no hay central telefónica, no se aplica ningún tipo de restricción en la
realización de llamadas. Tanto la PBX de Caracas como la de Puerto Cabello tienen
interconexión mediante líneas FXS/FXO con centrales Siemens de otras empresas
pertenecientes a la misma organización.
Las oficinas no cuentan con una aplicación fiable que permita conocer la distribución del
tráfico telefónico. No obstante, por medio de las facturas telefónicas del proveedor de servicio
se pudo estimar el tráfico inter-sucursal como se resume en las tablas 4.4, 4.5, 4.6, 4.7, 4.8,
4.9, 4.10 y 4.11.
75
Minutos
Desde la oficina Puerto Cabello Llamadas diarias diarios
Caracas 15 56,83
La Guaira 5 32,66
Maracaibo 1 8,55
Valencia 2 9,51
Cumaná 2 2,96
Puerto La Cruz 1 1,1
Punto Fijo 0 0
TOTAL 25 111,61
Tabla 4. 5 Resumen de llamadas desde Oficina Puerto Cabello
Minutos
Desde la oficina La Guaira Llamadas diarias diarios
Caracas 24 70,6
Puerto Cabello 10 35,17
Maracaibo 2 4,17
Valencia 2 153,08
Cumaná 3 10,73
Puerto La Cruz 2 2,61
Punto Fijo 0 0
TOTAL 42 276,36
Tabla 4. 6 Resumen de llamadas desde Oficina La Guaira
76
Llamadas Minutos
Desde la oficina Maracaibo diarias diarios
Caracas 4 31,40
Puerto Cabello 1 7,80
La Guaira 1 0,81
Valencia 0 0,00
Puerto La Cruz 1 1,87
Cumaná 0 0,00
Punto Fijo 2 8,84
TOTAL 9 50,72
Tabla 4. 7 Resumen de llamadas desde Oficina Maracaibo
Llamadas Minutos
Desde la oficina Valencia diarias diarios
Caracas 5 44,24
Puerto Cabello 3 16,43
La Guaira 1 0,79
Maracaibo 0 0,00
Cumaná 0 0,00
Puerto La Cruz 0 0,00
Punto Fijo 0 0,00
TOTAL 9 61,46
Tabla 4. 8 Resumen de llamadas desde Oficina Valencia
Llamadas Minutos
Desde la oficina Cumaná diarias diarios
Caracas 2 6.47
Punto Fijo 0 0
Puerto Cabello 3 3.65
La Guaira 2 10.53
Maracaibo 0 0
Valencia 0 0
Puerto La Cruz 0 0
Punto Fijo 0 0
TOTAL 7 20.66
Tabla 4. 9 Resumen de llamadas desde Oficina Cumaná
77
Llamadas Minutos
Desde la oficina Punto Fijo diarias diarios
Caracas 1 7,19
Puerto Cabello 0 0,00
La Guaira 0 0,00
Maracaibo 3 12,00
Valencia 0 0,00
Cumaná 0 0,00
Puerto La Cruz 0 0,00
TOTAL 4 19,19
Tabla 4. 11 Resumen de llamadas desde Oficina Punto Fijo
De acuerdo a las entrevistas realizadas, se asumió que la central está bien dimensionada en
cuanto a la cantidad de líneas contratadas a la PSTN.
Tanto en el entorno central como en las sucursales, la red LAN fue cableada en UTP categoría
5e y diseñada en topología estrella Fast Ethernet. Los switches empleados son marca
3com de diferentes modelos, conectados en cascada. No hay VLAN configuradas, aunque los
switches permiten esta funcionalidad (ver tabla 4.12)
78
Los servicios que presta la oficina central a las sucursales son servicios FTP, DNS, Correo
electrónico, Webmail y acceso a las aplicaciones de contabilidad, de gestión naviera.
La aplicación Starnet está ubicada en la localidad del cliente (USA) y se accede a ella
mediante un enlace que está instalado en la oficina principal. La aplicación es en entorno Web,
mientras que las aplicaciones de contabilidad y naviera son en ambiente caracter y están
ubicadas en la oficina principal, cada una en servidor IBM ISeries. También existen
aplicaciones de otros clientes que son accedidas directamente por cada oficina a través de
Internet y no dependen de la oficina principal.
Resumiendo, el tráfico de datos que circula por la red LAN/WAN se resume en la tabla 4.13:
PROTOCOLOS APLICACIONES
POP3 Correo electrónico
NRPC Correo electrónico
SMTP Correo electrónico
TELNET Contabilidad, naviera, SPA
http/Https Starnet, Intranet, Paginas web
Citrix Starnet
DNS Servicio DNS
FTP Servicio FTP
Frame Relay Enlace con las sucursales
mGRE, IPSEC VPN con sucursales, VPN con Seniat
(Sidunea)
Tabla 4. 13 Protocolos Activos en la Red Lan/Wan
80
Para conocer los tiempos (aproximados) de respuesta con las sucursales, se extrajo de la
aplicación BECOMONITOR (aplicación desarrollada en la Organización) un reporte donde se
indicaba que los mismos oscilaban entre 30 y 60 ms, en la red Frame Relay, y entre 100 y 200
ms, en la VPN.
Esta aplicación obtiene los valores mediante el registro del resultado de la ejecución de un
ping durante cierto tiempo, a un servidor ubicado en cada sucursal, varias veces en el día,
todos los días. Luego, mediante el modulo de reportes se consulta está información.
Una de las etapas críticas del diseño de una solución de VoIP es el cálculo de ancho de banda
necesario para cursar el tráfico de llamadas y el datos manteniendo la calidad de servicio
exigida por cada tráfico. En este ancho de bando influye, fundamentalmente, tres factores:
volumen de tráfico cursado, CODEC empleado para la generación de paquetes de voz y el
formato de dichos paquetes (cabecera e información útil).
Los canales de VoIP representan la cantidad de llamadas simultáneas entre las sucursales, es
decir, la cantidad de tráfico de voz que va a cursar a través de la WAN de la empresa
El tráfico es una medida de la carga de los recursos de la red, de manera que cuanto mayor es
el nivel del tráfico, tanto más cargados están los recursos o tantos más recursos son necesarios
para mantener una ocupación dada. En telecomunicaciones, la unidad utilizada como medida
estadística del volumen de tráfico, es el ERLANG.
Existen varios modelos de tráfico que se emplean para calcular cuántas líneas de enlace
(canales) son necesarias, los principales modelos son los siguientes:
81
• Erlang B: Es el modelo más común y se emplea para calcular cuántas líneas son
necesarias para una cifra de tráfico (en Erlangs) determinada en la hora cargada. Este
modelo supone que las llamadas bloqueadas se liberan inmediatamente.
• Erlang B Extendido: Es similar al anterior, salvo que en este caso tiene en cuenta cuál
es el porcentaje de llamadas bloqueadas (que reciben señal de ocupado) y se puede
especificar el porcentaje de reintentos.
• Erlang C: Este modelo supone que las llamadas bloqueadas permanecen a la espera
hasta que sean atendidas. Sirve, por ejemplo, para calcular las necesidades de personal
de un centro de llamadas, donde aquellas llamadas que no se pueden atender de
inmediato se ponen en cola.
Al finalizar las actividades que conforman esta fase se logro conocer el ancho de banda que se
requiere para soportar el tráfico de voz intersucursal calculado en la fase anterior, toda vez que
se seleccionó los CODECs y los protocolos de señalización requeridos para el diseño. Las
actividades realizadas fueron las siguientes:
• Busy hour traffic (BHT): La variable BHT es la cantidad de tráfico que cursa durante
la hora más ocupada del día.
• Blocking (bloqueo): Es la fracción de llamadas que no pudieron ser atendidas porque
todas las líneas estaban ocupadas. Dependiendo de la aplicación, una cifra razonable de
bloqueo está entre 0.01 y 0.03.
• Lines (Canales, circuitos, líneas): Cantidad de líneas necesarias o disponibles.
La variable BHT representa los sesenta minutos en los que los niveles de tráfico alcanzaron
el mayor nivel. Este parámetro solo pudo ser calculado para las oficinas de Caracas, Puerto
Cabello y La Guaira, debido a que solo existía data de estas oficinas. Los valores obtenidos
82
después de sumar los minutos cursados en un mes, hora por hora, en lapsos de 24 horas, están
reflejados en la tabla 4.14:
Oficina Hora pico BHT
Caracas 10:00am a 10:59am 2:04:30
Puerto Cabello 10:00am a 10:59am 00:47:15
La Guaira 10:00am a 10:59am 00:52:21
Tabla 4. 14 BHT de CCS, La Guaira y Puerto Cabello
Para aquellas oficinas en las que no fue posible calcular el valor del parámetro BHT, se
estimó (E) el mismo como el 17% del total del tráfico diario de la oficina.
Como se ha mencionado anteriormente, los protocolos de señalización son las normas que
describen el intercambio de información relacionada con el establecimiento, control y gestión
de las conexiones. Para este diseño se realizó la siguiente selección:
83
La selección del codec para este diseño debe responder a las siguientes condiciones:
• CODEC iLBC para la comunicación sobre WAN, debido a que ofrece de base , según
su sitio oficial (http://www.ilbcfreeware.org/) una calidad mayor al CODEC privativo
G.729A, altos índices de resistencia a la pérdida de paquetes y la complejidad
computacional está en el rango de G.729A. No requiere licencia.
Para elaborar el cálculo del consumo de ancho de banda, se utilizó la calculadora de ancho
de banda (figura 4.1). Los parámetros a ingresar en la misma son CODEC a utilizar, el tamaño
de la trama (en ms o bytes), protocolos de capa 3 y capa2 (aquí se indica si se desea
compresión de encabezado), si se considera la supresión de silencio y/o el retardo del 5% por
el envío de mensajes RTCP y finalmente el número de canales. Los resultados se presentan
en la tabla 4.16.
Header
Bits Rate BW /cBW Retardo Overhead Ethernet Header
Codec (kbps) (kbps) (ms) RTCP (5%) +Vlan FR MOS
G.711a 64 80 20 84 100,8 4,3 -4,7
iLBC 13,33 24 / 14,6 30 25,2 / 15,33 27,1 / 16,4 4
Tabla 4. 16 Consumo de Codecs Seleccionados
Cada llamada requiere dos flujos RTP, uno para cada sentido de la comunicación. Por tanto, el
ancho de banda por llamada que cursará por la WAN será 2 x 16.4 kbps (se debe trabajar con
compresión de cabeceras IP/UDP/RTP). El ancho de banda total requerido para soportar el
tráfico de voz intersucursal, se presenta en la tabla 4.17.
Oficina Canales BW
Caracas 7 229,6
Puerto Cabello 4 131,2
La Guaira 5 164
Maracaibo (E) 2 65,6
Valencia (E) 3 98,4
Cumaná (E) 2 65.6
Puerto La Cruz (E) 2 65,6
Punto Fijo(E) 2 65,6
Tabla 4. 17 Ancho de banda para Voz Requerido por Oficina
La ejecución de las actividades que conforman esta fase permitieron armar el Diseño de la
Solución de Telefonía IP que permitirá a Servinave actualizar su plataforma telefónica. Las
actividades realizadas fueron las siguientes:
cuente con un servidor Asterisk interconectado con la oficina principal, a través de la red
WAN de la empresa, además de una interconexión directa a la PSTN. Con este esquema se
pretende que el servicio telefónico de la sucursal no dependa de la oficina principal,
garantizando la continuidad del mencionado servicio ante eventuales caídas de la red WAN.
Partiendo de que la VLAN es un método para crear redes lógicamente independientes dentro
de una misma red física, se debe segmentar la red LAN de cada oficina en dos redes lógicas
clase C, tal como se puede apreciar en la tabla 4.18.
Donde XX,YY variarán de acuerdo a cada oficina, tal como se presenta en la tabla 4.19.
Cada localidad debe tener habilitado el servicio de Servidor de DHCP para poder asignar
dinámicamente las direcciones IP cada uno de los hosts, respetando el esquema de direcciones
establecido. En este servidor se debe crear las dos subredes, para que el servidor DHCP
asigne la dirección IP correspondiente a la VLAN a la que pertenece el host.
En las redes tradicionales de paquetes, los paquetes IP son de longitud variable y el tráfico de
datos suele ser a ráfagas. La política FIFO (First Input First Output) es adoptada para el
88
procesamiento de los paquetes, sin aplicar ninguna distinción entre ellos. Los recursos
requeridos para el envío de paquetes son determinados por el orden en el cual éstos llegan y
la política de servicio es conocida como mejor esfuerzo (Best effort), la cual entrega los
paquetes a su destino sin asegurar ni garantizar la entrega. Sin embargo, si la red de paquetes
va a transportar voz (VoIP), es necesario tener ciertas consideraciones en el transporte y
entrega de este tipo de paquetes para asegurarle a aquellas aplicaciones que requieren de la
utilización de un determinado ancho de banda, la disponibilidad de dicho recurso en el
momento que se lo solicite.
En tal sentido, se requiere establecer ciertas políticas o mecanismos que permitan dar
prioridad a cierto tipo de tráfico sensible a retrasos (voz - video) con respecto al resto del
tráfico, de modo que las conversaciones de voz no se vean interrumpidas por las grandes
transferencias de datos. Estas políticas o mecanismos son conocidas como Calidad de
Servicio o QoS (del inglés, Quality of Service). La QoS de extremo a extremo que se
implemente dependerá de la QoS admitida por los routers, switches y por los teléfonos IP
disponibles en la red.
Los teléfonos IP son los terminales del usuario, motivo por el cual resultan críticos para el
éxito del servicio de VoIP. Los teléfonos IP permiten, por lo general, establecer una etiqueta
para que los paquetes que salgan del teléfono la lleven adosada y puedan ser priorizados nada
más al salir, pero una vez que llegan al switch o al router, éste lo procesa como un paquete
más por lo que es fundamental tener priorizado dicho paquete en estos equipos también.
Dependiendo del teléfono IP a utilizar se aplicaran políticas de QoS en switches.
Existen diferentes tipos de teléfonos IP que pueden ser implementados, entre los que se
destacan:
Partiendo de la base de que es necesario separar el tráfico de voz del tráfico de data, hay que
hacer consideraciones según el tipo de teléfono a utilizar.
Existe una característica en los switches 3com llamada voiceVlan que permite, haciendo las
configuraciones pertinentes, asignar automáticamente tráfico voz a la VLAN correspondiente
(VLAN10), optimizando este tráfico tan sensible a las demoras. Esto solo es posible si se
utilizan hardphones /ATAs, ya que el switch identifica que son paquetes de voz porque vienen
de un terminal IP cuya dirección MAC esta registrada en una tabla que consultara para
identificarlo.
Como los softphones no tienen dirección MAC (es decir, su MAC es la misma que el PC). no
es posible registrarlos en la mencionada tabla.En este caso, es necesario que la aplicación
seleccionada tenga opciones de configurar QoS, de tal manera que los paquetes cuando salgan
de PC vayan marcados (tag) y así el switch pueda identificar los paquetes de voz para poder
priorizarlos. En caso de que la aplicación seleccionada no tenga esta característica, en el
90
switch se deberá configurar como puertos TRUNK los puertos de las PCs que utilizarán
softphone para que el switch se encargue de separar la VLANs .
La QoS de capa 3, ya sea DiffServe o Tipo de servicio (ToS), es un sistema que permite
identificar paquetes IP o flujos de tráfico para posteriormente agruparlos. Una vez
identificados, el tráfico se marca en grupos diferentes para que se les puedan aplicar las
directivas de QoS correspondientes. Por ejemplo, el acceso a Web debe presentar una
capacidad de respuesta razonablemente alta, aunque el tiempo de respuesta del correo
electrónico puede variar de segundos a minutos. Las soluciones de telefonía y
videoconferencia IP necesitan un alto nivel de QoS para alcanzar calidad empresarial.
Cisco ha desarrollado una forma de QoS denominada AutoQoS y que tiene como propósito
facilitarle al Administrador de la red el seteo básico de los atributos de QoS. AutoQoS se
encuentra disponible en los routers Cisco IOS desde la serie 2600 hasta la serie 7200 y
también en la mayoría de los routers Cisco que utilizan versiones de IOS 12.2(15)T y
posteriores. AutoQoS ofrece los siguientes beneficios:
• No requiere una comprensión avanzada de QoS del mismo modo que si se desea
configurar desde la línea de comandos.
• Se pueden modificar las políticas de QoS y reutilizarlas, del mismo modo que si se
tratara de un template.
Digium ha desarrollado una familia de tarjetas analógicas PCI y PCI-Express que permiten la
integración de Asterisk con la telefonía analógica clásica, tanto con teléfonos a modo de
extensión como de líneas PSTN de los proveedores. Partiendo de que todas las líneas PSTN
contratadas por la empresa Servinave son de tipo analógico y, de acuerdo al inventario de
líneas, se requerirán las tarjetas indicadas en la tabla 4.20 para interconectar cada oficina con
la red PSTN.
La diferencia entre las tarjetas viene dado por la capacidad máxima de las mismas, las
AEX800P permite hacer combinaciones de puertos FXO/FXS hasta un máximo de 8 en la
misma placa mientras que la AEX2400P permite combinaciones de hasta 24 puertos en total.
Esta última es de mayor dimensión (full-lengh) factor importante al momento de seleccionar
el servidor donde será conectada. Asimismo, la AEX2400P en lugar de tener conectores RJ11
directamente en la tarjeta, requiere un cable amphenol que puede ir conectado a un “breakout
box” o a un patch panel para rack (todo también parte de la solución Digium).
Tanto las tarjetas AEX2400P como las AEX800P permiten incluir módulos de 4 puertos en
cada banco para crear las diferentes configuraciones de FXS/FXO mediante la combinación
de los módulos, ofreciendo una alta escalabilidad a las implantaciones (AEX2400P tiene 6
92
bancos de canales y AEX800P tiene 2). Ambas tarjetas son del tipo PCI-Express. Los
módulos de 4 puertos disponibles son:
• FXS S400M
• FXO X400M
Goncalvez (2007) comenta que la mayoría de los algoritmos de supresión de eco opera
generando múltiples copias de señal, recibiendo cada una atrasada por un pequeño espacio de
tiempo. Este flujo es lo que se conoce como tap. El numero de taps determina el tamaño de
atraso de eco que puede ser cancelado. Estas copias atrasadas son entonces ajustadas y
sustraídas de la señal original recibida. El truco es ajustar la señal atrasada con el valor exacto
de forma de remover únicamente el eco.
4.4.2.2 Servidores
Se sugiere un Servidor IBM de la serie X3200 con 2GB de RAM para cada oficina, cuyas
características están resumidas en la tabla 4.21.
Según Digium, un equipo Dual Intel Xeon 1.8 Ghz 1 Gb Ram soporta 60 llamadas
concurrentes codificando con el codec G.729. Considerando que el CODEC iLBC tiene
características similares al CODEC G729 y que el volúmen de llamadas concurrentes de
Servinave es mucho menor, igualmente se sugiere un equipo con características similares (ver
tabla 4.21).
93
CARACTERÍSTICAS DESCRIPCIÓN
Formato y Altura Torre / Tower 5U
CPU Ghz/FB MHz máxima. Intel Xeon Pentium® Dual Core 1.87 Ghz / 1066 MHz
CentOS es un clon a nivel binario de la distribución Red Hat Enterprise Linux RHEL,
compilado por voluntarios a partir del código fuente liberado por Red Hat. Es una distribución
estable con una sólida comunidad de usuarios que lo utilizan y hacen posible la existencia de
gran cantidad de foros con preguntas y respuestas basadas en esta distribución. Sin embargo,
es importante resaltar que ”Asterisk funciona perfectamente bajo cualquier distribución“.
4.4.2.4 Asterisk
La versión estable de Asterisk a utilizar está compuesta por los módulos siguientes:
4.4.2.5 Teléfonos IP
En el diseño de esta solución se van a utilizar hardphones como sustitutos de los aparatos
telefónicos propietarios que existen actualmente en la empresa y dispositivos ATAs para
interconectar a la red IP los teléfonos analógicos que ya se poseen. Los softphone serán
considerados como alternativa únicamente para aquellos usuarios que se trasladan entre las
sucursales (usuarios móviles) y para los usuarios del departamento de tecnología.
Para el caso de los hardphones/ATA, se debe considerar que tengan 2 puertos Ethernet,
cuando sea necesario compartir el punto de red de la PC con el teléfono. Las propiedades a
evaluar en los teléfonos seleccionados para esta propuesta son:
Los hardphones seleccionados para los usuarios, son los equipos de la marca Linksys SPA
901, SPA 921 y SPA922, porque cumplen con las características anteriores y el precio es
razonable.
Para la operadora, se considero agregar un módulo extensión Linksys, para que cuente con
mayor número de teclas programables.
95
En cuanto a los softphones, existe una gran variedad que pueden ser descargados de Internet.
Particularmente se seleccionó Zoiper porque permite configurar los valores para QoS, toda
vez que es compatible con los CODECs considerados para el diseño, y, además de soportar el
protocolo de señalización SIP, soporta también el protocolo de señalización IAX (nativo de
Asterisk). Para estos casos, se sugieren auriculares diseñadas para VoIP, que se conecten vía
puerto USB. Los modelos propuestos son AUDIO 615USB (monoaural), 625USB (biaural),
630USB (biaural y estereo) y CS50USB inalámbrico, todos de la marca Plantronics. Esta
variedad responde a si se desea tener o no las dos orejas cubiertas, si se desea escuchar mejor
calidad de música y para la fácil movilización (inalámbrico). Este último está pensado
principalmente para el personal de soporte técnico y/o para cualquier otro que, por sus
actividades, requiera desplazarse continuamente por la oficina. En todo caso el auricular
seleccionado debe incluir micrófono con anulación de ruido y la característica de eliminación
del eco. En la tabla 4.22 se puede apreciar un resumen de los modelos sugeridos para el
diseño.
HARDPHONES
SPA901 1 puerto ethernet / sin pantalla
SPA921 1 puerto ethernet / con pantalla
SPA922 2 puertos ethernet / con pantalla
SPA932 2 puerto ethernet + modulo expansión
Polycom SStation2 Display NE Terminal Audioconferencia con pantalla marca POLYCOM
ATA
Linksys PAP2 1 puerto ethernet + 2 Rj11
SOFTPHONES
ZOIPER Version gratuita / paga dependiendo de las necesidades del usuario
HEADSET / AURICULARES
AUDIO 610USB/ 615USB Monoaural
AUDIO 630USB Biaural/estereo
CS50USB Inalámbrico
Tabla 4. 22 Modelos de Teléfonos Sugeridos
96
Los equipos de Fax, por ser equipos de tipo analógico se conectaran a la red a través de
dispositivos ATAs. En este caso, estos equipos deben ser compatibles también con el estándar
T.38 .
Servinave, en algunas de sus sucursales, así como en la principal, cuenta con planta eléctrica
de emergencia responsable de suministrar servicio eléctrico a la oficina, en caso de
interrupción del servicio eléctrico público. Sin embargo, para aquellas oficinas donde no esta
implementada una o existen intermitencias en el servicio, se recomienda contar con un UPS
por puesto de trabajo para que el servicio se mantenga operativo todo el tiempo. Considerando
que un pc tiene un consumo aprox 8 amp (con monitor) y el teléfono IP/ATA consume max 2
amp, el UPS a considerar por puesto debe ser de al menos 1100va (ver tabla 4.23).
UNIDADES AMP
CPU 6
Monitor 1,5
Telefono IP 2
TOTAL 9,5
9,5A * 115V = 1092,50va
Tabla 4. 23 Cálculo de consumo Eléctrico por Puesto de Trabajo
97
Asimismo, los servidores Asterisk deben estar protegidos por UPS On Line, que provea
alimentación constante desde su batería y no de forma directa. Esta tecnología es la que ofrece
el mayor nivel de protección, por lo tanto es ideal para equipos sensibles o importantes como
servidores centrales.
PRECIO
ITEM CANTIDAD (BSF) TOTAL (BSF)
Servidor IBM 8 5.100,00 40.800,00
Tarjetas AEX2400 4 9.438,00 37.752,00
Tarjetas AEX800P 5 4.128,00 20.640,00
Los contextos son agrupaciones lógicas de extensiones y se utilizan para dividir el dialplan en
diversos entes lógicos. Esta división es necesaria para hacer del dialplan mantenible. Cuando
Asterisk recibe una llamada, de entrada o de salida, esta pertenece a un contexto. A cuál
contexto pertenece, dependerá del canal que vea la llamada.
En forma general, el IVR de cada oficina deberá seguir los pasos especificados en figura 4.2.
100
El objetivo es realizar una prueba con un grupo acotado de usuarios, para poder probar el
diseño propuesto, así como medir los resultados e identificar los ajustes necesarios para que
este modelo pueda implantarse a gran escala, sin afectar la operatividad de la empresa
mientras se realizan estos ajustes.
Las oficinas seleccionadas para realizar la prueba piloto fueron las oficinas de Caracas y de
Puerto Cabello, específicamente los departamentos de sistemas y administración, de cada
oficina (total 7 personas). Se seleccionaron estas oficinas porque son las que disponen de
mayor ancho de banda.
Sin embargo, por ser una prueba piloto, cada oficina interconectará el servidor Asterisk con
la central telefónica Siemens existente, a través de puertos FXS/FXO, tal como se puede
apreciar en la figura 4.4.
• Dos clones tipo torre, 2 GB RAM, 1 slot PCI-E, 2 slot PCI, 160 GB disco duro, tarjeta
madre modelo 945GCM-S/M/ASR.
• Tarjetas de telefonía DIGIUM analógicas modelos AEX2400, 20 puertos FX0 y 4
puertos FXS
• Cancelador de eco por software MG2
• Teléfonos Linksys SPA922 y softphone Zoiper v2.0
• Headset Plantronics 610USB, 630USB, 615USB
• CentOS 5.3 con kernel 2.6.18-128.1.10.el5
• Asterisk 1.4.24.1
• Cuatro líneas analógicas CANTV en cada oficina
• Cuatro extensiones analógicas de la central Siemens en cada oficina.
• Cuatro puertos troncales en la central Siemens de cada oficina.
En está actividad se fueron realizando las diferentes configuraciones necesarias para alcanzar
las funcionalidades requeridas.
104
Tanto en la oficina de Caracas como en la oficina de Puerto Cabello tienen switches 3Com
modelo 4500. En cada uno se habilitó la característica voiceVlan para que el switche asignara
automáticamente los paquetes de voz a la Vlan 10, en aquellos puertos que son compartidos
por el PC y el teléfono. Aquellos telefonos IP que estan directamente conectados al switch,
como solo envían paquetes de voz, el modo de asignación fue manual.
En caso de no haber instalado las librerías requeridas para compilar el código de Asterisk al
momento de realizar la instalación del sistema operativo se pueden introducir los siguientes
comandos en una cónsola del equipo (debe disponerse de conexión a Internet):
• yum install ncurses ncurses –devel
106
Validar que los paquetes se hayan instalado de la manera adecuada: al ejecutar yum –C list
ncurses ncurses-devel openssl zlib zlib-devel curl gcc y debe aparecer:
• curl.i686 instalado
• ncurses-devel.i386 instalado
• openssl.i686 instalado
• zlib.i386 instalado
• zlib-devel.i386 instalado
PAQUETE COMANDOS
make clean
Libpri
make install
Make all
Dahdi make install
make config
./configure
make menuselect
Core Sounds Packages
Seleccionar (EN-ALAW y ES-ALAW)
Music on Hold Packages
Seleccionar (ES-ALAW)
Extra sound packages
Asterisk
Seleccionar (EN-ALAW)
make
make install
make config
make samples
rm /etc/asterisk/extensions.ael
service asterisk start
./configure
Asterisk-Addons make
make install
Tabla 4. 27 Orden de Compilación Paquete Asterisk
Asimismo, ejecutar los comandos cat /proc/interruptions (figura 4.6). y lspci –vvvv ( figura
4.7) para validar que no haya conflicto de interrupciones.
En las figuras 4.6 y 4.7 se puede observar que el sistema operativo asignó la IRQ 169 a la
tarjeta Digium; sin embargo, también se puede apreciar que esta IRQ la esta compartiendo con
otros dispositivos como puertos usb y Hda-Intel (sonido integrado de la tarjeta). Para evitar
esto, se procedió a deshabilitar los puertos USB desde la Bios y se removió el módulo de hda-
intel con el comando: rmmod snd-hda-intel (que es el driver del dispositivo hda-intel).
procesador 1 y el resto por el procesador 0 (ver figura 4.8). Para dejar fijo este cambio
se editó el archivo /etc/rc.d/rc.local y se agregó la instrucción en cuestión.
PARAMETRO DESCRIPCIÓN
loadzone=ve loadzone permite configurar el canal para que utilice las indicaciones de tonos como
defaultzone=ve el marcado, ocupado, etc. Para el país indicado. El defaultzone se utiliza en caso de
no indicar el loadzone para algú,n canal.
fxsks=1-20 Indica que los canales del 1-20 utilizarán señalización fxs, bajo el protocolo
Kewlstart (ks)
Fxoks=21-24 Indica que los canales del 21-24 utilizarán señalización fxo, bajo el protocolo
Kewlstart (ks)
echocanceller=mg2,1-24 Indica que se utilizará el cancelador de eco por software MG2 en todos los canales.
Tabla 4. 28 /etc/asterisk/system.conf
111
Figura 4. 9 /etc/asterisk/chan_dahdi
Existen varios comandos que son útiles para revisar el hardware instalado, entre ellas está:
Como se puede apreciar en la tabla 4.29, la primera sección, identificada como general, define
las opciones generales del servidor como la dirección IP y el puerto al que hacer el bind, es
decir, el puerto donde Asterisk escuchará a las llamadas entrantes. Las siguientes secciones
definen parámetros del cliente como el username, password u otras.
PARÁMETRO DESCRIPCION
[general] Sección donde se definen variables globales y aspectos por defecto para todos
los canales SIP.
language=es Selección del lenguaje español.
dtmfmode= rfc2833 Permite especificar el método por el cual se enviaran los tonos (dígitos pulsados
durante la conversación). El parámetro AUTO indica que debe negociar con el
par del otro extremo. rfc2833 permite mandar os tonos dtmf como RTP
port=5060 Puerto de conexión por donde el servidor aceptará la conexión
bindaddr=0.0.0.0 El servidor recibirá conexiones en todas sus interfaces
srvlookup=yes Parámetro que permite acceder a los servidores por nombre de dominio
disallow=all Se deshabilitan todos los codecs y luego se habilitan en orden de preferencia
allow=alaw
allow=iLbc
Tabla 4. 29 Sección General del Archivo Sip.conf
A continuación de la sección general, se define cada cliente SIP, el cual esta identificado por
un bloque de texto con un nombre encerrado entre corchetes (típicamente la extensión). Los
parámetros empleados se resumen en la tabla 4.30.
115
PARÁMETRO DESCRIPCION
type=friend Tipo de cliente SIP. Puede tomar el valor de: Friend: Puede tanto recibir como realizar
llamadas a través del sistema Asterisk. User: Puede recibir llamadas mas no puede hacer
llamadas. Peer: Pueden hacer llamadas pero no pueden recibir llamadas a través del
sistema Asterisk
context=phones Contexto por defecto donde ingresarán las llamadas entrantes. Este contexto se define en
extensions.conf
host=dynamic El host tiene dirección dinámica
secret=1234 Password de sesión
callgroup=1 Le asigna un grupo a la extensión. Ejemplo: es miembro del grupo 1
pickupgroup=1 De que grupo puede hacer captura esta extensión. Pueden ser varios.
disallow=all Deshabilitar todos los codecs
allow=ulaw Codec habilitados en orden de preferencia. Para el caso de las extensiones locales el valor
allow=gsm sera uLAw. Si es comunicación con otra localidad se coloca iLBC. Gsm para escuchar
los mensajes grabados
canreinvite=no Tipicamente “NO” si se encuentrra destrás de un NAT. De este modo se habilita que el
tráfico RTP pase por el servidor Asterisk.
call-limit=1 Número de llamadas simultáneas que se pueden realizar en esa extensión
dtmfmode= rfc2833 RFC2833 permite mandar los tonos dtmf como RTP.
mailbox=530@defa mailbox 530 en el contexto "default" del archivo voicemail.conf
ult
language=ve Define las señales para un país. Debe estar presente en el archivo indications.conf
Tabla 4. 30 Sección de Clientes del Archivo Sip.conf
A cada una de las extensiones definidas en el archivo sip.conf le fue asignado el grupo al que
pertenecen y a los que pueden hacer captura de llamadas (mediante la tecla *8 definida en el
archivo features.conf por defecto) de acuerdo a la tabla 4.31.
116
Rango
Departamento Grupo
Extensiones
Recepción 500-509 1
Multifuncionales 2
Salas Conferencia 3
Gerencia 510-514 4
Estadisticas 515-519 5
Mercadeo 520-529 6
Operaciones 530-539 7
Sistemas 540-549 8
Ofidemo 550-554 9
Cobranzas 555-560 10
Analisis 560-569 11
Contabilidad 570-579 12
Administración 580-589 13
Tabla 4. 31 Extensiones y Grupos de Captura
[general]
languaje=es
register=>CCS01:1234@192.168.32.24
[PBL01]
type=friend
host=192.168.32.24
secret=1234
context=phones
trunk=yes
disallow=all
allow=ilbc
117
[general]
languaje=es
register=>PBL01:1234@192.168.30.24
[CCS01]
type=friend
context=phones
secret=1234
host=192.168.30.24
trunk=yes
disallow=all
allow=ilbc
Se comprobo el éxito de los registros ejecutando desde el CLI de Asterisk “IAX2 SHOW
REGISTRY”; asi mismo se obtuvo una lista de los clientes que se han registrado en el
servidor con “IAX2 SHOW PEERS” (ver figura 4.13).
Los valores reflejados indican el tiempo de conversión de formatos (en milisegundos) para un
segundo de data .
119
El archivo extensions.conf tiene una sección [general] y otra [global]. La primera establece
algunas opciones respecto a como se tratar el dialplan y en la segunda, se definen las variables
globales (o constantes) y sus valores iniciales.
[general]
static=yes
writeprotect=yes
autofallthrough=yes
clearglobalvars=no
priorityjumping=no
[globals]
• Static: Si se define como 'yes' permite salvar el dialplan desde la cónsola de Asterisk.
• Writeprotect: Protección frente a escritura, si se deja como 'no' comandos como 'save
dialplan' modificaran los ficheros de configuración.
• Autofallthrough: Si está activada esta opción, cuando una extensión haya acabado de
ejecutar sus prioridades, o la lógica salte a una prioridad inexistente, hará que la
llamada se cuelgue, señalizandola como BUSY (ocupada), CONGESTION o
HANGUP dependiendo de cuál sea la mejor opción para Asterisk.
120
Después de estas dos secciones, estarán aquellos contextos que se necesitan para armar el
dialplan. Las dos reglas de oro de los contextos son:
• Una extensión solo puede marcar a números que están dentro del mismo contexto.
• El contexto de una comunicación es definido por el canal de entrada de comunicación
(ver figura 4.15).
1) Para trabajar con los patrones de marcado del país, se definieron los siguientes patrones
dentro de los contextos correspondientes (ver tabla 4.32):
121
2) Para enrutar ls llamadas entrantes a través del IVR se definió el contexto Entrantes. IVR
se refiere a los menúes con los que el usuario puede interactuar mediante pulsaciones
DTMF (Tonos de diferente frecuencia que son generados por un telefono al pulsar una
tecla del mismo ). El contexto Entrantes contiene una la llamada al contexto IVR-PPAL,
que es el que ejecuta el saludo de bienvenida e informa el menú de opciones
correspondientes, según el horario de la llamada y de acuerdo al diagrama que se
especificó en la figura 4.2. Asimismo, incluye una llamada al contexto Internas para
poder transferir las llamadas entrantes a cualquiera de las extensiones de Asterisk.
.
[Entrantes]
include => IVR-Ppal
include => Internas
3) Para poder restringir las llamadas salientes de las extensiones a la PSTN, se definieron
los siguientes contextos:
a) SoloInternas: Permite realizar llamadas a números abreviados, entre extensiones
definidas en el servidor Asterisk local y de cualquier otra oficina de la empresa,
números de información o emergencia de la PSTN (tales como 119, 155, 911, etc),
números 0800, 0500 y a extensiones en la central Siemens.
122
[Asterisk-PBL01]
exten =>_2425XX,1,set(GROUP()=pbl)
exten =>_2425XX,n,Gotoif($[${GROUP_COUNT(pbl)}>5]?revento)
exten =>_2425XX,n,Dial(IAX2/PBL01/${EXTEN:3},35,Tt)
exten =>_2425XX,n,Hangup
exten =>_2425XX,n(revento),Dial(DAHDI/g1/2423630909,35,Tt)
6) El método estándar para realizar conferencias es con la aplicación Meetme(). Para poder
hacer uso de esta aplicación se debió incluir ésta en el archivo extensions.conf la
123
extensión 900 fue creada para la sala de conferencia, dentro del contexto conferencia, con
una contraseña predefinida que el usuario deberá ingresar cuando desee hacer uso del
servicio.
7) Se creó el contexto voicemail, que define la extensión 921como la ext a donde el usuario
puede llamar para escuchar los mensajes de voz que le han dejado las personas que lo han
llamado (también recibirá la notificación y el mensaje por correo electrónico).
8) Se creó la extensión 922 dentro del contexto música, a donde se llamará cuando se desee
evaluar la música en espera.
9) Se creó el contexto parqueo que incluye la declaración include => parkedcalls, para
habilitar el servicio de parqueo de llamadas (obligatorio, si se desea habilitar este servicio).
El módulo de buzón de voz permite definir buzones para cada usuario, asi como compartir un
mismo buzon entre varios usuarios. Otra característica interesante es que el servidor puede
enviar un correo electrónico avisando que se ha recibido un mensaje nuevo y adjuntar el
mismo como un anexo del correo.
Para la configuración de estos buzones se debe editar el archivo voicemail.conf, que siguiendo
con la estructura habitual de los archivos de configuración de Asterisk, contiene una sección
general y distintas secciones para distintos contextos.
En la sección general se puede definir el formato en que se van a grabar los mensajes (wav,
gsm, entre otros) o el formato de los correos electrónicos de aviso de nuevos mensajes. Para
definir el formato de los correos, se dispone de las siguientes variables:
[general]
format=wav
serveremail=asterisk@servinave.com
attach=yes
maxmessage=180
minmessage=3
maxgreet=60
skipms=3000
maxsilence=10
silencethreshold=128
maxlogins=3
fromstring=Asterisk
pagerfromstring=Asterisk
searchcontexts=yes
envelope=no
;
emailsubject= PBX: Tienes un nuevo mensaje en el buzón ${VM_MAILBOX}
;
Los buzones de voz se definieron dentro de un contexto. Estos contextos no tienen relación
con los contextos definidos en el plan de marcado (dialplan) , sino que son una forma de
separar buzones. Específicamente para Servinave, fue suficiente con tener un único contexto
“default” con todos los buzones.
Se definieron los siguientes parámetros para cada buzón : contraseña, nombre y correo
electrónico. Ejemplo:
[default]
571 => 1234, Adriana Sanchez, asanchez@servinave.com
En el archivo sip.conf se hace referencia a este buzón con el parámetro Mailbox=530@default
Como se mencionó, el IVR es el conjunto de menus con los que el usuario va a interactuar
mediante pulsaciones DTMF. Para crearlo, se debió generar los sonidos que se van a
reproducir. Estos sonidos, que corresponden al saludo personalizado de la empresa (según el
horario) y al conjunto de opciones al usuario, deben ser ubicados en el directorio
/var/lib/asterisk/sounds en un formato reconocido por Asterisk.
Para no entrar en un bucle infinito se suelen fijar dos tipos de retardo: tiempo interdigito y el
tiempo de respuesta: ejemplo:
Set(TIMEOUT(digit)=3)
126
Set(TIMEOUT(response)=9)
Una vez que el usuario empieza a teclar una opción, el tiempo máximo permitido entre
dígitos sera TIMEOUT(digit). Si pasa este tiempo desde el último digito tecleado, el sistema
considera que el usuario ha terminado de teclear el numero de la opción y salatará a esa
extensión (u opción). Si no existe saltará a la extesión “i”.
Por otra parte, si el usuario no empieza a teclear una opción en el tiempo indicado en
TIMEOUT(response), el IVR saltará a la extensión “t”.
i: Invalid: Usado cuando se disca una extensión desconocida en el contexto o a una entrada
desconocida en un menu.
s: Start. Usado para planos de discado que entran en un contexto sin información previa
(como el identificador de llamadas).
h: Hangup. Usado para limpiar una llamada. Puede ser usado para sonar un mensaje de
despedida antes de colgar.
t: Timeout. Tiempo esperado antes de ejecutar una acción.
T: AbsoluteTimeout. Usado para llamadas que hayan sido colgadas debido a que las alcanzó
el AbsoluteTimeout(). Es últil, por ejemplo, para hacer sonar una notificación Playback()
i: Invalid: Usado cuando se disca una extensión desconocida en el contexto o a una entrada
desconocida en un menu.
O: Operador. Extension del operador. Usado para la salida presionando o en el buzón de
correo.
El contexto que contiene las secuencia de instrucciones para el IVR para los servidores
Asterisk, es el siguiente:
[IVR-Ppal]
127
exten=>s,1,gotoiftime(7:30-16:30|mon-sat|*|*?EnHorario)
exten=>s,n,background(/var/lib/asterisk/mismensajes/saludo-noche)
exten=>s,n,voicemail(500,s)
exten=>s,n,hangup()
exten=>s,n,DigitTimeOut(7)
exten=>s,n,responsetimeout(10)
exten=>s,n(EnHorario),background(/var/lib/asterisk/mismensajes/bienvenida-dia)
exten=>s,n,waitexten(6)
exten=>2,1,queue(Mercadeo)
exten=>2,n,hangup
exten=>3,1,queue(Ofidemo)
exten=>3,n,hangup
exten=>4,1,queue(Operaciones)
exten=>4,n,hangup
exten=>6,1,goto(IVR-Areas-Adminis,s,1)
exten=>6,n,hangup
exten=>7,1,queue(Sistemas)
exten=>7,n,hangup
exten=>fax,1,Dial(Iax2/iaxmodem)
exten=>t,1,Dial(SIP/500,30,Tt)
exten=>i,1,playback(invalid)
exten=>i,n,goto(s,n(EnHorario))
[IVR-Areas-Adminis]
exten=>s,1,background(/var/lib/asterisk/mismensajes/areas-adminis)
exten=>s,n,waitexten(6)
exten=>1,1,queue(Admon)
exten=>1,n,hangup
exten=>2,1,queue(Analisis)
exten=>2,n,hangup
exten=>3,1,queue(Cobranza)
128
exten=>3,n,hangup
exten=>4,1,queue(Contab)
exten=>4,n,hangup
exten=>5,1,queue(Estadistica)
exten=>5,n,hangup
exten=>9,1,goto(bienvenida-dia,s,1)
exten=>9,n,hangup
exten=>t,1,goto(s,1)
exten=>t,n,hangup
exten=>i,1,playback(invalid)
exten=>i,n,goto(s,n(EnHorario))
• Si las llamadas entran fuera de horario de oficina, el IVR informará cuál es el horario
de trabajo y le permitira dejar un mensaje.
• Si está dentro del horario de oficina, y solicita un departamento, el IVR enrrutará la
llamada a la cola que corresponda .
• Las colas utilizadas son definidas como estáticas, porque están integradas siempre por
las mismas extensiones, es decir, los miembros de cada cola son las extensiones SIP de
los integrantes de cada dpto.
• La estrategia de distribución de estas llamadas fue definido como ROUND ROBIN en
el archivo queue.conf . Esta estrategia permite enviar llas llamadas por orden a los
miembros de la cola.
[Sistemas]
strategy=roundrobin
timeout=10
retry=5
maxlen= 0
music=default
member=>SIP/540
member=>SIP/541
member=>SIP/542
member=>SIP/543
129
member=>SIP/544
member=>SIP/545
member=>SIP/546
member=>SIP/547
member=>SIP/549
A parte de los archivos mencionados, también fue necesario modificar otros para
complementar las funciones que se perseguían en plan de marcado.
• Se crearon las colas estáticas de atención del IVR en el archivo queues.conf, para
dirigir las llamadas atendidas por éste al departamento seleccionado, según la opción
marcada por el llamante. Se configuró la estrategia “roundrobin” para distribuir las
llamadas igualmente entre los miembros de la cola del departamento. Los miembros de
las colas son canales SIP directos (extensiones de los usuarios del departamento).
Para dar inicio a las pruebas se configuraron los teléefonos IP y un softophone para poder
establecer comparación de calidad durante el período de prueba.
Para configurar, conectarse vía http a la direccion IP del teléfono. Para conocer la dirección IP
del teléfono, como la misma fue asignada dinámicamente por el servidor DHCP, consúltela
directamente desde el menú del teléfono.
Para este caso, la dirección asignada es 192.168.30.81, coloque entonces desde la barra de
direcciones del explorador http://192.168.30.81, seleccione la opción Ext1 desplegada en la
parte alta del navegador. En la nueva pantalla configure los valores especificados en la tabla
4.33.
PARÁMETRO VALOR
Proxy 192.168.30.24 (ip del servidor Asterisk al que desea conectarse)
Display Name Adriana Sanchez
UserID 571 (numero extensión) definida en esip.conf
Password 1234 Coontraseña definida en sip.conf
Use DNS SRV Yes
DNS SRV Auto Prefix Yes
Tabla 4. 33 Configuración Hardphone
131
Luego, de debe validar que el codec preferido sea g711a y validar los cambios (ver figura
4.16).
• Seleccionar crear una cuenta SIP (click en add sip account) y colocar el la dirección IP
del servidor Asterisk, el numero de extensión asignada y el password. (ver figura
4.18).
• Seleccionar los CODECs correspondientes. En este caso iLBC y aLAW (ver figura
4.20)
133
El que los usuarios no supieran cuando están hablando por la red WAN y cuando por la
PSTN ayudó a que éstos reportaran consecuentemente las fallas encontradas en vez de
simplemente decidir no utilizarlo. Al no saber que hay dos sistemas funcionando permite que
los dos convivan sin que el usuario tenga preferencia sobre uno u otro, lo cual fue importante
para la etapa de prueba.
La integración de la red de voz y datos hace mas compleja la administración de la red, ya que
se debe necesariamente trabajar con calidad de servicio para el tratamiento adecuado de los
paquetes de voz y, la calidad de servicio, es un tema extenso, complejo y de poco dominio
por parte de muchos administradores de redes, lo que hace indispensable contar con personal
calificado (y en continua formación) para esta área. Asimismo, cualquier falla que ocurra en
la red afectará ambos servicios, lo que tradicionamelnte no sucedía.
Desde el punto de vista humano, las pruebas realizadas con softphone permitieron conocer la
reacción del usuario ante un eventual cambio. En algunos usuarios fue favorable y en otros no,
aunque inicialmente fueron receptivos con la idea. Esta situación varia mucho de oficina a
oficina, pero, aunque el diseño propuesto sugiere hardphone, es posible mezclar el uso de
softphone y hardphone en la solución, considerando siempre la actividad del usuario, para no
intevenir negativamente en el desenvolviendo de sus labores cotidianas.
Sin embargo, desde el punto de vista técnico, el softphone es una aplicación mas del PC y por
ende depende del rendimiento de éste. Si el equipo tiene aplicaciones agresivas o pesadas, y el
PC no está correctamente dimensionado, hacer una llamada puede representar toda una
136
pesadilla y en consecuencia, generar rechazo hacia el proyecto. Asimismo, voz y datos estan
separadas en dos VLANs, cuando utilizan softphone deben realizar ajustes en los parámetros
de calidad de servicio para poder identificar cuando el PC envia datos y cuando voz para
asignar los paquetes a la VLAN correspondiente, lo que incrementa la complejidad.
Desde el punto de vista económico, Asterisk representa una actualización del área de telefonía
a un costo moderado, sin contar el abanico de posibilidades que se le abre a la empresa. Sin
embargo, cabe preguntar ¿ Requiere la empresa toda esta cantidad de funcionalidades que
obliga a comparar a Asterisk con una central convencional de dimensiones mayores (para
comparar justamente) pero que en realidad no necesita en estos momentos? La respuesta es
absolutamente SI. En muchas ocasiones las empresas descartan ciertas funcionalidades en las
PBX que las pueden ayudar, porque el costo de hacerlas es prohibitvo. Para hacer una
comparación pequeña, si Servinave deseara instalar un E1 para sustituir las líneas analógicas
que actualmente tiene en la oficina de Caracas, el costo de la tarjeta para la central Siemens es
aproximadamente trece mil BsF, mientras que la E1 Digium TE121BF para Asterisk cuesta
521$. A esto hay que sumarle indiscutiblemente que la VoIP es una tendencia mundial
irreversible que hace ilógico invertir, hoy en día, en las centrales tradicionales.
137
CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
5.1 Conclusiones
Con la implementación de este diseño, la Empresa podrá contar con todas las funcionalidades
de una PBX, en todas sus sucursales.
Se concluye que este diseño funciona y es conveniente para la empresa, pero depende en gran
medida en como se haga la implementación y se tomen en cuenta las recomendaciones antes
de realizarlo.
5.2 Recomendaciones
Es necesario analizar los puntos suceptibles de ataques y hacer una valoración inicial del
estado de la seguridad en las instalaciones VoIP, para no abrir brechas de seguridad, antes de
realizar la implementación.
Aunque la reducción del gasto telefónico se podrá apreciar en la factura mensual del
proveedor de servicio, debe contemplarse la instalación de una aplicación que gestione la
tarificación telefónica, pues para la empresa es sumamente importante tarificar este servicio
por extensión.
138
Es necesario revisar los ancho de banda contratados. Aquí solo se está cursando el tráfico que
el ancho de banda actualmente contratado puede soportar.
Siempre que el costo lo permita, se recomienda hacer uso de canceladores de eco por hardware
ya que los de software consumen una cantidad sustancial del CPU.
Hay que tener especial cuidado en la implementación. Es recomendable hacerla por etapas
para ir ajustando particularidades que surgan en cada oficina. La implementación de Asterisk
en una oficina puede consolidar o rechazar el proyecto para el resto de las oficinas.
Se recomienda ir sustituyendo los switches actuales por switches con PoE. Asimismo, se
recomienda considerar comprar los teléfonos IP que soporten esta característica.
139
REFERENCIAS
Van Meggelen, J., Smith, J. y Madsen, L (2007). Asterisk the Future of Telephony. Segunda
edición.. Estados Unidos: O’Reilly Media, Inc.
Digium Inc. Digium 2400 series AEX2400/TDM2400P User Manual. Extraído el 24 de abril
de 2009, desde http://docs.digium.com/AEX2400/2400series_manual.pdf.
Spencer, R. (2008). PCI Card Common instalations issues. Extraído el 24 de abril de 2009
desde http://www.novavox.co.uk/docs/install-guides/novavox-asterisk-card-installation-
issues.pdf.
Cisco System (2007). Traffic Analysis for VoIP v-3. Extraído el 15 de marzo de 2009 desde
http://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/TA_ISD.html.
Spencer, M., Allison, M. Y Rhodes, C. (The Asterisk Documentation Team) (2003) . The
Asterisk handbook, version 2. Extraído el 24 de enero de 2009 desde
http://www.digium.com/handbook-draft.pdf.
140
Cotúa, J. (2009). Guía del curso VoIP y Telefonía IP . Atel Consultores. Caracas.
Vilares, F. (2008). Guía del curso Bootcamp Asterisk . Netsecurity Solutions Bogotá.