Universidad Simón Bolívar

UNIVERSIDAD SIMN BOLVAR
DECANATO DE ESTUDIOS DE POSTGRADO

COORDINACIN DE POSTGRADO EN INGENIERA ELECTRNICA
ESPECIALIZACIN EN TELEMTICA
TRABAJO ESPECIAL DE GRADO
DISEO DE UNA SOLUCIN DE TELEFONA IP BASADA EN

ASTERISK PARA SERVINAVE,C.A.
por
ADRIANA SNCHEZ BOUZAS
Octubre, 2009


ASTERISK PARA SERVINAVE, C.A.
Trabajo Especial de Grado presentado a la Universidad Simn Bolvar por
Adriana Snchez Bouzas
Como requisito parcial para optar al grado acadmico de

ESPECIALISTA EN TELEMTICA
Con la asesora del prof. Wilmer Pereira
Octubre 2009
ii

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

Universidad Simn Bolvar por el siguiente jurado examinador:
__________________________________
Profa. Vidalina De Freitas
Presidente
__________________________________
Profa. Mnica 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 corresponda 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 quera
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 bendicin de la familia.
A Maria Miguelina, por toda la orientacin, solidaridad y amistad prestada para culminar este
trabajo ahora te toca a ti, amiga!
A todas las personas que sin saberlo fueron fuente de inspiracin y me ayudaron a concretar
este trabajo.

Por: Snchez 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 geogrficamente en estados distintos. El
sistema de comunicacin de voz que utiliza la empresa es telefona convencional a travs de
centrales telefnicas bsicas cuyos modelos, en general, ya estn descontinuados. Con el
auge de Internet se han desarrollado muchas aplicaciones, modelos, servicios y tecnologas,
entre ellas tenemos, Voz sobre IP, tecnologa sta que se desea aprovechar para disear una
solucin de Telefona IP basada en software libre, que le permita a Servinave, C.A., desde el
punto de vista tcnico, actualizar la plataforma de telefona e integrar la infraestructura del
cableado de voz y datos, garantizando un servicio confiable, seguro, portable, de calidad y
fcil gestin que simplifique las comunicaciones de la empresa con sus sucursales y clientes.
Desde el punto de vista econmico, se espera una reduccin en los costos, manteniendo la
calidad de servicio igual o superior a la acostumbrada y la generacin de nuevos servicios, a
un costo de inversin razonable. En otras palabras, converger ambas formas de trfico sobre
una sola red para restar gastos y complejidad. Este diseo trabajar con una distribucin del
Sistema Operativo GNU/ Linux y con el software de PBX Asterisk, por ser sistemas de
fuente abierta ampliamente aceptados en el mercado. La investigacin est enmarcada en la
modalidad de proyecto factible, y las etapas que se van a seguir van desde la formacin en la
plataforma Asterisk, diagnstico de la situacin actual, identificacin de los componentes de la
red convergente deseada hasta culminar con el diseo de la propuesta.
Palabras claves: PBX, VoIP, Telefona IP, Convergencia de Redes, Software Libre.
vi
NDICE GENERAL
Pg.
APROBACIN DEL JURADO .ii
DEDICATORIA........................................................................................................................ iii
AGRADECIMIENTOS..............................................................................................................iv
RESUMEN ..................................................................................................................................v
NDICE DE TABLAS.................................................................................................................x
NDICE DE FIGURAS ............................................................................................................ xii
LISTA DE SMBOLOS Y ABREVIATURAS ....................................................................... xii
INTRODUCCIN.......................................................................................................................1
CAPTULO I: EL PROBLEMA .................................................................................................3
1.1 Planteamiento del Problema...............................................................................................3
1.2 Justificacin.......................................................................................................................4
1.3 Objetivos del Trabajo .........................................................................................................6
1.3.1 Objetivo General.......6
1.3.2 Objetivo Especficos..6
CAPTULO II: MARCO TERICO...........................................................................................7
2.1 Redes Conmutadas .............................................................................................................7
2.1.1 Conmutacin de Circuitos.7
2.1.2 Conmutacin de Paquetes..8
2.2 Descripcin General de la Red Telefnica Convencional ...............................................10
2.2.1 Sealizacin.12
2.2.1.1 Sealizacin Abonado a Red...13
2.2.1.2. Sealizacin entre Centrales.......15
2.3 Redes IP15
2.4 Voz Sobre IP (VoIP).....18
2.5 Telefona IP ......................................................................................................................19
vii
2.6 CODEC ............................................................................................................................19

2.6.1 Funcionamiento del CODEC..20
2.6.1.1 Muestreo..20
2.6.1.2 Cuantificacin..21
2.6.1.3 Codificacin.21
2.6.2 Tipos de CODEC21
2.6.2.1 ITU-T G.71122
2.6.2.2 ITU-T G.723.1.22
2.6.2.3 ITU-T G.72622
2.6.2.4 ITU-T G.72922
2.6.2.5 Ilbc...23
2.6.2.6 GSM.23
2.6.2.7 SPEEX.24
2.6.3 Parmetros 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 Prdida de Paquetes.....28
2.7.4 Eco...28
2.8 Arquitectura de los Protocolos de VoIP..........................................................................29
2.8.1 Protocolo de Sealizacin H.32330
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 Sealizacin de Inicio de Sesin SIP.35
2.8.2.1 Componentes de una Red Basada en SIP38
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 Sealizacin de Intercambio Inter Asterisk (IAX).48
viii
2.8.3.1 Tramas o Mensajes IAX49

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 Clculo de Ancho de Banda......................................................54
2.9.1 Retardo...57
2.9.1 Otros Factores.58
2.10 Asterisk...........................................................................................................................58
2.10.1. Arquitectura Asterisk59
2.10.2 Componentes del Paquete Asterisk...62
2.10.3 Directorios creados por el Paquete Asterisk.63
CAPTULO III: METODOLOGA...........................................................................................64
3.1. Tipo de Investigacin...64
3.2. Tcnicas de Recoleccin de Datos...64
3.3 Metodologa a Utilizar...65
CAPTULO IV: DESARROLLO..............................................................................................68
4.1 Marco Organizacional ......................................................................................................68
4.2 Recolectar Informacin ...................................................................................................70
4.2.1 Revisin Bibliogrfica70
4.2.2 Identificacin de Funcionalidades Necesarias por cada Sucursal/Principal...71
4.2.3 Revisin de la Infraestructura Actual.72
4.2.3.1 Servicio de Telefona...73
4.2.3.2 Clculo de Trfico Inter-Sucursal74
4.2.3.3 Red de Datos...77
4.3 Definicin de la Tecnologa....80
4.3.1 Clculo de Canales VoIP por sucursal/principal81
4.3.2 Seleccin de Protocolos..82
4.3.3 Seleccin de CODECs....83
ix
4.3.4 Clculo de Ancho de Banda....84

4.4 Diseo de la Propuesta....85
4.4.1 Definicin de la Infraestructura...85
4.4.1.1 VLANs y Direccionamiento87
4.4.1.2 Calidad de Servicio (Quality of Service - QoS)..87
4.4.2 Dimensionamiento y Seleccin del Hardware /Software...90
4.4.2.1 Interconexin con la PSTN..91
4.4.2.2 Servidores92
4.4.2.3 Sistema Operativo93
4.4.2.4 Asterisk93
4.4.2.5 Telfonos IP.94
4.4.2.6 Consideraciones con los equipos FAX96
4.4.2.7 Alimentacin de los telfonos IP.96
4.4.3 Estimacin de costos...97
4.4.4 Diseo del Plan de Discado (Dialplan)...97
4.5 Prueba Piloto ..................................................................................................................101
4.5.1 Definicin de la Prueba.101
4.5.2 Instalacin y Configuracin..103
4.5.2.1 Creacin de VLAN104
4.5.2.2 Instalacin del Sistema Operativo GNU/Linux (CentOS 5.3)..104
4.5.2.3 Instalacin de los Servicios de Telefona..106
4.5.2.4 Instalacin de las tarjetas de Telefona.107
4.5.2.5 Archivos de Configuracin de Asterisk...110
4.5.2.6 Configuracin de los terminales de voz130
4.5.3 Revisin y Ajustes133
4.5.4 Conclusiones de la Prueba Piloto..134
4.6 Anlisis de resultados.....................................................................................................135
CAPTULO V: CONCLUSIONES Y RECOMENDACIONES ...........................................137
5.1 Conclusiones ..................................................................................................................137
5.2 Recomendaciones...........................................................................................................137
REFERENCIAS ......................................................................................................................139
NDICE DE TABLAS
Tablas
Pg.
1. 1 Equipamiento de Telefona de Servinave.............................................................................4

2. 1 Comparacin de Tcnicas de Conmutacin ......................................................................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 Clculo Consumo de Ancho de banda por CODEC.........................................................55
2. 6 Frmulas para Clculos 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 Lneas Contratadas ............................................................................................................73
4. 3 Distribucin de Telfonos 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 Caractersticas 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 Caractersticas Tcnicas de los Servidores......................................................................93
4. 22 Modelos de Telfonos Sugeridos ....................................................................................95
4. 23 Clculo de consumo Elctrico por Puesto de Trabajo.....................................................96
4. 24 Estimacin de Costos ......................................................................................................97
4. 25 Resumen dialplan Servinave, C.A...................................................................................99
4. 26 Parmetros TCP/IP a Configurar..................................................................................106
4. 27 Orden de Compilacin Paquete Asterisk......................................................................107
4. 28 /etc/asterisk/system.conf................................................................................................110
4. 29 Seccin General del Archivo Sip.conf ..........................................................................114
4. 30 Seccin de Clientes del Archivo Sip.conf .....................................................................115
4. 31 Extensiones y Grupos de Captura.................................................................................116
4. 32 Patrones de Marcado .....................................................................................................121
4. 33 Configuracin Hardphone .............................................................................................130
xii
NDICE DE FIGURAS
Figuras
Pg
2. 1 Jerarqua de nodos de conmutacin...................................................................................11

2. 2 Sealizacin de una llamada de voz ..................................................................................14
2. 3 Modelo de Referencia OSI ................................................................................................16
2. 4 Comparacin entre las arquitecturas OSI y TCP/IP ..........................................................18
2. 5 Proceso de conversin de una seal ..................................................................................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 redireccin....................................................................................................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 Interconexin de la Propuesta .....................................................................101
4. 4 Esquema de Interconexin 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 Verificacin 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 Configuracin del Audio en Zoiper...............................................................................132
4. 20 Seleccin de CODECS ..................................................................................................133
xiv
LISTA DE SMBOLOS Y ABREVIATURAS
ADSL Asymmetric Digital Subscriber Line ( Lnea de Suscripcin Digital Asimtrica).

ADPCM Adaptive Differential Pulse Code Modulation (Modulacin por Codificacin de
Impulsos Diferencial Adaptativa).
CCITT Consultative Committee for International Telegraph and
Telephone (Comit
Consultivo Internacional de Telefona y Telegrafa).

DiffServ Differentiated Services Internet QoS model (Modelo de Calidad de Servicio en
Internet basado en Servicios Diferenciados).
DHCP Dynamic Host Configuration Protocol (Protocolo Configuracin Dinmica de
Servidor).
DNS Domain Name System (Sistema de Nombres de Dominio).
DTMF Dual-Tone Multi-Frequency (Marcacin por Tonos multifrecuenciales).
E.164 Recomendacin de la ITU-T para la numeracin telefnica internacional.
FDM Frequency Division Multiplexing (Multiplexacin por Divisin de Frecuencia).
FTP File transfer Protocol (Protocolo de Transferencia de Archivos).
FXO Foreign Exchange Office (Oficina de Intercambio Extranjera).
FXS Foreign Exchange Station (Estacin de Intercambio Extranjera).
GNU Es un acrnimo recursivo que significa GNU is Not Unix (GNU No es Unix ).
GPL General Public License (Licencia Pblica General).
H.323 Estndar 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 Ingeniera de Internet).
IP Internet Protocol (Protocolo Internet).
IP-PBX Internet Protocol Private Branch Exchange (Central Telefnica Privada basada en
IP).
xv
IRQ Interrupt ReQuest ( Peticin de Interrupcin) .

