Universidad Simón Bolívar

UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS DE POSTGRADO

COORDINACIÓN DE POSTGRADO EN INGENIERÍA ELECTRÓNICA
ESPECIALIZACIÓN EN TELEMÁTICA
TRABAJO ESPECIAL DE GRADO
DISEÑO DE UNA SOLUCIÓN DE TELEFONÍA IP BASADA EN

ASTERISK PARA SERVINAVE,C.A.
por
ADRIANA SÁNCHEZ BOUZAS
Octubre, 2009

ASTERISK PARA SERVINAVE, C.A.
Trabajo Especial de Grado presentado a la Universidad Simón Bolívar por
Adriana Sánchez Bouzas
Como requisito parcial para optar al grado académico de
ESPECIALISTA EN TELEMÁTICA
Con la asesoría del prof. Wilmer Pereira
Octubre 2009
ii


Por: Sánchez Bouzas Adriana

Carnet No.: 0685712
Este Trabajo Especial de Grado ha sido aprobado en nombre de la

Universidad Simón Bolívar por el siguiente jurado examinador:
__________________________________
Profa. Vidalina De Freitas
Presidente
__________________________________
Profa. Mónica Huerta
Miembro Principal
__________________________________
Prof. Wilmer Pereira
Miembro principal – Tutor
16, Octubre, 2009

iii
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 Chino, por todo el apoyo brindado en este exquisito camino de aprendizaje.
A mis padres, porque siempre me impulsaron a cumplir mis metas.
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


Por: Sánchez Bouzas Adriana

Carnet No.: 0685712
Tutor: Wilmer Pereira
Octubre, 2009
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
2.6 CODEC ............................................................................................................................19

2.6.1 Funcionamiento del CODEC……………………………………………………..20
2.6.1.1 Muestreo……………………………………………………………………..20
2.6.1.2 Cuantificación………………………………………………………………..21
2.6.1.3 Codificación………………………………………………………………….21
2.6.2 Tipos de CODEC…………………………………………………………………21
2.6.2.1 ITU-T G.711…………………………………………………………………22
2.6.2.2 ITU-T G.723.1……………………………………………………………….22
2.6.2.3 ITU-T G.726…………………………………………………………………22
2.6.2.4 ITU-T G.729…………………………………………………………………22
2.6.2.5 Ilbc…………………………………………………………………………...23
2.6.2.6 GSM………………………………………………………………………….23
2.6.2.7 SPEEX……………………………………………………………………….24
2.6.3 Parámetros de los CODEC……………………………………………………….24
2.7 Factores que Afectan la Calidad de la Voz .....................................................................25
2.7.1 Latencia / Delay (Retraso)………………………………………………………...26
2.7.2 Jitter……………………………………………………………………………….27
2.7.3 Pérdida de Paquetes…………………………………………..………….………..28
2.7.4 Eco………………………………………………………………………….……..28
2.8 Arquitectura de los Protocolos de VoIP..........................................................................29
2.8.1 Protocolo de Señalización H.323…………………………………………………30
2.8.1.1 Componentes de una red H.323……………………………………………...30
2.8.1.2 Establecimiento de una llamada en H.323……………………….………….32
2.8.2 Protocolo de Señalización de Inicio de Sesión SIP…………………….…………35
2.8.2.1 Componentes de una Red Basada en SIP……………………………………38
2.8.2.2 Direccionamiento SIP………………………………….…………………….41
2.8.2.3 Mensajes…………………………………………….……………………….42
2.8.2.4 Headers o Cabeceras………………………………………………………...45
2.8.2.5 Cuerpo del Mensaje………………………………………………………….46
2.8.2.6 Proceso de una Llamada en SIP……………………………………………...47
2.8.3 Protocolo de Señalización de Intercambio Inter Asterisk (IAX)………….………48
viii
2.8.3.1 Tramas o Mensajes IAX……………………………………………………49

2.8.3.2 Proceso de una llamada en IAX……………………………………………..50
2.8.4 Protocolos de Transporte……………………………………………...…………..51
2.8.4.1 Real-time Transport Protocol (RTP)………………………………………...52
2.8.4.2 Real-time Transport Control Protocol (RTCP)……………………………...52
2.8.4.3 Protocolo de Flujo de Datos en Tiempo Real RTSP (Real Time Streaming
Protocol)……………………………………………………………………………..54
2.9 Consideraciones para el Cálculo de Ancho de Banda......................................................54
2.9.1 Retardo…………………………………………………………………………...57
2.9.1 Otros Factores…………………………………………………………………….58
2.10 Asterisk...........................................................................................................................58
2.10.1. Arquitectura Asterisk……………………………………………………………59
2.10.2 Componentes del Paquete Asterisk……………………………………….……..62
2.10.3 Directorios creados por el Paquete Asterisk……………………………….……63
CAPÍTULO III: METODOLOGÍA...........................................................................................64
3.1. Tipo de Investigación…………………………………………………………………...64
3.2. Técnicas de Recolección de Datos………………………………………...……………64
3.3 Metodología a Utilizar…………………………………………………………………...65
CAPÍTULO IV: DESARROLLO..............................................................................................68
4.1 Marco Organizacional ......................................................................................................68
4.2 Recolectar Información ...................................................................................................70
4.2.1 Revisión Bibliográfica…………………………………………………………70
4.2.2 Identificación de Funcionalidades Necesarias por cada Sucursal/Principal…...71
4.2.3 Revisión de la Infraestructura Actual………………………………………….72
4.2.3.1 Servicio de Telefonía………………………………………………………...73
4.2.3.2 Cálculo de Tráfico Inter-Sucursal……………………………………………74
4.2.3.3 Red de Datos…………………...……………………………………………77
4.3 Definición de la Tecnología…………………………………….……………………...80
4.3.1 Cálculo de Canales VoIP por sucursal/principal…………………………………81
4.3.2 Selección de Protocolos…………………………………………………………..82
4.3.3 Selección de CODECs……………………….…………………………………...83
ix
4.3.4 Cálculo de Ancho de Banda………………….…………………………………...84

4.4 Diseño de la Propuesta…………………...…………………………………………….85
4.4.1 Definición de la Infraestructura…………………………………………………...85
4.4.1.1 VLANs y Direccionamiento…………………………………………………87
4.4.1.2 Calidad de Servicio (Quality of Service - QoS)……………………………..87
4.4.2 Dimensionamiento y Selección del Hardware /Software………………………...90
4.4.2.1 Interconexión con la PSTN…………………………………………………..91
4.4.2.2 Servidores……………………………………………………………………92
4.4.2.3 Sistema Operativo……………………………………………………………93
4.4.2.4 Asterisk………………………………………………………………………93
4.4.2.5 Teléfonos IP………………………………………………………………….94
4.4.2.6 Consideraciones con los equipos FAX………………………………………96
4.4.2.7 Alimentación de los teléfonos IP…………………………………………….96
4.4.3 Estimación de costos……………………………………………………………...97
4.4.4 Diseño del Plan de Discado (Dialplan)…………………………………………...97
4.5 Prueba Piloto ..................................................................................................................101
4.5.1 Definición de la Prueba……………….…………………………………………101
4.5.2 Instalación y Configuración……………………………………………………..103
4.5.2.1 Creación de VLAN…………………………………………………………104
4.5.2.2 Instalación del Sistema Operativo GNU/Linux (CentOS 5.3)……………..104
4.5.2.3 Instalación de los Servicios de Telefonía………………………….……….106
4.5.2.4 Instalación de las tarjetas de Telefonía…………………………………….107
4.5.2.5 Archivos de Configuración de Asterisk…………………………….……..110
4.5.2.6 Configuración de los terminales de voz……………………………………130
4.5.3 Revisión y Ajustes………………………………………………………………133
4.5.4 Conclusiones de la Prueba Piloto………………………………………………..134
4.6 Análisis de resultados.....................................................................................................135
CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES ...........................................137
5.1 Conclusiones ..................................................................................................................137
5.2 Recomendaciones...........................................................................................................137
REFERENCIAS ......................................................................................................................139
x
Í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
4. 16 Consumo de Codecs Seleccionados ................................................................................85

4. 17 Ancho de banda para Voz Requerido por Oficina.........................................................85
4. 18 VLANs Sugeridas............................................................................................................87
4. 19 Direccionamiento de las VLANs.....................................................................................87
4. 20 Tarjetas Digium Sugeridas ..............................................................................................91
4. 21 Características Técnicas de los Servidores......................................................................93
4. 22 Modelos de Teléfonos Sugeridos ....................................................................................95
4. 23 Cálculo de consumo Eléctrico por Puesto de Trabajo.....................................................96
4. 24 Estimación de Costos ......................................................................................................97
4. 25 Resumen dialplan Servinave, C.A...................................................................................99
4. 26 Parámetros TCP/IP a Configurar..................................................................................106
4. 27 Orden de Compilación Paquete Asterisk......................................................................107
4. 28 /etc/asterisk/system.conf................................................................................................110
4. 29 Sección General del Archivo Sip.conf ..........................................................................114
4. 30 Sección de Clientes del Archivo Sip.conf .....................................................................115
4. 31 Extensiones y Grupos de Captura.................................................................................116
4. 32 Patrones de Marcado .....................................................................................................121
4. 33 Configuración Hardphone .............................................................................................130
xii
Í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
4. 6 Salida del Comando cat /proc/interrupts ........................................................................108

4. 7 Salida del Comando lspci -vv........................................................................................109
4. 8 Sin Compartir Interrupciones .........................................................................................110
4. 9 /etc/asterisk/chan_dahdi..................................................................................................111
4. 10 Salida del Comando Dahdi_Hardware ..........................................................................112
4. 11 Salida Comando dahdi_cfg............................................................................................113
4. 12 Salida del Comando dahdi_test ....................................................................................113
4. 13 Comando de Verificación de Registro...........................................................................117
4. 14 Salida del Comando Core Show Translation.................................................................118
4. 15 Flujo de Llamadas en Asterisk ......................................................................................120
4. 16 Seleccionar el CODEC Preferido ..................................................................................131
4. 17 Menú de Herramientas..................................................................................................131
4. 18 Crear Cuenta SIP ...........................................................................................................132
4. 19 Configuración del Audio en Zoiper...............................................................................132
4. 20 Selección de CODECS ..................................................................................................133
xiv
LISTA DE SÍMBOLOS Y ABREVIATURAS
ADSL Asymmetric Digital Subscriber Line ( Línea de Suscripción Digital Asimétrica).

ADPCM Adaptive Differential Pulse Code Modulation (Modulación por Codificación de
Impulsos Diferencial Adaptativa).
CCITT Consultative Committee for International Telegraph and Telephone (Comité
Consultivo Internacional de Telefonía y Telegrafía).
DiffServ Differentiated Services Internet QoS model (Modelo de Calidad de Servicio en
Internet basado en Servicios Diferenciados).
DHCP Dynamic Host Configuration Protocol (Protocolo Configuración Dinámica de
Servidor).
DNS Domain Name System (Sistema de Nombres de Dominio).
DTMF Dual-Tone Multi-Frequency (Marcación por Tonos multifrecuenciales).
E.164 Recomendación de la ITU-T para la numeración telefónica internacional.
FDM Frequency Division Multiplexing (Multiplexación por División de Frecuencia).
FTP File transfer Protocol (Protocolo de Transferencia de Archivos).
FXO Foreign Exchange Office (Oficina de Intercambio Extranjera).
FXS Foreign Exchange Station (Estación de Intercambio Extranjera).
GNU Es un acrónimo recursivo que significa GNU is Not Unix (GNU No es Unix ).
GPL General Public License (Licencia Pública General).
H.323 Estándar de la ITU-T para voz y videoconferencia interactiva en tiempo real en redes
de área local, LAN, e Internet.
IAX Inter-Asterisk eXchange protocol. (Protocolo de Intercambio Asterisk).
IETF Internet Engineering Task Force (Grupo de Trabajo de Ingeniería de Internet).
IP Internet Protocol (Protocolo Internet).
IP-PBX Internet Protocol Private Branch Exchange (Central Telefónica Privada basada en
IP).
xv
IRQ Interrupt ReQuest ( Petición de Interrupción) .

ISP Internet Service Provider (Proveedor de Servicios Internet, PSI).
ITU-T International Telecommunications Union -Telecommunications (Unión Internacional
de Telecomunicaciones).
IVR Interactive voice response (Servicio Interactivo de Voz).
MGCP Media Gateway Control Protocol (Protocolo de Control de Dispositivos).
MIPS Million Instructions Per Second (Millones de Instrucciones Por Segundo).
MOS Mean Opinion Score (Nota Media de Resultado de Opinión).
PBX Private Branch Exchange (Central Telefónica Privada).
PCI Peripheral Component Interconnect (Interconexión de Componentes Periféricos).
PCM Pulse Code Modulation (Modulación por Impulsos Codificados).
POP3 Post Office Protocol (Protocolo de Oficina Postal).
POTS Plain Old Telephone Service (Servicio Telefónico Tradicional).
PSTN Public Switched Telephone Network (Red de Telefonía Conmutada Pública).
QoS Quality of Service (Calidad de Servicio).
RTCP Real Time Control Protocol (Protocolo de Control de Tiempo Real).
RTP Real Time Protocol (Protocolo de Tiempo Real).
RTSP Real Time Streaming Protocol (Protocolo de Flujo de Datos en Tiempo Real).
SDP Session Description Protocol (Protocolo de Descripción de Sesión)
SIP Session Initiation Protocol (Protocolo de Inicio de Sesión)
SMTP Simple Mail Transfer Protocol (Protocolo Simple de Transferencia de Correo)
SS7 Signalling System Number 7 (Sistema de Señalización número 7).
TCP Transmission Control Protocol (Protocolo de Control de Transmisión).
TDM Time Division Multiplexing (Multiplexación por Division de Tiempo).
TOS Type of service (Tipo de Servicio).
UDP User Datagram Protocol (Protocolo de Datagramas de Usuario).
VLAN Virtual Local Area Network (Red de Área Local Virtual).
VPN Virtual Private Network (Red Privada Virtual).
VoIP: Voice over IP (Voz sobre IP).
xDSL Cualquiera de las tecnologías de Líneas de Suscripción Digital (por ejemplo, ADSL).
1
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”.
Gracias al crecimiento de los anchos de banda, la estandarización de protocolos y

