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 justicado 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 ineciencia

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/beneco de las redes de datos

de las empresas, aprovechando sus benecos 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 dene 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 benecio

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 ocinas 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 modicar 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, congure 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 inuye la hetereogenidad de redes en la calidad de la comuni-

cación.

En denitiva, 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 maniesto 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 modicació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, conguració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 ineciente 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 taricación de llamadas.

4. Integración de nuevos servicios y unicació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-Eort"

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 eciencia 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 Codicados (MIC), donde la señal analógica será

muestreada a la vez que su amplitud será discretizada y codicada en formato binario.

Para establecer una llamada telefónica, un teléfono tradicional, sea analógico o digital,

requirirá un enlace con suciente 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 signica 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 codicar 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

codicadores de la señal, como en el receptor, como decodicares 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 denidos por recomendaciones

de la ITU-T, áquellas pertenecientes a la variedad G ( Trasmision system and media).

Dentro del grupo de codec denidos 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 codicació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 codicados 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 codican 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 coecientes 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 codicado bien mediante índices o por forma de onda, según el codec, y se

transmite junto con los coecientes 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 codicación/decodicación de 64 kbps que usa

8 bits para codicar 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 codicació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 transcodicados 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 dierential 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 suciente 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

suciente 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 benecio 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 codicación y decodicació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 codicado, transportado, decodicado 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 codicado. 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 notiquen 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 decodicador 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 coecientes 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 modica-

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 signica 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 identican: número de telefóno, dirección IP, etc. Este

proceso puede ser autenticado si se desea.

En la conguració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 autenticació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 identicador cuando éste efectue una llamada.

2. El gatekeeper guarda toda la información proveida por el terminal en memoria,

para posterior uso cuando autentique 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

Conrm), 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 taricació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 denió 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 especicar 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 dene 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 dene H.225:

En proceso: esto signica que el terminal de origen está intentando establecer

una conexión de red con el terminal de destino.

Alerta: esto signica que el extremo receptor está siendo noticado 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 signica que el receptor ha aceptado la llamada y que un canal

de audio/video puede ser establecido.

Liberar: esto signica 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 noticarse 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 taricació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, identicá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 conrmación ARQ (ACF). Esto conrma 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 vericar 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 inuir 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: dicultad 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 codicadas 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 denición completa se encuentra

recogida en las RFC's 3261-3265. El propósito denido 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 conguración más usual es usar servidores SIP, a los

cuales el resto de los teléfonos SIP deberán noticar 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 clasican 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, taricació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 prejo "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 clasican 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 conrmar que el cliente solicitante ha recibido una respuesta

nal desde un servidor a una solicitud INVITE, reconociendo la respuesta como

armativa.

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: notica 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 noticar 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 clasicados 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 codicada.

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

denen 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á codicado usando ASCII, ni ASN.1,

en vez de esto, usa un esquema propietario de codicado 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

especicació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 Método SIP Protocolo RAS Tramas de control

y admisión REGISTER IAX REG

Establecimiento y Método SIP INVITE Protocolo H.225 Tramas de control

liberación de llamada IAX NEW y

HANGUP

Negociación de capacidades, Protocolo de Protocolo H.245 Meta-trama de

codecs y puertos para datos Denición de Sesión Información de

multimedias Capacidades IAX

Paquetización y transmisión Protocolos Protocolos Tramas IAX

de muestras de sonido RTP/RTCP RTP/RTCP VOICE/DATA

Streaming de video y Protocolo RTSP Ninguno Ninguno

audio grabado recomendado recomendado

Codicación de trama ASCII ASN.1 Binario

Simulitud de mensajes HTTP RDSI/Q.931 Propietario

Rutaje de llamada descrito Proxy Gatekeeper- Software PBX

como rutado

Dipositivo de referencia Registrar Gatekeeper Servidor

para el rutaje de llamadas

Ruta de llamada Redirect Señalización Señalización

independiente directa directa

Interfaz RDSI Ninguna Gateway H.323 Ninguna

recomendada recomendada

Identicación de terminales SIP-URI, dirección Dirección E.164 SIP-URI,

de email, dirección dirección de

E.164 o alias email, dirección

E.164 o alias

Conexión a traves de Redirección a través Redirección a No se necesita

cortafuegos de Proxy/softPBX traves de Gate- Proxy

keeper/SoftPBX

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 noticaciones 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 denido 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á suciente). 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 eciente comunicación entre