ISP Internet Service Provider (Proveedor de Servicios Internet, PSI).
ITU-T International Telecommunications Union -Telecommunications (Unin 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 Opinin).
PBX Private Branch Exchange (Central Telefnica Privada).
PCI Peripheral Component Interconnect (Interconexin de Componentes Perifricos).
PCM Pulse Code Modulation (Modulacin por Impulsos Codificados).
POP3 Post Office Protocol (Protocolo de Oficina Postal).
POTS Plain Old Telephone Service (Servicio Telefnico Tradicional).
PSTN Public Switched Telephone Network (Red de Telefona Conmutada Pblica).
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 Descripcin de Sesin)
SIP Session Initiation Protocol (Protocolo de Inicio de Sesin)
SMTP Simple Mail Transfer Protocol (Protocolo Simple de Transferencia de Correo)
SS7 Signalling System Number 7 (Sistema de Sealizacin nmero 7).
TCP Transmission Control Protocol (Protocolo de Control de Transmisin).
TDM Time Division Multiplexing (Multiplexacin 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 tecnologas de Lneas de Suscripcin Digital (por ejemplo, ADSL).
INTRODUCCIN
Hoy en da es posible que una conversacin telefnica se pueda sostener entre dos puntos,
ocupando una porcin 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 compaas ms

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 transicin paulatina de los sistemas que ya conocen.
Internet simboliza, ms que cualquier otro fenmeno, 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 estn sintiendo las compaas prestadoras de servicio sobre el
rumbo que estn tomando el negocio de las comunicaciones, pues ya no parece necesario tener
una lnea telefnica y s una lnea de datos.
Gracias al crecimiento
de los
anchos de banda, la estandarizacin de protocolos
surgimiento de las aplicaciones fuente abierta, la VoIP est teniendo un gran auge. La
aparicin del protocolo SIP y Asterisk, as como el Sistema Operativo GNU/Linux han
permitido
consolidar aplicaciones de Telefona 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 captulos que mostraran cmo se dise una solucin de
Telefona IP para una empresa de servicios de agenciamiento navieros que busca modernizar
su plataforma telefnica. En el captulo I se proporciona una visin del problema que
enfrenta Servinave, los objetivos que se persiguen y que justifican el uso de la tecnologa de
VoIP. En el captulo II, se hace una exposicin de toda la base terica que soporta el diseo
realizado mediante la metodologa definida en el captulo III. La descripcin de cmo se llevo
a cabo este diseo, conjuntamente con el resultado de la prueba piloto, fue realizado en el
captulo IV. Para finalizar, se presentan las conclusiones obtenidas y algunas recomendaciones
necesarias que deben ser consideradas en la implementacin de la solucin.
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 geogrficamente 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 estn
completamente separadas, sin puntos comunes de conexin. Esta situacin ha llevado a la
contratacin de servicios de manera separada y a la necesidad de mantener procedimientos de
gestin y administracin igualmente separados.
El sistema de telefona que utiliza la empresa es el tradicional, inclusive para comunicarse

entre las sucursales. Todas las lneas suscritas son analgicas y son suministradas por un
nico proveedor: CANTV. LA contratacin de estos servicios es tramitada directamente por
cada oficina, y la gestin y administracin de stos es realizada por el rea administrativa y no
por el rea de tecnologa.
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 telefnicos, la mayora analgicos. La marca de stos varia
entre la marca del propietario de la central y marcas genricas. La marca de los digitales si
son de la marca propietaria de la central y estn destinados para los cargos de supervisor
nicamente. Por razones econmicas, no todos los puestos cuentan con aparatos telefnicos.
OFICINA
MARCA
MODELO
ESTATUS
(PROPIETARIO)
Caracas
Siemens
Hipath-3700/3750
Actualizada ao 2003
Puerto Cabello
Siemens
Hicom 160
Descontinuada
La Guaira
Siemens
EMS-80C
Descontinuada
Maracaibo
Siemens
Hipath 1190
Actualizada ao 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 Telefona de Servinave
Los servicios y facilidades con que cuentan las centrales telefnicas son mecanismos que van
a convertir la central telefnica en una herramienta mucho ms verstil. El inconveniente con
las centrales telefnicas propietarias es el hecho de que si se requiere de alguna de estas
facilidades, que no vienen incluidas en el licenciamiento de la solucin, 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 tcnica de las mismas, lo que obliga a pensar en
actualizar la plataforma de telefona de un momento a otro.

1.2 Justificacin
Cada da las empresas van demandando ms y mejores servicios de comunicacin,
independientemente de su tamao. El auge de Internet ha trado 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 tecnologa que permite la transmisin de la voz a travs de redes
IP en forma de paquetes de datos. La Telefona IP es una aplicacin inmediata de esta
tecnologa, de forma que permite la realizacin de llamadas telefnicas corrientes sobre redes
IP utilizando un PC, gateways y telfonos estndares.
La Telefona IP es una tendencia mundial, a tal punto que se estima que sustituya a la
telefona convencional en mediano plazo. Esta tendencia responde a que est basada en una
tecnologa en constante evolucin que est apoyada en estndares 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 telefona de Servinave, C.A. est obsoleta y aprovechar la tecnologa 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 tambin proveer de mejores servicios de comunicacin a las
sucursales, a un costo razonable y proporcional al tamao y rentabilidad de la misma.
La virtualidad de las lneas telefnicas IP hace que el riesgo de obsolescencia que sufren las
redes de telefona tradicional de una empresa por falta de funcionalidad o necesidad de
ampliacin de lneas o extensiones desaparezca. El acceso al servicio telefnico a travs de un
acceso a Internet, no slo reduce los costos de trfico sino que hace posible el uso de la lnea
personal desde cualquier punto en el que exista una conexin 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 Telefona IP, por ser una poltica de la Organizacin a la que pertenece Servinave,
C.A.; esta poltica sugiere a las empresas del grupo, evaluar Asterisk
para validar su
conveniencia antes de su implementacin. Entre las razones que respaldan este lineamiento
est el hecho de que Asterisk es la primera plataforma de Telefona IP de fuente abierta que
permite interoperar con todos los estndares de telefona del mercado, adems de contar con
una slida comunidad Open Source (fuente abierta) cuya capacidad de respuesta ante
problemas e implantacin de mejoras es bastante gil. Esta combinacin 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
Disear una solucin de telefona IP para la empresa Servinave, C.A., basada en el software
libre Asterisk, que cumpla con todas las funcionalidades de una central telefnica y aproveche
la tecnologa Voz sobre IP, con la finalidad de lograr una comunicacin prctica, sencilla y
rentable, manteniendo la calidad de servicio igual o superior a la acostumbrada.
1.3.2 Objetivo Especficos

1. Identificar las funcionalidades necesarias por cada sucursal/principal.
2. Diagnsticar de la situacin actual.
3. Clcular las capacidades y aprovisionar ancho de banda.
4. Dimensionar y seleccionar el hardware/software necesario.
5. Evaluar impacto y estimar costos.
CAPITULO II
MARCO TERICO
Este captulo proporciona definiciones, conceptos y trminos relevantes que fundamentan el
presente Trabajo Especial de Grado y que facilitar su comprensin.
2.1 Redes Conmutadas
Una red conmutada es un conjunto de nodos interconectados entre s, a travs de medios de

transmisin, donde la informacin se transfiere encaminndola del nodo de orgen al nodo
destino mediante conmutacin entre nodos intermedios. Se entiende por conmutacin en un
nodo, a la conexin fsica o lgica, de un camino de entrada al nodo con un camino de salida
del nodo, con el fin de transferir la informacin que llegue por el primer camino al segundo.
La conmutacin se divide en :
Conmutacin de paquetes.
Conmutacin de circuitos
2.1.1 Conmutacin de Circuitos
La conmutacin de circuitos implica que los equipos de conmutacin deben establecer un

camino fsico y dedicado entre los medios de comunicacin previo a la conexin entre los
usuarios. Este camino permanece activo durante la comunicacin entre los usuarios,
liberndose al terminar la comunicacin (Stallings, 2004).
Una comunicacin mediante circuitos conmutados posee tres etapas bien definidas:
1. Establecimiento del circuito: Cuando un usuario quiere obtener servicios de red para
establecer una comunicacin se deber establecer un circuito entre la estacin de origen y
la de destino. En esta etapa, dependiendo de la tecnologa 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
transmisin de datos. Dependiendo del tipo de redes y del tipo de servicio la transmisin
ser digital o analgica 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 terminacin de la sesin y la desconexin del circuito. Una vez liberado los
recursos utilizados por el circuito pueden ser usados por otra comunicacin.
En una red de conmutacin por circuitos, la capacidad del canal se reserva al establecer el
circuito y se mantiene durante el tiempo que dure la conexin, incluso si no se transmiten
datos. Es aqu donde radica su ineficiencia, aun cuando es altamente confiable.
2.1.2 Conmutacin de Paquetes

La tcnica de conmutacin de paquetes se diseo para ofrecer un servicio para el trfico de
datos ms eficiente que el proporcionado por la conmutacin de circuitos (Stallings, 2004).
En los sistemas basados en conmutacin de paquetes, la informacin/datos a ser transmitida

previamente es ensamblada en pequeos bloques llamados paquetes (datagramas). Si una
estacin tiene que enviar un mensaje de longitud superior a la del tamao mximo del paquete
permitido a travs de la red de conmutacin de paquetes, fragmenta el mensaje en paquetes y
lo enva uno a uno, hacia la red. La red tiene dos tcnicas de gestionar esta secuencia de
paquetes para encaminarlos en su seno y entregarlos al destino deseado: datagramas y
circuitos virtuales.
En la tcnica 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, segn su tabla de enrutamiento. Los paquetes que se
envan de esta manera pueden tomar diferentes rutas y se vuelven a montar una vez que llegan
al nodo receptor. La principal ventaja de esta tcnica es que permite el uso potencial de rutas
alternativas ante la eventual indisponibilidad de algunos nodos de conmutacin de la red,

adems de no precisar un establecimiento de llamada. Sin embargo, esta tcnica resulta poco
adecuada para el trfico de servicios interactivos (trfico sncrono en la que se precisa alta
velocidad).
En la tcnica de circuitos virtuales, se establece una conexin lgica antes de proceder a la

transmisin de datos. Una vez establecida sta, todos los paquetes intercambiados entre dos
partes comunicantes siguen dicho camino a travs de la red. Dado que el camino es fijo,
mientras dura la conexin lgica, es similar a un circuito en una red de conmutacin de
circuitos, por lo que se le llama circuito virtual. Adems de los datos, cada nodo contiene un
identificador del circuito virtual. En un instante de tiempo dado, cada estacin puede tener
ms de un circuito virtual hacia otra u otras estaciones. La principal caracterstica del mtodo
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 lnea de salida, mientras que otros
paquetes en otros circuitos pueden compartir el uso de la lnea.
La diferencia con el mtodo datagramas estriba en que cada nodo no necesita realizar una
decisin de encaminamiento para cada paquete, sino que se realiza una sola vez la decisin por
cada conexin. Otras diferencias se pueden apreciar en la tabla 2.1.
10
Caracterstica
CIRCUITOS
PAQUETES
PAQUETES
MEDIANTE
MEDIANTE
DATAGRAMAS
CIRCUITOS
VIRTUALES (C.V.)
No hay reserva de recursos
No
hay
reserva
de
recursos
No
hay
reserva
de
de
bits
recursos
Utilizacin de los
No existen bits suplementarios
Existencia
recursos de la red
en la transmisin una vez
suplementarios en cada
suplementarios en cada
(ancho de banda)
establecido el circuito
paquete
paquete (menos que en
de
bits
Existencia
datagramas) , adems de
los
mensajes
de
establecimiento y cierre
Complejidad de los
Conmutadores simples
nodos
Necesidad de memoria de
Necesidad de memoria
almacenamiento
de almacenamiento ms
numeros de C.V.
Latencia
Robustez
Adecuado
para
las
Poco adecuado para las
Poco adecuado para las
aplicaciones interactivas
La comunicacin finaliza
Se
La
buscan
rutas
alternativas
comunicacin
finaliza
Tabla 2. 1 Comparacin de Tcnicas de Conmutacin
2.2 Descripcin General de la Red Telefnica Convencional

Al sistema telefnico o a la red telefnica bsica (RTB) tambin se le denomina Public
Switched Telephone Network (PSTN) o Red de Telefona Pblica Conmutada (RTPC) .
La PSTN constituye la principal red de telecomunicaciones, permite que usuarios separados

geogrficamente puedan comunicarse de una manera sencilla, adems de permitir la
transmisin de datos. Est basada en conmutacin 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 telefnica es la de conmutacin, a

travs de centrales de conmutacin. La conmutacin surge como una solucin a la
imposibilidad de interconectar a todos los terminales entre s a travs de las lneas punto a
punto. Para ello se establece una jerarqua de nodos de conmutacin (centrales de
conmutacin) interconectados entre s (TRUNK o lneas troncales), de los que dependen las
conexiones de los terminales (ver figura 2.1).
Figura 2. 1 Jerarqua de nodos de conmutacin
El objetivo de una central de conmutacin es establecer el enlace entre dos abonados, uno
llamante otro llamado, que desean comunicarse; para ello debe disponer de los medios fsicos,
funciones y sealizacin 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 fsicamente
conecta el terminal de abonado a la central de conmutacin de la oficina central (tambin
conocido como CO, switch clase 5 o conmutador de punto final). La ruta de comunicacin
entre terminal de abonado y la central de conmutacin de la oficina central (CO) es conocida
como lnea telefnica del abonado.
12
Cada vez que el abonado utiliza la lnea telefnica se intercambian un conjunto de seales con
la CO. Estas seales se transmiten haciendo uso de un protocolo conocido como Sealizacin.
Para la transmisin por medio de la red se utilizan diferentes tipos de modulacin y
multilplexado. La informacin 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 modulacin de la voz se hace mediante portadoras de 64 Khz y la misma
puede ser analgica digital.
En un principio, la red de telefona fue creada para transmitir la voz humana. Tanto por la
naturaleza de la informacin a transmitir, como por la tecnologa disponible para la poca, fue
creada de tipo analgico. Hoy en da, la voz solo viaja en forma analgica desde el telfono
del usuario a la central (el denominado bucle de abonado). All es digitalizada y viaja en
forma binaria por el sistema telefnico hasta la central del otro abonado, donde es vuelta a
convertir en seal analgica antes de enviarla al telfono del otro abonado. El proceso de
comunicacin entre centrales totalmente digital se basa en el protocolo SS7 (sistema de
sealizacin 7).
2.2.1 Sealizacin
En el contexto telefnico,
la sealizacin
constituye el intercambio de informacin
relacionada con el establecimiento y control de las conexiones y con su gestin en una red de
telecomunicaciones (Stallings, 2004).
Es necesario considerar la sealizacin en dos contextos, ya que generalmente funciona

diferente:
La sealizacin entre el abonado y la red.
La sealizacin dentro de la red (entre centrales).
13
2.2.1.1 Sealizacin Abonado a Red

Se refiere al conjunto de seales que intercambian el terminal telefnico y la central local, a
travs 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 alimentacin elctrica, sealizacin de llamada (ring) y tono al
dispositivo terminal. Estas interfaces son las que permiten conectar un telfono analgico
convencional a un router o central de telefona IP.
Una interfaz FXO es la interfaz que permite conectar un dispositivo terminal a un servicio de
telefona como el servicio de telefona pblica (PSTN) o una PBX. Enva al sistema telefnio
una seal 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 lnea a una interfaz FXO.
Los mtodos de sealizacin utilizados por las interfaces FXS/FXO son los siguientes:
GroundStart (gs): En este tipo de sealizacin el tono se solicita conectando a una

toma de tierra uno de los polos. No es muy utilizado actualmente.
LoopStart (ls): Permite que un telfono indique el colgado/descolgado, y que el punto

terminal indique el ring/no ring. Es el mtodo ms utilizado. La diferencia entre ls y gs
radica en la manera en la que el telfono requiere tono de marcado a la CO.
GroundStart requiere tono de marcado aterrizando uno de los conductores de la lnea
telefnica mientras que ls
lo hace realizando un corto circuito entre ambos
conductores (es decir creando un lazo o loop).
KewlStart (ks): La sealizacin Kewlstart est basada en loopstart, pero ampla el

protocolo permitiendo al punto terminal invertir la polaridad de la lnea telefnica para
indicar al telfono 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 telfono (el dispositivo FXO).
El puerto FXS (CO) detecta que ha descolgado el telfono enva tono de invitacin a
marcar.
Abonado marca el nmero de telfono 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
enva un voltaje de llamada al dispositivo FXO adjunto . Si esta ocupado o no puede
establecerse la comunicacin, el puerto FXS igualmente envia realimentacin al
abonado llamante con los tonos correspondientes.
La conexin se libera cuando una de las dos partes cuelga.
Figura 2. 2 Sealizacin de una llamada de voz
15
2.2.1.2. Sealizacin entre Centrales

Es el conjunto de seales que intercambian las centrales telefnicas. Existen dos modos
diferentes de enviar la sealizacin:
Canal Aasociado: La sealizacin se transmite por los mismos canales que las seales
de voz. Cada canal de voz tiene asociado su canal de sealizacin. Ejemplo el
protocolo E&M (recEive & transMit o Ear & Mouth).
Canal Comn: La sealizacin se transmite por un canal diferente al empleado por las
seales de usuario. Constituye una red independiente y especializada de sealizacin.
Ejemplo Sistema de Sealizacin Nmero 7 (SS7).
El Sistema de Sealizacin Nmero 7 (SS7) es un estndar global para las telecomunicaciones

definidas por la ITU-T. El estndar define el protocolo y los procedimientos mediante los
cuales los elementos de la red de telefona conmutada pblica (PSTN) intercambian
informacin sobre una red digital para efectuar el enrutamiento, establecimiento y control de
llamadas.
2.3 Redes IP
Las normas que gobiernan la operacin de unidades funcionales para llevar acabo la
comunicacin se les llama Protocolos (Stallings, 2004). Cuando se precisa describir la
estructura y funcin 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 funcin realizada
cuando los datos son transferidos entre aplicaciones cooperativas a travs de una red
intermedia. En una capa no se define un nico protocolo sino una funcin de comunicacin 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 comunicacin con su
gemelo, sin preocuparse de las capas superior o inferior. Sin embargo, tambin debe haber
16
acuerdo en cmo pasan los datos de capa en capa dentro de un mismo sistema, pues cada capa
est implicada en el envo de datos.
Figura 2. 3 Modelo de Referencia OSI
El modelo OSI es utilizado como marco de referencia terico para describir la funcionalidad
de los dispositivos y protocolos que hacen funcionar una red, sin embargo, en la prctica,
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 heterogneos 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 representacin, ruta y envo. IP
es un protocolo no
orientado a conexin usado tanto por el orgen como por el destino para la comunicacin de
datos a travs de una red de paquetes conmutados.
17
TCP se dise especficamente para proporcionar un flujo de bytes confiable a travs de una
red no confiable. El protocolo IP no ofrece ninguna garanta de que los datagramas se
entregarn adecuadamente, por lo que es responsabilidad del TCP terminar de temporizar y
retransmitirlos, segn se necesite. Los datagramas que s llegan pueden hacerlo
desordenadamente; tambin 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 ms utilizado para el nivel de transporte en Internet,
pero adems de ste existen otros protocolos que pueden ser ms 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 conexin. Muchas aplicaciones cliente-servidor que
tienen una solicitud y una respuesta usan UDP en lugar de establecer y luego liberar una
conexin.
A diferencia del modelo OSI, TCP/IP est constituido por las cinco capas siguientes (ver
figura 2.4 ):
1. Capa de Aplicacin: Proporciona comunicacin 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 travs 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 Fsica: Define las caractersticas del medio, sealizacin y codificacin de
las seales.
18
Figura 2. 4 Comparacin entre las arquitecturas OSI y TCP/IP
2.4 Voz Sobre IP (VoIP)

En general, Voz sobre IP, tambin llamada VozIP, VoIP o Voz sobre Protocolo de Internet, es
una tecnologa que permite transmitir en tiempo real, seales de voz travs de redes de datos
empleando el protocolo IP. Esto significa que, aprovechando la infraestructura desplegada
para la transmisin de datos, se enva la seal de voz digitalizada en paquetes, en lugar de
enviarla a travs de circuitos utilizables slo para telefona (como una compaa telefnica
convencional o PSTN).
En una llamada telefnica tradicional, la central telefnica establece una conexin permanente
entre los interlocutores, para transmitir las seales de voz. En una llamada telefnica por IP,
los paquetes de datos, que contienen la seal de voz digitalizada y comprimida, se envan a
travs de la red IP (Internet/Intranet) a la direccin IP del destinatario. Cuando stos llegan a
su destino son ordenados y convertidos de nuevo en seal de voz .
La VoIP hace uso de los CODECs para que la voz pueda ser digitalizada y comprimida.
19
2.5 Telefona IP
Muchas veces los trminos de VoIP y Telefona IP son referenciados como un mismo
concepto, pues aun no existe una definicin oficial que los distinga, quedando a juicio de los
investigadores su interpretacin.
La definicin genrica de Telefona IP,
adoptada por la Unin Internacional de
Telecomunicaciones (UIT) en el Foro Mundial de Polticas de las Telecomunicaciones (FMPT

2001) - Telefona IP,
comprende la prestacin de servicios vocales a travs de redes basadas
en IP, ya sea en forma total o en combinacin con redes pblicas conmutadas tradicionales.
Para propsitos de esta tesis, ambos trminos VoIP y Telefona IP, sern referenciados
indistintamente como VoIP, ya que ambos permiten la realizacin de llamadas telefnicas
ordinarias sobre redes IP u otras redes de paquetes utilizando un PC, un telfono IP, gateways
y/o telfonos estndares.
2.6 CODEC
La seal de voz es una seal analgica, es decir, continua tanto en el tiempo como en
amplitud. Este tipo de seales deben ser convertidas para poder transmitirse por sistemas
digitales (redes IP). Los algoritmos que permiten convertir seales analgicas a digitales se
conocen como CODEC (codificador-decodificador).
Adems de la ejecucin de la conversin de analgico a digital, los CODECs comprimen la

secuencia de datos, lo que permite reducir el caudal de bits necesario para transmitir una
determinada informacin, logrando con ello optimizar el uso del ancho de banda.
Cualquier tcnica de compresin por lo regular introduce una cierta prdida de calidad
respecto al audio no comprimido, aunque en algunos casos dicha prdida es difcil de percibir.
En general, a mayor compresin menor calidad.
La ITU-T normaliza los esquemas de
codificacin 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
travs de la red IP hasta su nodo destino; el nodo destino debe utilizar los mismos estndares,
as como parmetros comunes, para poder realizar el proceso inverso, pues si no, el resultado
es una comunicacin inteligible.
2.6.1 Funcionamiento del CODEC

El proceso de conversin de la seal analgica a digital se realiza llevando a cabo los
siguientes pasos (ver figura 2.5):
Muestreo (sampling)
Cuantificacin (quantization)
Codificacin (codification)
Figura 2. 5 Proceso de conversin de una seal
2.6.1.1 Muestreo
El proceso de muestreo consiste en tomar valores instantneos (muestras) de una seal
analgica, a intervalos de tiempo iguales. El muestreo se efecta siempre a un ritmo uniforme,
que viene dado por la frecuencia de muestreo o sampling rate.
Segn el teorema de Nyquist-Shannon, la cantidad de veces que se debe medir una seal para
no perder informacin debe ser al menos el doble de la frecuencia mxima que alcanza dicha
seal. Partiendo de que las seales telefnicas 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 mxima -). En la prctica, 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 separacin entre muestras de:
T=1/8000= 0,000125 seg. = 125 s
Por lo tanto, dos muestras consecutivas de una misma seal estn separadas 125 s que es el
periodo de muestreo.
2.6.1.2 Cuantificacin
La cuantificacin 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 Codificacin
La codificacin es el proceso mediante el cual se representa una muestra cuantificada en un
grupo equivalente de pulsos binarios de amplitud constante, es decir, una sucesin de "1's" y
"0's".
2.6.2 Tipos de CODEC
Tradicionalmente, en entornos telefnicos se ha venido utilizando la modulacin por
codificacin 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 codificacin 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 carctersticas de algunos de los CODECs comnmente usados en VoIP, se resumen a

continuacin.
22
2.6.2.1 ITU-T G.711

El G.711, Tambin es conocido como seal digital de nivel 0 (DS0) o Modulacin de Pulsos
Codificados (PCM), no usa ninguna compresin y es el mismo codec utilizado por la PSTN.
Tiene la menor latencia (no hay necesidad de compresin), lo cual se traduce como menor
procesamiento o menor consumo de CPU. Este codec tiene dos versiones conocidas como
ulaw, usado en USA y Japn, correspondiente al estndar T1 y alaw, usado en Europa y el
resto de los pases, correspondiente al estndar 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 compresin pero hace uso intenso de la CPU para lograrlo.
2.6.2.3 ITU-T G.726
Es un codec basado en tecnologa 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 telefona. Tambin es el Codec
estndar usado en telfonos inalmbricos DECT. Reemplaza a los codecs G.721 y G.723.
2.6.2.4 ITU-T G.729
La ventaja en la utilizacin de G.729 radica principalmente en su alta compresin y por ende
bajo consumo de ancho de banda lo que lo hace atractivo para comunicaciones por Internet.
Pese a su alta compresin no deteriora la calidad de voz significativamente, sin embargo,
msica 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 mtodos fuera de esta banda para
23
transportar las mismas seales. 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 simplificacin de G729 y es compatible con G729. Es