surgimiento de las aplicaciones fuente abierta, la VoIP está teniendo un gran auge. La
aparición del protocolo SIP y Asterisk, así como el Sistema Operativo GNU/Linux han
permitido consolidar aplicaciones de Telefonía IP a costos moderados que pueden ser
adoptados por las empresas que desean incursionar en esta tendencia, la cual es irreversible.
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
1.1 Planteamiento del 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.
El sistema de telefonía que utiliza la empresa es el tradicional, inclusive para comunicarse

entre las sucursales. Todas las líneas suscritas son analógicas y son suministradas por un
único proveedor: CANTV. LA contratación de estos servicios es tramitada directamente por
cada oficina, y la gestión y administración de éstos es realizada por el área administrativa y no
por el área de tecnología.
En cuanto a equipamiento, se dispone de varios modelos de centrales digitales, tal como se

puede observar en la tabla 1.1.
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
OFICINA MARCA MODELO ESTATUS

(PROPIETARIO)
Caracas Siemens Hipath-3700/3750 Actualizada año 2003
Puerto Cabello Siemens Hicom 160 Descontinuada
La Guaira Siemens EMS-80C Descontinuada
Maracaibo Siemens Hipath 1190 Actualizada año 2006
Valencia No tiene N/A N/A
Cumaná Siemens Hipath-1120 Descontinuada
Puerto La Cruz Siemens HICOM-110 Descontinuada
Punto Fijo No tiene N/A N/A
Tabla 1. 1 Equipamiento de Telefonía de Servinave
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 plataforma de telefonía de Servinave, C.A. está obsoleta y aprovechar la tecnología de Voz

sobre IP, aparte de potenciar significativamente el uso de la infraestructura de datos ya
establecida, contribuirá a renovar esta plataforma y al mismo tiempo mitigar los gastos de
llamadas en los que la empresa incurre para poder comunicarse entre sí, con sus clientes y
socios comerciales, así como también proveer de mejores servicios de comunicación a las
sucursales, a un costo razonable y proporcional al tamaño y rentabilidad de la misma.
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.
De las propuestas y alternativas existentes en el mercado, se ha seleccionado Asterisk como

software de Telefonía IP, por ser una política de la Organización a la que pertenece Servinave,
C.A.; esta política sugiere a las empresas del grupo, evaluar Asterisk para validar su
conveniencia antes de su implementación. Entre las razones que respaldan este lineamiento
está el hecho de que Asterisk es la primera plataforma de Telefonía IP de fuente abierta que
permite interoperar con todos los estándares de telefonía del mercado, además de contar con
una sólida comunidad Open Source (fuente abierta) cuya capacidad de respuesta ante
6
problemas e implantación de mejoras es bastante ágil. Esta combinación contribuirá a

disminuir los costos por licenciamiento y eliminar la dependencia hacia un proveedor en
particular.
1.3 Objetivos del Trabajo
1.3.1 Objetivo General
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.
1.3.2 Objetivo Específicos
1. Identificar las funcionalidades necesarias por cada sucursal/principal.

2. Diagnósticar de la situación actual.
3. Cálcular las capacidades y aprovisionar ancho de banda.
4. Dimensionar y seleccionar el hardware/software necesario.
5. Evaluar impacto y estimar costos.
7
CAPITULO II
MARCO TEÓRICO
Este capítulo proporciona definiciones, conceptos y términos relevantes que fundamentan el

presente Trabajo Especial de Grado y que facilitará su comprensión.
2.1 Redes Conmutadas
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
2.1.1 Conmutación de Circuitos
La conmutación de circuitos implica que los equipos de conmutación deben establecer un

camino físico y dedicado entre los medios de comunicación previo a la conexión entre los
usuarios. Este camino permanece activo durante la comunicación entre los usuarios,
liberándose al terminar la comunicación (Stallings, 2004).
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
la de destino. En esta etapa, dependiendo de la tecnología utilizada, se pueden establecer la

capacidad del canal y el tipo de servicio.
2. Transferencia de datos: Una vez que se ha establecido un circuito puede comenzar la
transmisión de datos. Dependiendo del tipo de redes y del tipo de servicio la transmisión
será digital o analógica y el sentido de la misma será unidireccional ó full duplex.
3. Cierre del circuito: Una vez que se ha transmitido todos los datos, una de las estaciones
comienza la terminación de la sesión y la desconexión del circuito. Una vez liberado los
recursos utilizados por el circuito pueden ser usados por otra comunicación.
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.
2.1.2 Conmutación de Paquetes
La técnica de conmutación de paquetes se diseño para ofrecer un servicio para el tráfico de

datos más eficiente que el proporcionado por la conmutación de circuitos (Stallings, 2004).
En los sistemas basados en conmutación de paquetes, la información/datos a ser transmitida

previamente es ensamblada en pequeños bloques llamados paquetes (datagramas). Si una
estación tiene que enviar un mensaje de longitud superior a la del tamaño máximo del paquete
permitido a través de la red de conmutación de paquetes, fragmenta el mensaje en paquetes y
lo envía uno a uno, hacia la red. La red tiene dos técnicas de gestionar esta secuencia de
paquetes para encaminarlos en su seno y entregarlos al destino deseado: datagramas y
circuitos virtuales.
En la técnica de datagramas, cada paquete se trata de forma independiente sin referencia

alguna a los paquetes anteriores. Cada nodo de la red puede determinar libremente la ruta de
cada paquete de manera individual, según su tabla de enrutamiento. Los paquetes que se
envían de esta manera pueden tomar diferentes rutas y se vuelven a montar una vez que llegan
al nodo receptor. La principal ventaja de esta técnica es que permite el uso potencial de rutas
9
alternativas ante la eventual indisponibilidad de algunos nodos de conmutación de la red,

además de no precisar un establecimiento de llamada. Sin embargo, esta técnica resulta poco
adecuada para el tráfico de servicios interactivos (tráfico síncrono en la que se precisa alta
velocidad).
En la técnica de circuitos virtuales, se establece una conexión lógica antes de proceder a la

transmisión de datos. Una vez establecida ésta, todos los paquetes intercambiados entre dos
partes comunicantes siguen dicho camino a través de la red. Dado que el camino es fijo,
mientras dura la conexión lógica, es similar a un circuito en una red de conmutación de
circuitos, por lo que se le llama circuito virtual. Además de los datos, cada nodo contiene un
identificador del circuito virtual. En un instante de tiempo dado, cada estación puede tener
más de un circuito virtual hacia otra u otras estaciones. La principal característica del método
de circuito virtual es que la ruta entre terminales se establece con anterioridad a la
transferencia de datos, lo que no significa que haya una ruta dedicada. Los paquetes se
almacenan en cada nodo y puesto en cola sobre una línea de salida, mientras que otros
paquetes en otros circuitos pueden compartir el uso de la línea.
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
2.2 Descripción General de la Red Telefónica Convencional
Al sistema telefónico o a la red telefónica básica (RTB) también se le denomina Public

Switched Telephone Network (PSTN) o Red de Telefonía Pública Conmutada (RTPC) .
La PSTN constituye la principal red de telecomunicaciones, permite que usuarios separados

geográficamente puedan comunicarse de una manera sencilla, además de permitir la
transmisión de datos. Está basada en conmutación de circuitos, es decir, cuando se establece
una llamada los recursos quedan dedicados en forma exclusiva a la misma y éstos no pueden
ser utilizados por otros, aun cuando no se esté transmitiendo datos por ellos.
11
Una de las funciones principales que se realiza en la red telefónica es la de conmutación, a

través de centrales de conmutación. La conmutación surge como una solución a la
imposibilidad de interconectar a todos los terminales entre sí a través de las líneas punto a
punto. Para ello se establece una jerarquía de nodos de conmutación (centrales de
conmutación) interconectados entre sí (TRUNK o líneas troncales), de los que dependen las
conexiones de los terminales (ver figura 2.1).
Figura 2. 1 Jerarquía de nodos 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.
La infraestructura de la PSTN empieza con un cable (par de cobre) instalado en la casa/oficina

del abonado, conocido como bucle local o local loop, conjuntamente con los elementos que se
conectan a la red, conocidos con el nombre de terminal de abonado. El bucle local físicamente
conecta el terminal de abonado a la central de conmutación de la oficina central (también
conocido como CO, switch clase 5 o conmutador de punto final). La ruta de comunicación
entre terminal de abonado y la central de conmutación de la oficina central (CO) es conocida
como línea telefónica del abonado.
12
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
En el contexto telefónico, la señalización constituye el intercambio de información

relacionada con el establecimiento y control de las conexiones y con su gestión en una red de
telecomunicaciones (Stallings, 2004).
Es necesario considerar la señalización en dos contextos, ya que generalmente funciona

diferente:
• La señalización entre el abonado y la red.

• La señalización dentro de la red (entre centrales).
13
2.2.1.1 Señalización Abonado a Red
Se refiere al conjunto de señales que intercambian el terminal telefónico y la central local, a

través del par de cobre del bucle del abonado. La interfaces usadas para ello son Foreign
Exchange Station (FXS) y Foreign Exchange Office (FXO).
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:
• GroundStart (gs): En este tipo de señalización el tono se solicita conectando a una

toma de tierra uno de los polos. No es muy utilizado actualmente.
• LoopStart (ls): Permite que un teléfono indique el colgado/descolgado, y que el punto
terminal indique el ring/no ring. Es el método más utilizado. La diferencia entre ls y gs
radica en la manera en la que el teléfono requiere tono de marcado a la CO.
GroundStart requiere tono de marcado aterrizando uno de los conductores de la línea
telefónica mientras que ls lo hace realizando un corto circuito entre ambos
conductores (es decir creando un lazo o loop).
• KewlStart (ks): La señalización Kewlstart está basada en loopstart, pero amplía el
protocolo permitiendo al punto terminal invertir la polaridad de la línea telefónica para
indicar al teléfono que el otro extremo de la llamada ha colgado.
14
El procesamiento de una llamada de voz se puede describir como sigue (ver figura 2.2):
• Abonado llamante descuelga del teléfono (el dispositivo FXO).

• El puerto FXS (CO) detecta que ha descolgado el teléfono envía tono de invitación a
marcar.
• Abonado marca el número de teléfono y éste es enviado al puerto FXS de la CO.
• Si el abonado llamado no esta ocupado, El puerto FXS recibe una llamada y luego
envía un voltaje de llamada al dispositivo FXO adjunto . Si esta ocupado o no puede
establecerse la comunicación, el puerto FXS igualmente envia realimentación al
abonado llamante con los tonos correspondientes.
• La conexión se libera cuando una de las dos partes cuelga.
Figura 2. 2 Señalización de una llamada de voz

15
2.2.1.2. Señalización entre Centrales
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).
El Sistema de Señalización Número 7 (SS7) es un estándar global para las telecomunicaciones

definidas por la ITU-T. El estándar define el protocolo y los procedimientos mediante los
cuales los elementos de la red de telefonía conmutada pública (PSTN) intercambian
información sobre una red digital para efectuar el enrutamiento, establecimiento y control de
llamadas.
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.
Figura 2. 3 Modelo de Referencia OSI
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).
IP es uno de los protocolos de Internet que permite el desarrollo y transporte de paquetes de

datos IP, aunque sin garantizar su entrega. El protocolo IP procesa datagramas de IP de
manera independiente al definir su representación, ruta y envío. IP es un protocolo no
orientado a conexión usado tanto por el orígen como por el destino para la comunicación de
datos a través de una red de paquetes conmutados.
17
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 ):
1. Capa de Aplicación: Proporciona comunicación entre procesos o aplicaciones en

computadores distintos.
2. Capa de Transporte o computador-a-computador: Encargada de transferir datos
entre computadores sin detalles de red pero con mecanismos de seguridad.
3. Capa de Internet: Se encarga de direccionar y guiar los datos desde el origen al
destino a través de la red o redes intermedias.
4. Capa de Acceso a la Red: Interfaz entre sistema final y la subred a la que está
conectado.
5. Capa Física: Define las características del medio, señalización y codificación de
las señales.
18
Figura 2. 4 Comparación entre las arquitecturas OSI y TCP/IP
2.4 Voz Sobre IP (VoIP)
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.
La definición genérica de Telefonía IP, adoptada por la Unión Internacional de

Telecomunicaciones (UIT) en el Foro Mundial de Políticas de las Telecomunicaciones (FMPT
2001) - Telefonía IP, comprende la prestación de servicios vocales a través de redes basadas
en IP, ya sea en forma total o en combinación con redes públicas conmutadas tradicionales.
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).
Además de la ejecución de la conversión de analógico a digital, los CODECs comprimen la

secuencia de datos, lo que permite reducir el caudal de bits necesario para transmitir una
determinada información, logrando con ello optimizar el uso del ancho de banda.
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.
2.6.1 Funcionamiento del CODEC
El proceso de conversión de la señal analógica a digital se realiza llevando a cabo los

siguientes pasos (ver figura 2.5):
• Muestreo (sampling)
• Cuantificación (quantization)
• Codificación (codification)
Figura 2. 5 Proceso de conversión de una señal
2.6.1.1 Muestreo
El proceso de muestreo consiste en tomar valores instantáneos (muestras) de una señal

analógica, a intervalos de tiempo iguales. El muestreo se efectúa siempre a un ritmo uniforme,
que viene dado por la frecuencia de muestreo o sampling rate.
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:
T=1/8000= 0,000125 seg. = 125 µs
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
La cuantificación es el proceso mediante el cual se asignan valores discretos a las amplitudes

