Implantación de red · para comunicar teléfonos virtuales instalados en los hosts de la red con la red PSTN. Los usuarios de la red VoIP podrán llamarse entre ellos, llamar a la

Implantación de red

en el departamento de

ASIR

Implantación de Red VoIP en el departamento de Asir Mauro Fernández Quiñones

1. Estudio del problema y análisis del sistema 1.1. Escenario actual de la red del departamento

2. Objetivos 3. Solución elegida para implementar la red VoIP 4. Modelación de la solución

4.1. Recursos 4.2. Escenario de Asir con la red VoIP implantada

5. Planificación temporal 6. Documentación del sistema

6.1. Breve historia de la telefonía tradicional 6.2. Funcionamiento sistema de telefonía convencional 6.3. VoIP. ¿Qué es? 6.4. Ventajas e inconvenientes de VoIP 6.5. Elementos comunes en una red VoIP 6.6. Puertos FXS y FXO 6.7. Escenario de Asir con ATA VoIP 6.8. Asterisk

6.8.1. Breve historia de Asterisk 6.8.2. ¿Qué es? 6.8.3. Protocolos de VoIP que usa Asterisk 6.8.4. Funcionamiento del protocolo SIP 6.8.5. Versiones 6.8.6. Arquitectura 6.8.7. Directorios 6.8.8. Ficheros 6.8.9. Canal SIP

6.8.10. DialPlan 6.8.11. Asterisk CLI 6.8.12. DAHDI 6.8.13. Interfaces gráficas y distros

7. Ejecución del proyecto 7.1. Instalación de Asterisk 13 y FreePBX 13 desde fuentes 7.2. Motivos para realizar esta instalación 7.3. Integración de Asterisk con OpenLDAP

7.3.1. Instalación del servidor openldap


7.3.2. Carga de esquema de Asterisk 7.3.3. Carga de unidades organizativas y grupos en la bd 7.3.4. Script add_user.sh para la creación de usuarios 7.3.5. Un vistazo a la base de datos 7.3.6. Ficheros de configuración de Asterisk

7.4. Directorios de casa de los usuarios. NFS y AutoFS 7.5. Pruebas 7.6. Seguridad

7.6.1. SIP sobre TLS y SRTP en LDAP 7.6.1.1. Primera barrera de diseño 7.6.1.2. Solución propuesta

7.6.2. SIP sobre TLS y SRTP Asterisk 7.6.2.1. Pruebas

7.6.3. StartTLS 7.6.3.1. Proceso de establecimiento de StartTLS 7.6.3.2. Segunda barrera de diseño 7.6.3.3. Solución propuesta

7.7. Salida al exterior 7.7.1. Trunking 7.7.2. Trunks y rutas

7.7.2.1. Trunk SIP entre dos servidores Asterisk 7.7.3. FTTH 7.7.4. Trunk SIP entre Asterisk y proveedor mediante FreePBX 13 7.7.5. Pruebas

8. Conclusiones

9. Anexo → Capturas Wireshark

10. Bibliografía


1. Estudio del problema y análisis del sistema. Con cierta frecuencia, los miembros del departamento de Asir necesitan realizar llamadas

relacionadas con el mismo. Suelen utilizar sus teléfonos móviles personales para ello. Ya

que el departamento tiene contratados una línea telefónica y un proveedor VoIP que no se

utilizan, la idea es implantar una red VoIP en el departamento que utilice esa línea para

poder acceder a la PSTN (red telefónica tradicional).

1.1 Escenario actual de la red del departamento:

En el departamento de Asir disponemos de un dominio con diversos servicios corriendo, de

los cuales para el desarrollo del proyecto vamos a centrarnos en el servidor ldap, cuya base

de datos almacena los usuarios del dominio, y vamos a tener en cuenta los servicios NFS

del servidor y AutoFS de los clientes, que sirve y montan respectivamente el directorio de

casa de dichos usuarios. La idea central del proyecto consiste en implantar una IP-PBX


(una centralita telefónica basada en IP), y el hecho de centrarnos en esos servicios se debe

a que pretendemos integrar esta IP-PBX con el servidor LDAP, de manera que los usuarios

sean los mismos que hay actualmente pero con atributos nuevos que les permitan ser

también clientes de la IP-PBX. Esto último tiene como propósito facilitar la gestión de los

usuarios de la red VoIP al administrador.

2. Objetivos Pretendemos implantar una centralita VoIP Asterisk en el servidor del departamento y usarla

para comunicar teléfonos virtuales instalados en los hosts de la red con la red PSTN.

Los usuarios de la red VoIP podrán llamarse entre ellos, llamar a la red telefónica y recibir

llamadas de ella.

3. Solución elegida para implementar la red VoIP En cuanto a la solución elegir, existen multitud de empresas que te proporcionan todo lo

necesario para realizar lo que pretendemos, y también mucho software propietario.

Como es lógico, queremos usar software libre, y da la casualidad de que la solución más

usada y potente de la telefonía IP lo es, así que no hemos dudado en elegirla. Se llama

Asterisk, y es un software que proporciona funcionalidades de central telefónica.

Hablaremos de las funcionalidades y del funcionamiento de este software más adelante.

También decir que hay distros con asterisk y alguna interfaz GUI para el mismo

preinstalados, sin embargo nosotros vamos a instalar Asterisk manualmente sobre Ubuntu

Server, ya que es el SO del servus.inf real.

4. Modelado de la solución Para el desarrollo del proyecto

vamos a realizar una simulación

simplificada de la red VoIP en Asir

mediante el software Virtualbox.

Un servidor asterisk y dos clientes

ldap con un softphone instalado. Se

autenticarán en el softphone con el

con sus mismas credenciales del

SO.

Recursos hardware → 1 GB de

RAM y 6 GB almacenamiento para

cada MV


Recursos software → Software Asterisk, Openldap, NFS-server en servus.inf. Un

softphone y un cliente ldap instalados en pc01-t1.inf y en pc01-t2.inf

4.2 Escenario completo de Asir con la red VoIP implantada:


5. Planificación temporal El proceso de desarrollo del proyecto ha sido de aproximadamente 10 semanas.

6. Documentación del sistema 6.1 Breve historia de la telefonía tradicional

Aunque todavía quedan muchas compañías de telefonía que se resisten al cambio, lo cierto

es que el mundo actual tiende a la VoIP tanto por el incremento de conexiones de banda

ancha como por la gestión y servicios de valor

añadido que ofrece la VoIP. Pero... ¿Cómo

hemos llegado hasta aquí?

Por no hacer este apartado demasiado

extenso, vamos a contar la historia de la

telefonía de manera muy resumida…

Todo empieza en 1871 cuando Antonio Meucci (y no Graham Bell como mucha gente

piensa) inventa el teléfono, un dispositivo

capaz de transmitir voz entre dos extremos

separados por un material conductor (un

cable). Pronto el invento iría ganando la

atención de empresarios y gran público apareciendo los primeros enlaces de telefonía por

hilos. Las conexiones al principio eran punto a punto así que por cada destino al que

quisiéramos llamar tendríamos que tener un cable directamente conectado con dicho

destino. Como esta solución era inviable, se trabajó en desarrollar una solución que

permitiera dirigir las llamadas punto a multipunto con lo que aparece la centralita telefónica manual.

Con el tiempo, fuimos consiguiendo que las cosas funcionaran de manera automática y

aparecieron las primeras centralitas telefónicas de conmutación automática que

aprovechaban la marcación de los usuarios para dirigir las llamadas al destino deseado.

¿Qué tiene de particular esta solución? Pues que reservan recursos de la red ya que cada llamada requiere un enlace directo entre el origen y el destino. Las compañías


telefónicas eran las propietarias de la los cables por los que se enviaban las llamadas

enrutadas.

Con el desarrollo de las redes de ordenadores, empezamos a enviar información entre equipos situados a mucha distancia y no tardó en plantearse la posibilidad de enviar paquetes de datos de voz para "simular" el comportamiento de las redes telefónicas tradicionales.

La diferencia principal entre esta solución y la telefonía tradicional es que ya no se reservarían recursos en la red por lo que ésta quedaría más descongestionada y se podrían reducir los costes de las llamadas. Cada paquete con voz digitalizada sabe cuál

es su destino, y la red simplemente se encarga de que se reciban los paquetes de voz.

Cuando uno de los extremos no habla, simplemente no se envía nada, y la red no se satura

con canales que no se utilizan. Aunque al principio, sólo podíamos contar con soluciones

propietarias que a su vez eran bastante caras e incompatibles entre sí, con la aparición de

los sistemas multimedia, y en concreto las tarjetas de sonido y su bajada de precios, se

llegó a una situación en la que cualquier ordenador tenía la capacidad de trabajar con VoIP.

6.2 Funcionamiento de una llamada en un sistema de telefonía convencional:

1 - Se levanta el teléfono y se escucha el tono de marcado. Esto deja saber que existe

una conexión con el operador local de telefonía.

2 - Se marca el número de teléfono al que se desea llamar.

3 - La llamada es transmitida a través del conmutador de la centralita de su operador

apuntando hacia el teléfono marcado.

4 - Una conexión es creada entre tu teléfono y la persona que se está llamando,

entremedio de este proceso el operador de telefonía utiliza varios conmutadores para

lograr la comunicación entre las 2 líneas.

5 - El teléfono suena a la persona que estamos llamando y alguien contesta la llamada.

6 - La conexión abre el circuito.


7 - Uno habla por un tiempo determinado y luego cuelga el teléfono.

8 - Cuando se cuelga el teléfono el circuito automáticamente es cerrado, de esta manera

liberando la línea y todas las líneas que intervinieron en la comunicación.

6.3 VoIP. ¿Qué es? Voz sobre protocolo de internet o VoIP, es un conjunto de recursos que hacen posible que la señal de voz viaje a través de Internet empleando el protocolo IP (Protocolo de

Internet).

Esto significa que se envía la señal de voz en forma digital, en paquetes de datos, en lugar de enviarla en forma analógica a través de circuitos utilizables sólo por telefonía

convencional, como las redes PSTN (siglas de Public Switched Telephone Network, red

telefónica pública conmutada).

¿Qué supuso el verdadero 'boom' de la VoIP?

Pues dos factores fundamentales: Por un lado, La aparición en 1999 de una plataforma de

telefonía de código abierto creada por Mark Spencer, conocida como Asterisk y que no

tardó en convertirse en la solución de telefonía por IP de referencia a nivel mundial. Y

por otro lado, la aparición de proveedores de VoIP y servicios de telefonía IP que han

simplificado el esquema de funcionamiento de cara a los usuarios finales y que han

conseguido en países como Francia cuotas de mercado que superan el 40% de la telefonía

total del país.

6.4 Ventajas de VoIP

La telefonía VoIP utiliza una red de datos, que puede ser pública como Internet, y no

requiere para su transmisión la dedicación exclusiva y pago de una red específica como ocurre en la telefonía conmutada o tradicional, lo que reduce los costes para

operadores y usuarios.


El acceso al servicio telefónico a través de un acceso a Internet no sólo reduce los costes de tráfico sino que permite el uso de la línea personal desde cualquier punto en el que exista una conexión a Internet. Una empresa puede, por ejemplo, desviar desde un

único puesto central las llamadas de sus trabajadores allá donde se encuentren a través de

Internet y sin costes adicionales.

El usuario tiene la posibilidad de administrar remotamente su centralita telefónica IP desde

cualquier lugar.

- Inconvenientes de VoIP

Aún hoy en dia existen problemas en la utilización de VoIP. Estos problemas son producto

de limitaciones tecnológicas y se verán solucionadas en un corto plazo por la constante

evolución de la tecnología, sin embargo algunas de estas todavía persisten y son las

siguientes.

Requiere de una conexión de banda ancha. Aunque se está produciendo una constante

expansión de las conexiones de banda ancha, todavía hay hogares que tienen conexiones

por modem. Este tipo de conectividad no es suficiente para mantener una conversación

fluida con VoIP. Sin embargo, este problema se verá solucionado en breve crecimiento de

las conexiones de banda ancha.