menos complejo pero tiene algo menos de calidad.
G729B o anexo B: Es G729 pero con supresin de silencios y no es compatible con las
anteriores.
G729AB: Es G729A con supresin de silencios y sera 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 conexin o se retrazan los paquetes. Usa una codificacin de prediccin-lineal y
bloques-independientes (LPC). Se permite usar iLBC sin pagar licencia, sin embargo, el
dueo de la patente de iLBC, Global IP Sound (GIPS), quiere saber siempre cuando se lo usa
en una aplicacin comercial. La forma de hacer esto es descargando e imprimiendo una copia
de la licencia de iLBC, firmando y devolvindolo.
2.6.2.6 GSM
GSM (Global System for Mobile communications) es un sistema de telefona celular popular
fuera de los Estados Unidos. GSM incluye un codec y usualmente se refiere como GSM
cuando se discuten codecs. La velocidad mxima del codec de voz GSM se llama RPE-LTP
(Regular Pulse Excitation Long-Term Prediction). Este codec usa la informacin de muestras
anteriores (esta informacin no cambia rpidamente) para poder predecir la muestra actual. La
seal 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 cdec 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 Fundacin Xiph.org. Las metas en el diseo eran permitir buena calidad en la voz y
bajo bit-rate (desafortunadamente no al mismo tiempo). Buena calidad tambin significaba
tener soporte para wideband (frecuencia de muestreo de 16 kHz) adems de narrowband
(calidad de telfono, frecuencia de muestreo de 8 kHz). Speex es un Codec Variable BitRate
(VBR), lo que significa que es capaz de dinmicamente 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 Parmetros de los CODEC

Cada codec cuenta con una cantidad de parmetros que lo caracterizan o describen y a la vez
hacen posible la estimacin del ancho de banda de las comunicaciones de voz sobre la red IP.
Estos parmetros son:
Frecuencia de muestreo Sampling Rate (fs): Nmero de muestras tomadas de la

seal de voz en la unidad de tiempo de un segundo (tpico: 8khz).
Tamao de la trama - Frame Size (Tt): Indica cada cuantos milisegundos se enva un
paquete con la informacin sonora. El procesamiento de la seal de voz se hace por
intervalos de duracin predefinidos.
Tasa de bits - Bits Rate: Define el nmero 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 seal de audio y poder lograr una compresin mayor.
Se expresa en ms.
Mean Opinion Score (MOS): Es una referencia subjetiva comn para cuantificar el
rendimiento de un codec de voz. Un MOS de 5 indica una comunicacin de calidad
excelente, mientras que un MOS de 0 indica psima calidad.
25
Complejidad: Es una medida de la cantidad de CPU necesaria para procesar el

algoritmo de codificacin, y por tanto, del nmero de canales de voz que puede
soportar un mismo DSP (digital signal procesor) . La compresin tiene un tiempo de
procesamiento que depender del procesador utilizado y de la complejidad del
algoritmo del codec. Un
parmetro de medicin 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 seal.
Packet Loss Concealment (PLC): Es un algoritmo que permite recuperacin de

paquetes. Segn la complejidad del algoritmo de recuperacin de paquetes, este
puede reproducir el ltimo sonido o calcular cul sera el sonido correspondiente al
paquete perdido.
2.7 Factores que Afectan la Calidad de la Voz

Como ya se ha mencionado, la tecnologa de conmutacin 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 informacin. En la conmutacin de paquetes, por el contrario, slo
se ocupa el canal cuando se transmite informacin, aprovechando al mximo el ancho de
banda.
En las redes de datos el retardo, la alteracin del orden de llegada o la prdida de paquetes no
son un inconveniente, ya que el sistema final
tiene una serie de procedimientos de
recuperacin de la informacin original; pero para la transmisin 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 ingls Quality of Service).
La calidad de servicio (QoS) es definida por la Unin Internacional de Telecomunicaciones

(ITU-T), en la Recomendacin ITU-T E.800, como el efecto colectivo del funcionamiento del
servicio, el cual determina el grado de satisfaccin del usuario del mismo. Dicho grado de
26
satisfaccin est relacionado con la percepcin del usuario sobre aspectos objetivos y
subjetivos de la prestacin del mismo.
En otras palabras, se podra decir que QoS es un conjunto de parmetros de performance que
aseguran al usuario de un servicio niveles aceptables de calidad. Como distintos tipos de
servicio mantienen caractersticas particulares, cada uno tendra su propia QoS.
Los servicios en tiempo real como la voz y el video, necesitan tiempos de espera predecibles
para evitar el fenmeno de saltos en imagen o interrupciones de sonido. En este sentido, los
principales parmetros que afectan la QoS de estos servicios son:
Latencia / Delay (Retraso).
Jitter
Prdida 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 odo de la persona que escucha. La
recomendacin ITU-T G.114 sugiere 150 ms como mximo 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 seal

analgica de audio a una seal de audio digitalizada con una representacin
comprimida.
Retraso de Paquetizacin: Es el tiempo que se requiere para formar un paquete de

voz a partir de la representacin 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 Serializacin: 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
transmisin .
Retraso de Propagacin: Es el tiempo requerido por la seal ptica o elctrica para

viajar a travs a lo largo de un medio de transmisin y es una funcin de la distancia
geogrfica.
Buffer de Reproduccin: Cuando un paquete, celda o trama llega al router destino, las
cabeceras de los protocolos son retiradas (despaquetizacin) y las muestras son
almacenadas en el buffer de reproduccin. 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 nmero de
muestras que estn en el buffer en ese momento.
Figura 2. 6 Fuentes de retraso en la red
2.7.2 Jitter
El jitter se define tcnicamente como la variacin en el tiempo de llegada de los paquetes,
causada por congestin de red, perdida de sincronizacin o por las diferentes rutas seguidas
por los paquetes para llegar al destino. Es decir, es la variacin 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 debera
ser casi igual a la diferencia entre los paquetes en el transmisor y el estndar de desviacin
debera 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 fcil flujo de paquetes en la recepcin.
2.7.3 Prdida de Paquetes
Trmino utilizado para indicar la prdida de paquetes durante una transmisin sobre una red
IP. Puede suceder debido a una alta latencia en la red o por congestin en los router o switches
incapaces de procesar la informacin.
Los umbrales indicados en las recomendaciones de la
ITU-T P.800, P.830, P.862.1, se
resumen en la tabla 2.2:
EXCELENTE
BUENO
ACEPTABLE
POBRE
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
CLASIFICACIN
CALIDAD VOIP
Tabla 2. 2 Indicadores de QoS para VoIP
2.7.4 Eco
El eco se define como una reflexin retardada de la seal acstica 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 tcnicas
de cancelacin de eco.
En este caso hay dos posibles soluciones para evitar este efecto:
29
Supresores de eco: Consiste en evitar que la seal emitida sea devuelta convirtiendo
por momentos la lnea full-duplex en una lnea half-duplex de tal manera que si se
detecta comunicacin en un sentido se impide la comunicacin en sentido contrario. El
tiempo de conmutacin de los supresores de eco es muy pequeo. Impide una
comunicacin full-duplex plena.
Canceladores de eco: Es el sistema por el cual el dispostivo emisor guarda la

informacin que enva en memoria y es capaz de detectar en la seal de vuelta la
misma informacin (tal vez atenuada y con ruido). El dispositivo filtra esa informacin
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
mtodos de medida y lmites en los niveles y retardos de eco que se deberan seguir con
criterio de cumplimiento mnimo.
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 estn clasificados en tres grupos, segn la
funcin que realicen dentro de las fases de establecimiento de la llamada, a saber: (Huidobro y
Roldan, 2006):
Protocolo Sealizacin: El objetivo es establecer un canal de comunicaciones a travs

del cual fluya la informacion de usuario y liberar el canal cuando finalice la
comunicacin. Para ello debe existir un dilogo entre los componentes de red y entre
la red y los terminales de usuario. Algunos de los protocolos de sealizacion son
H.323, SIP, IAX, entre otros.
Protocolo de Transporte: Son las normas que definen cmo debe realizarse La
comunicacin entre los extremos por un canal de comunicaciones previamente
establecido. Los protocolos de transporte mas empleados son RTP-RTCP y RTSP.
30
Protocolos de Gestin: Permiten conocer el grado de utilizacin de la infraestructura

tecnolgica. Esta informacin es til para el mantenimiento o aplicacin de medidas
oportunas que garanticen el correcto funcionamiento de la red, asi como facilitar la
planificacin de ampliaciones o restructuraciones.
2.8.1 Protocolo de Sealizacin H.323

H.323 es un conjunto de especificaciones de la ITU-T para transmitir audio, video y datos a
travs de una red IP. Consta de los siguientes protocolos (ver figura 2.7):
Sealizacin de las llamadas: H.225
Control de la comunicacin 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
Tambin 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,

mensajera, intercambio de capacidades y comandos de sealizacin.
Transmisin de Medios: Formatea el audio, video, datos, flujos y mensajes

transmitidos hacia y recibidos desde la interfaz de red.
Codec de Audio: Codifica la seal de audio para su transmisin y decodifica el cdigo

de audio entrante.
Codec de Video: Opcional, si est implementado debe cumplir con el estndar 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 audiogrficas (estndar 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
bsicas son la traduccin de protocolos de establecimiento y liberacin de llamadas y la
conversin de formatos de la informacin 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:
Conversin de la sealizacin de la llamada
Conversin de la sealizacin de medios
Conversin de medios
2.8.1.1.3 Gatekeeper
Proporciona el servicio de admisin y traduccin de direcciones para terminales o gateways.

Aqu se efectan las tareas de direccionamiento, autenticacin tanto de terminales como
gateways, gestin de ancho de banda y contabilidad. Pueden tambin proveer servicios de
encaminamiento de llamadas.
2.8.1.1.4 Las Unidades de Control Multipunto (MCU)
Son dispositivos que permiten que dos o ms 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, admisin y estado) con los mensajes ARQ y ACF.
Posteriormente utilizando el protocolo H.225 (que se utiliza para establecimiento y

liberacin 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 direccin IP, puerto y
alias del llamante o la direccin 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 generacin de tono.
Por ltimo, CONNECT indica el comienzo de la conexin.
2.8.1.2.2 Sealizacin de Control
En esta fase se abre una negociacin mediante el protocolo H.245 (control de

conferencia), el intercambio de los mensajes (peticin y respuesta) entre los dos
terminales establecen quin ser master y quin slave, las capacidades de los
participantes y CODECs de audio y video a utilizar. Como punto final de esta
negociacin se abre el canal de comunicacin (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 lgico de informacin
que contiene informacin para permitir la recepcin y codificacin de los datos.
Contiene la informacin del tipo de datos que ser transportados.
35
2.8.1.2.3 Audio
Los terminales inician la comunicacin y el intercambio de audio (o video) mediante el

protocolo RTP/RTCP.
2.8.1.2.4 Desconexin
En esta fase cualquiera de los participantes activos en la comunicacin puede iniciar el

proceso de finalizacin de llamada mediante mensajes CloseLogicalChannel y
EndSessionComand de H.245.
Posteriormente, utilizando H.225 se cierra la conexin con el mensaje RELEASE

COMPLETE.
Por ltimo se liberan los registros con el gatekeeper utilizando mensajes del protocolo
RAS.
2.8.2
Protocolo de Sealizacin de Inicio de Sesin SIP
El protocolo SIP (Session Initiation Protocol) fue desarrollado por el grupo MMUSIC
(Multimedia Session Control) del IETF, definiendo una arquitectura de sealizacin y control
para VoIP. Inicialmente fue publicado en febrero del 1996 en la RFC 2543, ahora obsoleta con
la publicacin de la nueva versin RFC 3261 que se public en junio del 2002.
De acuerdo al RFC 3261, SIP es definido como Un protocolo de control de sealizacin de

la capa de aplicacin
que se utiliza para establecer, mantener y terminar sesiones
multimedia. Las sesiones multimedia incluyen la telefona 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 envo de mensajes, de peticin y respuesta, similares en su sintaxis y semntica a
los definidos en el estndar 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 conexin 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 trfico de video
y voz solamente; puede ser cualquier otro tipo de sesin 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 Sealizacin (UDP 5060) Establecimiento, negociacin y finalizacin de la

sesin.
Canal de stream RTP (UDP 10000-20000 normalmente) y control RTCP.
Figura 2. 10 SIP y RTP Viajan por Caminos Diferentes
SIP Trabaja en sintona 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 estndar no
limita SIP a usar solo UDP; puede tambin usar TCP).
Utiliza un protocolo llamado SDP (Session Description Protocol) en el proceso de

establecimiento de sesiones, que le permite administrar la descripcin de medios y
negociacin de CODECS, adems de conocer cules puertos IP se usan para la
transmisin 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 caractersticas ms 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 integracin con otras aplicaciones.
Eficiencia: SIP es muy eficaz en trminos de tiempo de conexin de la llamada ya que

toda la informacin 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 informacin del estado de las sesiones

UDP, con lo cul 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. Localizacin del usuario: Determinacin de los sistemas finales a ser usados para la
comunicacin.
2. Disponibilidad del usuario: Determinacin de la voluntad del receptor de la llamada de
participar en las comunicaciones.
3. Capacidad del usuario: Determinacin del medio y sus parmetros.
4. Establecimiento de la sesin: repique, negociacin de parmetros entre los
participantes de una sesin.
5. Gestin de la sesin: Transferencia, terminacin de sesiones y modificacin de los
parmetros de la sesin 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 caractersticas de
la sesin se llaman UA (User Agent - Agentes de Usuario). Los agentes de usuario
generalmente, residen en la computadora del usuario en forma de una aplicacin (tambin
pueden ser agentes de usuario los telfonos 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 lgicas y cada agente de usuario contiene un UAC y UAS.
UAC es la parte del agente de usuario que enva los pedidos y recibe respuestas. UAS es la
parte del agente de usuario que recibe los pedidos y enva 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 situacin. Por ejemplo, un agente de usuario
que realiza una llamada, se comporta como UAC cuando enva 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 enva las respuestas. Pero esta situacin cambia cuando la
parte llamada decide enviar un mensaje BYE para terminar la sesin. 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 conversacin, como es el caso de los centros de
comunicaciones y de los sistemas de llamadas prepagadas.
Un B2BUA es una entidad lgica que recibe una solicitud, la procesa como si fuese un
Servidor Agente de Usuario (UAS) y, para determinar cmo contestar al mensaje de solicitud,
acta 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 fsicamente en una nica
mquina; la divisin de stos puede ser por motivos de escalabilidad y rendimiento:
1) Servidores Proxy (Proxy Server): Es una entidad intermedia que acta como cliente y
servidor con el propsito 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 divisin de una peticin en varias (forking), con la finalidad de
la localizacin 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 reenvan 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 informacin de estas peticiones para suministrar un servicio de
localizacin y traduccin 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 polticas de acceso y seguridad con contraseas. Tambin se les
denomina servidores de localizacin (Location Server LS), pues son utilizados por los
servidores proxy y de redireccin para obtener informacin respecto a la localizacin 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 Redireccin: Es un servidor que genera respuestas de redireccin a las

peticiones que recibe y devuelve a los Agentes de Usuarios la direccin 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 redireccin
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
nmero telefnico 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 mquina.
usuario@direccin_ip, donde direccin_ip es la direccin IP del dispositivo.
nmero_telfono@gateway, donde el gateway permite acceder al nmero de telfono a

travs de la red telefnica pblica.
2.8.2.3 Mensajes
Los componentes SIP se comunican entre s mediante una serie de mensajes, los cuales son
solicitudes (mtodos) y las respuestas (cdigos de estado) (verfigura 2.15).
Figura 2. 15 Solicitudes y respuestas SIP
La estructura genrica de un mensaje SIP, sea de peticin o respuesta, es la siguiente:
Start Line: Una lnea de comienzo, que depende si el mensaje es de solicitud o de

Respuesta.
43
Headers: Una o ms cabeceras.
Empty Line : una lnea vaca que indica el fin de las cabeceras (CRLF).
Message Body: El cuerpo del mensaje (opcional).
2.8.2.3.1 Mtodos SIP (Solicitudes)
Las solicitudes SIP son caracterizadas por la lnea inicial del mensaje, llamada Request-Line,
que contiene el nombre del mtodo, el identificador del destinatario de la peticin (RequestURI) y la versin del protocolo SIP. Existen seis mtodos bsicos SIP que describen las
peticiones de los clientes:
1) INVITE: Permite invitar un usuario o servicio para participar en una sesin o para
modificar parmetros en una sesin ya existente.
2) ACK: Confirma el establecimiento de una sesin.
3) OPTION: Solicita informacin sobre las capacidades de un servidor.
4) BYE: Indica la terminacin de una sesin.
5) CANCEL: Cancela una peticin pendiente.
6) REGISTER: Registrar al User Agent.
Sin embargo, existen otros mtodos adicionales que pueden ser utilizados, ubicados en otros
RFCs como los mtodos INFO, SUBSCRIBER,entre otros.
La lnea de solicitud tiene la estructura siguiente:
Method SP Request-URI SP SIP-Version CRLF
Donde SP es el carcter espacio y CRLF es la secuencia retorno del carro y nueva lnea (ver
tabla 2.3) .
44
INVITE sip:bob@sip.com SIP/2

Mtodo
INVITE
Request-URI
bob@sip.com
Version SIP
SIP/2.0
Tabla 2. 3 Ejemplo de una Solicitud SIP
2.8.2.3.2 Cdigos de Estado SIP (Respuestas)
Los cdigos de estado se deviden en los siguientes grupos:
1xx Informacin: La solicitud ha sido recibida y se esta procesando.
2xx xito: La accin ha sido recibida con xito y aceptada.
3xx Redireccin: 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

