instalación de una ip pbx en el departamento de...
Post on 26-Sep-2018
216 Views
Preview:
TRANSCRIPT
Instalación de una IP PBX en el
Departamento de Telemática de la
E.S.I de Sevilla.
Alejandro Calo Casanova
22 de febrero de 2007
Índice general
1. INTRODUCCIÓN. 5
1.1. TELEFONÍA TRADICIONAL. . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. ORIGENES DE LA VoIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. INCONVENIENTES DE LA TELEFONÍA IP. . . . . . . . . . . . . . . 8
1.4. PBX TRADICIONALES VERSUS IP PBX. . . . . . . . . . . . . . . . . 8
1.5. SOFTWARE LIBRE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. MOTIVACIONES Y OBJETIVOS. 11
2.1. MOTIVACIONES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. OBJETIVOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. LA VoIP. 14
3.1. INTRODUCCIÓN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. TRANSMICIÓN DE VOZ SOBRE REDES IP. . . . . . . . . . . . . . . 16
3.2.1. MUESTREO Y DIGITALIZACION . . . . . . . . . . . . . . . . . 17
3.3. EL PROCESO DE CODIFICACIÓN DE LA VOZ. . . . . . . . . . . . . 18
3.3.1. EMPAQUETADO . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2. MULTIPLEXACIÓN. . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. COMPRESIÓN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.4. CODECS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.5. TASA DE PAQUETIZACIÓN DE LOS CODECS. . . . . . . . . 23
3.3.6. SISTEMAS DE TRANSIMISIÓN DTX/VAD/CNG. . . . . . . . 25
3.4. EL ESTANDAR VoIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1. PROTOCOLOS DE SEÑALIZACIÓN DE VoIP. . . . . . . . . . 27
3.4.2. EL PROTOCOLO H.323. . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2.1. ARQUITECTURA . . . . . . . . . . . . . . . . . . . . . 29
3.4.2.2. TORRE DE PROTOCOLOS . . . . . . . . . . . . . . . 32
3.4.2.3. ESQUEMA DE DIRECCIONES E.164 . . . . . . . . . . 38
2
Índice general
3.4.3. EL PROTOCOLO SIP. . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.3.1. ARQUITECTURA. . . . . . . . . . . . . . . . . . . . . 40
3.4.3.2. DIRECCIONAMIENTO SIP: SIP-URI. . . . . . . . . . 43
3.4.3.3. MÉTODOS SIP Y RESPUESTAS. . . . . . . . . . . . 43
3.4.4. EL PROTOCOLO IAX. . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.5. LOS PROTOCOLOS MEGACO Y SIGTRAN . . . . . . . . . . . 49
4. ASTERISK. 51
4.1. INTRODUCCIÓN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1. CENTRALITAS o PBX. . . . . . . . . . . . . . . . . . . . . . . . 52
4.2. ARQUITECTURA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1. INTERFACES Y CANALES. . . . . . . . . . . . . . . . . . . . . 57
4.2.2. ORGANIZACIÓN DE LOS FICHEROS. . . . . . . . . . . . . . . 57
4.3. CONFIGURACIÓN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.1. EL PLAN DE MARCADO. . . . . . . . . . . . . . . . . . . . . . 61
4.3.2. INTERFACES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2.1. INTERFACES TRADICIONALES. . . . . . . . . . . . . 63
4.3.2.2. INTERFACES SIP. . . . . . . . . . . . . . . . . . . . . . 64
4.3.2.3. INTERFACES IAX. . . . . . . . . . . . . . . . . . . . . 64
5. DESARROLLO. 67
5.1. DESCRIPCIÓN DETALLADA DE LA SOLUCIÓN. . . . . . . . . . . . 67
5.1.1. ENTORNO DE TRABAJO. . . . . . . . . . . . . . . . . . . . . . 67
5.1.2. ARQUITECTURA LÓGICA DE LA RED. . . . . . . . . . . . . 68
5.1.3. ARQUITECTURA FÍSICA DE LA RED. . . . . . . . . . . . . . 69
5.1.4. ELEMENTOS FUNCIONALES DEL SISTEMA. . . . . . . . . . 70
5.2. FASES DEL DESARROLLO . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1. PUESTA EN FUNCIONAMIENTO DEL SISTEMA DE TELE-
FONIA IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1.1. DESCRIPCIÓN DEL SOFTWARE A USAR. . . . . . . 72
5.2.1.2. DEPENDENCIAS DEL SOFTWARE ASTERISK. . . . 73
5.2.1.3. DESCARGA DEL SOFTWARE ASTERISK. . . . . . . 74
5.2.1.4. COMPILACIÓN DEL CÓDIGO FUENTE. . . . . . . . 75
5.2.1.5. CONFIGURACIÓN DEL SISTEMA DE VoIP. . . . . . 79
5.2.2. MODIFICACIÓN DE LA INTERFAZ GRÁFICA DE ADMINIS-
TRACIÓN DEL SISTEMA. . . . . . . . . . . . . . . . . . . . . . 81
3
Índice general
5.2.2.1. DESCRIPCIÓN DEL SOFTWARE. . . . . . . . . . . . 82
5.2.2.2. INSTALACIÓN DE LA INTERFAZ. . . . . . . . . . . . 88
5.2.2.3. MODIFICACIÓN DEL FLASH OPERATOR PANEL. . 90
5.3. INTEROPERABILIDAD H.323. . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.1. OBJETIVOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.2. ARQUITECTURA DE RED. . . . . . . . . . . . . . . . . . . . . 104
5.3.3. DESCRIPCIÓN DE LA SOLUCIÓN. . . . . . . . . . . . . . . . . 106
5.3.3.1. CONFIGURACIÓN DEL GATEWAY TELDAT. . . . . 106
5.3.3.2. CONFIGURACIÓN DE LA CENTRALITA ASTERISK. 112
5.4. BATERIA DE PRUEBAS. . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.4.1. INTRODUCCIÓN AL ENTORNO DE PRUEBAS. . . . . . . . . 114
5.4.2. LISTA DE PRUEBAS. . . . . . . . . . . . . . . . . . . . . . . . . 115
5.4.2.1. Pruebas entre terminales que usan señalización SIP. . . . 118
5.4.2.2. Pruebas entre terminales que usan señalización IAX. . . 118
5.4.2.3. Pruebas entre terminales con distinta señalización (IAX
, SIP y H.323). . . . . . . . . . . . . . . . . . . . . . . . 119
5.5. PUESTA EN MARCHA DEL SISTEMA DE TELEFONIA IP EN EL AIT.121
5.5.1. CONFIGURACIÓN DE LOS TERMINALES TELEFÓNICOS. . 121
5.5.2. CONFIGURACIÓN EN EL LADO DEL SERVIDOR ASTERISK. 124
5.5.3. ASIGNACIÓN DE NÚMEROS TELEFÓNICOS. . . . . . . . . . 128
5.5.4. PLAN DE MARCADO. . . . . . . . . . . . . . . . . . . . . . . . 129
6. CONCLUSIONES Y LÍNEAS FUTURAS. 132
6.1. CONCLUSIONES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.2. LÍNEAS FUTURAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7. BIBLIOGRAFIA 135
4
1 INTRODUCCIÓN.
1.1. TELEFONÍA TRADICIONAL.
Desde sus inicios, las redes empleadas para transmitir nuestras conversaciones tele-
fónicas han estado basadas en una misma infraestructura: la conmutación de circui-
tos,caracterizada por la reserva de capacidad y recursos a lo largo del trayecto de la
comunicación.
El uso de sistemas de conmutación de circuitos estaba justi�cado por una buena razón:
hasta los años sesenta, el único tipo de trá�co que circulaba por estas redes era trá�-
co telefónico. La reserva de recursos garantiza un retardo aceptable, y la multiplexión
estadística de las fuentes asegura un buen aprovechamiento de esos recursos.
Con la irrupción de los ordenadores personales, el mismo mecanismo de transmisión de
voz comenzó a ser empleado para la comunicación de información digital, si bien de
forma algo forzada. Apareció el módem analógico, que durante años ha sido el principal
método para transmitir datos sobre la red pública. Al contrario que la comunicación de
voz, la de datos se caracteriza por una fuerte variabilidad. La transmisión se realiza a
ráfagas (secuencias cortas de alta intensidad), estando el canal desocupado durante una
parte importante del tiempo. En estas condiciones, la reserva de recursos permanente
durante toda la conexión es excesiva e incurre en un coste innecesario.
Progresivamente, la red telefónica emprendió su cambio hacia una nueva infraestructu-
ra digital, aunque todavía basada en conmutación de circuitos. La voz se transportaba
en forma de un �ujo digital hasta llegar a las centrales locales, donde se realizaba una
conversión analógica para su transmisión por el bucle de abonado, que se resistió a la
digitalización por motivos de coste. Puesto que el bucle local seguía siendo analógico,
la transmisión de datos sobre la RTC seguía teniendo en el módem su principal meca-
nismo. Este esquema estaba bastante aceptado y funcionó razonablemente bien, hasta
5
1 INTRODUCCIÓN.
que cantidades de carga crecientes comenzaron a inundar la red pública debido al rápido
crecimiento del fenómeno Internet.
La solución proporcionada hasta ahora ha sido la evolución de una nueva red digital de
conmutación de paquetes que pueda en caminar el trá�co de datos de forma separada,
manteniéndolo aparte del trá�co de voz, y la utilización de nuevas tecnologías de bucle
local, desde módems de cable a xDSL, que aparte de la ventaja del mayor ancho de
banda, ofrecen acceso directo a Internet sin necesidad de ocupar recursos destinados a
voz.
Con el panorama descrito arriba, la industria de las telecomunicaciones se encuentra en
estos momentos con dos redes: una para voz, y otra para datos.
1.2. ORIGENES DE LA VoIP.
En su nacimiento, la VoIP estaba dirigida básicamente al mundo empresarial: se presen-
taba como una alternativa económica e integradora a la red de voz tradicional, mediante
el establecimiento de comunicaciones telefónicas a través de redes de área local, y la
capacidad de hacer que éstas interoperaran con la RTC
La busqueda de soluciones que les permitan aumentar la competitividad de la empresa
a costa de aprovechar al máximo la inversión en infraestructura, hace que la posibilidad
de volver a utilizar una única red para el transporte de ambos tipos de trá�co se torne
muy atractiva. Ahora bien, la conmutación de circuitos ha demostrado su ine�ciencia
para el transporte de datos; el desperdicio de recursos supone un desaprovechamiento
de la inversión realizada, algo en lo que estas empresas no están dispuestas a incurrir.
Por el contrario, la conmutación de paquetes, basada en la compartición del ancho de
banda, permite un uso óptimo de los recursos disponibles. Por lo tanto, la alternativa al
empleo de dos redes separadas pasa por el transporte de voz sobre una arquitectura de
este tipo.
A todo esto, se le une una serie de inconvenientes presentes en los sistemas de telefonía
tradicional, junto a las ventajas complementarias que ofrecen los sistemas basados en
VoIP:
Limitaciones de la telefonía tradicional
6
1 INTRODUCCIÓN.
1. Altos costos en equipos de telefonía empresarial. A pesar de que la compe-
tencia en el mercado ha hecho caer los precios, las PBX tradicionales se han
caracterizado por sus altos costos de adquisición y expansión.
2. Lentitud para desarrollar e implementar nuevos servicios. Debido a su alta
dependencia del hardware, la implementación de nuevos servicios de valor
agregado es lenta y costosa en la telefonía tradicional. Si una empresa tiene
una PBX tr adicional y quiere agregarle capacidades para correo de voz o
algún otro nuevo servicio, deberá hacer una fuerte inversión de dinero para
adquirir el módulo respectivo.
3. Capacidad proporcional a la infraestructura instalada. A pesar de que el dise-
ño de la RTPC asegura un buen trabajo en el establecimiento de los circuitos
o caminos necesarios para realizar una comunicación entre dos abonados, el
hecho de que el circuito esstablecido debe ser exclusivo para una llamada du-
rante el tiempo que esta dure, hace que se subutilicen los recursos y no se
aprovechen las lecciones aprendidas de las redes de datos con la transmisión
de paquetes.
Ventajas de la Telefonía IP:
1. Los dispositivos de VoIP son más fáciles y menos costosos de mantener ya que
están soportados sobre la red de datos, en lugar de su propia red exclusiva
para voz.
2. Integrar la telefonía con el computador es mucho más sencillo con la Telefonía
IP.
3. La Telefonía IP incrementa la relación costo/bene�co de las redes de datos
de las empresas, aprovechando sus bene�cos para conseguir escalabilidad,
movilidad y ahorro.
4. Permite un control más centralizado que las PBX tradicionales.
5. La mayoría de los equipos de telefonía tradicional pueden ser integrados a
sistemas de Telefonía IP, permitiendo aumentar su ida útil y preservando la
inversión realizada en su adquisición.
7
1 INTRODUCCIÓN.
1.3. INCONVENIENTES DE LA TELEFONÍA IP.
El retardo de tránsito, y las pérdidas de paquetes debido a congestiones momentáneas
de la red (provocadas por la naturaleza impredecible, a ráfagas, del trá�co de datos),
son los principales inconvenientes que presenta la VoIP. Todo ello resulta en una pérdida
apreciable de la calidad de la comunicación. Un incremento del ancho de banda es un
primer paso esencial en el camino hacia la resolución de los problemas de latencia, sin
embargo, no es el único. El trá�co en Internet aumenta en la misma proporción al
incremento de ancho de banda tan pronto como éste es añadido, de manera que esto no
supone una salida.
Son imprescindibles nuevas medidas que resulten en la provisión de garantías acerca de
la calidad del servicio prestado por la red.
1.4. PBX TRADICIONALES VERSUS IP PBX.
Las compañías han estado frustradas en el pasado debido a inversiones en sistemas PBX
de propiedad, que las han atrapado en una tecnología que se convierte obsoleta.
Este hecho también ha frenado la innovación de servicios por parte de los usuarios al ser
plataformas completamente cerradas. Son sistemas caros en los que el usuario no solo
paga por el hardware sino que también debe pagar por licencias de uso por usuario de
cada aplicación.
Las compañías pueden evadir los obstáculos que presentan los sistemas PBX basados
en hardware, tradicionales y de propiedad, seleccionando soluciones de comunicaciones
IP, que se basan en una arquitectura abierta y �exible, implementada en software, que
permite a las empresas escalar de sitios únicos y pequeños a sitios grandes y múltiples.
Las compañías no tienen que invertir en una nueva infraestructura, pero, en su lugar,
aumentan la red de datos que ya tienen para sus sistemas de información y computación.
Los sistemas privados de telefonía IP ( IP PBX) cada vez obtienen una mayor cota de
mercado gracias al menor coste respecto a los sistemas tradicionales y la facilidad de
incorporarles nuevas aplicaciones.
8
1 INTRODUCCIÓN.
El núcleo de estos sistemas de telefonía IP no es hardware sino software y está basada
en estándares. Esto permite el desarrollo de aplicaciones y servicios muy rápidamente y
con un bajo coste para adaptarse a las necesidades de la empresa. Otros servicios con las
mismas características como las aplicaciones web y el e-mail ha revolucionado el entorno
empresarial debido en gran medida a la innovación constante en aplicaciones y servicios
impulsados principalmente por los propios usuarios. También facilita la interacción con
otros sistemas software existentes. Todo ello recibe el nombre de CTI (Computer Telep-
hony Integration) y un uso adecuado en la empresa se puede traducir en un aumento de
productividad.
1.5. SOFTWARE LIBRE.
En 1991 Linus Tolvards hizo público un kernel basado en el sistema operativo UNIX
para ordenadores con procesadores 386 de Intel. No tardó en unirse al proyecto GNU de
la Free Software Foundation adoptando una licencia GPL (Generic Public License). El
kernel es el núcleo del sistema operativo, pero por sí solo no forma un sistema operati-
vo. Numerosos programadores colaboraron en este proyecto haciendo crecer el sistema
operativo Linux junto al aprovechamiento del software libre existente para Unix.
La �losofía del software libre se de�ne con las siguientes libertades:
Libertad de poder usar el programa con cualquier propósito.
Libertad de poder estudiar como funciona el programa y adaptarlo a las necesida-
des propias.
Libertad de distribuir libremente el software.
Libertad que permite mejorar el programa y hacer públicas las mejoras en bene�cio
de la comunidad. El acceso al código fuente es imprescindible para asegurar esta
libertad
La licencia GPL pone por escrito esta �losofía. Promover la copia y conocimiento del
código tiene como objetivo mejorarlo y adaptarlo a las necesidades.
9
1 INTRODUCCIÓN.
La empresa está perdiendo el miedo a utilizar software libre en sus negocios.Prueba de
ello es que algunas administraciones públicas han sustituido sus sistemas Microsoft por
sistemas Linux. En el mercado de los servidores web Apache (open source) tiene el 60%
del mercado frente al 27% de Microsoft.
Figure 1.1: Sistemas de software libre.
El software libre abre la posibilidad de creación de nuevos modelos de negocio. El software
propietario es un producto por el que se debe pagar mientras que el libre se adquiere de
modo gratuito. La primera impresión es que no es posible hacer negocio con él. La �losofía
open source es que el software no es un producto sino un servicio. Está idea además
coincide con las necesidades de una empresa, ya que generalmente no desea comprar
simplemente una caja en la que viene empaquetado un software, sino que también quiere
obtener un servicio.
10
2 MOTIVACIONES Y
OBJETIVOS.
2.1. MOTIVACIONES.
Según lo comentado anteriormente en la introdución, puede verse la viabilidad, �exibi-
lidad y extensibilidad que presenta la implantación de un sistema de telefonía IP allí
donde sea necesario la comunicación entre múltiples o�cinas o donde se necesite reem-
plazar sistemas de comunicaciones tradicionales, operando bajo una arquitectura de red
que no presente limitaciones de ancho de banda, como es el caso de una red área local.
Es en este contexto donde se va centrar dicho proyecto �n de carrera. Se va a dotar
al laboratorio de VoIP del departamento de Telemática de la Universidad de Sevilla
de las herramientas necesarias para la implementación de un sistema que permita la
comunicación entre las distintas sedes del departamento, laboratorio y despachos de
profesores, con la posibilidad de marcado al exterior, así como la gestión de dicho sistema
a través de una interfaz grá�ca de fácil acceso para el usuario. De esta forma se hace
un mejor aprovechamiento de los recursos de red, permitiendo que el nuevo sistema de
comunicaciones sea puesto en marcha sin modi�car la infraestructura existente y sin que
suponga coste alguno. Además el sistema pretende ser una herramienta de trabajo para
probar la calidad que posee un sistema de comunicaciones IP escalable, de forma que
pueda plantearse en un futuro próximo la migración hacia una arquitectura puramente
IP y su interoperabilidad con las redes telefonía tradicionales.
De esta forma, una vez implantado el sistema de comunicaciones, permitirá que un ad-
ministrador de red, vía interfaz web, con�gure los distintos parámetro propios de una
centralita IP: codecs, videoconferencias, llamada en espera, buzón de voz, etc. Permi-
tiendo así recrear distintos escenarios de comunicación y evaluar la calidad del sistema
en cada situación:
11
2 MOTIVACIONES Y OBJETIVOS.
Se podrá evaluar la calidad de diferentes codecs de voz, así como permitir que los
dos extremos de la comunicación usen codecs diferentes.
Permitirá ver el comportamiento de los diferentes protocolos de señalización exis-
tentes: SIP, H.323 y IAX.
Se podrá ver como in�uye la hetereogenidad de redes en la calidad de la comuni-
cación.
En de�nitiva, el proyecto, a parte de dotar al departamento de Telemática de una red
de telefonía IP, se presenta como una herramienta válida para poner de mani�esto las
ventajas e inconvenientes de la tecnología IP, así como ofrecer una base sobre la cual se
pueda observar y estudiar el comportamiento de nuevas características relacionadas con
la tecnología de VoIP.
2.2. OBJETIVOS.
El objetivo de este proyecto es implantar un sistema de telefonía IP bajo el área del
departamento de Telemática, basado en un entorno centralizado donde todas las comu-
nicaciones sean gestionadas por una central telefónica IP de caracter no propietario,
basada en el software libre Asterisk y dotada con una interfaz grá�ca que permite su ad-
ministración y monitorización. Además se pretende la interoperabilidad de dicho sistema
con el sistema de telefonía RDSI.
Para lograr tal objetivo, el desarrollo del proyecto de ha dividido en varias fases:
1. Puesta en funcionamiento del sistema de telefonía IP.
2. Adaptación de la interfaz grá�ca de administrador a las exigencias del laboratorio.
3. Interoperabilidad de los sistemas de telefonía IP y telefonia tradicional RDSI.
Para poner en marcha el sistema de telefonía se hará uso de aplicaciones ya desarrolladas,
no sujeta a restricciones de licencias propietarias. Tal es el caso del servidor Asterisk y de
los terminales telefónicos o "softphones", que operaran bajo los protocolos SIP y IAX.
12
2 MOTIVACIONES Y OBJETIVOS.
La adaptación de la interfaz grá�ca, se basará en la modi�cación del código fuente de
una parte del proyecto de software libre FreePBX version 2.1.1, que implementa una
interfaz web de administración, con�guración y monitoriazación del servidor Asterisk.
Para conseguir la interoperabilidad con el sistema de telefonía tradicional RDSI, haremos
uso de un "media gateway" ( dispositivo que permite la integración entre redes de distinta
tecnología), modelo Teldat, que hará de pasarela entre la red IP y RDSI.
Una vez implantado el sistema, el funcionamiento del mismo seguirá los siguientes pasos:
1. Los usuarios estableceran una llamada para contactar con otro usuario, o bien una
llamada entrante será recibida a través de RDSI.
2. La centralita IP, a la espera de llamadas, se encargará de conmutar éstas hacia
su destino y de ejecutar una serie de aplicaciones de telefonía, dependiendo de las
acciones asociadas a cada llamada.
3. En el panel que incorpora la interfaz grá�ca, se monitorizará el estado de las
llamadas establecidas.
13
3 LA VoIP.
El protocolo de Voz sobre IP es un estándar desarrollado para poder realizar comuni-
caciones de voz en tiempo real a través de redes IP, inicialmente desarrolladas para el
transporte de datos. Las redes IP han evolucionado desde la transmisión de datos única-
mente, hasta realizar las funciones de una red tradicional de conmutación de circuitos.
La mayor parte de las redes de conmutación que existen en la actualidad serán rempla-
zadas por redes de conmutación de paquetes en un futuro. Esta transición supone no
sólo una reducción de los costes, sino que proporcionará también el desarrollo de una
serie de nuevos servicios para voz y datos que no hubiesen sido posible con las redes de
conmutación de circuitos tradicionales.
En este apartado se describirán los elementos del estándar de VoIP, así como una des-
cricpión de la arquitectura y funcionamiento del software, de carácter libre, utilizado
para implementar la central de conmutación.
Las enormes posibilidades que tiene la VoIP de convertirse en la opción de telefonía
dominante del futuro, debido tanto a su reducido coste como a su �exibilidad, será otro
tema tratado en este apartado.
3.1. INTRODUCCIÓN.
La convergencia de las redes de telecomunicaciones actuales supone encontrar la tecno-
logía que permita hacer convivir en la misma red voz y datos. Esto obliga a establecer
un modelo o sistema que permita encapsular la voz para ser transmitida junto con los
datos sobre la misma red. Teniendo en cuenta la importancia y desarrollo de Internet,
el desarrollo de una tecnología universal nos lleva a pensar en el protocolo IP (Internet
Protocol) y a encontrar un método que nos permita la transmisión de voz sobre dicho
protocolo. Esto se consigue con el estándar VoIP (Voice Over Internet Protocol).
14
3 LA VoIP.
Dicho estándar, regula el transporte de los datos de voz a través de redes IP en forma
de paquetes de datos. El interés de transportar la voz por este tipo de redes, en lugar
de por las redes de conmutación de paquetes tradicionales, se debe a ciertas limitaciones
de éstas últimas y a las ventajas aportadas por las redes de conmutación de paquetes:
Limitaciones de las redes de conmutación de circuitos:
1. Uso ine�ciente de los recursos. Cada llamada telefónica utiliza un canal de 64
kbps, independientemente de trá�co que haya en cada momento. Además todos
los elementos de conmutación se designan para conmutar canales de 64 kbps inde-
pendiente de la cantidad de trá�co que llegue al conmutador en cada instante.
2. Son cerradas e poco �exibles.
3. Mantenimiento caro.
Ventajas de las redes de conmutación de paquetes:
1. Soportan un mayor volumen de trá�co gracias a que aprovechan mejor el ancho de
banda disponible.
2. Son redes abiertas.
3. Al no tener que reservar canales exclusivos para cada llamada, permite la reducción
drásticas de costes de tari�cación de llamadas.
4. Integración de nuevos servicios y uni�cación de la estructura de red.
Aunque las redes IP parece aportar excepcionales ventajes al mundo de la telefonía, la
integración de éstas con las redes de telefonía tradicional es un reto difícil y ,actualmente,
presentan ciertas limitaciones. Hay que tener en cuenta que los principios de diseño que
dieron lugar a la red de telefonía que actualmente conocemos, son casi los opuestos a los
que originaron la red IP. Mientras que IP proporciona un servicio de tipo "Best-E�ort"
mediante ancho de banda compartido, la red telefónica proporciona un servicio garanti-
zado mediante reserva de capacidad. La industria de las telecomunicaciones empezó con
15
3 LA VoIP.
una aplicación especí�ca: la telefonía, y construyó una red adaptada a sus necesidades.
Internet, por otro lado, comenzó exactamente en el extremo opuesto: creó una nueva
tecnología de red y buscó, con éxito, aplicaciones que pudieran hacer uso del servicio
ofrecido.
IP cuenta con varias limitaciones, que se han hecho más evidente conforme la red au-
menta de tamaño. El aumento del trá�co tradicional, se ha venido solventando mediante
la solución obvia de incrementar la capacidad de los medios de transmisión. Sin embar-
go, el trá�co por la red no sólo ha cambiado en volumen, sino también ha cambiado en
naturaleza. Existen muchos nuevos tipos de trá�cos, de múltiples aplicaciones nuevas,
cuyos requirimientos operacionales varían enormemente.
Entre estas nuevas aplicaciones, la telefonía se destapa como una de las más exigentes.
El mantenimiento de una conversación bidireccional en tiempo real es posiblemente una
de las aplicaciones más difíciles de satisfacer. A pesar de ser una aplicación multimedia,
sus requisitos de ancho de banda son muy escasos, apenas 8 Kbytes por segundo en cada
sentido. De modo que la capacidad no es problema, el problemas más bien es la latencia
durante la comunicación.
Para la telefonía IP, y en general para muchas otras aplicaciones bidireccionales y en
tiempo real, los requisitos de temporización son mucho más restrictivos que los de capa-
cidad. El retardo de tránsito, y las pérdidas de paquetes debido a congestiones momen-
táneas de la red, resultán en una pérdida apreciable de la calidad de la comunicación. Un
incremento del ancho de banda es una primera solución para los problemas de latencia,
sin embargo, el trá�co en Internet aumenta en la misma proporción que el incremento de
ancho de banda una vez que éste es añadido, de manera que esto no supone una salida.
Son imprescindibles nuevas medidas que aseguren cierta calidad del servicio prestado.
En los siguientes apartados se irán viendo los elementos necesarios utilizados por la
tecnología VoIP para transportar la voz sobre redes IP.
3.2. TRANSMICIÓN DE VOZ SOBRE REDES IP.
Este capítulo describe los pasos necesarios llevados a cabo para transmitir la voz a través
de redes IP, desde que ésta es capturada en el origen de la comunicación hasta que es
reproducida en el otro extremo.
16
3 LA VoIP.
El empaquetamiento de la voz dentro de datagramas IP, la transmisión de la misma a
traves de la red, la recepción y la reconstrucción digitalizada de la voz es llevado a cabo
dentro de caminos virtuales establecidos entre el origen y el destino a través de la red
IP, comunmente conocidos como canales.
3.2.1. MUESTREO Y DIGITALIZACION
La técnica por la cual la voz humana es convertida de su forma de onda natural al
formato digital �nal empleado por la tecnología de VoIP para su transmisión a traves
de red, se le conoce como DAC (Digital-to-Analog Conversation). En el mundo de la
telefonía tradicional, el proceso es bastante simple, ya que las variaciones de dichas
técnicas vienen impuestas según los diferentes tipos de enlaces de datos y dispositivos,
y según los estándares regionales empleados.
Sin embargo, estos procesos de digitalización en la tecnología VoIP no están exclusiva-
mente ligados al tipo de enlace de dato. Diferentes técnicas de digitalización y compre-
sión son usadas en circunstancias diferentes. No siempre las propiedades de los enlaces
de datos, tales como capacidad o latencia, son factores decisivos en la elección de estas
técnicas. Esta conversión de la señal a formato digital es llevada a cabo tanto en el mun-
do IP como en la telefonía tradicional, donde los sistemas de comunicación transportan
los datos mediante multiplexación de �ujos de voz digitalizados.
DAC incluye digitalización de la voz, cuantización de la señal digital, �ltrado para pre-
servar el ancho de banda y compresión de la señal para una mejor e�ciencia del ancho
de banda. La técnica de muestreo más común para convertir señales audibles a señales
digitales es la Modulación por Implusos Codi�cados (MIC), donde la señal analógica será
muestreada a la vez que su amplitud será discretizada y codi�cada en formato binario.
Para establecer una llamada telefónica, un teléfono tradicional, sea analógico o digital,
requirirá un enlace con su�ciente capacidad como para transportar un �ujo de datos de
64 Kbps. Ésta es la velocidad �jada para cualquier línea de teléfono tradicional. Tanto
sistemas de telefonía analógica como digital ofrecen una claridad del sonido similar, ya
que operan en el mismo rango de muestreo de la señal de voz: 8000 Hz. Esta frecuencia
combinada con una resolución de muestreo de 8 bits, da lugar a un régimen binario de
64kbps.
17
3 LA VoIP.
En el mundo de la telefonía tradicional cada conversación de voz concurrente, tanto
digital como analógica, requirirá un ancho de banda de 64kps, es por ello que este valor
representa un dato útil a tener en cuenta en el dimensionamiento de una red VoIP.
3.3. EL PROCESO DE CODIFICACIÓN DE LA
VOZ.
3.3.1. EMPAQUETADO
El empaquetado de la voz es el proceso, en tiempo real, por el cual un �ujo de voz digi-
talizada es dividida en trozos manejables y de igual tamaño para su adecuado trasnporte
sobre la red.
Figure 3.1: Señal discretizda.
18
3 LA VoIP.
No como ocurre en una línea analógica, en VoIP la señal de sonido es transmitida y
recibida mediante terminales IP. Esto hace que la señal sea más manejable para ser
transportadas a traves de circuitos tradicionales de voz, tales como E1 o RDSI. Pero a
diferencia del sistema de telefonía digital RDSI, la señal de voz en una llamada a través
de una red IP es empaquetada, esto signi�ca que dicha información es transportada a
través de la red en unidades que también son usadas para transportar otros tipos de
datos. En el caso de VoIP, dichas señales se encapsulan en datagramas UDP.
3.3.2. MULTIPLEXACIÓN.
La red de telefonía tradicional (RTC) ofrece una forma de proveer una mayor capaci-
dad de llamadas que la que provee la linea telefónica tradicional. A través de una línea
compuesta por dos pares de hilos conductores, a diferencia de la línea tradicional, com-
puesta por un sólo par de hilos, puede transmitirse hasta 24 llamadas simultáneas. Esta
tecnología de alta densidad es llamada E1 y es a menudo usada a modo de enlace para
unir centrales telfónicas (PBX). La técnica usada para aprovechar mejor los recursos
de la red se llama multiplexación. Diversos niveles de multiplexación de canales de voz,
proveen una mayor densidad de llamadas a través de un mismo medio. Por contra, la
adquisición de estos cirtcuitos tiende a ser bastante cara y es por ello que suelen em-
plearse exclusivamente como enlaces entre centrales telefónicas, o bien, en aplicaciones
de datos, suelen ser usados por los proveedores de servicio a Internet (ISP) que necesitan
ofrecer una alta capacida de conexión a Internet.
3.3.3. COMPRESIÓN.
VoIP provee una forma más económica de compartir el medio de transmisión. Para ello
emplea técnicas de compresión sobre las muestras de sonido usadas para representar la
voz en la red, de tal forma que una menor cantidad de enlaces físicos son requeridos
para transmitir la misma información. Es posible reducir el régimen binario de 64 kbps,
usados en una conversación telefónica tradicional, por debajo de los 44 kbps, sin llegar
a notar pérdida de calidad en la señal de voz reconstruida en el extremo receptor. Los
algoritmos usados por VoIP para codi�car los datos de sonido o para decrementar los
requerimientos de ancho de banda son conocidos como codec.
19
3 LA VoIP.
3.3.4. CODECS.
Los codecs, llamados así por la función que desempeñan tanto en el transmisor, como
codi�cadores de la señal, como en el receptor, como decodi�cares de la misma, son
algoritmos usados para empaquetar �ujos de datos multimedia (voz y/o audio), que
posteriormente serán retransmitidos por la red en forma de streaming o bien serán
transportados en tiempo real sobre la misma. Existen docenas de codecs para audio
y video, pero aqui sólo describiremos los que son más comunes en las redes VoIP.
La mayoría de estos codecs usados en redes VoIP son de�nidos por recomendaciones
de la ITU-T, áquellas pertenecientes a la variedad G ( Trasmision system and media).
Dentro del grupo de codec de�nidos por la ITU-T, pueden distinguirse dos tipos: los que
van destinados a aplicaciones que requieren una alta �delidad como puede ser la difusión
de música a través de la red, y aquellos que van destinados a la codi�cación de señales
de voz que serán transmitidas en tiempo real. Será sobre estos últimos sobre los que nos
centraremos posteriormente.
Los codecs de audio para aplicaciones de telefonía, así mismo, se dividen en dos grupos:
aquellos que se basan en la modulación por impulsos codi�cados para transmitir la señal
de audio, y aquellos que restructuran la representación digital de la señal PCM en un
formato más adecuado. Así estos dos grupos de codecs de telefonía son los codec PCM,
que son los codecs básicos de 64 kbps, y los vocoders, los cuales van un paso más alla del
algoritmo PCM. Por último, puede considerarse un tercer grupo de codecs, los codecs
híbridos, que reunen las ventajas de los anteriores.
Codecs PCM o basados en forma de onda:
Transmiten información sobre la forma de onda de la señal de voz. Este grupo
de codecs se caracterizan por tener una tasa de bit de 64 kbps, siendo el más
representativos de todos ellos el codec G.711. Esta tasa es muy elevada para las
posibilidades de algunas partes de la red, por lo que cada vez se utilizan menos
este tipo de codecs.
En este grupo también se encuentran los codecs predictivos, que comparan a codi-
�car con las anteriores y codi�can sólo la señal de error, con una menor cantidad
de bits y también mediante forma de onda. Se usan menos bits ya que la señal de
error es más pequeña que la muestra en sí, tiene un menor rango dinámico. Con
20
3 LA VoIP.
estos codecs se puede reducir la tasa de error hasta los 18 kbps, a cambio de perder
un poco de calidad.
Vocoders:
Estos codecs aprovechan las características de la señal de voz humana. Toman
muestras de intervalos de la señal de voz de diferente duración (10ms , 20ms o
30ms), según el tipo de codec. Una vez con estas muestras, la analizan mediante
determinados algoritmos para sacar los coe�cientes del �ltro vocal ( que hará el
papel del tracto vocal de la persona que habla) y para crear la señal de excitación
( que simula el impulso del aire que pasa por las cuerdas vocales al hablar). Con
estos datos de excitación y �ltro se puede reconstruir posteriormente la voz en el
receptor.
Estos codecs comprimen bastante la información a transmitir y alcazan tasas de
transmisión muy bajas, por contra la voz reproducida suena muy sintetizada, poco
natural y la calidad es bastante a inferirio a la de PCM.
Codecs híbridos:
Estos codecs tienen las ventajas de los vocoders, en cuanto a que se basan en
el modelo de excitación, más un �ltro vocal para conseguir bajas tasas de bit
a transmitir, y además poseen las ventajas de los predictivos, en cuanto a que
comparan la muestra generada mediante la señal de excitación y �ltro calculados,
con la original, para así transmitir también el error cometido con muy pocos bits y
conseguir más naturalidad en la voz reproducida en el destino. Dicho error puede
ser codi�cado bien mediante índices o por forma de onda, según el codec, y se
transmite junto con los coe�cientes del �ltro vocal y la señal de excitación. Con
esto se consiguen tasas de transmisión también muy bajas y además una calidad
de escucha bastante buena.
Dentro de este grupo, podemos encontrar a los codecs: G.729 y G.723.1, estan-
darizados por la ITU-T, y a GSM y sus variantes, estandarizados por el ETSI.
A continuación se describen brevemente los codecs más comunes usados en la
telefonía IP:
21
3 LA VoIP.
• G.711.
Este codec es un algoritmo de codi�cación/decodi�cación de 64 kbps que usa
8 bits para codi�car las muestras de señales de audio muestreadas a 8 khz.
Se trata de una señal de audio de buena calidad. Este codec presenta un
bajo procesamiento para ser implementado y es el esquema de codi�cación
usado por los circuitos de telefonía digital tradicional, como E1. Este codec
no provee ninguna compresión.
Existen dos variantes de las técnicas de digitalización PCM usadas en el
codec G.711: uLaw y ALaw. La primera utiliza una escala de digitalización
logarítmica para discretizar los niveles de amplitud, mientras la otra usa una
escala lineal. Entre ellos no son compatibles y deben ser transcodi�cados si
cada uno de los extremos de la conversación están utilizando uno de ellos.
uLaw suele ser usado en Norte America y parte Asia, mientras que ALaw
prevalece en el resto del mundo.
• G.721, G.723, G.726, G.728 y G.729A
Estos codecs hacen un mejor uso de la capacidad de la red, permitiendo la
reproducción de sonido de alta calidad a una tasa de bit de 8 a 32 kbps. Este
grupo de codecs usa los algoritmos ADPCM ( Adaptatice di�erential Pulse
Code Modulation) o CELP ( Code Excited Linear Predition) para reducir los
requerimientos de ancho de banda.
• G.722.
Este codec tiene ocupa un gran ancho de banda, ya que hace un muestreo de
la señal de audio al doble de valor normal: 16 Khz. El efecto es que el sonido
tiene mucha mayor calidad que el resto de los codecs usados para VoIP. Por
lo demás, es idéntico al codec G.711.
• GSM.
Este codec, usado en el sistema de telefonía movil global, ofrece una tasa de
13 Kbps. Como muchos otros codec salido de las recomendaciones de la ITU-
T, hace uso del algoritmo CELP para lograr una alta escala de compresión y
,a su vez, presenta un procesamiento mucho menor.
22
3 LA VoIP.
• ILBC.
El Internet Low Bitrate Code, es un codec de audio que puede adquirirse
gratuitamente. Presenta características similares, en cuanto a consumo de
ancho de banda e intesidad de procesamiento, a las del codec G.729A, pero
con un mejor comportamiento ante la pérdida de paquetes.
• Speex.
Este codec presenta una tasa de muestreo comprendida entre 8 y 32 kHz,
además de una tasa binaria variable. Speex permite cambiar la tasa binaria
en medio de la transmisión, sin tener que establecer una nueva llamada, lo
que puede ser útil en situaciones de congestión de la red. Se trata de un codec
disponible gratuitamente y con implemenataciones bajo código abierto.
Cada uno de estos codecs tiene sus ventajas e inconvenientes. �G.711� es adecuado en
enlaces donde hay su�ciente capacidad y presentan poca latencia, como es el caso de
Ethernet. Éste presenta un buen comportamiento ante los errores, pero, por ejemplo, no
sería adecuado su uso en un enlace Frame Relay de 56 kbps, ya que no se dispondría del
su�ciente ancho de banda. Recíprocamente, los codecs que proveen una algún tipo de
compresión, lo hacen a costa de degradar la calidad de la señal
3.3.5. TASA DE PAQUETIZACIÓN DE LOS CODECS.
Además de los bits que representan los datos de audio, todos los paquetes transportan
otros bits usados para funciones de rutaje, corrección de errores, etc. Esta sobre carga de
bits no representa ningún bene�cio para la aplicación de VoIP, más que permirtir a los
niveles inferiores transmitir cabeceras ethernet, cabeceras IP o cualquier otra información
necesaria para el transporte del paquete a través de la red. Cuanto mayor sea la cantidad
de datos de audio transmitidos por paquete, menos sobrecarga de cabeceras se transmite
por la red, ya que hacen falta menos paquetes para transportar el mismo sonido, y por
tanto mejor se aprovecha la capacidad del canal.
Como se ha comentado anteriormente, la clave para reducir la sobrecarga en una red
de VoIP es reducir el número de paquetes por segundo usado para transmitir la señal
de audio. Pero esto incrementa el impacto de los errores sobre la llamada telefónica.
23
3 LA VoIP.
Así que se necesita llegar a un compromiso entre un valor de sobrecargar aceptable y
un aceptable nivel de resistencia a los errores. En esta parte es donde la elección de
un determinado codec puede ayudar, ya que cada uno proporciona distintas tasas de
transmisión de paquetes por segundo y distintos cantidades de cabeceras.
Los diferentes tipos de codecs usan diferentes tasas de paquetes. Al espacio entre los
paquetes transmitidos se le conoce como intervalo entre paquetes, y es expresado en
relación a la tasa de paquetes. Algunos codecs, especialmente aquellos que usan algorit-
mos CELP avanzados, requieren una mayor cantidad de audio ( 20 ms, 30 ms) en un
mismo tiempo, para poder realiazar la codi�cación y decodi�cación. El intervalo entre
paquetes tiene un efecto directo sobre la sobrecarga. Cuanto mayor es éste, menor será
la sobrecarga requerida para transmitir los datos de audio, y viceversa. Pero por contra,
el aumento del mismo provoca un aumento directo de la latencia o retraso de los datos,
es decir, la diferencia de tiempo entre el momento en el que el sonido fue originado hasta
que éste fue codi�cado, transportado, decodi�cado y reproducido en el extremo receptor,
será mayor. Ya que un paquete IP no será transmitido hasta que éste sea totalmente
construido, una trama de audio no podrá viajar a través de la red hasta que éste esté
totalmente codi�cado. Esta latencia afecta negativamente a la calidad de la llamada,
percibida en el receptor.
Pero la latencia no es el único inconveniente que se deriva de tener un intervalo entre
paquetes grandes: cuanto mayor sea la duración de sonido transportada por cada paque-
te, mayor será la porbabilidad de que el extremo receptor note un efecto negativo en el
sonido si un paquete es perdido debido a una congestión u error de la red. La pérdida de
un paquete que transporta 20ms de audio es apenas imperceptible con el codec G.711,
pero no así la pérdida de 60 ms de audio, que puede ser bastante molesto. El principal
motivo por el que el sonido es transmitido bajo datagramas UDP, es porque ofrece un
servicion no �able y no orientado a conexión, de tal forma que aquellos paquetes perdido
no serán retransmitidos. El hecho de implementar el protocolo de VoIP sobre el TCP,
implicaría que todos los paquetes que se noti�quen como perdidos serían retrasmitidos.
Este efecto haría que los paquetes en el extremo receptor llegasen completamente fuera
de secuencia, con la consecuente perdidad de calidad que esto conlleva.
Si se considera un muestreo de 8khz para una señal de audio básica con 8 bits por mues-
tra, y se asume un intervalo entre paquetes de 20ms, puede verse que la cantidad de datos
de audio, utilizando el codec G.711, transportada es de 1.280 bits. Si a estos se le añade
24
3 LA VoIP.
los bit de cabecera introducidos por cada protocolo que encapsula el mensaje, resulta
1.904 por trama, suponiendo que se utiliza ethernet como tecnología de transimisión.
Figure 3.2: Trama de voz sobre tecnología Ethernet.
3.3.6. SISTEMAS DE TRANSIMISIÓN DTX/VAD/CNG.
Además de la conversión analógico-digital, el codec intenta comprimir lo máximo posible
la información a transmitir, para que así los requerimientos de ancho de banda necesarios
para llevar a cabo la comunicación sean los menores posibles.
Una forma importante de reducir ancho banda, además del que se consigue al comprimir
la señal, es el uso del sistema DTX / VAD / CNG. Se trata de un sisitema de transmisión
discuntínua ( Discontinous Transmision, DTX), que se emplea conjuntamente con un
detector vocal ( Vocal Activity Detector, VAD) y un generador de ruido de fondo (
Confort Noise Generator, CNG). Dicho sistema consiste en no enviar paquetes de datos
durante los silencios de las conversaciones. En estos silencios, aunque no se hable, seguirá
habiendo ruido de fondo, por lo que será necesario transmitir algún tipo de información
que sirva para reproducir el ruido de fondo en el receptor y no perder así la naturaleza
25
3 LA VoIP.
de la conversación. Este tipo de tramas con información para el ruido se conocen como
tramas SID ( Silence Insertion Descriptor) y son de poco tamaño comparadas con las
tramas de datos. El elemento del codec encargado de generar el ruido de fondo a partir
de la información de las tramas SID, es el generador de ruido de fondo ( CNG).
Utilizando el sistema de transmisión discontínua se ahorra mucho ancho de banda. Este
algoritmo DTX, también es menos sensible a los errores de transmisión que en un sistema
en el que se enviaran las tramas activas de datos constántemente, ya que si se pierden
tramas tramas SID, se cogen los parámetros de las anteriores para generar el ruido
actual, de manera que afecte poco esa pérdida. En el caso en que se pierda la primera
trama SID de un tramo de silencio, durante la fases de habla se van estimando también
dichos parámetros para su posterior reprodución.
Para que este sistema funcione es fundamental el buen funcionamiento de los detectores
de actividad vocal. Estos analizan intervalos de conversación de una determinada dura-
ción y concluyen si en este fragmento analizado ha habido voz ( tramo de "active voice"),
o no ( tramo de "inactive voice"). En los tramos de voz activa se envia información útil,
y en los tramos de voz inactiva, se mandan tramas SID, para que el decodi�cador pueda
generar un ruido de fondo adecuado, o , incluso, no se envía nada. Las tramas SID sólo
se envian si el ruido ha cambiado desde la última trama transmitida.
Para determinar si estamos ante un tramo de voz inactica o activa, los VAD's se basan
en diferentes medidas, tales como:
Los coe�cientes del �ltro LP de esa trama de voz.
La energia de la banda de frecuencias completa.
La energía de la banda de frecuencias que va desde 0 hasta 1 khz.
La tasa de cruces por cero de la señal de voz.
3.4. EL ESTANDAR VoIP.
Este apartado describe los estándares de señalización de llamadas en una red de VoIP.
También se describe la forma en la que estos estándares compiten y se complementan.
26
3 LA VoIP.
3.4.1. PROTOCOLOS DE SEÑALIZACIÓN DE VoIP.
Un protocolo se señalización es un lenguaje común hablado por teléfonos, servidores
de administración de llamadas (por ejemplo, centrales telefónicas implementadas via
software), PBX tradicionales y por cualquier otro elemento que pueda interferir en una
comunicación telefónica, a través del cual pueden comunicarse para establecer, negociar
y �nalizar llamadas.
La tecnología de voz sobre IP, provee una familia de protocolos de señalización. La mayor
parte de los protocolos de señalización tienen en común una serie características:
Sus propósitos son señalizar, registrar y facilitar los eventos claves de una llamada:
el comienzo, el �nal de llamada y cuándo los usuarios están intentando usar una
serie de servicios de telefonía como transferencia de llamada o conferencia.
Aunque las llamadas de señalización suelen establecerse usando UDP como proto-
colo de transporte, no son vistas como trá�co en tiempo real, como ocurre con la
transmisión de los datos de voz.
El patrón de trá�co que sigue la señalización cuando ésta es transmitida por la red,
suele ser de poca duración y a ráfagas, en oposición al trá�co de voz que tiende a
ser consistente y de larga duración.
La mayoría de estos protocolos de señalización no suelen estar implementados
simultáneamente en un mismo dispositivo IP.
Actualmente, existen dos importantes protocolos de señalización en el mundo de la te-
lefonía IP: el Protocolo de Inicio de Sesión (SIP), desarrollado por el IETF ( Internet
Engeneering Task Force); y H.323, desarrollado por la ITU-T. Existen otra serie de pro-
tocolos de señalización, desarrollado por compañias privadas, como pueden ser: SCCP,
desarrollado por Cisco Company, o IAX, propiedad de la empresa Digium.
Entre todos los estándar de señalización que existen, aquellos que han sido elaborados
por organismos públicos, como son SIP y H.323, nos aportarán una mayor �exibilidad
y extensibilidad, ya que se encuentran bajo libre disposición, distribución y modi�ca-
ción para toda la comunidad de Internet. Entre estos dos principales éstandares existen
27
3 LA VoIP.
sustanciales diferencias, en cuanto a los distintos tipos de caminos por donde pueden
establecer las llamadas telefónicas. H.323, hace posible establecer una comunicación en-
tre central de conmutación y central de conmutación, entre la RTC y una central de
conmutación, y entre terminales y centrales de conmutación. Esto signi�ca que H.323
posee una interfaz que le permite establecer una llamada con los sistemas de telefonía
tradicionales, especialmente con la RTC. Comparativamente, SIP es mucho más limitado
en cuanto a su alcance dentro de la red. Éste no soporta la comunicación con ningún
terminal tradicional, sea analógico o digital. Fue diseñado para permitir una comunica-
ción entre terminales IP. Sin embargo, una gran ventaja de SIP es su �exibilidad para
soportar aplicaciones de caracter no telefónico, tales como mensajería instantánea, vi-
deo conferencias, etc. Dicha propiedad es la principal característica de SIP y la mayor
carencia de H.323.
Familia de protocolos Escenarios de señalizacion Mantenedor
H.323 Telefonía y video. ITU-T
SIP Telefonía, video y mensajeria instantánea. IETF
IAX Telefonía. Digium Inc.
SCCP Telefonía( conmutadores<�>terminales) Cisco System
MEGACO/H.248 Telefonía(control de gateway's) ITU-T
MGCP Telefonía(control de gateway's) IETF
3.4.2. EL PROTOCOLO H.323.
H.323, actualmente en su versión 2, es una recomendación de la ITU-T para un estilo
de señalización basada en PBX que soporta transmición sobre redes de conmutación de
paquetes. H.323 no tiene que ser entregado completamente usando una red IP. Ciertas
subrecomendaciones de H.323 permiten a las redes de telefonía tradicional ser integra-
das, por medio de la señalización, con todos los dispositivos que intervienen en una
comunicación. Por ejemplo, H.323 permite la señalización sobre las líneas de teléfonos
tradicionales de la RTC, a través de las recomendaciones H.320 y H.324.
Mientras que el estándar H.323 se encuentra en un estado bastante maduro y bien do-
cumentado por la ITU-T, éste ha sido implementado en partes especí�cas por cada
fabricante que no son, desafortunadamente, totalmente interoperables. Esta incompati-
bilidad de las implementaciones de H.323 es un problema cuando se pretende enlazar
28
3 LA VoIP.
sistemas de distintos fabricantes. Para conseguir este objetivo, se hace uso de dispositi-
vos trandicionales, tales como E1, como elemento intermediador, ya que la mayoría de
las implementaciones de los protocolos de telefonía tradicional de cada fabricante son,
casi siempre, compatibles entre sí.
Los paquetes de mensajes H.323 son compactos, y la señalización H.323 es muy rápida,
especialmente comparada con SIP, el cual usa mensajes más largos y basados en texto
plano. El diseño de H.323 está basado en los fundamentos del diseño de la Red Telefónica
Conmutada: brevedad y disponibilidad. La red es usada tan poco como sea posible para
transportar la señalización de la llamada, y tanto como sea posible para transporta el
sonido.
3.4.2.1. ARQUITECTURA .
3.4.2.1.1. GATEKEEPER H.323.
El gatekeeper es un equipo de la red que provee monitorización, centralizada de lla-
madas y capacidades de señalizacón hacia terminales H.323. El alcance de un gatekeeper
puede ser un segmento particular de una LAN o , incluso, todo un continente.
Al alcance de red dentro del cual un gatekeeper opera se le denomina "zona". Puede
haber sólo un gatekeeper por zona y una zona por gatekeeper. Es normal referirse a un
gatekeeper H.323 como una central software de conmutación, una softPBX.
Tanto los terminales H.323 como los gateways, para que puedan ser accesibles a las
aplicaciones de telefonía, deben llevar a cabo un proceso de registro ante el gatekeeper.
Esto quiere decir que cada terminal H.323 debe informar al gatekeeper de cuáles son
sus características únicas que lo identi�can: número de telefóno, dirección IP, etc. Este
proceso puede ser autenticado si se desea.
En la con�guración de cada terminal hay que indicar la dirección IP o el nombre de
dominio del gatekeeper de la zona a la que pertenezca el terminal. También existe la
posibilidad de descubrir la precencia de un gatekeeper usando un IP multicast a la
dirección y puerto: �224.0.1.41:1718�.
El proceso de registro es llevado a cabo mediante el protocolo RAS: Resgistration, Admis-
sion y Status. Este protocolo sólo govierna el proceso de registro y no el establecimiento
29
3 LA VoIP.
de llamadas. Sin la presencia de un gatekeeper en una red H.323 no se podría estable-
cer mucho más que canales dedicados con otro terminal, se perderían, entre otras, las
funciones de rutaje de mensajes.
De acuerdo a las recomendaciones de la ITU-T, un gatekeeper debe proveer:
Resolución de direcciones via un estándar llamado E.164.
Registro y autenti�cación.
Control de ancho de banda.
Zona de administración de registro y llamada.
Señalización de las llamadas de control.
Monitorización de las llamadas.
El proceso que sigue un terminal H.323 cuando se registra, es el siguiente:
1. El terminal envía un mensaje RRQ ( Registration Request) al gatekeeper, que
consiste en la dirección IP y puerto del terminal, su dirección E.164 y un alias
para ser usado como identi�cador cuando éste efectue una llamada.
2. El gatekeeper guarda toda la información proveida por el terminal en memoria,
para posterior uso cuando autenti�que al terminal, junto con un hash, que es
usado para asegurar la identidad del terminal, evitando posibles suplantaciones de
identidad.
3. El gatekeeper responde al terminal con un mensaje RCF ( Registration Request
Con�rm), indicando que está listo para realizar y recibir llamadas en la red.
30
3 LA VoIP.
3.4.2.1.2. TERMINALES H.323.
Cada terminal H.323, ya éste implementado en software o hardware, contiene una pila
de elementos software que le permiten cubrir diferentes aspectos del proceso de llamada:
H.245, el cual le provee de capacidades de negociación, que le permiten estar seguro
de saber si existe en ambos extremos de la comunicación una aplicación y codecs
compatibles.
H.225, el cual le provee servicios de tari�cación y monitorización necesarios para
el establecimiento �able de llamadas y contabilidad de las mismas.
RTP, el estándar del IETF para la transmisión de datos mulitmedia en tiempo
real.
Selección de uno o más codecs de audio.
Opcionalmente, un terminal H.323 puede ofrecer T.120, un protocolo para habilitar
aplicaciones interactivas.
3.4.2.1.3. GATEWAY H.323.
El propósito de un gateway es hacer de interfaz entre los canales de voz basados en IP
y las tecnología tradicionales de señalización y transportes tales como FXO, FXS, RDSI,
E1, etc. Este elemento es requerido sólamente cuando se pretende hacer interoperar la
red de VoIP con una red de telefonía tradicional.
Un gateway H.323 ofrece una convergencia especializada de los protocolos de señalización
que soportan ciertos tipos de circuitos tradicionales:
H.320 soporta paquetización de la voz sobre circuitos RDSI y E1.
H.324 soporta paquetización de la voz sobre líneas de teléfono analógicas usando
el codec G.711.
Los gateways también deben registrarse con el gatekeeper para la zona en la que ellos
sirven, si las llamadas van a ser rutadas a través de sus interfaces.
31
3 LA VoIP.
3.4.2.1.4. UNIDAD DE CONTROL MULTIPUNTO.
Una MCU, es un dispositivo H.323 que tiene un único propósito: poder establecer una
multiconferencia entre tres o más canales de voz. Ésta puede ser implementada en un
servidor dedicado, o bien, ser integrada como parte de un terminal H.323.
Una MCU está formada por dos componentes fundamentales: MP (mulipoint processing)
y MC (multipoint controller). La primera de ellas, es el elemento software dentro de
la MCU encargado de llevar a cabo las accciones de un DSP, para agregar canales
multimedia a una multiconferencia. El controlador multipunto o MC, es el encargado
de gestionar las negociaciones H.245 entre todos los terminales para determinar las
capacidades comunes para el procesado de audio y datos. También controla los recursos
de la conferencia para determinar cuáles de los �ujos, si hay alguno, serán multipunto
(multicast). Las capacidades son enviadas por el MC hacia todos los extremos de la
conferencia, indicando los modos en los que pueden transmitir.
3.4.2.2. TORRE DE PROTOCOLOS .
H.323, es recomendación que impone los protocolos a utilizar para la comunicación.
Figure 3.3: Torre de protocolos H.323
32
3 LA VoIP.
Algunos protocolos, como RTP ( Real Time Protocolo) y RTCP (Real Time Control
Protocol), ya existían cuando se de�nió la recomendación y fueron reutilizados direc-
tamente. Otros, como H.225.0 y H.245, derivarón del ITU-T H.320, H.221 y H.242, y
algunos otros, como el protocolo RAS, fue diseñado especí�camente para H.323.
Como se describe más adelante, cada protocolo o conjunto de ellos en H.323 tiene como
objetivo ofrecer un servicio a las capas superiores:
Direccionamiento.
RAS: protocolo utilizado para la búsqueda de un gatekeeper por parte de un ter-
minal, para establecer un registro en la zona que éste controla.
Señalización:
H.225.0: protocolo que describe cómo el audio, los datos y la información de con-
trol, en una red de conmutación de paquetes, pueden ser usados para proporcionar
servicios telefónicos. Se encarga de la señalización de las llamadas. Los mensajes
H.225.0 siguen el estándar Q.931 y son del tipo: mensaje de establecimiento de lla-
madas, mensajes de información de la fase de la llamada, mensajes de terminación
de la llamada y otros.
H.245: protocolo de control para especi�car mensajes de apertura y cierre de cá-
nales lógicos para comunicaciones de voz, para realizar las negociaciones de los
parámetros y establecer conexiones UDP.
Los mensajes siguen la sintaxis ASN.1. Consisten en un intercambio de mensajes
que pueden ser del tipo: peticiones, respuestas, comandos y mensajes de indicación.
Información de audio:
Todos los terminales deben soportar el codec G.711. También pueden utilizarse
cualquiera de los codecs G.7xx estandarizados por la ITU-T.
Información de vídeo:
En el caso que los terminales H.323 soporten vídeo llamada o vídeo conferencia,
serán utilizados los protocolos H.261 y H.263, que de�ne la manera de transportar
�ujos de videos utilizando RTP.
33
3 LA VoIP.
Envio de datos entre terminales H.323.
Funcionaliadad opcional, que en el que caso de que sea soportada será implemen-
tada por los protocolos de la familia T.12x.
Transporte de los paquetes:
UDP: la transimición de los paquetes de datos en VoIP se suele realizar sobre
paquetes UDP, que aunque no ofrezca integridad a los datos, el aprovechamiento
del ancho de banda es mayor que con TCP.
RTC: protocolo que proporciona funciones de transporte convenientes para apli-
caciones que transmiten en tiempo real. Maneja los aspectos relativos a la tempo-
rización, marcando los paquetes UDP para un reordenamiento de los mismo en el
receptor.
Control de la transmisión:
RTCP: protocolo de control de RTP. Se utiliza principalmente para detectar si-
tuaciones de congestión en la red y tomar acciones correctoras. Se basa en la
transmisión periódica de paquetes de control a todos los participantes en la sesión,
usando el mismo mecanismo de distribución que los paquetes de datos.
Servicios suplementarios.
A través de los protocolos de la familia H.450.x se ofrence servicios tales como:
llamada en espera, intrusión de la llamada, etc.
3.4.2.2.1. INTERCAMBIO DE MENSAJES DURANTE EL PROCESO DE
SEÑALIZACIÓN.
Hay cinco pasos generales, a seguir por cada extremo de la llamada, para llevar a
cabo el proceso de señalización de la misma: establecimiento/�nalización, negociación de
capacidades, establecer canales de audio y/o video, llevar a cabo la llamada y liberación
de la llamada.
1. Establecimiento/�nalización:
34
3 LA VoIP.
Para iniciar una llamada se hace uso del protocolo H.225. Durante este paso, cada
terminal involucrado en la llamada es puesto al día del estado en que se encuentra
la llamada, a través de uno de los posibles estados que de�ne H.225:
En proceso: esto signi�ca que el terminal de origen está intentando establecer
una conexión de red con el terminal de destino.
Alerta: esto signi�ca que el extremo receptor está siendo noti�cado de que
alguién está intentando alcanzarle. En otras palabras, que el extremo receptor
está sonando, y que el terminal que originó la llamada está recibiendo una
indicación de ello.
Conectar: esto signi�ca que el receptor ha aceptado la llamada y que un canal
de audio/video puede ser establecido.
Liberar: esto signi�ca que uno de los extremos de la llamada ha señalizado
en �nal de la misma. Cuando este estado es indicado, la llamada pasa a ser
�nalizada.
2. Negociación de capacidades
Después de establecer la llamada, se hace uso del protocolo H.245 para negociar
los requerimientos de aplicación de la llamada y seleccionar el codec apropiado.
H.245 determina:
Qué tipo de apliacación multimedia puede cada terminal soportar: audio,
video u otras.
Cuáles son los codecs disponibles para cada terminal y cuáles son sus prefe-
rencias.
Cómo los canales serán estructurados y qué tipo de intervalo será usado.
Qué terminal jugará el papel de maestro y cuál de esclavo durante la duración
de la llamada. Los papeles de maestro y esclavo hacen referencia a quién
actuará como cliente o servidor en el proceso de envio de señales durante la
llamada, se trata exclusivamente de una formalidad del protocolo.
35
3 LA VoIP.
Cómo debe noti�carse al terminal que inició la llamada si la negociación falla.
Normalmente, el terminal mostrará un mensaje de error mientras suena una
señal de ocupado.
3. Establecer canales de audio/video.
Una vez que se ha llevado a cabo la negociación de capacidades, RTCP ( RTP
Control Protocol) es utilizado para establecer un canal UDP donde tendrá lugar
la transmisión de audio/video. Tras abrir el canal UDP, un �ujo de paquetes UDP,
que encapsulan al protocolo RTP, atravesará a la red usando el codec e intervalo
entre paquetes negociados anteriormente.
4. Llevar a cabo la llamada.
Una vez que la llamada esté en progreso, RTCP, que se ejecuta junto a RTP en
puertos UDP consecutivos, puede guardar ventanas del canal de comunicación, que
permanecerán intactas hasta el �n de la llamada.
5. Liberación
Al �nalizar la llamada, H.225 entra en su estado de liberación, señalizando el
�nal a los canales multimedia, a la sesión H.245 de negociación de capacidades
y al proceso de tari�cación llevado a cabo por el gatekeeper. Dependiendo de los
terminales, ambos podrán oir un tono o una señal de ocupado.
Figure 3.4: Señalización directa, sin Gatekeeer.
36
3 LA VoIP.
En la anterior �gura puede verse el proceso de señalización que tiene lugar cuando un
terminal H.323 intenta establecer una llamada con otro terminal via un gatekeeper:
1. El llamante envía un mensaje de petición de admisión, ARQ, al gatekeeper de su
zona, identi�cándose a sí mismo y a la dirección E.164 del terminal con el que
quiere establecer la llamada. Este mensaje es parte del protocolo RAS.
2. El gatekeeper contesta con una con�rmación ARQ (ACF). Esto con�rma al lla-
mante que la petición de sesión ha sido recibida por el gatekeeper.
3. El llamante envía un mensaje de establecimiento de llamada al otro extremo de la
llamada.
4. El receptor envía un mensaje provisional H.225 "Call Proceeding". Se trata de un
mensaje provisional porque el receptor debe veri�car la autenticidad del llamante
antes de proseguir con la llamada.
5. El receptor envía un mensaje "Called Party ARQ Adminsion Request" al gatekee-
per, preguntándole si la llamada es legítima. En este punto, el gatekeeper debería
tener una copia de la petición de registro del llamante para validar la llamada.
6. Si el gatekeeper tiene una copia de este registro, devuelve el mensaje "Called Party
ACF" al receptor, dando paso a que el receptor comienze a sonar.
7. El receptor, una vez que comienza a sonar, envía en mensaje H.225 "Alerting",
indicando al extremo que originó la llamada que el receptor está sonando.
8. Una vez que el receptor conteste a la llamada, éste envía un mensaje H.225 "Con-
nect" al otro extremo de la comunicación. Esto deja paso a que el proceso H.245,
de negociación de capacidades, comienze.
La diferencia entre señalización basada en gatekeeper y señalización directa entre ter-
minales, es el papel que juega éste en las sesiones H.225, sin in�uir en el camino que
seguirán los datos multimedia a través de la red.
37
3 LA VoIP.
Figure 3.5: Señalización a través gatekeeper.
3.4.2.3. ESQUEMA DE DIRECCIONES E.164 .
E.164 es una convención para asignar números de teléfonos a terminales en una red de
VoIP. E.164, permite a los terminales de una red de VoIP registrar dinámicamente sus
números de direcciones E.164 desde una lista de números almacenados en una base de
datos en el gatekeeper.
Esta base de datos es una lista de direcciones MAC Ethernet, cada una de las cuales
corresponden a una o más direcciones E.164. De esta forma se controla que terminal va
a usar un determinado número, permitiéndo así una fácil movilidad de los terminales en
la red: no importará a qué lugar vaya el terminal H.323, su dirección E.164 siempre será
la misma.
Pero exiten una serie de incovenientes usando direcciones MAC como enlaces hacia una
dirección E.164: di�cultad a la hora de memorizarlas e imposibilidad de cambiar su valor.
Existen mejores formas de manejar la asignación de alias a los terminales H.323, ya que
basarse en este método, es intrínsicamente basarse en la tecnología Ethernet. Esto es
unos de los grandes inconvenientes de H.323 en comparación a SIP.
38
3 LA VoIP.
3.4.3. EL PROTOCOLO SIP.
El Protocolo de Inicio de Sesión, fue desarrollado por el IETF, como una forma de
señalización multiusuario de telefonía distribuida y de aplicaciones de mensajerias en
una red IP.
Los deberes y escenarios de SIP son los mismos que los de H.323. Es decir, hay terminales
de VoIP de distintas capacidades y servidores que participan en el proceso de señalización
y establecen políticas para la red de VoIP. Sin embargo, SIP es más �exible que H.323,
puede considerarse más que un conjunto de protocolos de telefonía para audio y video. Se
trata entorno de trabajo para todos los tipos de aplicaciones basadas en el intercambio de
mensajes, desde aplicaciones de telefonía hasta mensajería instantánea u otros servicios.
SIP, en vez de usar una estructura de mensajes compacta y orientada a la máquina,
como H.323, usa cabeceras de gran longitud y codi�cadas en texto plano, como es el
caso de SMTP o HTTP, lo que permite, de forma más cómoda, la solución de problemas
y una mayor aceptación.
SIP, se encuentra acutalmente en su versión 2.0 y su de�nición completa se encuentra
recogida en las RFC's 3261-3265. El propósito de�nido de SIP es coordinar y facilitar
la monitorización de sesiones multimedia en la red. Éste soporta una variedad de es-
quemas de direccionamiento y es diseñado tanto para una topología centralizada como
distribuida.
39
3 LA VoIP.
Figure 3.6: Torre de protocolos SIP.
3.4.3.1. ARQUITECTURA.
SIP sigue el modelo cliente/servidor. En el entorno SIP, tanto servidores como los puntos
�nales de una comunicación, son llamados "nodos". Un telefóno SIP, es un nodo, y como
cada nodo, puede comunicarse directamente con cualquier otro para, de esta forma,
poder establecer sesiones multimedias, tal y como los terminales H.323 pueden establecer
canales directos entre ellos. Pero la con�guración más usual es usar servidores SIP, a los
cuales el resto de los teléfonos SIP deberán noti�car su presencian, es decir, deberán
registrarse, una vez que empiecen a funcionar.
Los elementos funcionales en la arquitectura SIP son:
1. Agentes de Usuario ( User Agent, AU).ññ
2. Servidores de red.
Los agentes de usuario son aplicaciones que residen en los nodos terminales SIP, y contie-
nen dos componentes: Agentes de Usuario Clientes ( User Agent Client, UAC) y Agentes
40
3 LA VoIP.
de Usuario Servidores ( User Agent Server, UAS). Los UAC originan las peticiones SIP
, y los UAS responden a estas peticiones, es decir, originan respuestas SIP asociadas al
extremo que recibe la llamada. Los UA's deben implementar el transporte tanto sobre
TCP como UDP.
Los UA's y UAS's pueden establecer, por sí solos, una comunicación. No obstante, la
potencialidad de SIP se aprovecha con el empleo de los servidores de red. Los servidores
de red, se clasi�can desde el punto de vista logico, de la siguiente manera:
Servidores de redirección.
Servidores Proxy.
Servidores de Registro.
3.4.3.1.1. SERVIDORES DE REDIRECCIÓN.
Se encargan de procesar mensajes INVITE, que son solicitudes SIP emitidas por la
parte que origina la llamada, y retornan la dirección , o direcciones, de la parte llamada,
es decir la URL de la parte llamada, o cómo contactar con ella. En caso contrario,
rechazan la llamada enviando una respuesta de error. Análogamente a H.323, juegan el
papel de gatekeeper.
Cuando un servidor SIP responde a la solicitud INVITE, enviada por la parte que origina
la llamada, con una respuesta 3xx, el servidor SIP está redireccionando a dicha parte
hacia otro servidor SIP. Posteriormente, el nodo SIP debe contactar con el nuevo servidor
SIP a través de otra solicitud SIP. Esta característica no está implementada en todos
los sistemas que soportan SIP, y suele ser propia de entornos extensos que operan bajo
redes exclusivamente SIP.
3.4.3.1.2. SERVIDORES PROXY.
Ejecutan un programa intermediario que actúa como servidor y cliente: desde al punto
de vista del llamante se comporta como un servidor y desde el punto de vista del receptor
como un cliente. Un servidor proxy puede reenviar solicitudes hasta el destino �nal sin
efectuar cambio alguno en ellas, o cambiar alguna parámetro si se requiere.
41
3 LA VoIP.
Los servidores proxy desarrollan el rutaje de los mensajes de solicitudes y respuestas
SIP, y pueden ser del tipo "stateful" o "stateless".
Los servidores proxy statefull retienen información dela llamada durante el proceso que
dure el establecimiento de ésta, no así los servidores stateless, que procesan un mensaje
SIP y entonces olvidan todo lo referente a la llamada hasta que vuelvan a recibir otro
mensaje asociado a la misma. Las implementaciones stateless proveen buena escalabi-
lidad, pues los servidores no requieren mantener información referente al estado de la
llamada una vez que la transacción ha sido procesada. Además, esta relación es muy
rubusta, dado que el servicio no necesita recordar nada en relación a la llamada. Sin
embargo, no todas las funcionalidades pueden ser implementadas por un servidor state-
less, algunas como: contabilización, tari�cación de llamadas,etc, pueden requerir que se
le sigua el rastro a todos los mensajes y estado de una comunicación.
3.4.3.1.3. SERVIDORES DE REGISTRO.
Se encargan de registrar las direcciones SIP, formato URL, y sus direcciones IP asocia-
das. Es decir, se encargan de mappear direcciones SIP en direcciones IP, y típicamente
se encuentran implementados junto con los servidores proxy o servidores de redirección.
También se les denominan servidores de localización ( Location Server), pues son utiliza-
dos por los servidores proxy y de redirección para obtener información de la localización
de la parte llamada. Realmente los servidores de localización, no son entidades propias
del sistema SIP, sino más bien, base de datos que pueden formar parte de arquitecturas
que utilicen SIP. Entre éstos y cualquier servidor SIP, sea proxy o de redirección, no se
utiliza el protocolo SIP, sino protolos típicos de bases de datos o servicios de directorio,
como por ejemplo LDAP.
La información registrada en los servidores de registros, no es permanente, sino que
requiere ser refrescada periódicamente, de lo contrario el registro correspondiente será
borrado.
Usualmente, un servidor SIP implementa una combinación de los diferentes tipos de
servidores SIP ya comentados.
42
3 LA VoIP.
Figure 3.7: Escenario SIP.
3.4.3.2. DIRECCIONAMIENTO SIP: SIP-URI.
Los nodos SIP son referenciado usando URI ( Uniform Resources Indicator), con la
siguiente estructura
sip:usuario@servidor_sip
Esta convención indica tanto el usuario al que quiere alcanzarse como el servidor SIP ,
que se espera que conozca la dirección SIP del usuario �nal. Aquellas conecciónes que
requieren una encriptación para la señalización usaran el pre�jo "sips", en lugar de "sip"
en la descripción de sus URI's. La encriptación de dichas señales hará uso de la capa de
transporte seguro (SSL).
3.4.3.3. MÉTODOS SIP Y RESPUESTAS.
Los mensajes de señalización SIP, solicitudes y respuestas, emplean el formato de mensaje
genérico establecido en la RFC 822, esto es:
43
3 LA VoIP.
Una línea de inicio.
Uno o más campos de cabeceras (header).
Una línea vacía indicando el �nal del campo cabeceras.
Cuerpo del mensaje.
Figure 3.8: Formato de un mensaje SIP.
Mientras que H.323 usa la sintaxis ASN.1 para la descripción del formato de los mensajes,
SIP se basa en texto plano.
Las solicitudes SIP se clasi�can dentro de diez categorías, llamadas métodos. Cada mé-
todo lleva a cabo una función diferente dentro de la arquitectura SIP:
1. INVITE: este método es usado para establecer sesiones y anunciar las capacidades
de los nodos SIP.
2. ACK: es usado para con�rmar que el cliente solicitante ha recibido una respuesta
�nal desde un servidor a una solicitud INVITE, reconociendo la respuesta como
a�rmativa.
3. OPTIONS: es usado para preguntar a un nodo SIP por sus capacidades, sin que
ningún canal multimedia haya sido establecido aún.
4. BYE: este método ocurre cuando la llamada es completada, es decir, cuando alguna
de los extremos involucrados en la comuniacación desea �nalizar la llamada.
5. CANCEL: cancela una solicitud pendiente, pero no afecta a una solicitud ya com-
pletada. Este método �naliza una solicitud de llamada incompleta.
44
3 LA VoIP.
6. REGISTER: noti�ca al servidor SIP en qué terminal SIP un usuario puede ser
alcanzado.
7. INFO: es usado para trnasmitir señales de aplicación de telefonía a través del canal
usado por la señalización SIP. Tales señales pueden ser dígitos marcados, etc.
8. PRACK: este método es usado en lugar de ACK para noti�car al otro extremo
que se está estableciendo una llamada.
9. SUBSCRIBE: este método provee una forma de establecer manejadores de eventos
dentro de aplicaciones de telefonía SIP.
10. NOTIFY: este método entrega mensajes entre estremos SIP, tales como eventos
ocurridos durante la llamada.
Cuando una llamada debe ser establecida, �nalizada o alterada, un evento SIP es em-
pleado. Los eventos precedentes son similares en concepto a los métodos de HTTP:
GET y POST; y como en HTTP, SIP espera códigos de respuestas cuando un método
es enviado. Los códigos de respuestas SIP son clasi�cados en seis categorias:
1xx: informativo. Solicitud recibida, se continua para procesar la solicitud.
2xx:solicitud exitosa. La solicitud fue recibida de forma adecuada, procesada y
aceptada.
3xx: re-direccionamiento. Más acciones deben ser consideradas para completar la
solicitud.
4xx: error del cliente. La solicitud contiene mal la sintaxis o no puede ser resuelta
en este servidor.
5xx: error de servidor. El servidor no ha podido resolver una solicitud aparente-
mente válida.
6xx: fallo global. La solicitud no puede ser resuelta en servidor alguno.
Los mensajes 1xx, son respuestas provisionales y no terminan la transacción SIP, a
diferencia de lo que ocurre en el resto de las categorias.
45
3 LA VoIP.
Figure 3.9: Intercambio de mensajes SIP.
3.4.4. EL PROTOCOLO IAX.
IAX, Inter-Asterisk Exchange Protocol, actualmente en su segunda versión, es un pro-
tocolo de señalización para redes VoIP, tal y como ocurre con H.323 y SIP. La principal
diferencia con estos últimos es que IAX no implementa RTP como mecanismo de paque-
tezación, sino que éste tiene su propia forma de empaquetar los datos de voz codi�cada.
IAX es un protocolo a prueba de NAT, donde cientos de llamadas simultáneas origin-
das desde detrás de un �rewall con enmascaramiento funcionarán correctamente, como
ocurre con HTTP.
IAX es implementado de forma más simple y menos exhaustiva que SIP o H.323. A
diferencia de estos últimos, que son más extensibles, IAX va dirigido exclusivamente a
aplicaciones de telefonía.
Mientras que un ciclo completo de registro, señalización de llamada, transmisión de
voz y �nalización, puede usar varios puertos TCP y UDP, en el caso de SIP o H.323, el
protocolo IAX maneja todas estas funciones usando un único puerto UDP. Tanto cuando
el cliente IAX, terminal, se registra con el servidor o proxy IAX, así como cuando una
llamada es establecida o se trasnmite tramas de voz, se utiliza el mismo puerto UDP.
La forma que IAX utiliza para distinguir las distintas funcionalidades llevadas a cabo
46
3 LA VoIP.
durante la llamada, es la inclusión de cabeceras y meta-datos en cada paquete, que
de�nen cuál es el propósito de éste y si lleva datos adjuntos.
La documentación del protocolo IAX describe el orden de estas cabeceras y los meta-
datos, tales como tramas de control, meta-tramas y elementos de información, cada uno
de los cuales tiene su propia sintaxis. IAX no está codi�cado usando ASCII, ni ASN.1,
en vez de esto, usa un esquema propietario de codi�cado binario más orientado a la
interfaz máquina-máquina.
Al contrario que ocurre con H.323 y SIP, IAX no es una recomendación estándar, sino
más bien un protocolo independiente creado por Mark Spencer. Aunque propietario, la
especi�cación de IAX es abierta y ha sido aceptada por la comunidad VoIP.
Funciones/Características SIP H.323 IAX
47
3 LA VoIP.
Localización de terminales
y admisión
Método SIP
REGISTER
Protocolo RAS Tramas de control
IAX REG
Establecimiento y
liberación de llamada
Método SIP INVITE Protocolo H.225 Tramas de control
IAX NEW y
HANGUP
Negociación de capacidades,
codecs y puertos para datos
multimedias
Protocolo de
De�nición de Sesión
Protocolo H.245 Meta-trama de
Información de
Capacidades IAX
Paquetización y transmisión
de muestras de sonido
Protocolos
RTP/RTCP
Protocolos
RTP/RTCP
Tramas IAX
VOICE/DATA
�Streaming� de video y
audio grabado
Protocolo RTSP Ninguno
recomendado
Ninguno
recomendado
Codi�cación de trama ASCII ASN.1 Binario
Simulitud de mensajes HTTP RDSI/Q.931 Propietario
Rutaje de llamada descrito
como
Proxy Gatekeeper-
rutado
Software PBX
Dipositivo de referencia
para el rutaje de llamadas
Registrar Gatekeeper Servidor
Ruta de llamada
independiente
Redirect Señalización
directa
Señalización
directa
Interfaz RDSI Ninguna
recomendada
Gateway H.323 Ninguna
recomendada
Identi�cación de terminales SIP-URI, dirección
de email, dirección
E.164 o alias
Dirección E.164 SIP-URI,
dirección de
email, dirección
E.164 o alias
Conexión a traves de
cortafuegos
Redirección a través
de Proxy/softPBX
Redirección a
traves de Gate-
keeper/SoftPBX
No se necesita
Proxy
Puertos UDP 5060/5061 1503,1720,1731 5036
48
3 LA VoIP.
3.4.5. LOS PROTOCOLOS MEGACO Y SIGTRAN
Estos dos protocolos surgieron con la aparición, como consecuencia de la liberación del
servicio telefónico, de escenarios que permiten el tránsito de llamadas entre terminales
telefónicos de la RTC, a través de una red IP. En estos escenarios no exiten terminales
VoIP nativos conectados directamente a la red IP. La solución se basa en el empleo de
pasarelas VoIP conectadas entre sí a través de una red dorsal IP, y localmente, a una o
más centrales telefónicas.
Con objeto de que las pasarelas que proporcionan el inter-funcionamiento entre la red la
red telefónica y la red IP sean lo más sencillas posibles, el proceso de llamada y el manejo
de la señalización se realizan en un servidor de llamadas (controlador de pasarelas). De
esta forma, las pasarelas sólo tienen que encargarse del manipulado físico de los �ujos
de voz: codecs, empaquetado, control de jitter, cancelación de ecos, etc.
Pasarela de medios (MG):
1. Conmutación de �ujos de voz, bajo las órdenes de su controlador.
2. Conversión de medios: codecs a usar, cancelación de ecos, etc. Controlado por
el MGC
3. Detección de eventos básicos: colgar, descolgar, marcación de dígitos, etc.
Controlador de pasarelas (MGC):
1. Procesos de llamadas: encaminamiento, etc.
2. Controlar a las pasarelas de medios (MG): codecs a utilizar, establecer cone-
xiones, etc
3. Recibir noti�caciones de diversos eventos desde las pasarelas.
Esta arquitectura da lugar a dos protocolos, que deben coexistir:
1. MEGACO/H.248: protocolo del tipo cliente/servidor de�nido conjuntamente por
el IETF y la ITU-T, para el control remoto de las pasarelas de medios desde el
controlador de las mismas. Una MGC controlará a varios MC a través del protocolo
H.248, y se comunicará con otras MGC a través del protocolo SIP o H.323.
49
3 LA VoIP.
2. SIGTRAN: familia de protocolos del IETF que permite el transporte de la señali-
zación telefónica sobre la red IP hasta el servidor de llamadas, MGC
Figure 3.10: Integración de las redes RTC e IP.
50
4 ASTERISK.
4.1. INTRODUCCIÓN.
Asterisk, es una implementación "open source" de una centralita telefónica (PBX: Pri-
vate Branch Exchange). Como cualquier PBX, Asterisk permite a un cierto número de
teléfonos conectados a él realizar llamadas entre ellos y conectarse a otros servicios tele-
fónicos, incluido la RTC. Su nombre viene del símbolo '*', que tanto en entornos UNIX
como DOS representa un comodín.
Asterisk es editado bajo una doble licencia, por una parte posee una licencia de software
libre, GNU Public License (GPL), y por el otro lado posee una licencia comercial, para
permitirle ejecutar código cerrado o patentado, tal y como ocurre con el codec G.729 (
aunque el codec G.729 puede trabajar tanto con versiones comerciales o libres). Mark
Spencer, fundador de la empresa Digium, originariamente creó Asterisk y permanece
como su principal mantenedor, aunque siguiendo el método de desarrollo de los proyectos
de software libre, existen una docena de programadores que han contribuido con nuevas
características, funcionalidades y reportando errores. Originariamente diseñado para el
sistema operativo Linux, Asterisk ahora también se ejecuta sobre OpenBSD, FreeBSD,
Mac OS X , Sun Solaris y Microsoft Windows, aunque como plataforma nativa, Linux
es el sistema operativo mejor soportado.
El software básico de Asterisk incluye bastantes características, previamente sólo dispo-
nibles en sistemas PBX propietarios, tales como: buzón de voz, conferencia de llamadas,
respuesta interactiva y distribución automática, entre otras. Los usuarios pueden añadir
nuevas funcionalidades de varias formas: desarrollando scripts en el lenguaje propio de
Asterisk, que posteriormente serán interpretados por éste; añadiendo módulos persona-
lizados escritos en C; o escribiendo AGI ( Asterisk Gateway Interface) scripts, en Perl u
otros lenguajes.
51
4 ASTERISK.
Para conectar teléfonos tradicionales a un servidor Linux ejecutando Asterisk, o para
tener acceso a la RTC, el servidor deber ser equipado con cierto hardware ( un simple
módem no será su�ciente). Digium y otras �rmas venden tarjetas PCI para conectar
líneas de teléfonos, líneas T1 o E1, y otros servicios telefónicos analógicos o digitales al
servidor.
Puede decirse que, hoy en día, el mayor interés que recibe Asterisk, se debe en parte,
al soporte que presenta ante un amplio rango de protocolos de VoIP, incluyendo SIP
y H.323. Asterisk, puede interoperar con teléfonos SIP, actuando como un servidor de
registro y como Gateway entre los teléfonos IP y la RTC. Los desarrolladores de Asterisk,
también han diseñado un nuevo protocolo, IAX, para una e�ciente comunicación entre
servidores Asterisk.
Mediante el soporte de una mezcla de servicios de telefonía tradicionales y de VoIP,
Asterisk permite construir e�cientemente nuevos sistemas de telefonía, o gradualmente
migrar sistemas tradicionales hacia nuevas tecnologías. Algunas empresas están usando
servidores Asterisk para reemplazar sistemas PBX propietarios; otras para proveer ca-
racterísticas nuevas o ahorrar costes, transportando llamadas de larga distancia a través
de Internet.
A partir del 9 de Septiembre de 2006, la versión actual de Asterisk es la 1.2.12.1, aunque
actualmente se encuentra en fase beta la versión 1.4.
4.1.1. CENTRALITAS o PBX.
PBX es el acrónimo de Private Branch eXchange o Private Business eXchange, también
llamada planta o central por los usuarios. Es un servicio ofrecido por una empresa de
telecomunicaciones, por el cual una cantidad �n� de líneas o números son agrupadas en un
único número que se publica o muestra al público y al cual pueden llamar. La empresa
proveedora se encarga de distribuir las llamadas entrantes por las líneas disponibles
contratadas por el cliente .
El cliente que compra este servicio puede contratar 10 líneas �jas y tener 10 teléfonos
en su o�cina y aunque los 10 números son diferentes y pueden ser accedidos de forma
independiente, el servicio PBX le permite tener un solo numero y así facilitar a sus
clientes la marcación del mismo. Cuando entra una llamada, ésta es asignada a la primera
52
4 ASTERISK.
línea disponible, y lo mismo sucede con el resto de llamadas entrantes que se cursen
simunltáneamente. Si todas las líneas están ocupadas se le noti�ca al llamante con un
tono de congestión y deberá esperar a que alguna llamada sea liberada.
Una PBX es el servicio de un numero virtual que administra llamadas entrantes a 2 o
mas líneas (números) telefónicas físicas.
En los orígenes de la telefonía era necesario conectar manualmente cables para establecer
la comunicación. Este sistema era conocido como PMBX (PBXManual). Este dispositivo
fue reemplazado por un dispositivo electromecánico automático y sistemas electrónicos
de conmutación llamado PABX (PBX automático) que desplazó al PMBX hasta hacerlo
casi inexistente. A partir de ese momento PABX y PBX se convirtieron en sinónimos.
El uso de un PBX evita conectar todos los teléfonos de una empresa de manera separada
a la red de telefonía local pública RTC, evitando a su vez que se tenga que tener una
línea propia con cargos mensuales y salidas de llamadas hacia la central telefónica que
regresan nuevamente para establecer comunicación interna.
Tanto como el fax, o el módem, o grupos de teléfonos, u otros dispositivos de comunica-
ción pueden ser conectados a un PBX (aunque el módem puede degradar la calidad de
la línea). Generalmente estos dispositivos se relacionan como extensiones.
El dispositivo PBX está instalado frecuentemente en la empresa que requiere el servicio
y conecta llamadas entre los teléfonos instalados en ella. Cuenta además con un número
limitado de líneas externas disponibles para hacer llamadas al sitio. Las compañías con
múltiples sedes pueden conectar juntos sus PBX a través de líneas troncales. El servicio
de PBX puede prestarse desde un equipo ubicado en el proveedor despachando el servicio
mediante la red de telefonía pública local conmutada.
Las llamadas hacia el exterior en un PBX son hechas marcando un número seguido del
número externo. En ese momento se selecciona automáticamente una línea troncal y
sobre ésta se completa la llamada.
Al igual que las PBX, Asterisk provee interoperabilidad entre un sistema local de tele-
fonía y la RTC. Muchas de las características en una PBX tradicional son raramente
usadas, incluso algunas de ellas han sido desarrolladas exclusivamente para un único
cliente. Es por esto que Asterisk no posee todas las características de las PBX de todos
53
4 ASTERISK.
los fabricantes, sin embargo, debido a que se trata de un proyecto de software libre, pue-
de añadírsela fácilmente cualquier característica deseada, sino ha sido ya desarrollada.
Figure 4.1: Entorno de trabajo con Asterisk.
4.2. ARQUITECTURA.
Asterisk ha sido cuidadosamente desarrollado para obtener una máxima �exibilidad. Al-
rededor de un sistema central, núcleo de la PBX, se ha de�nido un conjunto de API's.
Este avanzado núcleo maneja la interconexión interna de la PBX, abstrayéndola de pro-
tocolos especí�cos, codecs e interfaces hardware utilizadas para las distintos servicios de
telefonía. Esto permite que Asterisk utilize cualquier hardware y tecnología convenientes,
disponible ahora o en el futuro, para realizar sus funciones esenciales.
El núcleo de Asterisk maneja estas herramientas internamente:
La conmutación de la PBX: la esencia de Asterisk es el sistema de conmutación,
conectando llamadas entre varios usuarios y automatizando tareas. El núcleo de
54
4 ASTERISK.
conmutación conecta de forma transparente llamadas entrantes en diferentes har-
dware e interfaces software.
Lanzador de aplicación: se encarga de ejecutar servicios o aplicaciones tales como
buzón de voz, listado de directorios o mensajes de bienvenida.
Traductores de codec: se encarga del uso de diferentes módulos de codecs para
codi�car o decodi�car los distintos formatos de compresión de audio usados en la
industria de la telefonía. Se encuentran disponibles un conjunto de codecs, que
se adaptan a diversas necesidades y permiten llegar a un balance óptimo entre la
calidad del audio y el ancho de banda usado.
Administrador de la Entrada/Salida: maneja tareas de bajo nivel y la adminis-
tración del sistema para un funcionamiento óptimo bajo diferentes condiciones de
carga.
Módulos API's:
API de canal (channel API): esta API maneja el tipo de conexión por la que se
recibe una llamada entrante, independientemente de que se trate de una conexión
VoIP, RTC, RDSI o de cualquier otra tecnología. Distintos módulos serán carga-
dos dinámicamente para manejar los detalles de la capa de bajo nivel de estos
componentes.
API de aplicación (Aplication API): esta API permite que varias aplicaciones sean
ejecutadas para llevar a cabo distintas funciones: multiconferencia, buzón de voz,
listado de directorios y , en general, cualquier otra tarea que los sistemas PBX
puedan ejecutar tanto ahora como en el futuro.
API de traducción de codecs (Codec translator API): se encarga de cargar los dis-
tintos módulos de codecs para poder codi�car y decodi�car los distintos formatos
de audio, tales como: GSM, uLaw, aLaw e incluso MP3.
API de formato de �cheros (File format API): se encargar de manejar la escritura
y lectura en los distintos formatos de archivo utilizados para el almacenamiento
de datos.
55
4 ASTERISK.
Usando estas API's, Asterisk logra una abstracción entre sus funciones bases, propias de
los sistemas PBX, y la amplia variedad de tecnologías existente en el área de la telefonía.
Esta arquitectura modular, es la que permite a Asterisk integrar el hardware usado
en la telefonía tradicional y las novedosas tecnologías de transmisión de voz mediante
conmutación de paquetes. La capacidad para cargar diferentes módulos de codecs le
permite soportar transmisiones de voz a través de conexiones lentas, tales como las
conexiones a través de módems telefónicos, así como proveer una alta calidad de audio
sobre conexiones sin restricciones de ancho de banda.
El API de aplicación, provee un �exible uso de los módulos de aplicación para ejecutar
cualquier aplicación, y permite el desarrollo abierto de nuevas aplicaciones que satisfagan
necesidades y situaciones únicas. Además, cargar todas las aplicaciones como módulos
hace que el sistema sea un sistema �exible, permitiendo a los administradores diseñar
la mejor trayectoria para las llamadas entrantes en el sistema PBX, así como modi�car
las trayectorias de las llamadas para satisfacer las necesidades de la comunicación, que
irán cambiando dinámicamente.
Figure 4.2: Arquitectura de Asterisk.
56
4 ASTERISK.
4.2.1. INTERFACES Y CANALES.
Es necesario saber qué interfaces están disponibles y cómo éstas trabajan para ser capaz
de hacer funcionar a Asterisk. Cualquier llamada entrante o saliente es hecha a través de
una interfaz, ya sea SIP, Zaptel, H.323, IAX, etc. Cada llamada es colocada o recibida
a través de su interfaz en su propio canal. Estos canales pueden estar conectados a un
canal físico como una línea POST ( Plain Old Telephone Service) , o a un canal lógico
como los canales SIP o IAX.
Es muy importante diferenciar la llegada de una llamada en el canal desde la que fue
realizada. Cuando una llamada llega a Asterisk a través de un canal, el plan de marcado
determina qué es lo que hay que hacer con ella. Por ejemplo, una llamada puede llegar a
través de un canal SIP, siendo su origen bien un teléfono SIP o un SIP "softphone" eje-
cutándose en un ordenador. El plan de marcado determina si la llamada será contestada,
conectada a otro teléfono, desviada o redirigida al buzón de voz.
Asterisk provee varias aplicaciones, las cuales pueden ejecutarse en el plan de marcado
cuando se procesa una llamada entrante.
Diferentes tipos de interfaces son asociadas con diferentes tipos de hardware o protocolos.
Por ejemplo, los canales SIP son usados para rutar llamadas, tanto hacia dentro como
hacia fuera de Asterisk, a través de IP usando el protocolo SIP. Una llamada puede llegar
al servidor Asterisk a través de un canal SIP o dejar Asterisk, saliendo hacia Internet, a
través de otro canal SIP.
Todas las llamadas llegan al sistemas a través de un canal, incluso las llamadas internas.
Cuando un usuario descuelga el teléfono, un canal es activado, luego la llamada del
usuario �uye a través del canal activo y el plan de marcado decide qué es lo que hay que
hacer con dicha llamada.
Asterisk usa un driver ( típicamente llamado chan_xxx.so) para soportar cada tipo de
canal.
4.2.2. ORGANIZACIÓN DE LOS FICHEROS.
La siguiente tabla muestra los archivos donde se guarda información relacionada con
Asterisk. Contiene los archivos relacionados con la con�guración de Asterisk, excepto la
con�guración de las interfaces hardware.
57
4 ASTERISK.
/etc/asterisk Contiene los archivos relacionados con la con�guración
de Asterisk, excepto la con�guración de las interfaces
hardware.
/usr/sbin Programas ejecutables y scripts incluyendo asterisk,
astman, astgenkey y safe_asterisk.
/usr/lib/asterisk Objetos binarios especí�cos de la arquitectura de
Asterisk.
/usr/lib/asterisk/modules Módulos para aplicación, driver de canales, driver de
formato archivos, etc.
/usr/include/asterisk Archivos de cabecera requerido para construir
aplicaciones, drivers de canales y otros módulos
/var/lib/asterisk/agi-bin Scripts AGI utilizados en el plan marcado por la
aplicación AGI.
/var/lib/asterisk/astdb La base de datos de Asterisk, mantiene información de
con�guración. Este archivo nunca se modi�ca a mano,
para ello, debe usarse el comando "database" desde la
línea de comandos de Asterisk.
/var/lib/asterisk/images Imágenes a las que se hace referencia dentro del plan de
marcado o desde alguna aplicación.
/var/lib/asterisk/keys Claves privadas y públicas usadas dentro de Asterisk
para la autenticación RSA.
/var/lib/asterisk/mohmp3 Archivos MP3 usados por la aplicación "música en
espera". La con�guración de esta aplicación se
encuentra en el directorio /var/lib/asterisk/sounds.
/var/lib/asterisk/sounds Archivos de audio, mensajes de bienvenida, etc, usados
por las aplicaciones de Asterisk.
/var/run/asterisk.pid Identi�cador del proceso primario (PID) de la ejecución
de Asterisk.
/var/run/asterisk/ctl Nombre de la tubería usada por Asterisk para habilitar
la administración remota.
/var/spool/asterisk Archivos donde se guardan el registro de llamadas
entrantes, los buzones de voz de cada usuario, etc.
58
4 ASTERISK.
/var/spool/asterisk/outgoing Asterisk monitorea este directorio en busca de llamadas
salientes, especi�cadas en forma de archivos. Asterisk
comprueba el formato de los �cheros e intenta realizar
la llamada. Si la llamada es contestada, entonces ésta es
pasada al servidor Asterisk.
4.3. CONFIGURACIÓN.
Las operaciones de Asterisk son gobernadas mediante un conjunto de archivos de con�-
guración en texto plano. Cualquier cosa, desde la asignación de un número de extensión
hasta la con�guración a bajo nivel de las interfaces hardware, es establecida a través de
estos �cheros. Se muestra a continuación un resumen de la funcionalidad de los archivos
más importantes:
asterisk.conf
Contiene la localización de los componentes software de Asterisk, de los archivos
de sonidos, scripts y otros archivos usados por Asterisk.
extensions.conf
Contiene el plan de marcado, una pequeña con�guración de los teléfonos de los
usuarios, buzones de voz, etc.
features.conf
Le cuenta a Asterisk cómo manejar algunas características tales como las llamadas
en espera o la transferencia de llamadas.
h323.conf
Contiene instrucciones de cómo Asterisk debería interaccionar con los dispositivos
usando el protocolo H.323.
59
4 ASTERISK.
iax.conf
Le cuenta a Asterisk cómo manejar el protocolo IAX para interactuar con otros
clientes.
manager.conf
Con�gura restricciones de seguridad para la conexión con el "Asterisk Manager"
(herramienta que permite controlar y monitorizar Asterisk de forma remota)
modules.conf
Le cuenta a Asterisk qué módulos, o aplicaciones de telefonía, cargar cuando éste
se ejecute.
sip.conf
Contiene instrucciones de cómo Asterisk debería interactuar con dispositivos VoIP
usando el protocolo se señalización SIP.
logger.conf
Le cuenta a Asterisk dónde almacenar su archivos de registros y cómo de detallados
deben ser.
voicemail.conf
Le cuenta a Asterisk cómo funciona su servidor de correos, llamado "Comedian
Mail"
zapata.conf y zaptel.conf
Le cuenta a los módulos de señalización del kernel y a Asterisk qué tipo de interfaz
hardware está instalada y cómo está con�gurada.
60
4 ASTERISK.
4.3.1. EL PLAN DE MARCADO.
Todas las llamadas realizadas desde, hacia y a través de Asterisk, son manejadas por
medios de circuitos lógicos de voz, que puede consistir en una línea telefónica a través de
la cual sólo se establecerá una conexión o en una única conexión física donde cientos de
comunicaciones comparten la conexión, como ocurre con los teléfonos SIP conectados a
Asterisk a través de la interfaz Ethernet. En cualquier escenario, a estos circuitos lógicos
se les conoce como canales, y el propósito de Asterisk es manejar su trá�co de voz acorde
a un conjunto de reglas conocidas como plan de marcado, dial-plan. El efecto que el plan
de marcado tiene sobre una llamada, es llamado �ujo o secuencia de la llamada.
Muchos si temas PBX convencionales usan el plan de marcado para tratar con llamadas
que sólo podrán ser realizadas o contestadas cuando alguna persona se encuentre presente
en el otro extremo del terminal. Esto requiere ampliar el sistema añadiendo un nuevo
módulo hardware que actuará como servidor de correos y contestador automático, para
atender las llamadas cuando nadie se encuentre en las o�cinas. Ante esto, se puede
decir que Asterisk utiliza el plan de marcado con un propósito más general: completar
el proceso de llamada en ambos escenarios, es decir, tanto cuando el otro extremo se
encuentre presente como cuando no haya nadie. El plan de marcado de Asterisk incluyen
reglas que especi�can qué hacer cuando:
Una llamada se recibe en un canal particular o es realizada por un determinado
usuario.
Una llamada se recibe a una determinada hora del día, de la semana, etc
El extremo receptor de la llamada no contesta en un determinado intervalo de
tiempo.
La persona que realiza la llamada presiona ciertos dígitos tras escuchar un menú.
La persona que realiza la llamada es dejada en espera o necesita entrar en una cola
de espera, etc; durante la espera el usuario puede escuchar música o un mensaje;
el usuario puede estar en espera inde�nidamente o durante un tiempo limitado,
tras el cual se llevarán a cabo otras acciones sobre la llamada.
61
4 ASTERISK.
La persona que realiza la llamada establece una multiconferencia o trans�ere la
llamada telefónica a otra extensión.
Y muchas más situaciones.
El plan de marcado de Asterisk, es especi�cado en el archivo de con�guración exten-
sions.conf. Este �chero suele residir en el directorio /etc/asterisk.
En este archivo podemos distinguir tres secciones, cada una encabezada por una palabra
entre corchetes que de�ne el nombre de la sección. La primera sección, llamada [gene-
ral], te permite establecer el valor de dos opciones usadas para controlar que el plan
de marcado pueda o no ser modi�cado en tiempo real, desde la líneas de comando de
Asterisk. La segunda sección, llamada [globals], se utiliza para de�nir variables cuyos
valores podrán ser leídos y modi�cados en el plan de marcado, y que no modi�can el
comportamiento normal de Asterisk, sino simplemente almacenan un valor. La tercera
sección de este archivo de con�guración, son los llamados contextos. Mientras que sola-
mente pueden existir una sección llamada "general" y otra "globals", en el caso de los
contextos pueden existir tantos como se quiera. Un contexto, de�ne diferentes modos de
operación de Asterisk, se trata de un conjunto de extensiones que podrán ser ejecutadas
según determinados criterios o a las que se le asocian un conjunto de permisos para
realizar ciertas acciones que pueden depender de:
Quién es el destinatario de la llamada.
Qué hora del día sea.
Qué tipo de terminal originó la llamada.
Por ejemplo, una llamada entrante al sistema puede escuchar un menú donde se le diga:
"Pulse 1 para contactar con el Departamento de Marketing, Pulse 2 para contactar con
el departamento de Ventas, etc". Tras ésto se marcarán los dígitos del departamento (
contexto) que con el se quiera hablar, y una vez allí sólo serán alcanzables un conjunto
de extensiones propias de ese departamento, de tal forma que si se marca otra extensión
o si se hace en un horario en el que no se encuentren disponibles, el sistema no permitirá
la llamada. Es una forma de controlar el conjunto de servicios a los que una llamada
puede tener acceso
62
4 ASTERISK.
Figure 4.3: Contextos en Asterisk.
4.3.2. INTERFACES.
Mientras el archivo "extensions.conf" es el lugar principal donde se con�gura el plan
de marcado, otros archivos son necesarios para con�gurar las interfaces VoIP y TDM
necesarias para permitir al servidor Asterisk comunicarse con el mundo exterior. Estos
�cheros son: zapata.conf, zaptel.conf, sip.conf y iax.conf.
4.3.2.1. INTERFACES TRADICIONALES.
El �chero "zaptel.conf" contiene información usada por Asterisk para determinar qué
interfaces para interactuar con los módulos o drivers, van a usarse con el hardware
que se tiene instalado. Este archivo se divide en secciones, en cada una de las cuales
se con�gura una única interfaz. Dichas interfaces permiten una abstracción entre el
hardware, el driver usado para controlarlo, y el código de Asterisk, de tal forma que si el
driver es actualizado no tenga que modi�carse el código de Asterisk, ya que las llamadas
a éste se seguirán haciendo a través de la interfaz.
Mientras "zaptel.conf" establece la elección del tipo de señalización para cada pieza
del hardware, "zapata.conf" la con�guración telefónica de cada canal. Éste establece
qué características telefónicas puede usar el canal (identi�cador de llamada, llamada en
espera, tono de llamada, etc). La con�guración de cada canal se hace antes que el canal
sea designado con un número, y heredará aquellas propiedades que hayan sido de�nidas
por encima de él.
63
4 ASTERISK.
4.3.2.2. INTERFACES SIP.
Asterisk implementa el protocolo SIP sólo parcialmente. Aunque el protocolo SIP de�ne
en sí mismo un modelo de comunicación bajo VoIP, Asterisk emplea SIP principalmente
para conectar teléfonos SIP y para conectarse a otros sistemas que también utilizan SIP.
Asterisk trata con SIP en términos de canales: extremos de una llamada. Se necesitan
dos canales para completar una llamada entre dos teléfonos SIP, de igual manera que si
quisiéramos establecer una comunicación entre un teléfono SIP y otro analógico.
Asterisk denomina a los dispositivos que se comunican con él como "SIP-peers". Un
canal es establecido cuando una llamada es recibida desde, o redirigida hacia, un SIP-
peer. Los teléfonos SIP, al igual que los servidores SIP y cualquier terminal que tenga
un User Agent y un Server Agent, es considerado como un "SIP-peer".
El archivo "sip.conf" está estructurado en secciones: una sección general y de carácter
exclusivo, seguida por secciones especí�cas para cada SIP-peer que esté conectado di-
rectamente a Asterisk. La sección general establece los parámetros que se aplicarán de
forma global al módulo SIP de Asterisk, mientras que cada sección especí�ca trata sólo
con la con�guración de un determinado "SIP-peer".
En la sección general se pueden establecer qué codecs pueden usar o les está permitido
usar a los terminales SIP, el contexto por defecto hacia el que se redigirán las llamadas
entrantes hechas por los terminales SIP, si los terminales serán autenti�cados, etc. Una
vez que se hayan establecido las funcionalidades globales en esta sección, se pasa a esta-
blecer la con�guración individual de cada dispositivo SIP que esté conectado a Asterisk.
4.3.2.3. INTERFACES IAX.
El archivo de con�guración "iax.conf" contiene toda la información que Asterisk necesita
para crear y gestionar canales iax. Al igual que los anteriores está divido en secciones,
de�nidas por una palabra entre corchetes indicando el nombre del canal al que hace
referencia, salvo la sección general que será donde se establecerán las parámetros globales
de con�guración del protocolo IAX.
La primera línea no comentada de todo archivo "iax.conf" debe ser la de�nición de
la sección general: [general]. Los parámetros de esta sección se aplicarán a todas las
64
4 ASTERISK.
conexiones que usen este protocolo, salvo a aquellos canales que sobreescriban el valor
de este parámetro.
A través del protocolo IAX, Asterisk puede compartir su plan de marcado, permitiendo
que otros servidores Asterisk lean este archivo, así como poder leer el plan de marcado
de un servidor remoto. Cuando esto sucede, el driver del canal IAX debe quedarse a la
espera de una contestación proveniente del servidor remoto antes de poder continuar con
otro proceso IAX relacionado. Ésto puede especialmente problemático cuando tenemos
múltiples planes de marcados anidados entre servidores remotos, con lo cual se podrá
apreciar un retraso razonable hasta que el resultado sea devuelto. Para evitar este com-
portamiento, existe una parámetro que le indica a Asterisk que cree un proceso separado
cuando se ejecute un plan de marcado remoto. El uso de este hilo permite que el driver
del canal IAX continúe con otro proceso mientras el hilo espera la respuesta.
IAX provee mecanismos de autenticación que permite un nivel de seguridad �able entre
terminales. Esto no signi�ca que la información de audio no pueda ser capturada y
decodi�cada , sino que puedes tener un mayor control de a quién le está permitido
establecer conexiones con tu sistema. Existen tres niveles de seguridad soportados por
los canales IAX, que será indicado en la variable "auth": texto plano, md5 y RSA.
Cuando varias llamadas van destinadas hacia el mismo terminal o nodo de la red, po-
demos agruparlas para reducir el ancho de banda usado por las cabeceras del paquete
IAX. Esta propiedad es propia exclusivamente del protocolo IAX y está diseñada para
sacar partido de las múltiples conexiones de larga distancia que pueden ser establecidas
entre dos nodos de la red. La reducción de carga se hace permitiendo que la señalización
de varios canales viaje en un mismo paquete.
65
5 DESARROLLO.
En este apartado se va a describir el proceso llevado acabo para el desarrollo del proyecto.
Va a detallarse la solución que se pretende implantar, el entorno de trabajo donde va
a desarrollarse, y se especi�carán cada una de las etapas o fases en las que se divide el
proyecto, así como los objetivos alcanzados en cada una de ellas.
5.1. DESCRIPCIÓN DETALLADA DE LA
SOLUCIÓN.
5.1.1. ENTORNO DE TRABAJO.
El proyecto será llevado a cabo en una de las aulas del laboratorio de VoIP del departa-
mento de Telemática. En dicha aula se dispone de un varios ordenadores personales, de
los cuales uno de ellos jugará el papel de servidor dedicado, donde se ejecutará el servidor
Asterisk, un servidor web Apache que permitirá la con�guración remota de la centralita
a través de una interfaz web y servidor de base de datos Mysql, donde se almacenan los
usuarios del sistema. El resto de ordenadores serán utilizados como clientes telefónicos,
es decir, desde un punto de vista lógico, actuarán como teléfonos IP, ya sea operando
bajo el protocolo señalización SIP o IAX.
La interconexión entre los ordenadores se realiza a través la red de área local del la-
boratorio, donde pueden distinguirse varias subredes privadas. La subred en la que se
trabaja, opera bajo un rango de IP's dadas por los siguientes valores:
Dirección de red: 192.168.100.0
Máscara: 255.255.255.0
67
5 DESARROLLO.
Figure 5.1: Red del laboratorio.
El router indicado en la �gura anterior, permite la interconexión de las redes privadas
del laboratorio con la red pública donde se encuentran conectados los ordenadores de
los profesores del Departamento de Telemática. En el router se llevaran a cabo las me-
didas oportunas para permitir la comunicación entre la subred privada donde se aloja la
centralita IP y la red pública del departamento, donde los ordenadores de los profesores
también actuarán, desde el punto de vista la PBX, como teléfonos IP conectados a dicha
centralita.
5.1.2. ARQUITECTURA LÓGICA DE LA RED.
La arquitectura lógica de red que da soporte al sistema de telefonía que se pretende
implantar, es la siguiente:
68
5 DESARROLLO.
Figure 5.2: Arquitectura lógica de la red.
Esta arquitectura responde a uno de los requisitos del proyecto, donde se pide que tanto
los ordenadores de los profesores como los que se encuentren situados en el aula del
laboratorio de VoIP, deben formar parte del mismo sistema de telefonía IP, es decir,
deben estar conectados a la misma central telefónica. Desde el punto de vista de la
centralita IP, no deben existir diferencias entre los ordenadores que residen en la misma
subred que Asterisk, la red del laboratorio, y los ordenadores de la red del Departamento.
5.1.3. ARQUITECTURA FÍSICA DE LA RED.
Como se ha comentado en el apartado anterior, la topología lógica de la red responde a
uno de los requisitos del proyecto, pero realmente la arquitectura que sobre la que se ha
implementado el sistema es la siguiente:
69
5 DESARROLLO.
Figure 5.3: Arquitectura física.
Se trabaja sobre redes basadas en la tecnología de acceso al medio Ethernet. Tanto en el
laboratorio como en el Departamento, se hace uso de "swicthes" ( puentes de red) que
permitirán compartir el medio físico entre las estaciones conectadas a una misma subred.
La interconexión de las dos redes se realiza mediante el router, donde será necesario
con�gurarlo de tal modo que permita el �ujo de datos en ambas direcciones, permitiendo
así publicar servicios alojados en la subred privada, como es el caso del servidor Asterisk
y el servidor Web Apache.
5.1.4. ELEMENTOS FUNCIONALES DEL SISTEMA.
Como parte del sistema de telefonía IP, pueden distinguirse los siguientes entidades,
encargadas de desempeñar alguna función dentro de la arquitectura de VoIP:
Terminales telefónicos: serán implementados por los ordenadores del laboratorio
y del Departamento. Cada ordenador ejecutará uno o varios "softphones" (pro-
gramas, en nuestro caso, software libre, con soporte para alguno o varios de los
siguientes protocolos de señalización: SIP, IAX y H.323). Desde este punto de vis-
ta, cada ordenador puede representar a más de un teléfono IP, siendo alcanzado
desde diferentes extensiones, que ,en principio, no mantienen ninguna relación. Se
70
5 DESARROLLO.
podía haber optado por utilizar teléfonos IP hardware, que presentan una calidad
mayor, pero por contra suponen un coste innecesario en este proyecto, ya que con
los clientes empleados se alcanza la funcionalidad deseada del sistema. Los modelos
y versiones del software utilizado, son los siguientes:
• Xlite 1105d : software gratuito que implementa el protocolo SIP.
• Ekiga 2.0.1: software libre que implementa el protocolo H.323.
• Sjphone 1.60.99: software gratuito que implementa el protocolo SIP.
• Moziax 0.9.14: plug-in para el explorador web Mozilla, que implementa el
protocolo IAX.
• Kiax 0.85: software libre que implementa el protocolo IAX.
IP PBX: se trata de la centralita telefónica implementada bajo tecnología IP. Esta
función será llevada a cabo por el servidor Asterisk, en su versión estable 1.2.
Media Gateway: hace la función de pasarela de medios, entre redes que operan
bajo distinta tecnología. Permite interconectar la red RDSI con la red IP. En este
caso, se hace uso de un hardware dedicado modelo Teldat, que permite tanto la
conexión de entradas de líneas tanto RDSI como de la RTC.
Servidor de Registro de terminales telefónicos: Cada teléfono IP del sistema, opere
bajo el protocolo SIP o IAX, debe poseer una cuenta con la que autenticarse
ante la centralita. Asterisk, jugará también este papel, actuando como registrador,
permitiendo así, a los distintos usuarios," loguearse" en el sistema. Desde el punto
de vista del protocolo SIP, Asterisk actuará como SIP Registra, controlando el
acceso al sistema, y como SIP Server, con el que se comunicará un usuario cada
vez que quiera establecer una llamada con otro usuario.
Servidor de base de datos Mysql: En estas bases de datos se almacenará información
referente tanto a los teléfonos IP, como a la con�guración de Asterisk. Será la
herramienta fundamental de la interfaz grá�ca utilizada.
71
5 DESARROLLO.
5.2. FASES DEL DESARROLLO
A continuación se describirán las distintas fases en las que se ha llevado a cabo el
proyecto. Se detallarán las distintas tareas que las componen y se dará un a visión de
la complicación que ha entrañado cada una. La descripción sigue un orden cronológico
conforme al desarrollo real, comenzando por la fase de puesta implantación del sistema
de telefonía IP base, donde se describe, partiendo desde cero, cómo llegar al entorno de
trabajo deseado: terminales telefónicos gestionados por una central telefónica; siguiendo
con la fase de adaptación de la interfaz de administración del sistema, que como su
propio nombre indica señalará los cambios realizados sobre dicha interfaz para dotar al
sistema de determinadas funcionalidades adicionales; y por último, la fase de integración
de la red de telefonía IP con la Red de Servicios Integrados, donde se pone de mani�esto
los pasos llevados a cabo para conseguir una correcta comunicación entre ambas.
5.2.1. PUESTA EN FUNCIONAMIENTO DEL SISTEMA DE
TELEFONIA IP.
5.2.1.1. DESCRIPCIÓN DEL SOFTWARE A USAR.
La versiones usadas durante el desarrollo del proyecto del servidor Asterisk y del resto
de programas necesarios para dotar a la IP PBX de una completa funcionalidad, han
sido las siguientes:
Asterisk Versión 1.2.13
Software que implementa la centralita de voz IP.
Zaptel Versión 1.2.11
Módulo del kernel que presenta una capa de abstracción entre el driver del hardware
y el módulo Zapata de Asterisk, encargado de comunicarse con los dispositivos
externos.
72
5 DESARROLLO.
Libpri Versión 1.2.4
Librería opcional que será útil cuando se este usando interfaces RDSI Primarias.
Se recomienda que se instale aunque no se haga uso de ninguna interfaz RDSI,
ya que esta es usada por otros hardware basados en TDM ( Multiplexación por
División en el Tiempo).
Addons Versión 1.2.5
Contiene programas útiles para poder almacenar CDR's (Call Detail Records) en
bases de datos MySQL, ejecutar archivos MP3 y también un intérprete para cargar
código Perl dentro de la memoria mientras se este ejecutando el proceso Asterisk.
Sounds Version 1.2.1
Este software permite ampliar el conjunto de mensajes de voz prede�nidos que
vienen con Asterisk, extendiéndolo a diferentes lenguas.
5.2.1.2. DEPENDENCIAS DEL SOFTWARE ASTERISK.
Para poder compilar Asterisk en nuestro sistema, hace falta satisfacer una serie de de-
pendencias, es decir, deben instalarse previos al software base, formado por los paquetes
principales Asterisk, Zaptel y Libpri, una serie de librerías sobre las que se apoya Aste-
risk:
1. bison
Necesario para parsear las expresiones del archivo extensions.conf
2. openssl y openssl-dev o libssl-dev
Necesario para la encriptación en el protocolo IAX versión 2.
3. termcap
Para que la información relevante en la interfaz de línea de comando aparezca con
distintos colores.
73
5 DESARROLLO.
4. ncurses-dev
Complemento del paquete anterior.
5. zlib
Requerido para el el protocolo Dundi. Protocolo usado para buscar en una base
de datos que actúa como listín telefónico, donde partir del nombre de usuario la
dirección IP asociada al mismo.
6. libnewt
Necesario para la aplicación "astman". Interfaz web que permite monitorizar el
estado de las distintas tarjetas hardware de comunicaciones que hayamos instalados
en el servidor Asterisk.
7. sendmail
Software utilizado por Asterisk para el envío de correos electrónicos cuando se hace
uso de dicha opción dentro del buzón de voz.
8. libspeex
Implementación abierta del codec de voz speex.
5.2.1.3. DESCARGA DEL SOFTWARE ASTERISK.
Va a comentarse las dos formas que existen de obtener el código fuente del sistemas
Asterisk , entendiendo por ello el conjunto de software: Asterisk, Zaptel y Libpri, y
posteriormente se dirá cuál de las dos formas es la más adecuada según el caso. Estas
formas atienden a la naturaleza del software, es decir, por tratarse de un software libre,
los procedimientos de descarga, compilación e instalación, así como la gestión del mismo,
di�eren en gran medida de los de un software bajo licencia propietaria, donde la fase de
instalación apenas presenta grandes problemas.
La primera forma es a través del servidor FTP o�cial de Asterisk, alojado en la siguiente
dirección: "ftp://ftp.digium.com". Esta es la forma más adecuada si quiere instalarse
un versión estable de Asterisk, es decir, una versión que no se encuentre en su fase de
74
5 DESARROLLO.
desarrollo o de pruebas, y donde la mayoría de los fallos hayan sido reparados, así como
también se ofrezca soporte técnico por parte de los desarrolladores.
La otra forma de obtener el código fuente, es a través del sistema CVS (Concurrent
Version System). Se trata de una herramienta que implementa un sistema de control de
versiones: mantiene el registro de todo el trabajo y los cambios en la implementación
de un proyecto (de un programa) y permite que distintos desarrolladores colaboren.
Cuando se hace alguna modi�cación sobre el código fuente, éste es enviado al servidor
CVS, de tal forma que la nueva modi�cación queda disponible para su descarga. En este
sistema existen varias ramas de desarrollo del programa, entre ellas la rama estable y
la rama inestable. Realmente, la rama estable, no es puramente una rama estable, sino
que va sufriendo una serie de modi�caciones menores hasta convertirse en una edición
totalmente estable, momento en el cual pasará a alojarse bajo el servidor FTP. Esta
forma es la más adecuada cuando se quiere probar nuevas características del sistema,
aún no muy maduras, o se quiere realizar alguna modi�cación al código fuente del
programa.
En nuestro caso, se ha optado por descargar el código desde el servidor FTP, ya que
el sistema va a implantarse en un entorno de producción, es decir, va a hacerse un uso
público del mismo, por lo que no quiere comprometerse la seguridad, ni estabilidad del
sistema.
5.2.1.4. COMPILACIÓN DEL CÓDIGO FUENTE.
En los siguientes apartados se describen los pasos seguidos en la compilación del códi-
go fuente de Asterisk, se comentan la funcionalidad de los mismos, así como algunos
consejos a tener en cuenta durante el proceso de compilación, derivados de las sucesivas
compilaciones fallidas que se llevaron a cabo. La compilación de los paquetes "Zaptel"
y "Libpri", aunque realmente no sean utilizados actualmente en el sistema, se hizo por
dejar abierta la posibilidad de dotar al sistema de cierta funcionalidad, añadiéndole nue-
vas interfaces hardware del tipo FXS, FXO, o de conexión a RDSI. Además, el hecho
de haber compilado previamente este software, evitará tener que recompilar Asterisk en
caso de querer añadir dicho soporte una vez que Asterisk haya sido compilado.
Zaptel-1.2.11
75
5 DESARROLLO.
Módulo del kernel que presenta una capa de abstracción entre el driver del hardware
y el módulo Zapata de Asterisk, encargado de comunicarse con los dispositivos
externos.
Mientras que Asterisk puede compilarse en diversas plataformas, los drivers Zaptel
han sido escritos especí�camente para comunicarse con el kernel Linux.
Antes de compilar los drivers Zaptel en un sistema Linux, debe veri�carse que
dentro del directorio /usr/src (directorio donde será almacenado el código fuente
descargado desde Internet), existe un enlace simbólico llamado "Linux" señalando
a las cabeceras del kernel que estemos usando. En caso de que no existiera habría
que crearlo:
# cd /usr/src
# ln -s /usr/src/'uname -r' /usr/src/linux
Una vez hecho esto, la compilación de los drivers "Zapata telephony" consiste
simplemente en la ejecución de los siguientes comandos:
# cd /usr/src/zaptel-1.2.11
# make clean
# make
# make install
Los dos programas que serán instalados junto con "zaptel-1.2.11", son: ztfcg y
zttool. El programa ztcfg es usado para leer la con�guración del hardware del ar-
chivo "/etc/zaptel.conf"; y "zttool", es una herramienta que sirve para comprobar
el estado del hardware instalado.
El driver zaptel debe ser el primero en cargarse en el sistema, una vez se halla
con�gurado el archivo "/etc/zaptel.conf", donde se recoge la con�guración de los
distintos software que tenga nuestro sistema. Las siguientes instrucciones pueden
ser útiles para cargar y comprobar si el driver está activo:
# modprobe zaptel
# lsmod | grep zaptel
76
5 DESARROLLO.
Libpri-1.2.4
La compilación e instalación de la librería "libpri" sigue el mismo procedimiento
descrito en el apartado anterior:
# cd /usr/src/libpri-1.2.4
# make clean
# make
# make install
"libpri" será usado por varios dispositivos hardware basados en multiplexación por
división en el tiempo, aunque a pesar de no tener ningún hardware instalado, se
recomienda su instalación en el sistema.
La librería "libpri" no necesita ser cargada como un driver o módulo del sistema,
sino que Asterisk la busca en tiempo de compilación y la con�gura él mismo para
su uso.
Asterisk-1.2.11
Para la compilación de Asterisk, se hace uso del compilador de C, gcc, invocado a
través del programa make. En este caso, no se necesita ejecutar previamente ningún
scripts de con�guración, sino simplemente ejecutar los siguientes comandos:
# cd /usr/src/asterisk-1.2.11
# make clean
# make
# make install
A parte de los comandos básicos utilizados anteriormente para la compilación de
Asterisk, se hizo uso de otras opciones de compilación que permitían añadir nuevas
utilidades al sistema:
# make samples
77
5 DESARROLLO.
Este comando nos va a permitir instalar en el sistema archivos de ejemplos de la
con�guración de Asterisk. Se han utilizado estos archivos como fuente principal
para la con�guración de las distintas aplicaciones, gracias a que contienen una
detallada información sobre la opciones soportadas por las aplicaciones, así como
sobre la sintaxis de los archivos.
# make webvmail
Se trata de un script, Asterisk Web Voicemail, que ofrece una interfaz grá�ca a tu
cuenta de buzón de voz, permitiéndote administrar e interactuar tu buzón de voz
remotamente desde un navegador web.
# make progdocs
Este comando crea documentación acerca del código fuente de Asterisk, usando la
herramienta doxygen que obtiene dicha documentación a partir de los comentarios
hechos en el código fuente. Para obtener con éxito la documentación, se necesita te-
ner instalado en nuestro sistema dicha herramienta antes de que este sea invocado.
Para �nalizar con la instalación de Asterisk, se compiló el paquete Asterisk-sounds,
dándole soporte a Asterisk para voces en español:
# cd /usr/src/asterisk-sounds
# make install
Una vez instalado el sistema, se ejecuta el servidor Asterisk para comprobar que funciona
correctamente. La ejecución puede hacerse de dos maneras diferentes:
Ejecución simple desde la línea de comandos:
# asterisk -cgvvvvv
Ejecución de Asterisk a través de un script de seguridad:
# /usr/sbin/safe_asterisk
78
5 DESARROLLO.
El objetivo principal del script "safe_asterisk" es, en caso de que el servidor falle, guardar
en un archivo los motivos que provocaron la caída de éste, útil para una posterior fase
de depuración, y reiniciarlo a continuación.
Con respecto a la seguridad ante ataques de red y casos similares, se ha evitado que
el servidor Asterisk se ejecute como usuario root, ya que esto puede comprometer la
seguridad del sistema si alguien logra acceso a él. Para ello se ha creado un nuevo
usuario, llamado "asterisk", cuyo grupo asociado poseerá el mismo nombre, y el cual se
ha vinculado a los siguientes grupos ya prede�nidos en cualquier sistema Linux: audio
(para permitirle el manejo de la tarjeta de sonido) y dialout (para poder tener acceso
de bajo nivel a las interfaces hardware).
5.2.1.5. CONFIGURACIÓN DEL SISTEMA DE VoIP.
El siguiente paso, una vez instalado el núcleo principal del sistema de telefonía IP,
consiste en la con�guración tanto de los parámetros del servidor como de los terminales
telefónicos que vayan a usarse, para permitir que estos últimos puedan comunicarse entre
sí, así como hacer uso de las numerosas aplicaciones que Asterisk ofrece.
5.2.1.5.1. ELECCIÓN Y CONFIGURACIÓN DE LOS TERMINALES.
De los dos protocolos principales de señalización de VoIP, SIP y H.323, se va a trabajar
exclusivamente con el protocolo SIP, ya que esta parece ser la tendencia dominante en los
sistemas de VoIP, debido a su sencillez y expansibilidad. También se va a hacer uso del
protocolo propietario IAX, protocolo desarrollado únicamente para su uso con el servidor
Asterisk, por su capacidad para evitar los problemas derivados de los entornos donde se
realiza NAT (Network Address Translation). Esta característica del protocolo IAX, en
nuestro caso es muy interesante, ya que se pretende la intercomunicación entre una red
pública y otra privada, donde además los servicios que deben publicarse se alojan dentro
de la red privada, con la consecuente recon�guración de los parámetros del router que
esto conlleva. Es por ello, que se tenderá a la utilización de clientes que implementen el
protocolo IAX, ya que gracias a que éste transporta todo el �ujo de datos a través de
la misma conexión, sólo será necesario abrir el puerto del router destinado a este efecto,
no como ocurriría en el caso de clientes SIP, donde el �ujo de datos es trasmitidos en
diferentes conexiones UDP/IP, con la consiguiente utilización de un amplio conjunto de
puertos.
79
5 DESARROLLO.
Todos los ordenadores del sistema que actúen como terminal telefónico, es decir aquellos
que posean soporte para los protocolos de señalización nombrados anteriormente, ten-
drán instalados tres clientes diferentes: uno de ellos implementa el protocolo IAX y los
otros dos se basan en el protocolo SIP.
Figure 5.4: Clientes VoIP.
A continuación se hace una breve descripción de los modelos utilizados:
SJphone Linux, v.1.60.299 (SIP).
Se trata de un teléfono software propiedad de la compañía SJ Labs Inc. Éste soporta
los protocolos SIP y H.323. Está disponible para varios sistemas operativos: MS
Windows, MAC OS X y Linux; y aunque bajo licencia propietaria, existe una
versión gratuita del mismo, de la cual se ha hecho uso.
Ekiga 2.0.1 (SIP).
Formalmente conocido como Gnome Meeting, es un software gratuito bajo licencia
open source,GPL. Soporta ambos protocolos, SIP y H.323, así como la transmisión
de vídeo. Además se caracteriza por la gran variedad de codecs de audio y voz de
alta calidad que soporta.
80
5 DESARROLLO.
MozPhone 0.9.14 (IAX).
Se trata de una extensión, plug-in, para el navegador web Firefox, disponible en
varios sistemas operativos: MS Windows, MAC OS X y Linux.
Programa Sistema Operativo Licencia Protocolo Versión
Ekiga Linux GPL SIP 2.0.1
SJphone MS Windows,Linux, Mac Propietaria SIP,H323 1.60.299
MozPhone MS Windows, Mac, Linux GPL IAX 0.9.14
Los parámetros de con�guración comunes a todos los "softphones" relacionados con la
conexión a la central telefónica Asterisk son los siguientes:
1. Dirección IP del servidor SIP de registro o, en el caso del protocolo IAX, de la IP
PBX.
2. Nombre de usuario (debe coincidir con el nombre de alguna cuenta que hayamos
con�gurado previamente en Asterisk).
3. Contraseña (coincide con la contraseña especi�cada en la cuenta de usuario).
5.2.2. MODIFICACIÓN DE LA INTERFAZ GRÁFICA DE
ADMINISTRACIÓN DEL SISTEMA.
En este apartado se va a describir el proceso llevado a cabo para la instalación y mo-
di�cación de la interfaz grá�ca FreePBX versión 2.1.1 de administración y gestión del
sistema Asterisk. Se detallarán los pasos necesarios para su instalación e interconexión
con el software Asterisk, se describirán los distintos módulos que componen la inter-
faz, la con�guración del servidor Apache necesaria para que la interfaz sea accesible vía
web, la integración del sistema con el servidor de base de datos MySQL versión XXX y
,por último, se explicarán las modi�caciones hechas sobre el código fuente para añadirle
nuevas funcionalidades al sistema.
81
5 DESARROLLO.
5.2.2.1. DESCRIPCIÓN DEL SOFTWARE.
FreePBX (Asterisk Manager Portal) es un interfaz grá�ca de usuario que permite con�-
gurar Asterisk sin necesidad de editar archivos de con�guración a mano. Su desarrollador
original fue la empresa Coalescent Systems Inc, aunque como la mayor parte de los pro-
yectos de software bajo licencia GPL, cuenta hoy día con una amplia comunidad de
desarrolladores y de subproyectos de software libre sobre los que se basa.
Alguna de las características más importantes que facilita la administración del servidor
Asterisk, son las siguientes:
Añadir o cambiar una extensión en cuestión de segundos.
Soporte nativo para clientes SIP, IAX y ZAP.
Rutado de llamadas entrantes basado en la hora del día.
Creación interactiva de menús de IVR (nteractive Voice Response).
Administración de colas de llamadas.
Detección y recepción de faxes.
Copia de seguridad y restauración del sistema.
Recoge estadísticas de llamadas, a través de la herramienta CDR. (Call Detail
Record).
Monitorización de canales con la herramienta FOP (Flash Operator Panel).
Grabación de llamadas.
El proyecto FreePBX se compone de varios subproyectos, que siguen desarrollos y man-
tenimientos independientes, englobados bajo una misma interfaz grá�ca:
82
5 DESARROLLO.
1. Núcleo del sistema FreePBX:
Se trata de un conjuntos de módulos que dotan al sistema de diversas funcionali-
dades de gestión y administración del servidor Asterisk. Cualquier funcionalidad
que integre FreePBX, viene implementada por un módulo, que debe ser activado
para poder usarse. Por defecto la interfaz trae la mayor parte de los módulos des-
activado, siendo tarea del usuario �nal activar aquellas funcionalidades que más le
interesen.
A continuación se realiza una breve descripción de los módulos más importantes:
Core: Éste módulo cubre la con�guración de extensiones y trunks. Por defecto,
viene activado, ya que se trata de una de las funcionalidades claves del sistema.
Feature Code Admin: Usado para la con�gurar algunas de las características
propias de las llamadas, tales como: DNS, Call Forwarding, etc.
Ring Groups : Te permite de�nir un conjunto de extensiones o dispositivos
que serán llamados cuando cierta extensión esté sonando.
Time Conditions : Te permite de�nir un particular periodo de tiempo, útil
para manejar el �ujo de llamadas entrante en función de la hora en la que
éstas recibidas.
Call Forward : Permite redireccionar una llamada.
Call Waiting : Activa y con�gura la llamada en espera.
Do-Not-Disturb: Activa el estado "No molestar" en una determinada exten-
sión.
Voicemail : Activa y con�gura el buzón de voz.
IVR: Permite crear menús interactivos.
On Hold Music: Permite administrar los archivos de música en espera, así
como añadir otros nuevos al sistema.
Queues : Permite la creación de colas de llamada.
83
5 DESARROLLO.
Recordings : Permite la creación de archivos de voz que podrán ser usados en
otras aplicaciones.
Asterisk CLI : Añade una herramienta que permite enviar comandos a la
consola de Asterisk e interpretar los resultados.
Conferences : Permite la con�guración y establecimientos de conferencias.
Backup & Restore: Añade una herramienta que permite hacer copia de segu-
ridad o restaurar los archivos de con�guración de la interfaz.
CDR ( Call Detail Record).
Se trata de un proyecto de software libre independiente al desarrollo de la interfaz
FreePBX, que viene integrado con la misma. Su nombre original es "Asterisk-Stat",
y provee a los administradores de Asterisk diferentes informes y grá�cas que les
permitirán analizar rápida y fácilmente el trá�co de sus servidores.
Algunas de sus características son:
• Informes diarios o mensuales sobre los detalles de las llamadas procesadas por
el servidor Asterisk.
• Trá�co mensual.
• Carga diaria.
• Comparativa de la carga de llamadas realizadas en varios días.
• Exportación de los detalles de las llamadas bajo el formato de archivos 'pdf'.
• Exportación de los detalles de las llamadas bajo el formato de archivo 'csv'
(Comma Separated Value).
• Integración con bases de datos MySQL y Oracle.
Por defecto, Asterisk guarda los detalles de las llamadas procesadas en archivos con
formato 'csv', en el directorio /var/log/asterisk/cdr-csv. El archivo "Master.csv"
contiene la información de todas las llamadas.
84
5 DESARROLLO.
Figure 5.5: Call Detail Record.
FOP:
Éste es otro proyecto independiente de software libre que viene integrado con la
interfaz FreePBX. Se trata de un panel, desarrollado en tecnología "FLASH", que
es ejecutado en un navegador web. Dicho panel muestra información relacionada
con el estado de la centralita en tiempo real. El diseño es con�gurable y pueden
visualizarse más de cien extensiones por pantalla.
El Flash Operator Panel, consiste en dos partes: un servidor escrito en Perl, y
un cliente �ash que se conecta a éste. El servidor se comunica con Asterisk a
través del puerto TCP 5038, mientras que el cliente establece una comunicación
con el servidor a través del puerto TCP 4445. El servidor se conecta al Manager
Asterisk, programa encargado de permitir el control remoto de la centralita, así
como de informar a todos aquellos que mantengan una conexión con él de todos
los eventos que tengan lugar en el servidor Asterisk: inicio/�nalización de llamada,
transferencias, estados de las extensiones, etc; y actúa de proxy entre el cliente
�ash y Asterisk.
85
5 DESARROLLO.
En el panel se re�ejan:
• Qué extensiones están desocupadas, sonado o no disponibles.
• Quién está hablando a quién.
• Estado de los clientes IAX y SIP registrados.
• Estado de las salas de conferencias.
• Estado de las colas de llamadas.
• Canales/extensiones en espera de ser atendidas.
• Agentes registrados en el sistema.
Y desde éste pueden llevarse a cabo las siguientes acciones:
• Colgar un canal.
• Transferir una de las partes de una llamada.
• Originar llamadas entre extensiones con sólo arrastrar el botón de la extensión
origen hacia la extensión destino.
• Establecer el identi�cador de llamada cuando se origina o trans�ere una lla-
mada.
86
5 DESARROLLO.
Figure 5.6: Flash Operator Panel.
ARI:
Asterisk Recording Interface, es el último de los proyectos independientes de sof-
tware libre que se integra bajo la interfaz FreePBX. Éste provee acceso vía interfaz
web al sistema de buzón de voz de Asterisk, así como a las grabaciones de las
llamadas monitorizadas.
Alguna de sus características son:
• Permitir acceso a los buzones de voz de forma grá�ca.
• Permitir acceso a la base de datos para ver el listado de llamadas realizadas.
• Autenticación mediante la contraseña establecida en los archivos de con�gu-
ración del buzón de voz de Asterisk.
87
5 DESARROLLO.
Figure 5.7: Asterisk Record Interface.
5.2.2.2. INSTALACIÓN DE LA INTERFAZ.
La instalación de la interfaz FreePBX, a partir del código fuente, es un proceso tedioso,
ya que ésta hace uso de un gran número de paquetes software. El mayor problema se
presenta a la hora de determinar qué paquetes hace falta tener instalados en el sistema
para que la compilación pueda llevarse a cabo de forma exitosa. A continuación se da una
descripción de la línea que hay que seguir para instalar la interfaz, para más información
remitirse al archivo INSTALL que acompaña a la distribución:.
1. Descarga del software:
La interfaz será descargada completamente desde la siguiente dirección web: "http://www.freepbx.org".
2. Satisfacción de las dependencias:
Para poder compilar la interfaz, hace falta que en el sistema donde va a instalarse
dicha interfaz, se tengan instalados los siguientes paquetes software:
libxml2
libxml2-devel
88
5 DESARROLLO.
libti�
libti�-devel
lame
Apache
mysql (or mysql-client)
mysql-devel (or libmysqlclient10-dev)
mysql-server
php4
libapache2-mod-php4
php4-pear
php-gd
perl
perl-CPAN
audio�le-devel (or libaudio�le-devel)
curl
sox
Instalación de los módulos Perl: "Net::Telnet", "IPC::Signal" y "Proc::WaitStat".
Una vez instaladas todas las dependencias, se prestará especial atención a la con�gu-
ración de los servidores Mysql y Apache. Dichas aplicaciones vienen integradas en el
paquete LAMPP (Linux Apache Mysql PHP Perl), se trata de un paquete software pre-
compilado que permite una fácil instalación y con�guración de los módulos anteriores.
Una vez ejecutadas las aplicaciones anteriores, sólo quedaría ejecutar el siguiente script:
"intall_amportal.sh", incluido en la distribución de FreePBX, que se encargará de leer
89
5 DESARROLLO.
ciertos archivos de con�guración de Asterisk y determinar los valores de los parámetros
necesarios para la interconexión con la centralita.
Finalmente, se pondrá en marcha la interfaz, a través del comando:
# amportal start
y se accederá a ella a través de un navegador web, apuntando a la siguiente dirección
web:
http://localhost/
5.2.2.3. MODIFICACIÓN DEL FLASH OPERATOR PANEL.
5.2.2.3.1. INTRODUCCIÓN.
Como se dijo anteriormente el FOP, consiste en dos partes, un servidor y un cliente. El
servidor establece una conexión con el Asterisk Manager en el puerto TCP/5038 y actúa
de proxy entre el cliente �ash y Asterisk. El cliente �ash se comunica con el servidor
proxy, utilizando el puerto TCP/4445, mediante su propio protocolo. De esta forma el
panel �ash re�eja los cambios de estado y envía comandos de control a Asterisk.
Mientras que la comunicación entre cliente y servidor se lleva a cabo mediante un pro-
tocolo cerrado desarrollado por el creador del FOP, la comunicación entre el servidor y
Asterisk Manager, se basa en una interfaz abierta de�nida dentro del proyecto Asterisk,
cuyo objetivo es permitir la integración de la centralita con otras aplicaciones softwa-
re. El Asterisk Manager permite a un programa cliente conectarse a una instancia de
Asterisk y enviar o recibir eventos sobre una conexión TCP/IP.
El formato del protocolo se basa en un conjunto de parejas "clave: valor" agrupadas
dentro de un mismo mensaje, delimitadas entre ellas por el carácter CRLF y utilizando
el doble carácter CRLF CRFL, para delimitar los mensajes entre sí:
Action: <action type><CRLF>
<Key 1>: <Value 1><CRLF>
<Key 2>: <Value 2><CRLF>
90
5 DESARROLLO.
...
Variable: <Variable 2>=<Value 2><CRLF><CRLF>
Algunos ejemplos de mensajes enviados al Asterisk Manager son:
Dial: Ejecuta la aplicación "Dial", utilizada para iniciar una llamada con una extensión.
Event: Dial
Privilege: call,all
Source: Local/900@default-2dbf,2
Destination: SIP/900-4c21
CallerID: <unknown>
CallerIDName: default
SrcUniqueID: 1149161705.2
DestUniqueID: 1149161705.4
Hangup: Hace que Asterisk cuelgue la llamada establecida en el canal espe-
ci�cado.
Event: Hangup
Channel: SIP/101-3f3f
Uniqueid: 1094154427.10
Cause: 0
Originate: Establece una llamada entre un canal y una extensión, ambas indicadas como
parámetros.
91
5 DESARROLLO.
ACTION: Originate
Channel: SIP/12345
Exten: 1234
Priority: 1
Context: default
Para una correcta comunicación, el protocolo debe seguir el siguiente comportamiento:
Antes de enviar cualquier mensaje, debe establecerse una comunicación con el
Asterisk Manager.
Los mensajes podrán ser enviados en cualquier dirección una vez que el otro ex-
tremo se haya autenticado ante el Asterisk Manager.
La primera línea de un mensaje debe ir delimitada con la clave "Action", en el caso
de que el mensaje sea enviado hacia el Asterisk Manager, y con la clave "Event"
o "Response" cuando sea el Asterisk Manager quien envía la información.
Figure 5.8: Modelo cliente-servidor.
5.2.2.3.2. FUNCIONAMIENTO DEL CLIENTE FLASH.
Simplemente apuntando un navegador web al directorio público donde se ha colocado
el cliente �ash, se muestra en pantalla la apariencia del mismo:
92
5 DESARROLLO.
Figure 5.9: Panel del FOP.
Cuando un canal está ocupado, o hay alguien en una conferencia, el círculo de dicho
botón se volverá rojo. Si éste está disponible el circulo se volverá verde, y ,por último,
si éste parpadea continuamente, indicará que el canal está la extensión está sonando.
Antes de que los usuario del FOP pueda realizar cualquier acción sobre el panel, es
necesario que éstos introduzcan el código de seguridad, sin dicho código, cualquier acción
será ignorada. Una vez se hayan registrado en el sistema, los usuarios podrán:
Colgar un canal: doble clic en el led rojo del botón.
Transferir una parte de llamada: arrastrando el botón de una de las partes de la
llamada hacia otra extensión.
Originar llamadas: arrastrar el botón de una extensión que se encuentre en estado
disponible hacia otra extensión en el mismo estado.
5.2.2.3.3. PROPUESTAS DE MODIFICACIÓN PARA EL FOP.
Además de las funcionalidades que, por defecto, poseen todos los FOP cuando se
instalan en un sistema a partir de su código fuente, en nuestro caso, se le exigirá que
éste cumpla una serie de requisitos:
93
5 DESARROLLO.
1. En vez de existir un código de seguridad único para todos los usuarios del panel,
debe asociarse un código de seguridad a cada extensión, de tal forma que , indirec-
tamente, esté código de seguridad pertenecerá al usuario de dicha extensión. De
esta forma se tiene un mecanismo para controlar, denegar o permitir, el tipo de
operaciones que puede llevar a cabo un usuario.
2. Ligado con lo anterior, un usuario sólo podrá establecer una llamada desde el FOP
si la extensión origene es la suya. De esta forma se limita que los usuarios puedan
originar llamadas entre extensiones de terceros o forzar a que sea ellos el extremo
receptor de la llamada.
3. El panel debe re�ejar de forma grá�ca qué usuarios se encuentran disponibles y
cuáles no en el sistema, en cada momento.
4. Cada vez que, desde el módulo "Administrador" de la interfaz FreePBX, se añada
una nueva extensión/usuario al sistema, debe re�ejarse dicho cambio en el panel,
esto es, aparecerá un nuevo botón que identi�que a la extensión añadida.
5. Comprobar, una vez que se ha iniciado el servidor proxy del FOP, cuál era el estado
de los usuarios registrados en el sistema Asterisk, de tal forma que el panel re�eje
el estado actual de los usuarios del sistema. Por defecto, cuando el FOP se inicia
muestra a todos los usuarios como registrados.
En el apartado siguiente, se verá como para dotar al sistema de estas nuevas funcionali-
dades será necesario modi�car el núcleo del FOP, es decir, el código fuente del servidor
que actúa como proxy entre el cliente �ash y Asterisk Manager.
5.2.2.3.4. ESTRUCTURA DEL CÓDIGO FUENTE.
Para el análisis del código fuente, escrito en Perl, del programa que implementa el
servidor proxy, se han empleado las siguientes herramientas:
Entorno de desarrollo Eclipse, basado en software libre, con soporte para multitud
de lenguajes de programación, que permite un cómodo estudio del código fuente
de un programa gracias a herramientas extraen información a partir del código.
94
5 DESARROLLO.
Editor de textos "Kate", con reconocimiento de distintos lenguajes de programa-
ción, entre ellos el lenguaje de "scripting" Perl.
El procedimiento seguido para dotar al programa de las nuevas funcionalidades mencio-
nadas anteriormente, ha consistido en:
FASE 1
Obtención de información comprensible a partir del código fuente del progra-
ma. Para ello, nos hemos valido de las herramientas de análisis del entorno
de desarrollo Eclipse. Se ha exportado el código fuente del servidor a formato
html, de tal forma que se han obtenido varios archivos html, que permiten
una cómoda desplazamiento a través del código. Como resultado, se parte de
una página html a modo de índice, donde se puede navegar por las distintas
secciones del código, es decir, se muestra un listado de las funciones que posee
el código, del conjunto de variables globales del mismo y del bucle principal,
de manera que pulsando sobre algunas de estas secciones accedemos a la par-
te del código donde están situadas y mostrándose, como encabezamiento de
la sección, un resumen sobre la funcionalidad de la misma, extraída de los
comentarios hechos por el autor en dicho código. El objetivo de esta fase es
obtener un visión global de cómo funciona el programa, así como localizar
aquellas secciones del código que van a ser objeto de modi�cación.
FASE 2
Estudio de cada sección del código en detalle. En esta fase se hace un estudio,
dentro de aquellas secciones de interés, de cómo se estructura el código, de
forma que pueda llevarse a cabo la modi�cación del mismo. Como resultado
�nal, se obtendrá un conjunto de funciones modi�cadas que implementarán
las funcionalidades extra deseadas.
FASE 3
Esta será un fase iterativa, junto con la anterior, que se encargará de depurar
el código modi�cado a �n de que se obtengan los resultados previstos. Para
ello, se hará uso de los mensajes de depuración que muestra el programa en
la salida estándar, que en nuestro caso es la pantalla. El código original del
95
5 DESARROLLO.
programa permite la ejecución del mismo con diferentes niveles de depura-
ción, lo que permitirá analizar la salida del programa ante los eventos de
interés.
5.2.2.3.4.1. DIAGRAMA DE FLUJO DEL BUCLE PRINCIPAL.
A continuación se describe el comportamiento general del programa a través del dia-
grama de �ujo del bucle principal. El bucle principal, representa a grandes rasgos cual
es la dinámica del programa ante determinados eventos. Para una mayor compresión del
programa haría falta indagar en las distintas funciones de las que se hace uso tanto en
el bucle principal, como ,a su vez, en otras funciones. Lo que se pretende dar en este
apartado es una visión general del programa, de tal forma que pueda mostrarse cuáles
son las directrices del programa:
96
5 DESARROLLO.
Figure 5.11: Bucle principal: 2o parte.
5.2.2.3.4.2. INDICE DE FUNCIONES MODIFICADAS.
En este apartado se muestra la relación existente entre los requisitos, que fueron men-
cionados anteriormente, y las modi�caciones, llevadas a cabo sobre distintas funciones
del programa, para hacer cumplir dichos requisitos:
Requisito 1 y 2:
En vez de existir un código de seguridad único para todos los usuarios del panel,
debe asociarse un código de seguridad a cada extensión, de tal forma que , indirec-
tamente, esté código de seguridad pertenecerá al usuario de dicha extensión. De
esta forma se tiene un mecanismo para controlar, denegar o permitir, el tipo de
operaciones que puede llevar a cabo un usuario
Ligado con lo anterior, un usuario sólo podrá establecer una llamada desde el FOP
si la extensión origene es la suya. De esta forma se limita que los usuarios puedan
98
5 DESARROLLO.
originar llamadas entre extensiones de terceros o forzar a que sea ellos el extremo
receptor de la llamada.
• Funciones implicadas:
◦ "read_password"
◦ "process_�ash_command"
Descripción:
"read_password( )"
Se trata de una nueva función añadida al programa. Esta función es
llamada a comienzo del programa, justo antes de entrar en un bucle
principal que gobernará el comportamiento del programa. Se invoca sin
argumentos de entrada y no devuelve ningún valor.
Su función es leer el archivo "op_password.cfg", y almacenar su valor,
línea a línea, en la variable global "lista_password", que después será
procesada en la función "process_�ash_command" .
"process_�ash_command (comando, socket)"
Es llamada en el bucle principal cada vez que se reciba un evento pro-
veniente de un cliente �ash. Recibe como argumentos de entrada, el
comando que el cliente �ash envía al servidor para que este lo ejecute y
el socket de la conexión cliente.
La función se encarga de darle un buen formato al comando que envía el
cliente y llamar a la función "send_command_to_manager", encargada
de enviarlo al servidor Asterisk indicado.
La estructura de la función es la siguiente:
diagrama de �ujo process_�ash_command (Dia)
Con la primera función conseguimos leer un archivo de claves, asociadas a cada
canal que esté registrado en el sistema, y almacenarlo en una variable global.
99
5 DESARROLLO.
Posteriormente, esta variable global será utilizada por la segunda función para
determinar si el canal que está ejecutando la acción tiene permiso para ello.
Requisito 3:
El panel debe re�ejar de forma grá�ca qué usuarios se encuentran disponibles y
cuáles no en el sistema, en cada momento.
• Funciones implicadas:
◦ "procesa_bloque"
• Descripción:
"procesa_bloque ( evento_manager, socket, asteriskmanproxy_server)"
Es llamada por la función "digest_event_block". Se encarga de proce-
sar los eventos enviados por el Asterisk Manager y crear las respuestas
correspondientes que serán enviadas a los clientes �ash. Como paráme-
tros, recibe el evento en sí, el socket que identi�ca la conexión y ,en el
caso que se esté usando, la conexión hacia el servidor proxy que maneja
varios servidores Asterisk.
La función devuelve una lista con las respuestas que ese evento origina,
y que deberán ser enviadas a los clientes �ash que tengan conexión con
ese servidor Asterisk.
La estructura de la función es la siguiente:
diagrama de �ujo de procesa_bloque (Dia)
La modi�cación consiste en analizar la variable "estado" contenida en el evento
que envía el Asterisk Manager. Cuando el valor de dicha variable coincida con
"Unmonitored", comprobaremos si el nombre del evento es "RegStatus", en cuyo
caso haremos caso omiso, evitando así enviar un comando al cliente �ash para que
muestre como no registrado en el sistema al canal re�ejado en la variable "channel".
Esto evitará confusiones, ya que tomaremos como referencia que la extensión de un
canal sólo estará desactivada ( botón en modo transparente) cuando dicho cliente
100
5 DESARROLLO.
no esté registrado en el sistema, obviando la opción de cada cliente de estar o no
monitorizado .
Requisito 4:
Cada vez que, desde el módulo "Administrador" de la interfaz FreePBX, se añada
una nueva extensión/usuario al sistema, debe re�ejarse dicho cambio en el panel,
esto es, aparecerá un nuevo botón que identi�que a la extensión añadida.
• Funciones implicadas:
◦ script "retrieve_op_conf_from_mysql.pl"
• Descripción
Este script es ejecutado cada vez que creamos un nuevo usuario en el siste-
ma Asterisk desde la interfaz FreePBX. Se encarga de reescribir los archivos
de con�guración del Flash Operator Panel, permitiendo de esta forma crear
nuevos botones asociados a las nuevos usuarios creados.
La modi�cación ha consistido en añadir una parte de código que permita,
una vez se hayan escritos los archivos de con�guración del FOP, leer el cam-
po "password" de la base de datos, tipo Mysql, de la que dicha interfaz se
vale para almacenar los datos de los usuarios, y una vez leído éste junto al
nombre de usuario al que va asociada, se escribe sobre el archivo llamado
"op_password.cfg".
Requisito 5:
Comprobar, una vez que se ha iniciado el servidor proxy del FOP, cuál era el estado
de los usuarios registrados en el sistema Asterisk, de tal forma que el panel re�eje
el estado actual de los usuarios del sistema. Por defecto, cuando el FOP se inicia
muestra a todos los usuarios como registrados.
• Funciones implicadas:
◦ "procesa_bloque"
◦ "request_astdb_status"
101
5 DESARROLLO.
◦ "process_cli_command"
• Descripción:
" request_astdb_status ( )"
Es llamada por la función "send_initial_status".
Se encarga de leer el archivo "op_astdb.cfg", que contiene un conjunto
de comandos que pueden ser enviado al Asterisk Manager, en función del
resultado de un consulta a un determinado campo en la base de datos
interna de Asterisk. Si el campo está lleno, entonces le serán enviados a
Asterisk los comandos indicados en ese apartado, en caso contrario, no
se hará nada, y se pasa a la siguiente consulta. Se trata de un archivo
con�gurable por el usuario.
La estructura de la función es la siguiente:
diagrama de �ujo de request_astdb_status" (Dia)
La modi�cación consiste en añadir un consulta, en el archivo "op_astdb.cfg",
a los campos "SIP/Registry" y "IAX/Registry" seguidos del nombre de
cada uno de los canales declarados en el archivo de con�guración de la
interfaz ( que a su vez deben coincidir con una parte o la totalidad de los
usuarios declarados en los archivos de con�guración de Asterisk), que es
donde Asterisk almacena a los usuarios registrados. Por otra parte, en la
función "request_satdb_status", es necesario modi�carla para recortar
el nombre del canal que va a consultarse evitando posibles confusiones
a campos de la base datos no existentes.
"procesa_bloque ( evento_manager, socket, asteriskmanproxy_server)"
Se trata de la misma función descrita anteriormente. En este caso la
modi�cación consiste una, vez que se haya �ltrado el tipo de evento,
y este sea del tipo "astdb", analizar el valor de la variable, que forma
parte del evento, "valor". En el caso en que esta variable tenga el valor
"no_estan_registrados", la función creará un comando que será envia-
do a los clientes �ash correspondientes, indicándole que el canal, cuyo
102
5 DESARROLLO.
identi�cador viene referenciado por la variable "channel", contenida en
el evento, se encuentra no registrado en el sistema en el momento de
iniciar el FOP.
"process_cli_command( evento_manager)"
Es llamada en el bucle principal, tras recibir un evento del tipo "�END
COMMAND�". Como argumento recibe el evento, enviado por el As-
terisk Manager como respuesta a un comando que previamente le fue
enviado y tuvo que ejecutar.
La función no devuelve nada, sino que se encarga de leer la salida del
comando ejecutado por el Asterisk Manager y convertirla en un pseudo-
evento, que posteriormente será tratado por la función "digest_even_bolck",
como si de un evento normal recibido se tratase.
La estructura de la función es la siguiente:
diagrama de �ujo de process_cli_command (Dia)
La modi�cación ha consistido, justamente, en deshacer el cambio que se llevó a cabo
sobre el nombre del canal, en la función "request_astdb_status", para permitir
hacer las consultas de los usuarios registrados, en la base de datos de Asterisk
5.3. INTEROPERABILIDAD H.323.
En este apartado va a describirse el proceso llevado a cabo para dotar de soporte H.323
a nuestro sistema de telefonía de voz sobre IP. En principio, nuestro sistema estaba
basado exclusivamente en tecnología SIP, protocolo de señalización que actualmente está
teniendo una amplia aceptación en el campo de la VoIP, pero las facilidades que nos ofrece
la centralita Asterisk, permiten la integración de estas dos tecnologías. Esta integración
nos permite aprovechar las ventajas de ambas, además de poder aprovechar dispositivos
que en un principio fueron pensados, exclusivamente, para operar bajo el dominio H.323.
En nuestro caso, se pretende la interconexión entre la centralita software Asterisk y
una centralita tradicional RDSI, a través de un gateway, que actuará de pasarela entre
103
5 DESARROLLO.
ambos sistemas, modelo TELDAT NUCLEOX-PLUS con interfaz H.323, exclusivamente.
Además, se pretende mediante el gateway, soportar terminales analógicos, ya sean tanto
centralitas como teléfonos analógicos.
Se detallarán las con�guraciones realizadas sobre el servidor Asterisk y el gateway TEL-
DAT, la arquitectura de red del sistema resultante, así como algunos problemas derivados
del carácter propietario de los codecs implicados en la comunicación.
5.3.1. OBJETIVOS.
Dotando al sistema de soporte H.323 se pretende conseguir una serie de objetivos:
1. Interconexión entre el servidor Asterisk y un gateway con interfaz H.323, que
permita extender la red de telefonía IP.
2. Integración de Asterisk con una centralita digital basada en tecnología RDSI.
3. Añadir soporte para telefonía analógica, por medio de una de las interfaces que
presenta el gateway.
Como consecuencia del carácter abierto, en cuanto a tecnologías de telefonía se re�ere,
de nuestro sistema, se pone de mani�esto la gran escalabilidad e interoperabilidad que
presentan los sistemas de VoIP actualmente. Puede verse cómo se sobrepasan las fron-
teras propietarias propias de los sistemas cerrados, donde la interoperabilidad suele ser
un factor costoso y ,a veces, infranqueable.
5.3.2. ARQUITECTURA DE RED.
La arquitectura de red resultante de integrar una serie de elementos nuevos es la siguien-
te:
104
5 DESARROLLO.
Figure 5.12: Integración SIP-H.323.
En la �gura anterior se ha representado un esquema de red basado en la conexión lógica
entre los elementos, pudiendo diferir de la arquitectura física de conexión que siguen
estos. Al añadir nuevos dispositivos al sistema, estos aportan nuevas funcionalidades y
modi�can el comportamiento de alguno de los elementos anteriores . A continuación,
se detallan el papel que juega y las funciones de cada uno de los nuevos dispositivos
añadidos al sistema y de aquellos que se han visto in�uenciados por esta integración:
Gateway: se trata de un gateway de medios, es decir, es el dispositivo encargado
de permitir la integración entre distintas tecnologías y de la transcodi�cación de la
información de audio y vídeo entre distintos formatos. Actúa de pasarela, permi-
tiendo que los datos multimedia codi�cados con diferentes codecs puedan pasar de
un entorno de red basado en H.323 hacia una red de telefonía tradicional, ya sea
analógica o digital (RDSI). Posee, por tanto, tres interfaces: interfaz de red H.323
sobre tecnología Ethernet, interfaz de telefonía analógica tradicional e interfaz de
telefonía digital RDSI. Dentro de la arquitecturas H.323 y SIP, éste actúa como ga-
teway, cuyo comportamiento puede ir o no supeditado a un "gatekeeper"; y desde
el punto de vista de la telefonía tradicional, analógica o digital, éste actuará como
terminal de red o como centralita, proveyendo la señalización correspondiente en
cada caso.
105
5 DESARROLLO.
Asterisk: este elemento, punto clave del sistema de telefonía, ha adquirido nuevas
funcionalidades y tareas. Es el encargado de hacer transparentes al resto de los
terminales de la arquitectura SIP, la conexión con los sistemas de telefonía tradi-
cional y telefonía H.323, de tal forma que los terminales SIP no tendrán constancia
de la existencia de otro tipo de terminales distintos a ellos. Desde el punto de vista
de la tecnología H.323, Asterisk, al igual que el elemento anterior, juega el papel
de gateway de medios, estableciendo de esta forma una comunicación directa con
el gateway. Esto permitirá que Asterisk pueda contactar con todos aquellos termi-
nales que puedan ser manejados por su gateway vecino. Para permitir este tipo de
comunicación, que se aloja bajo el estándar H.323, ha habido que dotar a Asterisk
de un nuevo software que implemente una interfaz H.323.
Terminales analógicos: se trata de teléfonos tradicionales, que pueden ser conecta-
dos al gateway TELDAT a través de una de las cuatro interfaces analógicas que
presenta. Sirven para dotar al sistema de conexión analógica.
Central telefónica RDSI: a través del gateway TELDAT, se podrán pasar llamadas
desde dicha centralita hacia la centralita Asterisk, y viceversa. De esta forma se
podrá permitir una comunicación directa y sin coste alguno entre los usuarios de
ambos sistemas, además de poder cursar llamadas IP por la red RDSI.
5.3.3. DESCRIPCIÓN DE LA SOLUCIÓN.
5.3.3.1. CONFIGURACIÓN DEL GATEWAY TELDAT.
Los routers NUCLEOX PLUS están orientados también hacia el mercado de acceso de
o�cinas remotas, aunque dadas sus mayores prestaciones y número de interfaces, pueden
ser utilizados también como gateway o pasarela en una red H.323. Están dotados de los
siguientes interfaces:
Un puerto LAN Ethernet 10BaseT,
Dos accesos básicos RDSI (2B+D).
Dos, cuatro o seis puertos serie V.24/V.35, según versiones.
106
5 DESARROLLO.
Un puerto serie de consola RS-232C para con�guración local.
Hasta 4 interfaces analógicos para voz-fax.
5.3.3.1.1. CONFIGURACION BASICA.
El acceso al interfaz de con�guración de los routers TELDAT puede realizarse me-
diante una conexión local al puerto serie de consola o de forma remota mediante una
conexión vía Telnet. En caso de utilizar el puerto de consola del router (situado en el
frontal del mismo), es necesario conectar éste al puerto serie de un PC, utilizando un
cable serie RS-232 (cable plano negro y adaptador RJ-45/Cannon9 proporcionado con
el router). En el PC se debe arrancar alguna aplicación de emulación de terminales (por
ejemplo, el HyperTerminal o Tera Term en Windows o el Minicom en Linux) y con�gurar
la conexión con las siguientes características: terminal asíncrono a 9600 bps, 8 bits de
datos, sin paridad, 1 bit de parada y ningún control de �ujo.
Para acceder de forma remota utilizando Telnet, es necesario haber con�gurado previa-
mente los parámetros TCP/IP del router (dirección, máscara, etc). Para ello se deben
seguir los pasos siguientes:
1. Acceder al router mediante el cable de consola.
2. Con�gurar los parámetros de IP del interfaz LAN (dirección IP, máscara, dirección
IP interna, etc) siguiendo los procedimientos descritos más adelante en este manual.
3. Salvar la con�guración y retrancar
4. Establecer una sesión Telnet contra la dirección IP del router desde algún ordena-
dor TCP/IP.
La interfaz de con�guración está basada en cinco procesos diferentes, cada uno de los
cuales permite acceder a un conjunto distinto de comandos de con�guración y monito-
rización. Cada proceso se identi�ca mediante un prompt diferente. El proceso 1, que se
identi�ca con el prompt �*� y se denomina de gestión de consola, es el proceso que se
activa nada más acceder al router. Desde él puede accederse al resto de procesos me-
diante la ejecución del comando "process x" (o de forma abreviada p x), siendo �x� el
107
5 DESARROLLO.
número del proceso deseado. Para volver al proceso 1 desde cualquier otro proceso se
debe pulsar Ctrl-p.
Figure 5.13: Procesos de con�guración en routers Teldat.
La utilidad del resto de procesos es la siguiente:
Proceso 2.
Se utiliza para visualizar eventos del sistema (trazas, errores, etc).
Proceso 3 (prompt �+�).
Se utiliza para monitorizar el funcionamiento del router (por ejemplo, para ver las
tablas de encaminamiento o conocer estadísticas de enlaces) o para acceder a las
herramientas de diagnóstico (por ejemplo, ping y traceroute).
Proceso 4 (prompt �Con�g>�).
Se utiliza para modi�car o visualizar la con�guración del equipo. Cualquier cambio
realizado en este modo no entra en efecto hasta que se salve la con�guración y se
re-arranque el router.
108
5 DESARROLLO.
Proceso 5 (prompt �Con�g$�).
Se utiliza para modi�car o visualizar la con�guración del equipo. Es similar al
proceso 4, aunque los cambios efectuados entrar en efecto inmediatamente.
5.3.3.1.2. CONFIGURACION IP.
Para acceder al entorno de con�guración IP, se deberá introducir el siguiente comando:
Con�g>PROTOCOL IP
IP con�g>
El comando ADD ADDRESS se debe utilizar para asignar direcciones IP a los interfaces
hardware de la red. Los argumentos de este comando incluyen el número del interfaz har-
dware (obtenido con el comando LIST DEVICES ), la dirección IP así como su máscara
asociada.
IP con�g>ADD ADDRESS NoInterfaz DirIP MASCARA
5.3.3.1.3. CONFIGURACION TELNET.
Los equipos de Teldat incorporan un servidor Telnet que permite acceder a la consola
de los mismos, con lo que se puede realizar la con�guración o monitorización remota-
mente, del mismo modo que se haría en la consola de modo local. También incluyen un
cliente Telnet para poder conectarse a cualquier servidor Telnet de un servidor remoto.
5.3.3.1.4. CONFIGURACION H.323.
Para entrar en la con�guración del Protocolo H.323, se accederá desde el menú
principal de la siguiente forma:
1. En el prompt (*), teclee PROCESS 4 (o P 4).
109
5 DESARROLLO.
2. En el prompt de con�guración (Con�g>), teclee PROTOCOL H323 o PROTOCOL
4, o bien P 4.
3. En el prompt de con�guración del protocolo H.323 (H323 Con�g>), utilice los
comandos de con�guración que se describen en este capítulo para con�gurar los
parámetros de dicho Protocolo.
TABLA DE LINEAS.
Agregar una entrada a la tabla de líneas. Estas entradas asocian un número de teléfono
(o un pre�jo) a una línea física del equipo. Al recibirse una llamada se busca la línea a
partir del número llamado y si se encuentra en la tabla se encamina la llamada hacia esa
línea. En el caso de que no se encuentre, esté ocupada o esté deshabilitada se buscará
una línea libre de acuerdo con las prioridades que se hayan con�gurado.
En algunos casos (cuando el tipo de línea es FXO o el interfaz es RDSI) se marca un
número en la RTB o en la centralita (PABX o PBX según el caso). En estas situaciones,
resulta útil poder marcar un número diferente al número llamante H323 original. Para
este propósito cuando se asignan números de teléfono a líneas se pueden especi�car
compresiones (digits to strip) o expansiones numéricas (dial-out pre�x). El orden de
aparición en la tabla es importante dado que se procesan de acuerdo con éste: una vez
que encuentra una entrada que se ajusta, deja de comprobar las siguientes. Las entradas
que se agregan con este comando se ponen al �nal de la tabla; si desea que ocupen otra
posición hay que utilizar el comando MOVE LINE.
Sintaxis:
H323 Con�g>ADD LINE
Line?[1]? 1
Telephone number? 918076565
Digits to Strip[0]? 2
Dial-Out Pre�x? 0
H323 Con�g>
110
5 DESARROLLO.
TABLA DE DIRECCIONES.
Agregar una entrada a la tabla de asignación de números de teléfono (o de pre�jos) a
direcciones IP. Se utiliza para saber cómo acceder a un número de teléfono remoto. El
orden de aparición en la tabla es importante dado que se procesan de acuerdo con éste:
una vez que encuentra una entrada que se ajusta al número de teléfono llamado, deja
de comprobar las siguientes. Las entradas que se agregan con este comando se ponen al
�nal de la tabla; si desea que ocupen otra posición hay que utilizar el comando MOVE
ADDRESS.
Sintaxis:
H323 Con�g>ADD ADDRESS
Telephone number? 243
IP address: [0.0.0.0]? 10.1.1.2
Codec-class Id[0]?
Number type (0 unknown,1 international,2 national,3 network,4 subscriber,
6 abbreviated,7 reserved)[0]? 2
Translation ID[0]? 3
Upon (0 caller, 1 called num)[0]? 1
Digits to Strip[0]? 1
Dial-Out Pre�x? 9001
Tech-pre�x[]?
H323 Con�g>
111
5 DESARROLLO.
5.3.3.1.5. CODECS.
La placa de VoIP permite la transmisión de voz y fax vía una red de tipo Internet. Con
el �n de reducir el ancho de banda se somete la señal digital a un proceso de compresión
de acuerdo con diferentes normas (codecs), que en el caso de la placa VoxNet pueden
ser: G.729 o G.723.1.
Ante estos dos tipos de codecs es necesario dotar a Asterisk de un módulo adicional que
le permita hacer transcodi�cación entre estos y el resto de codecs, debido a condiciones
de licencia, por tratarse estos de un estándar cerrado que no posee una implementación
libre.
5.3.3.2. CONFIGURACIÓN DE LA CENTRALITA ASTERISK.
Como se dijo anteriormente, Asterisk, dentro de la arquitectura H.323, jugará el papel
de Gateway. En principio, no existen módulos para Asterisk que implementen un Ga-
tekeeper de zona H.323, por lo que de momento no será posible tener terminales H.323
gestionados directamente por Asterisk. El esquema actual permitirá, sin embargo, una
comunicación puramente H.323 entre Asterisk y otro terminal propio H.323: gatekeeper,
gateway y/o cliente H.323.
5.3.3.2.1. CONFIGURACIÓN BÁSICA.
Existen actualmente dos implementaciones para H.323 disponibles para Asterisk, bajo
el modelo de canales: "chan_h323" y "asterisk-oh323". El primero de ellos viene incluido
en el paquete "asterisk-h323", y se trata de una versión antigua del módulo "asterisk-
oh323" que no continuó la vía de desarrollo de su predecesor. En principio, no debería
usarse la versión estable de este módulo, ya que su código está siendo actualizado, sino
más bien la versión disponible en el servidor CVS.
Asterisk-oh323, ha sido compilado y liberado bajo el nombre de OpenH323, y actual-
mente se encuentra en una fase de desarrollo estable. Ha sido este último, el módulo
elegido para implementar la pila H.323 y la funcionalidad de gateway.
5.3.3.2.2. EL MÓDULO OpenH323.
Su desarrollo ha sido dividido en dos partes:
112
5 DESARROLLO.
El "wrapper" (envoltorio): se trata de una librería que implementa la lógica que
actúa como pegamento y la capa de abstracción entre el interior de OpenH323 y
la aplicación, en nuestro caso Asterisk.
El "asterisk-driver": que representa un módulo estándar de canal en Asterisk.
5.3.3.2.2.1. ARCHIVO DE CONFIGURACIÓN DEL MÓDULO OpenH323.
A continuación se describirán las distintas secciones y parámetros principales de con-
�guración del módulo OpenH323, que deben ser leídos por Asterisk para poder actuar
como un gateway:
Sección General
�������
"gatekeeper" - Selecciona un gatekeeper con el cual registrarse o en su defecto
se considera que no existe uno.
"context" - Contexto por defecto donde irán dirigidas todas aquellas llamadas
entrantes que no tengan un contexto asociado.
Sección Register
�������-
Esta sección contiene uno o más grupo con el siguiente formato:
context=...
alias=...
alias=...
...
"context" - Señala el contexto del archivo "extensions.conf" donde irán las
llamadas entrantes cuya número marcado se relacione con alguno de los alias
o pre�jos especi�cados tras esta opción.
113
5 DESARROLLO.
"alias" - Especi�ca el alias H.323 asociado a Asterisk. Si este parámetro
contiene sólo números, entonces será usado para registrarse con el gatekeeper
como un número E.164.
Sección codecs.
������-
Esta sección contiene uno o más grupos con el siguiente formato:
codec=...
frames=...
"codec" - Especi�ca un codec a ser usado por el canal H.323. Actualmente
los valores posibles son: G711U, G711A, G7231, G729, GSM o G726.
"frames" - Especi�ca el número de tramas de voz codi�cada por cada paquete
RTP.
5.4. BATERIA DE PRUEBAS.
5.4.1. INTRODUCCIÓN AL ENTORNO DE PRUEBAS.
El entorno de trabajo está compuesto, por un lado, por: el aula de VoIP, situada en
el laboratorio del departamento de Telemática. En dicha aula se dispone de un varios
ordenadores personales, de los cuales uno de ellos jugará el papel de servidor dedicado,
donde se ejecutará la centralita Asterisk, un servidor web Apache que permitirá la con-
�guración remota de la centralita a través de una interfaz web y un servidor de base de
datos Mysql, donde se almacenan los usuarios del sistema. El resto de ordenadores serán
utilizados como clientes telefónicos, es decir, desde un punto de vista lógico, actuarán
como teléfonos IP, ya sea operando bajo el protocolo señalización SIP o IAX; Y por
otra parte, en los distintos despachos que componen el departamento de telemática, se
instalarán, sobre cada ordenador personal, los clientes necesarios para poder interactuar
con la centralita IP Asterisk.
Como ya se comentó en apartados anteriores, la topología de la red sigue el esquema
siguiente:
114
5 DESARROLLO.
Figure 5.14: Arquitectura físca de la red.
A continuación se hace un resumen de las propiedades del software utilizado en la fase
de pruebas:
Xlite version 1105d : Utiliza señalización SIP y soporta los codecs: G.711u,G.711a,
GSM, ilbc y Speex.
Ekiga version 2.0.1: Utiliza señalización SIP (aunque también puede utilizar seña-
lización H.323) y soporta los codecs: Speex, ilbc, GSM y G.711u/a.
Moziax version 0.9.14: Utiliza señalización IAX y soporta los codecs: ilbc, gsm,
speex y G.711u/a.
Kiax version 0.85: Utiliza señalización IAX y soporta los codecs: ilbc, GSM, Speex
y G.711u/a.
5.4.2. LISTA DE PRUEBAS.
Las pruebas que se van a detellar a continuación se llevaron a cabo en dos modalidades,
respecto al camino que siguen los datos multimedias:
Camino directo:
115
5 DESARROLLO.
Se trata de pruebas donde los clientes fueron con�gurados en la centralita con la
opción "canreinvite=no". Esto obliga a les obliga a establecer una comunicación
multimedia con el destino, a través de la centralita. Es decir, tanto el �ujo de datos
como la señalización es encaminada a través de Asterisk.
Camino indirecto:
Consiste en permitir a los clientes establecer una comunicación multimedia con el
destino sin que los datos de voz y audio tengan que atravesar la centralita Asterisk,
sino que estos serán entregados al destino a través de conecciones IP establecidad
directamente entre los clientes. Para ello, los clientes fueron con�gurados con la
opción "canreinvite=yes".
A modo de resumen, comentar principales ventajas de uno y otro modo son las siguientes:
la comunicación directa, permite liberar de carga de procesado a la centralita y reduce
el retardo de los datos, pero a su vez, no permite que clientes con distinto juegos de
codecs se comuniques, ya que Asterisk no puede hacer transcodi�cación de los datos.
También impide que pueda establecerse una multiconferencia entre tres o más usuarios,
debido a que la centralita no puede manejar el �ujo de datos. Respecto a la comunicación
indirecta, comentar que permite contrarrestar las ventajas del modo anteriror, pero a su
vez aumenta el retardo del �ujo, así como sobre carga a la centralita que debe procesar
los �ujos de todas las llamadas que se estén cursando en un momento dado.
A pesar de lo que se ha comentado anteriormente, debido al escaso tamaño del sistema
(menos de veinte terminales) y a la falta de reestricciones de ancho de banda (traba-
jamos en una red de area local), la diferencia de comportamiento en ambos modos de
comunicación es inapreciable, salvo en el caso en el que los terminales origen y destino no
tengan un conjunto de codecs en común. En este caso, si estamos operando bajo el modo
de comuniación directa, será imposible establecer la comunicación de datos multimedia,
ya que el extremo receptor no sabrá decodi�car la información que le llega. La única
forma de establecer la comunicación cuando los terminales no comparten ningún codecs,
es hacer que la comunicación pase a través de Asterisk, haciendo que éste actúe como
gateway, transcodi�cando los datos.
A continuación se detallan las pruebas realizadas. Las tablas que se muestrán indican,
con una x en el lado "Origen", el codec utilizado por el cliente que inicia la llamada;
y laz "x" en la correspondiente �la, en el lado "Destino", indican que las pruebas se
116
5 DESARROLLO.
llevarón a cabo con cada uno de estos codecs en el destino. Por ejemplo, la siguiente
con�guración:
Cuadro 5.1: EXTENSIÓN ORIGEN
ilbc gsm speex pcm
Cliente1 X
Cuadro 5.2: EXTENSIÓN DESTINO
ilbc gsm speex pcm
Cliente2 X X X X
, muestra que se hicieron pruebas con cada una de las parejas de codecs formadas por:
el codec de origen ilbc y cada uno de los codecs disponibles en el destino. De esta forma,
la con�guración:
Cuadro 5.3: EXTENSIÓN ORIGEN
ilbc gsm speex pcm
Cliente1 X X X X
Cuadro 5.4: EXTENSIÓN DESTINO
ilbc gsm speex pcm
Cliente2 X X X X
, indica que se hicieron tantas pruebas como posibles combinaciones de codecs entre
ambos grupos.
117
5 DESARROLLO.
5.4.2.1. Pruebas entre terminales que usan señalización SIP.
Cuadro 5.5: EXTENSIÓN ORIGEN
ilbc gsm speex pcm
Ekiga X X X X
Cuadro 5.6: EXTENSIÓN DESTINO
ilbc gsm speex pcm
Xlite X X X X
Resultado
En estos casos la calidad de la conversación de voz es excelente. Ambos clientes poseen
el mismo conjunto de codecs, con lo cual pueden negociar on cualquier de ellos para
establecer la comunicación. La manera de obligar a que se use un determinado codec
es marcándolo como preferido en la con�guración del cliente. El retardo de voz es muy
leve y la conversación no sufre cortes de voz, sino que se desarrolla de forma continua y
clara.
5.4.2.2. Pruebas entre terminales que usan señalización IAX.
Cuadro 5.7: EXTENSIÓN ORIGEN
ilbc gsm speex pcm
MozIAX X X X X
Cuadro 5.8: EXTENSIÓN DESTINO
ilbc gsm speex pcm
Kiax X X X X
118
5 DESARROLLO.
Resultado.
En estos casos, la calidad de la conversación se puede catalogar como perceptible pero
no molesta. Se experimentan ligeros cortes en la voz, independientemente de la pareja
de codecs que estemos usando. En cuanto al retardo de la voz, se encuentra en el mismo
nivel que la prueba anteriror: leve. Este comportamiento puede venir causado por la
calidad de la implementación del bu�er de recepción de cada uno de los clientes.
5.4.2.3. Pruebas entre terminales con distinta señalización (IAX , SIP y
H.323).
Cuadro 5.9: EXTENSIÓN ORIGEN
ilbc gsm speex pcm
Ekiga/Xlite X X X X
Cuadro 5.10: EXTENSIÓN DESTINO
ilbc gsm speex pcm
Kiax/MozIAX X X X X
Resultado:
Combinando las distintas parejas de clientes, la calidad de voz de la conversación era
molesta. Se experimentaban sucesivos y prolongados cortes de voz, que la hacían im-
practicable. A priori no hay ninguna causa aparente que justi�que este resultado, ya
que en principio, no se tenia ninguna limitación: ancho de banda su�ciente, poco trá�co
en la red y poca carga en la centralita. Hay que decir que la comunicación entre clien-
tes que usan distinto esquema de señalización, sólo es posible si la centralita hace de
intermediaria, permitiendo la integración de ambos protocolos.
Cuadro 5.11: EXTENSIÓN ORIGEN
ilbc gsm speex pcm
Ekiga/Xlite X X X X
119
5 DESARROLLO.
Cuadro 5.12: EXTENSIÓN DESTINO
G.729A
H.323 X
Resultado:
La calidad de la conversación es aceptable. La conversación es �uida y el retraso apenas
perceptible. La única salvedad es que debe añadirse un módulo a Asterisk para que
puede hacer transcodi�cación entre el codec G.729 y el resto. Sin esta módulo, sería
imposible establecer una comunicación, ya que a priori, Asterisk, no soporta este codec,
por tratarse de un codec que posee una licencia comercial.
Cuadro 5.13: EXTENSIÓN ORIGEN
ilbc gsm speex pcm
Kiax/MozIAX X X X X
Cuadro 5.14: EXTENSIÓN DESTINO
G.729A
H.323 X
Resultado:
Al igual que el resultado anterior, la calidad de la conversación en esta con�guración,
es aceptable, aunque experimenta ligeros cortes puntuales. Debe habilitarse el soporte
adicional en la centralita, para poder realizar transcodi�cación con este tipo de codec.
Resaltar que al igual que Asterisk no soporta este codec, tampoco lo hacen los clientes
utilizados, ya que estos están bajo los terminos legales de la licencia GNU GPL, la cual
no permite el uso de código propietario y código libre bajo el mismo proyecto.
120
5 DESARROLLO.
5.5. PUESTA EN MARCHA DEL SISTEMA DE
TELEFONIA IP EN EL AIT.
En los siguientes apartados se detallarán los procesos llevados a cabo para desplegar el
entorno de telefonía IP bajo el Area de Ingeniería de Telemática de la E.S.I.
5.5.1. CONFIGURACIÓN DE LOS TERMINALES
TELEFÓNICOS.
Los clientes a utilizar tendrán características distintas en función de la localización de
los despachos de profesores y de las salas de práctica. Aquellos despachos y salas que
se encuentren conectados a las red pública del departamento de Telemática, es decir,
aquéllos cuyas direcciones IP no sean privadas, estarán equipados con un software cuyas
caracterizados son:
Cliente telefónico a utilizar: Moziax versión 0.9.14
Tipo de señalización: Protocolo IAX.
Parámetros de con�guración:
Figure 5.15: Interfaz grá�ca de MozIAX.
121
5 DESARROLLO.
Figure 5.16: Parámetros de con�guración IP.
Figure 5.17: Elección de los codecs.
La justi�cación de esta elección se basa, fundamentalmete, en las ventajas que presenta
la utilización del protocolo IAX en redes donde se utilize NAT (Network Address Trans-
lation). Es el caso de nuestro sistema de telefonía IP, donde debe existir una interacción
entre las redes privadas del laboratorio y la red pública del departamento de Telemática.
El protocolo IAX, gracias a que tanto la señalización como el transporte de datos se lleva
a cabo a trave? de la misma conexión, nos asegura que una vez que la fase de registro
del cliente con la centralita se realice, se va a poder establecer una sesión multimedia sin
que haya que preocuparse por abrir determinados puertos en el router para permitir la
122
5 DESARROLLO.
comunicación. También cabe resaltar, la facilidad con que se instala dicho software, ya
que se trata de un complemento del navegador web Mozilla-Firefox.
Por otro lado, se tendrá cierta libertad en la elección de los clientes que se instalarán en
los PC's conectados a la red privada de la sala de VoIP del laboratorio de Telemática.
En principio se hará uso de los clientes Ekiga y Moziax, lo cual nos permitirá comprobar
como afecta a la calidad de la voz el uso de uno u otro software. Los parámetros de
con�guración de dichos terminales son los siguientes:
Figure 5.18: Interfaz grá�ca de Ekiga.
Figure 5.19: Parámetros de con�guración IP.
123
5 DESARROLLO.
Figure 5.20: Elección de los codecs.
Para �nalizar con la con�guración de cara al usuario, cabe señalar la utilidad de la apli-
cación FOP, integrada como parte de la interfaz grá�ca. Ésta permitirá ver el conjunto
de usuarios disponibles en cada momento en la red, así como los datos relativos a su
localización.
Para permitir una completa integración entre las redes privadas y públicas, hará �ata
publicar varios servicios que se sitúan en la red privada, los cuales deben ser accesibles
desde el exterior. Se trata del servicio web a través del cual los usuarios podrán acceder
a la interfaz grá�ca y del servicio de escucha de peticiones entrantes IAX en el puerto
4569 que es llevado a cabo por Asterisk.
5.5.2. CONFIGURACIÓN EN EL LADO DEL SERVIDOR
ASTERISK.
Una vez que ya se ha visto cómo van a con�gurarse los clientes telefónicos, hace falta
crear las respectivas cuentas a las que van a estar asociados cada uno de ellos. Es decir,
haciendo uso de la interfaz grá�ca, concretamente del módulo de gestión, hay que creear
tantas cuentas como usuarios haya en el sistema. Cada una de ellas guardará información
sobre la con�guración de los usuarios, los permisos que le son otogados y el conjunto de
codecs disponible que pueden usar. El proceso a seguir para dar de alta dichas cuentas
se detalla a continuación:
124
5 DESARROLLO.
Figure 5.21: Interfaz FreePBX:Creación de una extensión IAX.
Figure 5.22: Interfaz FreePBX:Con�guración de una extensión IAX.
125
5 DESARROLLO.
Figure 5.23: Interfaz FreePBX:Opciones de una extension IAX.
Cabe resaltar, que cada vez que se cree una nueva cuenta, se creará la correspondiente
entrada en los archivos de con�guración de la aplicación FOP y , por último, se reiniciará
el FOP, permitiendo de esta forma que los cambios sean observados inmediatamente.
Por último, haremos uso de los servicios ofrecidos por un operador de VoIP para es-
tablecer llamadas internacionales, ya que son estos los que cuentan con las tarifas más
reducidas para tales destinaciones, siendo gran parte de ellas gratuitas:
126
5 DESARROLLO.
Figure 5.24: FreePBX: Proveedores VoIP (Pre�jos).
Figure 5.25: FreePBX: Proveedores VoIP (Con�guración).
127
5 DESARROLLO.
Figure 5.26: FreePBX: Proveedores VoIP (Registro).
(foto3: captura de pantalla de los pasos necesarios desde la interfaz grá�ca para establecer
una ruta saliente hacia un operador, así como para aceptar las llamadas que nos lleguen
a través de éste.)
5.5.3. ASIGNACIÓN DE NÚMEROS TELEFÓNICOS.
El esquema a seguir en la asignación de números de teléfonos a cada uno de los terminales
que componen la red de VoIP, así como los pre�jos que permitirán distinguir los tipos
de llamadas realizadas son los siguientes:
Los terminales situados en los despachos de los profesores tendrán asignados núme-
ros que empiecen por el dígito "1", seguido de tantos otros como fuesen necesario
para agrupar a todos los usuarios de esa zona, de tal forma que la longitud de los
números de teléfonos debe ser la misma.
De manera similar, se organizarán los números telefónicos asignados a los termi-
nales situados en la instalaciones del Laboratorio de Telemática, con la salvedad
de que vendrán pre�jados por el número "2".
Figure 5.27: Redes del AIT utilizadas.
128
5 DESARROLLO.
Llamadas nacionales: los números de teléfonos de caracter nacional vendrán pre-
�jados por el caracter "0". Sin distinguir entre números de teléfonos móviles y
números de teléfonos �jos.
Llamadas internacionales: el pre�jo "*1" delante de un número de teléfono indicará
que se está intentando realizar una llamada hacia un destino internarcional.
5.5.4. PLAN DE MARCADO.
Se trata del núcleo fundamental que gobierna el funcionamiento de la centralita. Queda
resumido en el archivo de con�guración "extensions.conf", y en él se le indica a la cen-
tralita cómo manejar el �ujo de la llamada. Está compuesto por distintos "contextos",
donde cada uno de ellos se encarga de llevar a cabo ciertas funciones y de restringir otras
tantas. Las secciones en las que se ha dividido son las siguientes:
[internas]
Este contexto sólo permitirá realizar llamadas entre los usuarios de�nidos en el sistema.
El esquema que seguirán las mismas, será el siguiente: primeramente, durante diez se-
gundos, se esperará a que el destinatario de la llamada conteste. Tanto si no contesta,
como si recibimos una señal de ocupado, automáticamente accederemos a su bozón de
voz donde se le podrá dejar un mensaje, el cual será enviado a su dirección de correo
electrónico, además de quedarse registrado en su buzón.
[nacionales]
El comportamiento de la llamada es este contexto es similar al anterior, con la diferencia
de que no existirá un buzón de voz asociado a ningún número externo al sistema y que
será el usuario que origine la llamada el encargado de �nalizar la misma cuando crea
que el destino no está disponible.
[internacionales]
Como su propio nombre indica, este contexto maneja el �ujo de las llamadas cursadas
al extranjero.
[entrantes]
Este contexto manejará todas aquellas llamadas que sea entrantes al sistema. Es decir,
no aquellas hecha por un usuario perteneciente al mismo, sino las que son realizadas
129
5 DESARROLLO.
por usuarios ajenos al sistema. En prinicipio serán llamadas que nuestro operador de
VoIP nos enviará, y a las que mostraremos un menú interactivo donde el que llama
deberá marcar la extensión de usuario del sistema. En caso de error, se le anunciará
éste mediante un mensaje y se �nalizará la llamada. Las llamadas entrantes sólo pueden
alcanzar a extensiones internas, nunca podrán iniciar una llamada al exterior desde
nuestro sistema.
[salientes_restringidas]
En ellas se dará permisos para establecer llamadas de carácter internas y nacionales.
[salientes]
Desde este contexto podrán realizarse llamadas a cualquier destino, independientemente
de su localización.
Por simplicidad y para una mayor claridad, no mostraremos cada uno de los pasos que
sería necesario realizar en la interfaz de con�guración. En su defecto mostraremos el
resultado �nal que sobre el archivo "extensions.conf" tienen dichos pasos:
[general]
static=yes
writeprotect=yes
language=es
[internas]
;Llamadas dirigidas a los departamentos.
exten =>_1.,1,Macro(llamadas,${EXTEN:1})
;Llamadas dirigidas al laboratorio.
exten =>_2.,1,Macro(llamadas,${EXTEN:1})
[nacionales]
;Proveedor con tarifas más baratas a teléfonos �jos nacionales.
exten =>_09XXXXXXXX,1,Dial(SIP/0034${EXTEN:1}@proveedor1_voip)
exten =>_09XXXXXXXX,n,Hangup
;Proveedor con tarifas más baratas en llamadas a telfonos móviles nacionales.
130
5 DESARROLLO.
exten =>_06XXXXXXXX,1,Dial(SIP/0034${EXTEN:1}@proveedor2_voip)
exten =>_06XXXXXXXX,n,Hangup
[internacionales]
;Proveedor con tarifas más baratas en llamadas internacionales.
exten =>_*1.,1,Dial(SIP/${ENTEN:1}@proveedor3_voip)
exten =>_*1.,n,Hangup
[entrantes]
;Llamadas provenientes de la red de los proveedores de VoIP
;con los que nos hemos registrado.Serán redirigidas al contexto "internas"
exten =>s,1,Background(Mensaje de Bienvenida)
exten =>_1.,1,Goto(internas,${EXTEN},1)
exten =>_2.,1,Goto(internas,${ENTEN},1)
exten =>i,1,Playground(Mensaje_error)
exten =>t,1,Playground(Exceso_tiempo)
exten =>h,1,Hangup
[salientes_restringidas]
include =>internas
[salientes]
include =>internas
include =>nacionales
include =>internacionales
[macro-llamadas]
;En caso de no poder establecerse la llamada, se deja un mensaje de voz.
exten =>s,1,Dial(${ARG1},20)
exten =>s,n,Goto(${DIALSTATUS})
exten =>s,n(CHANUNAVAIL),Voicemail(u${ARG1}@default)
exten =>s,n,Hangup
exten =>s,n(BUSY),Voicemail(b${ARG1}@default)
exten =>s,n,Hangup
131
6 CONCLUSIONES Y LÍNEAS
FUTURAS.
6.1. CONCLUSIONES.
En este apartado se extraen las conclusiones de la realización del proyecto:
El objetivo principal de este proyecto es implantar un sistema de telefonía IP, basado
en un entorno centralizado donde todas las comunicaciones son gestionadas por una
central telefónica IP de carácter no propietario, basada en el software libre Asterisk.
Como complemento al sistema, se le pretende dotar de una interfaz grá�ca que permita
su administración y monitorización, así como de la capacidad de interconexión con el
sistema de telefonía RDSI.
Las fases de implantación del sistema de telefonía IP e interoperabilidad, se han desa-
rrollado en el tiempo previsto, siendo la fase de adaptación de la interfaz grá�ca, la que
ha presentado una mayor incertidumbre respecto a su duración. Esto se ha debido a que,
en principio, no se sabía cuánto tiempo costaría abordar el problema de la modi�cación
de código fuente de la lógica de la interfaz, junto con la resolución de los problemas
derivados de la misma (fase de depuración). Respecto al grado de satisfacción de cada
una de las fases decir que ha sido óptimo, aproximándose bastante el resultado �nal al
que se deseaba.
En la primera parte, podemos señalar la facilidad con la que se ha llevado a cabo el
despliegue del sistema base: centralita y clientes operando bajo un entorno de red IP; la
amplia variedad de clientes telefónicos existentes, que nos ha permitido optar por aquél
que mejor respondía a nuestras exigencias; y por último, la falta de exigencias respecto
al hardware de los computadores implicados.
132
6 CONCLUSIONES Y LÍNEAS FUTURAS.
En la segunda fase, cabe destacar el papel fundamental que ha jugado el software Eclipse,
entorno de desarrollo de carácter no propietario, de cuyas ventajas se ha valido la fase
de análisis y depuración del código fuente de la interfaz.
Se vuelve a poner de mani�esto la potencia del software libre en la tercera y última
fase de desarrollo del proyecto, donde gracias a módulos complementarios desarrollados
por terceros, nos ha permitido de forma rápida y poco costosa la integración de dos
tecnologías distintas, SIP y H.323, bajo un mismo software, Asterisk.
Hacer mención especial al entorno sobre el que se ha trabajado: el software libre. La
gran potencialidad que éste posee, nos ha brindado la posibilidad de adaptar el software
a nuestras exigencias, disponer de una gran diversidad de módulos y herramientas adi-
cionales que nos han facilitado y posibilitado ciertas labores y ahorrar costes en licencias
abusivas para el usuario �nal. Sin este hecho abordar dicho proyecto habría sido una
empresa difícil y costosa de realizar, ya que la integración de distintas tecnologías, así
como la capacidad de adaptación del software a nuestras necesidades no es compatible
con la �losofía del software propietario.
El producto está basado en el sistema operativo Linux para uso docente o empresarial
,junto con el software PBX Asterisk. Este software se caracteriza principalmente por su
�exibilidad y ser totalmente abierto. Se pueden añadir con un bajo coste de desarrollo
nuevas aplicaciones y funcionalidades y nuevos protocolos y codecs de compresión de au-
dio. Se ha aprovecha esta característica para ofrecer un producto y servicio personalizado
e innovar en aplicaciones y funcionalidades según sus necesidades.
6.2. LÍNEAS FUTURAS.
De las conclusiones expuestas anteriormente, así como de la experiencia adquirida duran-
te la elaboración de este proyecto, podemos exponer una serie de líneas de investigación
a tener en cuenta para obtener una mayor expansión y madurez del sistema de telefonía
propuesto:
Ofrecer garantías de QoS, para que de esta forma se dé cabida a la sustitución de
la telefonía tradicional por la telefonía de voz sobre IP.
133
6 CONCLUSIONES Y LÍNEAS FUTURAS.
La con�dencialidad y seguridad de los datos de los usuarios debe ser primordial en
un sistema de telefonía IP. Se debe dotar al sistema de mecanismos que permitan
el encriptado de las conversaciones telefónicas y evitar capturas de la comunicación
por terceros.
Ampliar el sistema permitiendo una interconexión entre la red de telefonía móvil
y la red IP. Para ello puede dotarse al servidor Asterisk de un gateway GSM, dis-
puesto para tal �n. Además ésto permitiría al sistema integrar centrales telefónicas
móviles.
Por último, dada la previsible expansión del sistema, sería aconsejable alojar el
servidor Asterisk en una máquina dedicada a su exclusivo funcionamiento, así
como dotarla de los requisitos hardware necesarios para nuestras necesidades.
134
7 BIBLIOGRAFIA
VoIP
[1] �Switching to VoIP�.Theodore Wallingford. O'Reilly.Junio 2005.ISBN: 0-596-00868-6.
[2] Base de datos sobre VoIP. http://www.voip-info.org
[3] Enciclopedia libre Wikipedia. http://www.wikipedia.org
Asterisk
[4] �Asterisk: The Future of Telephony�. Leif Madsen, Jared Smith, Jim Van Meggelen.
O'Reilly. Septiembre 2006.ISBN: 0-596-00962-3.
[5] �Asterisk and IP Telephony�. Paul Mahler. Signate. ISBN 09759992-0-6
[6] ASTERISK. http://www.asterisk.org
[7] DIGIUM. http://www.digium.com
[8] IAXTEL. http://www.iaxtel.com
[9] CORNFED. http://www.cornfed.com/iax.pdf
[10] VOIP-INFO. http://www.voip-info.org/wiki-asterisk
[11] http://linuxdevices.com/articles/AT8678310302.html
Software
[12] SOURCEFORGE. http://sourceforge.net
[13] FESTIVAL. http://www.cstr.ed.ac.uk/projects/festival/
[14] X-LITE. http://www.xten.com
[15] SJPHONE http://www.sjlabs.com/
[16] FREEPBX http://www.freepbx.org/
135
top related