VoIP requiere de una conexión eléctrica.

En los casos en que se utilice un softphone la calidad de la comunicación VOIP se puede ver afectada por una posible falta de recursos del equipo.


6.5 Elementos comunes en una red VoIP

- End-points (dispositivos del lado cliente) Teléfono IP Teléfonos basados en protocolo IP, con una salida RJ-45 en vez

de la tradicional RJ-11. Con más funcionalidades que los

tradicionales. Teléfono tradicional Teléfono de siempre, analógico y con puerto FXO para la conexión a

la red telefónica tradicional. Como éstos no pueden conectarse

directamente a una red de datos, lo que se hace es intercalar una

etapa que realice la conversión analógica/digital.

A esta etapa se le denomina ATA (Adaptador de teléfono analógico).

Aunque no presentan las funcionalidades y ventajas de un teléfono

IP, muchas empresas siguen esta opción al no querer cambiar la

infraestructura que tenían anteriormente.

Softphone

Software que simula un teléfono VoIP físico

- Gateways VoIP o ATAs (diferencias sutiles)


Son dispositivos que se encargan de la conversión analógico-digital de los datos. El gateway por una parte se

conecta a la red telefónica convencional y por el otro a una red IP

(por ejemplo Internet), haciendo de puente entre ambas. Pueden

disponer de puertos FXS y FXO. Mediante un puerto FXS permiten

reutilizar terminales no IP (como los teléfonos convencionales) para

su uso con VoIP. Mediante un puerto FXO permiten conectar a la

PSTN. Disponen de puertos ethernet para la conexión con la red IP.

Los gateways voip pueden ser Implementados en unidades externas o en tarjetas PCI.

- IP-PBX Una centralita IP o una IP-PBX es una centralita telefónica que

trabaja internamente con el protocolo IP. De esta manera, utiliza la

infraestructura de comunicaciones de datos (LAN y WAN) para

realizar sus funciones. Las centralitas IP pueden por tanto conectarse

a servicios públicos VoIP, pero también tienen la capacidad de

trabajar con líneas convencionales de teléfono analogicas o digitales

(RDSI).

Una IP-PBX es el corazón de nuestra red VoIP. Es un host con el software Asterisk instalado, el cual define y gestiona la comunicación entre los end-points de la red VoIP.


6.6 Puertos FXS y FXO Los dispositivos FXO permiten manejar una línea telefónica externa, los dispositivos FXO

solo “reciben” tono de marcado, es decir, son lo mismo que los telefonos análogos,

necesitan de una linea (FXS) que les provea tono para funcionar. En los jerga de los PBX se

conocen como las entradas de las troncales.

También existen los dispositivos FXS, que permiten simular el comportamiento de una línea

telefónica (voltaje, corriente, timbres…). A estos dispositivos se conectan dispositivos FXO,

como los teléfonos convencionales o máquinas de fax. En la jerga de los PBX estan son las

salidas de extension.

En resumen a dispositivos FXS solo se pueden conectar dispositivos FXO y viceversa

Por ejemplo, en el caso de la línea de teléfono de nuestra casa, la toma de la pared por la que el proveedor proporciona la línea es una toma FXS, a la que podemos conectar nuestro teléfono, que dispone de una toma FXO. Escenario común de la línea de nuestra casa:

Los gateways VoIP, al igual que las tarjetas analógicas suelen disponer de puertos FXS y

en la mayoría de los casos incluyen puertos FXO. Esto permite conectar teléfonos

analógicos a los puertos FXS y a la conexión FXS que nos proporciona el proveedor

mediante el puerto FXO.


6.6 Escenario de Asir con ATA VoIP Durante gran parte del desarrollo del proyecto, la idea era utilizar un ATA VoIP para la

conexión con la PSTN, aunque al final se ha utilizado una conexión del servidor asterisk con

el proveedor de VoIP telefónica gracias a la línea FTTH (concepto que veremos más

adelante) de la que dispone el departamento. El escenario era el siguiente:

En el apartado “Ejecución del proyecto” veremos que la conexión con la PSTN la realizamos

mediante un trunk que conecta nuestra IP-PBX con la PBX de telefónica. Pero antes de


contemplar esta posibilidad pensábamos implementar el trunk para la conexión con la PSTN

mediante un ATA VoIP. El concepto trunk vamos a estudiarlo en el apartado “Sip trunking”.

- Conectividad de ATA VoIP:

Como vemos esta es una solución apta también para nuestro propósito. Después de una

serie de configuraciones en el dispositivo, sólo teníamos que conectarlo por el puerto LAN a

la red IP, por el puerto FXO a la toma FXS por la que llega la línea de telefónica y por el

puerto WAN al router si deseábamos poder recibir llamadas desde Internet, aunque esto

último no lo queríamos.

Después de configurar el trunk en nuestra IP-PBX, el ATA convertiría las llamadas entrantes

de analógico a digital y las reenviaría a la extensión o grupo de extensiones que indicara el

trunk, todo esto de forma transparente.

También podríamos añadir por el puerto phone (FXS) extensiones analógicas (teléfonos

tradicionales).


6.8 Asterisk 6.8.1 Breve historia de Asterisk

En el año 1999, Mark Spencer funda la empresa Linux Support Services (LSS). Ve la

necesidad de crear un software que simule una central telefónica. Crea y desarrolla

Asterisk. Le da ese nombre por el carácter *, que en Linux representa un comodín, con el

cual podemos realizar acciones que afectan a todos los elementos. La empresa pasa a

llamarse Digium en 2002. Actualmente siguen siendo los principales desarrolladores de

Asterisk. Esta empresa también desarrolla hardware para telefonía IP.

6.8.2 ¿Qué es? Asterisk es un programa de software libre (bajo licencia GPL) que proporciona

funcionalidades de una central telefónica (PBX). Como cualquier PBX, se puede conectar

un número determinado de teléfonos para hacer llamadas entre sí e incluso conectar a un

proveedor de VoIP.

6.8.3 Protocolos de VoIP que usa Asterisk

Por un lado tenemos los datos que marcan las reglas sobre cómo tiene que hacerse el

intercambio de información ('señalización') y por otro lado tenemos la información útil con

los datos voz que es lo que realmente queremos comunicar.

Paquetes de Voz

Los paquetes de voz van a viajar siempre sobre el protocolo de transporte UDP (User

Datagram Protocol) que es un protocolo que no está orientado a conexión y no es fiable

aunque sí que es mucho más rápido que TCP. Además, al no importar que algunos

paquetes se pierdan, no se retransmite información lo cual también supone una ventaja a la

hora de transmitir datos de voz.

Dentro de UDP, lo normal es que los paquetes de voz se encapsulen en tramas RTP (Real-Time-Protocol). Si algún paquete se pierde por el camino no hacemos nada por


recuperarlo porque con la información que nos llega del resto de paquetes podemos

"recomponer" la señal de voz. En esta práctica vamos a usar SRTP (RTP sobre TLS).

RTP son las siglas de Real-time Transport Protocol (Protocolo de Transporte de Tiempo

real). Es un protocolo de nivel de sesión utilizado para la transmisión de información en

tiempo real, como por ejemplo audio y vídeo en una video-conferencia. Está desarrollado

por el grupo de trabajo de transporte de Audio y Video del IETF, publicado por primera vez

como estándar en 1996 como la RFC 1889, y actualizado posteriormente en 2003 en la

RFC 3550, que constituye el estándar de Internet STD 64.

Señalización - Protocolo H.323

El protocolo H.323 es una recomendación de la ITU (International Telecommunication

Union) y define el conjunto de reglas que tienen que seguirse para proveer sesiones de

comunicación audiovisual en red. Se suele utilizar para VoIP y videoconferencias y es una

parte de la serie de protocolos H.32X, los cuales también dirigen las comunicaciones RDSI,

RTC ó SS7. No garantiza una calidad de servicio y el transporte de datos puede, o no, ser

fiable. Fue el primer protocolo que se utilizó para la VoIP y aunque sigue en uso, cada vez

se utiliza menos.

Señalización - Protocolo SIP (RFC 3261) También conocido como Protocolo de Inicio de Sesiones (Session Initiation Protocol), es

un protocolo desarrollado por el IETF con la intención de ser el estándar de referencia para

la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos como el vídeo, la voz, la mensajería instantánea, etc. Es un

protocolo parecido a HTTP y SMTP ya que existía un fuerte interés por que la telefonía se

convirtiera en un servicio más en Internet. Entre sus desventajas, la más importante es que

SIP da muchos quebraderos de cabeza cuando una comunicación pasa a través de un

dispositivo NAT (Network Address Translation), ya que está pensado para transportar la

señalización de una llamada pero no el transporte del audio. Así, mientras que la

señalización utiliza unos puertos fijos y estandarizados (el 5060 normalmente), el encargado

de enviar el audio (RTP) usa puertos elegidos al azar entre el 10.000 y el 20.000 lo que

lleva a que muchos firewalls/NAT no sean capaces de asociar el enlace establecido en la

señalización con el flujo de audio dentro de una llamada.


https://www.ietf.org/rfc/rfc3261.txt

Funciones del protocolo SIP

Localizar a otro usuario

Localizar servidores SIP

Establecer una sesión de datos

Modificar una sesión existente

Expresar capacidades y características de los usuarios agentes

Averiguar el estado, capacidades y disponibilidad de otro UA

Peticiones futuras sobre el estado y capacidad de otro UA

Intercambio de información de señalización de una llamada

Intercambio de mensajes cortos con otros UA 6.8.4 Funcionamiento del protocolo SIP

Entidades SIP

SIP define dos tipos de entidades → los clientes y los servidores.

De manera más precisa, las entidades definidas por SIP son:

El Servidor Proxy (Proxy Server): Recibe solicitudes de clientes que el mismo encamina o

trata de encaminar hacia otros servidores después de haber realizado o no ciertas

modificaciones sobre estas solicitudes.

El Servidor de Redireccionamiento (Redirect Server): se trata de un servidor que acepta

solicitudes SIP, traduce la dirección SIP de destino en una o varias direcciones de red y las

devuelve al cliente. Al contrario que un Proxy Server, el Redirect Server no encamina las

solicitudes SIP.

El Agente Usuario (User Agent): se trata de una aplicación de un dispositivo que emite y

recibe solicitudes SIP.

El Registrador (Register): se trata de un servidor que acepta las solicitudes SIP

REGISTER. SIP dispone de la función de registro de los usuarios. El usuario indica por un


mensaje REGISTER emitido al Registrar, la dirección donde es localizable (dirección IP). El

“Register” actualiza entonces una base de dato de localización. El registrador es una

función asociada a un Proxy Server o a un Redirect Server. Un mismo usuario puede

registrarse sobre distintas UAs SIP, en este caso, la llamada le será entregada sobre el

conjunto de estas UAs.

Solicitudes SIP

El RFC 3261 define seis solicitudes / requerimientos o métodos SIP.

El método “INVITE” es usado con el fin de establecer una sesión entre UAs. INVITE

corresponde al mensaje ISUP IAM o al mensaje Q.931 SET UP y contiene las informaciones sobre el que genera la llamada y el destinatario así como sobre el tipo de flujos que serán intercambiados (voz, video,...).

Cuando un UA que emitió el método SIP INVITE recibe una respuesta final a la invitación (ejemplo : 200 OK), confirma la recepción de esta respuesta por medio de un método “ACK”. Una respuesta del tipo “busy” o “answer” es considerada como final, mientras una

respuesta tipo “ringing” significando que el destinatario ha sido avisado y es una respuesta

provisional.

El método “BYE” permite la liberación de una sesión anteriormente establecida.

Corresponde al mensaje RELEASE de los protocolos ISUP y Q.931. Un mensaje BYE

puede ser emitido por el que genera la llamada o el que la recibe.

El método “REGISTER” es usado por una UA con el fin de indicar al Registrar la

correspondencia entre su Dirección SIP y su dirección de contacto (ejemplo : dirección IP).

El método “CANCEL” es utilizado para pedir el abandono de la llamada en curso pero no

tiene ningún efecto sobre una llamada y a aceptada. De hecho, solo el método“BYE” puede