vlida.
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 carcter espacio y CRLF es la secuencia retorno del carro y nueva lnea (ver
tabla 2.4)
SIP-Version: Es la versin del Protocolo SIP utilizado
Status-Code: Entero de tres dgitos que indica el resultado del intento de servir la
peticin.
45
Reason-Phrase: Explicacin 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 informacin necesaria a las entidades SIP;
especifican informacin 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 continuacin, se
detallan los campos:
Via: Indica el transporte usado para el envo e identifica la ruta del request, por ello
cada proxy aade una lnea a este campo.
From: Indica la direccin del origen de la peticin.
To: Indica la direccin del destinatario de la peticin.
Call-Id: Identificador nico para cada llamada y contiene la direccin del host. Debe
ser igual para todos los mensajes dentro de una transaccin.
Cseq: Se inicia con un nmero aleatorio e identifica de forma secuencial cada peticin.
Contact: Contiene una (o ms) direccin que pueden ser usada para contactar con el
usuario.
User Agent: Contiene el cliente agente que realiza la comunicacin.
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 descripcin de sesin con SDP, pero puede ser cualquier
otro contenido, en texto plano o cifrado.
SDP es el acrnimo de Session Description Protocol (Protocolo de descripcin de sesin) y

est definido en el RFC 4566 como un formato para definir parmetros de inicializacin de
flujos de medios.
SDP es exclusivamente para propsitos de descripcin y negociacin de los parmetros de la

sesin. No transporta medio en s. El transporte de informacin acerca de los flujos de medios
permite a los destinatarios participar en la sesin si ellos soportan dichos flujos.
De forma general, la informacin que SDP incluye en sus paquetes es la siguiente:
La versin del protocolo
El nombre de la sesin y su propsito
El tiempo que la sesin esta activa
Los medios relacionados con la sesin (video, audio, formatos para audio o video,
entre otras).
Las direcciones IP y los puertos para el establecimiento de la sesin
Los atributos especficos a la sesin 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 transaccin 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 transaccin
esta el parmetro 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 envan una peticin REGISTER, donde los campos from y to corresponden
al usuario registrado. El servidor Proxy, que acta como Register, consulta si el usuario
puede ser autenticado y enva un mensaje de OK en caso positivo.
La siguiente transaccin corresponde a un establecimiento de sesin. Esta sesin

consiste en una peticin INVITE del usuario al proxy. Inmediatamente, el proxy enva
48
un TRYING 100 para parar las retransmisiones y reenva la peticin al usuario B. El

usuario B enva un Ringing 180 cuando el telfono empieza a sonar y tambin 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 parmetros (puertos, direcciones, codecs, etc.) establecidos en
la negociacin mediante el protocolo SDP.
La ltima transaccin corresponde a una finalizacin de sesin. Esta finalizacin se

lleva a cabo con una nica peticin 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 Sealizacin 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 estndar abierto que, aunque originalmente fue
diseado para comunicacin entre centrales Asterisk (de aqu deriva su nombre), soporta
muchos otros proyectos de comunicacin fuente abierta, as como distintos proveedores de
hardware.
El protocolo IAX se refiere generalmente al IAX2, la segunda versin del protocolo IAX. El
protocolo original ha quedado obsoleto en favor de esta versin. En tal sentido, se emplea IAX
o IAX2 indistintamente para referirse siempre a sta ultima versin.
De acuerdo a Goncalvez (2007), los objetivos de diseo 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 transmisin de datos multimedia, resumiendo como los objetivos
de diseo 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 sealizacin par-a-par (peer to peer o P2P) que implementa
codificacin binaria, en lugar de una codificacin basada en Texto/ASCII como en SIP, lo
cual contribuye a la rapidez de procesamiento de los mensajes/paquetes en el protocolo y
adems hace que el protocolo consuma marginalmente un menor ancho de banda.
IAX usa slo un par de flujos donde voz y datos coexisten (utiliza solamente el puerto 4569
para transmitir tanto la sealizacin como los datos). Esta forma de enviar tanto las
conversaciones como la sealizacin por el mismo canal se conoce como inband, en contraste
con el mtodo que usa SIP, el outofband. La idea de enviar la sealizacin dentro del canal de
voz (inband) obliga a separar los paquetes de voz de los paquetes de sealizacin. Aunque este
diseo requiere ms gasto de procesamiento (CPU) ofrece mejores propiedades en presencia
de cortafuegos y NAT.
Otra caracterstica de IAX es que soporta TRUKING; es decir, un solo enlace puede enviar
datos y sealizacin de varios canales. Cuando se hace TRUKING, un solo paquete IP puede
contener informacin de varias llamadas lo cual supone un importante ahorro de ancho de
banda, ya que hay una disminucin 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 envan 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 explcitamente. 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 explcitamente.
B) Tramas M o Mini Frames
Las tramas M o mini frames para mandar la informacin con la menor informacin 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 travs del
protocolo IAX:
Figura 2. 17 Proceso de una llamada IAX
51
Establecimiento de la llamada: El terminal A o terminal llamante
inicia una
conexin y manda un mensaje "NEW". El terminal B o terminal llamado

responde/confirma la peticin con un "ACCEPT" y el llamante le responde con un
"ACK", reconfirmando. A continuacin el terminal llamado da las seales de
"RINGING" y el llamante contesta con un "ACK" para confirmar la recepcin 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 envan las tramas M y F en ambos sentidos con la
informacin 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 informacin de sincronizacin. Es importante volver a resaltar que en
IAX este flujo utiliza el mismo protocolo UDP que usan los mensajes de sealizacin
evitando problemas de NAT.
Liberacin de la llamada o desconexin. Cualquiera de los involucrados, llamante o

llamado, puede terminar la llamada enviando una trama HANGUP y esperando una
trama de confirmacin 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 ms alta el control de la transmisin. En Internet, esta funcin es ejecutada por el
protocolo de control de transmisin (TCP), que es un protocolo fiable que corrige los errores
del protocolo subyacente. En la prctica se puede observar que la recuperacin de los paquetes
perdidos aumenta el tiempo de trnsito. La prdida repetida de un slo paquete puede provocar
desfases temporales muy importantes. Como las aplicaciones de audio y vdeo necesitan flujos
constantes que no pueden tolerar variaciones y fluctuaciones sin causar interrupciones, el
protocolo TCP es inadecuado para este tipo de aplicacin cuando se rebasa un 4 5% de tasa
de prdida de paquetes, segn el informe esencial sobre telefona IP del Grupo de expertos de
Telefona IP del UIT-D (Sector de desarrollo de las telecomunicaciones ).
52
La estrategia escogida para este tipo de aplicacin consiste en dar preferencia a la continuidad
sobre la fiabilidad, en otras palabras, admitir la prdida de paquetes abandonndolos para
salvaguardar la continuidad del flujo. El protocolo UDP es ms utilizado en la telefona IP, en
lugar del protocolo TCP. El protocolo UDP funciona en un modo sin conexin, 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 correccin de
errores (por lo que no es fiable) y su funcin principal consiste en distinguir entre los
diferentes servicios de aplicacin, encaminndolos hacia el mdulo de procesamiento de
software de recepcin adecuado, mediante la atribucin de un nmero de puerto a cada
aplicacin. 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 travs 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 va un puerto impar y el siguiente puerto
par sirve para el protocolo de control RTP (RTCP). RTP y RTCP se definen dentro del mismo
estndar.
La transmisin de audio y video a travs 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 garanta de calidad de servicio (QoS), entrega fiable, ni de

reserva de recursos para el trfico de multimedia en tiempo real. RTP confa en que los
protocolos underlaying se ocuparn de estos aspectos.
2.8.4.2 Real-time Transport Control Protocol (RTCP)

RTCP es un protocolo que permite mantener informacin de control sobre una sesin RTP. Se
fundamenta en el envo peridico de paquetes de control a todos los participantes de una
53
sesin RTP, utilizando el mismo mecanismo de distribucin empleado para los paquetes de
streaming RTP. Se utiliza un canal distinto al de cada canal RTP de la sesin (se utiliza otro
puerto UDP). RTCP fue diseado para trabajar en conjunto con RTP.
2.8.4.2.1 Funciones de RTCP
Este protocolo de control tiene tres funciones principales:
1) Monitorizacin de la QoS y control de congestin: Obtiene informacin acerca de la

calidad de entrega de los datos en la distribucin de contenido multimedia en la sesin.
2) Identificacin 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
identificacin alternativa al SSRC(Sinchronization Source); as se garantitza que
streams que no tienen el mismo SSRC se puedan sincronizar y ordenar correctamente.
3) Sincronizacin Inter-Media: Obtener informacin acerca del nmero de participantes
de una sesin y recalcular dinmicamente la tasa de envo 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 sesin informar
sobre estadsticas de recepcin y transmisin.
2) Informes de receptor (receiver reports): Los utilizan los receptores que no son emisores
para enviar estadsticas sobre la recepcin.
3) Descripcin de la fuente: Contiene los CNAMEs y otros datos que describen la
informacin de los emisores.
4) Paquetes de control especficos de la aplicacin. Varios paquetes RTCP pueden ser
enviados en un mismo mensaje UDP.
54
2.8.4.3 Protocolo de Flujo de Datos en Tiempo Real

