Asterisk Advanced. Day 3

Hoy voy a hacer una prueba, escribir un articulo durante la clase a modo “Inline”. Seguramente salga un articulo demasiado extenso pero al menos, lo máximo completo.

– Teoría de Macros en el DialPlan

En primer lugar un tema que no hemos visto hasta la fecha y es crucial para configuraciones de dialplan repetitivas, las Macros.

Dos conceptos basicos

Las macros se componen del contexto del Macro [macro-<nombredelmacro>]

Solo tienen una extension, la “s”
exten => s,1,Answer()
same => n,Hangup

Por otro lado, las Macros se ejecutan desde el Plan de Marcacion, como una aplicación cualquiera con el formato Macro(<nombredelmacro>, <argumento1>, <argumento2>, etc)

Luego dentro del contexto Macro para poder utilizar esos argumentos llamados se utilizan las variables especificas de las macros ${ARG1}, ${ARG2}, etc

Ejemplo:

[extensiones]
exten => 100,1,Macro(prueba,SIP/mitelefono, 30)

[macro-prueba]
exten => s,1,Dial(${ARG1},${ARG2})

Aparte disponemos de variables especificas de las Macro. ${MACRO_CONTEXT}, ${MACRO_EXTEN} y ${MACRO_PRIORITY}. Sirven para saber dentro de la macro, que contexto, que extensión y que prioridad llamó a la Macro.

Un ejemplo, si utilizamos un Buzon de Voz, que coincide con el numero de extension pues podriamos utilizar ${MACRO_EXTEN}:

[extensiones]
exten => 100,1,Macro(prueba,SIP/mitelefono, 30)

[macro-prueba]
exten => s,1,Dial(${ARG1},${ARG2})
exten => n,VoiceMail(${MACRO_EXTEN})

A partir de aquí ya podemos dar “rienda suelta” a la imaginacion y poder simplificar nuestro trabajo de escritura de tareas repetitivas.

– Asterisk Realtime