de las muestras obtenidas en el proceso de muestreo.
2.6.1.3 Codificación
La codificación es el proceso mediante el cual se representa una muestra cuantificada en un

grupo equivalente de pulsos binarios de amplitud constante, es decir, una sucesión de "1's" y
"0's".
2.6.2 Tipos de CODEC
Tradicionalmente, en entornos telefónicos se ha venido utilizando la modulación por

codificación de pulsos o PCM (Pulse Code Modulation) en que cada muestra de voz se
presenta por 8 bits, resultando un flujo de 64 kbps (8000 x 8 ). Si la frecuencia de muestreo se
escoge respetando el Teorema de Nyquist, la codificación recibe el nombre de G.711, por la
norma ITU-T que la recoge. Este CODEC es el que mayor calidad de voz consigue, sin
embargo, el precio que hay que pagar es un mayor consumo de ancho de banda, pues requiere
64 kbps.
Las carcterísticas de algunos de los CODECs comúnmente usados en VoIP, se resumen a

continuación.
22
2.6.2.1 ITU-T G.711
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.
2.6.2.2 ITU-T G.723.1
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.
2.6.2.3 ITU-T G.726
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.
2.6.2.4 ITU-T G.729
La ventaja en la utilización de G.729 radica principalmente en su alta compresión y por ende

bajo consumo de ancho de banda lo que lo hace atractivo para comunicaciones por Internet.
Pese a su alta compresión no deteriora la calidad de voz significativamente, sin embargo,
música o tonos tales como DTMF o tonos de fax no pueden ser transportados con seguridad
con este codec, como resultado, se debe usar G.711 u otros métodos fuera de esta banda para
23
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:
• G729: es el codec original

• G729A o anexo A: es una simplificación de G729 y es compatible con G729. Es
menos complejo pero tiene algo menos de calidad.
• G729B o anexo B: Es G729 pero con supresión de silencios y no es compatible con las
anteriores.
• G729AB: Es G729A con supresión de silencios y sería compatible solo con G729B.
• Aparte de esto G729 (todas las versiones) en general tienen un bit rate de 8Kbps pero
existen versiones de 6.4 kbps (G729 anexo D) y 11.4 Kbps (G729 anexo E).
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.
2.6.3 Parámetros de los CODEC
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:
• Frecuencia de muestreo – Sampling Rate (fs): Número de muestras tomadas de la

señal de voz en la unidad de tiempo de un segundo (típico: 8khz).
• Tamaño de la trama - Frame Size (Tt): Indica cada cuantos milisegundos se envía un
paquete con la información sonora. El procesamiento de la señal de voz se hace por
intervalos de duración predefinidos.
• Tasa de bits - Bits Rate: Define el número de bits que se transmiten por unidad de
tiempo. Se expresa en Kbps.
• Retardo de “Look-ahead” (Tla): Son muestras a futuro que algunos codecs
requieren para estimar mejor la señal de audio y poder lograr una compresión mayor.
Se expresa en ms.
• Mean Opinion Score (MOS): Es una referencia subjetiva común para cuantificar el
rendimiento de un codec de voz. Un MOS de 5 indica una comunicación de calidad
excelente, mientras que un MOS de 0 indica pésima calidad.
25
• Complejidad: Es una medida de la cantidad de CPU necesaria para procesar el

algoritmo de codificación, y por tanto, del número de canales de voz que puede
soportar un mismo DSP (digital signal procesor) . La compresión tiene un tiempo de
procesamiento que dependerá del procesador utilizado y de la complejidad del
algoritmo del codec. Un parámetro de medición del performance de estos
procesadores es la cantidad de millones de instrucciones por segundo (MIPS) que
puede ejecutar.
• Retardo: Tiempo que requiere el algoritmo del codec para poder codificar y
comprimir la señal.
• Packet Loss Concealment (PLC): Es un algoritmo que permite recuperación de
paquetes. Según la complejidad del algoritmo de recuperación de paquetes, este
puede reproducir el último sonido o calcular cuál sería el sonido correspondiente al
paquete perdido.
2.7 Factores que Afectan la Calidad de la Voz
Como ya se ha mencionado, la tecnología de conmutación de circuitos no hace uso eficiente

de los mismos debido a que los canales permancen ocupados mientras dura la llamada,
inclusive si no se transmite información. En la conmutación de paquetes, por el contrario, sólo
se ocupa el canal cuando se transmite información, aprovechando al máximo el ancho de
banda.
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).
La calidad de servicio (QoS) es definida por la Unión Internacional de Telecomunicaciones

(ITU-T), en la Recomendación ITU-T E.800, como el efecto colectivo del funcionamiento del
servicio, el cual determina el grado de satisfacción del usuario del mismo. Dicho grado de
26
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:
• Latencia / Delay (Retraso).

• Jitter
• Pérdida de Paquetes
• Eco
2.7.1 Latencia / Delay (Retraso)
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.
Existen varias fuentes de retrasos (ver figura 2.6 ):
• Retraso de Procesamiento: Es el tiempo que tarda el CODEC en convertir la señal

analógica de audio a una señal de audio digitalizada con una representación
comprimida.
• Retraso de Paquetización: Es el tiempo que se requiere para formar un paquete de
voz a partir de la representación comprimida generada por el CODEC.
27
• 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.
Figura 2. 6 Fuentes de retraso en la red
2.7.2 Jitter
El jitter se define técnicamente como la variación en el tiempo de llegada de los paquetes,

causada por congestión de red, perdida de sincronización o por las diferentes rutas seguidas
por los paquetes para llegar al destino. Es decir, es la variación del retardo. El excesivo jitter
hace que la voz sea entrecortada y con dificultades para entenderse. El jitter es calculado
28
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.
2.7.3 Pérdida de Paquetes
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.
Los umbrales indicados en las recomendaciones de la ITU-T P.800, P.830, P.862.1, se

resumen en la tabla 2.2:
CLASIFICACIÓN EXCELENTE BUENO ACEPTABLE POBRE

CALIDAD VOIP
Jitter [ms] t < 10 10 =< t < 20 20 =< t < 50 t >= 5
Latencia [ms] t < 50 50 =< t < 150 150 =< t < 300 t >= 300
Perdida Paquetes [%] p < 0,1 0,1 =< p < 0,5 0,5 =< p < 1,5 p >= 1,5
Tabla 2. 2 Indicadores de QoS para VoIP
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.
2.8 Arquitectura de los Protocolos de VoIP
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):
• Protocolo Señalización: El objetivo es establecer un canal de comunicaciones a través

del cual fluya la informacion de usuario y liberar el canal cuando finalice la
comunicación. Para ello debe existir un diálogo entre los componentes de red y entre
la red y los terminales de usuario. Algunos de los protocolos de señalizacion son
H.323, SIP, IAX, entre otros.
• Protocolo de Transporte: Son las normas que definen cómo debe realizarse La
comunicación entre los extremos por un canal de comunicaciones previamente
establecido. Los protocolos de transporte mas empleados son RTP-RTCP y RTSP.
30
• Protocolos de Gestión: Permiten conocer el grado de utilización de la infraestructura

tecnológica. Esta información es útil para el mantenimiento o aplicación de medidas
oportunas que garanticen el correcto funcionamiento de la red, asi como facilitar la
planificación de ampliaciones o restructuraciones.
2.8.1 Protocolo de Señalización H.323
H.323 es un conjunto de especificaciones de la ITU-T para transmitir audio, video y datos a

través de una red IP. Consta de los siguientes protocolos (ver figura 2.7):
• Señalización de las llamadas: H.225

• Control de la comunicación multimedia: H.245
• Datos para conferencias multimedia: T.120
• Servicios complementarios H.450
• Codecs de audio: G.711, G.722, G.723, G.728 y G.729
• Codecs de video: H.261 y H.263
Figura 2. 7 Pila de protocolos H323
2.8.1.1 Componentes de una red H.323
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
También se denominan puntos finales, proporcionan conferencias punto a punto y multipunto

para audio y de manera opcional para video. En un terminal H.323 se encuentran las
siguientes funciones (ver figura 2.8):
Figura 2. 8 Elementos funcionales de un terminal H.323
• Unidad de Control del Sistema: Proporciona a H.245 y H.225 el control de llamadas,

mensajería, intercambio de capacidades y comandos de señalización.
• Transmisión de Medios: Formatea el audio, video, datos, flujos y mensajes
transmitidos hacia y recibidos desde la interfaz de red.
• Codec de Audio: Codifica la señal de audio para su transmisión y decodifica el código
de audio entrante.
• Codec de Víideo: Opcional, si está implementado debe cumplir con el estándar H.261
Quarter Comment Intermediate Format (QUIF).
32
• 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).
2.8.1.1.2 Gateways o Pasarelas
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
Proporciona el servicio de admisión y traducción de direcciones para terminales o gateways.

Aquí se efectúan las tareas de direccionamiento, autenticación tanto de terminales como
gateways, gestión de ancho de banda y contabilidad. Pueden también proveer servicios de
encaminamiento de llamadas.
2.8.1.1.4 Las Unidades de Control Multipunto (MCU)
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.
2.8.1.2 Establecimiento de una llamada en H.323
Una llamada H.323 se ejemplifica en la figura 2.9 y se caracteriza por las siguientes fases:
33
Figura 2. 9 Establecimiento de una llamada en H.323

34
2.8.1.2.1 Establecimiento
• Uno de los terminales se registra en el gatekeeper utilizando el protocolo RAS

(Registro, admisión y estado) con los mensajes ARQ y ACF.
• Posteriormente utilizando el protocolo H.225 (que se utiliza para establecimiento y
liberación de la llamada) se manda un mensaje de SETUP para iniciar una llamada
H.323. Entre los datos que contiene el mensaje se encuentra la dirección IP, puerto y
alias del llamante o la dirección IP y puerto del llamado.
• El terminal llamado contesta con un CALL PROCEEDING advirtiendo del intento de
establecer una llamada.
• En este momento el segundo terminal tiene que registrarse con el gatekeeper utilizando
el protocolo RAS de manera similar al primer terminal
• El mensaje ALERTING indica el inicio de la fase de generación de tono.
• Por último, CONNECT indica el comienzo de la conexión.
2.8.1.2.2 Señalización de Control
• En esta fase se abre una negociación mediante el protocolo H.245 (control de

conferencia), el intercambio de los mensajes (petición y respuesta) entre los dos
terminales establecen quién será master y quién slave, las capacidades de los
participantes y CODECs de audio y video a utilizar. Como punto final de esta
negociación se abre el canal de comunicación (direcciones IP, puerto). Los principales
mensajes H.245 que se utilizan en esta fase son:
o TerminalCapabilitySet (TCS). Mensaje de intercambio de capacidades

soportadas por los terminales que intervienen en una llamada.
o OpenLogicalChannel (OLC). Mensaje para abrir el canal lógico de información
que contiene información para permitir la recepción y codificación de los datos.
Contiene la información del tipo de datos que será transportados.
35
2.8.1.2.3 Audio
Los terminales inician la comunicación y el intercambio de audio (o video) mediante el

protocolo RTP/RTCP.
2.8.1.2.4 Desconexión
• En esta fase cualquiera de los participantes activos en la comunicación puede iniciar el

proceso de finalización de llamada mediante mensajes CloseLogicalChannel y
EndSessionComand de H.245.
• Posteriormente, utilizando H.225 se cierra la conexión con el mensaje RELEASE
COMPLETE.
• Por último se liberan los registros con el gatekeeper utilizando mensajes del protocolo
RAS.
2.8.2 Protocolo de Señalización de Inicio de Sesión SIP
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.
SIP no provee servicios, sino primitivas para implementar servicios; se fundamenta en un

esquema de envío de mensajes, de petición y respuesta, similares en su sintaxis y semántica a
los definidos en el estándar HTTP (Hypertext Transfer Protocol). Este intercambio de
36
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:
• Canal de Señalización (UDP 5060) Establecimiento, negociación y finalización de la

sesión.
• Canal de stream RTP (UDP 10000-20000 normalmente) y control RTCP.
Figura 2. 10 SIP y RTP Viajan por Caminos Diferentes
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)
Figura 2. 11 Pila de Protocolos SIP
Las características más destacables del protocolo son las siguientes:
• 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”.
2.8.2.1 Componentes de una Red Basada en SIP
Los dos componentes de un sistema SIP son:
• Agentes de usuario
• Servidores de red.
2.8.2.1.1 Agentes de Usuario
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).
Figura 2. 12 UAS y UAC
2.8.2.1.1.1 Agente de Usuario Inverso, Back-to-Back User Agent (B2BUA)
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
Figura 2. 13 Servidor de Registro
3) Servidores de Redirección: Es un servidor que genera respuestas de redirección a las

peticiones que recibe y devuelve a los Agentes de Usuarios la dirección del NHS (Next
Hop Server). Asimismo, permite el establecimiento de llamadas entre Clientes sin
necesidad de usar Proxy SIP. Los procesos de llamadas redireccionadas disminuyen la
carga de los Servidores Proxy debido a llamadas concurrentes (ver figura 2.14).
Figura 2. 14 Servidor de redirección
2.8.2.2 Direccionamiento SIP
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:
• usuario@dominio, donde dominio es un nombre de dominio completo.

• usuario@equipo, donde equipo es el nombre de la máquina.
• usuario@dirección_ip, donde dirección_ip es la dirección IP del dispositivo.
• número_teléfono@gateway, donde el gateway permite acceder al número de teléfono a
través de la red telefónica pública.
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).
Figura 2. 15 Solicitudes y respuestas SIP
La estructura genérica de un mensaje SIP, sea de petición o respuesta, es la siguiente:
• Start Line: Una línea de comienzo, que depende si el mensaje es de solicitud o de

Respuesta.
43
• Headers: Una o más cabeceras.

