Asterisk Manual de Instalacion

Anexo III.
Escenario
de Trabajo y Anlisis
de posibles
soluciones
MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK
140
3. ESCENARIO DE TRABAJO Y ANLISIS DE

SOLUCIONES
3.1. Situacin actual de Persan
Re
d
de
Te
le
fo
n
a
Re
d
de
Da
to
s
A continuacin se muestra un esquema con la situacin actual en la que se

encuentra el escenario de trabajo. En la actualidad coexisten en Persan dos redes:
una de datos IP con un ncleo Ethernet y un acceso wi-fi desde las naves, y una de
telefona analgica con una centralita propia y terminales DECT en algunas naves.
La red de datos est diseada y mantenida por el departamento de sistemas
mientras que la red de telefona est diseada y mantenida por el departamento de
produccin. La red de datos tiene un ncleo cableado Ethernet (12 nodos) que no
ofrece garantas en el transporte de paquetes ni auto-restauracin ante cortes del
servicio. La red de telefona, gestionada por el departamento de produccin,
dispone de una centralita y telfonos tradicionales en el edificio de oficinas as como
puntos inalmbricos DECT para naves industriales
Figura 52. Escenario actual Persan
Problemtica en la Red de Telefona:

El cableado no llega a todas las naves industriales con lo cual existen zonas de la
fbrica sin cobertura telefnica. Adems, dentro de cada nave con puntos de acceso
DECT, la localizacin de estos puntos y la escasez de los mismos hace que a veces
sea necesario perder mucho tiempo hasta localizar al operario deseado.
El sistema DECT (Digital Enhanced Cordless Telecommunications) esta diseado
para ser inmune a las interferencias tpicas de un entorno domstico/oficina en un
radio de 100m. En media, un terminal radia una seal de 10mW por lo que en
zonas con alto ruido industrial, el funcionamiento de los terminales es muchas
veces insatisfactorio debido al ruido industrial provocado por los motores de los
distintos elementos de la cadena de produccin. Adems, la centralita a la que van
141
conectados los puntos de acceso DECT ya se encuentra saturada con lo que no es

posible poner ms puntos de acceso inalmbrico.
Problemtica en la Red de Datos:

El cableado no llega a todas las naves con lo que existen problemas de cobertura
en varias zonas de la fbrica. De hecho slo 20 de las 40 naves que componen la
fbrica tienen acceso wifi gracias a 16 puntos de acceso. Esto limita los espacios en
los que los operarios pueden utilizar el sistema de almacenamiento asistido.
Tambin limita las zonas de la fbrica que pueden servir como almacenes. Estos
problemas de cobertura se agravan por un mal diseo en la ubicacin de los puntos
de acceso existentes ya que no se tuvo en cuenta la existencia de motores que
provocan interferencias con el sistema Wi-fi, haciendo que el throughtput
temporalmente decaiga. Aunque ello no impide el funcionamiento de la aplicacin
cliente/servidor de almacenaje, imposibilita el uso actual de la red de datos como
red de telefona IP. Adems, ni el ncleo ni el acceso de red ofrecen actualmente
soporte de calidad en el transporte de la voz ni del vdeo impidiendo a su vez el uso
para el control de procesos industriales, campo que resulta del inters de la
empresa.
Finalmente, ha ocurrido no pocas veces en los ltimos dos aos el corte de cables
de fibra ptica dentro de la fbrica provocando la parada de todo el sistema de
almacenaje. Con cada corte se suspende la conexin que necesita la aplicacin de
almacenamiento asistido por lo que los operarios necesitan cambiar su operativa,
pasando a un funcionamiento manual que provoca prdidas de tiempo, falta de
eficacia y el consiguiente coste econmico.
Por lo tanto podemos resumir la problemtica actual en:
Costes de mantenimiento alto debido a la existencia de dos redes

independientes mantenidas por departamentos diferentes.
Falta de cobertura en gran parte de la fbrica tanto en la red de datos como

la de voz. Ello limita el uso actual y futuro del espacio. Por ejemplo, una
zona dedicada al almacenaje debe necesariamente estar dotada de
cobertura wifi.
Entorno de alto ruido electromagntico que perturba el funcionamiento de

los servicios de voz y datos en algunas naves industriales e impide el uso de
la red wifi para el transporte de trfico en tiempo real.
Cortes eventuales en fibras del ncleo de la red provocan la prdida de

conectividad y la parada de las actividades de almacenamiento automtico.
El diseo incremental de la red no ha tenido en cuenta infraestructura
redundante ni procedimientos de restauracin.
La arquitectura del sistema que se desea implementar es similar a aquella de las

redes de prxima generacin tal y como las define la ITU-T en su serie de
recomendaciones Y. Es decir, un ncleo de transporte o backbone IP con garantas
de calidad de servicio (QoS) conectado a una serie de redes de acceso (en nuestro
caso Wi-Fi, ethernet y la red de telefona existente) y un estrato de control de
servicios independiente de los estratos anteriores. Esto se muestra en la siguiente
figura, donde se pueden distinguir los tres pilares del proyecto: ncleo de red de
transporte IP, red acceso wifi, servicios multimedia.
142
En el estrato inferior tendramos las redes actuales y de acceso con sus respectivos
terminales. Estas redes cursan y reciben trfico a travs de un ncleo de red IP
(ethernet conmutada) que a su vez ofrece dos servicios claves a las aplicaciones:
fiabilidad (restauracin automtica y diseo redundante) y control de prestaciones
(retardo, prdidas y ancho de banda) para aplicaciones de tiempo real (voz y
vdeo). Finalmente, el estrato de los servicios se plantea como un plano que
permite la implementacin y el control (contabilidad, autorizaciones, seguridad,
calidad del servicio, grupos, etc.. ) de las aplicaciones ofrecidas. A este respecto en
el proyecto se plantean la implementacin de VoIP, televigilancia, telediagnstico y
de un servicio de localizacin y control de presencia basado en WiFi.
Toda esta informacin ha sido obtenida del pliego del proyecto presentado a la
empresa y que se puede encontrar aqu.
3.2. ANLISIS DE ESCENARIOS OPUESTOS PARA PERSAN

Para estudiar los distintos escenarios propuestos para Persan, se van a estudiar los
factores que suelen ser significativos en la eleccin de una topologa concreta.
Dicha eleccin suele estar determinado por factores como:
1. Coste: Coste de los medios de comunicacin, sencillez de instalacin y
mantenimiento.
2. Flexibilidad: Dificultad de incrementar o disminuir el nmero de estaciones
3. Fallos en la instalacin o estaciones. Facilidad de mantener el servicio y
enlaces alternativos.
4. Retardo mnimo introducido por la red
5. Trafico de informacin que puede soportar
6. Aplicacin a la que esta destinado
7. Tecnologa a emplear, dificultad de configuracin y protocolos de
comunicacin.
Para el anlisis de las topologas propuestas se va a estudiar como los factores
arriba descritos afectan a las distintas configuraciones propuestas.
ESCENARIO 1:
Figura 53. Esquema Escenario 1
143
ESCENARIO 2:
E S C E N A R IO N M E R O 2
750
A1
756
A2
B1
231
B2
B3
GSM
B4
PSTN
Figura 54. Esquema Escenario 2

Antes de proceder al anlisis, se debe puntualizar que para el escenario 2, se han
estudiado dos formas distintas de mandar las llamadas a travs de los puertos A1 y
A2 para que sean reenvidas (por la centralita Asterisk) a su destino.
1. Las llamadas se envan indistintamente por los puertos A1 y A2 y ser la
centralita Asterisk quien se encargue de tratarlas.
2. Las llamadas se envan siguiendo el siguiente patrn, todas las llamadas a
fijos o destinadas a los telfonos IP se mandarn a travs del puerto A1, y
las que vayan a la red GSM por el puerto A2.
Anlisis
Se ha considerado que los factores referentes al coste, al retardo mnimo, el trfico
y la aplicacin a la que va destinada no son relevantes para el anlisis de estos
escenarios.
Facilidad de mantenimiento o reparacin ante fallo:

Estudiemos qu pasara si se produjese un fallo en la centralita Asterisk o en la red
IP.
Escenario 1: La parte de comunicacin entre los terminales que existen

actualmente (aquellos cuya extensin comienza por 7xxx u 8xxx) no se
veran afectados, ni la comunicacin de ellos al exterior a travs del
primario conectado a RTC, puesto que todo esto lo gestiona la centralita
Ericsson. En cuanto al primario conectado a GSM, simplemente se devolvera
el enlace a su situacin original y durante un breve periodo de tiempo no se
encontrara disponible dicho enlace. El fallo producido en la centralita
Asterisk quedara aislado y el escenario quedara como fue planteada
originalmente, sin que los usuarios de esta se vean afectados por dicho fallo.
Escenario 2: En este escenario, el acceso a los primarios es gestionado

desde la centralita Asterisk se pueden dar dos situaciones distintas (las
planteadas arriba):
144
Si ambos puertos A1 y A2 se usan de forma indistinta para llevar

llamadas a Asterisk y el se encarga de gestionar el camino que deben
seguir dichas llamadas, entonces
la comunicacin quedara
interrumpida y debera modificarse la configuracin de la centralita
Ericsson para que vuelva a asumir la eleccin de por donde deben ir
las llamadas (como hace actualmente). Esto supondra un periodo de
reestablecimiento de la configuracin mucho ms elevado que en el
escenario 1, y en este periodo los usuarios de la centralita quedaran
sin servicio de ningn tipo.
Sin embargo, si las lneas se siguen tratando como hasta ahora, es

decir de las dos conexiones (puertos A1 y A2), una se usa para fijos y
otra para mviles, y lo nico que se hace es redirigirlas hacia la
centralita Asterisk para que las saque fuera por los primarios, ante
error, simplemente se vuelve a conectar el puerto A1 con la red RTC
y el puerto A2 con la red GSM. Durante un periodo de tiempo
relativamente corto se vera interrumpido el servicio.
Conclusin: Ante fallo, deberan realizarse las pruebas referentes al tiempo de

reestablecimiento de las conexiones a los primarios de RTC y de GSM (dichas
pruebas se detallan en al apartado 5). Los resultados de dichas pruebas pueden
resultar determinantes a la hora de ofrecer una determinada calidad de servicio, sin
embargo, sin realizar dichas pruebas, se puede observar que la opcin 2.2.1 sera
la menos aconsejable ante fallo.
Caractersticas a nivel de configuracin

Para analizar esta caracterstica, se seguir el siguiente patrn:
Tipo llamada:
Configuracin escenario 1
Configuracin escenario 2
A continuacin se analiza el camino que siguen las llamadas dependiendo del origen
y el destino, se podrn distinguir llamadas internas, externas salientes o externas
entrantes. Se debe tener en cuenta que el nombre de los puertos descritos en los
esquemas de los escenarios se han elegido de forma arbitraria y simplemente para
facilitar la explicacin de las llamadas.
Tambin es necesario mencionar que tambin el valor de 2xxx correspondiente a
los telfonos IP, se ha escogido de forma arbitraria.
Es necesario indicar aqu que puesto que en el apartado anterior se he determinado
(aun sin realizar pruebas) que mandar las llamadas de forma aleatoria por uno u
otro puerto sera la peor opcin, a partir de ahora cuando se haga referencia a este
escenario se considerar que por el puerto A1 salen todas las llamadas destinadas a
fijos tanto externos como internos (para los telfonos IP) y por el puerto A2 las
referentes a mviles.
Llamadas internas:
Escenario 1: Comunicacin entre los usuarios 7750 y 7756, ambas
extensiones conectadas a la centralita Ericsson: no habra modificaciones
sobre la actual configuracin.
Comunicacin entre los usuarios 7750 y 2731: Se modifica la actual
configuracin, se elige el puerto que llamaremos A2 de la centralita A que
145
mandar la llamada a la central Asterisk (la recibe por B2) y ella se