Protocol)
RTSP (Real Time Streaming
Protocolo de nivel de aplicacin no orientado a conexin definido en el RFC 2326,
que
define cmo debe llevarse a cabo el streaming. Se entiende por streaming la capacidad de
distribucin 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 aplicacin cliente ha recibido suficientes paquetes comienza la reproduccin y
simultneamente, puede estar descomprimiendo uno y reproduciendo otro. Asimismo, un
servidor mantiene informacin de estado de cada cliente que est conectado a l.
2.9 Consideraciones para el Clculo de Ancho de Banda

Es comn denominar ancho de banda a la cantidad de datos que se pueden transmitir en una
unidad de tiempo. Huidobro y Roldn (2006) lo definen como la capacidad de transmisin
de un canal de comunicaciones, medido en hercios en las comunicaciones analgicas y en
bits por segundo (bps) en las comunicaciones digitales.
Ganzbal (2008), explica que encontrar el ancho de banda en VoIP radica en encontrar los
parmetros:
Tasa de paquetes (Pr) constante.
Tamao de paquete (Pl) fijo.
Estos dos parmetros, tanto la tasa de paquetes como el tamao de paquete dependen del
codificador que se utilice. El tamao total del paquete depende adems, del tamao 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
CODEC
G.711
G.722
G.726
G.729
GSM
iLBC
Speex
BITS
RATE
(kbps)
64
48
56
64
16
24
32
40
6,4
8
11,8
13,3
13,33
15,2
5,95
8
11
15
18,2
24,6
Tt PAYLOAD
TAMAO
Tt
paquete
(bytes)
PPS
(bytes) (ms)
160
20
160
50
200
60
10
60
100
100
70
10
70
100
110
80
10
80
100
120
20
10
20
100
60
30
10
30
100
70
40
10
40
100
80
90
50
10
50
100
16
20
16
50
56
20
20
20
50
60
30
20
30
50
70
17
10
17
100
57
50
30
50
33
90
38
20
38
50
78
15
20
15
50
55
20
20
20
50
60
28
20
28
50
68
38
20
38
50
78
46
20
46
50
86
62
20
62
50
102
Tabla 2. 5 Clculo Consumo de Ancho de banda
BW
Tla
(bps)
(ms)
80.000
80.000
0
88.000
0
96.000
0
48.000
1,5
56.000
1,5
64.000
1,5
72.000
1,5
22.400
5
24.000
5
5
27.800
45.300
23.997
31.200
21.950
24.000
27.000
31.000
34.200
40.600
por CODEC
RETARDO
(ms)
20
10
10
10
11,5
11,5
11,5
11,5
25
25
25
10
30
20
20
20
20
20
20
20
Las frmulas empleadas para realizar los clculos presentados en la tabla 2.5 se resumen en la
tabla 2.6.
DESCRIPCIN
Tamao de la Trama (en
bytes)
FRMULAS
Tt (bytes)= Codec bit rate * Tt (ms)
8 bits/bytes * 1000 ms/s
Tamao Total del Paquete
TTP= (Cabecera Capa2)+(Cabecera IP/UDP/RTP)+(tamao payload de voz)
Paquetes por Segundo
PPS= Codec bit rate / tamao payload de voz
Ancho de Banda
BW= TTP * PPS

Tabla 2. 6 Frmulas para Clculos de Consumo por CODECs
Los paquetes generados por el CODEC no se transmiten directamente por la red, sino que
viajan con el aadido de cabeceras empleadas por los protocolos de las diferentes capas. Esos
bits adicionales de control tambin 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 segn el protocolo.
CABECERAS
PROTOCOLO
ANCHO DE BANDA
(BYTES)
IP/UDP/RTP
IP
20
UDP
RTP
12
Total IP/UDP/RTP
IPSEC
VPN
ETHERNET
FRAME RELAY
40 bytes
50-57
L2TP/GRE
24
Total VPN
74-81 bytes
Ethernet
18
Vlans (802.1Q )
Total Ethernet
22 bytes
Frame Relay
7 bytes
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 comn las mismas direcciones IP y los mismos puertos. El objeto del proceso de
compresin del encabezado IP/UDP/RTP definido en el RFC 2508 de la IETF, es la
reduccin de estos encabezados, con un total de 40 bytes a 2 o 4 bytes. Segn este
RFC, la compresin del encabezado opera enviando el encabezado completo
IP/UDP/RTP al principio de la comunicacin y luego solo enva informacin de
cambios.
Aunque la cabecera Ethernet tiene 38 bytes, para el clculo de consumo de ancho de

banda se utilizan simplemente 18 bytes de stos. La razn 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
Overhead Capa 2
SOBRECARGA (OVERHEAD)
MAC-DEST
(6
bytes)
MAC-ORIG
(6
BYTES
bytes)
18 bytes
Preamble (7 bytes) + Start-of-Frame-Delimiter (1 byte) +
20 bytes
Length/Type (2 bytes) + FCS/CRC (4 bytes)

Overhead Capa 1
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 parmetros que va a determinar la calidad de voz es el retardo que sufran los
paquetes. Para realizar el clculo, 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 codificacin / decodificacin
y el de empaquetamiento /
desempaquetamiento estn determinados por el codec utilizado.
El retardo de supresin de jitter , a efectos de diseo, suele tomarse igual a la duracin

de dos muestras de voz.
El retardo de propagacin,
si no se dispone de ningn valor aproximado, la
recomendacin ITU-T G.114 aconseja emplear el valor de 6ms/Km.
El retardo de serializacin, es la relacin entre el tamao de la trama y la velocidad del

enlace.
La recomendacin G.114 de la ITU-T establece como limite los 150ms o 200 ms ( en una va).
Si se supera este valor, la voz de los interlocutores tender a solaparse y la conversacin se
58
tornar inteligible. Asimismo, hay que tener en cuenta tambin que aunque aumentar la carga
til reduce el ancho de banda global, tambin aumenta en general el retardo.
El retardo siempre est presente, solo que en una conversacin telefnica convencional es tan
pequea que el odo humano no lo aprecia.
2.9.2 Otros Factores

Existen otros factores a tener en cuenta en el clculo de ancho de banda. El primero es la
supresin de silencio que se basa en la deteccin 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 informacin ahorrando de esta forma ancho de banda. El factor de actividad
de la voz suele considerrsele en el orden de un 35% a un 50%. Como consecuencia, se suele
multiplicar el resultado del clculo del ancho de banda por este factor.
Otro factor que suele sumarse al clculo es el aumento de ancho de banda debido al envo 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% ms para el
envo del RTCP.
2.10 Asterisk
Asterisk es definida oficialmente en su Handbook por su equipo de documentacin, como
Una PBX hbrida, fuente abierta, que integra tecnologa TDM, paquetes de voz
plataforma IVR con funcionalidades ACD. No oficialmente, muchos concuerdan en definirla

como
una aplicacin de software libre (bajo licencia GPLv2) que proporciona las mismas
funcionalidades (y ms) de las PBXs de los grandes sistemas propietarios, a un precio

inferior.
Con el acrnimo PBX (siglas en ingls de Private Branch Exchange) se conoce
a los
diferentes tipos de centrales telefnicas de uso privado o utilizadas en las empresas. Las
59
centrales telefnicas tienen conexin directa a la PSTN y permiten conmutar llamadas entre
usuarios de la empresa en lneas locales y compartiendo lneas externas.
Asterisk acta como middleware entre los servicios de VoIP (IAX, SIP, MGCP, H.323),
canales de telefona (como Zaptel, T1, PRI, E1, FXO, FXS, VoIP, VoFR, RDSI, mdem,
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
estndares de telefona del mercado, tanto los tradicionales (TDM) con el soporte de puertos
de interfaz analgicos (FXS y FXO) y RDSI (bsicos y primarios), as como los de telefona
IP (SIP, H.323, MGCP, SCCP/Skinny). Esto le permite conectarse a las redes pblicas de
telefona 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 lneas
analgicas / digitales con una gama amplia y soportada.
2.10.1. Arquitectura Asterisk
Asterisk fue diseado de forma modular, de manera de que cada usuario puede seleccionar las
partes que requiere utilizar (ver figura 2.18), hacindolo un sistema escalable y extensible;
escalable
porque se van habilitando o deshabilitando mdulos segn los recursos y las
necesidades; y extensible porque para programar un nuevo mdulo no es necesario conocer

todo el cdigo de Asterisk (Gmez y Gil, 2008).
60
Figura 2. 18 Arquitectura de Asterisk
Los mdulos que componen la arquitectura Asterisk son:
Core: Es el ncleo de Asterisk, que contiene las funciones ms bsicas y posibilita la

carga de mdulos. Entre sus funciones se tiene:
o Leer y procesar las configuraciones del sistema.

o Carga dinmica de mdulos.
o Ejecucin de aplicaciones.
o Proveer temporizacin al sistema.
o Conversin 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 configuracin (res_config), msica en espera (res_musichold), etc. Son
cargados de forma esttica.
61
Canales: Permiten a Asterisk manejar un dispositivo de una determinada tecnologa.

Por ejemplo, para manejar dispositivos SIP se utiliza el modulo chan_sip, para IAX
chan_iax, y para canales analgicos/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 mdulos cargables y son cargados dinmicamente por el ncleo al ser
llamadas desde el dialplan. Son invocadas secuencialmente durante el transcuro de una
llamada.
CDR (Call Detail Records): Estos mdulos controlan la escritura del registro telefnico
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 compresin.
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 mdulo que da soporte al hardware de Asterisk
llamado Zaptel, cambio de nombre a DAHDI ) desaparecera. Sin embargo, normalmente es
necesario conectarse a redes tradicionales como la red telefnica pblica conmutada (PSTN)
y el canal ZAP contiene los drivers para el funcionamiento de tarjetas telefnicas PCI que
permitirn esta interconexin.
Los canales SIP, IAX y ZAP (asi como otras entidades en el sistema) tienen acceso a su
archivo de configuracin a travs 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
nmero. Esta peticin es recibida por el mdulo correspondiente de Asterisk (canales
chan_zap, chan_sip, chan_iax, chan_xxx), quien a su vez revisa el archivo de configuracin
correspondiente (archivos zapata.conf, sip.conf, iax.conf ) para autorizar la llamada y decidir a
que contexto (agrupaciones lgicas 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
instalacin que se vaya a realizar, son necesarios unos u otros, a saber:
1. Digium Asterisk Hardware Device Interface DAHDI: Son los mdulos del kernel para
hacer funcionar las tarjetas de comunicacin analgicas y digitales. Adems contiene
varias utilidades de configuracin y diagnstico. El mdulo 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 mdulos de kernel necesario para poder

utilizar las tarjetas de comunicaciones.
b. El paquete
DAHDI-TOOLS son las aplicaciones necesarias para cargar la
configuracin, hacer tests a algunas tarjetas y algunas cosas ms que se irn

aadiendo poco a poco.
c. El paquete DAHDI-LINUX-COMPLETE es la unin de los dos anteriores, para
no tener que descargar dos paquetes independientes.
2. LIBPRI: Es la librera encargada de dar soporte a sealizacin 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 ningn primario.
3. ASTERISK: Es el cdigo fuente de Asterisk y es el nico componente necesario si la
instalacin 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 mdulos 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
METODOLOGA
En el presente captulo se exponen los aspectos referidos a la metodologa que se desarrollo
para para elaborar el Diseo de una Solucin de Telefona IP basada en Asterisk para
Servinave, C.A., describiendo el tipo de investigacin, las tcnicas de recoleccin de datos y
el procedimiento que se sigui para la propuesta final del Diseo.
3.1. Tipo de Investigacin
El presente Trabajo Especial de Grado est enmarcado dentro de la modalidad de Proyecto

Factible, apoyado en una Investigacin Documental y de Campo.
Se considera que es un Proyecto Factible debido a que en l se plantea una solucin posible o
viable a la problemtica que enfrenta la Empresa Servinave,C.A.
Se apoya en una Investigacin Documental porque es necesario consultar literatura acerca de

la tecnologa utilizada (manuales, trabajos previos realizados, informaciones impresas y/o
electrnicas, entre otras ), para obtener una base terica slida que permita crear el enfoque
y criterio necesario para la lograr la viabilidad del trabajo. Igualmente se apoya es una
Investigacin 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 telefnicos y
computadores.
3.2. Tcnicas de Recoleccin de Datos
Las tcnicas de recoleccin 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 tcnico responsable de la red de voz y datos para
conocer y obtener la documentacin de la infraestructura desplegada, asi como
conocer el plan de marcacin que actualmente tienen las PBX instaladas.
Observacin Directa: Tcnica que permiti validar la informacin recogida en las

entrevistas as como comprender el funcionamiento real de la plataforma tecnolgica
utilizada por la Empresa.
Revisin Documental: Mediante esta tcnica se obtuvieron las bases tericas

necesarias para la elaboracin del diseo. Se bas en la revisin de todo tipo de
literatura: documentacin de la red de voz y datos actual, manuales, libros, estandares
vigentes, documentos publicados en Internet, trabajos previos realizados, foros, entre
otras.
3.3 Metodologa a Utilizar

El desarrollo de del Diseo de una Solucin de Telefona IP basada en Asterisk para
Servinave, C.A., fue dividido en cinco fases, las cuales son:
Fase 1: Recolectar Informacin
Actividades
Revisin bibliogrfica.
Identificacin de las funcionalidades necesarias por cada sucursal/principal.
Revisin de la infraestructura actual.

o Red de Telefona
66
o Determinar la carga y el flujo del trfico de voz intersucursal

o Red de Datos
FASE 2: Definicin de la Tecnologa
Actividades
Clculo de canales VoIP por sucursal/principal
Seleccin protocolos
Seleccin de CODECs
Clculo de ancho de banda
FASE 3: Diseo de la Propuesta
Actividades
Definicin de la infraestructura
Dimensionamiento y seleccin del hardware y software
Estimacin de costos
Diseo del plan de discado (dialplan)
FASE 4: Prueba Piloto
Actividades
Definicin de la prueba
Creacin de VLANs
Instalacin y configuracin en los servidores Asterisk de

o GNU/Linux CentOS
o Servicios de telefona
67
o Tarjetas de telefona
o Configuracin de Asterisk
Configuracin de los terminales de voz
Pruebas
Revisin y ajustes de los parmetros definidos en el diseo
Conclusiones
FASE 5: Anlisis de Resultados
Actividades
Impacto de la nueva propuesta
68
CAPITULO IV
DESARROLLO
En el presente captulo se exponen todos los aspectos relacionados con el desarrollo del
diseo de la solucin. Cabe destacar que, antes de iniciar esta exposicin, se presenta una
breve descripcin de la Empresa para la que se est realizando este diseo.
4.1 Marco Organizacional
Servinave, C.A. es una empresa de servicios
de la organizacin BLOHM, dedicada al
agenciamiento naviero. Entre sus principales actividades se destacan la operacin de buques,

representacin y documentacin de las lneas navieras.
La oficina principal se encuentra ubicada en Caracas y las sucursales estn 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
comunicacin entre los puertos y oficina principal, as como de la oficina principal con los
clientes (informar arribos y estatus
de cargas) y las lneas representadas (itinerarios y
Manifiestos de cargas). Es importante resaltar que las lneas representadas no se encuentran en

Venezuela, por lo que las llamadas internacionales tambin son muy frecuentes.
De acuerdo al Dpto. de operaciones de Servinave, el proceso productivo de la empresa se

puede resumir como sigue:
69
1. Planificacin del servicio: En esta parte del proceso se realiza toda la logstica
determinando qu le corresponde.
2. Elaboracin y recepcin 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
lnea realiza la transferencia de fondos a la empresa.
3. Cancelacin de pagos previos Capitana, 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 capitana de puerto cinco das antes de la llegada del
barco y se solicita un muelle para que el buque atraque.
5. Elaboracin del prospecto de buque: Con la informacin suministrada por la capitana 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 lnea 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. Transmisin de los manifiestos de carga: Cuarenta y ocho horas antes de la llegada del
barco o a ms tardar antes de su salida, se deben presentar los conocimientos de la carga de
importacin que trae el buque a travs del sistema online del Seniat (SIDUNEA). La
transmisin extempornea genera multas.
8. Amarre o conexin para el atraque del buque: Se amarra el buque a la unidad que remolca
el buque hasta el muelle.
9. Atencin del Buque: Esta es la parte central del proceso, incluye el amarre y desamarre
del buque al muelle, prestar provisiones para la tripulacin del barco, atencin mdica,
custodia del buque, suministro de combustible, lancha, remolcador, agua fresca,
recoleccin de basura, migracin, embarque y desembarque, entre otros.
10. Solicitud de despacho de buque para el zarpe: Se debe ir a la capitana de puerto y solicitar
el permiso de zarpe, documento que indica que el buque no tiene problemas para zarpar.
11. Desamarre o Desconexin 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. Cancelacin 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. Facturacin: Mediante un sistema computarizado se elaboran las facturas las cuales son
asentadas y enviadas al departamento de contabilidad para su control y elaboracin de
informes y balances mensuales.
14.
Elaboracin y Envo de Estado de Cuenta: Se elaboran los estados de cuenta mediante un

sistema automatizado, lo que incluye entrada y verificacin de datos. Luego se envan a las
lneas para su control.
4.2 Recolectar Informacin

Al finalizar las actividades que conforman esta fase se logro tener un diagnstico de la
situacin actual. Las actividades realizadas fueron las siguientes:
4.2.1 Revisin Bibliogrfica

En esta actividad se obtuvieron las bases tericas necesarias para realizar el Trabajo. Se bas
principalmente en la bsqueda de informacin referente al tema estudiado.
Las principales fuentes de informacin fueron documentos bibliogrficos, los cuales provienen
de diferentes fuentes, libros, revistas, e Internet. Sin embargo, es importante mencionar que
parte de la informacin y de los conocimientos necesarios se obtuvieron de cursos tcnicos
tomados en el rea de Asterisk , Linux , VoIP y telefona IP. Otra fuente de referencia
importante consultada fue la experiencia de otras empresas de la Organizacin en instalaciones
similares que, aunque tienen realidades y tecnologas diferentes, sirvieron como gua.
Dentro de la informacin obtenida se resaltan los siguientes tpicos:
Filosofa de la telefona convencional.
Funcionamiento de las redes de voz y datos
71
Filosofa de VoIP y Telefona IP
Administracin Linux
Funcionamiento y configuracin Asterisk.
Calidad de Servicio (QoS)
4.2.2 Identificacin 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 administracin. La entrevista
constaba de las siguientes preguntas:
1. Actualmente, Existe algn tipo de problema con las lneas telefnicas o con la PBX?
2. Piensa Ud. que cuentan con suficientes lneas telefnicas?
3. Con qu facilidades telefnicas cuentan actualmente?
4. Qu otras facilidades telefnicas cree Ud. que la oficina requiere?
5. Han recibido quejas de los clientes o de otras sucursales acerca de que nunca atienden el
telfono?
De las respuestas obtenidas (ver tabla 4.1), se pudo concluir lo siguiente:
Se detect que la Empresa hace uso bastante bsico de las funcionalidades de una central
telefnica.
La mayora de las facilidades que solicitan las ofrece Asterisk como parte de su
funcionalidad bsica.
La cantidad de lneas con que cuenta cada oficina es suficiente.
Basado en lo anterior, se definen las siguientes funcionalidades para todas las oficinas (como
mnimo):
Hacer y recibir llamadas (internas y externas)
Hacer transferencia de llamadas.
72
Que la llamada sea redirigida a travs de la red de datos cuando se desee llamar a una
de las sucursales.
Que cada extensin tenga asignado su correspondiente voicemail .
Que las llamadas entrantes sean atendidas por un IVR y ste las distribuya segn las
opciones seleccionadas.
Poder ver el identificador del llamante (Caller Id).
OFICINA
PREGUNTA
1
Caracas
NO SI
PBX
CALLER ID de llamadas externas
IVR
Poder llamar por
Buzn de voz
minimizar gastos)
Directos
Puerto
5
NO
la red privada a las sucursales (para
Poder controlar el gasto telefnico de las sucursales
NO SI
PBX bsica
Ninguna en particular
NO
La Guaira
NO SI
PBX bsica
NO
Maracaibo
NO SI
PBX bsica
NO
Valencia
NO SI
LINEA
Poder transferir llamadas entre la ellos
NO
Cabello
DIRECTAS
Controlar el acceso a la PSTN
Cuman
NO SI
PBX bsica
NO
Puerto La
NO SI
PBX bsica
NO
NO SI
LINEA
Que cada uno tenga una extensin.
NO
Cruz
Punto Fijo
DIRECTAS
Controlar el acceso a la PSTN

Poder transferir entre ellos llamadas
Tabla 4. 1Respuesta de las Entrevistas
4.2.3 Revisin de la Infraestructura Actual

A travs de la entrevista con el personal responsable de la red de voz y datos y de la revisin
de la documentacin de la misma se pudo conocer la infraestructura desplegada a nivel
nacional.
73
En lneas generales, tanto en la oficina central como en las sucursales, las redes de voz y datos
son totalmente independientes, sin puntos comuns de conexin. A continuacin se describen
cada una de ellas.
4.2.3.1 Servicio de Telefona

El sistema de telefona que utiliza la empresa es el tradicional, inclusive para comunicarse
entre las sucursales. Todas las lneas suscritas son analgicas con distinta numeracin y
llegan a la central mediante par telefnico (conexin estndar).
Las lneas son suministradas
por un nico proveedor, CANTV, y la contratacin y gestin de las mismas es tramitada

directamente por el rea administrativa de cada oficina y no por el rea de tecnologa (a
excepcin de la oficina principal). Para todas las oficinas, el cableado empleado para esta red
es categora 3. En la tabla 4.2, se resume la cantidad de lneas 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 Lneas
CARACAS
31
PUERTO CABELLO
18
LA GUAIRA
17
MARACAIBO
11
VALENCIA
CUMAN
PUERTO LA CRUZ
PUNTO FIJO
Tabla 4. 2 Lneas Contratadas
Existe una variedad de aparatos telefnicos, la mayora analgicos. La marca de stos vara
entre la marca del propietario de la central y marcas genricas. Por razones econmicas, no
todos los puestos cuentan con aparatos telefnicos (ver tabla 4.3).
74
Modelos de Telfonos
OFICINA
ANALGICOS DIGITALES FAX

Caracas
48
Puerto Cabello
22
21
La Guaira
16
Maracaibo
14
Valencia
Cuman
Puerto la Cruz
Punto Fijo
Tabla 4. 3 Distribucin de Telfonos por Oficina
Actualmente, en las oficinas donde hay central telefnica, los servicios de la central que estn
configurados y en uso son los bsicos y los servicios de fax son prestados a travs de equipos
tradicionales. Solo la oficina de Caracas cuenta adems con servicio de IVR (Interactive voice
response) y buzn 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
estn autorizadas para todos los usuarios, mediante la configuracin de nmeros abreviados.
Finalmente, ninguna de las oficinas posee un contrato de mantenimiento para la PBX. En las
oficinas donde no hay central telefnica, no se aplica ningn tipo de restriccin
en la
realizacin de llamadas. Tanto la PBX de Caracas como la de Puerto Cabello tienen

interconexin mediante lneas FXS/FXO con centrales Siemens de
otras empresas
pertenecientes a la misma organizacin.
4.2.3.2 Clculo de Trfico Inter-Sucursal

Las oficinas no cuentan con una aplicacin fiable que permita conocer la distribucin del
trfico telefnico. No obstante, por medio de las facturas telefnicas del proveedor de servicio
se pudo estimar el trfico 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
Caracas hacia
Minutos
Llamadas diarias
diarios
Puerto Cabello
32
114,59
La Guaira
38
131,34
Maracaibo
5,59
Valencia
49,93
Cuman
9,81
Puerto La Cruz
6,77
Punto Fijo
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
32,66
Maracaibo
8,55
Valencia
9,51
Cuman
2,96
Puerto La Cruz
1,1
Punto Fijo
TOTAL
25
111,61
Tabla 4. 5 Resumen de llamadas desde Oficina Puerto Cabello
Minutos
Desde la oficina La Guaira
Llamadas diarias
diarios
Caracas
24
70,6
Puerto Cabello
10
35,17
Maracaibo
4,17
Valencia
153,08
Cuman
10,73
Puerto La Cruz
2,61
Punto Fijo
TOTAL
42
276,36
Tabla 4. 6 Resumen de llamadas desde Oficina La Guaira
76
Desde la oficina Maracaibo
Llamadas
Minutos
diarias
diarios
Caracas
31,40
Puerto Cabello
7,80
La Guaira
0,81
Valencia
0,00
Puerto La Cruz
1,87
Cuman
0,00
Punto Fijo
8,84
TOTAL
50,72
Tabla 4. 7 Resumen de llamadas desde Oficina Maracaibo
Desde la oficina Valencia
Llamadas
Minutos
diarias
diarios
Caracas
44,24
Puerto Cabello
16,43
La Guaira
0,79
Maracaibo
0,00
Cuman
0,00
Puerto La Cruz
0,00
Punto Fijo
0,00
TOTAL
61,46
Tabla 4. 8 Resumen de llamadas desde Oficina Valencia
Desde la oficina Cuman
Llamadas
Minutos
diarias
diarios
Caracas
6.47
Punto Fijo
Puerto Cabello
3.65
La Guaira
10.53
Maracaibo
Valencia
Puerto La Cruz
Punto Fijo
TOTAL
20.66
Tabla 4. 9 Resumen de llamadas desde Oficina Cuman
77
Desde la oficina Puerto La
Llamadas
Minutos
Cruz
diarias
diarios
Caracas
6,91
Puerto Cabello
0,07
La Guaira
9,19
Maracaibo
8,37
Valencia
0,00
Cuman
0,17
Punto Fijo
0,36
TOTAL
10
25,07
Tabla 4. 10 Resumen de llamadas desde Oficina Puerto La Cruz
Desde la oficina Punto Fijo
Llamadas
Minutos
diarias
diarios
Caracas
7,19
Puerto Cabello
0,00
La Guaira
0,00
Maracaibo
12,00
Valencia
0,00
Cuman
0,00
Puerto La Cruz
0,00
TOTAL
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 lneas 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 categora
5e y diseada en
topologa 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
Modelo
802.1q
802.1p
Colas
Puertos FE
Puertos GE
(Vlans)
(QoS)
x Puerto
3300XM
24
si
si
4400SE
24
si
si
24/48
2/2
si
si
24
si
si
4500
4226T
Tabla 4. 12 Caractersticas de los Switches de Servinave, C.A.
La navegacin a Internet es independiente en cada oficina, contando una conexin 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 tambin cuenta con una conexin ABA, exigida para poder conectarse, via VPN, a
la aplicacin del Seniat donde se declaran las cargas, SIDUNEA (Es exigencia del SENIAT
establecer una conexin VPN con ellos solo a travs de una conexin 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 versin del IOS 12.4. La Serie 2800 de Cisco, est diseada para la
entrega a velocidad de cable para servicios concurrentes altamente seguros y puede soportar
conexiones mltiples 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
electrnico, Webmail y acceso a las aplicaciones de contabilidad, de gestin naviera.
El DNS principal se encuentra en la oficina principal y existe un servidor de reenvo en la

oficina de Puerto Cabello.
79
El servicio de correo electrnico 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 dems
oficinas se conectan mediante protocolo POP3 al servidor de la oficina central para bajar sus
correos y el envo de los mismos (SMTP) es directamente a travs del proveedor de Internet
de cada localidad (las oficinas que tienen servidor de relevo envan a travs del servidor de
correos de la oficina principal).
La aplicacin 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 aplicacin es en entorno Web,
mientras que las aplicaciones de contabilidad y naviera son en ambiente caracter y estn
ubicadas en la oficina principal, cada una en servidor IBM ISeries. Tambin existen
aplicaciones de otros clientes que son accedidas directamente por cada oficina a travs de
Internet y no dependen de la oficina principal.
La aplicacin SPA(aplicacin de gestin de Contenedores y estiba ) se encuentra instalada en

un servidor IBM ISeries ubicado en la oficina de Puerto Cabello. Esta aplicacin es accedida
adems por las oficinas de La Guaira y Cuman, mediante sesiones telnet.
Resumiendo, el trfico de datos que circula por la red LAN/WAN se resume en la tabla 4.13:
PROTOCOLOS
APLICACIONES
POP3
Correo electrnico
NRPC
Correo electrnico
SMTP
Correo electrnico
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 estadstica 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
aplicacin BECOMONITOR (aplicacin desarrollada en la Organizacin) 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 aplicacin obtiene los valores mediante el registro del resultado de la ejecucin de un
ping durante cierto tiempo, a un servidor ubicado en cada sucursal, varias veces en el da,
todos los das. Luego, mediante el modulo de reportes se consulta est informacin.
4.3 Definicin de la Tecnologa

Una de las etapas crticas del diseo de una solucin de VoIP es el clculo de ancho de banda
necesario para cursar el trfico de llamadas y el datos manteniendo la calidad de servicio
exigida por cada trfico. En este ancho de bando influye, fundamentalmente, tres factores:
volumen de trfico cursado, CODEC empleado para la generacin de paquetes de voz y el
formato de dichos paquetes (cabecera e informacin til).
Los canales de VoIP representan la cantidad de llamadas simultneas entre las sucursales, es
decir, la cantidad de trfico de voz que va a cursar a travs de la WAN de la empresa
El trfico es una medida de la carga de los recursos de la red, de manera que cuanto mayor es
el nivel del trfico, tanto ms cargados estn los recursos o tantos ms recursos son necesarios
para mantener una ocupacin dada. En telecomunicaciones, la unidad utilizada como medida
estadstica del volumen de trfico, es el ERLANG.
Existen varios modelos de trfico que se emplean para calcular cuntas lneas de enlace
(canales) son necesarias, los principales modelos son los siguientes:
81
Erlang B: Es el modelo ms comn y se emplea para calcular cuntas lneas son

necesarias para una cifra de trfico (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 cul
es el porcentaje de llamadas bloqueadas (que reciben seal 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 trfico de voz intersucursal calculado en la fase anterior, toda vez que
se seleccion los CODECs y los protocolos de sealizacin requeridos para el diseo. Las
actividades realizadas fueron las siguientes:
4.3.1 Clculo de Canales VoIP por sucursal/principal

El clculo 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 trfico que cursa durante
la hora ms ocupada del da.
Blocking (bloqueo): Es la fraccin de llamadas que no pudieron ser atendidas porque

todas las lneas estaban ocupadas. Dependiendo de la aplicacin, una cifra razonable de
bloqueo est entre 0.01 y 0.03.
Lines (Canales, circuitos, lneas): Cantidad de lneas necesarias o disponibles.
La variable BHT representa los sesenta minutos en los que los niveles de trfico alcanzaron
el mayor nivel. Este parmetro solo pudo ser calculado para las oficinas de Caracas, Puerto
Cabello y La Guaira, debido a que solo exista data de estas oficinas. Los valores obtenidos
82
despus de sumar los minutos cursados en un mes, hora por hora, en lapsos de 24 horas, estn
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 parmetro BHT, se
estim (E) el mismo como el 17% del total del trfico diario de la oficina.
Finalmente, sabiendo que un Erlang equivale a 60 minutos de llamadas en una hora y

asumiendo como parmetro 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
Puerto Cabello
47,25
0,7875
La Guaira
52,35
0,8725
Maracaibo (E)
8.62
0.14
Valencia (E)
10.44
0.17
Cuman (E)
3.51
0.06
Puerto La Cruz (E)
4.26
0.071
Punto Fijo(E)
3.26
0.05
Tabla 4. 15 Cantidad de Canales por Oficina
4.3.2 Seleccin de Protocolos

Como se ha mencionado anteriormente, los protocolos de sealizacin son las normas que
describen el intercambio de informacin relacionada con el establecimiento, control y gestin
de las conexiones. Para este diseo se realiz la siguiente seleccin:
83
1. La sealizacin entre el servidor Asterisk y la PSTN es
atravs de interfaces
FXS/FXO, con sealizacin KewlStart (ks), por ser la sealizacion utilizada por las
lineas analgicas y corresponder con lo que tiene contratado servinave actualmente.
2. La sealizacin entre el servidor Asterisk y los telfonos IP es a travs del protocolo
SIP, por se un estndar abierto de mucha popularidad en el sector y el ms comercial
(es fcil conseguir en el mercado telefonos IP que trabajen con este estndar).
3. La sealizacin entre servidores Asterisk es a travs del protocolo IAX2, por ser un
protocolo abierto originalmente creado para interconectar servidores. Asimismo, Es
capaz de enviar mltiples 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 Seleccin de CODECs
La seleccin del codec para este diseo 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 difcil tener las tres condiciones simultneamente, se seleccion:
CODEC G711a para la comunicacin entre los telfonos 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 comunicacin sobre WAN, debido a que ofrece de base , segn
su sitio oficial (http://www.ilbcfreeware.org/) una calidad mayor al CODEC privativo
G.729A, altos ndices de resistencia a la prdida de paquetes y la complejidad
computacional est en el rango de G.729A. No requiere licencia.
4.3.4 Clculo de Ancho de Banda

Para elaborar el clculo del consumo de ancho de banda, se utiliz la calculadora de ancho
de banda (figura 4.1). Los parmetros a ingresar en la misma son CODEC a utilizar, el tamao
de la trama (en ms o bytes), protocolos de capa 3 y capa2 (aqu se indica si se desea
compresin de encabezado), si se considera la supresin de silencio y/o el retardo del 5% por
el envo de mensajes RTCP y finalmente el nmero 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 compresin, y otras

funcionalidades, mayor es el procesamiento y mayor es el retardo intrnseco de los CODECs.
85
Header
Bits Rate
BW /cBW
Retardo
Overhead
Ethernet
Header
Codec
(kbps)
(kbps)
(ms)
RTCP (5%)
+Vlan
FR
G.711a
64
80
20
84
100,8
13,33
24 / 14,6
30
25,2 / 15,33
iLBC
MOS
4,3 -4,7
27,1 / 16,4
Tabla 4. 16 Consumo de Codecs Seleccionados
Cada llamada requiere dos flujos RTP, uno para cada sentido de la comunicacin. Por tanto, el
ancho de banda por llamada que cursar por la WAN ser 2 x 16.4 kbps (se debe trabajar con
compresin de cabeceras IP/UDP/RTP). El ancho de banda total requerido para soportar el
trfico de voz intersucursal, se presenta en la tabla 4.17.
Canales
BW
Caracas
229,6
Puerto Cabello
131,2
La Guaira
164
Maracaibo (E)
65,6
Valencia (E)
98,4
Cuman (E)
65.6
Puerto La Cruz (E)
65,6
Punto Fijo(E)
65,6
Oficina
Tabla 4. 17 Ancho de banda para Voz Requerido por Oficina
4.4 Diseo de la Propuesta

La ejecucin de las actividades que conforman esta fase permitieron armar el Diseo de la
Solucin de Telefona IP que permitir a Servinave actualizar su plataforma telefnica. Las
actividades realizadas fueron las siguientes:
4.4.1 Definicin de la Infraestructura

Este diseo persigue colocar en funcionamiento PBXs de software en equipos hardware de
propsito general (arquitectura PC), en un esquema distribuido, es decir, que cada sucursal
86
cuente con un servidor Asterisk interconectado con la oficina principal, a travs de la red
WAN de la empresa, adems de una interconexin directa a la PSTN. Con este esquema se
pretende que el servicio telefnico de la sucursal no dependa de la oficina principal,
garantizando la continuidad del mencionado servicio ante eventuales cadas de la red WAN.
El rendimiento de Asterisk no depende directamente del nmero de usuarios sino de la

cantidad de llamadas simultneas 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, hacindolo muy dependiente del rendimiento del
CPU. En consecuencia, todas las funciones que no estn 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 asignacin de IRQ
(Interrupt Request - Pedido de Interrupcin). 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 analgicas, en cortes de audio, y en el caso de las tarjetas digitales, en prdidas de
tramas, incluida la de sincronizacin lo que podra ocasionar el reinicio de todo el primario.
Como se mencion, cada instalacin Asterisk se ejecutar en un servidor dedicado y se debe

implementar VLAN (acrnimo de Virtual LAN, red de rea local virtual) para separar el
trfico de voz del trfico 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 fenmenos ocurren, puedan
comprometer el correcto funcionamiento de Asterisk. Las implementaciones de VLAN son
realizadas bajo el estndar IEEE 802.1Q.
Finalmente es importante resaltar que el diseo busca aprovechar, en la medida de lo posible,

la infraestructura instalada, haciendo solo ajustes necesarios para mantener un costo de
inversin-actualizacin razonable para la empresa.
87
4.4.1.1 VLANs y Direccionamiento

Partiendo de que la VLAN es un mtodo para crear redes lgicamente independientes dentro
de una misma red fsica, se debe segmentar la red LAN de cada oficina en dos redes lgicas
clase C, tal como se puede apreciar en la tabla 4.18.
VLAN
DIRECCIONAMIENTO
DESCRIPCIN
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 variarn 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
dinmicamente 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 direccin 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 trfico de
datos suele ser a rfagas.
La poltica FIFO (First Input First Output) es adoptada para el
88
procesamiento de los paquetes, sin aplicar ninguna distincin entre ellos. Los recursos
requeridos para el envo de paquetes son determinados por el orden en el cual stos llegan y
la poltica 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
utilizacin 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 polticas
o mecanismos que permitan dar
prioridad a cierto tipo de trfico sensible a retrasos (voz - video) con respecto al resto del
trfico, de modo que las conversaciones de voz no se vean interrumpidas por las grandes
transferencias de datos.
Estas polticas
o mecanismos son conocidas como Calidad de
Servicio o QoS (del ingls, Quality of Service). La QoS de extremo a extremo que se
implemente depender de la QoS admitida por los routers, switches y por los telfonos IP
disponibles en la red.
4.4.1.2.1 QoS en telfonos IP

Los telfonos IP son los terminales del usuario, motivo por el cual resultan crticos para el
xito del servicio de VoIP. Los telfonos IP permiten, por lo general, establecer una etiqueta
para que los paquetes que salgan del telfono la lleven adosada y puedan ser priorizados nada
ms al salir, pero una vez que llegan al switch o al router, ste lo procesa como un paquete
ms por lo que es fundamental tener priorizado dicho paquete en estos equipos tambin.
Dependiendo del telfono IP a utilizar se aplicaran polticas de QoS en switches.
Existen diferentes tipos de telfonos IP que pueden ser implementados, entre los que se
destacan:
Hardphones: Son terminales de usuario semejante a los telfonos tradicionales, con la
89
diferencia que disponen de al menos un puerto de conexin RJ-45, en lugar del

tradicional RJ-11. La conexin RJ-45 es un puerto Ethernet con el cual se conectan
dichos telfonos 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 telfono convencional. Es necesario
tener instalado micrfono y auriculares.
ATA: Acrnimo de Analog Telephone Adapter, es un dispositivo electrnico que

crea una conexin fsica entre el telfono analgico convencional y un PC o una red de
rea local (LAN), convirtiendo y comprimiendo la seal de la voz en paquetes de datos
que se envan en una red IP tal como lo hace un Telfono IP. Las empresas que ya
disponen de telfonos analgicos y prefieren no invertir en nuevos telfonos IP hacen
uso de estos dispositivos.
4.4.1.2.2 QoS en Switches
Partiendo de la base de que es necesario separar el trfico de voz del trfico de data, hay que
hacer consideraciones segn el tipo de telfono a utilizar.
Existe una caracterstica en los switches 3com llamada voiceVlan que permite, haciendo las
configuraciones pertinentes, asignar automticamente trfico voz a la VLAN correspondiente
(VLAN10), optimizando este trfico 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 direccin MAC esta registrada en una tabla que consultara para
identificarlo.
Como los softphones no tienen direccin 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 aplicacin
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 aplicacin seleccionada no tenga esta caracterstica, en el
90
switch se deber configurar como puertos TRUNK los puertos de las PCs que utilizarn
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 trfico para posteriormente agruparlos. Una vez
identificados, el trfico 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
electrnico puede variar de segundos a minutos. Las soluciones de telefona 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 propsito
facilitarle al Administrador de la red el seteo bsico de los atributos de QoS. AutoQoS se
encuentra disponible en los routers Cisco IOS desde la serie 2600 hasta la serie 7200 y
tambin en la mayora de los routers Cisco que utilizan versiones de IOS 12.2(15)T y
posteriores. AutoQoS ofrece los siguientes beneficios:
No requiere una comprensin avanzada de QoS del mismo modo que si se desea
configurar desde la lnea de comandos.
Se pueden modificar las polticas de QoS y reutilizarlas, del mismo modo que si se
tratara de un template.
4.4.2 Dimensionamiento y Seleccin del Hardware /Software

A continuacin de identifican todos los elementos de hardware y software necesarios para el
diseo.
91
4.4.2.1 Interconexin con la PSTN

Digium ha desarrollado una familia de tarjetas analgicas PCI y PCI-Express que permiten la
integracin de Asterisk con la telefona analgica clsica, tanto con telfonos a modo de
extensin como de lneas PSTN de los proveedores. Partiendo de que todas las lneas PSTN
contratadas por la empresa Servinave son de tipo analgico y, de acuerdo al inventario de
lneas, se requerirn las tarjetas indicadas en la tabla 4.20 para interconectar cada oficina con
la red PSTN.
OFICINA
N Lneas
Tarjeta
AEX2400P
CARACAS
31
AEX800P
PUERTO CABELLO
18
AEX2400P
LA GUAIRA
17
AEX2400P
MARACAIBO
11
AEX2400P
VALENCIA
AEX800P
CUMAN
AEX800P
PUERTO LA CRUZ
AEX800P
PUNTO FIJO
AEX800P
Tabla 4. 20 Tarjetas Digium Sugeridas
La diferencia entre las tarjetas viene dado por la capacidad mxima de las mismas, las
AEX800P permite hacer combinaciones de puertos FXO/FXS hasta un mximo de 8 en la
misma placa mientras que la AEX2400P permite combinaciones de hasta 24 puertos en total.
Esta ltima es de mayor dimensin (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 tambin parte de la solucin Digium).
Tanto las tarjetas AEX2400P como las AEX800P permiten incluir mdulos de 4 puertos en
cada banco para crear las diferentes configuraciones de FXS/FXO mediante la combinacin
de los mdulos, 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
mdulos de 4 puertos disponibles son:
FXS S400M
FXO X400M
Es importante incluir tambin en cada tarjeta el
mdulo VPMADTO32
para ofrecer
cancelacin 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 mayora de los algoritmos de supresin de eco opera
generando mltiples copias de seal, recibiendo cada una atrasada por un pequeo espacio de
tiempo. Este flujo es lo que se conoce como tap. El numero de taps determina el tamao de
atraso de eco que puede ser cancelado. Estas copias atrasadas son entonces ajustadas y
sustradas de la seal original recibida. El truco es ajustar la seal 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
caractersticas estn resumidas en la tabla 4.21.
Segn 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
caractersticas similares al CODEC G729 y que el volmen de llamadas concurrentes de
Servinave es mucho menor, igualmente se sugiere un equipo con caractersticas similares (ver
tabla 4.21).
93
CARACTERSTICAS
DESCRIPCIN
Formato y Altura
Torre / Tower 5U
CPU Ghz/FB MHz mxima.
Intel Xeon Pentium Dual Core 1.87 Ghz / 1066 MHz
Memoria [1] (base, mxima)
2 GB expandible hasta 8GB / CAbc
Ranuras de expansin
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 alimentacin
400 WATTIOS
Tabla 4. 21 Caractersticas Tcnicas de los Servidores
4.4.2.3 Sistema Operativo

El diseo de la solucin est basado en la distribucin GNU/Linux CentOS (Community
ENTerprise Operating System) versin 5.3 como sistema operativo de los servidores Asterisk.
CentOS es un clon a nivel binario de la distribucin Red Hat Enterprise Linux RHEL,
compilado por voluntarios a partir del cdigo fuente liberado por Red Hat. Es una distribucin
estable con una slida comunidad de usuarios que lo utilizan y hacen posible la existencia de
gran cantidad de foros con preguntas y respuestas basadas en esta distribucin. Sin embargo,
es importante resaltar que Asterisk funciona perfectamente bajo cualquier distribucin.
4.4.2.4 Asterisk
La versin estable de Asterisk a utilizar est compuesta por los mdulos siguientes:
Asterisk: Archivos base del proyecto. Versin instalada 1.4.24.1
DAHDI: Soporte para hardware. Drivers de tarjetas. (Anteriormente ZAPTEL).

Versin instalada dahdi linux 2.1.0.4 y dahdi tools 2.1.0.2
Asterisk Addons: Complementos y aadidos del paquete Asterisk (opcional). Versin

instalada 1.4.8
Libpri: Soporte para conexiones digitales. (Opcional). Versin instalada 1.4.9
94
4.4.2.5 Telfonos IP
En el diseo de esta solucin se van a utilizar hardphones como sustitutos de los aparatos
telefnicos propietarios que existen actualmente en la empresa y dispositivos ATAs para
interconectar a la red IP los telfonos analgicos que ya se poseen.
Los softphone sern
considerados como alternativa nicamente para aquellos usuarios que se trasladan entre las
sucursales (usuarios mviles) y para los usuarios del departamento de tecnologa.
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 telfono. Las propiedades a
evaluar en los telfonos seleccionados para esta propuesta son:
Soporte del protocolo 802.1P/Q
Soporte para supresin de silencios y cancelacin de eco
Interface amigable
Compatible con los codecs iLBC, g711, entre otros.
Protocolo de sealizacin SIP, IAX (opcional)
Envo 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 caractersticas 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 funcin de telfono
integrada. Ideal para reuniones de hasta 8 personas. Sistema full duplex, con seleccin
automtica del mejor micrfono.
Para la operadora, se considero agregar un mdulo extensin Linksys, para que cuente con
mayor nmero 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 diseo, y, adems de soportar el
protocolo de sealizacin SIP, soporta tambin el protocolo de sealizacin IAX (nativo de
Asterisk). Para estos casos, se sugieren auriculares diseadas para VoIP, que se conecten va
puerto USB. Los modelos propuestos son AUDIO 615USB (monoaural), 625USB (biaural),
630USB (biaural y estereo) y CS50USB inalmbrico, 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 msica y para la fcil movilizacin (inalmbrico). Este ltimo est pensado
principalmente para el personal de soporte tcnico y/o para cualquier otro que, por sus
actividades, requiera desplazarse continuamente por la oficina. En todo caso el auricular
seleccionado debe incluir micrfono con anulacin de ruido y la caracterstica de eliminacin
del eco. En la tabla 4.22 se puede apreciar un resumen de los modelos sugeridos para el
diseo.
HARDPHONES
SPA901
1 puerto ethernet / sin pantalla
SPA921
1 puerto ethernet / con pantalla
SPA922
2 puertos ethernet / con pantalla
SPA932
2 puerto ethernet + modulo expansin
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
Inalmbrico
Tabla 4. 22 Modelos de Telfonos Sugeridos
96
4.4.2.6 Consideraciones con los equipos FAX

Los equipos de Fax, por ser equipos de tipo analgico se conectaran a la red a travs de
dispositivos ATAs. En este caso, estos equipos deben ser compatibles tambin con el estndar
T.38 .
4.4.2.7 Alimentacin de los telfonos IP

En las redes telefnicas, los terminales reciben alimentacin de la central de conmutacin
publica del operador gracias a la corriente de bucle (-48V CC). Esta corriente se ve
garantizada siempre, puesto que las centrales telefnicas disponen de bateras y equipos de
emergencia para el caso de fallo de suministro elctrico. Sin embargo, en las redes de telefona
IP es necesario alimentar los telfonos 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 elctrica
de emergencia responsable de suministrar
servicio elctrico a la oficina, en caso de
interrupcin del servicio elctrico pblico. 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 telfono 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
Monitor
1,5
Telefono IP
TOTAL
9,5
9,5A * 115V = 1092,50va

Tabla 4. 23 Clculo de consumo Elctrico por Puesto de Trabajo
97
Asimismo, los servidores Asterisk deben estar protegidos por UPS On Line, que provea
alimentacin constante desde su batera y no de forma directa. Esta tecnologa es la que ofrece
el mayor nivel de proteccin, por lo tanto es ideal para equipos sensibles o importantes como
servidores centrales.
4.4.3 Estimacin de costos

En la table 4.24, se detallan todos los costos referentes al diseo de la solucin.
PRECIO
CANTIDAD
(BSF)
TOTAL (BSF)
Servidor IBM
5.100,00
40.800,00
Tarjetas AEX2400
9.438,00
37.752,00
Tarjetas AEX800P
4.128,00
20.640,00
PATCH PANEL CABLE AMPHENOL
840,00
3.360,00
ATA
85
432,00
36.720,00
Modulo expansion
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)
15.000,00
45.000,00
UPSservidores (3kva)
7.000,00
28.000,00
136
750,00
102.000,00
TOTAL BsF
375.712,00
ITEM
ups puestos trabajo (1kva)
Tabla 4. 24 Estimacin de Costos
4.4.4 Diseo del Plan de Discado (Dialplan)

El plan de discado es el responsable de la conmutacin de llamadas dentro de Asterisk. Es
similar a una tabla de enrutamiento: el usuario marca un nmero y el dialplan contiene las
acciones a realizar para ese nmero 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 lgicas de extensiones y se utilizan para dividir el dialplan en
diversos entes lgicos. Esta divisin es necesaria para hacer del dialplan mantenible. Cuando
Asterisk recibe una llamada, de entrada o de salida, esta pertenece a un contexto. A cul
contexto pertenece, depender del canal que vea la llamada.
El dialplan para Servinave permitir:
Trabajar con los patrones de marcado del pas.
Interconectarse con las sucursales empresa del grupo.
Que la llamada sea redirigida a travs de la PSTN, de manera transparente para el

usuario, cuando el lmite 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 segn las
opciones seleccionadas.
En caso de seleccionar la opcin 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 segn
las
autorizaciones (internas, locales, nacionales e internacionales).
Permitir pre-cargar nmeros (abreviados) y que todos, independientemente de la

autorizacin de la extensin, puedan marcarlos.
Cada extensin debe tener asignado su correspondiente voicemail.
Una vez que la llamada ha ingresado, reproducir msica 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: Interconexin con la Siemens (Hacer Llamadas desde Asterisk hacia

la Siemens)
o Grupo 3: Interconexin con la Siemens(Hacer llamadas desde la Siemens hacia
Asterisk)
o Grupo 4: Lineas directas PSTN (entrantes)
Descripcin
Rango
Cant.
digitos
Prefijo para tomar lnea PSTN
Prefijo para llamar a sucursales
2XX
Donde XX coincidir con el cdigo 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
Nmeros Abreviados para
3XX
4XX
Extensiones
500-599
Extensiones para
900-999
llamar a empresas del grupo

Nmeros Abreviados para
llamar a proveedores y clientes
administracin 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
diseo 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 Definicin de la Prueba

Las oficinas seleccionadas para realizar la prueba piloto fueron las oficinas de Caracas y de
Puerto Cabello, especficamente los departamentos de sistemas y administracin, de cada
oficina (total 7 personas). Se seleccionaron estas oficinas porque son las que disponen de
mayor ancho de banda.
El esquema de conexin que persigue
el diseo de la solucin, es sustituir las centrales
telefnicas actuales por servidores Asterisk, tal como se puede apreciar en la figura 4.3.
Figura 4. 3 Esquema de Interconexin de la Propuesta
102
Sin embargo, por ser una prueba piloto, cada oficina interconectar el servidor Asterisk con
la central telefnica Siemens existente, a travs de puertos FXS/FXO, tal como se puede
apreciar en la figura 4.4.
Figura 4. 4 Esquema de Interconexin de la Prueba Piloto
En lneas generales, la configuracin a realizar en la prueba piloto se puede resumir como

sigue:
1. Reproducir, en la medida de lo posible, la actual configuracin 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 travs 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 interconexin por las
103
llamadas Siemens-Asterisk y viceversa.

5. Definir lneas de entrada tambin 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 lnea, y ya se haya alcanzado el lmite mximo destinado para
cursar llamadas por el enlace, configurar para que tome automticamente una lnea de la
PSTN y haga la llamada al master de la oficina.
El Hardwarey Software seleccionado para la prueba piloto, se especifca a continuacin:
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 telefona DIGIUM analgicas modelos AEX2400, 20 puertos FX0 y 4

puertos FXS
Cancelador de eco por software MG2
Telfonos 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 lneas analgicas CANTV en cada oficina
Cuatro extensiones analgicas de la central Siemens en cada oficina.
Cuatro puertos troncales en la central Siemens de cada oficina.
4.5.2 Instalacin y Configuracin
En est actividad se fueron realizando las diferentes configuraciones necesarias para alcanzar
las funcionalidades requeridas.
104
4.5.2.1 Creacin 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 caracterstica voiceVlan para que el switche asignara
automticamente los paquetes de voz a la Vlan 10, en aquellos puertos que son compartidos
por el PC y el telfono. Aquellos telefonos IP que estan directamente conectados al switch,
como solo envan paquetes de voz, el modo de asignacin fue manual.
En cada switche se realiz los siguientes pasos:
Se cre la VLAN 10.
Se agreg la MAC Address del telfono 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
adems:
o Se asign por defecto la VLAN 1
o Se permiti el trfico de la VLAN 10
o Se habilit la voiceVLAN
Se cre las rutas estticas 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 Instalacin del Sistema Operativo GNU/Linux (CentOS 5.3)

A continuacin se enumeran los pasos realizados para instalar la distribucin de Linux
CentOS en el servidor de Asterisk.
Se habilita la opcin 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 instalacin en modo grfico.
Se selecciona OK para realizar validacin del CD de instalacin, o SKIP para

omitir la prueba.
105
Se selecciona el idioma de instalacin (Espaol).
Se selecciona el idioma del teclado (latinoamericano o Ingls EU).
Se selecciona Remover particiones en dispositivos seleccionados y crear disposicin

para formatear el disco y crear las dependencias del Sistema Operativo.
Seleccionar la opcin manual, colocar Nombre del Host: asterisk.XX.com.ve
Regin: Amrica / Caracas
Colocar clave de root
Desactivar la opcin Desktop Gnome y se habilita KDE Desktop
Seleccionar la opcin de personalizar la instalacin de componentes.
Eliminar en Aplicaciones: editores, grficos, internet basada en texto, juegos y

entretenimiento, oficina y productividad, sonido y video
Eliminar en Servidores, soporte para impresin.
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 instalacin.
Al finalizar la instalacin retirar el DVD y reiniciar la PC; al reiniciar el PC el sistema

solicitar una configuracin adicional.
Cortafuegos: seleccionar la opcin de deshabilitado.
SELINUX (Security Enhanced Linux): seleccionar la opcin deshabilitado.
Tarjeta de Sonido: No seleccionar nada.
CDs adicionales: No seleccionar nada y reiniciar.
En caso de no haber instalado las libreras requeridas para compilar el cdigo de Asterisk al
momento de realizar la instalacin del sistema operativo se pueden introducir los siguientes
comandos en una cnsola del equipo (debe disponerse de conexin 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 nmero de la
interfaz) y configurar los parmetros 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
192.168.30.16
192.168.32.16
GW
Tabla 4. 26 Parmetros TCP/IP a Configurar
4.5.2.3 Instalacin de los Servicios de Telefona

a) Obtener los archivos de instalacin 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 cdigo 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 Compilacin Paquete Asterisk
4.5.2.4 Instalacin de las tarjetas de Telefona

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 bitcora. 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, tambin 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 mdulo de hdaintel con el comando: rmmod snd-hda-intel (que es el driver del dispositivo hda-intel).
Para que no se cargue en el prximo reinicio del servidor, se
edit el archivo
/etc/modprobe.d/blacklist y se agreg al final la lnea : blacklist snd-hda-intel (ver figura 4.8).
De acuerdo al documento PC Card Common Instalations Issues de Richard Spencer, se

realizaron tambin los siguientes ajustes:
Se deshabilit la interface grfica (en el archivo de configuracin /etc/inittab, se asign

el 3 como nivel de arranque: id:3:initdefault).
Se deshabilit el framebuffer (en el archivo de configuracin del gestor de arranque

/boot/grub/menu.lst se agrego la lnea vga=normal).
Se asign el IRQ de la tarjeta Digium al procesador 1 mediante la instruccin echo 2

> /proc/irq/169/smp_affinity. Asi las peticiones de esta tarjeta sern 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 instruccin en cuestin.
Figura 4. 8 Sin Compartir Interrupciones
4.5.2.5 Archivos de Configuracin de Asterisk

4.5.2.5.1 Configuracin de DAHDI
Se deben configurar dos archivos:
/etc/dahdi/system.conf (ver tabla 4.28)
/etc/asterisk/chan_dahdi.conf (ver figura 4.9).
PARAMETRO
DESCRIPCIN
loadzone=ve
loadzone permite configurar el canal para que utilice las indicaciones de tonos como
defaultzone=ve
el marcado, ocupado, etc. Para el pas 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 utilizarn sealizacin fxs, bajo el protocolo
Kewlstart (ks)
Fxoks=21-24
Indica que los canales
del 21-24 utilizarn sealizacin 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 parmetros habilitados en el archivo chan_dahdi son:
busydetect (yes/no): Con esta opcin habilitada, Asterisk escuchar el tono de

ocupado cuando el proveedor del servicio lo mande.
busycount (Nmero): Es el nmero 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/ nmero entero) Habilita o no la cancelacin de eco. Tambin

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 nmero de canales ser tratados como uno, para propsitos 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 msica 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 verificacin

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 configuracin 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 interrupcin. Es comn los problemas

de calidad de audio por causa de conflictos y prdidas de interrupcin. El nmero de
interrupciones no debe ser peor que 99,987793%, segn 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 Configuracin de canales SIP

La configuracin 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 seccin se define por un nombre entre corchetes seguido de las opciones de dicha
seccin.
Como se puede apreciar en la tabla 4.29, la primera seccin, identificada como general, define
las opciones generales del servidor como la direccin IP y el puerto al que hacer el bind, es
decir, el puerto donde Asterisk escuchar a las llamadas entrantes. Las siguientes secciones
definen parmetros del cliente como el username, password u otras.
PARMETRO
DESCRIPCION
[general]
Seccin donde se definen variables globales y aspectos por defecto para todos
los canales SIP.
language=es
Seleccin del lenguaje espaol.
dtmfmode= rfc2833
Permite especificar el mtodo por el cual se enviaran los tonos (dgitos pulsados
durante la conversacin). El parmetro AUTO indica que debe negociar con el
par del otro extremo. rfc2833 permite mandar os tonos dtmf como RTP
port=5060
Puerto de conexin por donde el servidor aceptar la conexin
bindaddr=0.0.0.0
El servidor recibir conexiones en todas sus interfaces
srvlookup=yes
Parmetro 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 Seccin General del Archivo Sip.conf
A continuacin de la seccin general, se define cada cliente SIP, el cual esta identificado por
un bloque de texto con un nombre encerrado entre corchetes (tpicamente la extensin). Los
parmetros empleados se resumen en la tabla 4.30.
115
PARMETRO
DESCRIPCION
[530]
Nmero de extensin del cliente.
callerid="Adriana
Identificacin del Llamante
Sanchez" <530>
type=friend
Tipo de cliente SIP. Puede tomar el valor de: Friend: Puede tanto recibir como realizar
llamadas a travs del sistema Asterisk. User: Puede recibir llamadas mas no puede hacer
llamadas. Peer: Pueden hacer llamadas pero no pueden recibir llamadas a travs del
sistema Asterisk
context=phones
Contexto por defecto donde ingresarn las llamadas entrantes. Este contexto se define en
extensions.conf
host=dynamic
El host tiene direccin dinmica
secret=1234
Password de sesin
callgroup=1
Le asigna un grupo a la extensin. Ejemplo: es miembro del grupo 1
pickupgroup=1
De que grupo puede hacer captura esta extensin. 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 comunicacin con otra localidad se coloca iLBC. Gsm para escuchar
los mensajes grabados
canreinvite=no
Tipicamente NO si se encuentrra destrs de un NAT. De este modo se habilita que el

trfico RTP pase por el servidor Asterisk.
call-limit=1
Nmero de llamadas simultneas que se pueden realizar en esa extensin
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 seales para un pas. Debe estar presente en el archivo indications.conf
Tabla 4. 30 Seccin 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
Departamento
Rango
Extensiones
Recepcin
500-509
Grupo
1
Multifuncionales
Salas Conferencia
Gerencia
510-514
Estadisticas
515-519
Mercadeo
520-529
Operaciones
530-539
Sistemas
540-549
Ofidemo
550-554
Cobranzas
555-560
10
Analisis
560-569
11
Contabilidad
570-579
12
Administracin
580-589
13
Tabla 4. 31 Extensiones y Grupos de Captura
4.5.2.5.3 Interconexin de servidores Asterisk

La interconexin de servidores Asterisk se realiz mediante el protocolo IAX2. Para realizar la
inteconexin, 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 parmetro register permite al servidor de Caracas registrarse en el servidor de Puerto

Cabello (servidor remoto), identificndose como usuario CCS01, para as poder recibir y hacer
llamadas o acceder a los servicios como buzn 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 verificacin

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 Verificacin de Registro
118
4.5.2.5.4 Instalacin del codec iLBC

Desde la versin 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 opcin 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 conversin de formatos (en milisegundos) para un
segundo de data .
119
4.5.2.5.5 Configuracin 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 conmutacin 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 tambin se puede hacer referencia a otros archivos, mediante la declaracin
#include <archivo>, si se desea dividir el dialplan en varios. Esta divisin se realiza entre
otras razones, para hacerlo mantenible.
En este proyecto, el dialplan se dividi en dos archivos de configuracin: 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 seccin [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 cnsola de Asterisk.
Writeprotect: Proteccin frente a escritura, si se deja como 'no' comandos como 'save
dialplan' modificaran los ficheros de configuracin.
Autofallthrough: Si est activada esta opcin, cuando una extensin haya acabado de
ejecutar sus prioridades, o la lgica salte a una prioridad inexistente, har que la
llamada se cuelgue, sealizandola como BUSY (ocupada), CONGESTION o
HANGUP dependiendo de cul sea la mejor opcin para Asterisk.
120
Clearglobalvars: con cada recarga de extensions.conf se recargarn las variables globales

de Asterisk. Si se desactiva las variables globales permanecern 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 ejecucin devuelve una prioridad.
Despus de estas dos secciones, estarn aquellos contextos que se necesitan para armar el
dialplan. Las dos reglas de oro de los contextos son:
Una extensin solo puede marcar a nmeros que estn dentro del mismo contexto.
El contexto de una comunicacin es definido por el canal de entrada de comunicacin

(ver figura 4.15).
Figura 4. 15 Flujo de Llamadas en Asterisk
1) Para trabajar con los patrones de marcado del pas, 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
posicin 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 travs del IVR se defini el contexto Entrantes. IVR
se refiere a los menes 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, segn 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 nmeros abreviados, entre extensiones
definidas en el servidor Asterisk local y de cualquier otra oficina de la empresa,
nmeros de informacin o emergencia de la PSTN (tales como 119, 155, 911, etc),
nmeros 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 ms todo lo definido en el contexto
SoloLocal.
d) SoloNacional: Permite llamadas de larga distancia nacional ms todo lo definido en el
contexto SoloLocal.
e) Nacional-Celular: Permite llamadas a celulares, de larga distancia nacional ms todo
lo definido en el contexto SoloLocal.
f) SinRestriccin: Permite llamadas internacionales ms 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 AbreviadosSucursales (prefijo 2XX), Abreviados-Blohm (prefijo 3XX) y Abreviados-Otros (prefijo
4XX) para que cualquier extensin pueda llamar a estos telfonos, independientemente de
las restricciones que posea.
5) Para limitar el nmero de llamadas simultneas 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 permita
el clculo), y si no es as , se hace una llamada por la PSTN al mster de la oficina en
cuestin. 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 continuacin 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 mtodo estndar para realizar conferencias es con la aplicacin Meetme(). Para poder
hacer uso de esta aplicacin
se debi incluir sta en el archivo extensions.conf la
123
extensin 900 fue creada para la sala de conferencia, dentro del contexto conferencia, con
una contrasea predefinida que el usuario deber ingresar cuando desee hacer uso del
servicio.
7) Se cre el contexto voicemail, que define la extensin 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 (tambin recibir la notificacin y el mensaje por correo electrnico).
8) Se cre la extensin 922 dentro del contexto msica, a donde se llamar cuando se desee
evaluar la msica en espera.
9) Se cre el contexto parqueo que incluye la declaracin 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 mdulo de buzn de voz permite definir buzones para cada usuario, asi como compartir un
mismo buzon entre varios usuarios. Otra caracterstica interesante es que el servidor puede
enviar un correo electrnico avisando que se ha recibido un mensaje nuevo y adjuntar el
mismo como un anexo del correo.
Para la configuracin de estos buzones se debe editar el archivo voicemail.conf, que siguiendo
con la estructura habitual de los archivos de configuracin de Asterisk, contiene una seccin
general y distintas secciones para distintos contextos.
En la seccin general se puede definir el formato en que se van a grabar los mensajes (wav,
gsm, entre otros) o el formato de los correos electrnicos de aviso de nuevos mensajes. Para
definir el formato de los correos, se dispone de las siguientes variables:
VM_NAME: Nombre del propietario del buzn
VM_DUR: Duracin del mensaje
VM_MSGNUM: Nmero de orden de este mensaje
VM_MAILBOX: Buzn de voz
124
VM_CALLERID: Nombre y nmero de la persona que ha llamado.
VM_CIDNUM: Nmero 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 buzn
;
${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\tCentral 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 relacin
con los contextos definidos en el plan de marcado (dialplan) , sino que son una forma de
separar buzones. Especficamente para Servinave, fue suficiente con tener un nico contexto
default con todos los buzones.
El formato utilizado para definir cada buzn es:

Extensin => contrasea, nombre usuario, email, buscapersonas usuario,opciones
125
Se definieron los siguientes parmetros para cada buzn : contrasea, nombre y correo
electrnico. Ejemplo:
[default]
571 => 1234, Adriana Sanchez, asanchez@servinave.com
En el archivo sip.conf se hace referencia a este buzn con el parmetro 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 (segn 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 opcin (o un nmero de

extensin)
Background (sonido): Reprodcr un sonido, pero el usuario puede interrumpir la

reproduccin, tecleando un nmero de opcin. Sera equivalente a utilizar las
aplicaciones Playback y WaitExten de forma simultnea.
GotoIfTime(hora|dia_semana|dias_mes|ao?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 opcin, el tiempo mximo permitido entre
dgitos 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 opcin y salatar a esa
extensin (u opcin). Si no existe saltar a la extesin i.
Por otra parte, si el usuario no empieza a teclear una opcin en el tiempo indicado en
TIMEOUT(response), el IVR saltar a la extensin t.
Asterisk usa algunos nombres de extensin para propsitos especiales. A continuacin se

indica cules son estas extensiones y cul es su significado:
i: Invalid: Usado cuando se disca una extensin 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 informacin 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 accin.
T: AbsoluteTimeout. Usado para llamadas que hayan sido colgadas debido a que las alcanz
el AbsoluteTimeout(). Es ltil, por ejemplo, para hacer sonar una notificacin Playback()
i: Invalid: Usado cuando se disca una extensin 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 buzn 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 cul 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 estticas, porque estn 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 distribucin 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 configuracin
A parte de los archivos mencionados, tambin fue necesario modificar otros para
complementar las funciones que se perseguan en plan de marcado.
Hay dos tipos de transferencia, la directa (blindxfer) y la asistida (atxfer). Los

parmetros 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 parmetro 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 botn que permite
realizar la transferencia de llamadas directamente sin utilizar la secuencia de teclas
mencionadas.
En este mismo archivo features.conf, en la seccin general, se
cambiaron los
parametros: parkext => 700 y parkpos => 701-720, que corresponden a la extensin
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 924940 respectivamente.
Para crear las salas de conferencias, aparte de incluir la aplicacin meetme en el

archivo extensions.conf, se debi crear la sala de conferencia en
meetme.conf . En la seccin rooms, se colocaron
el archivo
las salas que seran accedidas
marcando las extensiones definidas en el archivo extensions.conf.
Para activar la msica en espera se debe editar el archivo chan_dahdi.conf y colocar

dentro de la seccin [channels], musiconhold=default. Si se desea personalizar la
msica en espera, se debe editar el archivo musiconhold.conf.
130
Se crearon las colas estticas de atencin del IVR en el archivo queues.conf, para
dirigir las llamadas atendidas por ste al departamento seleccionado, segn la opcin
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).
Despus de realizar los cambios en estos archivos se recomienda reiniciar asterisk

4.5.2.6 Configuracin de los terminales de voz
Para dar inicio a las pruebas se configuraron los telefonos IP y un softophone para poder
establecer comparacin de calidad durante el perodo de prueba.
4.5.2.6.1 Configuracin del hardphone Linksys SPA922
Para configurar, conectarse va http a la direccion IP del telfono. Para conocer la direccin IP
del telfono, como la misma fue asignada dinmicamente por el servidor DHCP, consltela
directamente desde el men del telfono.
Para este caso, la direccin asignada es 192.168.30.81, coloque entonces desde la barra de
direcciones del explorador http://192.168.30.81, seleccione la opcin Ext1 desplegada en la
parte alta del navegador. En la nueva pantalla configure los valores especificados en la tabla
4.33.
PARMETRO
VALOR
Proxy
192.168.30.24 (ip del servidor Asterisk al que desea conectarse)
Display Name
Adriana Sanchez
UserID
571 (numero extensin) definida en esip.conf
Password
1234 Coontrasea definida en sip.conf
Use DNS SRV
Yes
DNS SRV Auto Prefix
Yes
Tabla 4. 33 Configuracin 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 Configuracin 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 direccin IP
del servidor Asterisk, el numero de extensin asignada y el password. (ver figura
4.18).
Figura 4. 18 Crear Cuenta SIP
Activar la opcin de cancelacin de eco y seleccionar el headset VoIP en Input y

output device. Tambin se debe configurar como Ringing device, las cornetas del
equipo, para que pueda escuchar cuando una llamada entra an cuando no tenga el
headset puesto. (ver figura 4.19)
Figura 4. 19 Configuracin del Audio en Zoiper
Seleccionar los CODECs correspondientes. En este caso iLBC y aLAW (ver figura
4.20)
133
Figura 4. 20 Seleccin de CODECS
4.5.3 Revisin y Ajustes

A continuacin se mencionan los ajustes realizados al diseo original.
El archivo indications.conf que viene con la versin de Asterisk instalada, no contiene

los tonos correctos para Venezuela. Fue necesario
actualizar los tonos segn
informacin suministrada por CANTV.
Se habilit para que las llamadas a las extensiones Siemens fueran enrutadas sin
marcar el prefijo 7.
Se coloc la misma combinacin 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 extensin IP, la llamada era
transferida a travs de los canales FXS/FXO de la interconexin. 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, mantena 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 telfonos 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 distribucin precompilada de Asterisk TRIXBOX y
se comprob que es realmente sencillo configurar Asterisk a travs de la interfaz grfica
provista en la distribucin. Como se sabe, el objetivo de toda interfaz grfica es simplificar la
configuracin y gestin de una aplicacin (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 grfica se hace complejo por la cantidad de cdigo (macros, includes y variables) que
escribe la interfaz grfica en los archivos de configuracins para hacer una simple tarea
alusiva a una llamada. Despus de varios intentos de tratar de comprender los archivos de
configuracin generados, se procedi entonces a desinstalar TRIXBOX y a instalar el
sistema operativo CentOS y el Asterisk manualmente, para asi configurarlo directamente a
travs de los archivos de configuracin, paso a paso. Hacerlo de esta manera permit conocer
mejor todo lo que implicaba la configuracin realizada, lo que se traduce en mejor tiempo de
respuesta para el soporte en caso de fallas. No obstante, el trabajar con una interfaz grfica
ciertamente facilita y automatiza muchas tareas de configuracin, pero agrega una nivel mas
de complejidad al momento de resolver problemas.
La configuracin 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 mayora de los ajustes realizados al Dialplan correspondan a mejorar la experiencia del

usuario, ms que a una falla reportada.
135
Si el PC tiene
instalado un softphone y ejecuta
aplicaciones agresivas o pesadas,
simultnemente con una conversacin telefnica, la conversacin se entrecorta.
Las interfaces FXS/FXO utilizadas para la interconexin tendan en ocasiones a quedarse

inhibidas y era necesario resetearlas.
El que los usuarios no supieran
cuando estn 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 Anlisis de Resultados

La integracin de la red de voz y datos hace mas compleja la administracin 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 formacin) para esta rea. Asimismo, cualquier falla que ocurra en
la red afectar ambos servicios, lo que tradicionamelnte no suceda.
Desde el punto de vista humano, las pruebas realizadas con softphone permitieron conocer la
reaccin del usuario ante un eventual cambio. En algunos usuarios fue favorable y en otros no,
aunque inicialmente fueron receptivos con la idea. Esta situacin varia mucho de oficina a
oficina, pero, aunque el diseo propuesto sugiere hardphone, es posible mezclar el uso de
softphone y hardphone en la solucin, considerando siempre la actividad del usuario, para no
intevenir negativamente en el desenvolviendo de sus labores cotidianas.
Sin embargo, desde el punto de vista tcnico, el softphone es una aplicacin 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 parmetros
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 telfonos, es importante decir que, aparte de facilitar la comunicacin,

afectan considerablemente la percepcin del usuario acerca de la calidad de audio en un
sistema VoIP. La evaluacin y seleccin del telfono IP correcto como una parte integral de
la implementacin del sistema VoIP, permite definir una solucin completa optimizada, sin
importar si son mviles o se basan en escritorio. Adems 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 eleccin incorrecta de este elemento puede afectar
considerablemente el proyecto completo, asegurando el xito o el fracaso del mismo.
Desde el punto de vista econmico, Asterisk representa una actualizacin del rea de telefona
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
comparacin pequea, si Servinave deseara instalar un E1 para sustituir las lneas analgicas
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 ilgico invertir, hoy en da, en las centrales tradicionales.
137
CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
5.1 Conclusiones
Con la implementacin de este diseo, 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 tecnologa .
Se concluye que este diseo funciona y es conveniente para la empresa, pero depende en gran
medida en como se haga la implementacin y se tomen en cuenta las recomendaciones antes
de realizarlo.
5.2 Recomendaciones
Es necesario analizar los puntos suceptibles de ataques y hacer una valoracin inicial del
estado de la seguridad en las instalaciones VoIP, para no abrir brechas de seguridad, antes de
realizar la implementacin.
La alimentacin elctrica de respaldo es muy importante considerarla, sobre todo en las

sucursales, ya que el servicio elctrico en esas zonas no es tan estable como lo es en Caracas
y es un punto lgido en la implementacin de la solucin.
Aunque la reduccin del gasto telefnico se podr apreciar en la factura mensual del
proveedor de servicio, debe contemplarse la instalacin de una aplicacin que gestione la
tarificacin telefnica, pues para la empresa es sumamente importante tarificar este servicio
por extensin.
138
Es necesario revisar los ancho de banda contratados. Aqu solo se est cursando el trfico 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
tambin 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 fcilmente
mantenible.
Hay que tener especial cuidado en la implementacin. Es recomendable hacerla por etapas
para ir ajustando particularidades que surgan en cada oficina. La implementacin 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 telfonos IP que soporten esta caracterstica.
139
REFERENCIAS
Gomez, J y Gil F. (2008). VoIP y Asterisk Redescubriendo la Telefona. Primera edicin.
Almera: RA-MA
Goncalvez, F. (2007). Asterisk PBX Gua de Configuracin. Tercera edicin. Florianpolis:

ttulo independiente.
Van Meggelen, J., Smith, J. y Madsen, L (2007). Asterisk the Future of Telephony. Segunda
edicin.. Estados Unidos: OReilly Media, Inc.
Huidobro, J. y Roldn, D. (2006). Tecnologa VoIP y Telefona IP. Mxico: Alfaomega.

Stallings, W. (2004). Comunicaciones y Redes de Computadores. Sptima edicin. Madrid:
Pearson Educacin.
Tamayo y Tamayo, M. (1991). El Proceso de la Investigacin Cientfica. Mxico, Mxico.

Editorial Limusa.
Digium Inc. Digium 2400 series AEX2400/TDM2400P User Manual. Extrado el 24 de abril
de 2009, desde http://docs.digium.com/AEX2400/2400series_manual.pdf.
Spencer, R. (2008). PCI Card Common instalations issues. Extrado el 24 de abril de 2009
desde
http://www.novavox.co.uk/docs/install-guides/novavox-asterisk-card-installationissues.pdf.
Cisco System (2007). Traffic Analysis for VoIP v-3. Extrado 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. Extrado el 24 de enero de 2009 desde
http://www.digium.com/handbook-draft.pdf.
140
Silva, M. (2006). Gua de Configuracin e Instalacin de Asterisk . Extrado el 25 abril de

2009 desde http://www.moythreads.com/wordpress/?p=13.
Ganzbal, J. (2008). Clculo de Ancho de Banda en VoIP.Extrado 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 Poltica De Las Telecomunicaciones FMPT . Extrado el

23 de febreo de 2009 desde
http://www.itu.int/osg/spu/wtpf/wtpf2001/Chairreport/Chair%20report%20final%20Spanish.pdf.
Cota, J. (2009). Gua del curso VoIP y Telefona IP . Atel Consultores. Caracas.
Vilares, F. (2008). Gua del curso Bootcamp Asterisk . Netsecurity Solutions Bogot.
Fuenmayor, J. (2006) Gua de Sistemas de Telecomunicaciones. Universidad Central de

Venezuela. Caracas.
UNIVERSIDAD SIMON BOLIVAR

NOMBRE DEL ESTUDIANTE:
ADRIANA SNCHEZ BOUZAS
TITULO DE LA TESIS: DISEO DE UNA SOLUCIN DE TELEFONA IP BASADA EN

ASTERISK PARA SERVINAVE,C.A.
NOMBRE DEL ASESOR:
WILMER PEREIRA
MIEMBROS DEL JURADO: VIDALINA DE FREITAS / MONICA HUERTA

PALABRAS CLAVES:
SOBRESALIENTE:
N DE PAGS:
MAESTRA EN:
140
PBX, VoIP, Telefona IP, Convergencia de Redes, Software Libre

GRADUADO CON HONORES:
FECHA DE GRADUACIN:
RESUMEN
Servinave, C.A. es una empresa de servicios dedicada al agenciamiento naviero y consta

de una oficina central y siete sucursales ubicadas geogrficamente en estados distintos. El
sistema de comunicacin de voz que utiliza la empresa es telefona convencional a travs
de centrales telefnicas bsicas cuyos modelos, en general, ya estn descontinuados. Con
el auge de Internet se han desarrollado muchas aplicaciones, modelos, servicios y
tecnologas, entre ellas tenemos, Voz sobre IP, tecnologa sta que se desea aprovechar
para disear una solucin de Telefona IP basada en software libre, que le permita a
Servinave, C.A., desde el punto de vista tcnico, actualizar la plataforma de telefona e
integrar la infraestructura del cableado de voz y datos, garantizando un servicio confiable,
seguro, portable, de calidad y fcil gestin que simplifique las comunicaciones de la
empresa con sus sucursales y clientes. Desde el punto de vista econmico, se espera una
reduccin en los costos, manteniendo la calidad de servicio igual o superior a la
acostumbrada y la generacin de nuevos servicios, a un costo de inversin razonable. En
otras palabras, converger ambas formas de trfico sobre una sola red para restar gastos y
complejidad. Este diseo trabajar con una distribucin del Sistema Operativo GNU/
Linux y con el software de PBX Asterisk, por ser sistemas de fuente abierta ampliamente
aceptados en el mercado. La investigacin est enmarcada en la modalidad de proyecto
factible, y las etapas que se van a seguir van desde la formacin en la plataforma
Asterisk, diagnstico de la situacin actual, identificacin de los componentes de la red
convergente deseada hasta culminar con el diseo 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 SIMN BOLVAR

DECANATO DE ESTUDIOS DE POSTGRADO

TRABAJO ESPECIAL DE GRADO

DISEO DE UNA SOLUCIN DE TELEFONA IP BASADA EN

ADRIANA SNCHEZ BOUZAS

UNIVERSIDAD SIMN BOLVAR

DISEO DE UNA SOLUCIN DE TELEFONA IP BASADA EN

Trabajo Especial de Grado presentado a la Universidad Simn Bolvar por

Adriana Snchez Bouzas

Como requisito parcial para optar al grado acadmico de

Con la asesora del prof. Wilmer Pereira

UNIVERSIDAD SIMN BOLVAR

Este Trabajo Especial de Grado ha sido aprobado en nombre de la

16, Octubre, 2009

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.

UNIVERSIDAD SIMN BOLVAR

2.6 CODEC ............................................................................................................................19

2.8.3.1 Tramas o Mensajes IAX49

4.3.4 Clculo de Ancho de Banda....84

1. 1 Equipamiento de Telefona de Servinave.............................................................................4

4. 16 Consumo de Codecs Seleccionados ................................................................................85

2. 1 Jerarqua de nodos de conmutacin...................................................................................11

4. 6 Salida del Comando cat /proc/interrupts ........................................................................108

LISTA DE SMBOLOS Y ABREVIATURAS

ADSL Asymmetric Digital Subscriber Line ( Lnea de Suscripcin Digital Asimtrica).

Consultivo Internacional de Telefona y Telegrafa).

IRQ Interrupt ReQuest ( Peticin de Interrupcin) .

Voice over IP (Voz sobre IP).

Todo esto implica un cambio en la forma de comunicarnos. Las grandes compaas ms

Internet simboliza, ms que cualquier otro fenmeno, la naturaleza evolutiva de las

anchos de banda, la estandarizacin de protocolos

consolidar aplicaciones de Telefona IP a costos moderados que pueden ser

1.1 Planteamiento del Problema

El sistema de telefona que utiliza la empresa es el tradicional, inclusive para comunicarse

En cuanto a equipamiento, se dispone de varios modelos de centrales digitales, tal como se

Tabla 1. 1 Equipamiento de Telefona de Servinave

garantiza la asistencia tcnica de las mismas, lo que obliga a pensar en

actualizar la plataforma de telefona de un momento a otro.

La plataforma de telefona de Servinave, C.A. est obsoleta y aprovechar la tecnologa de Voz

De las propuestas y alternativas existentes en el mercado, se ha seleccionado Asterisk como

problemas e implantacin de mejoras es bastante gil. Esta combinacin contribuir a

1.3 Objetivos del Trabajo

1.3.2 Objetivo Especficos

Una red conmutada es un conjunto de nodos interconectados entre s, a travs de medios de

2.1.1 Conmutacin de Circuitos

La conmutacin de circuitos implica que los equipos de conmutacin deben establecer un

la de destino. En esta etapa, dependiendo de la tecnologa utilizada, se pueden establecer la

2.1.2 Conmutacin de Paquetes

En los sistemas basados en conmutacin de paquetes, la informacin/datos a ser transmitida

En la tcnica de datagramas, cada paquete se trata de forma independiente sin referencia

alternativas ante la eventual indisponibilidad de algunos nodos de conmutacin de la red,

En la tcnica de circuitos virtuales, se establece una conexin lgica antes de proceder a la

No hay reserva de recursos

No existen bits suplementarios

en la transmisin una vez

paquete (menos que en

Poco adecuado para las

Poco adecuado para las

Tabla 2. 1 Comparacin de Tcnicas de Conmutacin

2.2 Descripcin General de la Red Telefnica Convencional

La PSTN constituye la principal red de telecomunicaciones, permite que usuarios separados

Una de las funciones principales que se realiza en la red telefnica es la de conmutacin, a