• Empty Line : una línea vacía que indica el fin de las cabeceras (CRLF).
• Message Body: El cuerpo del mensaje (opcional).
2.8.2.3.1 Métodos SIP (Solicitudes)
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.
La línea de solicitud tiene la estructura siguiente:
Method SP Request-URI SP SIP-Version CRLF
Donde SP es el carácter espacio y CRLF es la secuencia retorno del carro y nueva línea (ver
tabla 2.3) .
44
INVITE sip:bob@sip.com SIP/2

Método INVITE
Request-URI bob@sip.com
Version SIP SIP/2.0
Tabla 2. 3 Ejemplo de una Solicitud SIP
2.8.2.3.2 Códigos de Estado SIP (Respuestas)
Los códigos de estado se deviden en los siguientes grupos:
• 1xx Información: La solicitud ha sido recibida y se esta procesando.

• 2xx Éxito: La acción ha sido recibida con éxito y aceptada.
• 3xx Redirección: Hay que tomar acciones para completar la solicitud.
• 4xx Error del Cliente: Lla solicitud contiene sintaxis.
• 5xx Error de Servidor: El servidor no puede completar una solicitud aparentemente
válida.
• 6xx Fallo Global: La solicitud no puede ser tratada en ningun servidor.
La estructura de los mensajes de respuesta es:
SIP-Version Space Status-Code Space Reason-Phrase CRLF
Donde SP es el carácter espacio y CRLF es la secuencia retorno del carro y nueva línea (ver
tabla 2.4)
• SIP-Version: Es la versión del Protocolo SIP utilizado

• Status-Code: Entero de tres dígitos que indica el resultado del intento de servir la
petición.
45
• 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
Tabla 2. 4 Ejemplo de Mensaje de Respuesta
2.8.2.4 Headers o Cabeceras
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
2.8.2.5 Cuerpo del Mensaje
Los mensajes SIP, solicitudes y respuestas, opcionalmente pueden contener un cuerpo de

mensaje. Generalmente éste es una descripción de sesión con SDP, pero puede ser cualquier
otro contenido, en texto plano o cifrado.
SDP es el acrónimo de Session Description Protocol (Protocolo de descripción de sesión) y

está definido en el RFC 4566 como “un formato para definir parámetros de inicialización de
flujos de medios”.
SDP es exclusivamente para propósitos de descripción y negociación de los parámetros de la

sesión. No transporta medio en sí. El transporte de información acerca de los flujos de medios
permite a los destinatarios participar en la sesión si ellos soportan dichos flujos.
De forma general, la información que SDP incluye en sus paquetes es la siguiente:
• La versión del protocolo

• El nombre de la sesión y su propósito
• El tiempo que la sesión esta activa
• Los medios relacionados con la sesión (video, audio, formatos para audio o video,
entre otras).
• Las direcciones IP y los puertos para el establecimiento de la sesión
• Los atributos específicos a la sesión o a los medios dentro de ella.
La única manera de ampliar o de agregar nuevas capacidades al SDP es definir un nuevo

atributo. Sin embargo, los atributos desconocidos pueden ser ignorados.
47
2.8.2.6 Proceso de una Llamada en SIP
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.
Figura 2. 16 Proceso de una llamada SIP
• 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
un TRYING 100 para parar las retransmisiones y reenvía la petición al usuario B. El

usuario B envía un Ringing 180 cuando el teléfono empieza a sonar y también es
reenviado por el proxy hacia el usuario A. Por último, el OK 200 corresponde a aceptar
la llamada (el usuario B descuelga).
• En este momento la llamada está establecida, pasa a funcionar el protocolo de
transporte RTP con los parámetros (puertos, direcciones, codecs, etc.) establecidos en
la negociación mediante el protocolo SDP.
• La última transacción corresponde a una finalización de sesión. Esta finalización se
lleva a cabo con una única petición BYE enviada al Proxy, y posteriormente reenviada
al usuario B. Este usuario contesta con un OK 200 para confirmar que se ha recibido el
mensaje final correctamente.
2.8.3 Protocolo de Señalización de Intercambio Inter Asterisk (IAX)
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
2) Proporcionar soporte transparente frente a un NAT (Network Address Traslations).
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 .
2.8.3.1 Tramas o Mensajes IAX
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:
A) Tramas F o Full Frames
La particularidad de las tramas o mensajes F es que deben ser respondidas explícitamente. Es

decir cuando un usuario manda a otro una trama F (full frame) el receptor debe contestar
50
confirmando que ha recibido ese mensaje. Estas tramas son las únicas que deben ser
respondidas explícitamente.
B) Tramas M o Mini Frames
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.
2.8.3.2 Proceso de una llamada en IAX
En la figura 2.17 se puede apreciar los pasos para establecer una llamada a través del
protocolo IAX:
Figura 2. 17 Proceso de una llamada IAX

51
• Establecimiento de la llamada: El terminal A o terminal llamante inicia una

conexión y manda un mensaje "NEW". El terminal B o terminal llamado
responde/confirma la petición con un "ACCEPT" y el llamante le responde con un
"ACK", reconfirmando. A continuación el terminal llamado da las señales de
"RINGING" y el llamante contesta con un "ACK" para confirmar la recepción del
mensaje. Por último, el llamado acepta la llamada con un "ANSWER" y el llamante
confirma ese mensaje con un "ACK".
• Flujo de datos o flujo de audio. Se envían las tramas M y F en ambos sentidos con la
información vocal. Las tramas M son mini-frames que contienen solo una cabecera de
4 bytes para reducir el uso en el ancho de banda. Las tramas F son tramas completas
que incluyen información de sincronización. Es importante volver a resaltar que en
IAX este flujo utiliza el mismo protocolo UDP que usan los mensajes de señalización
evitando problemas de NAT.
• Liberación de la llamada o desconexión. Cualquiera de los involucrados, llamante o
llamado, puede terminar la llamada enviando una trama ‘HANGUP’ y esperando una
trama de confirmación ‘ACK’.
2.8.4 Protocolos de Transporte
El protocolo de red IP de nivel 3 no es fiable, porque corresponde al protocolo de transporte de

capa más alta el control de la transmisión. En Internet, esta función es ejecutada por el
protocolo de control de transmisión (TCP), que es un protocolo fiable que corrige los errores
del protocolo subyacente. En la práctica se puede observar que la recuperación de los paquetes
perdidos aumenta el tiempo de tránsito. La pérdida repetida de un sólo paquete puede provocar
desfases temporales muy importantes. Como las aplicaciones de audio y vídeo necesitan flujos
constantes que no pueden tolerar variaciones y fluctuaciones sin causar interrupciones, el
protocolo TCP es inadecuado para este tipo de aplicación cuando se rebasa un 4 ó 5% de tasa
de pérdida de paquetes, según el informe esencial sobre telefonía IP del Grupo de expertos de
Telefonía IP del UIT-D (Sector de desarrollo de las telecomunicaciones ).
52
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).
2.8.4.1 Real-time Transport Protocol (RTP)
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.
La transmisión de audio y video a través del protocolo RTP incluyen en su cabecera

informaciones que sincronizan imagen y sonido, al tiempo que es capaz de determinar si se
han perdido paquetes y si éstos han llegado en el orden correcto.
RTP no incluye funciones de garantía de calidad de servicio (QoS), entrega fiable, ni de

reserva de recursos para el tráfico de multimedia en tiempo real. RTP confía en que los
protocolos underlaying se ocuparán de estos aspectos.
2.8.4.2 Real-time Transport Control Protocol (RTCP)
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.
2.8.4.2.1 Funciones de RTCP
Este protocolo de control tiene tres funciones principales:
1) Monitorización de la QoS y control de congestión: Obtiene información acerca de la

calidad de entrega de los datos en la distribución de contenido multimedia en la sesión.
2) Identificación de Fuente: Ofrece una forma de correlacionar y sincronizar diferentes
media streams que provienen del mismo emisor, transmitiendo unos identificadores
asociados a las fuentes RTP, conocidos como CNAME (Canonical Name), como una
identificación alternativa al SSRC(Sinchronization Source); así se garantitza que
streams que no tienen el mismo SSRC se puedan sincronizar y ordenar correctamente.
3) Sincronización Inter-Media: Obtener información acerca del número de participantes
de una sesión y recalcular dinámicamente la tasa de envío de paquetes RTCP.
2.8.4.2.2 Mensajes RTCP
RTCP define varios tipos de paquetes que incluyen:
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)
Protocolo de nivel de aplicación no orientado a conexión definido en el RFC 2326, que

define cómo debe llevarse a cabo el streaming. Se entiende por streaming la capacidad de
distribución de contenido multimedia de manera que es posible visualizarlos mientras estan
siendo transmitidos, es decir, sin necesidad de descargarlos completamente (Huidobro y
Roldan, 2006).
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.
2.9 Consideraciones para el Cálculo de Ancho de Banda
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:
• Tasa de paquetes (Pr) constante.

• Tamaño de paquete (Pl) fijo.
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).
En la tabla 2.5 se presenta el consumo de ancho de banda por CODEC.

55
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.
CABECERAS PROTOCOLO ANCHO DE BANDA

(BYTES)
IP 20
IP/UDP/RTP UDP 8
RTP 12
Total IP/UDP/RTP 40 bytes
IPSEC 50-57
VPN L2TP/GRE 24
Total VPN 74-81 bytes
Ethernet 18
ETHERNET Vlans (802.1Q ) 4
Total Ethernet 22 bytes
Frame Relay 7 bytes
FRAME RELAY Total FR 7 Bytes
Tabla 2. 7 Resumen de la Sobrecarga Generada por Encabezados
Es importante resaltar lo siguiente:
• Una vez que la llamada ha sido establecida, un encabezado IP/UDP/RTP es generado

para cada uno de los paquetes que cursará la red IP. Cada uno de estos paquetes tiene
en común las mismas direcciones IP y los mismos puertos. El objeto del proceso de
compresión del encabezado IP/UDP/RTP definido en el RFC 2508 de la IETF, es la
reducción de estos encabezados, con un total de 40 bytes a 2 o 4 bytes. Según este
RFC, la compresión del encabezado opera enviando el encabezado completo
IP/UDP/RTP al principio de la comunicación y luego solo envía información de
cambios.
• Aunque la cabecera Ethernet tiene 38 bytes, para el cálculo de consumo de ancho de
banda se utilizan simplemente 18 bytes de éstos. La razón es que como Ethernet
pertenece a la capa 1 y a la capa 2 del modelo de referencia OSI, los 38 bytes se
57
refieren al (overhead de capa1 + overhead de capa2), mientras que los 18 bytes se

refieren únicamente al overhead de capa 2 (ver tabla 2.8).
CAPA SOBRECARGA (OVERHEAD) BYTES

Overhead Capa 2 MAC-DEST (6 bytes) + MAC-ORIG (6 bytes) + 18 bytes
Length/Type (2 bytes) + FCS/CRC (4 bytes)
Overhead Capa 1 Preamble (7 bytes) + Start-of-Frame-Delimiter (1 byte) + 20 bytes
Interfame Gap (12 bytes)
Overhead capa2 + overhead capa 1
(Adicionalmente, si la trama lleva un tag de VLAN, hay que agregar 4 bytes 38 bytes
adicionales al overhead total)
Tabla 2. 8 Desglose de la Sobrecarga de la Cabecera Ethernet
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:
• El retardo de codificación / decodificación y el de empaquetamiento /

desempaquetamiento están determinados por el codec utilizado.
• El retardo de supresión de jitter , a efectos de diseño, suele tomarse igual a la duración
de dos muestras de voz.
• El retardo de propagación, si no se dispone de ningún valor aproximado, la
recomendación ITU-T G.114 aconseja emplear el valor de 6ms/Km.
• El retardo de serialización, es la relación entre el tamaño de la trama y la velocidad del
enlace.
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.
2.9.2 Otros Factores
Existen otros factores a tener en cuenta en el cálculo de ancho de banda. El primero es la

supresión de silencio que se basa en la detección de actividad de la voz (VAD). De esta forma
el transmisor, al detectar que la actividad de la voz cesa (la amplitud está debajo de un umbral)
deja de transmitir información ahorrando de esta forma ancho de banda. El factor de actividad
de la voz suele considerársele en el orden de un 35% a un 50%. Como consecuencia, se suele
multiplicar el resultado del cálculo del ancho de banda por este factor.
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
Asterisk es definida oficialmente en su Handbook por su equipo de documentación, como

“Una PBX híbrida, fuente abierta, que integra tecnología TDM, paquetes de voz y
plataforma IVR con funcionalidades ACD. No oficialmente, muchos concuerdan en definirla
como una aplicación de software libre (bajo licencia GPLv2) que proporciona las mismas
funcionalidades (y más) de las PBXs de los grandes sistemas propietarios, a un precio
inferior.
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.
DIGIUM es el creador y desarrollador primario de Asterisk. Actualmente, es uno de los

principales fabricantes de hardware para Asterisk y disponen de modelos para líneas
analógicas / digitales con una gama amplia y soportada.
2.10.1. Arquitectura Asterisk
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
Figura 2. 18 Arquitectura de Asterisk
• Los módulos que componen la arquitectura Asterisk son:
• 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:
o Leer y procesar las configuraciones del sistema.

o Carga dinámica de módulos.
o Ejecución de aplicaciones.
o Proveer temporización al sistema.
o Conversión entre formatos, codecs y protocolos.
o Procesamiento de solicitudes del dialplan (plan de marcado).
o Crear instancias de canales.
• Recursos: Aportan funcionalidades adicionales al core, como la posibilidad de leer los

archivos de configuración (res_config), música en espera (res_musichold), etc. Son
cargados de forma estática.
61
• Canales: Permiten a Asterisk manejar un dispositivo de una determinada tecnología.