encargar de redirigir la llamada a la extensin correspondiente (tratndola
como una llamada entrante).
De igual forma, si la llamada se realiza de 2731 a 7750, Asterisk mandar la
llamada a travs del puerto B2 de dicha centralita y Ericsson la tratar como
una llamada entrante y la remitir a la extensin seleccionada.
Escenario 2: Comunicacin entre los usuarios 7750 y 7756, ambas
extensiones conectadas a la centralita Ericsson: no sufrir modificaciones a
la configuracin actual.
Comunicacin entre los usuarios 7750 y 2731: Se modifica la
actual
configuracin, ahora cuando se realiza la llamada se usar el puerto A1
como salida y ser la centralita Asterisk quien se encargue de tratar la
llamada.
Cuando la conversacin es establecida por 2731 es Asterisk quien trata la
llamada envindola por el puerto A2 y Ericsson la trata como una llamada
entrante.
En la centralita Ericsson no se realizan modificaciones de configuracin de
las llamadas, las nicas modificaciones son aquellas necesarias para
conectarlo a la centralita Asterisk.
Llamadas salientes
Escenario 1: Llamada desde 7750 al exterior: La extensin llamante puede
acceder al exterior de dos formas distintas:
Marcando _0954xxxxxx: La centralita Ericsson enviar la llamada por
el puerto A1 como hace actualmente.
el puerto A2 y ser Asterisk el encargado de mandarla a travs del
puerto B1 a la red GSM.
La llamada se realiza desde 2731 al exterior:
Marcando el _0954xxxxxx: La centralita Asterisk enviar la llamada
por el puerto B1.
por el puerto B1.
Escenario 2: Llamada desde 7750 al exterior: La extensin llamante puede
acceder al exterior de dos formas distintas:
el puerto A1 como hace actualmente, pero en este caso la centralita
Asterisk tendr que tratarla y volver a enviarla a la red RTC por el
puerto B3.
el puerto A2 y ser Asterisk el encargado de mandarla a travs del
puerto B4 a la red GSM.
La llamada se realiza desde 2731 al exterior:
por el puerto B3.
por el puerto B4.
Llamadas entrantes:
146
Escenario 1: Las llamadas pueden entrar a la centralita a travs de

cualquiera de los dos primarios de los que disponemos.
A travs de la RTC: Cuando llega una llamada a travs de la Red

Telefnica Conmutada, y entra en la centralita Ericsson, esta deber
discriminar si la llamada a la extensin solicitada debe ser tratada
por ella o por la central Asterisk. Si la llamada responde al patrn
_954557xxx o _954558 la centralita A la tratar el mismo, pero si el
patrn con el que coincide es _9542xxx ser enviada a travs del
puerto A2 para que sea Asterisk quien se encargue de dirigirla hacia
la extensin llamada.
Si la llamada llega a travs de la red GSM, ser la centralita Asterisk

quien se encargue de determinar si la llamada debe ser atendida por
ella o enviada a travs del puerto B2 para que se encargue de ella la
central Ericsson.
Escenario 2: Las llamadas pueden entrar a la centralita a travs de

cualquiera de los dos primarios de los que disponemos.
A travs de la RTC: Cuando llega una llamada a travs de la Red

telefnica conmutada, y entra en la centralita Asterisk (puerto B3),
esta deber discriminar si la llamada a la extensin solicitada debe
ser tratada por ella o por la central Ericsson. Si la llamada responde
al patrn _954557xxx u _954558 ser enviada por el puerto B1 para
que la centralita A la trate, pero si el patrn con el que coincide es
_9542xxx ser Asterisk quien se encargue de dirigirla hacia la
extensin llamada.
Si la llamada llega a travs de la red GSM (puerto B4), ser la
centralita Asterisk quien se encargue de discriminar si la llamada
debe ser atendida por ella o enviada a travs del puerto B2 para que
se encargue de ella la central Ericsson.
Llegados a este punto, se resumen las modificaciones que habra que hacerle a la
actual centralita Ericsson, puesto que ser un factor determinante en la eleccin de
topologa.
1. En el escenario 1: El puerto A2 que anteriormente se utilizaba para conectar
con el primario GSM ahora son la salida de las llamadas _0650xxxxxx y las
llamadas _954552xxx correspondiente a las extensiones de los telfonos IP,
por lo tanto hay que modificar Ericsson para que todas las llamadas que
sigan ese patrn vayan encaminadas por ese puerto.
2. En el escenario 2:La nica modificacin necesaria es que cuando se llame a
una de las extensiones correspondientes a telfonos IP, la centralita Ericsson
deber aadirles el 954552xxx y enviarla por el puerto A1 para que la
centralita Asterisk lo trate.
Conclusin: A nivel de modificaciones en la centralita Ericsson, a simple vista no
se aprecian diferencias significativas en cuanto a dificultad de configuracin, sin
embargo, dichas diferencias se pueden hacer patentes en el momento de configurar
las conexiones con las redes RTC y GSM por ejemplo en el escenario 1 donde se
usar la misma conexin para llamadas a fijos como a mviles
Se ha considerado que es necesario analizar en el apartado de configuracin dos
puntos ms, el referente a desvo de llamadas incondicional (para la fase de
147
sustitucin de telfonos) y la configuracin de las conexiones con las redes RTC y

GSM. Dicho anlisis se justifica por el hecho de que en estos dos puntos puede
aparecer una diferencia significativa en cuanto a la dificultad de programar uno u
otro escenario.
Configuracin de desvo incondicional
Para la configuracin del desvo de llamadas incondicional que ser necesario

durante el periodo donde coexistan las dos centralitas pero se empiecen a
eliminar los telfonos actuales, se analizarn a continuacin cmo y donde se
llevarn a cabo las modificaciones necesarias. Hay que tener en cuenta que la
asociacin de nmeros ser similar al siguiente ejemplo: el nmero actual de
extensin es 7750 el nuevo nmero correspondiente al telfono IP ser 2750.
Para cualquiera de los dos escenarios se crear:

Un contexto denominado por ejemplo [desvio_incondicional], donde

mediante una orden hint se asociar la antigua extensin con la actual.
Se deber estudiar la posibilidad de que la extensin IP llame a su
extensin homloga que ya ha sido sustituida
Estas asociaciones debern figurar tanto en la centralita Ericsson como
en la Asterisk, para que dependiendo de por donde llegue la llamada sea
analizada.
El modo de funcionamiento sera como en el siguiente ejemplo:

Miramos si la extensin que llama (p.e 7750) sin el primer dgito coincide con la
extensin a la que se est llamando (p.e 2750) se enva a 2 donde se cuelga, si
son diferentes se enva al contexto desvio_incondicional donde se indicar que
asocie con una extensin determinada y establecer la conexin. Esto debe
hacerse en ambas centralitas, Asterisk y Ericsson. A continuacin se describe
como sera el proceso de redireccin de llamadas.
Llamadas internas:
Escenario 1:
a. Un telfono 7750 til (entendiendo por til que no tiene asociado una
extensin IP) llama al nmero 7753 que ya no es til sino que ahora es
2753. La centralita Ericsson deber identificar que ese nmero de extensin
est ahora asociado a 2753 y le asignar el valor 954552753 y lo enviar
por el puerto A2 para que Asterisk la redirija a la extensin correspondiente.
b. Un telfono 2750 llama a un 7753 que ya no existe: primero Asterisk deber
comprobar que la extensin a la que estoy llamando no es ahora l mismo.
Si fuera as se cortara por ejemplo colgando. Una vez comprobado, la
centralita, deber asignarle el nuevo nmero y dirigir a la extensin
correspondiente, que tambin gestiona ella.
Escenario 2:
a. Un telfono 7750 til llama al nmero 7753 que ya no es til sino que ahora
es 2753. La centralita Ericsson, deber asociarlo al valor que le corresponde
ahora y al identificar que es un nmero 2750 le aadir el 95455 y lo enva
como todas las extensiones correspondientes a IP a travs del puerto A2.La
centralita Asterisk redirigir la llamada a la extensin correspondiente.
148
b. Un telfono 2750 llama a un 7753 que ya no existe: primero Asterisk deber

comprobar que la extensin a la que estoy llamando no es ahora l mismo.
Si fuera as por ejemplo colgar. Una vez comprobado la centralita, deber
asignarle el nuevo nmero y dirigir a la extensin correspondiente, que
tambin gestiona ella.
Conclusin: En cuanto a las llamadas internas, no se aprecian diferencias
significativas en lo referente a la dificultad de programar una u otra.
Llamadas salientes:
Para este caso no afecta el hecho de que haya desvo de llamada puesto que
si un puesto de trabajo solo dispone ya de un telfono IP usar este y el
nmero llamante en este caso es indiferente.
Llamadas entrantes:
Escenario 1:
a. Nmero externo llama a travs de la RTC a una extensin 7750 que ya no
existe: Ericsson comprueba que esta extensin ya no corresponde a ese
valor sino a 2750, le aade el 954552xxx y la enva a travs del puerto A2
para que Asterisk trabaje con ella.
b. Nmero externo llama a travs de GSM a una extensin 7750 que ya no
existe: Asterisk debe comprobar que esta extensin est asociada ahora al
valor 2750 y tratarla como una llamada entrante.
Escenario 2:
a. Nmero externo llama a travs de la RTC a una extensin 7750 que ya no
existe: Asterisk comprueba que esta extensin ya no corresponde a ese
valor sino a 2750, y la redirige a la extensin correspondiente.
b. Nmero externo llama a travs de GSM a una extensin 7750 que ya no
existe: Asterisk debe comprobar que esta extensin est asociada ahora al
valor 2750 y tratarla como una llamada entrante.
Conclusin: En cuanto al tratamiento de llamadas entrantes, en este segundo

caso no se realizaran modificaciones en la centralita Ericsson, sino que tanto por
uno como por otro enlace se analizan las llamadas con Asterisk y se redirigen a la
nueva extensin usando la misma configuracin. Es ms sencilla que la anterior
puesto que con la misma funcin se pueden solucionar los dos posibles casos y en
el escenario 1 debera modificarse tambin la centralita Ericsson.
Hay que tener en cuenta que cuantas ms funciones asuma la centralita Asterisk
ms fcil ser una futura migracin a que sta asuma completamente el control de
la red.
149
Flexibilidad a la hora de aadir nuevos equipos

Se debe tener en cuenta como de difcil ser la migracin a la nueva red IP cuando
se aadan nuevos equipos IP, y si se tender a usar solamente equipos de este
tipo.
Si en un futuro se pretende usar solamente la centralita Asterisk, en el

escenario 1 ser necesario realizar las siguientes modificaciones referentes a
la configuracin de la centralita Asterisk para que el puerto B1 est
directamente conectado a la RTC en lugar de a la centralita Ericsson, lo cual
no es un problema puesto que los nmeros con el patrn _0954xxxxxx
estn ya configurados para salir por ese puerto. Si el resto de los equipos
son IP, dicha centralita tratar directamente las llamadas entrantes.
Si lo que se pretende es migrar desde el escenario 2 no seran necesario

modificaciones algunas, simplemente deshabilitar los puertos B1 y B2 y la
centralita Asterisk seguira funcionando normalmente.
Conclusin
Para la emisin de una conclusin que contribuya a decidir la topologa que se
adoptar como solucin a este proyecto se tendr en cuenta por un lado el
resultado de dicho anlisis as como una serie de consideraciones ajenas a las
ventajas tcnicas.
En primer lugar, para cada una de las anteriores especificaciones se ha obtenido
que:
1. Ante fallo: Escenario 1 no deja sin servicio a la fbrica, sin embargo puede
que tras realizar las pruebas, el tiempo que queda sin servicio en el
escenario 2 se encuentra dentro de unos mrgenes aceptables dentro de la
calidad de servicio exigida.
2. Facilidad de configuracin actual: Escenario 2
3. Facilidad de migracin al uso nico de Asterisk: Escenario 2
4. Desvo de llamada permanente: Escenario 2
Por lo tanto, ante estos resultados y a falta de realizar las pruebas, se estima que
el escenario 2 supondr una mejor solucin al proyecto planteado.
Mediante el anlisis se obtuvo que el Escenario 2 presentaba una condiciones
mucho ms ventajosas respecto al otro candidato para la adopcin del mismo como
solucin al escenario a elegir, sin embargo, a pesar de que este escenario ser el
que se adopte como solucin final, el escenario 1 se usar durante la fase tanto de
pruebas de configuracin como en el periodo donde coexistan la centralita Ericsson
con Asterisk.
150
3.3. FASE 1: IMPLANTACION DE UN SISTEMA DE TELEFONA

CON ASTERISK.
Instalacin de sistema operativo
El primer paso para la instalacin de la centralita Asterisk es decidir que sistema
operativo se usar. Originalmente fue desarrollada para el sistema operativo
GNU/Linux, pero tambin se distribuye en versiones para los sistemas operativos
BSD, MacOSX, Solaris y Microsoft Windows, aunque la plataforma nativa
(GNU/Linux) es la mejor soportada de todas. Por este motivo se elegir Linux como
S.O. No existe ninguna recomendacin por parte del proyecto Asterisk en cuanto a
qu distribucin de Linux utilizar. La distribucin Debian Etch 4.0. ser la elegida
en este caso. Se trata de la ltima versin estable (a fecha de elaboracin de este
documento)
Instalacin del S.O. Debian