terminar una llamada establecida.

El método “OPTIONS” es utilizado para interrogar las capacidades y el estado de un User

Agent o de un servidor . La respuesta contiene sus capacidades (ejemplo: tipo de media

siendo soportado, idioma soportado) o el hecho de que el UA sea indisponible.


Respuestas SIP

Después de haber recibido e interpretado una solicitud SIP, el destinatario de esta solicitud

devuelve una respuesta SIP. Existen seis clases de respuestas:

Clase 1xx : Información, el requerimiento ha sido recibido y está en curso de tratamiento.

Clase 2xx: Éxito, el requerimiento ha sido recibido, entendido y aceptado.

Clase 3xx: Re-enrutamiento, la llamada requiere otros procesamientos antes de poder

determinar si puede ser realizada.

Clase 4xx: Error requerimiento cliente, la solicitud no puede ser interpretada o servida por el

servidor. El requerimiento tiene que ser modificado antes de ser reenviado.

Clase 5xx: Error servidor, el servidor fracasa en el procesamiento de un requerimiento

aparentemente válido.

Clase 6xx: Fracaso global, el requerimiento no puede ser procesado por ningún servidor.

Registro en la red SIP

El método “REGISTER” es utilizado por un “USER AGENT” con el fin de indicar a la función Registrar (físicamente implantada en un Proxy Server o un Redirect Server) la correspondencia entre su dirección SIP (ejemplo: sip:[email protected]) y su

dirección IP (ejemplo: sip:[email protected]). La dirección IP puede ser estática

o obtenida de modo dinámico por DHCP. La función Registrar actualiza entonces una base

de datos de localización.

Desde este momento, el User Agent puede recibir llamadas ya que se encuentra ubicado.


Registro, establecimiento y liberación de sesión SIP

Capturas de tráfico de protocolos SIP y RTP en el anexo “Capturas Wireshark”


Señalización - Protocolo IAX El protocolo IAX (Inter-Asterisk eXchange protocol), recogido en la RFC-5456, fue diseñado

como protocolo de conexiones VoIP entre servidores de Asterisk aunque hoy en día

también se utiliza para conexiones entre clientes. Es un protocolo mucho más ligero, simple

y compacto que H.323 y que SIP ya que la señalización no se hace fuera de banda sino que

señalización y datos viajan en los mismos paquetes. Esta característica permite reducir el

número de conexiones simultáneas y es la más adecuada para entornos en los que firewalls

y NATs nos pueden dar problemas. Entre sus inconvenientes, el más importante es que

IAX2 no es un estándar con lo que no está implementado en muchos dispositivos que están

en el mercado. Otro inconveniente es que si utilizamos un servidor SIP, la señalización de

control pasa siempre por el servidor pero la información de audio puede viajar extremo a

extremo sin tener que pasar necesariamente éste. En IAX, al viajar la señalización y los

datos de forma conjunta, todo el tráfico de audio debe pasar obligatoriamente por el servidor

IAX, por lo que se produce un aumento en el uso del ancho de banda que deben soportar

los servidores IAX sobretodo cuando hay muchas llamadas simultáneas.

Como la primera versión de IAX se quedó corta casi al principio, apareció una segunda

versión (IAX2) que es la que se utiliza hoy en día.

6.8.5 Versiones de Asterisk Existen varias versiones de Asterisk con soporte. Cada una de las cuales se distinguen por

las funcionalidades incluidas. Cada vez que se lanza una versión, se soporta durante un

periodo de tiempo determinado. Durante este período de soporte inicial, habrá versiones

que incluyen cambios para corregir los errores que vayan siendo reportados. En algún

momento, la versión se queda obsoleta y sólo se mantiene con las correcciones para

problemas de seguridad. Por último, la versión llegará a su final de la vida (EOL), donde ya

no recibirá cambios de ningún tipo.

El tipo de versión (Release type) define durante cuánto tiempo va a ser soportada. Una

versión LTS (de largo plazo, Long Term Support) será totalmente vigente durante 4 años,

con un año adicional de mantenimiento de parches de seguridad. Las versiones estándar


están soportadas por un período de tiempo más corto, que será por lo menos un año más un año adicional de mantenimiento de parches de seguridad.

Para esta práctica se ha usado Asterisk 13.9.0 LTS, la última versión LTS disponible.

Versiones Tipo de versión Lanzamiento Soporte seguridad EOL

1.2.X 2005-11-21 2007-08-07 2010-11-21

1.4.X LTS 2006-12-23 2011-04-21 2012-04-21

1.6.0.X Standard 2008-10-01 2010-05-01 2010-10-01

1.6.1.X Standard 2009-04-27 2010-05-01 2011-04-27

1.6.2.X Standard 2009-12-18 2011-04-21 2012-04-21

1.8.X LTS 2010-10-21 2014-10-21 2015-10-21

10.X Standard 2011-12-15 2012-12-15 2013-12-15

11.x LTS 2012-10-25 2016-10-25 2017-10-25

12.x Standard 2013-12-20 2014-12-20 2015-12-20

13.x LTS 2014-10-24 2018-10-24 2019-10-24

14.x Standard 2016-10

(tentative)

2017-10 (tentative) 2018-10 (tentative)

15.x LTS 2017-10

(tentative)

2021-10 (tentative) 2022-10 (tentative)

6.8.6 Arquitectura de Asterisk Asterisk fue diseñado de manera modular, de manera que cada usuario pueda seleccionar

qué partes de Asterisk o módulos desea utilizar. Esto hace de Asterisk un sistema

realmente escalable y extensible.


Escalable porque es posible desactivar los módulos no utilizados para instalar Asterisk en

dispositivos de pocos recursos.

Es extensible porque para programar un nuevo módulo de Asterisk no es necesario

conocer todo su código.

Esta arquitectura permite al usuario construir su sistema Asterisk como si de un “lego” se

tratase, seleccionando los módulos que va a necesitar. Estos módulos se dividen en

categorías. Las principales son:

Core. Se trata del núcleo de Asterisk, que incluye las funciones más básicas y posibilita la

carga de módulos. Todos los demás módulos se conectan a él. El núcleo también contiene

el plan de marcado (Dialplan), que es la lógica de cualquier sistema Asterisk. El plan de

marcación contiene una lista de instrucciones que debe seguir para que Asterisk sepa cómo

manejar las llamadas entrantes y salientes en el sistema. El dialplan lo vemos más

detalladamente a lo largo del documento.

Recursos. Aportan funcionalidades adicionales al core, como la posibilidad de leer de

ficheros de configuración (res_config), música en espera (res_musiconhold), etc.

Canales. Permiten a Asterisk manejar un dispositivo de una determinada tecnología. Por

ejemplo, para manejar dispositivos SIP se utiliza el módulo chan_sip, para IAX2 chan_iax y


para canales analógicos/digitales chan_zap.

Aplicaciones y funciones de dialplan. Estos módulos conforman la “caja de herramientas”

de Asterisk, ya que son módulos que aportan las distintas herramientas para configurar el

sistema Asterisk.

Codecs. Un códec es un módulo para la codificación o decodificación de audio o vídeo. Por lo

general se utilizan codecs para codificar los medios de comunicación a fin de que se necesite

menos ancho de banda.

CDR. Estos módulos controlan la escritura del registro telefónico generado por Asterisk a

diferentes formatos, por ejemplo a un fichero CSV, una base de datos MySQL, etc.

Formatos. Estos módulos posibilitan a Asterisk “entender” y manejar ficheros en distintos

formatos, como mp3, alaw, ulaw, etc. 6.8.7 Directorios de asterisk

Los directorios que utiliza Asterisk para su funcionamiento son los siguientes:

/etc/asterisk: directorio donde se alojan todos los ficheros de configuración del servicio.

/usr/lib/asterisk/modules: contiene todos los módulos que podrá cargar Asterisk para

añadir funcionalidades. Algunos de ellos son format_wav.so, codec_alaw.so, chan_sip.so

entre muchos otros.

/var/lib/asterisk: directorio que contiene las claves, música en espera y todos los sonidos

que vienen por defecto con Asterisk.

/var/spool/asterisk: almacena los mensajes grabados en el buzón de voz, las conferencias

grabadas, etc.

/var/run/asterisk: contiene el fichero pid del proceso Asterisk en ejecución.

/var/log/asterisk: directorio de almacenamiento de ficheros de logs del servicio.


6.8.8 Ficheros de configuración de asterisk

Vamos a nombrar los principales: asterisk.conf, sip.conf y extensions.conf. Más adelante

hablaremos también de res_ldap.conf asterisk.conf → el fichero de configuración donde se configuran todos los componentes de

Asterisk (ficheros de log, ficheros de configuración, etc). También es posible configurar

parámetros generales en Asterisk.

sip.conf → Fichero de configuración del canal SIP. Es el fichero donde configuraremos los

clientes SIP que podrán conectarse a nuestra centralita Asterisk

extensions.conf → uno de los ficheros más utilizados y más importantes en Asterisk. En

resumidas cuentas, es donde configuraremos el comportamiento de nuestra centralita, por

eso es uno de los más importantes. 6.8.9 Canal SIP El fichero de configuración del canal sip se encuentra en /etc/asterisk/sip.conf y por tanto

será donde configuremos las cuentas SIP. Se encuentra dividido en secciones conocidas en

Asterisk como contextos. En el fichero sip.conf hay un contexto predefinido, se llama

[general]:

En el contexto [general] definiremos parámetros que se aplicarán en todos los contextos

posteriores. Algunos de los parámetros generales del canal SIP son:


port: es el puerto que utilizará Asterisk para escuchar conexiones SIP entrantes. El puerto

SIP por defecto es el 5060.

bindaddr: interfaz de red que utilizará Asterisk para atender las conexiones SIP entrantes.

El valor por defecto es 0.0.0.0, es decir, escucha en todas las interfaces de red disponibles.

context: contexto que se aplica a las llamadas entrantes. Se aplica cuando una cuenta SIP

no tiene definido un contexto.

videosupport: soporte de video en SIP. Permite los valores 'yes' o 'no'.

language: lenguaje utilizado por defecto para todos los clientes SIP.

allow: especificamos los códecs de sonido que vamos a utilizar. Permite valores como 'all',

'alaw', 'ulaw', 'gsm', etc.

disallow: códecs de audio que no vamos a permitir. Cuando vamos a restringir los códecs

de audio, lo mejor es siempre prohibirlos todos (disallow=all) y luego permitir aquellos que

queramos.

nat: habilitamos o deshabilitamos el soporte de nat para la extensión.

Un ejemplo para el contexto [general] en /etc/asterisk/sip.conf podría ser la siguiente:

[general]

port=5060

bindaddr=0.0.0.0

context=normal

videosupport=no

language=es

disallow=all

allow=alaw,gsm


Definiendo clientes SIP

Antes de que un cliente SIP pueda enviar o recibir llamadas a través de Asterisk, debe ser

declarado y configurado en el fichero /etc/asterisk/sip.conf. Cada cliente SIP se configurará como si de otro contexto / sección se tratase, y podemos

especificar varios parámetros:

type: define la clase de conexión que tendrá el cliente. Hay tres tipos de clientes SIP:

peer: solo puede recibir llamadas.

user: solo puede realizar llamadas.

friend: puede recibir y realizar llamadas.

callerid: es el identificador del cliente, es decir, el nombre que aparecerá cuando se realice

una llamada.

username: usuario con el que nos conectaremos al servidor Asterisk.

secret: contraseña con la que se realizará la autenticación en Asterisk junto con el

username.

context: contexto asociado al cliente en el dialplan de Asterisk, es decir, contexto que se

aplicará en el fichero extensions.conf del cual hablaremos más adelante.

dtmfmode: Dual-Tone Multi-Frequecy (DTMF) se refiere a la marcación por tonos.

Normalmente le especifico que use el estandar rfc2833.

qualify: si se establece a ‘yes’ podremos monitorizar la extensión. Esta configuración no es

muy recomendable cuando tenemos muchas extensiones.

De esta forma, para registrar el teléfono digital cuya extensión es 1001 tendremos que