Por ejemplo, para manejar dispositivos SIP se utiliza el modulo chan_sip, para IAX
chan_iax, y para canales analógicos/digitales chan_zap (hasta la version 1.4.21) o
chan_dahdi (versiones a partir de la 1.4.22). Los canales son los administradores de
todas las entradas y salidas desde y hacia Asterisk. Actua como traductor entre su
protocolo nativo y el protocolo interno de Asterisk.
• Aplicaciones y Funciones: Conjunto de herramientas para configurar Asterisk. Son
almacenadas en módulos cargables y son cargados dinámicamente por el núcleo al ser
llamadas desde el dialplan. Son invocadas secuencialmente durante el transcuro de una
llamada.
• CDR (Call Detail Records): Estos módulos controlan la escritura del registro telefónico
generado por Asterisk a diferentes formatos, por ejemplo archivos CSV, una base de
datos MySQL, entre otras. Los CDRs son necesarios para el cobro, auditorias y para
realizar trazas de llamadas.
• CODECs (Codificador/Decodificador o Compresor/Decompresor): Codifica la voz de
un formato a otro, permitiendo que la voz sea transmitida con compresión.
• Formatos: Se utilizan para leer y escribir archivos de medios en varios formatos.
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
Figura 2. 19 Flujo de una llamada generada por un SIP UA
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.
2.10.2 Componentes del Paquete Asterisk
En la WEB de Asterisk se pueden encontrar cuatro paquetes que, dependiendo de la

instalación que se vaya a realizar, son necesarios unos u otros, a saber:
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
o superior y Asterisk 1.6.0 o superior, versiones inferiores deben utilizar el paquete

ZAPTEL. Los paquetes asociados a DAHDI son:
a. El paquete DAHDI-LINUX contiene los módulos de kernel necesario para poder

utilizar las tarjetas de comunicaciones.
b. El paquete DAHDI-TOOLS son las aplicaciones necesarias para cargar la
configuración, hacer tests a algunas tarjetas y algunas cosas más que se irán
añadiendo poco a poco.
c. El paquete DAHDI-LINUX-COMPLETE es la unión de los dos anteriores, para
no tener que descargar dos paquetes independientes.
2. LIBPRI: Es la librería encargada de dar soporte a señalización de primario (E1/T1) a

Zaptel / Dahdi. Se instala normalmente con Zaptel para que el stack quede completo, sin
embargo, no es necesario instalarlo si no se utiliza ningún primario.
3. ASTERISK: Es el código fuente de Asterisk y es el único componente necesario si la
instalación va a ser puramente VoIP.
4. ASTERISK ADD-ONS: Contiene diversas utilidades que no han podido ser incluidas en el
paquete principal por temas relacionados con el licenciamiento de aplicaciones.
2.10.3 Directorios creados por el Paquete Asterisk
• /etc/asterisk: En este directorio se encuentran todos los archivos necesarios para

configurar la gran cantidad de servicios que Asterisk provee.
• /usr/lib/asterisk/modules: Contiene los módulos de Asterisk que se han compilado.
• /var/log/asterisk: En esta carpeta se encuentran los archivos de registro de las
operaciones de Asterisk.
• /var/lib/asterisk: Directorio con archivos de audio, llaves RSA, scripts AGI (Asterisk
Gateway Interface), base de datos astdb, entre otros.
• /var/lib/asterisk/agi-bin: Directorio para contener los AGI.
• /var/spool/asterisk: Directorio de spool de Asterisk que contien diversos

subdirectorios, relacionada con la entrada y salida de archivos. .
64
CAPITULO III
METODOLOGÍA
En el presente capítulo se exponen los aspectos referidos a la metodología que se desarrollo

para para elaborar el Diseño de una Solución de Telefonía IP basada en Asterisk para
Servinave, C.A., describiendo el tipo de investigación, las técnicas de recolección de datos y
el procedimiento que se siguió para la propuesta final del Diseño.
3.1. Tipo de Investigación
El presente Trabajo Especial de Grado está enmarcado dentro de la modalidad de Proyecto

Factible, apoyado en una Investigación Documental y de Campo.
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.
Se apoya en una Investigación Documental porque es necesario consultar literatura acerca de

la tecnología utilizada (manuales, trabajos previos realizados, informaciones impresas y/o
electrónicas, entre otras ), para obtener una base teórica sólida que permita crear el enfoque
y criterio necesario para la lograr la viabilidad del trabajo. Igualmente se apoya es una
Investigación de Campo, porque fue necesario realizar entrevistas con el personal de
Servinave, inspeccionar la red de voz y datos y realizar pruebas de sus equipos telefónicos y
computadores.
3.2. Técnicas de Recolección de Datos
Las técnicas de recolección de datos que se utilizaron son las siguientes:

65
• 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.
• Observación Directa: Técnica que permitió validar la información recogida en las

entrevistas así como comprender el funcionamiento real de la plataforma tecnológica
utilizada por la Empresa.
• Revisión Documental: Mediante esta técnica se obtuvieron las bases teóricas

necesarias para la elaboración del diseño. Se basó en la revisión de todo tipo de
literatura: documentación de la red de voz y datos actual, manuales, libros, estandares
vigentes, documentos publicados en Internet, trabajos previos realizados, foros, entre
otras.
3.3 Metodología a Utilizar
El desarrollo de del Diseño de una Solución de Telefonía IP basada en Asterisk para

Servinave, C.A., fue dividido en cinco fases, las cuales son:
Fase 1: Recolectar Información
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
o Determinar la carga y el flujo del tráfico de voz intersucursal

o Red de Datos
FASE 2: Definición de la Tecnología
Actividades
• Cálculo de canales VoIP por sucursal/principal

• Selección protocolos
• Selección de CODECs
• Cálculo de ancho de banda
FASE 3: Diseño de la Propuesta
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)
FASE 4: Prueba Piloto
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
FASE 5: Análisis de Resultados
Actividades
• Impacto de la nueva propuesta

68
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.
4.1 Marco Organizacional
Servinave, C.A. es una empresa de servicios de la organización BLOHM, dedicada al

agenciamiento naviero. Entre sus principales actividades se destacan la operación de buques,
representación y documentación de las líneas navieras.
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.
De acuerdo al Dpto. de operaciones de Servinave, el proceso productivo de la empresa se

puede resumir como sigue:
69
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.
4.2 Recolectar Información
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:
4.2.1 Revisión Bibliográfica
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.
Dentro de la información obtenida se resaltan los siguientes tópicos:
• Filosofía de la telefonía convencional.

• Funcionamiento de las redes de voz y datos
71
• Filosofía de VoIP y Telefonía IP

• Administración Linux
• Funcionamiento y configuración Asterisk.
• Calidad de Servicio (QoS)
4.2.2 Identificación de Funcionalidades Necesarias por cada Sucursal/Principal
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?
De las respuestas obtenidas (ver tabla 4.1), se pudo concluir lo siguiente:
• 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):
• Hacer y recibir llamadas (internas y externas)

• Hacer transferencia de llamadas.
72
• 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
4.2.3 Revisión de la Infraestructura Actual
A través de la entrevista con el personal responsable de la red de voz y datos y de la revisión

de la documentación de la misma se pudo conocer la infraestructura desplegada a nivel
nacional.
73
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.
4.2.3.1 Servicio de Telefonía
El sistema de telefonía que utiliza la empresa es el tradicional, inclusive para comunicarse

entre las sucursales. Todas las líneas suscritas son analógicas con distinta numeración y
llegan a la central mediante par telefónico (conexión estándar). Las líneas son suministradas
por un único proveedor, CANTV, y la contratación y gestión de las mismas es tramitada
directamente por el área administrativa de cada oficina y no por el área de tecnología (a
excepción de la oficina principal). Para todas las oficinas, el cableado empleado para esta red
es categoría 3. En la tabla 4.2, se resume la cantidad de líneas contratadas por la empresa.
En cuanto a equipamiento, se dispone de varios modelos de centrales digitales, casi todos

descontinuados del mercado (ver tabla 1.1).
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.
4.2.3.2 Cálculo de Tráfico Inter-Sucursal
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
Desde la oficina Minutos

Caracas hacia Llamadas diarias diarios
Puerto Cabello 32 114,59
La Guaira 38 131,34
Maracaibo 3 5,59
Valencia 9 49,93
Cumaná 4 9,81
Puerto La Cruz 3 6,77
Punto Fijo 1 2,66
TOTAL 89 320,68
Tabla 4. 4 Resumen de llamadas desde Oficina Caracas
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
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
Maracaibo 2 4,17
Valencia 2 153,08
Cumaná 3 10,73
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
La Guaira 1 0,81
Valencia 0 0,00
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
La Guaira 1 0,79
Maracaibo 0 0,00
Cumaná 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
Desde la oficina Puerto La Llamadas Minutos

Cruz diarias diarios
Caracas 2 6,91
La Guaira 2 9,19
Maracaibo 3 8,37
Valencia 0 0,00
Cumaná 1 0,17
Punto Fijo 1 0,36
TOTAL 10 25,07
Tabla 4. 10 Resumen de llamadas desde Oficina Puerto La Cruz
Llamadas Minutos
Desde la oficina Punto Fijo diarias diarios
Caracas 1 7,19
La Guaira 0 0,00
Maracaibo 3 12,00
Valencia 0 0,00
Cumaná 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.
4.2.3.3 Red de Datos
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
802.1q 802.1p Colas

Modelo Puertos FE Puertos GE (Vlans) (QoS) x Puerto
3300XM 24 0 si si 2
4400SE 24 0 si si 4
4500 24/48 2/2 si si 8
4226T 24 2 si si 2
Tabla 4. 12 Características de los Switches de Servinave, C.A.
La navegación a Internet es independiente en cada oficina, contando una conexión ADSL en

las sucursales (ABA) y dos enlaces dedicados en la oficina central, con velocidades de
contratadas de 512 Kbps y 1024 Kbps. Adicionalmente a estos dos enlaces, la oficina
principal también cuenta con una conexión ABA, exigida para poder conectarse, via VPN, a
la aplicación del Seniat donde se declaran las cargas, SIDUNEA (Es exigencia del SENIAT
establecer una conexión VPN con ellos solo a través de una conexión ABA ).
Las sucursales de Maracaibo, La Guaira, Valencia y Puerto cabello se interconectan con la

oficina principal mediante un enlace Frame Relay mientras que las sucursales Cumaná, Puerto
La Cruz y Punto fijo se interconectan mediante una DMVPN (hub and spoke). Los routers
empleados en la red WAN son equipos CISCO 2811, para las sucursales y 2821 para la oficina
principal, todos con la versión del IOS 12.4. La Serie 2800 de Cisco, está diseñada para la
entrega a velocidad de cable para servicios concurrentes altamente seguros y puede soportar
conexiones múltiples T1/E1 para los servicios incluyendo voz, dato y video. La oficina
Principal tiene un circuito de acceso de 512 Kbps para atender a la oficina de Puerto Cabello
(256/128 Kbps), La Guaria (64/64), Valencia (32/32) y Maracaibo (64/64).
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.
El DNS principal se encuentra en la oficina principal y existe un servidor de reenvío en la

oficina de Puerto Cabello.
79
El servicio de correo electrónico esta estructurado en tres servidores: el principal en Caracas,

un servidor de relevo el Puerto Cabello y otro servidor de relevo en la Guaira. Las demás
oficinas se conectan mediante protocolo POP3 al servidor de la oficina central para bajar sus
correos y el envío de los mismos (SMTP) es directamente a través del proveedor de Internet
de cada localidad (las oficinas que tienen servidor de relevo envían a través del servidor de
correos de la oficina principal).
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.
La aplicación SPA(aplicación de gestión de Contenedores y estiba ) se encuentra instalada en

un servidor IBM ISeries ubicado en la oficina de Puerto Cabello. Esta aplicación es accedida
además por las oficinas de La Guaira y Cumaná, mediante sesiones telnet.
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
No se aplica el concepto de calidad de servicio, ni en la red LAN ni en la red WAN, y no se

lleva ninguna estadística en cuanto al delay, el jitter y el porcentaje de perdida de paquetes
en las redes.
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.
4.3 Definición de la Tecnología
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:
4.3.1 Cálculo de Canales VoIP por sucursal/principal

El cálculo de canales VoIP por sucursal/principal se basó en el modelo Erlang B, el cual
define tres variables:
• 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.
Finalmente, sabiendo que un Erlang equivale a 60 minutos de llamadas en una hora y

asumiendo como parámetro de probabilidad de bloqueo el 1%, la formula Erlarng B, arrojó
los resultados que se muestran en la tabla 4.15 :
Oficina BHT Erlang Canales

(min)
Caracas 124,5 2,075 7
Puerto Cabello 47,25 0,7875 4
La Guaira 52,35 0,8725 5
Maracaibo (E) 8.62 0.14 2
Valencia (E) 10.44 0.17 3
Cumaná (E) 3.51 0.06 2
Puerto La Cruz (E) 4.26 0.071 2
Punto Fijo(E) 3.26 0.05 2
Tabla 4. 15 Cantidad de Canales por Oficina
4.3.2 Selección de Protocolos
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
1. La señalización entre el servidor Asterisk y la PSTN es através de interfaces

FXS/FXO, con señalización KewlStart (ks), por ser la señalizacion utilizada por las
lineas analógicas y corresponder con lo que tiene contratado servinave actualmente.
2. La señalización entre el servidor Asterisk y los teléfonos IP es a través del protocolo
SIP, por se un estándar abierto de mucha popularidad en el sector y el más comercial
(es fácil conseguir en el mercado telefonos IP que trabajen con este estándar).
3. La señalización entre servidores Asterisk es a través del protocolo IAX2, por ser un
protocolo abierto originalmente creado para interconectar servidores. Asimismo, Es
capaz de enviar múltiples sesiones en un solo flujo de datos, lo que contribuye a
reducir la latencia, la necesidad de procesamiento y el ancho de banda requerido.
4.3.3 Selección de CODECs
La selección del codec para este diseño debe responder a las siguientes condiciones:
• Bajo consumo de ancho de banda.
• Que no requiera pago de licencia.
• Que no haga uso intensivo de la CPU.
Como es difícil tener las tres condiciones simultáneamente, se seleccionó:
• CODEC G711a para la comunicación entre los teléfonos que se encuentren en la