Usaremos una imagen oficial tipo netinst que permite una instalacin bsica. Tras la
instalacin de la Debian, aadimos los repositorios en el fichero /etc/apt/source.list
para poder instalar nuevos paquetes va Internet. En concreto aadimos la
siguiente lnea al fichero:
http://http.us.debian.org/debian stable main contrib non-free
El siguiente paso es actualizar la lista de paquetes de nuestro repositorio. Para ello
ejecutamos:
>apt-get update
Ahora actualizamos la versin de los paquetes que ya tenemos instalados con:
>apt-get upgrade
En el caso de que la actualizacin haya instalado un nuevo kernel tendremos que
reiniciar el sistema con shutdown r
now. Despus de reiniciar el sistema,
entramos como usuario root. Para satisfacer las dependencias de Asterisk hay que
instalar algunos paquetes adicionales. En concreto:
Build-essential
Libncurses5-dev
Libcurl3-dev
Libvorbis-dev
Libspeex-dev
Unixodbc
Unixodbc
Libiksemel-dev
Linux-header-<version_del _kernel>
Para hacerlas efectivas ejecutamos el comando apt-get. Para instalar la versin
correcta del paquete linux-header necesitamos conocer el kernel de nuestro
sistema. Esto se puede averiguar con uname r. Ya estamos en disposicin de
comenzar la instalacin de Asterisk.
151
Instalacin de Asterisk
En primer lugar nos cambiamos al directorio /usr/src para guardar el cdigo fuente
de Asterisk. Para obtener Asterisk, podemos dirigimos a su pgina oficial
www.asterisk.org. Debemos asegurarnos de utilizar una versin estable y no una
de desarrollo. Cuando se escribi este documento, la ltima versin estable era la
1.6.1. Otra forma de conseguir el cdigo fuente es
ejecutando desde de la
consola el siguiente comando:
>wget
http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk1.6.1.9.tar.gz
Adems del cdigo de Asterisk necesitamos los drivers Dahdi. El paquete dahdilinux provee a nuestro servidor de drivers para las tarjetas de conexin a las lneas
de telefona tradicional ya sean las E1, T1. stos se usan para poder utilizar
hardware de Digium, como por ejemplo las tarjetas TDM400P, TE110P, etc.
Tambin usaremos la versin 1.4. Para obtenerlos:
>wget
http://downloads.asterisk.org/pub/telephony/dahdi-linuxcomplete/releases/dahdi-linux-complete-2.2.0.2+2.2.0.tar.
A continuacin descargamos las libreras libpri que sirve para gestionar los enlaces
RDSI. El empaquetado de libpri da a nuestra central telefnica la posibilidad de
realizar conexiones a lneas primarias como las que existen en las PSTN. Se pueden
descargar haciendo:
>
get
http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri1.4.10.2.tar.gz
El siguiente paso es conseguir unos mdulos adicionales llamados Asterisk-addons
que permiten usar bases de datos para almacenar detalles de las llamadas
(proveen drivers para conexin a servidores de MySQL) y permite utilizar
archivos MP3 para la msica en espera. Tambin aade el protocolo H.323 para
proveer a los usuarios servicio de teleconferencia con capacidades de voz, video y
datos. Para ello:
>
wget
http://downloads.asterisk.org/pub/telephony/asterisk/asteriskaddons-1.6.1-current.tar.gz
Por ltimo, obtenemos un conjunto de archivos con voces en castellano desde
http://dowloads.digium.com/pub/telephony/sounds. Una vez que tenemos el cdigo
fuente de Asterisk y del resto de los mdulos nos disponemos a compilarlo.
Compilacin de Asterisk y mdulos adicionales

En primer lugar debemos descomprimir los ficheros que nos hemos descargado
para poder compilarlos. Nos ubicamos en el directorio /etc/src y ejecutamos la
orden:
> tar xvzf <fichero>
152
Una vez descomprimidos, los mdulos deben compilarse siguiendo un orden

concreto:
1.
2.
3.
4.
dahdi-linux-complete
libpri
Asterisk
Asterisk-addons
Compilacin de los drivers de Dahdi

Para la compilacin de este mdulo se ejecutan los siguientes comandos:
> cd /usr/src/zaptel-1.6.<x>
> make clean
>./configure
base de
> make && make install
> make config
Asterisk
# en <x> ponemos el valor que corresponda

# borra los ficheros compilados antiguos
#script que crea el makefile que constituye la
#compilacin
#lee el fichero makefile
# crea los script de arranque y parada de
Asterisk requiere de una fuente de sincronizacin. En ausencia de una fuente de

sincronizacin hardware, nosotros usaremos el software de sincronizacin contenido
en el mdulo ztdummy del kernel. Para cargarlo ejecutamos:
> modprobe ztdummy

Una vez agregado el mdulo de Zaptel al Kernel de Linux es recomendable reiniciar
el equipo. Si adems se cuenta con una tarjeta Digium se puede verificar que el
mdulo se instal correctamente, viendo si se enciende el indicador LED de la
tarjeta.
Compilacin de libpri
Ahora agregaremos la librera de Libpri que como dijimos se utiliza para poder
manejar tarjetas para enlaces E1 con la sealizacin PRI.
> cd /usr/src/libpri-1.6.<x>
> make clean
> make && make install
Compilacin de Asterisk
Los pasos seguidos son los siguientes:
> cd /usr/src/asterisk-1.6.<x>
> make clean
> ./configure
>make && make install
> make samples
defecto
# donde <x> es la versin 1.4 actual
# instala los ficheros de configuracin por
153
>make progdocs
>make config
A partir de este momento Asterisk est instalado. Se puede teclear man asterisk en
la lnea de comandos de Linux para obtener detalles de como arrancar y parar el
servidor.
Los ficheros de configuracin de Asterisk se encuentran en el directorio
/etc/asterisk.
Compilacin de Asterisk-addons
A continuacin describimos como se instala este mdulo.
> cd /usr/src/Asterisk-addons-1.6.<x>
actual
>make clean
>./configure
> make & make install
# donde <x> es la versin 1.6
Adicin de voces en castellano