añadir la siguiente configuración al fichero /etc/asterisk/sip.conf:

[1001]

callerid=mauro


username=1001

secret=1001

type=friend

host=dynamic

context=normal

qualify=yes

pickupgroup=1

dtmfmode=rfc2833

nat=yes

6.8.10 Dialplan El Plan de Marcación, llamado Dialplan en Asterisk, podría considerarse la columna

vertebral del sistema. Como característica principal, podríamos decir que es algo parecido a

un lenguaje de script, en el que funciones, aplicaciones y recursos se van intercalando para

formar algo parecido a "procedimientos" y "programas" dentro de lo que pudiera

considerarse.

Este paradigma de programación orientado a los canales de telefonía es exclusivo en el

mundo y aporta todo el potencial y flexibilidad, que las PBX tradicionales no pueden ofrecer,

o lo hacen mediante mecanismos de licenciamiento y estructuras en ocasiones demasiado

complejas.

El Dialplan se fundamenta principalmente en un fichero, aunque se pueden incluir ficheros

auxiliares adicionales, llamado extensions.conf, dentro del directorio de configuraciones

generales /etc/asterisk.

Concepto de marcación

Cuando hablamos de Plan de Marcación, hacemos referencia literalmente a esto: La

Marcación en un teléfono, o dispositivo de cualquier tipo (no tiene que ser necesariamente

los clásicos 10 números (del 0 al 9), sino también empezamos a incluir el concepto de

carácter alfanumérico). Una vez realizado el marcado, este, entraría como una "entrada"

dentro de nuestro plan de marcación por el contexto que corresponda, en función de como

hayamos definido el canal al que hace referencia nuestro dispositivo SIP,IAX, etc.

Dentro de este contexto, la entrada (la marcación que hicimos), empieza a recorrer el script secuencialmente y a partir de ahí pueden surgir una serie de eventos asociados


a esa entrada que en cualquier caso siempre suelen tener algo que ver con el mundo de la

comunicación, aunque no necesariamente, ya que por ejemplo, podría darse un caso

curioso de una aplicación concreta, como es la de al Marcar los números 1-1-1 en nuestro

teléfono, y que se encendiera la luz de nuestro despacho.

A cada posibilidad concreta, de un conjunto de marcaciones o marcación individidual se le

denomina extensión. Ejemplo, la marcación 1-1-1 sería la extensión 111.

Contextos

Los contextos son la forma de categorizar o englobar , una serie de procedimientos en

función de la marcación a la que hacemos referencia desde el dispositivo que la hacemos.

La sintaxis típica seria un nombre de contexto englobado entre corchetes, algo asi:

[contexto].

En caso que un dispositivo no tenga especificado un contexto en concreto, todas sus

marcaciones se redirigirán directamente a un contexto genérico llamado [default].

Extensiones

Dentro de los contextos, se van definiendo las posibilidades concretas para un conjunto de

marcaciones o como dijimos antes, extensiones.

Para definir una extensión se hace poniendo la palabra "exten =>" delante de la marcación

a la que queremos hacer referencia (ejemplo exten => 111).

Como comentábamos antes, hay que recordar que el concepto de marcación gracias a

Asterisk no solo se limita a caracteres numéricos, sino que se expande a los alfanuméricos,

por tanto la extensión, exten => doe también se podría considerar una extensión valida.

La sintaxis correcta sería:

exten => <marcación_de_la_extensión>,<prioridad>,<aplicación>

Prioridades

Una Extensión, al ser de alguna forma como un lenguaje de script, puede tener varias

funciones, o aplicaciones de forma secuencial.

Al marcar la extensión 111, si la intención es que prepare la comida del horno, en primer

lugar, podríamos requerir que programara la temperatura, en segundo lugar, que

programara el tiempo de horneado, y en tercer lugar que lanzara la orden de calentado.

Como queremos que este "algoritmo" siga un orden establecido, esto lo hacemos a través de las prioridades, que se conforman en orden secuencial numérico (el 1, el 2, el


3), aunque también podemos hacer una llamada recursiva a un contador interno para que

vaya aumentando de forma "automática" (el 1, el 2, el n+1 (3), el n+1 (4) etc). La n viene de

next, y es importante recalcar que la primera prioridad siempre ha de ser la número 1.

Siguiendo la sintaxis de las extensiones para ejecutar la orden de horneado seria algo así:

exten => 111,1,Programa_Temperatura()

exten => 111,2,Programa_Tiempo()

exten => 111,3,Encender_Horno()

Pero podemos mejorar esta estructura con si aplicamos el contador que hablábamos antes:


exten => 111,n,Programa_Tiempo()

exten => 111,n,Encender_Horno()

Desde Asterisk 1.8, para no andar repitiendo constantemente lo de "exten => extension" se

introduce una sintaxis nueva que simplifica mucho la vida, con same => (significa algo asi

como, "lo mismo que antes").


same => n,Programa_Tiempo()

same => n,Encender_Horno()

Esta última forma es la más escueta y correcta a día de hoy.


Etiquetas

Dado que podemos empezar a utilizar los contadores en las prioridades, que ya no asignan

un número especifico, puede ser difícil referenciarnos a una prioridad de una extensión en

cuestión. Por esto surge el concepto de etiquetas, que junto a las prioridades, podemos

darle un nombre a las mismas, y así poder hacer una referencia directa si nos surgiera la

necesidad.

Por ejemplo, si tenemos una extensión con muchas prioridades:

exten => 111,1,...

exten => 111,n,...

...

exten => 111,n,...

exten => 111,n,...

Y por cualquier circunstancia quisiéramos ir justamente a la penúltima prioridad de la

extensión, añadiendo la etiqueta (penúltima) a esa prioridad, ya tendríamos esa referencia

penúltima para darle el uso a conveniencia en un futuro. Esto es especialmente útil para los

saltos condicionales que veremos más adelante.

exten => 111,1,...

exten => 111,n,...

...

exten => 111,n(penultima),...

exten => 111,n,...

Variables

Como en todo buen lenguaje de programación o en este caso, de script, es fundamental

que exista un mecanismo para almacenar Variables. Las variables pueden almacenar


múltiples tipos de información pero no tan extendido como en otros lenguajes.

Principalmente se usan para simplificar el código o hacerlo más legible.

Existen cuatro tipos de variables:

● Variables de Canales

● Variables Globales

● Variables de Entorno

● Variables Compartidas

6.8.11 Asterisk CLI

Para la supervisión y corrección de fallos que pueden surgir en el sistema, tanto a nivel de

servicio como a nivel de entender por qué se ha producido un fallo en una llamada o si un

cliente se está registrando en el servicio o no, contamos con el CLI (Asterisk Command Line Interface).

Gracias a esta interfaz podemos realizar una amplia variedad de acciones de administración

en el servicio de Asterisk entre las que podemos destacar:

● La obtención de datos del estado del sistema y de sus componentes. ● Aplicar cambios en la configuración del sistema. ● Visualización del log en tiempo real (errores, warnings, etc.). ● Generar llamadas de prueba. ● Ver información sobre APIs, aplicaciones y funciones y módulos.

Para acceder al CLI, tan sólo tendremos que ejecutar desde nuestra terminal el comando

"asterisk" seguido de las opciones con las que queramos abrir la consola:


● Opción -c: (Console) - Nos permite abrir la consola. La particularidad de este

comando es que si el servicio de Asterisk no se estaba ejecutando, intentará

lanzarlo.

● Opción -d: (Debug) - Permite indicar el nivel de debug que queremos para los

mensajes que nos aporta el CLI. Si queremos un alto nivel de debug tendremos que

pasarle al comando asterisk tantas veces "d" como nivel queramos. Por ejemplo:

"dddddd".

● Opción -h: (Help) - Muestra todas las opciones posibles.

● Opción -r: (Running) - Conectamos con un servicio de Asterisk que se está

ejecutando en segundo plano.

● Opción -T: (Time) - Para que se muestren marcas de tiempo en cada mensaje de la

consola.

● Opción -v: (Verbose) - Permite indicar el nivel de verbose que queremos para los

mensajes que nos aporta el CLI. Si queremos un alto nivel de verbose, tendremos

que pasarle al comando asterisk tantas veces "v" como nivel queramos. Por ejemplo:

"vvvvvv".

● Opción -V: (Version) - Para ver la versión de Asterisk.

● Opción -x: (Execute) - Para ejecutar un comando en concreto. Se utiliza para no

tener que entrar en la interfaz, ejecutar el comando y salir. Directamente pasamos

inline el comando que queremos que se ejecute. Por ejemplo: asterisk -rx "core

restart when convenient".

Lanzar el CLI con nivel 3 de verbosidad:

$ asterisk -rvvv

Si queremos hacer una llamada remota al sistema que haga que éste se reinicie cuando no

esté procesando ninguna llamada, ejecutamos lo siguiente:

$ asterisk -rx "core restart when convenient"

Para ver la lista completa de opciones, ejecutamos el siguiente comando:


$ asterisk -h

Volvamos al punto en el que abrimos una nueva consola, lo primero que observamos es

que nos aparece un nuevo prompt indicándonos que estamos dentro del CLI:

servus*CLI>

Si queremos salir de la consola, tan sólo tendremos que escribir y ejecutar los comandos

"quit" o "exit".

servus*CLI> exit

Dentro de la consola existen muchos comandos que podemos ejecutar, tan sólo tendremos

que ejecutar "help" para obtener la lista completa:

servus*CLI> help

Algunos de los comandos que más se utilizan:

● console dial - Nos permite hacer una llamada desde consola a una extensión que

se encuentra en un contexto determinado. Muy útil en tareas de depuración de fallos

y control del plan de marcado.

● core restart now - Reinicia el servicio de Asterisk.

● core show channels - Nos permite ver información sobre los canales que están

abiertos en el momento en el que ejecutamos el comando.

● dialplan reload - Nos permite hacer una recarga de configuración del fichero

dialplan.conf, indispensable cuando realizamos algún cambio sobre dicho fichero y

queremos que el cambio se haga efectivo sin reiniciar el servicio completo.

● module load - Nos permite cargar un módulo en Asterisk sin necesidad de reiniciar

el servicio.

● sip reload - Nos permite hacer una recarga de configuración del fichero sip.conf.

Cuando perdemos la comunicación con un troncal al que estamos registrados, obliga

a lanzar un nuevo registro contra dicho troncal.

● sip show peers - Nos permite ver la lista de clientes registrados así como

información adicional como puede ser el ping que tenemos con esos clientes o la IP

desde la cual nos conectamos a ellos.


6.8.12 DAHDI Las siglas DAHDI hacen referencia a Digium/Asterisk Hardware Device Interface, es

decir, una interfaz para toda la lista de productos Digium (y compatibles) que conecta con el

sistema Asterisk, considerando que hablamos de productos que conectan concretamente

con la PSTN, la telefonía clásica.

La estructura del módulo DAHDI es la siguiente:

Considerando que Asterisk trabaja sobre un sistemas UNIX, es necesario establecer una

capa de abstracción entre el hardware provisto (las tarjetas Digium y compatibles), y nuestro sistema operativo. Para ello disponemos el paquete DAHDI, el cual provee

principalmente de todo el sistema de interfaz entre estos dos elementos, y los Drivers

específicos de las tarjetas para poder ser reconocidas por nuestro sistema en el arranque.

Todo esto se concentra por defecto en el directorio /etc/dahdi. Dentro de este directorio

existe cuatro ficheros principales:

● modules: Encargado de gestionar los módulos en el kernel, para que se inicien

automáticamente en el arranque. Por defecto lo ideal es anular todos los módulos

(comentando las líneas donde están con el símbolo '#', y habilitarlos conforme los

vayamos necesitando según las tarjetas que insertemos).

● system.conf: Aquí es donde se provee la información exacta sobre cómo se

conectarán las interfaces con nuestras tarjetas y otros parámetros específicos de las

mismas.


● init.conf: Se pueden especificar la inicialización o descarga de ciertos modulos

adicionales, y scripts shell que queramos que sean ejecutados en la carga de la

aplicación dahdi en el inicio.