misma LAN, ya que aquí se cuenta con suficiente ancho de banda y, al no comprimir,
se evita recargar el procesador de cada servidor Asterisk. Aquí se sacrifica el ancho
de banda por bajo uso del CPU. No requiere licencia.
84
• 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.
4.3.4 Cálculo de Ancho de Banda
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.
Figura 4. 1 Calculadora de Ancho de banda
Es importante tener en cuenta que, mientras mayor es el factor de compresión, y otras

funcionalidades, mayor es el procesamiento y mayor es el retardo intrínseco de los CODECs.
85
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
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
4.4 Diseño de la Propuesta
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:
4.4.1 Definición de la Infraestructura
Este diseño persigue colocar en funcionamiento PBXs de software en equipos hardware de

propósito general (arquitectura PC), en un esquema distribuido, es decir, que cada sucursal
86
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.
El rendimiento de Asterisk no depende directamente del número de usuarios sino de la

cantidad de llamadas simultáneas que éste tiene que procesar. En tal sentido, como Asterisk
utiliza el CPU del servidor para procesar los canales de voz, necesita tener prioridad de
acceso al procesador y al sistema de buses, haciéndolo muy dependiente del rendimiento del
CPU. En consecuencia, todas las funciones que no están directamente relacionadas con las
tareas de procesamiento de llamadas de Asterisk, se deben deshabilitar o ejecutarlas con baja
prioridad. Para ello, es necesario asegurarse que no existen conflictos en la asignación de IRQ
(Interrupt Request - Pedido de Interrupción). Un conflicto de interrupciones es una fuente
potencial de problemas de calidad de audio en Asterisk que se traduce en el caso de las
tarjetas analógicas, en cortes de audio, y en el caso de las tarjetas digitales, en pérdidas de
tramas, incluida la de sincronización lo que podría ocasionar el reinicio de todo el primario.
Como se mencionó, cada instalación Asterisk se ejecutará en un servidor dedicado y se debe

implementar VLAN (acrónimo de Virtual LAN, red de área local virtual) para separar el
tráfico de voz del tráfico de data, con el objeto de proteger la red de voz de problemas de
loops, virus, tormentas de broadcast o congestionamiento de la LAN que, por el alto uso de la
CPU que hacen las tarjetas de red cuando alguno de estos fenómenos ocurren, puedan
comprometer el correcto funcionamiento de Asterisk. Las implementaciones de VLAN son
realizadas bajo el estándar IEEE 802.1Q.
Finalmente es importante resaltar que el diseño busca aprovechar, en la medida de lo posible,

la infraestructura instalada, haciendo solo ajustes necesarios para mantener un costo de
inversión-actualización razonable para la empresa.
87
4.4.1.1 VLANs y Direccionamiento
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.
VLAN DESCRIPCIÓN DIRECCIONAMIENTO

VLAN 1 Data 192.168.XX.0/24
VLAN 10 Voz (Servidor + terminales voz) 192.168.YY.0 /24
Tabla 4. 18 VLANs Sugeridas
Donde XX,YY variarán de acuerdo a cada oficina, tal como se presenta en la tabla 4.19.
OFICINAS VLAN1 VLAN10

Caracas 192.168.20.0 192.168.30.0
Puerto Cabello 192.168.22.0 192.168.32.0
La Guaira 192.168.23.0 192.168.33.0
Maracaibo 192.168.24.0 192.168.34.0
Valencia 192.168.25.0 192.168.35.0
Cumaná 192.168.26.0 192.168.36.0
Punto Fijo 192.168.27.0 192.168.37.0
Puerto La Cruz 192.168.28.0 192.168.38.0
Tabla 4. 19 Direccionamiento de las VLANs
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.
4.4.1.2 Calidad de Servicio (Quality of Service - QoS)
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.
4.4.1.2.1 QoS en teléfonos IP
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:
• Hardphones: Son terminales de usuario semejante a los teléfonos tradicionales, con la

89
diferencia que disponen de al menos un puerto de conexión RJ-45, en lugar del

tradicional RJ-11. La conexión RJ-45 es un puerto Ethernet con el cual se conectan
dichos teléfonos a la red .
• Softphones: Es un software especial que se ejecuta en el computador, y que permite al
usuario realizar llamadas como si se tratara un teléfono convencional. Es necesario
tener instalado micrófono y auriculares.
• ATA: Acrónimo de Analog Telephone Adapter, es un dispositivo electrónico que
crea una conexión física entre el teléfono analógico convencional y un PC o una red de
área local (LAN), convirtiendo y comprimiendo la señal de la voz en paquetes de datos
que se envían en una red IP tal como lo hace un Teléfono IP. Las empresas que ya
disponen de teléfonos analógicos y prefieren no invertir en nuevos teléfonos IP hacen
uso de estos dispositivos.
4.4.1.2.2 QoS en Switches
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 .
4.4.1.2.3 QoS en Routers
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.
4.4.2 Dimensionamiento y Selección del Hardware /Software
A continuación de identifican todos los elementos de hardware y software necesarios para el

diseño.
91
4.4.2.1 Interconexión con la PSTN
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.
OFICINA Nº Líneas Tarjeta

AEX2400P
CARACAS 31 AEX800P
PUERTO CABELLO 18 AEX2400P
LA GUAIRA 17 AEX2400P
MARACAIBO 11 AEX2400P
VALENCIA 5 AEX800P
CUMANÁ 4 AEX800P
PUERTO LA CRUZ 4 AEX800P
PUNTO FIJO 2 AEX800P
Tabla 4. 20 Tarjetas Digium Sugeridas
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
Es importante incluir también en cada tarjeta el módulo VPMADTO32 para ofrecer

cancelación de eco de 128 ms (1024 taps) en todos los canales. Si no se considera cancelador
de eco por hardware, es necesario entonces hacer uso de cancelador de eco por software.
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
Memoria [1] (base, máxima) 2 GB expandible hasta 8GB / CAbc

Ranuras de expansión 3 PCI y 2 PCI-Express (x8, x1)
Almacenamiento interno Disco de 250GB SATA de 7.200rpm expandible hasta Cuatro (4)
Interfaz de red GigaEthernet integrado 100/1000 Gigabit (GbE)
Fuente de alimentación 400 WATTIOS
Tabla 4. 21 Características Técnicas de los Servidores
4.4.2.3 Sistema Operativo
El diseño de la solución está basado en la distribución GNU/Linux CentOS (Community

ENTerprise Operating System) versión 5.3 como sistema operativo de los servidores Asterisk.
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:
• Asterisk: Archivos base del proyecto. Versión instalada 1.4.24.1

• DAHDI: Soporte para hardware. Drivers de tarjetas. (Anteriormente ZAPTEL).
Versión instalada dahdi linux 2.1.0.4 y dahdi tools 2.1.0.2
• Asterisk Addons: Complementos y añadidos del paquete Asterisk (opcional). Versión
instalada 1.4.8
• Libpri: Soporte para conexiones digitales. (Opcional). Versión instalada 1.4.9
94
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:
• Soporte del protocolo 802.1P/Q

• Soporte para supresión de silencios y cancelación de eco
• Interface amigable
• Compatible con los codecs iLBC, g711, entre otros.
• Protocolo de señalización SIP, IAX (opcional)
• Envío de tonos DTMF
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 sala de conferencias se sugiere el Terminal audioconferencia con pantalla marca

POLYCOM, modelo Soundstation 2 Display NE con Pantalla LCD y función de teléfono
integrada. Ideal para reuniones de hasta 8 personas. Sistema full duplex, con selección
automática del mejor micrófono.
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
4.4.2.6 Consideraciones con los equipos FAX
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 .
4.4.2.7 Alimentación de los teléfonos IP
En las redes telefónicas, los terminales reciben alimentación de la central de conmutación

publica del operador gracias a la corriente de bucle (-48V CC). Esta corriente se ve
garantizada siempre, puesto que las centrales telefónicas disponen de baterías y equipos de
emergencia para el caso de fallo de suministro eléctrico. Sin embargo, en las redes de telefonía
IP es necesario alimentar los teléfonos localmente, teniendo en cuenta los posibles fallos de la
red, para que el servicio pueda mantenerse sin discontinuidades.
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.
4.4.3 Estimación de costos
En la table 4.24, se detallan todos los costos referentes al diseño de la solución.
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
PATCH PANEL CABLE AMPHENOL 4 840,00 3.360,00
ATA 85 432,00 36.720,00

Modulo expansion 2 520,00 1.040,00
Telefono IP usuario 70 720,00 50.400,00
Auriculares 615USB 20 500,00 10.000,00
UPS servidores (6kva) 3 15.000,00 45.000,00
UPSservidores (3kva) 4 7.000,00 28.000,00
ups puestos trabajo (1kva) 136 750,00 102.000,00
TOTAL BsF 375.712,00
Tabla 4. 24 Estimación de Costos
4.4.4 Diseño del Plan de Discado (Dialplan)
El plan de discado es el responsable de la conmutación de llamadas dentro de Asterisk. Es

similar a una tabla de enrutamiento: el usuario marca un número y el dialplan contiene las
acciones a realizar para ese número que se ha marcado.
98
El dialplan se encuentra en el archivo extensions.conf y está compuesto por una serie de

contextos, en los cuales existen extensiones que tienen varias prioridades.
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.
El dialplan para Servinave permitirá:
• Trabajar con los patrones de marcado del país.

• Interconectarse con las sucursales empresa del grupo.
• Que la llamada sea redirigida a través de la PSTN, de manera transparente para el
usuario, cuando el límite de canales para comunicarse con alguna sucursal mediante la
red WAN sea alcanzado.
• Que las llamadas entrantes sean atendidas por un IVR y éste las distribuya según las
opciones seleccionadas.
• En caso de seleccionar la opción de hablar con un departamento, las llamadas deben
repicar rotativamente entre los miembros del mismo.
• Permitir la captura de llamadas por grupos.
• Aplicar restricciones a las extensiones para realizar llamadas según las
autorizaciones (internas, locales, nacionales e internacionales).
• Permitir pre-cargar números (abreviados) y que todos, independientemente de la
autorización de la extensión, puedan marcarlos.
• Cada extensión debe tener asignado su correspondiente voicemail.
• Una vez que la llamada ha ingresado, reproducir música en espera mientras el llamante
no es atendido.
• Las troncales deben estar divididas en los siguientes grupos:
o Grupo 1: Lineas directas PSTN (salientes)
99
o Grupo 2: Interconexión con la Siemens (Hacer Llamadas desde Asterisk hacia

la Siemens)
o Grupo 3: Interconexión con la Siemens(Hacer llamadas desde la Siemens hacia
Asterisk)
o Grupo 4: Lineas directas PSTN (entrantes)
Descripción Cant. Rango

digitos
Prefijo para tomar línea PSTN 1 9
Prefijo para llamar a sucursales 3 2XX
Donde XX coincidirá con el código de área de la ciudad
de la sucursal y el numero asociado corresponderá al
master de la oficina.
Caracas queda como 2121 y La guaira como 2122 en
todas las sucursales
Números Abreviados para 3 3XX

llamar a empresas del grupo
Números Abreviados para 3 4XX
llamar a proveedores y clientes
Extensiones 3 500-599
Extensiones para 3 900-999
administración de la central
Tabla 4. 25 Resumen dialplan Servinave, C.A.
En forma general, el IVR de cada oficina deberá seguir los pasos especificados en figura 4.2.
100
Figura 4. 2 Flujo de llamada atendida por el IVR

101
4.5 Prueba Piloto
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.
4.5.1 Definición de la Prueba
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.
El esquema de conexión que persigue el diseño de la solución, es sustituir las centrales

telefónicas actuales por servidores Asterisk, tal como se puede apreciar en la figura 4.3.
Figura 4. 3 Esquema de Interconexión de la Propuesta

102
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.
Figura 4. 4 Esquema de Interconexión de la Prueba Piloto
En líneas generales, la configuración a realizar en la prueba piloto se puede resumir como

sigue:
1. Reproducir, en la medida de lo posible, la actual configuración de la central Siemens en el

servidor Asterisk, sin que la central Siemens salga de servicio.
2. Interconectar la central Siemens con el Servidor Asterisk a través de 4 troncales FXO y 4
troncales FXS, para permitir que las llamadas cursen en ambos sentidos. Es decir, que
desde la Siemens puedan llamar a extensiones Asterisk y desde Asterisk se puedan llamar
a extensiones Siemens.
3. Desviar las extensiones Siemens actuales del grupo piloto a las nuevas extensiones
Asterisk correspondientes, para que todas las llamadas las reciban y realicen por
softphone/ hardphone.
4. Configurar para que todas las llamadas de salida de las extensiones definidas en el servidor
Asterisk, sean procesadas por éste y solo se ocupe el enlace de interconexión por las
103
llamadas Siemens-Asterisk y viceversa.

5. Definir líneas de entrada también para el servidor Asterisk, con su correspondiente IVR,
aunque el master principal permanezca en la Siemens.
6. Una vez instalado los dos servidores Asterisk (uno en cada oficina), interconectarlos para
evaluar la calidad de las llamadas que cursen por el enlace.
7. Cuando el usuario tome una línea, y ya se haya alcanzado el límite máximo destinado para
cursar llamadas por el enlace, configurar para que tome automáticamente una línea de la
PSTN y haga la llamada al master de la oficina.
El Hardwarey Software seleccionado para la prueba piloto, se especifíca a continuación:
• 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.
4.5.2 Instalación y Configuración
En está actividad se fueron realizando las diferentes configuraciones necesarias para alcanzar
las funcionalidades requeridas.
104
4.5.2.1 Creación de VLAN
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 cada switche se realizó los siguientes pasos:

• Se creó la VLAN 10.
• Se agregó la MAC Address del teléfono Linksys a la tabla de direcciones OUI del
switch.
• Se configuró la VLAN 10 como VLAN de voz.
• Se creó como puerto trunk los puertos que comparten el punto de switch con el pc y
además:
o Se asignó por defecto la VLAN 1
o Se permitió el tráfico de la VLAN 10
o Se habilitó la voiceVLAN
• Se creó las rutas estáticas para alcanzar las dos redes (vlan 1 y 10).
• Se asignó las direcciones IP a las interfaces VLAN de los switch.
4.5.2.2 Instalación del Sistema Operativo GNU/Linux (CentOS 5.3)
A continuación se enumeran los pasos realizados para instalar la distribución de Linux

CentOS en el servidor de Asterisk.
• Se habilita la opción de arranque del equipo (boot) en el Bios.
• Se introduce el DVD con el sistema operativo.
• Se enciende el equipo.
• Se selecciona “Enter” para proceder con la instalación en modo gráfico.
• Se selecciona “OK” para realizar validación del CD de instalación, o “SKIP” para
omitir la prueba.
105
• Se selecciona el idioma de instalación (Español).

• Se selecciona el idioma del teclado (latinoamericano o Inglés EU).
• Se selecciona “Remover particiones en dispositivos seleccionados y crear disposición”
para formatear el disco y crear las dependencias del Sistema Operativo.
• Seleccionar la opción manual, colocar Nombre del Host: asterisk.XX.com.ve
• Región: América / Caracas
• Colocar clave de root
• Desactivar la opción Desktop – Gnome y se habilita KDE – Desktop
• Seleccionar la opción de personalizar la instalación de componentes.
• Eliminar en Aplicaciones: editores, gráficos, internet basada en texto, juegos y
entretenimiento, oficina y productividad, sonido y video
• Eliminar en Servidores, soporte para impresión.
• Eliminar en Sistema base, soporte de red mediante discado.
• Activar en servidores: Servidor de correo (por defecto), servidores de red anticuados
(tftp server).
• Activar en desarrollo: bibliotecas de desarrollo (por defecto), desarrollo de software
anticuado (por defecto), herramientas de desarrollo (por defecto).
• Validar las dependencias y luego seleccionar siguiente para comenzar la instalación.
• Al finalizar la instalación retirar el DVD y reiniciar la PC; al reiniciar el PC el sistema
solicitará una configuración adicional.
• Cortafuegos: seleccionar la opción de deshabilitado.
• SELINUX (Security Enhanced Linux): seleccionar la opción deshabilitado.
• Tarjeta de Sonido: No seleccionar nada.
• CD´s adicionales: No seleccionar nada y reiniciar.
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
• yum install zlib zlib-devel

• yum install TFTP-server
• yum install GCC-C++
• yum update kernel-devel
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
Editar el archivo /etc/sysconfig/network-scripts/ifcfg-ethx (donde x es el número de la

interfaz) y configurar los parámetros especificados en la tabla 4.26:
CARACAS PUERTO CABELLO

IP 192.168.30.24 192.168.32.24
Mascara 255.255.255.0 255.255.225.0
Nombre CCS01 PBL01
GW 192.168.30.16 192.168.32.16
Tabla 4. 26 Parámetros TCP/IP a Configurar
4.5.2.3 Instalación de los Servicios de Telefonía
a) Obtener los archivos de instalación de los servicios (www.asterisk.org) e instalarlos

en la ruta /usr/src:
• Asterisk –1.4.24.tar.gz
• Dahdi Linux 2.1.0.4 y Dahdi tools 2.1.02
• Libpri 1.4.9
• Asterisk Addons 1.4.8
107
b) Compilar el código en el orden reflejado en la tabla 4.27:
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
4.5.2.4 Instalación de las tarjetas de Telefonía
Se instalaron las tarjetas DIGIUM seleccionadas en el servidor Asterisk, de la siguiente

manera:
• Se colocaron las tarjetas en el slot PCI correspondiente

108
• Se encendió el equipo y se ejecutó el comando dmesg para revisar la bitácora. Un

extracto de la salida debe ser similar a lo mostrado en la figura 4.5:
Figura 4. 5 Salida Dmesg
Asimismo, ejecutar los comandos cat /proc/interruptions (figura 4.6). y lspci –vvvv ( figura
4.7) para validar que no haya conflicto de interrupciones.
Figura 4. 6 Salida del Comando cat /proc/interrupts

109
Figura 4. 7 Salida del Comando lspci -vv
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).
Para que no se cargue en el próximo reinicio del servidor, se editó el archivo

/etc/modprobe.d/blacklist y se agregó al final la línea : blacklist snd-hda-intel (ver figura 4.8).
De acuerdo al documento “PC Card Common Instalations Issues” de Richard Spencer, se

realizaron también los siguientes ajustes:
• Se deshabilitó la interface gráfica (en el archivo de configuración /etc/inittab, se asignó

el 3 como nivel de arranque: id:3:initdefault).
• Se deshabilitó el framebuffer (en el archivo de configuración del gestor de arranque
/boot/grub/menu.lst se agrego la línea vga=normal).
• Se asignó el IRQ de la tarjeta Digium al procesador 1 mediante la instrucción “echo 2
> /proc/irq/169/smp_affinity”. Asi las peticiones de esta tarjeta serán atendidas por el
110
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.
Figura 4. 8 Sin Compartir Interrupciones
4.5.2.5 Archivos de Configuración de Asterisk
4.5.2.5.1 Configuración de DAHDI
Se deben configurar dos archivos: /etc/dahdi/system.conf (ver tabla 4.28) y

/etc/asterisk/chan_dahdi.conf (ver figura 4.9).
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
Los parámetros habilitados en el archivo chan_dahdi son:

• busydetect (yes/no): Con esta opción habilitada, Asterisk escuchará el tono de
ocupado cuando el proveedor del servicio lo mande.
• busycount (Número): Es el número de tonos de ocupaddo cuando busydetect está
habilitado.
• callwaiting (yes/no): Habilita o no la llamada en espera en lineas FXO .
• context: Define el contexto inicial para el canal.
• echocancel (yes/no/ número entero) Habilita o no la cancelación de eco. También
admite un valor de 32 to 256 para configurar el numero de taps.
112
• echocancelwhenbridged (yes,no) : Cancelar eco cuando se puentee una llamada.

• echotraining (yes, no, o un numero de milisegundos -10 – 2000 -): Mecanismo para
mejorar el tiempo de convergencia del cancelador de eco
• group: Permite a un número de canales ser tratados como uno, para propósitos de
marcado. Se crearon cuatro grupos:
o Grupo 1: Llamar a la PSTN (Salientes)
o Grupo 2: Llamar a extensiones de la Siemens
o Grupo 3: Recibir llamadas desde la extensiones Siemens
o Grupo 4: Recibir llamadas desde la PSTN (Entrantes)
• hidecallerid (yes / no): Ocultar el identificador del llamante en las llamada salientes.
• DTMF (yes / no): detector tonos DTMF
• Threewaycalling: (yes / no): Soportar llamada a 3
• Musiconhold=default: Habilita la música en espera.
• transfer (yes/no): Permitir la transferencia de llamadas.
• canpark (yes/no) Habilita o no el parkeo de llamadas.
• usecallerid (yes/no) : Usar identificador de llamadas.
4.5.2.5.1.1 Otros comandos de verificación
Existen varios comandos que son útiles para revisar el hardware instalado, entre ellas está:
• dahdi_hardware: Es para detectar el tipo de tarjeta que se está usando, al mismo

tiempo para ver si la reconoce.(ver figura 4.10).
Figura 4. 10 Salida del Comando Dahdi_Hardware

113
• dahdi_cfg –v : Es para verificar que el archivo de configuración está correcto;

muestra los canales bien configurados (ver figura 4.11)
Figura 4. 11 Salida Comando dahdi_cfg
• Dahdi_test: Permite verificar los conflictos de interrupción. Es común los problemas

de calidad de audio por causa de conflictos y pérdidas de interrupción. El número de
interrupciones no debe ser peor que 99,987793%, según dice Goncalvez (2007); en
este caso, el resultado arrojado por el comando (ver figura 4.12 ) está por encima de
ese valor.
Figura 4. 12 Salida del Comando dahdi_test

114
4.5.2.5.2 Configuración de canales SIP
La configuración de los dispositivos SIP se realiza mediante el archivo sip.conf. En este

archivo se definen variables generales, clientes y servidores SIP y se estructura en secciones
donde cada sección se define por un nombre entre corchetes seguido de las opciones de dicha
sección.
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
[530] Número de extensión del cliente.
callerid="Adriana Identificación del Llamante

Sanchez" <530>
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
4.5.2.5.3 Interconexión de servidores Asterisk
La interconexión de servidores Asterisk se realizó mediante el protocolo IAX2. Para realizar la

inteconexión, se configuró el archivo iax.conf de cada servidor Asterisk, como sigue:
Servidor oficina Caracas (principal)
[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
El parámetro register permite al servidor de Caracas registrarse en el servidor de Puerto

Cabello (servidor remoto), identificándose como usuario CCS01, para así poder recibir y hacer
llamadas o acceder a los servicios como buzón de voz desde cualquier terminal de las dos
instalaciones.
Servidor oficina Puerto Cabello
[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
Donde PBL01 es el servidor Asterisk ubicado en la oficina de Puerto Cabello (servidor

local) y CCS01 es el servidor Asterisk ubicado en la oficina de Caracas (servidor remoto).
4.5.2.5.3.1 Comandos de verificación
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).
Figura 4. 13 Comando de Verificación de Registro

118
4.5.2.5.4 Instalación del codec iLBC
Desde la versión de Asterisk 1.4.19 ya no se incluye el codec iLBC de serie, y si se desea

usarlo se debe seguir el siguiente procedimiento:
• Editar el archivo /usr/src/asterisk1.14.24.1/contrib/scripts/ get_ilbc_source.sh y

comentar la linea 21 (read)
• Ejecutar el archivo get_ilbc_source.sh
• Copiar la carpeta ilbc a la carpeta codecs de asterisk
• Ejecutar make menuselect y seleccionar dentro del apartado de codecs la opción ILBC
• Compilar asterisk (make y todos los pasos subsiguientes)
• Si al ejecutar el comando core show translations, aparecen valores en la fila/columna
correspondiente al codigo, quiere decir que esta activado (ver figura 4.14).
Figura 4. 14 Salida del Comando Core Show Translation
Los valores reflejados indican el tiempo de conversión de formatos (en milisegundos) para un
segundo de data .
119
4.5.2.5.5 Configuración del plan de discado (Dialplan)
Como se ha mencionado anteriormente, el plan de discado o dialplan contiene el conjunto de

instrucciones o pasos que Asterisk deberá seguir para la conmutación de llamadas. Es el que
controla como las llamadas de entrada y salida son encaminadas y configuradas.
Este conjunto de instrucciones se encuentra definido en el archivo extensions.conf. Dentro de
este archivo también se puede hacer referencia a otros archivos, mediante la declaración
#include <archivo>, si se desea dividir el dialplan en varios. Esta división se realiza entre
otras razones, para hacerlo mantenible.
En este proyecto, el dialplan se dividió en dos archivos de configuración: extensions.conf y

servicios.conf, donde el primero es el principal y el segundo contiene los servicios de la
central, como conferencias, voicemail, extensiones de testeo, entre otros.
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
• Clearglobalvars: con cada recarga de extensions.conf se recargarán las variables globales

de Asterisk. Si se desactiva las variables globales permanecerán con el valor que tienen en
memoria, hasta que se vuelva a reiniciar Asterisk y a recargar el extensions.conf.
• Priorityjumping: Activa el salto de prioridad como respuesta, hay aplicaciones que tras
su ejecución devuelve una prioridad.
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).
Figura 4. 15 Flujo de Llamadas en Asterisk
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
TIPO DE ACCESO PATRON DESCRIPCION

Local 9XXXXXXX 9 es el indicador de que la llamada es hacia la
Celular 904XXXXXXXXX PSTN, las X indican que puede tomar cualquier
Nacional 902XXXXXXXXX valor entre 0 y 9. La cantidad de X indica la
Internacional 9XXXXXXXXXXX longitud del string esperado. Los valores entre
Informacion o emergencia 9XXX corchetes indican que, en este caso, la tercera
0800 o 0500 90[58]00XXXXXXX posición del string solo puede ser un 5 o un 8.
Ext Siemens 74XX 7 es el indicador de que la llamada es hacia la

Siemens. Todas las extensiones en Siemens
empiezan por 4 y son de 3 digitos.
Ext Asterisk 5XX Las ext. en asterisk van de la 500-599
Tabla 4. 32 Patrones de Marcado
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
b) SoloLocal: Permite llamadas locales mas todo lo definido en el contexto SoloInternas.

c) SoloCelular: Permite llamadas a celulares más todo lo definido en el contexto
SoloLocal.
d) SoloNacional: Permite llamadas de larga distancia nacional más todo lo definido en el
contexto SoloLocal.
e) Nacional-Celular: Permite llamadas a celulares, de larga distancia nacional más todo
lo definido en el contexto SoloLocal.
f) SinRestricción: Permite llamadas internacionales más todo lo definido en el contexto
Nacional-Celular.
g) Phones: Contexto que incluye todos los contextos creados en el dialplan.
4) Se creó el contexto Abreviados, que a su vez contiene los contextos Abreviados-
Sucursales (prefijo 2XX), Abreviados-Blohm (prefijo 3XX) y Abreviados-Otros (prefijo
4XX) para que cualquier extensión pueda llamar a estos teléfonos, independientemente de
las restricciones que posea.
5) Para limitar el número de llamadas simultáneas y desbordar a la PSTN, en caso de no
haber canales disponibles, se creó el contexto Asterisk-PBL01, donde primero se verifica
que la cantidad de canales establecidos hacia el grupo pbl sea menor a 5 (hasta 4 permitía
el cálculo), y si no es así , se hace una llamada por la PSTN al máster de la oficina en
cuestión. Aquí se hace uso de las funciones Group y Group_count(), que permiten colocar
un canal dentro de un grupo y contar cuantos canales activos existen en un determinado
momento. A continuación se presenta el contexto mencionado:
[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).
4.5.2.5.5.1 Buzones de Voz
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:
• VM_NAME: Nombre del propietario del buzón