servidores Asterisk.

Mediante el soporte de una mezcla de servicios de telefonía tradicionales y de VoIP,

Asterisk permite construir ecientemente 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 ocina 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 notica 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 (PBX Manual). 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 denido 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

codicar o decodicar 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 codicar y decodicar 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 modicar

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 conguración de Asterisk, excepto la

conguración de las interfaces hardware.

57
 4 ASTERISK.

/etc/asterisk Contiene los archivos relacionados con la conguración

de Asterisk, excepto la conguració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

conguración. Este archivo nunca se modica 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 conguració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 Identicador 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, especicadas 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 conguració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 conguració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

Congura 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á congurada.

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 ocinas. 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 especican 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 indenidamente 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 transere la

llamada telefónica a otra extensión.

Y muchas más situaciones.

El plan de marcado de Asterisk, es especicado en el archivo de conguració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 dene 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 modicado en tiempo real, desde la líneas de comando de

Asterisk. La segunda sección, llamada [globals], se utiliza para denir variables cuyos

valores podrán ser leídos y modicados en el plan de marcado, y que no modican el

comportamiento normal de Asterisk, sino simplemente almacenan un valor. La tercera

sección de este archivo de conguració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, dene 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 congura el plan

de marcado, otros archivos son necesarios para congurar 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 congura 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 modicarse 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 conguración telefónica de cada canal. Éste establece

qué características telefónicas puede usar el canal (identicador de llamada, llamada en

espera, tono de llamada, etc). La conguración de cada canal se hace antes que el canal

sea designado con un número, y heredará aquellas propiedades que hayan sido denidas

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 dene

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 conguració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 autenticados, etc. Una

vez que se hayan establecido las funcionalidades globales en esta sección, se pasa a esta-

blecer la conguración individual de cada dispositivo SIP que esté conectado a Asterisk.

4.3.2.3. INTERFACES IAX.

El archivo de conguració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,

denidas 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 conguración del protocolo IAX.

La primera línea no comentada de todo archivo "iax.conf" debe ser la denició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 signica que la información de audio no pueda ser capturada y

decodicada , 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
 4 ASTERISK.

Figure 4.4: Tramas del protocolo IAX.

66
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 especicará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 conguració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

congurarlo 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 conguració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 maniesto

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 predenidos 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,

dieren 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 ocial 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 modicación sobre el código fuente, éste es enviado al servidor

CVS, de tal forma que la nueva modicació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 modicaciones 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 modicació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 vericarse 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 conguració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

congurado el archivo "/etc/zaptel.conf", donde se recoge la conguració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 congura é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 conguració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

conguración de Asterisk. Se han utilizado estos archivos como fuente principal

para la conguració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 predenidos 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 conguració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 reconguració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 conguració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

congurado previamente en Asterisk).

