Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Asterisk
Asterisk
Asterisk en GNU/Linux
Y para ello se form una alianza con un proyecto de telefona llamado Zapata iniciado
por Jim Dixon. La idea del proyecto Zapata, era la posibilidad de disear tarjetas
especficas para convertir la seal analgica que provena de la PSTN a una seal
digital, y ahorrar costes en la construccin de dispositivos de telefona y audio
avanzados (y muy costosos) gracias a la tremenda reduccin de costes que sufran
ao tras ao los procesadores. A travs de estos, cada vez ms potentes, y baratos,
se podran procesar una o varias seales de audio digital (DSP) sin gran dificultad y
poder paralelamente construir telfonos con ese coste reducido.
Hoy en da el proyecto Zapata, fue integrado totalmente en Asterisk, y Asterisk
patrocinado por una empresa que construye dispositivos de telefona digital, llamada
Digium, y se ha acomodado como una parte ms de Asterisk con un nuevo nombre:
DAHDI (son las siglas de Digium Asterisk Hardware Device Interface).
La primera version estable surgio casi 5 aos despues, Asterisk 1.0. A partir de aqui el
sistema de versiones ha evolucionado de la siguiente forma:
Asterisk 1.0 2004
Asterisk 1.2 2005
Asterisk 1.4 2006
Asterisk 1.6.0 2008
Asterisk 1.6.1 2009
Asterisk 1.6.2 2009
Asterisk 1.8 2010
Asterisk 1.10 2011 (Nuevo Nombre Asterisk 10)
Asterisk SCF
Asterisk SCF es un entorno todava en vas de desarrollo que aunque originalmente
no ha sido lanzado para reemplazar al sistema original Asterisk, ofrecer una
evolucin en mltiples trminos que supondra en un futuro su posible adaptacin por
la mayora de los usuarios del mismo.
La idea intencional esta basada, en la posibilidad de ofrecer un sistema capaz de ser
desplegado en Clusters, o mltiples sistemas con total transparencia, algo que en la
actualidad el sistema Asterisk no puede ofrecer de por si, y en caso de necesitar
algun tipo de escalado, era necesario recurrir a soluciones alternativas como los
Proxies SIP como los reconocidos Opensips o Kamailio. Segn la definicin ofrecida
por los desarrolladores, Asterisk SCF ha sido arquitectnicamente diseado para
ofrecer los mximos niveles de disponibilidad, escalabilidad, extensibilidad, tolerancia
a fallos y rendimiento .
Arquitectura de Asterisk
La arquitectura de Asterisk esta basada en un sistema modular, que depende del
ncleo principal del sistema.
Recursos
La funcin especifica de los recursos es la de integrar Asterisk con los sistemas
externos. Hablamos de bases de datos, servidores web, calendarios, etc.
Tienen la capacidad de utilizar por si mismos, Aplicaciones del sistema como veamos
antes. Pero una de las diferencias con respecto a estas, es que se cargan de manera
esttica, y pueden operar simultneamente en mltiples canales, en vez de crearse
dinmicamente para cada canal en curso.
Uno de los mas comunes, es el recurso para ofrecer servicios de Msica en Espera
(Music ion Hold), o para realizar interconexiones con bases de datos a travs de
ODBC.
El formato clsico de este tipo de mdulos es res_<nombre>.so
Funciones del Dialplan
La idea fundamental detrs de las Funciones es la capacidad de obtener o aadir,
determinada informacin especifica a cada canal. Suelen ser complementarias a las
Aplicaciones y son capaces de ofrecer mejoras para determinados aspectos del
sistema que de por si pudieran ser limitados.
Por ello la forma mas comn de ser utilizadas es a travs de la Aplicacin Set
Por ejemplo una funcin tpica es la capaz de recoger el Identificador de llamada de
un canal (CALLERID) para poder manejarlo dentro del plan de marcacin a voluntad.
Instalacin de Asterisk
La descarga se puede realizar atraves de un navegador web como tambin desde la
linea de comandos ejecutando el comando wget:
Dependencias
Las dependencias son aquellos paquetes que vamos a necesitar para instalar
Asterisk. Por supuesto, ya que vamos a instalar Asterisk desde cdigo fuente, vamos
a necesitar instalar las libreras y compiladores que utiliza Asterisk, en su modo
desarrollo (developer, devel o dev) as que vamos a proceder a la instalacin. Por lo
general, podramos poner una lista gigantesca de todos los paquetes y libreras
necesarias para la compilacin, no obstante, vamos a acelerar un poco la instalacin
de estas libreras mediante un par de comandos:
cd /usr/src/asterisk/contrib/scripts
./install_prereq install
ldconfig -v
El script install_prereq hace una comprobacin de los paquetes ya instalados en tu
sistema e instala automticamente el resto de paquetes que pueden hacer falta para
una instalacin completa. Lo bueno de esta forma de instalar dependencias, es que
nos va a permitir compilar Asterisk con prcticamente todas las opciones que
podamos necesitar, todo el soporte para poder compilar cualquier mdulo, lo malo es
que, al poder compilar cualquier mdulo, tendremos que filtrar manualmente qu
mdulos queremos cargar y cuales no.
Para compilar e instalar el driver DAHDI se deben seguir los siguientes pasos como
usuario 'root'.
cd /usr/src/
cd dahdi-linux-complete-2.10.1+2.10.1
Para compilar e instalar ASTERISK se deben seguir los siguientes pasos como
usuario 'root'.
cd /usr/src/
cd asterisk-1.8.32.3/
Ahora hay que comprobar que Asterisk qued correctamente instalado y se ingresa a
la consola de asterisk de la siguiente forma:
asterisk -vvvvc
El siguiente paso en nuestra instalacin es la deshabilitacin de Selinux que es un
mdulo de seguridad para el kernel Linux que proporciona el mecanismo para
soportar polticas de seguridad para el control de acceso, este se debe dejar en modo
disabled y se ejecuta el siguiente comando:
Directorios Usados
A continuacin los archivos y directorios mas importantes creados en el proceso de
instalacin.
/etc/asterisk En este directorio se encuentran todos los archivos necesarios para
configurar la gran cantidad de servicios que Asterisk provee. Revisaremos los mas
importantes.
asterisk.conf Configuraciones generales de la ubicacin de directorios de archivos de
configuracin, Mdulos compilados, voicemails etc. En general es buena idea no
modificar estas configuraciones, salvo casos especiales.
cdr.conf Configuraciones referentes al "Call Detail Record". Los CDR son sumamente
importantes para las compaas telefnicas. Modificar datos en este archivo puede
repercutir en la integridad de los CDR si no se esta seguro de lo que se hace. Si la
instalacin es nicamente de prueba, o los CDR no son materia importante, no hay
problema. codecs.conf A menos que utilices SPEEX, o quieras hacer cosas
especiales con la forma en la que los codecs se comportan, es mejor no modificar
este archivo.
extensions.conf Tal vez el archivo mas importante de Asterisk. En este archivo se
toman las decisiones de ruteo de las llamadas. Mas adelante veremos la sintaxis de
este archivo. features.conf Este archivo es tambin muy importante. Permite habilitar
y configurar servicios genricos de un PBX como la transferencia asistida y monitoreo
de llamadas.
iax.conf Importante archivo para el funcionamiento del canal chan_iax que le permite
a Asterisk interactuar con otros dispositivos IAX, incluyendo otros PBX Asterisk.
logger.conf Que nivel de verbosidad deben tener los mensajes de log y a donde
deben ser enviados.
manager.conf Configuracin del importante servicio AMI (Asterisk Manager Interface)
que permite conectarnos a un socket TCP y manejar el PBX. De cierta forma se
encuentra relacionado con el archivo http.conf, que provee de una interfaces para
programar aplicaciones con AJAX que se comuniquen directamente con AMI.
modules.conf Archivo sumamente importante. Determina que mdulos sern
cargados por Asterisk al iniciar. Es frecuente que cuando se instala asterisk por
primera vez, no arranque debido a que no puede cargar un mdulo para el que no
tenemos soporte. Esto se soluciona comentando la lnea del mdulo en este archivo.
sip.conf Anlogo del archivo iax.conf para el protocolo SIP
zapata.conf(dahdi.conf) Configuracin de los canales ZAP. Las configuraciones de
este archivo deben coincidir con el hardware instalado y la configuracin del
driverzaptel.
voicemail.conf Configuracin de las casillas de voz creadas para los respectivos
anexos.
meetme.conf Configuracin de las salas de conferencias.
SIP (Session Initiation Protocol)
Session Initiation Protocol (SIP o Protocolo de Inicio de Sesiones) es un protocolo
desarrollado por el IETF MMUSIC Working Group con la intencin de ser el estndar
para la iniciacin, modificacin y finalizacin de sesiones interactivas de usuario
donde intervienen elementos multimedia como el video, voz, mensajera instantnea,
juegos online y realidad virtual. En Noviembre del ao 2000, SIP fue aceptado como
el protocolo de sealizacin de 3GPP y elemento permanente de la arquitectura IMS
(IP Multimedia Subsystem). SIP es uno de los protocolos de sealizacin para voz
sobre IP, otro es H.323. Funcionamiento del protocolo El protocolo SIP permite el
establecimiento de sesiones multimedia entre dos o ms usuarios. Para hacerlo se
vale del intercambio de mensajes entre las partes que quieren comunicarse. Agentes
de Usuario Los usuarios, que pueden ser seres humanos o aplicaciones de software,
utilizan para establecer sesiones lo que el protocolo SIP denomina "Agentes de
usuario". Estos no son ms que los puntos extremos del protocolo, es decir son los
que emiten y consumen los mensajes del protocolo SIP. Un videotelfono, un telfono,
un cliente de software (softphone) y cualquier otro dispositivo similar es para el
protocolo SIP un agente de usuario. El protocolo SIP no se ocupa de la interfaz de
estos dispositivos con el usuario final, slo se interesa en los mensajes que estos
generan y cmo se comportan al recibir determinados mensajes. Los agentes de
usuario se comportan como clientes (UAC: User Agent Clients) y como servidores
(UAS: User Agent Servers). Son UAC cuando realizan una peticin y son UAS cuando
la reciben. Por esto los agentes de usuario deben implementar un UAC y un UAS.
Adems de los agentes de usuario existen otras entidades que intervienen en el
protocolo, estos son los Servidores de Registro o Registrar, los Proxy y los
Redirectores. A continuacin se describe su finalidad. Servidores de Registro o
Registrar El protocolo SIP permite establecer la ubicacin fsica de un usuario
determinado, esto es en qu punto de la red est conectado. Para ello se vale del
mecanismo de registracin. Este mecanismo funciona como sigue: Cada usuario tiene
una direccin lgica que es invariable respecto de la ubicacin fsica del usuario. Una
direccin lgica del protocolo SIP es de la forma usuario@dominio es decir tiene la
misma forma que una direccin de correo electrnico. La direccin fsica (denominada
"direccin de contacto") es dependiente del lugar en donde el usuario est conectado
(de su direccin IP). Cuando un usuario inicializa su terminal (por ejemplo conectando
su telfono o abriendo su software de telefona SIP) el agente de usuario SIP que
reside en dicho terminal enva una peticin con el mtodo REGISTER a un Servidor
de Registro (Registrar en ingls), informando a qu direccin fsica debe asociarse la
direccin lgica del usuario. El servidor de registro realiza entonces dicha asociacin
(denominada binding). Esta asociacin tiene un perodo de vigencia y si no es
renovada, caduca. Tambin puede terminarse mediante una derregistracin. La forma
en que dicha asociacin es almacenada en la red no es determinada por el protocolo
SIP, pero es vital que los elementos de la red SIP accedan a dicha informacin.
Servidores Proxy y de Redireccin Un conjunto de usuarios que pertenecen a una
compaa o proveedor de servicios de comunicaciones, conforman un dominio. Este
dominio, que se indica en una direccin SIP despus del caracter "@" es
normalmente atendido por un servidor (o ms de uno). Este servidor recibe las
peticiones hacia sus usuarios. Este servidor ser el encargado de determinar la
direccin fsica del usuario llamado y puede actuar de dos maneras: Como Proxy, o
Como Redirector (Redirect). Al actuar como Proxy el servidor determina la ubicacin
del usuario llamado y enva la peticin original a la direccin fsica del usuario
llamado. Las respuestas del agente de usuario llamado tambin son enviadas al proxy
que las remite hacia el originante. Al actuar como Redirector el servidor genera una
respuesta que indica al originante la direccin fsica del usuario que busca para que
este pueda realizar una peticin y enviarla a la direccin fsica del usuario deseado.
Un mismo servidor puede actuar como Redirector o como Proxy dependiendo de la
situacin. Un servidor que recibe las peticiones destinadas a un dominio especfico es
denominado servidor entrante (Inbound Server). Es habitual tambin, que exista un
servidor que reciba las peticiones originadas por los usuarios de un dominio hacia
otros dominios. Este recibe el nombre de Servidor Saliente (Outbound Server). Un
agente de usuario normalmente encamina todos sus pedidos hacia un servidor de su
propio dominio. Es este quien determina (por sus propios medios o valindose de
otros servidores) las ubicaciones de los usuarios que son llamados por el agente de
usuario en cuestin.
Canales SIP
Los canales SIP (Session Initiation Protocol) son los canales utilizados por los
dispositivos IP que usan este protocolo, aadir nuevos usuarios o conectar con
proveedores SIP. La configuracin para estos canales se encuentra en el el archivo
'sip.conf' ubicado en el directorio '/etc/aserisk/' el cual deber ser editado como
En general los servidores SIP escuchan en el puerto 5060 UDP. Por tanto
configuramos port=5060.
En algunos casos, por ejemplo si utilizamos SER (Sip Express Router) con Asterisk
debemos cambiar este puerto. DNS es una forma de configurar una direccin lgica
para que pueda ser resuelta. Esto permite que las llamadas sean enviadas a
diferentes lugares sin necesidad de cambiar la direccin lgica. Usando el DNS SRV
se ganan las ventajas del DNS mientras que deshabilitandolo no es posible enrutar
llamadas en base a nombre de dominios. Conviene tenerlo activado, por tanto se
pone la directiva srvlookup=yes Cada extensin est definida por un user o usuario,
un peer o proveedor o un friend o amigo y viene definida con un nombre entre
corchetes [].
El tipo (type) "user" se usa para autenticar llamadas entrantes, "peer" para llamadas
salientes y "friend" para ambas.
En nuestro caso hemos definido una extensin 4000 como "friend". Puede realizar y
recibir llamadas.
Secret es la contrasea usada para la autenticacin. En este caso ser "password".
Se puede monitorizar la latencia entre el servidor Asterisk y el telefono con
qualify=yes para determinar cuando el dispositivo puede ser alcanzado.
En este caso Asterisk considera por defecto que que un dispositivo est presente si
su latencia es menor de 2000 ms (2 segundos). Se puede cambiar este valor
poniendo el numero de milisegundos en vez de yes.
Si una extensin est detrs de un dispositivo que realiza NAT (Network Address
Translation) como un router o firewall se puede configurar nat=yes para forzar a
Asterisk a ignorar el campo informacin de contacto y usar la direccin desde la que
vienen los paquetes.
Si ponemos host=dynamic quiere decir que el telefono se podr conectar desde
cualquier direccin IP. Podemos limitar a que dicho usuario solo pueda acceder con
una IP o con un nombre de dominio.
Si ponemos host=static no hara falta que el usuario se registrar con la contrasea
proporcionada en "secret".
Tambin se ha puesto canreinvite=no. En SIP los invites se utilizan para establecer
llamadas y redirigir el audio o vdeo. Cualquier invite despus del invite inicial en la
misma conversacin se considera un reinvite.
Cuando dos usuarios han establecido la comunicacin con canreinvite= yes (por
defecto) los paquetes RTP de audio podran ser enviados extremo a extremo sin
pasar por el servidor Asterisk. Esto, normalmente, no suele ser conveniente en casos
en los que haya NAT en alguno de los clientes. (NAT=yes).
Usando canreinvite=no se fuerza a Asterisk a estar en medio no permitiendo que los
puntos finales intercambien mensajes RTP directamente. De todos modos, existen
numerosas condiciones en que Asterisk no permite el reinvite a pesar de que no
pongamos esta condicin ya que necesita controlar el flujo RTP. Por ejemplo: Si los
clientes usan codecs diferentes, si hay opciones de Music On hold o temporizadores
en la llamada, etc ...
Por ltimo context=internal indica el contexto donde est las instrucciones para dicha
extensin. Esto est relacionado con el contexto del archivo extensions.conf que
marca el plan de numeracin para ese contexto. Por tanto el contexto internal debe
existir en el fichero extensions.conf o de lo contrario deberamos crearlo. Varios
extensiones pueden tener el mismo contexto.