• VM_DUR: Duración del mensaje
• VM_MSGNUM: Número de orden de este mensaje
• VM_MAILBOX: Buzón de voz
124
• VM_CALLERID: Nombre y número de la persona que ha llamado.

• VM_CIDNUM: Número de la persona que ha llamado.
• VM_CIDNAME: Nombre de la persona que ha llamado.
• VM_DATE: Fecha y hora del mensaje.
[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}
;
emailbody= Estimado (a) ${VM_NAME}: \n\n\t Deseo informarle que tiene un

mensaje de voz (numero ${VM_MSGNUM}) con una duracion de ${VM_DUR}\n en el
buzon ${VM_MAILBOX} de parte de ${VM_CALLERID}, en la fecha "$
{VM_DATE}".\n\n Espero pueda revisarlo prontamente (puede escucharlo desde
su telefono marcando *98) .\n\n Gracias!\n\n\t \t\t\t—Central Telefonica
Asterisk Caracas \n
;
mailcmd=/usr/sbin/sendmail -t
[zonemessages]
Caracas=America/Caracas|'vm-received' Q 'digits/at' R
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.
El formato utilizado para definir cada buzón es:
Extensión => contraseña, nombre usuario, email, buscapersonas usuario,opciones…

125
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
4.5.2.5.5.2 Interactive Voice Response (IVR)
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 programar el IVR se disponen de las siguientes aplicaciones:
• Playback (sonido): Reproduce el sonido

• WaitExten(tiempo): Espera a que el usuario teclee una opción (o un número de
extensión)
• Background (sonido): Reprodcr un sonido, pero el usuario puede interrumpir la
reproducción, tecleando un número de opción. Sería equivalente a utilizar las
aplicaciones Playback y WaitExten de forma simultánea.
• GotoIfTime(hora|dia_semana|dias_mes|año?si_cierto:si_falso): Realiza un salto a
otro punto del dialplan dependiendo de la fecha y la hora. Resulta útil para emitir un
mensaje si se esta en horario de oficina o uno distinto si se está fuera de éste.
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”.
Asterisk usa algunos nombres de extensión para propósitos especiales. A continuación se

indica cuáles son estas extensiones y cuál es su significado:
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.
Ejemplo de la cola para el dpto de sistemas definido en el archivo queues.conf:
[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
4.5.2.5.5.3 Otros archivos de configuración
A parte de los archivos mencionados, también fue necesario modificar otros para
complementar las funciones que se perseguían en plan de marcado.
• Hay dos tipos de transferencia, la directa (blindxfer) y la asistida (atxfer). Los

parámetros para ambos tipos de transferencias y sus correspondientes secuencias de
teclas estan definidas en el archivo features.conf, las cuales son #11 y *2
respectivamente. Para hacer uso de este servicio, en el archivo sip.conf debe estar
configurado el parámetro canreinvite=no y en el archivo extensions.conf las opciones
“t“ o “T” deben estar configuradas en el comando DIAL (t permite al usuario Llamado
transferir la llamda. T permite al usuario de origen transferir la llamada).
Adicionalmente, tanto el softphone como el hardphone tienen un botón que permite
realizar la transferencia de llamadas directamente sin utilizar la secuencia de teclas
mencionadas.
• En este mismo archivo features.conf, en la sección general, se cambiaron los
parametros: parkext => 700 y parkpos => 701-720, que corresponden a la extensión
donde el usuario deberá transferir la llamada a parquear y las extensiones donde
debera llamar posteriormente para recuperar la llamada, por los valores 923 y por 924-
940 respectivamente.
• Para crear las salas de conferencias, aparte de incluir la aplicación meetme en el
archivo extensions.conf, se debió crear la sala de conferencia en el archivo
meetme.conf . En la sección rooms, se colocaron las salas que seran accedidas
marcando las extensiones definidas en el archivo extensions.conf.
• Para activar la música en espera se debe editar el archivo chan_dahdi.conf y colocar
dentro de la sección [channels], musiconhold=default. Si se desea personalizar la
música en espera, se debe editar el archivo musiconhold.conf.
130
• 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).
Después de realizar los cambios en estos archivos se recomienda reiniciar asterisk
4.5.2.6 Configuración de los terminales de voz
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.
4.5.2.6.1 Configuración del hardphone Linksys SPA922
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).
Figura 4. 16 Seleccionar el CODEC Preferido
4.5.2.6.2 Configuración del softphone Zoiper
• Entrar al menú de herramientas, como se indica en la figura 4.17.
Figura 4. 17 Menú de Herramientas

132
• 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).
Figura 4. 18 Crear Cuenta SIP
• Activar la opción de cancelación de eco y seleccionar el headset VoIP en Input y

output device. También se debe configurar como Ringing device, las cornetas del
equipo, para que pueda escuchar cuando una llamada entra aún cuando no tenga el
headset puesto. (ver figura 4.19)
Figura 4. 19 Configuración del Audio en Zoiper
• Seleccionar los CODECs correspondientes. En este caso iLBC y aLAW (ver figura
4.20)
133
Figura 4. 20 Selección de CODECS
4.5.3 Revisión y Ajustes
A continuación se mencionan los ajustes realizados al diseño original.
• El archivo indications.conf que viene con la versión de Asterisk instalada, no contiene

los tonos correctos para Venezuela. Fue necesario actualizar los tonos según
información suministrada por CANTV.
• Se habilitó para que las llamadas a las extensiones Siemens fueran enrutadas sin
marcar el prefijo 7.
• Se colocó la misma combinación de teclas que usa Siemens en Asterisk para llamar al
voice mail, capturar llamadas, marcar abreviados, entre otras, que son frecuentemente
usadas por el personal (de la oficina de Caracas).
• Se configuró el master para que entrara directamente por Asterisk. Originalmente el
master entraba por la Siemens y si la llamada iba para una extensión IP, la llamada era
transferida a través de los canales FXS/FXO de la interconexión. El problema es que
Siemens cuando hacia ese tipo de transferencia, asignaba un temporizador para cortar
la llamada. Esto implicaba que si la llamada duraba mas del tiempo establecido, se
cortaba y si duraba menos, mantenía el canal ocupado hasta que se cumpliera el
tiempo establecido. Al hacerlo de manera contraria, no era necesario establecer ningun
temporizador porque Asterisk se entera siempre cuando la llamada finaliza y libera los
canales inmediatamente.
134
• Los modelos de teléfonos Siemens que tiene Servinave, no permiten hacer

transferencia a ciegas a las extensiones Asterisk. Solo es posible hacer la transferencia
de forma atendida.
4.5.4 Conclusiones de la Prueba Piloto
Inicialmente se empezó a trabajar con la distribución precompilada de Asterisk TRIXBOX y

se comprobó que es realmente sencillo configurar Asterisk a través de la interfaz gráfica
provista en la distribución. Como se sabe, el objetivo de toda interfaz gráfica es simplificar la
configuración y gestión de una aplicación (en este caso, de Asterisk), sin embargo, tiene sus
limitaciones. Enterarse y entender todo lo que implica cualquier cambio que se realiza desde la
interfaz gráfica se hace complejo por la cantidad de código (macros, includes y variables) que
escribe la interfaz gráfica en los archivos de configuracións para hacer una simple tarea
alusiva a una llamada. Después de varios intentos de tratar de comprender los archivos de
configuración generados, se procedió entonces a desinstalar TRIXBOX y a instalar el
sistema operativo CentOS y el Asterisk manualmente, para asi configurarlo directamente a
través de los archivos de configuración, paso a paso. Hacerlo de esta manera permitó conocer
mejor todo lo que implicaba la configuración realizada, lo que se traduce en mejor tiempo de
respuesta para el soporte en caso de fallas. No obstante, el trabajar con una interfaz gráfica
ciertamente facilita y automatiza muchas tareas de configuración, pero agrega una nivel mas
de complejidad al momento de resolver problemas.
La configuración realizada en cada servidor Asterisk de la prueba piloto, corresponde a la

sostenida actualmente por las centrales Siemens de cada oficina involucrada en la prueba, lo
que asegura que la Empresa puede contar con las mismas funcionalidades con las que ya
cuenta la oficina y a partir de aquí, empezar a aprovechar otras funcionalidades como por
ejemplo un IVR para la oficina de Puerto Cabello, que actualmente no lo tiene.
La mayoría de los ajustes realizados al Dialplan correspondían a mejorar la experiencia del

usuario, más que a una falla reportada.
135
Si el PC tiene instalado un softphone y ejecuta aplicaciones agresivas o pesadas,

simultánemente con una conversación telefónica, la conversación se entrecorta.
Las interfaces FXS/FXO utilizadas para la interconexión tendían en ocasiones a quedarse

inhibidas y era necesario resetearlas.
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.
4.6 Análisis de Resultados
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.
En cuantos a los teléfonos, es importante decir que, aparte de facilitar la comunicación,

afectan considerablemente la percepción del usuario acerca de la calidad de audio en un
sistema VoIP. La evaluación y selección del teléfono IP correcto como una parte integral de
la implementación del sistema VoIP, permite definir una solución completa optimizada, sin
importar si son móviles o se basan en escritorio. Además del criterio requerido para ofrecer un
nivel superior de audio en un entorno VoIP, la durabilidad y la comodidad al usarlo son
factores importantes y determinantes. La elección incorrecta de este elemento puede afectar
considerablemente el proyecto completo, asegurando el éxito o el fracaso del mismo.
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.
Es necesario formar al personal de sistemas de la empresa en esta nueva tecnología .
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.
La alimentación eléctrica de respaldo es muy importante considerarla, sobre todo en las

sucursales, ya que el servicio eléctrico en esas zonas no es tan estable como lo es en Caracas
y es un punto álgido en la implementación de la solució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.
Es importante destacar que un contexto represente un único concepto, es decir, que el

contexto SoloLocal , por ejemplo, defina la forma de hacer llamadas locales únicamente y no
también a celulares, larga distancia nacional e internacional. Esta forma de dividir el dialplan
en contextos posibilitará que luego éstos sean combinados como se necesite mendiante la
sentencia include y asi evitar repetir codigo y en consecuencia hacer el dialplan fácilmente
mantenible.
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
Gomez, J y Gil F. (2008). VoIP y Asterisk Redescubriendo la Telefonía. Primera edición.

Almería: RA-MA
Goncalvez, F. (2007). Asterisk PBX Guía de Configuración. Tercera edición. Florianópolis:

título independiente.
Van Meggelen, J., Smith, J. y Madsen, L (2007). Asterisk the Future of Telephony. Segunda
edición.. Estados Unidos: O’Reilly Media, Inc.
Huidobro, J. y Roldán, D. (2006). Tecnología VoIP y Telefonía IP. México: Alfaomega.

Stallings, W. (2004). Comunicaciones y Redes de Computadores. Séptima edición. Madrid:
Pearson Educación.
Tamayo y Tamayo, M. (1991). El Proceso de la Investigación Científica. México, México.

Editorial Limusa.
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
Silva, M. (2006). Guía de Configuración e Instalación de Asterisk . Extraído el 25 abril de

2009 desde http://www.moythreads.com/wordpress/?p=13.
Ganzábal, J. (2008). Cálculo de Ancho de Banda en VoIP.Extraído el 15 de marzo de 2009

desde http://www.idris.com.ar/lairent/pdf/ART0001%20-
%20Calculo%20de%20ancho%20de%20banda%20en%20VoIP.pdf.
ITU-T (2001). Foro Mundial De Política De Las Telecomunicaciones FMPT . Extraído el

23 de febreo de 2009 desde
http://www.itu.int/osg/spu/wtpf/wtpf2001/Chairreport/Chair%20report%20final%20-
Spanish.pdf.
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á.
Fuenmayor, J. (2006) Guía de Sistemas de Telecomunicaciones. Universidad Central de

Venezuela. Caracas.
UNIVERSIDAD SIMON BOLIVAR
NOMBRE DEL ESTUDIANTE: ADRIANA SÁNCHEZ BOUZAS

TITULO DE LA TESIS: DISEÑO DE UNA SOLUCIÓN DE TELEFONÍA IP BASADA EN
ASTERISK PARA SERVINAVE,C.A.
NOMBRE DEL ASESOR: WILMER PEREIRA
MIEMBROS DEL JURADO: VIDALINA DE FREITAS / MONICA HUERTA
PALABRAS CLAVES: PBX, VoIP, Telefonía IP, Convergencia de Redes, Software Libre
SOBRESALIENTE: GRADUADO CON HONORES:
Nº DE PAGS: 140 FECHA DE GRADUACIÓN:
MAESTRÍA EN: ESPECIALIZACIÓN EN TELEMÁTICA
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.

Universidad Simón Bolívar

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Universidad Simón Bolívar

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SIMÓN BOLÍVAR

DECANATO DE ESTUDIOS DE POSTGRADO

TRABAJO ESPECIAL DE GRADO

DISEÑO DE UNA SOLUCIÓN DE TELEFONÍA IP BASADA EN

ADRIANA SÁNCHEZ BOUZAS

DISEÑO DE UNA SOLUCIÓN DE TELEFONÍA IP BASADA EN

Trabajo Especial de Grado presentado a la Universidad Simón Bolívar por

Adriana Sánchez Bouzas

Como requisito parcial para optar al grado académico de

Con la asesoría del prof. Wilmer Pereira