Tras la compilacin copiamos todos los archivos con las voces en castellano
descargados de http://dowloads.digium.com/pub/telephony/sounds al directorio de
sonidos por defecto de Asterisk que es /var/lib/asterisk/sounds.
> cp rf /usr/src/asterisk-sounds/*
/var/lib/asterisk/sounds/
Scripts de arranque y parada del servicio

Se usan para arrancar Asterisk de forma automtica al iniciar el equipo y para que
se detenga de forma adecuada cuando el sistema de apague o reinicie.
> cd /usr/src/asterisk-1.4.<x>
> echo ztdummy >> /etc/modules
el sistema
# hace que el mdulo arranque al iniciar
Para utilizar estos scripts:
>/etc/init.d/asterisk {start|stop|restart}
Instalacin y configuracin de heartbeat

En este apartado se va a explicar como instalar y configurar un cluster de 2 nodos
usando heartbeat. Para configuran un mayor nmero de equipos el procedimiento
sigue siendo vlido.
En primer lugar debemos instalar el mdulo:
> apt-get install heartbeat

Ponemos las direcciones IP los nombres de los equipos en el fichero /etc/hosts de
ambos nodos. Para nuestro ejemplo tenemos:
154
172.0.0.1
172.16.16.55
172.16.16.56
localhost.localdomain
asterisk-A.us.es
asterisk-B.us.es
localhost
asterisk-A
asterisk-B
Debemos modificar 3 ficheros en cada una de las mquinas, stos se encuentran en

/etc/ha.d. Son:
1. authkeys: Configura la autentificacin de red.
2. ha.cf: Configura informacin bsica del cluster.
3. haresources.cf: Configura los grupos de recursos tipo init.
En authkeys especificamos las claves, para nuestro caso usaremos el modo
inseguro CRC (por ser simplemente un caso de ejemplo) asumiendo que tenemos
un firewall bien configurado. Se puede usar md5 o sha para mayor seguridad.
auth 1
1 crc
En el fichero ha.cf especificaremos las opciones de configuracin de hearbeat.
Primero indicamos donde queremos guardar los logs, en keepalive le indicamos que
los latidos se enviarn cada 2 segundos, en deadtime especificamos que si un nodo
no responde en 30 segundos est muerto, en warntime le decimos que si no
responde en 10 segundos se lanzar una alerta. En el inicio antes de considerar un
nodo muerto esperaremos 120 segundos para evitar problemas con el arranque del
servicio (initdead). Usaremos el puerto UDP 649 para la comunicacin entre las
mquinas, en ucast indicaremos nuestro dispositivo ethernet y configuramos que
los latidos se enven al otro equipo por unicast. Ponemos el parmetro failback en
on para indicar el comportamiento en caso de recuperacin ante un nodo cado.
Estando en on, ste recuperar todos los servicios al volver a estar activo, si lo
dejamos en off, los servicios residirn en el nodo espejo hasta que ste caiga.
Finalmente indicamos que nodos forman el servicio y un dispositivo ethernet para
broadcast. El fichero descrito se muestra a continuacin.
-------------------------------------------------------------------------------------------------------------#
File to write debug messages to
debugfile /var/log/ha-debug
#
File to write other messages to
logfile /var/log/ha-log
#
Facility to use for syslog()/logger
logfacility local0
#
A note on specifying "how long" times below...
#
The default time unit is seconds
#
10 means ten seconds
#
You can also specify them in milliseconds
#
1500ms means 1.5 seconds
#
keepalive: how long between heartbeats?
keepalive
2
#
deadtime: how long-to-declare-host-dead?
#
If you set this too low you will get the problematic
#
split-brain (or cluster partition) problem.
#
See the FAQ for how to use warntime to tune deadtime.
deadtime
30
#
warntime: how long before issuing "late heartbeat" warning?
#
See the FAQ for how to use warntime to tune deadtime.
warntime 10
155
#
Very first dead time (initdead)
#
On some machines/OSes, etc. the network takes a while to come up
#
and start working right after you've been rebooted. As a result
#
we have a separate dead time for when things first come up.
#
It should be at least twice the normal dead time.
initdead
120
#
What UDP port to use for bcast/ucast communication?
udpport 694
#
Set up a unicast / udp heartbeat medium
#
ucast [dev] [peer-ip-addr]
#
[dev]
device to send/rcv heartbeats on
#
[peer-ip-addr] IP address of peer to send packets to
ucast eth0 (ip_del_otro_servidor, es decir 172.16.16.55 172.16.16.56)
#
auto_failback on
#
Tell what machines are in the cluster
#
node nodename ... -- must match uname -n
node asterisk-A
node asterisk-B
bcast eth0
---------------------------------------------------------------------------------------------------------Estos ficheros deberan ser idnticos para los dos equipos con la excepcin de la
lnea ucast donde se debe poner la direccin del nodo espejo que ser diferente
para cada uno. En el fichero haresources especificaremos los servicios que debe
manejar hearbeat. Este fichero debe ser el mismo en los dos nodos.
asterisk-A
IPaddr2::172.16.16.57/eth0
asterisk
En la lnea anterior la direccin IP no es la de ninguno de los dos nodos. Esto es as

porque el servicio se ofrece a travs de una IP virtual (172.16.16.57). Los clientes
debern indicar esa direccin como la del Proxy SIP.
Tras realizar la configuracin, reiniciamos el servicio heartbeat en las dos
mquinas:
> /etc/init.d/heartbeat restart

Es importante indicar que el servicio slo debe estar activo en un nodo a la vez.
Cuando el que est ofrecindolo cae, heartbeat es el encargado de que se arranque
en otro nodo.
3.4. FASE 2: CONFIGURACIN DEL PLAN DE MARCADO Y

SERVICIOS OFRECIDOS
Antes de detallar la configuracin del plan de marcado, se har un breve resumen
sobre las caractersticas y la configuracin de los conceptos que maneja el plan de
marcado.
El plan de marcado o Dial plan es el fichero residente en algunos gateways y en
casi todas las IP-PBX que permite determinar el tratamiento que debe darse a un
nmero que llega a Asterisk. Para ello, se hace uso de patrones y combinaciones de
dgitos que permiten al software saber qu hacer en funcin del nmero llamado o
llamante.
156
Esto permite enrutar las llamadas automticamente de acuerdo a la ruta ms

conveniente. El dial plan es totalmente configurable. No slo permite fijar la ruta de
salida de las llamadas. Tambin permite bloquear nmeros que comienzan con una
secuencia de dgitos, anteponer siempre uno o varios dgitos, reemplazar dgitos
por otros prefijados, autorizar nmeros determinados, etc.
3.4.1. Elementos bsicos en la configuracin de Asterisk

Asterisk est formado por una serie de ficheros donde se irn definiendo cada uno
de los elementos que formen parte del escenario.
A continuacin se van a definir algunos de los conceptos ms importantes de
Asterisk, y sobre los que se sustentar todo el escenario de trabajo.
Canal: Es la conexin que recoge una llamada entrante o saliente con el

sistema Asterisk. La conexin puede ir o venir de la red telefnica tradicional
o de una red VoIP. Asterisk soporta varios tipos de canales, los ms
importantes FXO, FXS para lneas analgicas, SIP para lneas a redes VoIP e
IAX para conexin entre servidores Asterisk.
Extensin: En la telefona tradicional se asocia con telfonos, interfaces o

mens. En Asterisk una extensin es una lista de comandos a ejecutar. Las
extensiones se acceden cuando:

Se recibe una llamada entrante por un canal dado

El usuario que ha llamado marca una extensin
Se ejecuta un salto de extensiones desde el dialplan de Asterisk
Patrones de numeracin de Asterisk: El plan de numeracin no est limitado

solo a nmero fijos, se pueden usar tambin patrones de nmeros para
controlar el flujo de llamadas. Para ello el patrn debe iniciarse con el
smbolo _.
Contexto: El dialplan o lgica de Asterisk se divide en uno o varios
contextos. Un contexto es una coleccin de extensiones. Los contextos
existen para poder diferenciar el lugar donde se encuentra una llamada,
para:
Aplicar polticas de seguridad: Asterisk no se comporta igual cuando
un usuario local marca el 1 que cuando un usuario externo marca el
1.
Mens y submens diferenciados
Aplicacin: Asterisk ejecuta secuencialmente los comandos asociados a cada
extensin. Esos comandos son realmente aplicaciones que controlan el
comportamiento de la llamada y del sistema en s. Ejemplos de ello son:
HangUp: Colgar la llamada.
Dial: Realizar una llamada saliente
Goto: Salta a otra extensin o context
Etc
Todos estos conceptos sern la base para la creacin de un dialplan que ofrezca
una solucin ptima al escenario planteado para este trabajo.
En Asterisk, el dial plan se configura en el archivo extensions.conf. El fichero
extensions.conf se compone de secciones o contextos definidos entre corchetes [].
Hay dos contextos especiales que estn siempre presentes que son [general] y
[globals]
157
Contexto [general]
El contexto [general] configura unas pocas opciones generales como son:

static: Indica si se ha de hacer caso a un comando "save dialplan" desde la

consola. Por defecto es "yes". Funciona en conjunto con "writeprotect".
writeprotect: Si writeprotect=no y static=yes se permite ejecutar un
comando "save dialplan" desde la consola. El valor por defecto es " no".
autofallthrough: Si est activado y una extensin se queda sin cosas que
hacer termina la llamada con BUSY, CONGESTION o HANGUP Si no est
activada se queda esperando otra extensin. Nunca debera suceder que una
extensin se quede sin cosas que hacer como explicaremos posteriormente.
clearglobalvars: Si est activado se liberan las variables globales cuando
se recargan las extensiones o se reinicia Asterisk.
En general estas opciones no son muy importantes y se suelen dejar tal y como
aparecen por defecto.
Contexto [globals]
En este contexto se definen las variables globales que se van a poder utilizar en el
resto de los contextos. En este caso se han definido como variables globales el
tamao mximo (9) y mnimo (4) que puede aceptar Asterisk como nmero
telefnico o de extensin. Tambin se les ha asignado variable global a los canales
DAHDI donde se comunica con los primarios para facilitar el trabajo con ellos.
Adems de los contextos genricos, en este dial plan se han creado tres tipos de
contextos:
Contextos de servicios: Son contextos que recogen la programacin de los

servicios tanto bsicos como avanzados que ofrece Asterisk a los distintos
usuarios.
Contextos de permisos: Estos contextos se crean para restringir el tipo de

llamada que se puede realizar que debe ser acorde con el perfil del
trabajador. Existen 5 tipos de permisos (y contextos) que van desde el 0,
donde se pueden realizar llamadas internas, provinciales, nacionales, a
mviles e internacionales hasta el permiso 5 que solo permite llamadas
internas.
Contextos de organizacin: Estos contextos son tres y se encargan del

encaminamiento de todas las llamadas que pasan por Asterisk. Realmente
son el corazn de Asterisk ya que sin ellos no sabra que hacer con las
llamadas que llegan de la red o que van dirigidas a ellas.
A continuacin se detalla el plan de marcado de la solucin ofrecida con Asterisk.
158
3.4.2. Configuracin Servicios Bsicos

En este anexo se profundiza en el cdigo que permite implementar los servicios
bsicos.
Funcin Llamada a tres

Este servicio nos permite establecer una llamada a dos usuarios usando la misma
lnea. El cdigo usado se presenta a continuacin:
[conferencia]
exten => 600,1,Answer()
exten => 600,n,MeetMeCount(600,CONFCOUNT)
exten => 600,n,Noop(${CONFCOUNT})
exten => 600,n,GotoIf($[${CONFCOUNT} <= 2]?conf:full) ;el primer
participante no lo cuenta, es la llamada a 3
exten => 600,n(conf),Authenticate(1234)
exten => 600,n,MeetMe(600,,cix)
exten => 600,n(full),Playback(conf-full)
exten => 600,n,HangUp()
Para la implementacin de esta funcin se ha hecho uso principalmente

funciones de Asterisk, son:
de tres
1. MeetmeCount: Se utiliza para contar el nmero de participantes en una

conversacin. Empieza a contar desde el segundo usuario que accede al
room, puesto que el primero es el que inicia la conferencia.
2. Meetme: Esta funcin se usa para establecer la comunicacin, es decir,
cuando un usuario marca un nmero para acceder a un room, esta
funcin se encarga de indicarle a Asterisk con quien debe establecer la
comunicacin. Ofrece gran cantidad de opciones de configuracin, como
por ejemplo una clave para restringir el acceso que el usuario que
intenta acceder a la conferencia debe pulsar, etc Sin embargo, en este
caso la autenticacin se llevar a cabo con otra funcin, Authenticate.
3. Authenticate: Se solicita al llamante que introduzca una contrasea dada
para continuar con la ejecucin de la siguiente prioridad del dialplan
(establecer la comunicacin con Meetme). Esta funcin da a la persona
que llama tres oportunidades para introducir la contrasea
correctamente.
Si la contrasea no se introduce correctamente despus de tres intentos,
el canal se bloquea.
Una vez se ha explicado el trabajo realizado por cada una de estas funciones, la
comprensin del cdigo es inmediata.
La primera vez que Asterisk detecta el patrn que coincide con el nmero que se
marca para establecer la conferencia (en este caso 600), se inicia un contador,
COUNTCONF, que se actualizar con cada participante que entra en la conferencia.
Cada vez que este contador se aumenta, se comprueba su valor, y si es superior a
dos se enva a la prioridad con etiqueta full donde se escuchar una locucin que
informa al usuario que esta conversacin est completa y no puede acceder.
159
Si el nmero de usuarios todava no llega a tres se autentica al usuario,

solicitndole que introduzca la contrasea necesaria (en este caso 1234). Si se
introduce correctamente se establece la comunicacin. Como se ha explicado antes,
si el usuario no conoce la clave de acceso a la conexin su comunicacin se quedar
bloqueada.
Funcin Buzn de Llamadas

Este servicio ofrece la posibilidad a un usuario que llama a una extensin y o bien
no contesta o est ocupado, deje un mensaje en el buzn de voz.
Para la explicacin del cdigo correspondiente a esta funcin, es necesario indicar
primero que para implementar este servicio se ha usado una macro.
Las macros son instrumentos de diseo muy tiles para evitar la repeticin en el
dialplan de determinadas sentencias. Para utilizar una macro en nuestro dialplan,
se hace uso de la aplicacin Macro ().Esta aplicacin llama a la macro especificada
(indicando el nombre) y se le pasa los argumentos que se hayan especificado
como necesarios.
Para este caso concreto, se ha codificado una macro voicemail que se encargar
del establecimiento de llamada y de qu hacer en caso de que esta llamada no sea
contestada.
En primer lugar se analizar dicha macro, dividindola en varias partes. El motivo
de esto es que lleva incluidas una serie de acciones necesarias para el correcto
funcionamiento de otros servicios, puesto que requieren la misma informacin
referente a la llamada.
Comprobaciones y establecimiento de llamada
[macro-voicemail]
exten => s,1,Set(CFIM=${DB(CF/${MACRO_EXTEN})})
exten => s,n,Noop(${CFIM})
exten => s,n,GotoIf($["${CFIM}"=""]?NoCF:CF)
exten => s,n(CF),Dial(SIP/${CFIM},10,tT)
exten => s,n,Set(vm=${CFIM})
exten => s,n,Goto(estado)
exten => s,n(NoCF),Dial(SIP/${MACRO_EXTEN},10,Tt)
exten => s,n,Set(vm=${MACRO_EXTEN})
;exten => s,n,Noop(${DIALSTATUS})
1. En primer lugar se va a comprobar que el nmero al que se llama no

tiene establecido ningn desvo de llamadas, para ello, se almacena en la
variable CFIM el valor que se tenga almacenado en la base de datos en
CF/${MACRO_EXTEN}, es decir, CFIM contendr el nmero al que
desviar la llamada en el caso de que este exista (este activo el desvo de
llamadas) y estar vaco si no est activo este servicio.
2. Dependiendo de si existe o no se enviar a prioridades diferentes. Si el
desvo existe, se enva a la prioridad etiquetada como (CF) y
se
establece un canal SIP con el nmero al que se desva la llamada, de
esto se encarga la funcin Dial.
160
3. Si la comunicacin se establece satisfactoriamente, la llamada se realiza,

si no se almacena el valor del nmero al que desviar la llamada en la
variable vm y se saltar a la prioridad con etiqueta estado para
analizar el motivo de que la llamada no se haya realizado correctamente.
Esto se explicar a continuacin.
4. En el caso de que no se haya establecido un desvo de llamadas, Asterisk
establece un canal de comunicacin con la extensin llamada. Si no
puede realizarse, en la prioridad etiquetada como estado se analiza el
motivo.
Anlisis del estado
Llegados a este punto, tenemos una llamada que no se ha establecido, bien porque
el nmero llamado no est o est ocupado.
exten => s,n(estado),GosubIf($[${DIALSTATUS}=NOANSWER]?s-NOANSWER,1:sBUSY,1)

;NO ANSWER OR BUSY en un desvo de llamadas el buzn de voz disponible
ser el de la extensin a la que se reenva
exten => s-NOANSWER,1,Voicemail(${vm}@default,u))
exten => s-NOANSWER,n,HangUp()
;exten => s-BUSY,1,Answer()
;exten => s-BUSY,n,Wait()
exten => s-BUSY,n,Set(ID=${ARG1})
exten => s-BUSY,n,Read(callbusy,,1,5)
exten => s-BUSY,n,GotoIf($["${callbusy}"="5"]?re:buzon)
exten => s-BUSY,n(re),macro(rellamada-automatica,${ID},${MACRO_EXTEN})
exten => s-BUSY,n(buzon),Voicemail(${vm}@default,b)
exten => s-BUSY,n,HangUp()
Aqu pueden ocurrir dos cosas dependiendo del motivo por el que se ha llegado a
esta prioridad. En la primera lnea del cdigo se analiza el motivo y se enva a
prioridades distintas donde las llamadas sern tratadas en funcin de ello.
Haciendo uso de la funcin GosubIf donde se evala la condicin (se comprueba el
valor de la variable DIALSTATUS, donde se almacena el estado de la llamada, es
decir, el motivo por el que no se ha completado) y se enva a prioridades distintas.
Podemos encontrar dos casos:
1. Etiqueta s-NOANSWER: El motivo por el que no se complet la llamada
es que el usuario no contest. Haciendo uso de la aplicacin voicemail
(que se encarga de la gestin del mensaje de voz).Esta aplicacin
permite enviar a buzn de voz distinto si no contesta, para ello se usa la
opcin u. El buzn al que enviar el mensaje si indica mediante la
sentencia (${vm}@default,u)), es decir, vm contiene el nmero de
extensin al que iba dirigida la llamada, independientemente de que
tenga o no establecido el desvo de llamadas.
2. Etiqueta s-BUSY: Si se ha llegado aqu, es porque hemos llamado a una
extensin y sta, estaba comunicando. Uno de los servicios bsicos que
se pueden ofrecer es la rellamada-automtica. Este servicio permite al
llamante la opcin de presionar una tecla (en este caso el 5) a travs de
161
la cual Asterisk se encargar de marcar la extensin ocupada y una vez

que est libre conectarla con el llamante. Por ello, se debe decidir si el
llamante prefiere esperar a que cuelgue y hablar con l (pulsando el 5) o
si desea dejarle directamente un mensaje en el buzn de voz. Los pasos
a seguir son:

Meditante la funcin Set asignamos a la variable ID el valor

del nmero que est realizando la llamada. En este caso ese
nmero se le pasaba como argumento uno (${ARG1}) a la
macro.
Con la funcin Read, se asigna un valor a una variable, en este
caso
espero que el llamante presione
la tecla 5 , que
almacenar en la variable callbusy durante 5 segundos que es el
valor del Timeout. Si se pulsa 5 se inicia el proceso que permita
la rellamada. Sobre todo esto se profundizarn el la seccin
correspondiente a dicho servicio.
Dependiendo si se ha activado o no la rellamada se saltar a
una prioridad u otra.
Si se ha activado, se llama a la macro rellamada-automtica,
pasndole todos los argumentos necesarios.
Si no se ha activado, el llamante podr dejar un mensaje de voz
en el buzn, haciendo uso de nuevo de la aplicacin voicemail.
Los argumentos necesarios son los mismos que en el caso de
que la llamada no fuese contestada, pero en esta ocasin la
opcin es b (buzn de voz caso ocupado).
Finalmente se cuelga
Llamada a la macro
Por ltimo, se presenta a continuacin la llamada a la macro que hemos explicado
anteriormente.
Esta macro se ejecutar cuando Asterisk detecte un patrn 3XXX, correspondiente
a una extensin SIP. Los parmetros de la macro son:
1. Nombre de la macro
2. Nmero de extensin llamante (que se usar posteriormente para la
comprobacin de si est activa la llamada automtica)
exten => _3XXX,n,Macro(voicemail,${CALLERID(num)})
Desvo de llamadas
Este servicio se utiliza para permitir a un usuario que va a cambiar de ubicacin
temporalmente poder recibir las llamadas que van dirigidas a su extensin en la
nueva ubicacin.
La codificacin de esta funcin se basar en el uso de la base de datos propia de
Asterisk (AstDB) donde se almacenar el nmero al que se desvan las llamadas.
El cdigo es el siguiente:
[callforwarding]
exten =>_*21*X.,1,Noop(${LEN(${EXTEN})})
exten
=>_*21*X.,n,GotoIf($[${LEN(${EXTEN})}=$[${TAM_EXTERNO}+5]]?externo:3);
162
a esos valores se le suman los 5 dgitos *21* y # del final

exten
=>_*21*X.,n,GotoIf($[${LEN(${EXTEN})}=$[${TAM_INTERNO}+5]]?interno:4)
exten =>_*21*X.,n,HangUp()
exten =>_*21*X.,n(externo),Set(DB(CF/${CALLERID(NUM)})=${EXTEN:4:9})
exten =>_*21*X.,n,Noop(el numero ${EXTEN:4:9} es un numero externo)
exten =>_*21*X.,n,HangUp()
exten =>_*21*X.,n(interno),Set(DB(CF/${CALLERID(NUM)})=${EXTEN:4:4})
exten =>_*21*X.,n,Hangup()
exten => #21#,1,Noop(borrado=${DB_DELETE(CF/${CALLERID(num)})})
exten => #21#,n,HangUp()
En este cdigo, se diferencia por un lado la activacin del servicio y por otro la
desactivacin.
Activacin desvo de llamadas
Cuando Asterisk detecta el patrn _*21*X., lo que interpreta es que va a iniciarse
un desvo de llamadas (*21*) y el nmero al que realizar dicho desvo.
Este nmero de telfono puede ser tanto una extensin o un nmero de telfono
externo.
En este caso, se har uso de dos variables globales, TAM_EXTERNO (que es igual a
9) y TAM_INTERNO (que tendr almacenado el valor de 4).
El primer paso a realizar es comprobar si el nmero al que se desva la llamada es
un nmero externo o no, comprobando la longitud del mismo, es decir, si
corresponde a un nmero externo estar formado por nueve dgitos a los que habr
que sumar los cuatro correspondientes al indicador de desvo de llamadas (*21*) y
un ltimo carcter (#), en total cinco dgitos ms. A pesar de que ste ltimo
carcter no tiene ninguna utilidad para Asterisk, se pretende mantener el servicio
que haba originalmente y en ste si se usaba. La centralita lo interpretaba como el
ltimo dgito que se iba a introducir.
Si corresponde a un nmero externo se salta a la prioridad etiquetada como
externo y se almacena en la base de datos. La sintaxis para almacenar un valor en
esta base de datos responde al patrn FAMILY/KEY. En este caso se usar
CF/${CALLERID(NUM)}, es decir, la familia ser CF( callforwarding) y la llave ser
el nmero que est realizando la llamada, es decir, el usuario que pone en marcha
el servicio.
El nmero que se almacena ser el nmero que se marque despus del *21*, es
decir, primero se eliminan los 4 primeros dgitos y de lo que quede y se seleccionan
los 9 primeros (hay que eliminar el # del final).
En esta versin de Asterisk, se har uso de la funcin Set para almacenar valores
en AstDB.
Si el nmero que inicia el servicio desva la llamada a una extensin ( se
comprueba al inicio mediante el tamao) se saltar a la prioridad con etiqueta
interno.En esta prioridad se repite el almacenamiento del nmero al que se
desviar la llamada.
El nico motivo de separar ambos casos es el hecho de que hay que eliminar el
ltimo carcter introducido y para ello se debe jugar con el tamao de los patrones.
Desactivacin desvo de llamadas
La desactivacin de este servicio, inicia cuando Asterisk encuentra el patrn #21#.
En ese momento, lo nico que deber hacer ser eliminar la entrada
correspondiente de la base de datos.
163
Para ello hace uso de la funcin (borrado=${DB_DELETE(CF/${CALLERID(num)})},

donde se elimina la entrada correspondiente a la familia CF con llave
correspondiente al nmero que est iniciando el servicio.
Rellamada
El servicio de rellamada se utiliza para llamar al ltimo nmero llamado.
Las lneas de cdigo usadas para implementar esta funcin son muy sencillas pero
se realizan en dos pasos.
En primer lugar cada vez que un usuario realiza una llamada se almacena ese
nmero en la AstDB como:
exten => _3XXX,1,Set(DB(${CALLERID(num)}/ultimo)=${EXTEN}
Es decir, nmero llamante/ultimo ser igual al nmero al que llama. Este valor se
ir refrescando con cada nueva llamada y es un paso previo a la posibilidad de
solicitar el servicio.
La funcin propiamente dicha es:
[rellamada]
exten => ***,1,Dial(SIP/${DB(${CALLERID(num)}/ultimo)})
Aqu simplemente se establece un canal SIP (haciendo uso de la aplicacin Dial)
con el ltimo nmero almacenando en la base de datos correspondiente a la
extensin llamante.
Rellamada automtica
Del uso de este servicio se ha hablado el la explicacin del servicio Voicemail. Aqu
se profundizar en la macro que se encarga de reestablecer la llamada.
Llamada a macro
Se recuerda la llamada a la macro.
exten => s-BUSY,n(re),macro(rellamada-automatica,${ID},${MACRO_EXTEN})
En esta llamada, se indica aparte del argumento obligatorio del nombre de la macro
que se quiere ejecutar, el contenido de la variable ID, donde se almacena la
extensin del nmero llamante (pasada como argumento uno a la macro voicemail
que es desde la que se llama)
y la extensin a la que se llam en la macro
original, almacenada en MACRO_EXTEN, es decir, el nmero llamante y el llamado.
Macro
Antes de pasar a explicar el cdigo de la macro utilizada, es necesario aclarar
algunos conceptos previos.
164
Call file
Para la implementacin de esta funcin, se va a aprovecha la capacidad de Asterisk
de procesar archivos de texto con unas caractersticas concretas y transformarlos
en llamadas salientes. Estos tipos de archivos se llaman call files.
Utilizando este mtodo, se debe dar a Asterisk la siguiente informacin:

Cmo realizar la llamada, similar a la aplicacin Dial().

Qu hacer cuando se contesta la llamada
Se crear un archivo con la sintaxis necesaria y colocado en el directorio de la cola

de salida, que se encuentra por defecto en / var / spool / asterisk / outgoing /
(configurable en asterisk.conf).. Por el sistema utilizado por Asterisk para procesar
estos archivos, stos no se pueden crear directamente en la carpeta
/var/spool/asterisk/outgoing.
La estructura de un call files es la siguiente:
1. Channel: <channel>; Extensin a la que se quiere llamar
2. Callerid: <callerid>; El identificador de llamada que queremos enviar a la
extensin llamada.
3. WaitTime: <number>; Cuantos segundos esperamos antes de considerar
la llamada sin xito
4. Maxretries: <number>; Numero de veces que intentaremos llamar la
extensin
5. RetryTime: <number>; Cuantos segundos debe esperar Asterisk para
volver a marcar.
6. Account: <account>; El nombre de la cuenta con la cual queremos
grabar esta llamada (CDR)
Una vez que la extensin llamada conteste tenemos que decirle a Asterisk lo que
tiene que hacer. Esto tambin se define en el mismo archivo. Hay dos opciones:
1. Ejecutar una aplicacin, indicando la aplicacin (Application: <appname>)
que se va a usar as como las opciones que se consideran necesarias para
dicha aplicacin (Data: <args>).
2. Ejecutar un punto concreto del plan de marcado o dialplan, es decir, el
contexto (Context: <context>), la extensin (Extension: <exten>) que se
quiere usar en el contexto especificado, la prioridad (Priority: <priority>) o
etiqueta si est definida y las variables que se pueden necesitar en el
contexto (Setvar: <var=value>).
En este caso se usar una aplicacin y en concreto la aplicacin Dial
Descripcin
La macro que se ejecuta bajo el nombre rellamada-automtica es la siguiente:
[macro-rellamada-automatica]
exten => s,1,System(echo Channel:SIP/${ARG2}>>/tmp/callback${ARG2})
exten => s,n,System(echo WaitTime:5>>/tmp/callback${ARG2})
exten => s,n,System(echo Maxretries:2>>/tmp/callback${ARG2})
165
exten => s,n,System(echo RetryTime:5>>/tmp/callback${ARG2})

exten => s,n,System(echo Account:${ARG1}>>/tmp/callback${ARG2})
exten => s,n,System(echo Application:Dial>>/tmp/callback${ARG2})
exten => s,n,System(echo Data:SIP/${ARG1}>>/tmp/callback${ARG2})
exten => s,n,Wait(1)
exten => s,n,System(mv /tmp/callback${ARG2}
/var/spool/asterisk/outgoing)
exten => s,n(unavail),HangUp()
exten => s,h,HangUp()
La aplicacin usada durante todo el cdigo es System(). Esta aplicacin, ejecuta un

comando en el sistema operativo subyacente.
La ejecucin es:
Con
la
lnea
de
cdigo
System(echoChannel:SIP/${ARG2}>>/tmp/callback${ARG2})
comienza
la
creacin del fichero Call file, Asterisk llamar a la extensin ocupada. Creamos un
archivo de texto llamado callback seguido de la extensin del nmero llamado en la
carpeta /tmp.
Las lneas de cdigo siguientes son para configurar los valores de los campos que
necesitar Asterisk para ejecutar la rellamada, como pueden ser el tiempo que
debe esperar para considerar que la llamada se ha realizado sin xito (WaitTime)
que en este caso son 5 segundos, el nmero mximo de intentos (MaxRetry) que
ser de dos, etc
Una vez que la extensin llamada conteste tenemos que decirle a Asterisk lo que
tiene que hacer, en este caso ejecutamos la aplicacin Dial para establecer la
conexin con el usuario llamante y as completar la llamada.

Application:Dial>>/tmp/callback${ARG2}
Data:SIP/${ARG1}>>/tmp/callback${ARG2}
A continuacin movemos el fichero a la carpeta en el directorio de la cola de salida,

que se encuentra por defecto en / var / spool / asterisk / outgoing /.
Asterisk controlar cada segundo si hay algn archivo nuevo en la carpeta y lo
procesar en seguida.
A continuacin, abrir una conexin con el dispositivo que se le indique (mediante
Channel). Si el dispositivo est en uso o no responde, Asterisk intentar la
comunicacin tantas veces como indique le valor almacenado en MaxRetries.
Es decir, el funcionamiento sera: Asterisk llamar la extensin que reserv la
llamada ( nmero llamado), una vez que conteste, ejecutar la aplicacin Dial y
llamar el numero de telfono escogido para la llamada programada, es decir, el
nmero del llamante y podremos hablar.
3.4.3. Configuracin Servicios Avanzados

En este anexo se profundiza en el cdigo que permite implementar los servicios
bsicos
166
IVR General
Como se ha explicado en el apartado correspondiente, el IVR no es ms que una
operadora digital que permite seleccionar mltiples opciones antes de ser atendida
por una persona.
Esta seccin se va a dividir en dos partes, la primera hace referencia al diagrama
de flujo explicativo del cdigo. La segunda es la explicacin del cdigo.
LLAMADA A NMERO
= 954998350
SI
ES DE DIA
NO
LOCUCIN
NOCHE
LOCUCIN DIA
MARCA
EXTENSIO
N?
NO
NO
Es de
Da?
BUZN DE VOZ
N EXTERNO , DDI's
SI
SI
OPERADORA
NO
LIBRE?
SI
es de
Dia?
SI
ESTA
LIBRE?
NO
BUZN DE
VOZ
CONSTESTA
Locucin Cola y
Msica
SI
NO
MENSAJE Y
TRANFERENCIA A LA
OPERADORA
CONTESTA?
SI
FIN
Figura 55. Diagrama de Flujo IVR
Descripcin del cdigo del fichero extensions.conf

Para la comprensin del cdigo, basta con mirar el diagrama de flujo de arriba,
puesto que recoge todas las posibilidades de actuacin.
Para la explicacin del cdigo se va a seguir el diagrama.
[ivr]
167
exten => 7178350,1,Answer()

exten => 7178350,n,GoToIfTime(08:00-18:30,mon-fri,*,*?noche:dia)
; Es de dia, apartado a
exten => 7178350,n(dia),PlayBack(thank-you-for-calling&if-u-know-extdial,es)
exten => 7178350,n,WaitExten(10)
exten => 7178350,n,Queue(cola_operadora,tw)
exten => 7178350,n,hangup()
; Es de noche, apartado b
exten => 7178350,n(noche),Playback(our-business-hours-are&vm-from&ifu-know-ext-dial,es)
exten => 7178350,n,Voicemail(3001@default,u)
; si marca la extensin, apartado c

exten => _3XXX,1,Dial(SIP/${EXTEN},10)
exten => _3XXX,n(numdirecto),GoToIfTime(08:00-18:30,monfri,*,*?noche2:dia2)
; ... y es de dia ,apartado d
exten => _3XXX,n(dia2),Playback(were-sorry&nbdy-avail-to-takecall&pls-stay-on-line,es)
exten => _3XXX,n,Queue(cola_operadora,tw)
exten => _3XXX,n,Hangup()
; ... y es de noche, apartado f
exten => _3XXX,n(noche2),Voicemail(${EXTEN}@default,u)
exten => _3XXX,n,Hangup()
Inicialmente, cuando un usuario externo realiza una llamada (en este cdigo se ha
supuesto que desde la red mvil) lo primero que se comprueba si es o no horario
de oficina, puesto que el camino a seguir ser distinto, saltando a las prioridades
etiquetadas como noche o da dependiendo de ello.
Si es de da (apartado a), en primer lugar sonar una locucin que agradece al
usuario la llamada y le indica que si conoce la extensin a la que desea llamar la
marque. Esta locucin est en castellano, lo cual se indica con la opcin es de
Playback .
Asterisk esperar que se introduzca la extensin durante 10 segundos
aproximadamente. Si durante este tiempo se introduce, se ejecutar directamente
el patrn al que llame, en caso de que sea un 3XXX ejecutar un Dial
(SIP/${EXTEN}), como se ve en el apartado c. Si el nmero llamado no contesta,
pueden ocurrir dos cosas dependiendo de la hora a la que se produzca la llamada
(de ello se encarga la funcin GotoIfTime):
1. Es de da (apartado d), se pasar a la operadora que la atender
directamente, se pone en cola de operadora. El hecho de que vuelva a la
operadora es para preguntar al usuario qu desea hacer entonces. Es una
forma de garantizar un trato ms personal.
2. Es de noche (apartado f), te permite dejarle un mensaje en el buzn de voz
individual de la extensin llamada.
Una de las aplicaciones que hay que tener en cuenta en este cdigo es Queue().Es
la aplicacin que permite crear y gestionar colas de espera en Asterisk.
168
Normalmente este tipo de configuracin se usa en un para el IVR y permite enrutar

las llamadas entrantes a los agentes que se encargarn de atenderlas. El manejo
de estas colas se realiza haciendo uso de dos archivos:
1. agents.conf
2. queues.conf
Las modificaciones realizadas a la configuracin de dichos ficheros se explicarn

posteriormente.
Los parmetros que se le pasan a la aplicacin Queque para la gestin de la cola de
la operadora son:
1. El nombre de la cola. Se encuentra definido en queque.conf
2. Opciones t: permite al usuario llamado transferir la llamada.
3. Opcin w: permitir al usuario llamado escribir la conversacin en el disco a
travs del monitor.
La transferencia de llamadas contestadas fuera de la cola se habilita mediante la
opcin t arriba indicada.
Volviendo al cdigo, solo falta por analizar qu pasar cuando se realiza una
llamada por la noche.
La locucin que se escuchar ser la misma que solicita introducir el nmero de la
extensin llamada si se conoce. Si es as, nos comunicar directamente con esa
extensin (siguiendo el patrn correspondiente), pero teniendo en cuenta que es de
noche, no habr nadie para contestarla, por lo que se podr dejar un mensaje de
voz en el buzn de la extensin correspondiente.
Si no se conoce la extensin, no se introduce en el margen de 10 segundos que da
Asterisk e igualmente se podr dejar un mensaje de voz, pero esta vez en un buzn
concreto (en este cdigo correspondiente a la extensin 3001 usada para pruebas).
Descripcin del cdigo del fichero agents.conf

En este fichero configuramos, definiendo algunas variables y parmetros, los
agentes que luego atendern las colas. Un agente es la persona que contesta
registra en lo que indica que s / que ya est listo para recibir llamadas. Asterisk
transferencias de una llamada entrante a una cola, que luego es transferido a su
vez a un agente disponible.
En este cdigo, solo habr una cola y los ficheros sern muy sencillos, por lo que
solo har falta definir un agente, en este caso, un usuario SIP/3001 (en este caso
de prueba).
[general]
persistentagents=yes
[agents]
agent => 3001,1234,Operadora
Esta es la nica parte del cdigo que resultar de inters.
Se definen dos contextos principales: uno general y otro agents.
1. Contexto general, donde se especifica nicamente le parmetro
persistentagents=yes. Este campo define si el callbacklogin tiene que ser
almacenado en la base de datos interna de Asterisk. Si tiene asignado el
169
valor yes cuando se vuelva a

arrancar Asterisk estos datos sern
recargados.
2. Contexto agents. Aqu se especificar los agentes que atienden la cola, en
este caso solo existe un agente que asociado con la extensin 3001. Los
siguientes valores que siguen son la contrasea (1234) y el nombre del
agente en cuestin (Operadora).
Descripcin del cdigo del fichero queque.conf

En el queues.conf se configuran las colas (pueden ser una o ms), cuales agentes
y/o grupos son miembros de una determinada cola y que tipo de estrategia se
utiliza para enrutar las llamadas a los distintos agentes.
[general]
persistentmembers = yes
[cola_operadora]
timeout=10
retry=20
periodic-announce-frequency = 10
queue-thankyou = queue-thankyou
periodic-announce =queue-thankyou
member => Agent/3001
En este fichero, tambin aparecen dos contextos, en este caso uno general y otro
que define las caractersticas de la cola.
1. Contexto general, se detalla el mismo parmetro que en fichero anterior si
usamos agentes dinmicos su configuracin se guardar en la base de datos de
Asterisk. De esta forma si Asterisk se vuelve a arrancar, cada agente ser
enrutado a su correspondiente cola.
2. Contexto cola_operadora. En este contexto se recogen las caractersticas de la
cola que se ir formando. Estos parmetros son:
Timeout: tiempo, en segundos, pasado el cual la llamada se considerar no
contestada por el agente, en este caso diez segundos.
Retry: tiempo, en segundos, antes de volver a llamar todos los agentes
Periodic-announce-frequency: este parmetro representa cada cuantos
segundos se le presentar un anuncio a un usuarios de la cola (por ejemplo
relacionado con algn producto de la empresa).
Periodic-announce: Es el anuncio que se har cada periodic-announcefrequency.
Member: Los miembros son los canales que estn activos responder a la
cola. Puede ser agentes o los canales normales, como en este caso SIP/3001.
Una vez definidos todos estos archivos, se puede trabajar con colas.
IVR presidente
El IVR del presidente, no es ms que una particularizacin simplificada del IVR
general, sin embargo, se refleja aqu para solventar posibles dudas respecto al
170
funcionamiento (estas dudas sern aclaradas con la simple visualizacin del

diagrama de flujo).
Figura 56. Diagrama Flujo IVR del presidente

Descripcin del cdigo del fichero extensions.conf
En este caso el fichero es muy sencillo. No se har uso de otros ficheros puesto que
no se requiere utilizar colas y por tanto los archivos complementarios que su uso
requiere.
exten => 954598391,1,GoToIfTime(08:00-18:30,mon-fri,*,*?noche:comun)
; es de noche
exten => 954598391,n(noche),Playback(our-business-hours-are&vmfrom,es)
exten => 954598391,n(comun),Dial(SIP/3${EXTEN:6},10)
exten => 954598391,n,Voicemail(3${EXTEN:6}@default,u)
Una vez se llama al telfono directo del presidente (nmero 954598391) la funcin
GotoIfTime decidir en funcin de la hora a la que se realice la llamada a que
prioridad se debe saltar.
La nica diferencia entre las prioridades etiquetadas como noche y comn es que
si es de noche se escuchar una locucin que indica que se est realizando una
llamada fuera del horario de oficina. La nica finalidad de esto es indicarle al
llamante que es posible (de hecho lo ms probable) que nadie conteste a su
llamada. De todas formas, se comunica con la extensin correspondiente.
Aqu reside la nica complejidad de estas lneas de cdigo. El nmero directo al
que se llam se transforma en un nmero que responda al patrn de una extensin
SIP. Para ello se eliminan los seis primero dgitos 954598391 (marcados en negrita
171
para este caso), y se aade el dgito 3 como corresponde a las extensiones de

telfonos VoIP. Se debe recordar que el mtodo usado para realizar la migracin de
nmero de extensiones analgicas a extensiones SIP es sustituyendo el nmero
inicial 7 u 8 por el 3 o 4.
Si la llamada no es contestada, se ofrece la posibilidad al usuario llamante de dejar
un mensaje de voz en el buzn de la extensin.
172
3.5. FASE 3: INTERCONEXIN CON LOS ENLACES

PRIMARIOS
Introduccin
Para la interconexin con la red telefnica conmutada, ya sea fija o mvil, son
necesarios enlaces primarios que poseen la capacidad suficiente para gestionar un
gran nmero de llamadas. Por lo tanto, ser necesario instalar tarjetas que
contengan los puertos necesarios para dicha conexin. Normalmente Asterisk va de
la mano de Digium, y son estas tarjetas las usadas en todos los escenarios donde
se emplea como solucin Asterisk.
Para esta fase del proyecto se ha usado una tarjeta TE220 PCI Express con
cancelador de eco hardware de dos puertos como la que se muestra en la Figura
57.
Figura 57. Tarjeta TE220 PCI Express

La tarjeta Digium TE220 PCI Express proporciona hasta 60 canales de voz o datos a
travs de dos interfaces E1, T1 o J1 en un formato PCIe24 x1. Estos interfaces se
pueden seleccionar mediante una columna de jumpers que aparecen en la tarjeta y
puede hacerse a nivel de puerto o para cada tarjeta. Esta tarjeta soporta PCIe x1, y
puede ser utilizado en cualquier ranura 1.0 disponible compatible con - x1, x4, x8
y x16 sin consideracin del voltaje o tamao de pista. Para ms informacin, tanto
el datasheet de la tarjeta como el del cancelador de eco aparecen a continuacin.
La TE220 puede ser combinada con el mdulo Digium VPMOCT064 Octasic basado
en DSP de cancelacin de eco. El VPMOCT064 proporciona el algoritmo G.168 que
se ha marcado un punto de referencia para la cancelacin de eco y realiza 128ms
(1024 taps) de cancelacin de eco en todos los 60 canales del modo E1 o los 48
canales en T1/J1 modos. Incluido con la VPMOCT064.
Configuracin de la Tarjeta
Para la configuracin de la tarjeta se hace uso de otro de los ficheros de Asterisk. El
fichero chan_dahdi.conf. Este fichero se encuentra en /etc/asterisk y en l se
24
PCI consiste en un bus de ordenador estndar para conectar dispositivos perifricos directamente a
su placa base. PCI Express es un nuevo desarrollo del bus PCI que usa los conceptos de programacin y
los estndares de comunicacin existentes, pero se basa en un sistema de comunicacin serie mucho
ms rpido. Este bus est estructurado como enlaces punto a punto full-duplex.
173
configuran los parmetros esenciales de la tarjeta. A continuacin se detallan

algunos de los parmetros y su significado:
Switchtype: tipo de switch en la lnea PRI que se usa, los ms comunes son
euroisdn, national y qsig. En nuestro caso se selecciona Euroisdn.
Echocancel: Se usa para activar el algoritmo de cancelacin de eco mediante

software. Se activan con el parmetro 'echocancel=yes' o 'echocancel=xxx'
donde 'xxx' es el nmero de 'taps' que va a cancelar mnimo 0 mximo 256
(256 taps / 8 = 64ms (es decir, hasta un mximo de 64 milisegundos de
eco)).
Este cancelador es el bsico, sin embargo, haciendo uso del cancelador de
eco hardware de las tarjetas Digium (como es este caso) pasas a poder
cancelar desde 0 hasta 1024 taps (1024/8 = 128ms) es decir, el doble,
ahorrando adems recursos del procesador pues es a nivel hardware.
Signalling: tipo de sealizacin pri_cpe (Costumers Premisses Equipment)

para indicar que la tarjeta trabajar como esclavo y pri_net (Network) para
el maestro.
La configuracin bsica para este fichero sera:

language=es
switchtype=euroisdn
signalling=pri_cpe
context=from-pstn
group=1
channel=>1-15,17-31
group=2
channel=>32-46,48-62
Donde el context hace referencia al contexto donde se recogen los primarios.
Adems del fichero chan_dahdi, ser necesario modificar el fichero system.conf que
se encuentra en el directorio /etc/dahdi.
Ser necesario aadir la lnea Span, que hace referencia a un grupo de canales de
un primario. Para cada E1 ser necesario definir un span. La nomenclatura se
muestra a continuacin:
span=(spannum),(timing),(LBO),(framing),(coding)
donde:
spannum: es el nmero con que se identifica el span.
timing: indica de donde se toma la fuente de reloj. Puede tomar los valores
0 (no se usa este span como fuente de reloj), 1 (se usa este span como
fuente primaria de reloj), 2 (es parecido a el cero solo que no hay
propagacin de la seal de reloj)
LBO: indica el nivel de potencia con el que se trasmite la seal (por default
se pone en 0), este valor esta funcin de la longitud del cable, colocamos:
0: 0-133 ft, 1: 133-266 ft, 2: 266-399 ft, 3: 399-533 ft y 4: 533655 ft.
framing: indica cmo comunicarse con el hardware en el otro extremo de la
lnea. Para T1 puede ser d4 o esf y para E1 puede ser cas (Channel
Associated Signalling) o ccs (Common-Channel signalling).
174
coding: indica como comunicarse con el otro extremo. Para T1 puede ser
ami o b8zs y para E1 puede ser ami (Alternate Mark Inversion) o hdb3 (High
Density Bipolar of order 3 code) a veces se puede necesitar crc4.

bchan: indica los canales que van a ser usados para datos.
dchan: indica los canales que van a ser usados para control.
Dahdi usa mdulos cancelador de eco que deben ser configurados para cada canal.
Estos canceladores son compilados e instalados como parte del paquete dahdi. Se
puede especificar el cancelar de eco usado para cada canal. Por defecto no hay
cancelador de eco en ningn canal, pero es muy importante definirlo, sobre todo si
no se dispone de un cancelador de eco hardware.
La definicin de este parmetro sera:
Echocaneller= <echocanceller name>, <channel>
Un ejemplo sencillo de la configuracin del fichero system.conf sera:
loadzone=es
defaultzone=es
# Tarjeta Digium TE200
#puerto 1: Asterisk <-> E1 fijo
span = 1,1,0,ccs,hdb3,crc4
bchan= 1-15,17-31
dchan= 16
echocanceller= mg2,1-15,17-31
A continuacin se anexa el datasheet de la tarjeta TE220 PCI Express as como la

del cancelador de Eco hardware usado en la solucin del proyecto.
DATASHEET TARJETA TE220 PCI EXPRESS Y CANCELADOR DE ECO HARDWARE
datasheet_cancelador de eco.zip
datasheet_tarjeta PCI Express.zip
Comprobaciones finales.
Una vez se han configurado los ficheros anteriores teniendo en cuenta las
caractersticas especficas del escenario de trabajo, se debe comprobar que la
sincronizacin se ha realizado correctamente con los enlaces primarios. Para ello,
se puede usar el cdigo de colores de los led de la tarjeta.
Verde: La tarjeta est perfectamente sincronizada con el extremo remoto.
Amarillo: La tarjeta est sincronizndose o est recibiendo una alarma roja
de extremo lejano.
Rojo: La tarjeta no encuentra el extremo remoto, el circuito no est arriba o
el cable est estropeado.
Tras la configuracin ambos led deben quedar en verde.

175
Figura 58.Sincronizacin perfecta de Asterisk
3.5.1. Prueba 1: Interconexin de Asterisk con el enlace

primario de mviles
Configuracin de Asterisk
En esta seccin se va a detallar la configuracin de los tres ficheros que es
necesario modificar para la realizacin de las pruebas. Como se dijo, anteriormente,
estos ficheros son: extensions.conf, chan_dahdi.conf y system.conf
Extensions.conf
En este fichero se describe el funcionamiento del plan de marcado. Asterisk puede
recibir llamadas desde tres orgenes distintos: la red pblica mvil, la centralita y la
red IP. Para diferencia el manejo de esas llamadas en funcin de su origen se han
creado tres contextos distintos: from-pstn, from-pbx y from-sip.
a) Contexto [from-pstn]
Este contexto recoge el tratamiento de las llamadas entrantes desde la red pblica
(la mvil en este caso).
[from-pstn]
exten => _717XXXX,1,Background(welcome&privacy-please-dial&digits/1)
exten => _717XXXX,n,WaitExten(3)
exten => _717XXXX,n,Dial(DAHDI/g2/${EXTEN})
; MARCA LA EXTENSION SIP
exten => 1,1,Background(ent-target-attendant)
exten => _[34]XXX,1,Dial(SIP/${EXTEN})
En ocasiones, los operadores de telefona asignan a sus clientes un cdigo de

usuario para identificarlos. Cuando una central de conmutacin que sirve a un
cliente con cdigo de identificacin detecta una llamada dirigida hacia l, sustituye
parte del nmero destino con el identificador de cliente. En concreto, en el caso de
Persan se sustituyen los cinco primeros dgitos del nmero llamado (95499) por su
prefijo de cliente (717). El resto del nmero (4 dgitos) no se modifica. Debido a
176
que persan tiene contratados un rango de nmeros directos (DDI), esos cuatro
ltimos dgitos no son fijos sino que se correspondern con los 4 ltimos dgitos del
nmero directo llamado. Por ejemplo, si alguien llama al 954998350, el nmero
enviado por la central de conmutacin ser 7178350. En cambio, si se llama al
954998448 (DDI), la central entregar el 7178448. Por este motivo, en el plan de
marcado se busca la coincidencia con el patrn _717XXXX. Esta llamada ser
tratada en primer lugar por Asterisk.
El llamante escuchar una locucin que le pregunta si el nmero al que desea
marcar es una extensin correspondiente a un telfono IP, en ese caso, se le indica
que marque el dgito 1. El llamante tiene aproximadamente unos 4 segundos para
marcar (se aade un tiempo de margen de 3 segundos mediante la orden
WaitExten), si en ese tiempo no pulsa 1, Asterisk asume que se desea establecer
una conexin con un nmero correspondiente a una extensin analgica y lo enva
por el enlace correspondiente (g2) para que sea tratada por la centralita Ericsson,
donde se activar el IVR y le solicitar de nuevo que marque la extensin si la
conoce o lo pondr en contacto con la operadora para que lo atienda
personalmente.
En caso de haber marcado el dgito 1 tras escuchar la primera locucin, es decir, si
se desea establecer una comunicacin con un telfono IP (con patrn 3-4XXX, se
solicita introduzca la extensin correspondiente y Asterisk simplemente la enva por
el canal SIP correspondiente a la extensin marcada.
b) Contexto [from-pbx]
Este contexto recoge el tratamiento de las llamadas realizadas por usuarios de
telfonos analgicos tanto a extensiones SIP como a nmeros mviles externos.
[from-pbx]
exten => _[34]XXX,n,Hangup()
exten => _X.,1,Dial(DAHDI/g1/${EXTEN})

exten => _X.,n,Hangup()
Se contemplan dos posibilidades a la hora de realizar una llamada desde un

telfono analgico:
1. Llamada a una extensin SIP: Cuando Asterisk detecta una llamada que responde
al patrn [3-4XXX] simplemente establecer un canal SIP con el nmero llamado.
2. Llamada a un nmero mvil externo: este tipo de llamadas se tratan con un
patrn muy general (_X. coincide con cualquier nmero). Cualquier llamada
procedente de la centralita que no vaya dirigida a una extensin SIP es
encaminada por el primario de mviles (g1). Asterisk encamina la de forma
transparente. La adicin de prefijos necesarios para que la llamada salga a la red
mvil (999) ser realizada por la centralita Ericsson.
Las llamadas entre telfonos analgicos no se contemplan porque no son tratadas
por Asterisk.
c) Contexto [from-sip]
Este contexto recoge el tratamiento de las llamadas realizadas por telfonos IP tanto a
extensiones analgicas como a nmero mviles de la red pblica.
177
[from-sip]
; llamadas a mviles
exten =>_06XXXXXXXX,1,Dial(DAHDI/g1/999${EXTEN:1})
exten =>_06XXXXXXXX,n,Congestion()
exten =>_06XXXXXXXX,n,Hangup()
; llamadas internas de SIP a SIP y SIP-analgicas
exten => _[78]XXX,1,Dial(DAHDI/g2/954998438)
Las posibilidades contempladas a la hora de realizar una llamada desde un telfono SIP
son:
1. Llamada a un mvil externo: Esta llamada ser tratada directamente por la
centralita Asterisk. Una vez detecte un patrn que se ajuste a dicha llamada
_06XXXXXXXX (se recuerda que es necesario marcar el 0 para realizar una
llamada externa), Asterisk se encargar de dar al nmero el formato correcto
para que pueda ser enviado a la red. Para ello, elimina el 0 y aade el prefijo
999, por lo que el nmero definitivo que saldr hacia la red mvil (por el enlace
g1) coincidir con el patrn 9996XXXXXXXX.
2. Llamadas internas entre terminales SIP: El tratamiento es el mismo que en el
escenario anterior, Asterisk establecer un canal SIP entre llamante y llamado.
3. Llamadas internas entre terminales SIP y analgicos: Cuando un usuario SIP
realice una llamada que coincida con el patrn _7-8XXX, sta se encamina por el
canal g2 hacia la centralita. El enlace primario que une la centralita con Asterisk
es el que conectaba, en el escenario original de Persan (Figura 35), la centralita
con la red fija Por lo tanto, el formato de nmero esperado por parte de la
centralita es del tipo 95499XXXX. En su configuracin se establece que a estos
nmeros se les quiten las 5 primeras cifras (95499) y se queda con las cuatro
ltimas (XXXX). En este proceso, la centralita comprueba si esas cuatro cifras
coinciden con un nmero directo (DDI). Si es as, la llamada se encamina
directamente hacia la extensin correspondiente. En caso contrario, se encamina
hacia la extensin de la operadora (8350). Por lo tanto, las nicas extensiones
analgicas que pueden comunicarse directamente con extensiones SIP (sin pasar
por la operadora) son las que tienen un nmero directo asociado. Aunque el
funcionamiento general es el expuesto, en las pruebas slo se utiliz un nmero
directo (954998438) para evitar molestias a los trabajadores.
Chan_dahdi.conf
En este fichero se almacena la configuracin de los dos enlaces primarios

conectados a Asterisk. Bsicamente se especifica el tipo de sealizacin a utilizar
(euroisdn) y el papel que desempea Asterisk en ella (si actua como usuario,
pri_cpe o como red, pri_net). Tambin se definen los contextos encargados de
manejar las llamadas (from-pstn y from-pbx) as como los canales de transporte
asociados a cada uno.
178
; ------------------------------------------------; Fichero de configuracion /etc/chan_dahdi.conf

; ------------------------------------------------[channels]
language=es
switchtype=euroisdn
.
.
.
; Conexion Asterisk<->pstn
context=from-pstn
group=1
signalling=pri_cpe
channel=>1-15,17-31
; Conexion Asterisk<->pbx
context=from-pbx
group=2
signalling=pri_net
channel=>32-46,48-62
En el enlace que une Asterisk con la red pblica (fija en este caso), ste desempea
el papel de usuario en la sealizacin. En cambio, en la conexin con la centralita
Ericsson juega el papel de red.
System.conf
Este fichero define algunos parmetros de configuracin adicionales para los

enlaces primarios. Se centra en cuestiones del plano fisco: cdigo de modulacin,
fuente de sincronismo, mecanismos de control de errores, etc.
# -----------------------------------------------# Fichero de configuracion /etc/dahdi/system.conf

# -----------------------------------------------loadzone=es
defaultzone=es
#puerto 1: Asterisk <-> E1 movil
bchan= 1-15,17-31
dchan= 16
#puerto 2: Asterisk <-> pbx
bchan= 32-46,48-62
dchan= 47
179
La diferencia de configuracin entre los dos puertos estriba en que en la conexin

con la red pblica, Asterisk se comporta como esclavo de sincronismo, mientras
que en la conexin con la centralita, acta como maestro
3.5.2. Prueba 2: Interconexin de Asterisk con el enlace

primario de fijos
En esta prueba, los ficheros chan_dahdi.conf y system.conf son los mismos que en
la anterior, por lo tanto, el nico fichero que sufre alguna modificacin es
extensions.conf.
Extensions.conf
Asterisk puede recibir llamadas desde tres orgenes distintos: la red pblica fija, la
centralita y la red IP. Para diferenciar el manejo de estas llamadas en funcin de su
origen se han creado tres contextos distintos: from-pstn, from-pbx y from-sip.
Este contexto recoge el tratamiento de las llamadas entrantes desde la red fija (en
este caso).
[from-pstn]
exten => _X.,1,Background(welcome&privacy-please-dial&digits/1)

exten => _X.,n,WaitExten(3)
exten => _X.,n,Dial(DAHDI/g2/${EXTEN})
exten => 1,1,Background(ent-target-attendant)
El cdigo de este contexto es prcticamente igual al descrito en la prueba 1. La
nica modificacin realizada concierne al tratamiento de llamadas entrantes desde
la red fija. En este caso, el patrn al que debe ajustarse el nmero de destino es
_X., que coincide con cualquier nmero marcado. Esto asegura que todas las
llamadas sean atendidas. El uso de este patrn est justificado ya que, a priori
(antes de realizar las pruebas), se desconoce el formato de nmero entregado por
la red fija.
b) Contexto [from-pbx]
Este contexto recoge el tratamiento de las llamadas realizadas por usuarios de
telfonos analgicos tanto a extensiones SIP como a nmeros fijos externos.
180
[from-pbx]
exten => _X.,1,Dial(DAHDI/g1/${EXTEN})

exten => _X.,n,Hangup()
Las llamadas realizadas por extensiones analgicas que pasan Asterisk pueden ser:
1. Llamadas a extensin SIP: si la llamada recibida por Asterisk coincide con el
patrn correspondiente a extensiones SIP (3-4XXX), se establece un canal
SIP entre Asterisk y el llamado.
2. Llamadas a nmeros fijos externos: cualquier destino que no coincida con el
patrn 3-4XXX se encamina por el de salida hacia la red fija (enlace g1).
c) Contexto [from-sip]
Este contexto recoge el tratamiento de las llamadas realizadas por telfonos IP
tanto a extensiones analgicas como a nmero fijos externos.
[from-sip]
; llamadas a cualquier destino externo
exten =>_0X.,1,Dial(DAHDI/g1/${EXTEN:1})
exten =>_0X.,n,Congestion()
exten =>_0X.,n,Hangup()
exten => _[78]XXX,1,Dial(DAHDI/g2/954998438)
Con respecto a pruebas anteriores, la nica modificacin significativa es la
generalizacin del patrn de llamadas externas. Se debe tener en cuenta, que en el
plan de marcado definitivo, este contexto ser modificado para restringir las
llamadas salientes a fijos de acuerdo con unos permisos previamente establecidos.
Chan_dahdi.conf
Para esta prueba, no se realiza ninguna modificacin del fichero respecto a la
prueba anterior.
System.conf
Para esta prueba, no se realiza ninguna modificacin del fichero respecto a la
prueba anterior.
181
3.5.3. Prueba 3: Interconexin de Asterisk con la red fija y

mvil
En el escenario final planteado para Persan, el servidor Asterisk deber asumir el
manejo de todas las llamadas.
Para la realizacin de esta prueba, ha sido necesaria la modificacin de los
archivos: extensions.conf, chan_dahdi.conf y sistem.conf.
Este contexto recoge el tratamiento de las llamadas entrantes desde la red fija y
desde la red mvil.
[from-pstn]
; DDI
exten => _954998448,1,Dial(SIP/3${EXTEN:6}
exten => _X.,1,Background(ent-target-attendant)
exten => _X.,n,WaitExten(3)
En el cdigo de este contexto se hace una diferenciacin entre los tipos de llamadas
entrantes ante las que se podra encontrar Asterisk:
1. DDIs o nmero directos: Si asterisk identifica una llamada dirigida a un
nmero directo la encamina hacia a la extensin SIP correspondiente (sin
lanzar ningn tipo de men o aviso). Una extensin SIP comparte los tres
ltimos dgitos con su DDI asociado. As, un usuario que, por ejemplo, tenga
un DDI igual a 954998448 tendr una extensin SIP terminada en 448.
Teniendo en cuenta que en el plan de marcado diseado, las extensiones
SIP comienzan por 3, la extensin completa ser 3448. Una vez obtenida la
extensin SIP, Asterisk solo tiene que establecer el canal SIP
correspondiente.
2. Otro: comprende cualquier nmero externo dirigido al nmero de atencin
de la empresa (954998350). En este caso, la poltica consiste en atender al
llamante a travs de un IVR. En concreto, se solicita marcar la extensin
deseada, si se conoce, y en caso contrario, se enva al usuario a la extensin
de la operadora.
b) Contexto [from-sip]
Recoge el tratamiento de las llamadas realizadas desde telfonos SIP
[from-sip]
; llamadas a cualquier destino externo
exten =>_06.,1,Dial(DAHDI/g2/999${EXTEN:1})
exten =>_06.,n,Congestion()
exten =>_06.,n,Hangup()
182
exten =>_0.,1,Dial(DAHDI/g1/${EXTEN:1})
exten =>_0.,n,Congestion()
exten =>_0.,n,Hangup()
En este contexto se hace un distincin de las llamadas en funcin de su destino. Si

van dirigidas hacia la red pblica mvil, el nmero que debe coincidir con el patrn
_06. (para salir al exterior siempre se marca un 0) y la llamada se encamina por el
enlace g2 (aadiendo el cdigo de red 999). Si el destino es la red fija, la llamada
se enruta por el enlace primario g1. Si se trata de una llamada interna, tan slo se
debe establecer el canal SIP que corresponda.
Chan_dahdi.conf
En esta configuracin slo se usa un contexto para manejar las llamadas
procedentes de la red pblica (from-pstn). El plan de marcado (extensions.conf) es
el encargado de diferenciar entre los dos posibles orgenes de stas (red fija y
mvil).
; ------------------------------------------------; Fichero de configuracion /etc/chan_dahdi.conf
; ------------------------------------------------[channels]
language=es
switchtype=euroisdn
signalling=pri_cpe
.
.
.
; Conexion Asterisk<->pstn
context=from-pstn
group=1
channel=>1-15,17-31
group=2
channel=>32-46,48-62
System.conf
La nica diferencia del fichero system.conf de esta prueba con respecto a las dos
anteriores, es que Asterisk se comporta como esclavo de sincronismo en los dos
puertos (marcado con un crculo rojo) y no slo en uno.
183
# -----------------------------------------------# Fichero de configuracion /etc/dahdi/system.conf

# -----------------------------------------------loadzone=es
defaultzone=es
#puerto 1: Asterisk <-> E1 fijo

bchan= 1-15,17-31
dchan= 16
#puerto 2: Asterisk <-> E1 movil
bchan= 32-46,48-62
dchan= 47
184

Asterisk Manual de Instalacion

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Asterisk Manual de Instalacion

Enviado por

Direitos autorais:

Formatos disponíveis

Anexo III.

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

3. ESCENARIO DE TRABAJO Y ANLISIS DE

A continuacin se muestra un esquema con la situacin actual en la que se

Figura 52. Escenario actual Persan

Problemtica en la Red de Telefona:

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

conectados los puntos de acceso DECT ya se encuentra saturada con lo que no es

Problemtica en la Red de Datos:

Costes de mantenimiento alto debido a la existencia de dos redes

Falta de cobertura en gran parte de la fbrica tanto en la red de datos como

Entorno de alto ruido electromagntico que perturba el funcionamiento de

Cortes eventuales en fibras del ncleo de la red provocan la prdida de

La arquitectura del sistema que se desea implementar es similar a aquella de las

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

3.2. ANLISIS DE ESCENARIOS OPUESTOS PARA PERSAN

Figura 53. Esquema Escenario 1

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

Figura 54. Esquema Escenario 2

Facilidad de mantenimiento o reparacin ante fallo:

Escenario 1: La parte de comunicacin entre los terminales que existen

Escenario 2: En este escenario, el acceso a los primarios es gestionado

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

Si ambos puertos A1 y A2 se usan de forma indistinta para llevar

Sin embargo, si las lneas se siguen tratando como hasta ahora, es

Conclusin: Ante fallo, deberan realizarse las pruebas referentes al tiempo de

Caractersticas a nivel de configuracin

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

mandar la llamada a la central Asterisk (la recibe por B2) y ella se

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

Escenario 1: Las llamadas pueden entrar a la centralita a travs de

A travs de la RTC: Cuando llega una llamada a travs de la Red

Si la llamada llega a travs de la red GSM, ser la centralita Asterisk

Escenario 2: Las llamadas pueden entrar a la centralita a travs de

A travs de la RTC: Cuando llega una llamada a travs de la Red

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

sustitucin de telfonos) y la configuracin de las conexiones con las redes RTC y

Configuracin de desvo incondicional

Para la configuracin del desvo de llamadas incondicional que ser necesario

Un contexto denominado por ejemplo [desvio_incondicional], donde

El modo de funcionamiento sera como en el siguiente ejemplo:

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

b. Un telfono 2750 llama a un 7753 que ya no existe: primero Asterisk deber

Conclusin: En cuanto al tratamiento de llamadas entrantes, en este segundo

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

Flexibilidad a la hora de aadir nuevos equipos

Si en un futuro se pretende usar solamente la centralita Asterisk, en el

Si lo que se pretende es migrar desde el escenario 2 no seran necesario

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

3.3. FASE 1: IMPLANTACION DE UN SISTEMA DE TELEFONA

Instalacin del S.O. Debian

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

Compilacin de Asterisk y mdulos adicionales

> tar xvzf <fichero>

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

Una vez descomprimidos, los mdulos deben compilarse siguiendo un orden

Compilacin de los drivers de Dahdi

# en <x> ponemos el valor que corresponda

Asterisk requiere de una fuente de sincronizacin. En ausencia de una fuente de

> modprobe ztdummy

# donde <x> es la versin 1.4 actual

# instala los ficheros de configuracin por

MIGRACIN DE UN SISTEMA DE TELEFONA EN PRODUCCIN HACIA VOIP CON ASTERISK

a esos valores se le suman los 5 dgitos 21 y # del final