Ya conocemos esto de artículos anteriores, como el uso del Web-MeetMe (configuraciones de salas de conferencia directamente desde la Web, a través de bases de datos en “tiempo real” (realtime).

Pero ahora una visión un poco mas práctica de como se trabaja con Realtime, ya que realmente el Web-Meetme siguiendo los pasos venia prácticamente preparado paso por paso y no podíamos entender que estaba haciendo realmente a nivel interno.

La utilidad de Realtime sobre configuraciones en ficheros de texto, es simplemente el hecho de poder introducir modificaciones constantes de una forma ultra-rapida (mediante un interfaz web por ejemplo que acceda a la base de datos).

Un ejemplo tipico: en la web vemos el listado de usuarios, con un boton para borrarlos cuando los damos de baja, y luego un mini formulario en el que ponemos el usuario y la contraseña y damos de alta una extensión inmediatamente. No habria que estar accediendo al servidor, accediendo al fichero de texto, editándolo, guardando, recargando el modulo, etc…

En configuraciones estáticas (situaciones en las que rara vez se cambia una extension por ejemplo), es poco practico por que puede salir mas caro el collar que el perro. Pero si un dia nos da por diseñar una interfaz web sencilla, y una base de datos (fichero .sql) que precargue nuestros valores default, podriamos implementar esto en tiempo record y podríamos tenerlo siempre presente en todas nuestras instalaciones (quizá algún día lo plantee esto como un articulo, muchos temas ya tengo pendientes conforme avanzamos en el mundo de Asterisk).

Un primer inconveniente que encontramos, es que Asterisk pretende centralizar todas las conexiones a bases de datos a traves de una capa de abstraccion como ODBC, es decir que los conectores directos nativos como MySQL y PostgreSQL tienden a su desaparicion. Para los no demasiado experimentados en el mundo ODBC esto podria ser un inconveniente a corto plazo.

Si recuerdan, el Web-Meetme lo hacia todo a traves de ODBC asi que este problema lo salvan (lo que no salvan que Meetme tiende a desaparcer tambien en favor de ConfBridge (nueva aplicación para conferencias sin necesidad de timing, tambien hablaremos de ella en un futuro).

Ahora sobre la configuración los ficheros involucrados

En primer lugar /etc/asterisk/extconfig.conf necesitamos añadir una linea del tipo
<nombredelaconfiguracion> => <driver>,<nombrebasededatos>,<nombretabla>

En el caso ejemplo del Web-Meetme era:
meetme => odbc,meetme, booking

El segundo fichero es el /etc/asterisk/res_config.conf

[nombrebasededatos]
enabled => yes // Esta activada la conexion
dsn => el Data Source Name del driver ODBC
pre-connect => yes // La conexión se ejecuta al arrancar Asterisk
username => usuario de la base de datos // En caso que conectemos por Puerto a la base de Datos, como en bases remotas
password => password de la base de datos // Lo mismo que lo anterior

En el ejemplo que estamos siguiendo:

[meetme]
dsn => meetme (este es el contexto que creamos antes en el sistema)
username => asterisk (supuestamente va a ser nuestro usuario para asuntos de Asterisk y servidor de base de datos)
password => asterisk (o la que le pusiéramos)
pre-connect => yes
enabled => yes

Ahora la configuracion del driver odbc en el sistema, /etc/odbc.ini

[meetme]
Description = ODBC para MySQL // Una descripcion cualquiera
Driver = MySQL // El driver ODBC que utilizamos, en este caso para MySQL por el tema ese que va a tender a desaparecer que comentábamos antes
Server = localhost // Servidor donde esta la base de datos
Database = meetme // Nombre de la base de datos con la que trabajaremos
Port = 3306 // Puerto de la base de datos
User = asterisk // En caso que conectemos por puerto en vez de por Socket
Password = asterisk // En caso que conectemos por Socket
Socket = /var/run/mysqld/mysqld.sock // Por aquí conectamos por Socket

Y finalmente /etc/odbcinst.ini

[MySQL]
Description = MySQL ODBC MyODBC Driver
Driver = /usr/lib/odbc/libmyodbc.so // librería ODBC del Driver MySQL
Setup = /usr/lib/odbc/libodbcmyS.so // librería ODBC de Configuración MySQL

Solo quedaria configurar la tabla y base de datos y ya preparado.

Algunas consideraciones adicionales: para reducir el numero de peticiones a cache, el fichero de configuracion del modulo que estamos convirtiendo en “RealTime” introducimos la siguiente variable: rtcachefriends=yes

De aquí pueden surgir multiples ideas prácticas que me gustaria probar personalmente y dedicar un articulo especifico con mis resultados, como por ejemplo, crear una funcion en func_odbc.conf para consultar algo especifico de una base de datos externa para tratarlo a traves del DialPlan, como por ejemplo consultar el telefono de un Cliente.

– CDR y CEL

Esta parte trata sobre como se gestiona CDR (Registro de Detalles de Llamada) y la nueva implementación mas detallada del registro CEL, en el que es posible ver a nivel de flujo de llamada de DialPlan, no solo a nivel de canal. La verdad es que es meramente informativa con informacion sobre los campos que se utilizan, y algunas aplicaciones de dialplan para edicion, pero realmente merece un articulo bastante amplio para poder entrar en detalle incluso algun mecanismo para extraer informacion como vimos en el articulo de CDR-Stats, una gran aplicación para poder visualizar los datos de forma bastante generica (y recuerdo que quede en montar un software para analizar llamadas pero mas en detalle para un proposito en concreto).

– El mundo de las Tarjetas Analogicas

Ya dedique varios articulos a este tema cuando empece a trabajar con la tarjeta TDM410P como el siguiente y la segunda parte del mismo.

Algunos conceptos novedosos y no vistos hasta la fecha:

Sobre la tecnologia Analogica, existen tres posibles de sistemas de señalizacion, (en el fichero chan_dahdi.conf) ground start (en desuso), loop start (tambien en desuso) y kewl start (sistema mas utilizado en la actualidad, 99% de los casos).

Otra novedad que trae la version 1.8 es la posibilidad de crear contextos en el chan_dahdi.conf y tener por ejemplo un contexto generico [channels] donde especificar ciertos argumentos especificos de la tecnologia analogica (que eran los que soliamos definir antes del channel => cuando utilizabamos un modulo FXO

Ejemplo:

[channnels]
usecallerid = yes
transfer = yes

[telefono-analogico]
callerid = “Telefono Analogico” <1001>
context= extensiones
signaling = fxo_ks
dahdichan = <el_canal_que_definimos_en_/etc/dahdi/system.conf>

[linea-analogica]
callerid=asreceived
context = llamadas_entrantes
signaling = fks_ks
dahdichan = <el_canal_que_definimos_en_/etc/dahdi/system.conf>

Pero luego, en el Dialplan tenemos que seguir definiendo en canal a la vieja usanza (DAHDI/1, DAHDI/2, etc…)

Dato importante de las lineas extrantes analogicas, es que hay que mandarlas a un contexto en el DialPlan (por ejemplo, llamadas_entrantes) y dentro de ese contexto, poner la extension “s” (start) ya que es imposible reconocer hacia donde pretende ir esa llamada por las limitaciones de la “analogia”.

Mañana parece que seguiremos con el tema de las conexiones de Tarjeteria, pero esta vez con una nueva que no hemos visto hasta la fecha, una tarjeta de Primarios.

Espero vuestros comentarios sobre como quedo esta “modalidad” de blogging inline. Para mi particularmente resulto mas comoda porque en los huecos libres podia ir escribiendo, y no tener que hacer todo el texto ya a deshoras y ademas tambien ha servido un poco con “apuntes personales” de lo visto para revisiones futuras (como realmente es el blog entero para mi personalmente).

Conquistando el Dialplan II: Configuración DID para Operadores IP

Para todos aquellos que utilizamos operadores SIP tenemos la gran posibilidad de adquirir múltiples canales entrantes a muy bajo coste. A día de hoy la verdad que las llamadas salientes salen realmente caras, sobre todo si nos vemos en entornos empresariales. Ya hace tiempo os comente múltiples alternativas que había barajado en su día, con operadores como Netelip, Voztelecom, Telsome. A día de hoy, 2 céntimos el minuto para llamadas nacionales: Es muy caro. Tenemos alternativas internacionales como CheapVoip, pero aquí entra en juego el tema de las latencias. Además estas no nos ofrecen líneas de entrada y/o DID por tanto no podemos adquirir un sistema integral de llamadas tanto de entrada como de salida.

Aquellas empresas que si ofrecen canales de entrada, “se aprovechan” a un alto coste para la salida. Podemos combinar ambas soluciones, y de hecho, debemos, pero ya en estos casos las líneas de entrada empiezan a compensar cada vez menos.

Aun así, para configuraciones de pocas líneas de entrada (menos de 10) y relativamente pocos DID, (menos de 50), siguen siendo soluciones factibles. Por ejemplo una de las soluciones más óptimas en el mercado español, VozTelecom, con líneas de calidad muy muy alta a nivel de latencia, jitter, etc., ofrece por 8 euros, 2 canales de entrada, y 1 DID, 4 euros el DID adicional geográfico. Encima, los temas técnicos los libramos, y no tenemos que contratar mantenimientos adicionales para preservar la calidad del servicio

Si optamos la opción de Telefónica, tenemos una línea RDSI por 29 euros al mes, más el mantenimiento, habría que sumarle, mínimo, 4 euros para preservar una calidad aceptable de respuesta. Esto hace 33 euros. Luego los DID son relativamente baratos, en torno a los 2 euros.

Si no queremos optar por la opción del primario, 4 RDSI haciendo un grupo ISPBX (para saltos automáticos y demás), sumaria un total de 132 euros. En caso de VozTelecom hablaríamos de 32 euros. Luego si queremos 30 DID, serian 60 euros más para Telefónica 192 euros, y 120 euros para Voz Telecom: 152 euros. Solo 45 euros, estamos en el umbral. Aunque obviamente la solución con líneas RDSI es muy superior a la solución VOIP, porque además que podríamos “aislar” el sistema PBX a un nivel puramente local, si requerir de Internet, la calidad siempre suele ser superior a nivel de voz. Solo con un Gateway Epygi como el que vimos antes, tendríamos resuelta la papeleta.

Vamos a poner el caso concreto, de que elijamos la solución VoIP. Ahí vamos con la configuración:

En caso del Epygi, realmente no necesitamos un comando “register” en el fichero sip.conf para registrarnos contra el troncal. Pero en caso del operador SIP, si haría falta, como vimos con anterioridad. Esto nos “obliga” a ir hacia la extensión del Dialplan dentro del contexto que seleccionemos específicamente.

Y desde esa extensión, tendremos que realizar la configuración para seleccionar el DID que “recibamos” según los mensajes SIP que se intercambian durante la comunicación. Esto ocurre con la mayoría de los operadores IP, aunque algunos ejercen de troncal de forma equivalente al Epygi, que no necesitaremos realizar selección alguna:

En el extensions.conf imaginando que si pusimos contexto destino, en la configuración del operador SIP, pero no pusimos extensión destino en el comando Register (último parámetro /ddi como vimos antes):

exten => s,1,NoOp()
exten => s,n,Set(cNum=${SIP_HEADER(TO):5:9})
exten => s,n,GotoIf($[“${cNum}” = “987654321”]?1,1)
exten => s,n,GotoIf($[“${cNum}” = “912345678”]?2,1)
exten => s,n,GotoIf($[“${cNum}” = “988776655”]?3,1)
exten => s,n,Hangup()

Con la variable general SIP_HEADER, seleccionamos la cabecera del mensaje SIP, y nos vamos a la posición 5 longitud 9 (el número de teléfono) para guardarlo en una variable local que le llamamos cNum. Aquí en 99% de los casos se encuentra el DID. De todas formas haciendo debug en la consola (# asterisk –r) podemos ver exactamente qué valor está recibiendo esta variable, cNum

Esta sintaxis es nueva para nosotros. La aplicación GotoIf es condicional. Con el formato GotoIf($[condición], se cumple, no se cumple), En este caso concreto, si se cumple, saltamos al contexto 1, 2 o 3 según lo que se cumpla, y si no se cumple, pasamos a la siguiente prioridad.

La consulta de variables en Asterisk tiene el formato ${variable} en cambio la “escritura” de las mismas con la aplicación Set, se realiza sin nada, variable=. Esto es un poco técnico, aun con ciertos conocimientos de programación, esto se aprende en cuestión de segundos.

Así en vez de ir discriminando con extensiones con el número DID como hacíamos con el Epygi, lo haremos con este sistema por condicionales. Lo que no tengo muy claro todavía es porque algunos operadores mandan bien (y sin entender a qué me refiero con “mandar bien” el DID para asignarlo directamente como extensión), y para otros, hay que hacer operaciones como estas para salir al paso. Si lo averiguo, actualizare este mensaje.

Para finalizar con todo esto, voy a aprovechar, para hacer un apunte fuera del contexto. El tema es que Asterisk, por ventaja, o desgracia, favorece mucho a los informáticos, y acerca un mundo anteriormente exclusivo a ciertos técnicos especializados, o especialistas de las telecomunicaciones, al mundo de los informáticos. Por esto si realmente no tenemos nociones extensivas tanto de Linux como de programación, nos vamos a ver con un sistema bastante simple, (aun aceptable comparativamente con otras soluciones PBX), pero no vamos a poder sacar toda la potencia de su interior al máximo. No voy a pararme demasiado en temas de programación, variables, condicionales, bucles, aunque si explicando el formato, porque doy por supuesto que más o menos entendemos de que estoy hablando, y más considerando que desde hoy, la curva de aprendizaje va mejorando para el público entendido en esta materia, pero va a empeorar drásticamente para los que carezcan de estos conocimientos.

Conquistando el Dialplan I. Aplicaciones Asterisk: Voicemail

Como ya sabemos, el Dialplan, plan de marcación, es el esqueleto en esencia de Asterisk. A partir de este se abre el sin fin de posibilidades que nos ofrece este sistema.

Solo el que conoce lo que ofrece el Dialplan al 100%, es aquel que realmente conoce Asterisk de verdad. Por ello, las series de documentación sobre Dialplan serán mensajes mas cortitos pero no por ello menos interesantes  y que ayudaran a organizar mejor la información.

Realmente ya vimos parte del potencial del Dialplan, con la creación de una operadora automática de coste cero, ahora vamos a ver las funciones de Buzón de Voz para nuestras extensiones. Aquí básicamente hay dos actores principales. La Aplicación Voicemail, y el fichero voicemail.conf

El fichero voicemail.conf puede llegar a ser todo lo complejo que deseemos en función de nuestras necesidades, pero voy a comentar un caso práctico en el que podemos ver diversa funcionalidad que podemos llegar alcanzar. Como la mayoría de los ficheros de Asterisk, se divide en contextos, como casi siempre, general, suele ser el genérico que afecta a todos los contextos por igual.

[general]
format=wav
//Formato de las grabaciones para el buzon de voz. Se admiten otros formatos como gsm.
serveremail=direccion@queenvia.com
//Direccion del remitente de los envios
attach=yes
// Para enviar el fichero adjunto en los emails con el audio
delete=yes
// Para permitir la opción de borrado del mensaje de voz local en el servidor una vez enviado por correo eletronico
maxmsg=100
// Maximo numero de mensajes permitidos en la bandeja local por buzon
maxsecs=180
// Maximos segundos por mensaje
minsecs=2
// Minimos segundos por mensaje para desechar los mensajes vacios o casi vacios
skipms=3000
// Opciones del mensaje de audio, para indexarlo cara a desplazamientos X ms adelante o detrás cuando sea reproducido en el pc del destinatario
maxsilence=10

// Silencio máximo permitido, esto es importante cara a poder desconectar la llamada en caso de silencio antes de cumplir el máximo posible caso 180 segundos (en nuestro ejemplo)
silencethreshold=128
// Este es el umbral de audio para el que consideramos que es un silencio, de aquí podemos ir mas abajo o mas arriba en función de nuestra necesidad, no hay un valor “ideal”
maxlogins=3
// Intentos de acceso a voicemail, en caso de sobrepasarlos, Asterisk desconectara al usuario de su cuenta SIP/IAX
emailsubject=Nuevo Mensaje de ${VM_CALLERID}
emailbody=Buenos días ${VM_NAME},\n\nHemos recibido un mensaje en su buzon de voz…
// Esto seria el asunto y el cuerpo del mensaje email. Aquí se pueden aprovechar variables para poder formatear el correo y mostrar datos quizá interesantes para el destinatario. Algunas de estas variables de ejemplo:
${VM_CALLERID}: El numero identificador del llamante (el número de teléfono)
${VM_NAME}: El nombre del dueño del buzon (lo definiremos más adelante)
${VM_DUR}: Duracion del mensaje
${VM_DATE}: Fecha y hora de recogida del mensaje
Mas variables pueden encontrarse aquí: en su correspondiente sección (tampoco son muchas más)
emaildateformat=%A, %B %d, %Y at %r
// Formato de la fecha para el email. Para la variable VM_DATE. Consultar el manual de date para mas información (# man date)

Con esto tenemos más que suficiente para componer mensajes para el buzon de voz y enviarlos por email. Ahora vienen los contextos. Como siempre, si es [default] es el genérico, y luego los contextos específicos. En principio vamos a poner uno genérico y uno especifico.
[default]
1234 => 5678,Buzon de Ejemplo,ejemplo@buzones.com
– En primer lugar, el número del buzón, luego lo utilizaremos en el Dialplan para la aplicación Voicemail así referirnos a este buzón
– En segundo lugar, la contraseña para acceder al buzón. Tendremos que crear una “extensión” en el Dialplan para que el usuario pueda acceder a su buzón de forma interna. Esto solo es útil si no marcamos la opción de borrado de mensajes del buzón al ser enviados por email
– En tercer lugar, nombre del buzón que luego utilizaremos en variables como VM_NAME
– En cuarto lugar, Email del destinatario de los mensajes de este buzón

Este es un ejemplo muy sencillo, pero a esto podríamos aplicarle un poco mas de complejidad al asunto

[extensiones]
1000 => 9878,Mr. Lenny, lenny@debian.net,,attach=yes|delete=1
– En quinto lugar, iria la dirección del Pager… muy poco utilizado a dia de hoy
– En último lugar, irían opciones especiales. En este caso, decimos que adjunto el mensaje, y lo borre a continuación. Si hemos activado las opciones en el contexto general, ira bien esto.

Si queremos hacer “broadcasting” de mensajes de buzon a varios emails, hay varios métodos pero el que a mi mejor me ha funcionado es hacerlo en combinación a aliases del servidor de correo (en nuestro caso al usar Ubuntu, por defecto, Postfix)

1001 => 8765, Dpto. de Botijos, botijos@nuestroservidor,,attach=yes|delete=1

Nos vamos a /etc/aliases y añadimos
botijos: sr.sanchez@botijoland.com,sr.perez@botijoland.com,sr.alvarez@botijoland.com

Y refrescamos aliases comando: # newaliases

Por ultimo no olvidemos recargar nuestro voicemail.conf #asterisk –rx ‘voicemail reload’

Ahora toca editar nuestro Dialplan para poder utilizar estos buzones recién configurados. Vamos al extensions.conf:

Si queremos por ejemplo hacer que los usuarios puedan dejar mensajes a nuestro contestador tenemos que utilizar la aplicación Voicemail
Ejemplo:

exten => 1000,1,NoOp()
exten => 1000,n,Dial(SIP/1000,30)
exten => 1000,n,Voicemail(1000@extensiones,u)
// En este caso, ponemos el número del buzón que pusimos antes @ el contexto al que pertenecía, adicionalmente ponemos una opción, para que antes de dar el pitido de “empezar a grabar” diga el mensaje de “en estos momentos no nos encontramos, deje su mensaje después de oír la señal”. Aquí tenemos varias, opciones, en vez de utilizar los mensajes por defecto que se pueden encontrar en la carpeta de sonidos /var/lib/asterisk/sounds/ todos los que empiezan por vm- tienen algo que ver con el buzón de voz y estas opciones. Las opciones posibles son:
sin opciones: se escuchan las instrucciones para dejar el mensaje
s: no se escucha nada (útil si queremos poner mensajes personalizados para cada usuario)
su: mensaje de no disponible
u: mensaje de no disponible + instrucciones
sb: mensaje de ocupado
b: mensaje de ocupado + instrucciones

Con esto también podemos jugar con las aplicaciones Playback y Record, para con la opción “s” crear un buzón acorde a las necesidades de un usuario en concreto

Por otro lado vendría la aplicación destinada a escuchar los mensajes guardados si no pusimos la opción de borrado automático: VoicemailMain. Tiene poca historia:
exten => 10001,1,VoicemailMain(1000@extensiones)
El tema es que a partir de ahí vendría un menú relativamente complejo, editable, y demás. Yo personalmente no lo utilizo ya que la función de envío a correo aparte de que me descarga el disco duro, hoy en día a la mayoría del personal le resulta formidable. Aun así, para aquellos que deseen profundizar, les dejo un enlace al manual por si acaso quieren probarlo. Cualquier consulta acerca de esto, no duden en comentármela!

En principio, con todo esto, ya se podrían componer sistemas de Buzón de voz bastante interesantes. Como ven no es demasiado complejo y existen muchas alternativas y opciones. Yo personalmente opino que las opciones de envío a correo, todavía están muy poco elaboradas, pese a que se ha profundizado en ellas. Yo personalmente no he encontrado opciones por ejemplo, de envío CC o CCO (BCC) para envíos broadcasting (lo cual me resultaría muy interesante). Supongo que sería una cuestión de apoyar programando, al proyecto Asterisk. Quien sabe, a lo mejor más adelante nos animamos a ello.

Preparando nuestro sistema de FAX en Asterisk: Hylafax + IAXModem

Hoy voy a tratar de explicar cómo crear un sistema de faxing a través de nuestro Gateway (o tarjeta) para poder recibir faxes a email, y poder enviar faxes con un software desde nuestros PCs. He observado múltiples manuales en la web, pero la verdad es que si no tienes “suerte” encontraras miles de problemas, especialmente en las últimas versiones de Ubuntu Server. Y la verdad es que cuantos más problemas mejor, así aprendemos más sobre el asunto que nos concierne.

En primer lugar toca configurar nuestro IAX.conf para añadir una extensión para el FAX

[iaxmodem]
type=friend
username=iaxmodem
//secret=contraseña_de_la_extension
secret=fax
qualify=yes
notransfer=yes
disallow=all
allow=ulaw
host=dynamic
context=extensions
callerid=”FAX” <100>
requirecalltoken=no
// esta línea ultima es muy importante rebaja la seguridad de IAX para esta extensión, pero sino lo ponemos no funcionara IAXmodem en concreto

Acto seguido vamos a configurar nuestro Dialplan para a través de un número DID que tenemos disponible o línea analógica conectada (como hemos visto en anteriores mensajes, configuraciones relacionadas al Gateway RDSI, o relacionadas al módulo DAHDI desde chan_dahdi.conf), indiquemos a que extensión se deben enviar los FAXes (en este caso IAX2/iaxmodem) que es nuestra extensión IAX para el FAX. Esto se añadiría en el contexto que se envían las llamadas de nuestra PSTN (en nuestro caso desde-isdn)

exten => 123123123,1,NoOp()
exten => 123123123,n,Answer()
exten => 123123123,n,Wait(3)
exten => 123123123,n,Dial(IAX2/iaxmodem)

Quiero recordar que cuando hagamos modificaciones en los ficheros es necesario “Recargar” nuestro asterisk para que tome los cambios. No estoy seguro en este punto, si ni siquiera lo comente alguna vez!

# asterisk –x dialplan reload
# asterisk –x iax2 reload

(Recargamos el extensions .conf modificado y el iax.conf modificado)

Ahora toca configurar un modem capaz de reconocer los “tonos” de los faxes, a través de nuestra extensión IAX recién creada. Todo a través de software. La aplicación en cuestión, se llama IAXmodem

Podemos descargarla desde aquí:  http://sourceforge.net/projects/iaxmodem/files/iaxmodem/

Ahora la descomprimimos:

# tar –xvf iaxmodem-versionquesea.tar.gz
# cd iaxmodem-versionquesea
Necesitamos alguna librería adicional en nuestro sistema para poder compilar:

# aptitude install libtiff-dev libtiff-tools
# ./configure
# make

Con esto creamos el binario iaxmodem. Lo copiamos en el path de ejecución de binarios, generalmente /usr/bin o /usr/local/bin o /usr/local/sbin

# cp iaxmodem /usr/local/bin

Y ahora nos toca configurar un puerto virtual para que iaxmodem sea capaz de generar la señal, tendriamos que crear el archivo /etc/iaxmodem/ttyIAX con la siguiente información:

device /dev/ttyIAX
owner asterisk:asterisk
mode 660
port 4570
refresh 300
server 127.0.0.1
peername iaxmodem
secret fax
cidname FAXIAX
cidnumber 100
codec ulaw

Es muy importante asignar un Puerto diferente al de IAX (4569) para que funcione puesto que esta extensión estará siempre en activo como veremos ahora. Sería necesario configurar un script de arranque event.d para que esto ocurra. Dentro de /etc/init/
#vim /etc/init/iaxmodem.conf

start on startup
respawn
exec /usr/local/bin/iaxmodem ttyIAX

Probamos para ver si hemos configurado bien iaxmodem:
# iaxmodem ttyIAX
Si aparece: Registration completed successfully.
Entonces hemos tenido éxito en la configuración.

Después arrancamos el “servicio” con el comando:
# start iaxmodem

ATENCION: Este sistema de scripting es el sistema por defecto de las últimas versiones de Ubuntu, concretamente es Upstart, para más información: http://upstart.ubuntu.com/getting-started.html.  Anteriormente esto se hacia dentro /etc/event.d  en versiones anteriores a la 9.10 e incluso antes esto se hacía en inittab, clásico de sistemas Debian. Parece que se mantendrá ahora así, pero como Ubuntu va cambiando constantemente, obliga a tenernos actualizados constantemente, y por tanto esto está sujeto a modificaciones.  Si no os arranca automáticamente, investigad un poquito, o mandadme un comentario a ver si os pudiera ayudar y/o actualizar este mensaje.

Ahora viene la instalación de Hylafax para manejar los FAXes que entren por este modem.

Primero descargamos las fuentes:
# wget ftp://ftp.hylafax.org/source/hylafax-6.0.5.tar.gz
# tar –xvf hylafax-versionquesea.tar.gz
# cd hylafax-versionquesea

Y compilamos como casi siempre

# ./configure
Aquí nos muestra  los directorios donde se encuentran aplicaciones básicas, decimos que si a todo si estamos conformes (que creo que lo estaremos casi siempre)
# make
# make install

Ahora necesitamos que faxgetty (para recibir faxes) funcione automáticamente como hicimos antes con iaxmodem. Lo mismo, introducimos el fichero de configuración en /etc/init:

# nano /etc/init/ttyIAX.conf
start on startup
respawn
exec /usr/local/sbin/faxgetty ttyIAX

Y arrancamos con start ttyIAX igual que antes. Ahora tocaría configurar un poco el sistema de fax con faxsetup. En general todas las opciones por defecto, pero hay ciertas preguntas que debemos responder para mejorar la fiabilidad del sistema:
Serial port that modem is connected to []?
Ponemos ttyIAX que es nuestro iaxmodem

También configuramos parámetros de número de fax y demás, no es que sea crucial pero cara al envío es importante puesto que en las cabeceras de los FAX esto es lo que aparece.

Otra pregunta importante:
Rings to wait before answering [1]?
Ponemos “2” para asegurarnos que pasa un poco antes de empezar a recepcionar el FAX. No es fundamental, pero ayuda a que fallen menos Faxes por experiencia.

Seguimos adelante hasta que nos pida configurar otro modem y decimos que no para terminar: Do you want to run faxaddmodem to configure another modem [yes]?

Ahora vamos a probar que todo quedo bien configurado. Llamemos al teléfono que hemos configurado el FAX 123123123. Y si todo fue bien, oiremos los típicos pitidos de FAX.

Por defecto, todos los faxes van a parar a /var/spool/hylafax/recvq en formato TIFF.

Si queremos que el FAX recibido se envíe automáticamente, adjuntando la imagen TIFF en formato PDF, y utilizando una plantilla de envío en Español, tenemos que editar un fichero dentro de /var/spool/hylafax/etc/FaxDispatch y añadimos:

TEMPLATE=es;
FILETYPE=pdf;
NOTIFY_FAXMASTER=errors;
FROMADDR=email.que@envia.com
case “$DEVICE” in
ttyIAX)
TOADDR=email.que@recibe.com;SENDTO=email.que@recibe.com;;
esac

Si fallara por cualquier razón, estaría bien que pusiéramos un email de administrador. En /etc/aliases hay que incluir la línea
FaxMaster: nuestroemail@de.administrador

Y “refrescar” los aliases: # newaliases

Es importante respetar los ‘;’ y sin espacios donde no tiene que haberlos. Considerar que es importante definir un FROMADDR exclusivamente, cuando utilicemos un Smarthost en nuestro servidor de correo que requiera autenticación, ya que por defecto se enviara el correo con el usuario “fax”. Todos los parámetros por defecto que no incluyamos en este fichero los recogerá de /var/spool/hylafax/bin/faxrcvd

Si teníamos la ruta de uuencode en setup.cache funcionara correctamente. Básicamente las instrucciones estas pueden encontrarse aquí

Ahora viene la parte, para enviar un FAX, tenemos múltiples opciones. Vamos a considerar en principio que nos encontramos ante una red común en Windows, con máquinas Windows XP.  Existe un software que carga un puerto de impresión para poder enviar Faxes como si de una impresión se tratase por una “impresora” virtual sobre este puerto. De este tipo hay varias opciones, pero la que vamos a tratar aquí de ejemplo es Winprint Hylafax.

La página oficial de descarga es: http://winprinthylafax.sourceforge.net/

ACTUALIZACION: Ya existe version de Winprint Hylafax para Windows 7!: http://sourceforge.net/projects/wphfforwin7/files/

Y sobran las explicaciones de configuración, ya que en la propia página aparece un pequeño manual con capturas de pantalla. Pero este manual solo explica como configurar la interfaz en Windows. Por otro lado tenemos que tomar algunas consideraciones para hacerlo funcionar.

Por un lado tenemos el fichero de configuración de “hosts” permitidos, usuarios y contraseñas. Se encuentra en /var/spool/hylafax/etc/hosts.hfaxd. El formato para registrar nuevos se puede consultar en la página de manual de este fichero man hosts.hfaxd

Básicamente se trata de una expresión regular bien explicada, en la que introduciremos la red, para la cual será permitido enviar FAXes con este software. Ejemplo:

localhost
127.0.0.1
fax@10.158.[0-9]+.[0-9]+::
// Con esta línea sería equivalente a dar permiso a todos los equipos de la subred 192.168.1.0/24, además en la última pantalla de configuración, estaremos obligados a poner un usuario “fax” pero no necesariamente una contraseña.

Lo más importante es especificar en la primera línea de la pantalla de configuración, el servidor Asterisk. Aparte sería interesante especificar el modem que vamos a utilizar para enviar (en nuestro caso ttyIAX)

Tenemos otras opciones como Default Notify, que sería el correo de confirmación de entrega o error, también Address Book Format (dos ficheros o un fichero CSV para almacenar nuestra libreta de direcciones) y la ruta de nuestro ordenador donde queremos guardar la libreta (ejemplo C:\libreta), y finalmente parámetros de calidad y tipo de papel.

Con esto, al imprimir una hoja por esta impresora, nos pedirá los datos de envío y procederemos con el mismo

Por último, si queremos que las notificaciones lleguen en español necesitamos crear un fichero dentro de /var/spool/hylafax/etc/FaxNotify y añadimos:
TEMPLATE=es;
Muy parecido a lo que hicimos en el FaxDispatch

Voy a comentar un aspecto que puede ser interesante para muchos, ya que el envío de FAX y la recepción suele traer muchos quebraderos de cabeza. Las líneas RDSI, primarios, y líneas analógicas, es decir, el mundo PSTN es realmente la única vía aceptable para poder manejar la señal de FAX sin grandes complejidades. El envío a través de proveedores SIP, o a través de enlaces GSM puede dar lugar a problemas y errores que son bastante difíciles de solucionar, y yo personalmente aún no he conseguido aliviar, aunque la verdad es que resultaría bastante interesante profundizar sobre este tema.

Concretamente si leísteis mensajes anteriores, veréis como todas las salidas de mi central de pruebas son a través de enlaces GSM. Esto quiere decir, que he tenido que hacer modificaciones específicas en el Gateway Epygi, y en el Dialplan, para poder enviar Faxes específicamente, por las líneas RDSI que a priori, iban a estar exclusivamente dedicadas para la recepción de llamadas.

Para ello aquí van las dos modificaciones de ejemplo que tuve que hacer:

1.       Por un lado en el extensions.conf, cree una regla adicional sobre la que ya había, para salida al exterior:

exten => _3[9]ZXXXXXXX,1,NoOp()

exten => _3[9]ZXXXXXXX,n,Dial(SIP/${EXTEN}@my-isdn,30)

exten => _3[9]ZXXXXXXX,n,Hangup()

Con esto estoy diciendo, que para mandar un fax, primero hay que marcar el número 3. Así le mandaremos al Epygi un número del tipo “3987654321”

2.       Ahora en el Epygi, como vimos, en Call Routing -> Call Routing Table vamos a crear una ruta equivalente a las otras dos que hicimos, pero saliendo por uno de os troncales donde teníamos conectado una línea ISDN (en nuestro caso por ejemplo, el troncal 2). La única diferencia es que en la primera parte de la configuración pondríamos:
Enable Record activado
Tipo de llamada, ISDN
Pattern: 3* (para que sean todas las llamadas que empiecen por 3, es decir las que vienen para FAXes)
Number of Discarded Symbols: 1 (para que descarte el primer símbolo, el 3, a la hora de hacer la llamada a través del ISDN)

Description: isdn fax (aquí ponemos lo que queremos, yo pongo isdn 1 para saber que troncal de fax)

El resto, todo igual que los otros que ya configuramos. Incluso podríamos hacer otra línea equivalente, con razón de Failover igual, para tener la opción de ocupar múltiples troncales RDSI en caso que los otros estuvieran ocupados.

Si quisiéramos enviar un FAX de prueba utilizaríamos la herramienta sendfax con el siguiente comando:

$ sendfax -n -d 33987654321 /etc/issue.net
// Enviaríamos la información de /etc/issue.net simbólicamente

Seguramente recibamos un error con la métrica de fuentes Courier Bold. Necesitamos  instalar las fuentes ghostscript para ello podemos descargarlas y descomprimirlas en el directorio /usr/local/lib/ghostscript/fonts que es el que por defecto utiliza Hylafax para estas fuentes (sino existe podemos crearlo)
# mkdir /usr/local/lib/ghostscript/
# cd /usr/local/lib/ghostscript/
# wget http://ghostscript.googlecode.com/files/ghostscript-fonts-std-8.11.tar.gz
# tar –xvf ghostscript-fonts-std-8.11.tar.gz

¿Qué ocurriría si deseáramos auto enviarnos faxes con motivo de pruebas? Al enviar a través de la extensión iaxmodem, daría comunicando. Como es gratis tener múltiples instancias de iaxmodem (aunque no sean gratis los canales subyacentes a estas instancias, damos por supuesto que nos sobran para este supuesto), pues vamos a ello (aunque también se podría hacer que la extensión IAX fuese capaz de recibir y enviar múltiples llamadas sin dar comunicando, pero yo no lo he conseguido aun, quizá exista un parámetro para el contexto en el iax.conf que desconozco).

En primer lugar debemos crearnos otro modem IAX como vimos antes, otra extensión IAX. De momento para simplificar el iax.conf vamos a crear una máscara basándonos en el contexto [iaxmodem] que creamos antes. Cambiamos [iaxmodem] por [modem] y le añadimos (!)

[modem](!)
//con los mismos parámetros que antes, sacamos username, secret y callerid
[iaxmodem](modems)
// y aquí ponemos esos tres parámetros específicos del modem primero que creamos
[iaxmodem2](modems)
// Lo mismo que para iaxmodem pero nuevos parámetros
username=iaxmodem2
secret=fax
callerid=”Fax 2″ <101>

Luego copiamos el ttyIAX y lo modificamos el nuevo ttyIAX2
# cd /etc/iaxmodem/ttyIAX
# cp ttyIAX ttyIAX2

Ejemplo:
device /dev/ttyIAX2
owner asterisk:asterisk
mode 660
port 4571
refresh 300
server 127.0.0.1
peername iaxmodem2
secret faxiax
cidname iaxFAX 2
cidnumber 101
codec ulaw

Y lo probamos # iaxmodem ttyIAX2 y creamos el archivo para autoejecucion en /etc/init y demás:

#  cp/etc/init/iaxmodem.conf /etc/init/iaxmodem2.conf
Editamos el iaxmodem2.conf y cambiamos el final por iaxmodem ttyIAX2
# start iaxmodem2

Necesitamos configurar también Hylafax para la gestión de envío de estos faxes, para ello copiamos el archivo de configuración del otro modem. Realmente no necesitamos editar nada relacionado a faxgetty puesto que no tendríamos, al menos en este caso, recibir faxes por este canal de fax.

#cd /var/spool/hylafax/etc/
#cp config.ttyIAX config.ttyIAX2

Y finalmente # faxaddmodem ttyIAX2 y dejamos todos los parámetros por defecto tal cual se nos presentan. Para inicializarlo # faxmodem ttyIAX2. Podemos crear un script como el de faxgetty que creamos antes para la recepción de faxes equivalente. En /etc/init creamos el fichero ttyIAX2.conf con:

start on startup
respawn
exec /usr/local/sbin/faxgetty ttyIAX2

Realmente faxgetty es el único comando que funciona a modo “demonio” y sirve tanto para hacer que el modem IAX pueda tanto recibir como enviar. En este caso vamos a usar ttyIAX2 para enviar pero igualmente podría recibir.

Si pusiéramos en consola #faxmodem ttyIAX2, también resultaría para enviar, pero este comando no funciona para ser utilizando para dejarlo en background como demonio. Si alguien conoce alguna forma de conseguir este mismo efecto sin ponerlo en escucha con faxgetty actualizaría este mensaje con la novedad.

Y ahora por fin si:
$ sendfax -n -d 3987654321 -h ttyIAX2@localhost /etc/issue.net

Y finalmente recibiremos nuestro propio FAX como corresponde comprobando que todo está correcto y funcionando.

Debo decir que realmente esto se podría haber resumido bastante si hubiéramos utilizado los paquetes de los repositorios de hylafax y demás, pero la verdad es que haciéndolo a mano como comentaba al principio se ve en detalle como operada cada uno de los sistemas involucrados y si tenemos un problema, sabremos donde ir a buscar con más sencillez. Exactamente lo mismo que ocurre con el propio sistema Asterisk, cuando lo compilamos desde las fuentes al principio de todo.

Seguramente salgan 1001 problemas más que yo no haya contemplado aquí. Si tenéis alguna inconveniencia escribidla y trataremos de analizarla en el detalle para perfeccionar este mensaje al máximo.

De nuevo, agradezco vuestro interés por Asterisk y por este blog, al igual que vosotros agradeceréis el interés aquí mostrado. No nos dejes caer en la tentación y líbranos del mal. Amén.

Combate Analogico: Segundo Asalto

Han pasado ya varios meses desde aquel mensaje en el que perdia la primera batalla tratando de conectar mi tarjeta Digium TDM410P.

Pues bien, tras la tramitacion del RMA de la misma, fue aceptada, y al poco tiempo de ser enviada, recibi una de vuelta, que tristemente ha quedado en la estanteria casi todo este tiempo, hasta que recientemente, he tenido la oportunidad de trastear con ella.

Concretamente en estos ultimos dias, he vuelto a montar otra maquina sencilla de pruebas, ya que el servidor anterior ha pasado a un estado de “semi-produccion” con un total de 10 extensiones en funcionamiento, y una concurrencia de unas 3-4 llamadas en horario laboral. A esta nueva maquina le he conectado la tarjeta digium, y he procedido como vimos en anteriores mensajes a instalarle Asterisk version 1.6.2 (que a fecha es la que mayor estabilidad me reporta). Es curioso como ya paso mucho tiempo desde aquel mensaje en el que planteaba otras versiones y la velocidad a la que va creciendo esto.

Ahora empieza el segundo asalto. Lo mas importante como se vio en el primer asalto, es conectar la tarjeta en la ranura PCI y conectarle un molex de la fuente, si vamos a utilizar como es nuestro caso, un modulo FXS. Esto es asi, por el hecho de que debemos entregarle corriente al telefono analogico conectado a este modulo, si solo tuvieramos modulos FXO en esta tarjeta, no haria falta realmente este conector.

En este caso, disponemos de un modulo FXS conectado en el puerto 1 y un modulo FXO en el puerto 4. Si realizamos la instalacion correcta de dahdi-linux-complete, solo necesitariamos tener un modulo activado en el fichero de configuracion /etc/dahdi/modules para que nuestro sistema reconozca esta tarjeta de inmediato: wctdm24xxp

Por otro lado como vimos en su dia, lo necesario para configurar el fichero /etc/system.conf ya fue explicado. Solo hay que recordar el inciso que si el modulo es FXS ponemos fxoks y viceversa para el FXO, realmente indicamos lo que va a haber en el otro extremo, a mi personalmente me resulta un poco contra la logica sencilla, pero seguramente a otro nivel de logica, tiene mucho sentido, con el tiempo averiguare esto y si cabe os lo contare. Y tambien recordar que el FXS es el verde y el FXO el rojo.

Una vez hechas estas configuraciones, solo quedaria adaptar nuestro fichero chan_dahdi.conf de asterisk para poder trabajar con estos modulos (aparte de la consiguiente configuracion del Plan de Marcacion para dar un uso practico finalmente).

El fichero chan_dahdi puede ser tan sencillo o tan complejo como deseemos ya que permite una personalizacion casi milimetrica del sistema con respecto a la red telefonica.

El contexto principal en este fichero es [channels] y a partir de ahi surgen varias configuraciones basicas que voy a comentar a continuacion

[channels]
language=es
// Lenguaje que vamos a usar
usercallerid=yes
// Si queremos usar el identificativo de la llamada
cidsignalling=v23
// Señalizacion CID mas comun, tambien esta la opcion bell
cidstart=ring
// Cual es la señal de inicio de llamada. Aqui en caso de lineas RTB normales, ring es lo mas comun, pero en caso de usar enlaces GSM analogicos, seria una buena idea poner otro sistema como polarity_IN (inversion de polaridad) por el propio funcionamiento de los mismos que no viene al caso ahora, aunque yo los he probado con ring y tambien funciona aun con mas propensidad a fallos.
hidecallerid=no
// Autoexplicativo, si quieremos ocultar nuestro identificador de llamadas
callwaiting=yes
// Si podemos poner llamadas en espera, utilizamos el boton Hook Flash (comunmente visto en los telefonos analogicos con una letrita R aunque configurable en la mayoria de los casos) para saltar de una llamada en espera a otra
callwaitingcallerid=yes
// En el caso de poder tener llamadas en espera, poder ver el Identificativo de llamadas cuando vamos saltando de una a otra llamada
threewaycalling=yes
// Llamada a tres activada, hay que considerar especialmente para llamadas a traves de la PSTN, que estos valores deben estar soportados adicionalmente por la misma y la mayoria de los operadores (Telefonica) suelen cobrar por estos “servicios adicionales”.
transfer=yes
// Poder transferir llamadas, no tanto por limitaciones de nuestro Dialplan, sino por el de la PSTN como hablamos antes
canpark=yes
// Poder aparcar llamadas, lo mismo. Diferencia entre poner una llamada en espera y aparcarla, es que en el segundo caso la utilidad es por ejemplo, recuperar la llamada desde otra extension diferente
cancallfoward=yes
// Para poder “reenviar” la llamada
callreturn=yes
// Para poder volver a recibir de vuelta una llamada reenviada sin exito
echocancel=yes
// Cancelacion de eco activado
echocancelwhenbridged=no
// En caso que la llamada quede “dentro” de la red ejemplo, de una extension analogica a un equipo SIP, para que no cancele el eco en vano (ya que la llamada realmente con minimo retardo no lo requiere). Es curioso porque esta opcion viene activada “yes” por defecto, y tenemos que desactivarla en la mayor parte de las configuraciones chan_dahdi
echotraining=800
// Tiempo que tarda en ms para “aprender” como de “retardada” viene la llamada y que cancelacion de eco debe aplicar. En el algoritmo intervienen variables como el retardo medio, y el jitter que viene a ser algo asi como la desviacion estandar sobre el retardo medio.
relaxdtmf=yes
// Ya habiamos visto esto en la parte SIP… los dichosos DTMF suelen ser motivo de problemas especialmente partiendo de la base de que no sabemos que sistema lleva el llamante.
rxgain=1.0
txgain=2.0
// Ganancias en decibelios de la llamada entrante y saliente respectivamente
busydetect=yes
busypattern=200,200
// Con estas opciones, simplemente detectamos si el otro lado esta comunicando con un tono de comunicando clasico en nuestro auricular. Ademas podemos especificar la cadencia en ms de el tono de llamada a detectar. Esto es diferente en cada pais y lo suele suministrar una norma de la PSTN que puede ser consultada en las normas del proveedor principal, en caso de España, Telefonica por ejemplo
answeronpolarityswitch=yes
hanguponpolariryswitch=yes
// Esto es fundamental para como comentamos antes, la gestion de las llamadas en funcion si trabajamos directamente sobre una linea RTB, o si utilizamos un enlace GSM. En el primer caso, serian las dos opciones a no, y en el segundo caso, a si (yes)
faxdetect=incoming
// Para detectar faxes entrantes, es util, si vamos a utilizar ese canal para recibir Faxes. Tambien esta both para ambos sentidos. El hecho de detectar faxes tiene ciertas aplicaciones como IAXmodem, Hylafax como aplicaciones de recepcion de FAX para Asterisk, o envios automaticos de llamadas, y gestion de las mismas con Autodialers.
mohinterpret=default
// Musica en espera por defecto
mohsuggest=default
// Musica en espera sugerida cuando ponemos una llamada en espera para este canal.

Para todo esto que he explicado, hay miles de opciones y configuraciones posibles. Aqui he puesto una configuracion valida de ejemplo para funcionar desde 0. Se pueden consultar las opciones directamente en las explicaciones mismas que trae el fichero de ejemplo proporcionado por el propio sistema generado por la opcion del make de Asterisk “samples”.

Finalmente, metemos la configuracion especifica de los canales para luego ser tratada desde nuestro Dialplan. En mi caso, he conectado un telefono Dect en el canal 1 (FXS), y un Enlace GSM en el canal 4 (por eso he puesto las opciones anteriores basadas en este caso en concreto). Asi quedaria:

group = 1
// Grupo de llamada, equivalente al fichero SIP
context= desde-movil
// El contexto al que sera dirigidas las llamadas entrantes por este canal
signalling = fxs_ks
// Señalizacion del canal, en este caso si es intuitivo
callerid=asreceived
// No se si recuerdan cuando se configuro el gateway Epygi, una de las opciones que habia que poner en la configuracion de las lineas ISDN es como pasar el Identificador de llamante al sistema. En este caso, tal como viene decimos
channel => 1

Asi por un lado quedaria configurado el canal 1, FXS. Por otro lado el canal 4 FXO quedaria asi:

group=4
context=extensiones
signalling=fxo_ks
callerid=”Telefono DECT” <101>
mailbox=101@extensiones
channel=>4

En este caso, como puede observarse es exactamente igual que la configuracion del fichero SIP en cuanto a lo que contexto, callerid, mailbox y demas pudiere referirse.

Con esto ya quedaria integramente configurado nuestro fichero chan_dahdi.conf. Para “recargarlo” desde la consola (CLI) Asterisk tenemos que utilizar el comando:
module reload chan_dahdi.so

Para la configuracion del Dialplan solo tomamos en cuenta una consideracion muy sencilla. Los canales analogicos por tarjetas se representan como DAHDI/X siendo X el canal. Asi que toda la configuracion del extensions.conf es equivalente a si pusieramos SIP/(nombre del contexto sip) pero con DAHDI

Ejemplo, para la extension 101 del telefono Dect

exten => 101,1,NoOp()
exten => 101,n,Answer
exten => 101,n,Dial(DAHDI/4)
exten => 101,n,Hangup

Asi de sencillo, asi mismo para enviar una llamada a traves del FXS creamos una regla para moviles en mi caso (Enlace GSM conectado al canal 1)

exten => _[67]XXXXXXXX,1,NoOp()
exten => _[67]XXXXXXXX,n,Dial(DAHDI/1/${EXTEN})
exten => _[67]XXXXXXXX,n,Hangup()

Por cierto ya que ha salido el tema, ¿os habeis enterado que como novedad este 2011 empezaran a salir numeros moviles que empiezan por el 7?

Finalmente creariamos el contexto [desde-movil] para recepcionar todas las llamadas entrantes, si es que llamasen al numero del movil en cuestion asociado al canal 1.

Y con esto ya hemos ganado el segundo Asalto, abordando un poco la cuestion relacionada a las tarjetas de Asterisk y su configuracion despues de lo que se sufrio en dias pasados. De todas formas esto no sera muy frecuente en mis sucesivos mensajes porque como comente, yo no soy nada partidario de utilizar tarjetas por los motivos que explique en su dia. Aunque es curioso que todo aquel que se quiera presentar a un dCAP (logico, porque digium solo fabrica principalmente tarjetas), ha de conocer esto en profundidad. Hay que ademas saber tratar con tarjetas BRI y PRI que tienen ciertas variaciones muy especificas. Pero para eso existe un comando todo poderoso que te hace la mitad del trabajo: dahdi_genconf. Basicamente te configura el fichero system.conf tras chequear que hay disponible entre la tarjeteria cargada en el sistema (Y que puede observarse con el comando dahdi_tools). Quiza vengan en un futuro mas detalles si tengo la oportunidad de trastear con otras tarjetas, sean BRI de otras marcas (¿Beronet?) o alguna tarjeta Primaria de Digium (creo que es la unica tarjeta que verdaderamente merece la pena en cualquiera de los casos).

Para terminar me gustaría sugerir a todo aquel seguidor de mi Blog, si tiene interés en que profundice o experimente en algún tema no dude en planteármelo como un comentario y procederé con la cuestión. Todo sea por mejorar la curva de aprendizaje de todos aquellos que me sigan tras el paso por este Blog a través de mi experiencia.

Creando una Operadora Automatica de Coste Cero I

Es curioso observar que el 99,99% de sistemas de operadoras automaticas de las PBX de marcas reconocidas como Alcatel-Lucent, Panasonic, Siemens, el coste de poseer un sistema de operadora automatica, o IVR (interactive voice response), sea directamente proporcional al numero de canales entrantes de voz. Y la pregunta es, ¿realmente estas operadores ofrecen algo mas que no podamos obtener a traves de nuestro magnifico sistema Asterisk? La respusta no solo es negativa, sino que ademas podemos discriminar que vamos a ser capaces a traves de nuestro plan de marcacion de realizar operaciones totalmente casi inimaginables para estas centralitas de alto nivel, al menos, sin una dificultad de alto standing.

¿Pero no se supone que las PBX de marcas reconocidas poseen interfaces de configuracion ampliamente escalables y de relativa facil configuracion? Solo si queremos hacer funciones, que no sobrepasen el nivel del mar.

Y eso es lo que vamos a tratar de hacer hoy, pero sin ir demasiado lejos, solo andando un poco por la arena.

Segun veiamos el otro dia con respecto a los Gateways, y la capacidad de recibir llamadas entrantes, vamos a plantear un nuevo contexto dentro del DialPlan en el que manejemos dichas llamadas a nuestra voluntad.

Partiendo de la base:

[desde-rdsi]
exten => 987654321,1,NoOp()
exten => 987654321,n,Answer
exten => 987654321,n,Goto(operadora,s,1)

Tenemos la instruccion Goto, que nos permite desplazarnos a otro contexto (operadora), marcacion de extension (s) y prioridad (1). Ya hemos hablado sobre las prioridades y los contextos. ahora voy a hacer una breve reseña sobre las marcaciones de extension.

Por un lado existen las marcaciones especiales:

s viene de start, suele ser, la marcacion de inicio de todo contexto, una extension comodin para dejar claras las cosas por regla general.
i viene de invalid, en caso que marquemos una extension que no pertenezca a un contexto, entonces iremos a esta marcacion de extension
t viene de timeout simple, seria el caso de que se acabe el tiempo por una aplicacion que tenga expiracion de tiempo, como WaitExten
T viene de timeout absoluta, existe una variable global (ya veremos variables locales y globales en otro momento) llamada TIMEOUT que establece el tiempo total que se permite mantener una llamada en activo, en el momento que expira este tiempo, entonces saltariamos a la T del contexto que nos encontremos

Por otro lado existen las extensiones normales, y los patrones

Una extension normal simplemente es un numero cualquiera
Un patron viene precedido por un guion bajo  “_” y permite que se puedan crear patrones de posibles extensiones numericas. Informacion detallada sobre esto, la explico en un post mas antiguo

Ahora ya que sabemos lo que necesitamos saber sobre extensiones comenzamos con nuestro contexto de IVR

[operadora]
exten => s,1,NoOp
exten => s,n,Answer()
exten => s,n, GotoifTime(8:00-14:00,mon-fri,*,*?abierto,s,1)
exten => s,n,GotoifTime(16:00-18:00,mon-fri,*,*?abierto,s,1)
exten => s,n,GotoifTime(*,mon-fri,1,jan?festivo)
exten => s,n,Playback(fueradehorario)
exten => s,n,Voicemail(100@default)
exten => s,n,Hangup
exten => s,n(festivo),Playback(festivo)
exten => s,n,Voicemail(100@default)
exten => s,n,Hangup

Esto podria ser la estructura de una eficaz “introduccion” a nuestra operadora automatica. Leyendolo rapidamente, lo que tratamos de hacer es que salte al contexto “abierto” en caso que la llamada se encuentre en horario lectivo de la empresa, o que salte a la etiqueta “festivo” en caso que coincida que es dia de fiesta. En otro caso, lanzara un mensaje de “estamos cerrados”, saltara un buzon de voz para dejar mensajes y colgara, en caso que salte a la etiqueta “festivo”, algo parecido, un mensaje diciendo que es dia festivo en la empresa, buzon de voz y cuelgue.

Realmente esto se podria usar incluso como plantilla para miles de centralitas de PYMES y SOHO y ofreceria una configuracion basica, potente y eficaz, sin tener que andar merodeando en miles de interfaces graficas que pueden dar lugar al error facilmente. Esta claro que este blog esta dedicado a gente especializada en el mundo de la informatica y/o las telecomunicaciones por lo que trabajar sobre una pantalla con fondo negro y letras blancas no deberia ser demasiado drama y mas alla aun, deberia ser una gratificacion excepto en contados casos.

Figura 1: “No exige aprender Linux o Scripting” Como si fuera algo malo

Ahora vamos alla con el detalle. En primer lugar vamos a introducir la aplicacion GotoifTime:

Como vimos con Goto, es equivalente, pero introduciendo una condicion temporal. Para los conocedores de Cron, esto es equivalente.

En primera posicion, especificamos hora o rango horario, incluso varios rangos horarios. Por nuestro ejemplo podriamos haberlo resumido con:

exten => s,n, GotoifTime(8:00-14:00,mon-fri,*,*?abierto,s,1)
exten => s,n,GotoifTime(16:00-18:00,mon-fri,*,*?abierto,s,1)

por

exten => s,n,GotoifTime(8:00-14:00|16:00-18:00,mon-fri,*,*?abierto,s,1). Dos pajaros de un tiro como quien dice.
El segundo parametro, es el dia de la semana, en ingles, los tres primeros caracteres, y ocurre lo mismo que con las horas, rangos, multiples rangos, etc.
El tercer parametro, es el dia del mes y el cuarto, el mes en ingles y los tres primeros caracteres igual. El resto es equivalente a a la aplicacion Goto.

Ademas aqui hemos introducido las etiquetas aparte de los contextos. Una etiqueta se ubica en una parte de la prioridad, esto es util cuando como ocurre en mis ejemplos en vez de poner prioridades del tipo, 1 2 3, etc pongo siempre n considerando lo de n+1 y queremos saltar a otra prioridad sin tener que saber la posicion relativa (esto nos permite la maxima genericidad en nuestros planes de marcacion y la capacidad de insercion futura en casos complejos).

Sobre los ultimos dos parametros, dia del mes y mes, hay que considerar que esto permite mucho “poder” para crear genericidad a lo largo de los años, como son el caso de los dias festivos. En nuestro ejemplo decimos: Si es lunes a viernes y ademas cae el 1 de Enero entonces es festivo. Aunque sea lo que sea realmente es festivo este seria un ejemplo especifico de la posibilidad saltar al contexto dia festivo realmente en estos dias, y si fuera un sabado o un domingo, como ya es festivo de por si, que de el otro mensaje (El de cerrado simplemente) . Opciones hay muchas y esto quedaria a nuestra libertad.

Mas alla aun, asterisk 1.8 tengo entendido que incluso existe la posibilidad de crear calendarios con Google Calendar y desde ahi especificar los dias festivos y toda la informacion relativa a tiempos. Hay mas informacion aqui, y esto nos ofreceria un nivel de potencia a bajo coste de complejidad para nuestro IVR que ninguna otra central se acercaria lo mas minimo. Ahora ya podemos decir que estamos sobre el nivel del mar, y eso que no hemos empezado siquiera en este mundillo.

Por otro lado, tenemos la aplicacion Playback. Simplemente reproduce un archivo de musica que tengamos en la carpeta correspondiente en funcion de nuestro lenguaje definido. Los sonidos se encuentran en /var/lib/asterisk/sounds/

Finalmente esta la aplicacion Voicemail, que basicamente llama a otro archivo de musica (“deje su mensaje despues de oir la señal”) y guarda el mensaje de voz en el buzon especificado (100) del contexto por defecto (@default). Todo esto podemos verlo y configurarlo en el archivo de configuracion voicemail.conf que seguramente veremos en otro momento.

Y ahora ¿que ocurre con las llamadas que van al contexto “abierto”?

Vamos a hacer algo sencillito en abierto para terminar por hoy, y mas adelante intentaremos profundizar aun mas en todo esto.

[abierto]
exten => s,1,NoOp
exten => s,n,Background(listadistribucion)
exten => s,n,WaitExten(20)

exten => 1,1,NoOp
exten => 1,n,Goto(comercial,s,1)

exten => 2,1,NoOp
exten => 2,n,Goto(postventa,s,1)

exten => t,1,NoOp
exten => t,n,Goto(telefonista,s,1)
exten => t, n,Goto(s,1)

Voy a leerlo: primero, saltaria un mensaje, que diria “Bienvenido a nuestra empresa, Marque el 1 para hablar con Comercial o Marque el 2 para hablar con Posventa, en otro caso espere y le pondremos con un Agente”. En caso de marcar el 1, le mandaria al contexto comercial, y en caso de marcar el 2, a postventa. En caso de “Timeout simple” le mandaria al telefonista.

Aqui solo tenemos dos aplicaciones que no vimos hasta el momento:

Background es equivalente a Playback pero deja a la espera de marcacion de una extension. Podemos interrumpir el background si marcamos teclas en el telefono y saltaria a la extension del contexto marcada (hay mas opciones complejas, como saltar a extensiones de otros contextos pero no voy a entrar en detalles)

Por otro lado Waitexten, basicamente establece el tiempo que tenemos para marcar una extension antes de ir a la extension especial “t”.

Parece sencillo, y lo es. Asi que invito a hacer mil combinaciones con toda esta información para crear posibles IVR sencillitos que cumplan una funcion que para la mayoria de las PBX del mercado suele ser bastante compleja y obliga a pasar por miles de secciones de la interfaz grafica. Por esto, es suficiente por hoy. Seguiremos informando como suele decirse

Conectandonos al mundo Real: El planeta Gateway II

Como comentaba en el ultimo mensaje, hoy tenia la intención de explicar en detalle como se realizaría la configuración en Asterisk, para admitir el Gateway Epygi configurado, y por otro lado, poder presentar la sencillez configuración y manejo los FXS que proporciona el magnifico Gateway Linksys SPA8000.

Por un lado hablando del Epygi, tendríamos que conectarlo via SIP como ya sabemos.

En el fichero sip.conf que ya conocemos de anteriores configuraciones vamos a crear un apartado para el mismo:

[epygi]
host=dirección ip de nuestro gateway
defaultuser=usuario que pusimos en la configuración del sip trunk
secret= la contraseña correspondiente
qualify=yes (para tener monitorizado el elemento)
type=friend (para recibir y emitir llamadas a través del mismo)
context=desde-rdsi (este es el contexto en el dialplan donde las llamadas de las RDSI a través del gateway)

Con esto es suficiente, seguramente podríamos especificar alguna opción de seguridad adicional, pero sobre seguridad en Asterisk ya hablaremos otro dia.

Ahora toca hablar un poco del dialplan, el fichero extensions.conf. Realmente no he dedicado un mensaje especifico a hablar sobre el Dialplan, porque como es un tema tan extenso, prefiero ir introduciéndolo según la necesidad vaya surgiendo, en un mensaje próximo, escribiré un pequeño manual para crear un sencillísimo IVR (Contestador Automatico) para manejar las llamadas que nos entren a través de este Gateway, o cualquier otro operador ip que podamos utilizar.

Como dijimos antes, vamos a utilizar el contexto [desde-rdsi] para todas las llamadas que nos entren por nuestro Gateway.

[desde-rdsi]
exten => 987654321,1,NoOp()
exten => 987654321,n,Answer
exten => 987654321,n,…

Muy sencillo Dialplan. Simplemente como vimos en anteriores mensajes, siguiendo la estructura general de todo Dialplan, pasamos la extensión en primer lugar. La extensión que recibimos es justamente la que nos pasa el Gateway, y como configuramos en la sección ISDN del mismo, enrutaba a la centralita poniendo el teléfono del DID como extensión llamante. Esto quiere decir, que si disponemos de varios DID y los configuramos en la sección que vimos, pues simplemente tendríamos poner poner cada DID como extensión y configurar en el dialplan como querríamos manejar cada caso (mandándolo a una extensión con el comando Dial, o a un grupo de extensiones, o activando el IVR en secuencia por comandos, o toda la potencia en general que nos permite el Plan de Marcacion de Asterisk)

Si todo esto lo hubiera tenido por escrito en el momento que empece a configurar el Gateway seguramente podría haberlo montado en cuestión de 15 minutos sin problemas, porque como puede verse es realmente sencillo de manejar.

Si esto resulto facl, vamos a ver un poco acerca del Linksys, que es todavía aun mas sencillo, aunque viene cargado de opciones, que podríamos editar al gusto, en este mensaje solo vamos a centrarnos en los primeros pasos, echarlo a funcionar, comprobar que todo esta OK, y configurar Asterisk para que reconozca bien cada puerto a voluntad.

En primer lugar, comentar que el aparato tiene 4 modos de uso

–          Usuario Basico

–          Usuario Avanzado

–          Administrador Basico

–          Administrador Avanzado

Todo esto se selecciona desde la interfaz de inicio, arriba a la derecha, Admin, Advanced necesitamos estar para configurar el sistema con lo básico.

En el apartado Router -> WAN Setup configuramos lo básico acerca del sistema de red del equipo.

Direccion IP (Static IP), Mascara de red, y Puerta de Enlace (esto no es muy recomendable usarlo, si no vamos a necesitarlo para nada en particular, ya que podría llegar a exponer nuesto equipo a ataques foráneos), aunque sin esto no podremos utilizar opciones para tener actualizada la hora de los teléfonos como los “NTP Server”, aunque podemos configurarlo a mano, no es una utilidad en principio que nos vaya a resolver la vida en Asterisk.

En el apartado Voice es donde realizaremos toda la conexión con Asterisk.

Uno de los problemas que mas afecto a mi sistema, era el hecho de no poder recibir los DTMF correctamente. Esto se solucionó inmediatamente cambiando un parámetro dentro de Regional:

Con respecto a la interconexión SIP con Asterisk se realiza desde cada una de las Lineas del sistema (L1,L2,L3, etc)

Entrando por ejemplo en la linea 1, L1, en el apartado siguiente:

Tan simple como configurar eso 4 parametros, el servidor Asterisk, el usuario y la contraseña que tendremos en nuestro servidor Asterisk.

Ahora ya solo quedaria registrar esta linea FXS, como una extension (ext10 del ejemplo), en el fichero sip.conf

[ext10](extension,codecs)
callerid=”Extension Analogica”
defaultuser=ext10
secret=contraseñasupersegura
mailbox=10@default

Tan sencillo como con configurar cualquier extension SIP que podamos usar en un terminar IP puro, o en un softphone como vimos hace tiempo

Tras este resumen, tenemos claro, que si manejamos bien todos los mensajes que fuimos recorriendo hasta este, configurar este Gateway no supone ningun inconveniente. De todas formas como siempre podrian surgir inconveniencias, tanto para este como para el Epygi, yo estoy abierto para resolver todos los problemas que pudieran surgiros al respecto, y asi si cabe, engrosar con mas cantidad y calidad, el nivel de informacion que circule en este blog.

Nada mas por hoy. Con tanto componente en funcionamiento, ya solo queda empezar a subir el listo un poco, el proximo dia hablaremos sobre un IVR de ejemplo y tambien hare una gran introduccion al mundo de los CDR (Call detail record, o registro del detalle de llamadas) para poder analizar llamadas guardadas en una base de datos del sistema, e introducire el primer software adjunto al sistema que he conseguido poner en funcionamiento y reporta unos excelentes resultados.

Introduciendo un Proveedor SIP: Parte 2

Tras la migracion, y aun a la espera del retorno de la tarjesta TDM410P enviada en garantia, hoy voy a hacer una pequeña explicacion de las ultimas modificaciones introducidas a nuestro sistema Asterisk, concretamente a nivel de DialPlan, para en detalle, el funcionamiento del Proveedor SIP que configuramos el otro dia y por otro lado, algunos retoques para darle un poco mas de nivel a nuestro sistema, como una pequeña operadora automatica de pruebas.

Realmente aqui se vera gran parte del codigo contenido en nuestro fichero “extensions.conf” y un poco la explicacion de cada atributo.

[operadorip]
exten => 851123456,1,NoOp()
exten => 851123456,n,Goto(s,1)
exten => sirlouen,1,NoOp()
exten => sirlouen,n,Goto(s,1)

Si recuerdan, el otro dia pusimos en el contexto del provedor SIP dentro del sip.conf, llamado “operadorip”. Este contexto vendra directamente aqui.

La primera vez que hable del DialPlan no explique exactamente a que se referia cada argumento de la linea exten=>

En primer lugar, exten, se refiere como su nombre indica, a la extension marcada a la que va a hacer referencia como primer argumento. Esto es lo mas extendido y utilizado por defecto. En este caso, la extension, hablamos del numero DDI que nos ofrece el operador IP ya que de alguna forma es como lo reconocera como primera “entrada” nuestra centralita. En algunos casos, el proveedor IP te ofrece un numero de usuario adicionalmente, y este numero de usuario tambien lo entrega el operador IP sustituyendo al numero DDI, de forma casi aleatoria segun comprobe tras diversas pruebas. Por eso decidi poner las dos posibilidades.

Como segundo argumento, es el numero de prioridad en la lista de ejecucion. Lo tipico es poner en la primera linea el 1, en la segunda el 2, etc. Pero si ponemos en la primera el 1 y luego la n, significa que aumentamos el contador de prioridad linealmente, 1, n+1 (2), n+1 (3), etc. Esto es util si por ejemplo en un futuro tenemos intencion de meter mas lineas intermedias, no tengamos que cambiar el numero de prioridad a toda la secuencia completa, algo engorroso y que puede dar lugar a errores.

El tercer argumento hace referencia a la funcion que va a cumplir esa linea. En mi caso, siguiendo un buen consejo que me dieron, lo ideal seria poner NoOp (sin operacion), para poder asi asignarle el elemento 1 por defecto. Esto es una buena practica en general ya que si luego creamos Macros (equivalente a plantillas para secuencias del Plan de Marcacion), esto hace que exista cierta uniformidad y estandarizacion. Tampoco es crucial escribir asi, pero desde que se creo el Copy & Paste tampoco supone una gran inconveniencia y nos aportara mas que nos rebajara.

Los siguientes Argumentos en embos casos, son condicionales GO TO, tipicos en programacion. La funcion GoTo recibe 3 parametros siendo como primer parametro, un contexto, si solo se dan dos, se conserva en el contexto en que nos encontremos. El segundo, seria la posicion de marcacion dentro de ese contexto. S viene a ser la posicion de inicio por defecto. Donde suele entrar todo (hace referencia a Start, comienzo) al entrar en un contexto. Finalmente indicamos el lugar de la prioridad donde queremos entrar. Tambien con la funcion Goto podriamos pasar 1 solo argumento, esto es el lugar dentro del a prioridad (y consideraria la posicion de marcacion y el contexto donde actualmente nos encontrasemos), tambien podemos pasar una bandera asociada a un nivel de prioridad como veremos mas adelante.

Con esto, de alguna forma, si nos llaman a nuestro numero DDI, “ya estariamos dentro de la centralita”, ahora tocaria a traves de un Contestador Automatico, manejar esta llamada

exten => s,1,NoOp()
exten => s,n,Answer
exten => s,n,Background(menu)
exten => s,n,WaitExten(20)

Esto es bastante sencillo. Igual que vimos con anterioridad, recogemos la llamada con Answer, y con Background ponemos un sonido que tendremos registrado en nuestro directorio /var/lib/asterisk/sounds.
Hay dos formas de crear sonidos
1. A traves de una marcacion con la funcion Record, grabariamos nuestros propios sonidos
2. Directamente introduciendo la pista de audio en la carpeta indicada con el nombre en cuestion y segun el formato .gsm, .wav, etc que tengamos especifcado dentro de los codecs soportados en este contexto.
Finalmente tenemos la funcion WaitExten que basicamente realiza la operacion de espera a que se marque un digito durante los segundos pasados como parametro. Este digito entra como marcacion DTMF y como comente en otra ocasion, aqui se originaron problemas por parte del operador IP, a raiz de las malas latencias, que al final consegui solucionar en el fichero de configuracion de disposistivos SIP utilizando el modo DTMF “inband”
exten => 1,1,NoOp()
exten => 1,n,Playback(ext1000)
exten => 1,n,Goto(extensiones_internas,1000,1)
exten => 2,1,NoOp()
exten => 2,n,Playback(ext1001)
exten => 2,n,Goto(extensiones_internas,1001,1)
Una vez marcado el digito por DTMF iriamos a la posicion de marcacion, en este caso pongo dos ejemplos sencillos, lo unico especial, la funcion Playback que a diferencia de Background no espera una marcacion, simplemente reproduce un mensaje y continua hasta la siguiente orden. En este caso, cambiamos de contexto y ya finalmente nos vamos a nuestro contexto “privado” donde estan ubicadas las extensiones de nuestra oficina tal y como configuramos con anterioridad.
Ahora vendria la otra perspectiva, desde “dentro” hacia el exterior a traves del proveedor SIP.
En este caso por motivos logicos de “seguridad” no nos interesaria que alguien pudiera acceder a traves de las marcaciones DTMF en el mismo contexto “operadorip” y ser capaz de llamar al exterior. Por esto, la idea es que esto solo pueda marcarse desde el contexto “privado” donde se encuentran nuestras extensiones.
En este caso la marcacion es un tanto especial y tenemos que introducir nuevos conceptos:
;Salida de llamadas Nacionales
exten => _[689]XXXXXXXX,1,NoOp()
exten => _[689]XXXXXXXX,n,Dial(SIP/${EXTEN}@netelip,30)
exten => _[689]XXXXXXXX,n,Hangup()
Como podemos ver, aqui aceptamos un total de 9 posiciones. Bueno parecen mas, pero aqui explico el formato especial de marcacion que he tenido en cuenta para este caso:
En primer lugar, si vamos a usar caracteres especiales como X,N o Z necesitamos poner delante la barra baja.
En segundo lugar, observamos los tres valores 6,8,9 contenidos entre corchetes. Al estar contenidos entre corchetes significa los posibles valores que puede tomar el primer digito, solo el 6 (moviles), 8 (numeros geograficos virtuales) y 9 (numeros geograficos de España). Tambien podriamos tener un guion tipo [67-9] en este caso estariamos considerando los valores 6,7,8 y 9 seria lo mismo que [6-9]
En tercer lugar tenemos digitos especiales. X significa cualquier valor entre 0 y 9, Z entre 1 y 9 y N entre 2 y 9. En este caso seguramente seria mas eficaz separar los moviles y los fijos dado que podriamos en un segundo nivel restringir las llamadas a numeros especiales tipo 902, 901, etc eliminando la posibilidad con [89]ZXXXXXXX. Aqui tenemos tantas posibilidades como queramos.
Una vez marcada esta secuencia, nos encontramos con la Funcion Dial, que al igual que utilizado para marcar extensiones en este caso con la variable ${EXTEN} recogemos lo marcado en la posicion de marcacion y lo “enrutamos” a traves del contexto sip indicado tras la @ en este caso nuestro Proveedor IP. El ultimo parametro 20, es el tiempo que esperara tras marcar para que recoja tono la llamada, en otro caso colgara.
Entendido esto podriamos crear sistemas de marcacion todo lo complejo que se nos ocurriesen. Y muy util para la creacion de plantillas, y para la generacion de extensiones de manera semi-automatica puesto que por parte del dialplan no seria necesario apenas escribir codigo si el patron de las extensiones es equivalente.
Con esto doy una breve revision de la interrelacion de un proveedor IP y el Plan de Marcacion de nuestro sistema para poder darle uso. Pero el Dial Plan tiene mucha miga por dentro, miles de funciones. Seguire en sucesivos articulos poniendo mas ejemplos sobre posibles opciones que se me ocurran y que mas concretamente sean muy utiles en un entorno de produccion/oficina.

Curso Asterisk de Iniciacion: Dias 2 y 3

He dejado pasar sin mayor opcion algunos dias tras el ultimo mensaje. Tenia pendiente la escritura de mis impresiones y como fueron los ultimos dos dias del Curso de Asterisk de Iniciacion.

La cuestión reporto grandes y mejores resultados en estos dias ya que tras la instalacion y los primeros pasos en el sistema Asterisk empezamos a realizar ciertos ejercicios con nuestra maquina y nuestro telefono.

El día 2 fue íntegramente dedicado a la comprensión del sistema de marcación, Dial Plan de Asterisk. Tras haber visto, como conectar diferentes dispositivos con la Maquina Asterisk, llegaba el momento de interconectar todo entre si a traves de este mecanismo. El Dial Plan queda reflejado principalmente en el fichero extensions.conf del sistema.

A lo largo del dia vimos numerosos ejemplos, entre los que se encontraban, llamadas directas a una extension, mascaras, algunas Aplicaciones, entendimiento del concepto secuencial del sistema, prioridades, etiquetas, etc. Tambien vimos un poco de programación, que contemplaban alternativas condicionales y bucles principalmente.

Todo esto si que me resulto verdaderamente util, ya que al final de dia, tenia bastante claro como realizar la primera acción que tenía bastante interes y expectacion sacar del curso: Como configurar una Operadora Automatica (IVR/Autoattendant). Jutamente el ultimo ejercicio del dia fue configurar una operadora muy sencilla, la cual debia poner un mensaje de Contestador Automatico en caso de estar fuera de la Oficina, luego un menu de marcacion, y la aplicacion de saltos condicionales, y de un pequeño bucle para comprobar que la persona no habia introducido por error la marcacion un numero determinado de veces, antes de colgar la llamada.

Todo esto lo vamos a ver en profundidad en otro momento ya que constituye bajo la perspectiva del momento, el pilar principal del sistema.

Un comentario extra, justamente ese día aprovechamos para ver el partido de España-Suiza, una lastima que perdiéramos de 1 gol, contra un equipo tan inferior a nuestra Selección! Pero definitivamente esto no hizo que variáramos nuestra programación, de hecho diría que fue el día mas productivo de los tres! (Espero que la Selección también se aplique el cuento en productividad para el futuro)

El tercer dia, originalmente trataria sobre la adaptacion del mundo Analogico a nuestro sistema Asterisk. Para ello nos proveian de una Tarjeta Digium 410, con un modulo FXO y otro FXS, uno para conectar en teoria, a un Gateway con varios puertos FXS que haria las veces de enlace directo con otra centralita Asterisk, y el otro para conectar a un telefono analogico.

Primero se vieron multiples conceptos basicos de la Telefonia convencional y luego se tantearon todos los ficheros de configuracion que involucraban esta idea. El sistema Analogico, especialmente a nivel interno Linux-Tarjetas lo maneja Dahdi (se ve que antiguamente se llamaba Zaptel). Aparte Dahdi y las tarjetas Digium ofrecen una fuente de reloj de sincronizacion para ciertas aplicaciones avanzadas, como las Salas de Conferencias (aplicacion MeetMe). En caso que necesitemos una alternativa a Dahdi, se podria plantear todo el sistema a traves de Gateways SIP y configurarlos dentro del sistema como interfaces SIP exactamente igual que cualquier otro dispositivo, como los configurados el primer dia del Curso. Luego todos los detalles analogicos de interconexion con Asterisk, y con el operador o telefonos analogicos, se configurarian aparte en el Gateway, a traves una interfaz web propia del Gateway.

Pero en el caso de las tarjetas, aparte, en Linux es necesario cargar los modulos de sistema, y luego en el fichero chan_dahdi.conf la necesidad de indicar montones de parametros que detallan toda la configuracion en referencia a como debe tratar Asterisk a los citados Puertos.

Tambien se hizo una buena reseña al mundo de los Primarios y los Accesos Basicos.

El pequeño detalle negativo, fue el hecho de que los equipos que nos fueron proporcionados y hacian de servidor de Asterisk, no poseian puertos PCI libres (y las tarjetas Digium que nos ofrecieron eran PCI 2.2). Esto impidio que pudieramos probar por nuestra cuenta, si la configuracion expuesta funcionaba correctamente, y haber hecho algunas pruebas de integracion, con lo que habiamos realizado en los dias anteriores. Las pruebas se hicieron con un unico equipo que si poseia el citado puerto, manejado por el profesor. Realmente me hubiera gustado probar todo aquello en aquel momento que estaba en mi salsa con todo montado y sin mucho mas que hacer que eso mismo. Pero en los proximos dias, aprovechare para hacer las primeras pruebas con la tarjeta, y algun equipo que trate de configurar.

Por la tarde, se vieron algunas cuestiones mas avanzadas del sistema, como el uso de Macros, las salas de conferencia, y la gestion de Colas y Agentes.

Con esto, ya he podido coger un buen espectro del funcionamiento del sistema en lineas generales. Debo decir que he quedado bastante impresionado con las funcionalidades basicas de Asterisk, mas considerando que para mi condicion en relacion a la informatica, todo el tratamiento del sistema me resulta muy cercano, y mucho menos complejo de lo que esperaba (ya que habia que tocar ficheros de configuracion / programar y comparando con ciertas interfaces graficas que proveen otro tipo de PBX, pense que iba a haber una diferencia ignominiable a nivel de complejidad, aunque ahora veo que nada mas lejos de la realidad, es bastante mas sencillo y versatil.

Comparativamente esto es como tener que crear una pagina web, con un asistente de creación de paginas web, o poder crearla a nivel HTML con codigo. Es cierto que hay que aprenderse con código todos los detallitos que conforman el sistema, pero el poder y las combinaciones y opciones que esta opcion otorga, no tiene fin, ni limite, es posible dar alas a la imaginación, y todo lo imaginable. se puede hacer realidad.

Como valoracion general, debo decir que me ha resultado bastante provechoso el curso de Iniciacion, y de hecho se lo recomendaria a cualquiera. El profesor resulto muy flexible en general, y el nivel dentro de lo posible se intento mantener lo suficientemente alto como para no quedarnos estancados sin avanzar.

Por contra, principalmente, que fueron demasiados pocos dias, el precio por dia es un poco elevado, y el nivel de organización no fue el deseado. Un curso de 4 dias hubiera estado mucho mejor para cubrir algunos aspectos que se quedaron en el tintero, como la integración con IAX (el protocolo de intercomunicación entre centralitas Asterisk, con la idea de unir varias centralitas Asterisk y poder compatir ciertas cuestiones, como los Dial Plan), quiza haber tratado un poco mas el mundo RDSI, y poder haber realizado mas practicas para haber dejado todo claro como el agua. Aparte, tambien tuvimos ciertas dificultades desde el inicio, desde que los sistemas no estaban bien instalados, hasta el tema que comente antes de los puertos PCI, un grandisimo error (mas, para aquellos que ni siquiera adquirieron la tarjeta en propiedad para luego hacer sus practicas en casa, y para los que si lo hicieron, que no tuvimos la oportunidad de “catarla”).

Espero poder avanzar ahora después de esto mucho mas rápido, y poder proveeros de mucha mas información para poder Acelerar la curva del Aprendizaje de Asterisk lo máximo posible.