● genconf_parameters: Existe una aplicación capaz de configurar un system.conf

generico, según las tarjetas que se hayan reconocido a través de modules, de forma

totalmente automática. Con este fichero podemos modificar un poco este

comportamiento automático a nuestra voluntad, por ejemplo cambiar el cancelador

de eco software por defecto a uno más profesional como el oslec, en vez del clásico

MG2.

Por otro lado, tenemos que ver cómo interactúa DAHDI (considerando que es una

"aplicación" independiente) con nuestra máquina Asterisk. Para ello utiliza un módulo

específico, de tipo canal llamado chan_DAHDI.so, y opera de forma muy parecida a los

otros módulos de canal como SIP e IAX.

Todo esto se configuraría gracias a un fichero específico dentro del directorio de Asterisk de

archivos de configuración /etc/asterisk/, llamado chan_dahdi.conf. 6.8.13 Interfaces gráficas y distros Existen varias interfaces de administración web disponibles para la gestión de nuestro

software Asterisk. Pueden instalarse sobre Asterisk o venir en distros preparadas. Las más

populares son las siguientes:

Freepbx (Distro Linux + Asterisk + Freepbx)

Esta interfaz es posible instalarla tanto sobre un Asterisk puro

en cualquier distro, como desde la distro oficial preparada.

Disponible en www.freepbx.org. Es una de las interfaces web

más conocidas porque funciona bien y porque incluye muchas

funcionalidades.


● Lo mejor de esta distro es que es completamente modular, nos permite ahorrar

recursos en nuestro servidor y se facilita mucho el manejo. Además, como es de las

distribuciones más conocidas, hay más información en la red que de las demás.

● Por comentar algo en su contra, todos los manuales de FreePBX utilizan muchos

tecnicismos por lo que si no somos expertos en telefonía puede costarnos bastante

aprender a manejarla. Además, algunos módulos no están soportados, o no están

bien depurados y pueden llevarnos a fallos. Es el caso del módulo para Openldap, el cual no está soportado por Freepbx

TrixBox (Fonality)

Disponible en www.fonality.com. Contaba con dos versiones, una libre bajo licencia GPL2, y

otra con soporte completo pero previo pago. Ahora sólo está disponible la de pago.

Pensada más para aplicaciones empresariales, utiliza un lenguaje sencillo, fácil de manejar,

optimizada para sistemas Cloud,... La contra, es de pago y no cuenta ya con comunidades

de desarrolladores tan extensas como las de las otras plataformas.

Elastix (Distro CentOS + Asterisk + Elastix)

Disponible en www.elastix.org. Es de las pocas que podemos encontrar totalmente en

español. Ha mejorado mucho en los últimos años gracias a los cursos de formación para la

plataforma. Tiene herramientas básicas de Asterisk y algunas suyas propias.


● Lo mejor - Además de ser libre, estar disponible en español y que seguramente sea

de las más completas junto a FreePBX, destaca la cantidad de información que

podemos encontrar sobre ella.

● Lo peor - Nos obliga a tener CentOS, utiliza demasiados tecnicismos y si luego

queremos configurar algo directamente sobre los ficheros de configuración de

Asterisk vamos a tener que sufrir un poco. Aunque se está trabajando mucho en el

tema de la seguridad todavía falla.

AsteriskNOW (Distro CentOS + Asterisk + FreePbx)

Basado en el panel libre que ofrece Digium a través de la página de Asterisk

(www.asterisk.org), sólo disponible en imagen ISO con Linux incluido, tiene como público

objetivo a desarrolladores, integradores de sistemas, estudiantes, hackers,... y todo aquel

que pueda contribuir de alguna forma a mejorar Asterisk. Existen varias opciones de soporte

previo pago pero la plataforma es totalmente gratuita y Open Source.

● Lo mejor - Como suele ser lo primero que prueban los iniciados en VoIP, existe

mucha documentación. Además viene perfecto si estamos trabajando con equipos

de Digium. Los ficheros de configuración están bien estructurados y no es

excesivamente complicado trabajar con ellos.


● Lo peor - Pese a que debería ser la mejor plataforma por tener el respaldo de Digium

actualmente no ocupa la primera posición de las interfaces web libres. Al margen de

esto, también destaca que hay que tener muchos conocimientos de Asterisk para

poder explotarla bien.

7. Ejecución del proyecto

7.1 Instalación de Asterisk 13 y Freepbx 13 en servus desde fuentes

Actualizando y instalando dependencias

~$ sudo -i

~$ apt-get update && apt-get upgrade -y

~$ apt-get install -y build-essential linux-headers-ùname -r` openssh-server apache2

mysql-server mysql-client bison flex php5 php5-curl php5-cli php5-mysql php-pear

php5-gd curl sox libncurses5-dev libssl-dev libmysqlclient-dev mpg123 libxml2-dev

libnewt-dev sqlite3 libsqlite3-dev pkg-config automake libtool autoconf git unixodbc-dev

uuid uuid-dev libasound2-dev libogg-dev libvorbis-dev libcurl4-openssl-dev libical-dev

libneon27-dev ibsrtp0-dev libspandsp-dev libmyodbc

~$ reboot

~$ pear install Console_Getopt

Instalando Iksemel:

~$ cd /usr/src

~$ wget https://iksemel.googlecode.com/files/iksemel-1.4.tar.gz

~$ tar xf iksemel-1.4.tar.gz

~$ cd iksemel-*

~$ ./configure


~$ make

~$ make install

Instalando y configurando asterisk:

Descargando ficheros fuente

~$ cd /usr/src

~$ wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz

~$ wget http://downloads.asterisk.org/pub/telephony/libpri/libpri-1.4-current.tar.gz

~$ wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz

~$ wget -O jansson.tar.gz https://github.com/akheron/jansson/archive/v2.7.tar.gz

~$ wget http://www.pjsip.org/release/2.4/pjproject-2.4.tar.bz2

Compilando e instalando DAHDI

~$ cd /usr/src

~$ tar xvfz dahdi-linux-complete-current.tar.gz

~$ rm -f dahdi-linux-complete-current.tar.gz

~$ cd dahdi-linux-complete-*

~$ make all

~$ make install

~$ make config

~$ cd /usr/src

~$ tar xvfz libpri-1.4-current.tar.gz

~$ rm -f libpri-1.4-current.tar.gz

~$ cd libpri-*

~$ make

~$ make install

Compilando e instalando pjproject


~$ cd /usr/src

~$ tar -xjvf pjproject-2.4.tar.bz2

~$ rm -f pjproject-2.4.tar.bz2

~$ cd pjproject-2.4

~$ CFLAGS='-DPJ_HAS_IPV6=1' ./configure --enable-shared --disable-sound

--disable-resample --disable-video --disable-opencore-amr

~$ make dep

~$ make

~$ make install

Compilando e instalando jansson

~$ cd /usr/src

~$ tar vxfz jansson.tar.gz

~$ rm -f jansson.tar.gz

~$ cd jansson-*

~$ autoreconf -i

~$ ./configure

~$ make

~$ make install

Compilando e instalando asterisk

~$ cd /usr/src

~$ tar xvfz asterisk-13-current.tar.gz

~$ rm -f asterisk-13-current.tar.gz

~$ cd asterisk-*

~$ contrib/scripts/install_prereq install

~$ ./configure

~$ contrib/scripts/get_mp3_source.sh


~$ make menuselect (escoger los módulos y aplicaciones que deseemos)

~$ make

~$ make install

~$ make config

~$ ldconfig

~$ update-rc.d -f asterisk remove

Instalar ficheros de sonido de asterisk

~$ cd /var/lib/asterisk/sounds

~$ wget http://downloads.asterisk.org/pub/telephony/sounds/asterisk-core-sounds-en-wav-current.tar.gz

~$ wget http://downloads.asterisk.org/pub/telephony/sounds/asterisk-extra-sounds-en-wav-current.tar.gz

~$ tar xvf asterisk-core-sounds-en-wav-current.tar.gz

~$ rm -f asterisk-core-sounds-en-wav-current.tar.gz

~$ tar xfz asterisk-extra-sounds-en-wav-current.tar.gz

~$ rm -f asterisk-extra-sounds-en-wav-current.tar.gz

# Wideband Audio download

~$ wget http://downloads.asterisk.org/pub/telephony/sounds/asterisk-core-sounds-en-g722-current.tar.gz

~$ wget http://downloads.asterisk.org/pub/telephony/sounds/asterisk-extra-sounds-en-g722-current.tar.gz

~$ tar xfz asterisk-extra-sounds-en-g722-current.tar.gz

~$ rm -f asterisk-extra-sounds-en-g722-current.tar.gz

~$ tar xfz asterisk-core-sounds-en-g722-current.tar.gz

~$ rm -f asterisk-core-sounds-en-g722-current.tar.gz

Instalando y configurando freepbx:

~$ useradd -m asterisk

~$ chown asterisk. /var/run/asterisk

~$ chown -R asterisk. /etc/asterisk

~$ chown -R asterisk. /var/{lib,log,spool}/asterisk

~$ chown -R asterisk. /usr/lib/asterisk

~$ rm -rf /var/www/html


Unas modificaciones en el servidor Apache:

~$ sed -i 's/$ûpload_max_filesize = $.*/\120M/' /etc/php5/apache2/php.ini

~$ cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf_orig

~$ sed -i 's/^$User\|Group$.*/\1 asterisk/' /etc/apache2/apache2.conf

~$ sed -i 's/AllowOverride None/AllowOverride All/' /etc/apache2/apache2.conf

~$ service apache2 restart

Configurar ODBC

cat >> /etc/odbcinst.ini << EOF

[MySQL]

Description = ODBC for MySQL

Driver = /usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so

Setup = /usr/lib/x86_64-linux-gnu/odbc/libodbcmyS.so

FileUsage = 1

EOF

cat >> /etc/odbc.ini << EOF

[MySQL-asteriskcdrdb]

Description=MySQL connection to 'asteriskcdrdb' database

driver=MySQL

server=localhost

database=asteriskcdrdb

Port=3306

Socket=/var/run/mysqld/mysqld.sock

option=3

EOF

Descargar e instalar Freepbx 13


~$ cd /usr/src

~$ wget http://mirror.freepbx.org/modules/packages/freepbx/freepbx-13.0-latest.tgz

~$ tar vxfz freepbx-13.0-latest.tgz

~$ rm -f freepbx-13.0-latest.tgz

~$ cd freepbx

~$ ./start_asterisk start

~$ ./install -n

Al finalizar, tendremos asterisk y freepbx funcionando:


7.2 Motivos para haber realizado esta instalación y no mediante repositorios.

Versión Ubuntu 14.04 LTS 15.10

Versión de Asterisk del repositorio 11.7 LTS 13.6.0 LTS

Versión de FreePBX del repositorio NO NO

Aunque siempre es preferible utilizar los repositorios siempre que se pueda para instalar

software, debido a que de esta manera tenemos después la posibilidad de instalarlo y

actualizarlo fácilmente, como vemos, para instalar Asterisk vía repositorio, tenemos que

elegir entre usar una versión desactualizada de Asterisk o usar una versión inestable de

Ubuntu.

Instalar Asterisk desde las fuentes nos ha permitido instalar la última versión estable de

Asterisk (13.6.0) y la última versión de FreePBX (13)(este último software no está siquiera

en los repositorios).

Aunque el motivo de esta instalación haya sido desarrollar el proyecto sobre la última

versión estable de Asterisk (13.6.0), he realizado pruebas con la versión de los repositorios

(11.7), y no varía prácticamente en nada, es igual de apta para el desarrollo del proyecto.

Además, con la llegada de Ubuntu 16.04 LTS, tendremos disponible la última versión

estable de Asterisk en los repositorios.

7.3 Integración de Asterisk con Openldap Algo importante que debemos tener en cuenta, es que una vez integrados Asterisk y

Openldap, no podremos gestionar nada relacionado con openldap desde Freepbx, ya que no lo soporta, por tanto gestionaremos todo desde la consola CLI de Asterisk.

7.3.1 Instalación del servidor openldap Instalación del servidor ldap y herramientas para poder consultar la base sudo apt-get install slapd ldap-utils


Configuramos algunos parámetros del servidor ldap sudo dpkg-reconfigure slapd

dc=inf

nombre org = inf

admin password = 0688

Database backend to use: HDB

7.3.1 Carga de esquema de Asterisk

Copiamos el esquema de Asterisk disponible en /usr/src/asterisk-13.6.0/contrib/scripts/ al

directorio /etc/ldap/schema/ y le decimos al servidor que lo incluya en los esquemas

disponibles.

sudo cp /usr/src/asterisk-13.6.0/contrib/scripts/asterisk.ldap-schema /etc/ldap/schema/asterisk.schema

En /usr/share/slapd/slapd.conf:

include /etc/ldap/schema/asterisk.schema

Cargamos el ldif de asterisk disponible en /usr/src/asterisk-13.6.0/contrib/scripts/ que

contiene los objects classes y atributos relacionados con Asterisk.

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /usr/src/asterisk-13.6.0/contrib/scripts/asterisk.ldif


Una vez cargado el esquema de asterisk podemos ver que tenemos nuevos object classes

disponibles que permiten definir usuarios y extensiones:

Reiniciamos el servicio ldap:

service slapd restart

7.3.3 Carga de unidades organizativas y grupos en la bd Cargamos en la base de datos del servidor ldap 4 unidades organizativas y 2 grupos:

sudoldapadd -x -D cn=admin,dc=inf -W -f frontend.ldif


### frontend.ldif ### # Unidad Organizativa asterisk dn: ou=asterisk,dc=inf

objectClass: top

objectClass: organizationalUnit

ou: asterisk

# Unidad Organizativa users dn: ou=users,ou=asterisk,dc=inf

objectClass: top


ou: users

# Unidad Organizativa extensions dn: ou=extensions,ou=asterisk,dc=inf

objectClass: top


ou: extensions

# Unidad Organizativa Grupos dn: ou=Grupos,dc=inf


ou: Grupos

# Grupo grupoAlumnos dn: cn=grupoAlumnos,ou=Grupos,dc=inf

objectClass: posixGroup

cn: grupoAlumnos

gidNumber: 50000

# Grupo grupoProfesores dn: cn=grupoProfesores,ou=Grupos,dc=inf

objectClass: posixGroup

cn: grupoProfesores


gidNumber: 50001

7.3.4 Script add_user.sh para la creación de usuarios

Para cargar usuarios y extensiones en la base de datos usamos el script add_user.sh, que

genera un fichero ldif que define un usuario y un dialplan simple formado por 4 extensiones

asociadas al mismo. Para crear un usuario que pertenezca a grupoProfesores es necesario

introducir como primer argumento la cadena “prof”.

### add_user.sh ### #!/bin/sh

mkdir -p ~/tmp

touch ~/tmp/user.ldif

ldif=~/tmp/user.ldif

#pedir nombre echo "Usuario :"

read user

#pedir número extensión


echo "Nº extension :"

read num

#pedir contraseña echo "Contraseña :"

#desactivar pantalla stty -echo

read pass

#reactivar pantalla stty echo

echo ""

#crear checksum md5 de "usuario+dominio+pass" md5pwd=ècho -n "$user:inf:$pass" | md5sum | cut -c1-32`