3. Contraseña (coincide con la contraseña especicada 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-

dicació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 conguració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 modicaciones 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 conguració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 conguració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 congurar algunas de las características

propias de las llamadas, tales como: DNS, Call Forwarding, etc.

Ring Groups : Te permite denir un conjunto de extensiones o dispositivos

que serán llamados cuando cierta extensión esté sonando.

Time Conditions : Te permite denir 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 congura la llamada en espera.

Do-Not-Disturb : Activa el estado "No molestar" en una determinada exten-

sión.

Voicemail : Activa y congura 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 conguración y establecimientos de conferencias.

Backup & Restore : Añade una herramienta que permite hacer copia de segu-
ridad o restaurar los archivos de conguració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 congurable 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 reejan:

• 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 identicador de llamada cuando se origina o transere 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 congu-

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.

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

audiole-devel (or libaudiole-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 congu-

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 conguració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 conguració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 reeja 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 denida 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-

cicado.

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 reejar 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 reejarse dicho cambio en el panel,

esto es, aparecerá un nuevo botón que identique 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 reeje

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 modicar 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 modicació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 modicación del mismo. Como resultado

nal, se obtendrá un conjunto de funciones modicadas 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 modicado 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.

o
Figure 5.10: Bucle principal: 1 parte.

97
 5 DESARROLLO.

o
Figure 5.11: Bucle principal: 2 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 modicaciones, 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 reejar 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 identica 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 modicació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 reejado 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 reejarse dicho cambio en el panel,

esto es, aparecerá un nuevo botón que identique 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 conguración del Flash Operator Panel, permitiendo de esta forma crear

nuevos botones asociados a las nuevos usuarios creados.

La modicación ha consistido en añadir una parte de código que permita,

una vez se hayan escritos los archivos de conguració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 reeje

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

congurable por el usuario.

La estructura de la función es la siguiente:

diagrama de ujo de request_astdb_status" (Dia)

La modicació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 conguración de la

interfaz ( que a su vez deben coincidir con una parte o la totalidad de los

usuarios declarados en los archivos de conguración de Asterisk), que es

donde Asterisk almacena a los usuarios registrados. Por otra parte, en la

función "request_satdb_status", es necesario modicarla 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

modicació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.

identicador 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 modicació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 conguraciones 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 reere,

de nuestro sistema, se pone de maniesto 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

modican 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 inuenciados 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 transcodicación de la

información de audio y vídeo entre distintos formatos. Actúa de pasarela, permi-

tiendo que los datos multimedia codicados 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

ocinas 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 conguración local.

Hasta 4 interfaces analógicos para voz-fax.

5.3.3.1.1. CONFIGURACION BASICA.

El acceso al interfaz de conguració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 congurar

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 congurado 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. Congurar 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 conguració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 conguración está basada en cinco procesos diferentes, cada uno de los

cuales permite acceder a un conjunto distinto de comandos de conguración y monito-

rización. Cada proceso se identica mediante un prompt diferente. El proceso 1, que se

identica 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 conguració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 Cong>).

Se utiliza para modicar o visualizar la conguración del equipo. Cualquier cambio

realizado en este modo no entra en efecto hasta que se salve la conguración y se

re-arranque el router.

108
 5 DESARROLLO.

Proceso 5 (prompt Cong$).

Se utiliza para modicar o visualizar la conguració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 conguración IP, se deberá introducir el siguiente comando:

Cong>PROTOCOL IP

IP cong>

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 cong>ADD ADDRESS No Interfaz 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 conguració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 conguració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 conguración (Cong>), teclee PROTOCOL H323 o PROTOCOL

4, o bien P 4.

3. En el prompt de conguración del protocolo H.323 (H323 Cong>), utilice los

comandos de conguración que se describen en este capítulo para congurar 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 prejo) 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 congurado.

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 especicar

compresiones (digits to strip) o expansiones numéricas (dial-out prex). 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 Cong>ADD LINE

Line?[1]? 1

Telephone number? 918076565

Digits to Strip[0]? 2

Dial-Out Prex? 0

H323 Cong>

110
 5 DESARROLLO.

TABLA DE DIRECCIONES.

Agregar una entrada a la tabla de asignación de números de teléfono (o de prejos) 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 Cong>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 Prex? 9001

Tech-prex[]?

H323 Cong>

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 transcodicació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 prejos especicados tras esta opción.

113
 5 DESARROLLO.

" alias " - Especica 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 " - Especica un codec a ser usado por el canal H.323. Actualmente

los valores posibles son: G711U, G711A, G7231, G729, GSM o G726.

" frames " - Especica el número de tramas de voz codicada 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 congurados 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 congurados 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 transcodicació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á decodicar 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, transcodicando 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

conguració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 conguració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 conguració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 buer 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 justique este resultado, ya

que en principio, no se tenia ninguna limitación: ancho de banda suciente, 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 transcodicació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 conguración,

es aceptable, aunque experimenta ligeros cortes puntuales. Debe habilitarse el soporte

adicional en la centralita, para poder realizar transcodicació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 conguración:

Figure 5.15: Interfaz gráca de MozIAX.

121
 5 DESARROLLO.

Figure 5.16: Parámetros de conguración IP.

Figure 5.17: Elección de los codecs.

La justicació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

conguración de dichos terminales son los siguientes:

Figure 5.18: Interfaz gráca de Ekiga.

Figure 5.19: Parámetros de conguración IP.

123
 5 DESARROLLO.

Figure 5.20: Elección de los codecs.

Para nalizar con la conguració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 congurarse 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 conguració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:Conguració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 conguració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 (Prejos).

Figure 5.25: FreePBX: Proveedores VoIP (Conguració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 prejos 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 prejados 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 prejo "*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 conguració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 denidos 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 conguració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 modicació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 maniesto 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 condencialidad 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
 7 BIBLIOGRAFIA

Programación

[17] Documentación sobre Perl. http://www.perl.org/

[18] Entorno de desarrollo integrado Eclipse. http://www.eclipse.org/

136