Embed Size (px)
Citation preview
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.10: Bucle principal: 1o parte.
97
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