#--------------------

#generar el ldif

#--------------------

#primero el usuario echo "dn:uid=$user,ou=users,ou=asterisk,dc=inf">>$ldif

echo "objectClass: top">>$ldif

echo "objectClass: inetOrgPerson">>$ldif

echo "objectClass: AsteriskSIPUser">>$ldif

echo "objectClass: posixAccount">>$ldif

echo "objectClass: shadowAccount">>$ldif

echo "cn: $user">>$ldif

echo "sn: $user">>$ldif

echo "uid: $user">>$ldif

echo "displayName: $user">>$ldif

echo "uidNumber: $num">>$ldif

if [ "$1" = "prof" ]; then

echo "gidNumber: 50001">>$ldif


else

echo "gidNumber: 50000">>$ldif

fi

echo "userPassword: $user">>$ldif

echo "gecos: $user">>$ldif

echo "loginShell: /bin/bash">>$ldif

if [ "$1" = "prof" ]; then

echo "homeDirectory: /home/pub/profesores/$user">>$ldif

else

echo "homeDirectory: /home/pub/alumnos/$user">>$ldif

fi

echo "shadowExpire: -1">>$ldif

echo "shadowFlag: 0">>$ldif

echo "shadowWarning: 7">>$ldif

echo "shadowMin: 8">>$ldif

echo "shadowMax: 999999">>$ldif

echo "shadowLastChange: 10877">>$ldif

echo "AstAccountContext: internal">>$ldif

echo "AstAccountCallerID: $user <$num>">>$ldif

echo "AstAccountRealmedPassword: $md5pwd">>$ldif

echo "AstAccountQualify: yes">>$ldif

echo "AstAccountNAT: yes">>$ldif

echo "AstAccountType: friend">>$ldif

echo "AstAccountHost: dynamic">>$ldif

echo "AstAccountMailbox: $num@default">>$ldif

echo "AstAccountCanReinvite: yes">>$ldif

echo "AstAccountAllowedCodec: alaw">>$ldif

echo "AstAccountLastQualifyMilliseconds: 500">>$ldif

echo "">>$ldif

#después 4 extensiones (exten,prioridad,aplicación) echo "dn:cn=$num-1,ou=extensions,ou=asterisk,dc=inf">>$ldif



echo "objectClass: AsteriskExtension">>$ldif


echo "cn: $num-1">>$ldif

echo "sn: $num-1">>$ldif

echo "AstContext: internal">>$ldif

echo "AstExtension: $num">>$ldif

echo "AstPriority: 1">>$ldif

echo "AstApplication: Answer">>$ldif

echo "">>$ldif

echo "dn:cn=$num-2,ou=extensions,ou=asterisk,dc=inf">>$ldif









echo "AstApplication: Dial">>$ldif

echo "AstApplicationData: SIP/$user">>$ldif

echo "">>$ldif










echo "AstApplication: Voicemail">>$ldif

echo "AstApplicationData: $num@default">>$ldif

echo "">>$ldif











echo "AstApplication: Hangup">>$ldif

#cargar ldif echo "Cargando el usuario en la base de datos LDAP"

ldapadd -x -D "cn=admin,dc=inf" -W -f $ldif

#voicemail.conf voicemail=/etc/asterisk/voicemail.conf

echo "$num => $num,$user">>$voicemail

#copiar el ldif a home y eliminar el original cp $ldif /home/mauro

rm $ldif

exit


Creando usuario perteneciente a grupoAlumnos:

Creando usuario perteneciente a grupoProfesores:


7.3.5 Un vistazo a la base de datos Una vez que cargamos el fichero

frontend.ldif y ejecutamos add_user

para crear los usuarios: Juanan, Juanjo, Mauro, Diego, Javier y Jaime nuestra bd tiene la siguiente

pinta:

Usuarios:

De estos atributos del usuario Juanjo que vemos, los que le permiten tener funciones de

usuario SIP de nuestro servidor asterisk son los pertenecientes al objectclass

“AsteriskSIPUser”, uno de los objectclasses incluidos en el esquema de Asterisk que

hemos cargado en la base de datos.


Extensiones:

Como podemos comprobar, se han creado 4 extensiones por usuario, es decir 4 reglas que

constituyen un dialplan muy simple para cada usuario. Estas extensiones, a diferencia de


los usuarios, tienen atributos del objectclass “AsteriskExtension” y son reglas de DIALPLAN

almacenadas en la base de datos LDAP y vinculadas a los usuarios sip.

Sirven para que los clientes SIP puedan realizar las funciones básicas de una llamada (y un

buzón de voz). Estas son Answer (contestar), Dial (marcar), Hangup (colgar) y Voicemail

(buzón de voz).


7.3.6 Ficheros de configuración de Asterisk

modules.conf

[modules]

autoload=yes

preload = pbx_config.so

preload = chan_local.so

preload = chan_sip.so load = res_config_ldap.so load = format_wav.so

load = format_pcm.so

load = format_mp3.so

load = res_musiconhold.so

noload = chan_woomera.so

noload = pbx_gtkconsole.so

noload = pbx_kdeconsole.so

noload = app_intercom.so

noload = chan_modem.so

noload = chan_modem_bestdata.so

noload = chan_modem_i4l.so

noload = app_trunkisavail.so

noload = chan_alsa.so

noload = chan_oss.so

noload = app_directory_odbcstorage.so

noload = app_voicemail_odbcstorage.so


noload = chan_modem_aopen.so

noload = chan_woomera.so

noload = cdr_radius.so

noload = cel_radius.so

noload = cdr_mysql.so

noload = res_phoneprov.so

noload = res_digium_phone.so

noload = res_config_sqlite3.so

noload = res_clialiases.so

noload = chan_mgcp.so

noload = cdr_custom.so

noload = app_minivm.so

noload = cel_custom.so

nano /etc/asterisk/res_ldap.conf

[_general]

host=127.0.0.1

port=389

protocol=3

basedn=ou=asterisk,dc=inf

user=cn=admin,dc=inf

pass=0688

Aquí establecemos los parámetros para conectar con el servidor LDAP. nano /etc/asterisk/extensions.conf

[internal]

switch => Realtime/@

Aquí indicamos que queremos usar realtime para leer el dialplan en ldap.


nano /etc/asterisk/extconfig.conf

sipusers => ldap,"ou=users,ou=asterisk,dc=inf",sip

sippeers => ldap,"ou=users,ou=asterisk,dc=inf",sip

extensions => ldap,"ou=extensions,ou=asterisk,dc=inf",extensions

Fichero en el que indicamos a asterisk en qué parte de la base de datos puede encontrar

los usuarios y las extensiones. nano /etc/asterisk/sip.conf

rtcachefriends=yes

realm=inf

Aquí especificamos el nombre de nuestro dominio y que muestre en la consola los usuarios

de realtime.


7.4 Directorio de casa de los usuarios

Cuando un usuario cliente de ldap inicia sesión, se comprueba en la base de datos cuál es

su directorio de casa y se realiza una petición de montaje del mismo. El servicio AutoFS

sirve para montar automáticamente sistemas de ficheros y es el que monta

automáticamente el directorio de casa del usuario mediante NFS cuando detecta esta

petición. El directorio lo está sirviendo por NFS servus.inf.


7.5 Pruebas

Una vez que nos registramos con los usuarios juanan y juanjo en dos softphones:


Podemos visualizarlos desde la consola de Asterisk

Llamadas internas


7.6 Seguridad

En estos momento estamos pudiendo realizar llamadas entre los clientes de la red, pero

tenemos que tener en cuenta que tanto los datos para la señalización (SIP) como los datos

para la transmisión de la voz (RTP), se están intercambiando entre los nodos de la red VoIP

en plano.

7.6.1 SIP sobre TLS y SRTP en LDAP

El siguiente paso es entonces establecer el uso de SIP sobre TLS y SRTP para los

usuarios/clientes sip de la base de datos ldap. Aquí es donde encontramos una primera

barrera de diseño para el desarrollo completo del proyecto, y es la siguiente:

7.6.1.1 Primera barrera de diseño

Para indicar a Asterisk que queremos que un usuario utilice SIP sobre TLS, hay que

especificarlo mediante dos campos (transport y encryption) en el fichero sip.conf en la

definición del propio usuario, además de habilitar una serie de opciones generales en el

mismo fichero. Esto es obligatorio. Lo primero que se nos puede ocurrir para llevar esto a

cabo, dado que no hay ningún tipo de documentación relacionada con SIPS y SRTP para

ldap, es ir a revisar el esquema de Asterisk cargado en ldap, en cuyos object classes

deberían estar esos dos campos, quizás con una sintaxis algo diferente.

Sin embargo en el esquema de ldap no sólo no están esos dos campos, sino que no hay

ningún campo relacionado con TLS.

Debido a la inexistente documentación al respecto, tiendo a pensar que simplemente el

esquema de asterisk no está completamente desarrollado debido al poco uso de asterisk

integrado con ldap. Esto deja abierto un nuevo proyecto, que sería desarrollar el esquema

para añadir esta y otras características.

Como comentamos antes, Freepbx no tiene soporte para OpenLDAP (si para Active

Directory), pero escribe también en bases de datos, en concreto mysql. Por tanto, para

intentar comparar, procedemos a crear una extensión sip (8000) mediante freepbx y

establecer mediante la interfaz que use SIPS y SRTP:


Para mi sorpresa, cuando consulto la base de datos mysql encuentro que se definen esos

dos mismos campos, es decir, que aun tratándose de una base de datos y no de un fichero

de configuración, la sintaxis es la misma:

Esto me lleva a reafirmarme en la idea de que sencillamente el esquema de asterisk para ldap no está desarrollado para ofrecer esta característica.


Post en el foro oficial de Asterisk acerca de este tema:

7.6.1.2 Solución propuesta Ya que hemos visto que en mysql es posible establecer esta configuración, una posible

solución para el desarrollo de esta parte del proyecto puede ser la replicación de los

usuarios que hay actualmente en Openldap a una base de datos mysql.

El script también crearía los trunks necesarios para que esas extensiones puedan salir

fuera, ya que en el esquema de asterisk tampoco disponemos de los atributos necesarios

para la creación de trunks. Más adelante se explican los trunks para la salida al exterior.

Haciendo esto lograríamos que hubiera un usuario en mysql con las características que

deseamos por cada usuario del dominio de Asir, tal y como pretendemos hacer en este

proyecto pero con la ventaja de poder gestionarlo todo desde FreePBX.


Podemos hacerlo de dos formas:

Una solución “batch” adecuada para la cantidad de datos que se van a manejar:

Un script python que consulta la base de datos ldap y guarda los datos en mysql (en la base

de datos que maneja freepbx) con los atributos que nos hacen falta añadidos.

Esbozo en GitHub.

Una solución más adecuada para un sistema en producción:

Usar el motor de replicación syncrpl de ldap, disponible desde la API de python-ldap.

Esbozo en GitHub.

A continuación vamos a documentar el proceso de establecer el uso de SIPS y SRTP en

asterisk sin integrar con OpenLDAP.

7.6.2 SIP sobre TLS y SRTP Asterisk Creamos un directorio donde almacenaremos los certificados y las claves:

~$ mkdir /etc/asterisk/keys

En el directorio /usr/src/asterisk-13.6.0/contrib/scripts/ tenemos un script que nos

proporciona asterisk para crear los certificados y claves:

~$ ./ast_tls_cert -C servus.inf -O Asir -d /etc/asterisk/keys

● "-C" → DNS o IP.

● "-O" → Nombre organización.

● -d" → Directorio al que van a parar los ficheros.


Pide contraseña para la llave de la CA (ca.key) y con ella genera el certificado de la CA:

/etc/asterisk/keys/ca.crt

Pide contraseña para crear la llave del servidor:

/etc/asterisk/keys/asterisk.key

El fichero /etc/asterisk/keys/asterisk.crt se genera automáticamente.

Pide una contraseña por tercera vez, y se genera el fichero /etc/asterisk/keys/asterisk.pem

automáticamente combinando los ficheros asterisk.key y asterisk.crt

Creando certificado para el primer cliente SIP de prueba (extensión 3001)

./ast_tls_cert -m client -c /etc/asterisk/keys/ca.crt -k /etc/asterisk/keys/ca.key -C pc01-t1.inf

-O Asir -d /etc/asterisk/keys -o 3001

● "-m client" → queremos un certificado para un cliente, no para un servidor.

● "-c /etc/asterisk/keys/ca.crt" → indicar la Autoridad Certificadora

● "-k /etc/asterisk/keys/ca.key" clave de la Autoridad Certificadora.

● "-C" → hostname o IP de nuestro cliente SIP.

● "-O" → Nombre organización

● "-d" → Directorio al que van a parar los ficheros

● "-o" → Nombre de la clave del cliente (3001.pem).


Ficheros que tenemos Servidor:

asterisk.csr

asterisk.crt asterisk.key → Llave privada del servidor Asterisk asterisk.pem → Certificado del servidor Asterisk

CA:

ca.key → Llave de la CA ca.crt → Certificado de la CA

Cliente:

3001.csr

3001.crt 3001.key → Llave privada del cliente. 3001.pem → Certificado del cliente.

Transferimos 3001.pem y ca.crt al host cliente sip

cd /etc/asterisk/keys

scp 3001.pem ca.crt [email protected]:~

Repetir este último paso para cada cliente.


Configuración sip.conf General

tlsenable=yes

tlsbindaddr=0.0.0.0 ; Por defecto puerto 5061 transport=tls

tlscertfile=/etc/asterisk/keys/asterisk.pem tlscafile=/etc/asterisk/keys/ca.crt tlscipher=ALL

tlsclientmethod=tlsv1

Dos usuarios Juanjo y Juanan (extensiones 3001 y 3002)

[3001]

type=friend

host=dynamic

username=juanjo

secret=juanjo

callerid="Juanjo" <3001>

context=extensiones-internas ;Contexto simple definido en extensions.conf

dtmfmode=rfc2833

disallow=all

allow=g722

transport=tls ; TLS para la señalización sip encryption=yes ; Encriptar la transferencia de información en la llamada (SRTP)

[3002]

type=friend

host=dynamic

username=juanan

secret=juanan

callerid="Juanan" <3002>


context=extensiones-internas ;Contexto simple definido en extensions.conf

dtmfmode=rfc2833

disallow=all

allow=g722

transport=tls ; TLS para la señalización sip encryption=yes ; Encriptar la transferencia de información en la llamada (SRTP)

Configuración del cliente SIP (Blink) En cada cliente, establecemos el la dirección IP o nombre del servidor (servus.inf), el puerto

5061 (puerto para sip sobre TLS) y el tipo de transporte TLS:

En cada cliente, en la pestaña “media” establecemos que la encriptación sea obligatoria

para el protocolo RTP:


Indicamos a cada cliente dónde se encuentran tanto el certificado de la CA (ca.crt) como el

certificado del cliente (X.pem):

7.6.2.1 Pruebas

Recargarmos el canal sip y comprobamos que detecta el certificado:

Vemos que el servidor asterisk escucha por el puerto 5061:

Si ejecutamos en la consola de asterisk el comando “sip show peer 3002” podremos ver

todos los atributos definidos de ese usuario (juanan). Entre ellos están los relacionados con

la seguridad que hemos establecido.


Llamando podemos comprobar que se está usando el protocolo TLS:


Llamada establecida: Además de comprobar el uso de TLS en la consola de asterisk, el cliente blink nos muestra

un par de candados.

Uno azul que nos indica que la señalización de la sesión está usando TLS:


Otro gris que nos indica que la transmisión de los datos está siendo encriptada

Capturas de tráfico SIPS y SRTP en el anexo “Capturas Wireshark” 7.6.3 StartTLS En el departamento de Asir la comunicación entre los clientes y servidor ldap se realiza

utilizando StartTLS.

StartTLS es una extensión de los protocolos de comunicación de texto plano, que ofrece

una forma de mejorar desde una conexión de texto plano a una conexión cifrada (TLS o

SSL) en lugar de utilizar un puerto diferente para la comunicación cifrada.

En el caso de Openldap el puerto por defecto es el 389. Con StartTLS usamos este mismo

puerto pero obligando la encriptación de los datos y el uso de certificados.

El siguiente paso en el desarrollo del proyecto es establecer el uso obligatorio de StartTLS

tanto para la comunicación entre clientes y servidor ldap.

7.6.3.1 Proceso de establecimiento de StartTLS

Vamos a utilizar dos herramientas para llevar a cabo el proceso: gnutls-bin y ssl-cert

~$ apt-get install gnutls-bin ssl-cert


Vamos a generar dos pares de claves/certificados:

Una clave y un certificado para nuestra Autoridad Certificadora (CA)

/etc/ssl/private/ca_server.key → clave de la CA

/etc/ssl/certs/ca_server.pem → certificado de la CA

Una clave y un certificado asociados al servidor LDAP

/etc/ssl/private/ldap_server.key → clave del servidor

/etc/ssl/certs/ldap_server.pem → certificado del servidor

Vamos a crear un directorio que contendrá plantillas para generar cada uno de los

certificados:

~$ mkdir /etc/ssl/templates

Plantilla para el certificado autofirmado de la CA:

~$ nano /etc/ssl/templates/ca_server.conf

##ca_server.conf##

cn = LDAP Server CA

ca

cert_signing_key

Plantilla para el certificado del servidor:


~$ nano /etc/ssl/templates/ldap_server.conf

organization = "Asir"

cn = servus.inf

tls_www_server

encryption_key

signing_key

expiration_days = 3652

Creando clave y certificado para nuestra CA:

Clave:

~$ certtool -p --outfile /etc/ssl/private/ca_server.key

Generando certificado a partir de plantilla y firmándolo con la clave generada:

~$ certtool -s --load-privkey /etc/ssl/private/ca_server.key --template

/etc/ssl/templates/ca_server.conf --outfile /etc/ssl/certs/ca_server.pem

Creando par de certificados/claves para el servidor LDAP

Generando clave:

~$ certtool -p --sec-param high --outfile /etc/ssl/private/ldap_server.key

Generar el certificado para el servidor ldap cargando en él llave generada, el certificado de la CA y utilizando la llave de la CA a partir de la plantilla del servidor ldap:


~$ certtool -c --load-privkey /etc/ssl/private/ldap_server.key --load-ca-certificate

/etc/ssl/certs/ca_server.pem --load-ca-privkey /etc/ssl/private/ca_server.key --template

/etc/ssl/templates/ldap_server.conf --outfile /etc/ssl/certs/ldap_server.pem

Dando acceso al usuario openldap al grupo ssl-cert (grupo que tiene acceso a llaves y certificados):

~$ usermod -aG ssl-cert openldap

Haciendo propietario al grupo ssl-cert de la llave ldap_server.key

~$ chown :ssl-cert /etc/ssl/private/ldap_server.key

Dando permiso de lectura sobre la clave al grupo propietario de la clave

~$ chmod 640 /etc/ssl/private/ldap_server.key

Vamos a modificar algunos parámetros en la base de datos ldap para el uso de los

certificados por parte del servidor.

Para ello generamos un fichero ldif “addcerts.ldif”:

##addcerts.ldif##

dn: cn=config

changetype: modify

add: olcTLSCACertificateFile

olcTLSCACertificateFile: /etc/ssl/certs/ca_server.pem

-

add: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ssl/certs/ldap_server.pem

-

add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ssl/private/ldap_server.key


Y lo cargamos en la base de datos:

~$ ldapmodify -H ldapi:// -Y EXTERNAL -f addcerts.ldif

Forzamos el reinicio del servicio ldap:

~$ service slapd force-reload

Copiamos el certificado del servidor al directorio /etc/ldap e indicamos al servidor dónde se

encuentra:

~$ cp /etc/ssl/certs/ca_server.pem /etc/ldap/ca_certs.pem

~$ nano /etc/ldap/ldap.conf

##/etc/ldap/ldap.conf##

TLS_CACERT /etc/ldap/ca_certs.pem

Para probar que podemos usar StartTLS para consultar la base de datos ldap usamos el

parámetro -ZZ:

~$ ldapsearch -x -LLL -b dc=inf -H ldapi:// -ZZ


Para que los clientes también puedan usar starttls para comunicarse con el servidor:

Transferimos el certificado del servidor a cada cliente, lo copiamos al directorio /etc/ldap e

indicamos en /etc/ldap/ldap.conf dónde se encuentra:

~$ scp [email protected]:/etc/ssl/certs/ca_server.pem ~/

~$ cat ~/ca_server.pem | sudo tee -a /etc/ldap/ca_certs.pem

nano /etc/ldap/ldap.conf

##/etc/ldap/ldap.conf##


Misma prueba que en el servidor desde los clientes para comprobar el uso de starttls:

ldapsearch -x -LLL -b dc=inf -H ldap://servus.inf -ZZ


En este momento, el uso de StartTLS está habilitado, pero no es obligatorio. Al establecerlo

obligatorio nos topamos con la segunda barrera de diseño en el desarrollo del proyecto. Es

la siguiente:

7.6.3.2 Segunda barrera de diseño La conexión entre el servidor Asterisk y el servidor ldap se realiza a través del módulo

res_config_ldap.so, y su fichero de configuración es /etc/asterisk/res_config_ldap. Este

módulo soporta el uso de TLS por el puerto 636. Sin embargo, el uso de startTLS no está soportado por este módulo, por tanto cuando

establezco el uso de starTLS obligatorio, la conexión entre asterisk y ldap se rompe.

Durante el desarrollo del proyecto se ha dedicado mucho tiempo a investigar si realmente

no estaba soportado o había que realizar esta configuración de otro modo. Hemos echado

un vistazo al módulo res_config_ldap.so en busca de referencias a startTLS o TLS sin

encontrar nada. Finalmente, al no encontrar forma de configurar esto, ni obtener respuesta

a posts escritos en el foro de Asterisk, he terminado pensando que los que crearon el

módulo res_config_ldap.so no contemplaron la posibilidad de usar startTLS.


Consulta en el foro:

7.6.3.3 Solución propuesta:

Dado que en el departamento de Asir no tiene sentido retroceder a establecer el uso de

TLS, una posible solución para este problema sería escribir un proxy que hiciera las

peticiones

No he encontrado ningún proxy ya escrito, sería un proyecto de considerable embergadura

que se queda abierto el escribirlo. Forzar el uso de StartTLS

Creamos un ldif


##forcetls.ldif##

dn: olcDatabase={1}hdb,cn=config

changetype: modify

add: olcSecurity

olcSecurity: tls=1

sudo ldapmodify -H ldapi:// -Y EXTERNAL -f forcetls.ldif

En /etc/ldap.conf de servidor:

ssl start_tls

tls_checkpeer yes

tls_cacertfile /etc/ssl/certs/ca_server.pem

tls_cacertdir /etc/ssl/certs

En /etc/ldap.conf de clientes:

ssl start_tls

tls_checkpeer yes

tls_cacertfile /etc/ldap/ca_certs.pem

tls_cacertdir /etc/ldap

En /etc/ldap/ldap.conf de servidor y clientes: BASE dc=inf

URI ldap://servus.inf



7.7 Salida al exterior 7.7.1 Trunking Un trunk es una línea troncal que sirve para conectar el servidor asterisk con otro servidor o

con un proveedor de servicio VoIP para la conexión con la PSTN.

7.7.2 Trunks y rutas

Voy hacer uso de una analogía con una estación o terminal de autobuses, con múltiples puertas de entrada y salida. Para el abordaje del autobús que me lleva a mi destino, lo

que debo hacer es seleccionar la puerta correcta donde se encuentra el autobús que me

transportará al destino deseado. La estación o terminal de autobuses es el servidor Asterisk, las puertas de entrada y salida son las troncales, el destino es la ruta de entrada o salida, los autobuses vendrían a ser los proveedores del servicio de telefonía.

Por lo anterior podemos concluir que la ruta es el destino y las troncales es el canal o el medio.

Tipos de trunks

Los tipos de troncales pueden ser: Troncales SIP (SIP Trunk): El medio de transporte para la voz es la red IP. Una buena

cantidad de proveedores los están utilizando últimamente para proveer el servicio telefónico.

una de sus mayores ventajas es que podemos utilizar el Internet para establecer los

enlaces, de esta manera podemos tener números telefónicos (DID) de cualquier parte del

mundo sin importar la ubicación geográfica. Es muy popular también por los fabricantes de

equipos ya que por ser un estándar se garantiza la compatibilidad y conectividad con

cualquier equipo que soporte SIP. La cantidad de canales dependerá del ancho de banda

del enlace IP.

Troncales IAX2 (IAX2 Trunk): El medio de transporte para la voz es la red IP, se utiliza

para establecer enlaces entre 2 o más servidores Asterisk. Aún no se ha convertido en


estándar, por esta razón son pocos los fabricantes de equipos que lo soportan. Una de sus

mayores ventajas es la utilización de un solo puerto (UDP 4569) para la comunicación, esto

lo convierte en el método ideal para unir 2 o más Asterisk en redes con Firewall de por

medio.

Troncales Digitales (Puertos E1, T1, J1): Es el método hoy por hoy más utilizado por los

proveedores para la entrega de los servicios telefónicos, utiliza medios físicos para el

transporte de la voz como cable de cobre o fibra óptica, por este medio se entregan los

números DID, se deberá instalar un adaptador o tarjeta en el servidor Elastix para configurar

la troncal, existen también Cajas o Gateways que funcionan con protocolo TDMoIP, que

permiten recibir los enlaces E1 y conectarlos a la red IP del servidor Asterisk-Elastix, de

esta manera no es necesario la colocación de ningún adaptador.

Troncales Análogas (Puertos FXO): Es la manera tradicional de recibir las lineas

telefonicas, muy utilizado cuando la cantidad de líneas no sobrepasa las 8, mas haya de

esto se recomienda utilizar E1. Por cada línea es necesario un puerto, es así por ejemplo si

hay 4 líneas telefónicas es necesario utilizar un adaptador con 4 puertos FXO. Un método alterno al uso de los adaptadores FXO, es la utilización de adaptadores ATA con puertos FXO, estos permiten conectar las líneas telefónicas sin instalar ningún hardware en

el servidor Elastix, la comunicación se hace mediante el protocolo SIP.

El tipo de troncal determina el número de llamadas concurrentes que se pueden tener, por

ejemplo en una troncal digital E1 permite hasta un máximo de 30 llamadas por enlace, en

una troncal analoga FXO solo permite una llamada por enlace, en troncales SIP e IAX2 en

teoría no hay límite de llamadas concurrentes, el límite lo impone el ancho de banda de la

red IP, sin embargo se recomienda no sobrepasar los 200 canales.

Tipos de Rutas Las rutas son las reglas que le indicarán al servidor Asterisk-Elastix por qué troncal deberá

enviar una llamada en base a ciertos patrones de marcado, esto es lo que se conoce como

plan de marcación.

Rutas de Entrada (Inbound Routes): Una ruta de entrada le dice a Asterisk hacia donde

deberá transferir una llamada recibida cuando se cumpla cierta condición.


Rutas de Salida (Outbound Routes): controla la manera en que salen las llamadas, es

decir, por que canal sale cada llamada con un patrón concreto.

7.7.5 Trunk SIP entre dos servidores Esquema de conexión entre dos servidores Asterisk mediante sip trunk:

Ejemplo práctico: Dos servidores Asterisk: asterisk1.inf (192.168.2.225) y asterisk.2.inf (192.168.2.222)


Con esta configuración los peers de asterisk.inf pueden comunicarse con los de asterisk2.inf


Esquema de conexión entre un servidor Asterisk y un proveedor VoIP:

Las troncales y las rutas son complementarias entre si, no se puede crear ninguna ruta sin

especificar una troncal, aunque pueden existir troncales sin declarar rutas en ellas. Antes de

declarar cualquier ruta de salida es indispensable que exista al menos una troncal.

7.7.6 FTTH La tecnología de telecomunicaciones FTTH (del inglés Fiber To The Home), también

conocida como fibra hasta la casa o fibra hasta el hogar, enmarcada dentro de las

tecnologías FTTx, se basa en la utilización de cables de fibra óptica y sistemas de

distribución ópticos adaptados a esta tecnología para la distribución de servicios avanzados,

como el Triple Play: telefonía, Internet de banda ancha y televisión, a los hogares y

negocios de los abonados.

La implantación de esta tecnología está tomando fuerza, especialmente en países como

Estados Unidos, Colombia, Uruguay, Japón y países de Europa, donde muchos operadores

reducen la promoción de servicios ADSL en beneficio de la fibra óptica con el objetivo de


proponer servicios muy atractivos de banda ancha para el usuario (música, vídeos, fotos,

etc.)

7.7.7 Trunk SIP entre servidor Asterisk y proveedor mediante FreePBX 13 General:

Trunk Name → 956204264

Outbound CallerID → Asir

Maximum Channels → 1

Outgoing:

trunk name → trunk_prueba

Peer Details:

type=peer

fromuser=956204264

secret=956204264

fromdomain=telefonica.net


host=telefonica.net

outboundproxy=10.31.255.134:5070

port=5070

nat=yes

insecure=port,invite

dtmfmode=auto

disallow=all

allow=ulaw,alaw

Incoming:

User context → from-trunk

User detail:

type=peer

username=956204264

secret=956204264

fromdomain=telefonica.net

host=10.31.255.134

port=5060


outboundproxy=10.31.255.134

qualify=no

nat=yes

insecure=port,invite

dtmfmode=auto

canreinvite=no

disallow=all

allow=ulaw,alaw

outboundproxyport=5070

y por ultimo en register string...

[email protected]:[email protected]:5070

Creación de la outbound route:

Route name → to_pstn


Trunk sequence for matched routes → 956204264

Dial Patterns, match pattern → “.” (para que salgan todas las llamadas, indicando que

deben salir por nuestro Trunk)


Como vemos la ruta de salida está asociada al trunk creado. Para usar esta regla de salida

hay que pasar por el mismo.

Creación de la inbound route

La inbound route está asociada a la extensión 9000. Quiere decir que las llamadas al trunk

desde el exterior serán redireccionadas a la extensión 9000.


7.7.5 Pruebas Llamando a nodo de la red PSTN

Recibiendo llamada de nodo de la PSTN y redireccionándola a la extensión Mauro


Llamada establecida

8 Conclusiones En el desarrollo del proyecto me he adentrado en el mundo de la telefonía IP y en concreto

en el software Asterisk. Pienso que al referirnos a VoIP estamos hablando de evolución de

la telefonía, y creo que sus ventajas hablan por sí solas:

- Total movilidad geográfica. Tener una línea disponible en cualquier parte del mundo.

- Posibilidad de administrar y gestionar el comportamiento de las llamadas, y muchas

más funcionalidades que una centralita tradicional no posee.

- Gran flexibilidad y escalabilidad Aunque yo he encontrado barreras que me han impedido completar el desarrollo del

proyecto como deseaba, he aprendido algo o bastante de cada uno de los impedimentos.

Pienso que puliendo las soluciones planteadas, que por cuestión de tiempo no han podido

desarrollarse más, podría llegar a implantarse la red VoIP en el departamento de Asir. El

desarrollo de las soluciones queda disponible como nuevo proyecto.


9 Anexo - Capturas Wireshark Protocolo SIP Registro usuario Juanan Register juanan → servidor

Ok servidor → juanan


Llamada de usuario Juanan (1000) a usuario Juanjo (1001), usuario juanan cuelga

Invite juanan → servidor


Trying servidor → juanan

Invite servidor → juanjo


Trying juanjo → servidor

Ringing juanjo → servidor


Ringing servidor → juanan

Ok juanjo → servidor



Rtp


Bye juanan → servidor



Bye servidor → juanjo

Ok juanjo → servidor


Captura SIPS

10 Bibliografía http://comunidad.asterisk-es.org/index.php?title=Portada http://wiki.freepbx.org/display/FOP/Installing+FreePBX+13+on+Ubuntu+Server+14.04.2+LTS http://forums.asterisk.org/ http://community.freepbx.org/ https://wiki.asterisk.org/wiki/display/AST/Home


http://community.freepbx.org/

http://wiki.freepbx.org/display/FOP/Installing+FreePBX+13+on+Ubuntu+Server+14.04.2+LTS

http://forums.asterisk.org/

https://wiki.asterisk.org/wiki/display/AST/Home

http://comunidad.asterisk-es.org/index.php?title=Portada

http://wiki.freepbx.org/display/FOP/Installing+FreePBX+13+on+Ubuntu+Server+14.04.2+LTS

Documents

Implantación de red · para comunicar teléfonos virtuales instalados en los hosts de la red con la red PSTN. Los usuarios de la red VoIP podrán llamarse entre ellos, llamar a la