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.

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.

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.

Conectandonos al mundo Real: El planeta Gateway I

En estos momentos mi pretension se encuentra en poder ofrecer servicios de la PSTN a mi centralita Asterisk. En la actualidad existen dos opciones principales:

1. Hacer la conexion a traves de tarjetas internas, PCI o PCIe en el servidor Asterisk
2. Hacerla a traves de Gateways que utilizan principalmente el protocolo SIP y a traves de una interfaz ethernet comunicarse con ellos.

Obviamente cada opcion tiene sus ventajas y desventajas. La primera opcion, al ser parte del servidor, se configura a traves del modulo Dahdi, y para grandes instalaciones resulta muchisimo mas sencillo hacer una instalacion de las mismas, ya que copiando los ficheros de configuracion de uno a otro se conseguirian los mismos resultados. Ademas el manejo de las mismas es “puro” y solo intervendria el sistema operativo y el propio Asterisk, aunque esto no tiene porque ser realmente una ventaja.

Por otro lado los gateways, tienen una espectacular ventaja sobre las tarjetas, y un pequeño inconveniente bajo mi criterio (a lo mejor tienen mas y estoy abierto a descubrirlos), pero que quiza haga que la espetacular ventaja sea muy superior a todos los inconvenientes y particularmente incline la balanza en un gran numero de casos en los que sea necesaria una implantacion de las mismas.

Y la gran ventaja de la que hablo es sencilla: La alta disponibilidad al minimo coste. Cuando contamos con 1 o mas gateways (preferiblemente mas de 1), realmente es como si contaramos con multiples servidores. Si tenemos por ejemplo dos servidores Asterisk funcionando, con heartbeat de por medio y un sistema de varios Gateways en funcionamiento, en caso de caer un servidor, automaticamente el segundo utilizaria exactamente los mismos gateways para su funcionamiento, sin la necesidad de tener que redundar las tarjetas para este supuesto. Hoy en dia en casos de Comunicaciones de Voz, la alta disponibilidad es crucial, ya que en la mayor parte de los casos, llamadas perdidas supone, clientes perdidos. Hoy en dia una centralita caida es mas dramatico que el servidor de bases de datos caidos, ya que las operaciones que comunmente podemos hacer a traves de un ordenador, pueden hacerse temporalmente a mano para aliviarlo, pero los clientes que no tienen forma de contactar con nosotros… ¿que podemos hacer en contrapartida para hacer que sea menos dañino? En la mayor parte de las ocasiones, sin un sistema alternativo… nada, clientes perdidos.

Curiosamente, a nivel comparativo, Gateways de diferentes marcas, cuestan exactamente igual que tarjetas con las mismas especficaciones. Esto es, un Gateway Linksys SPA8000 con 8 extensiones FXS cuesta apenas 200 euros en Octubre 2010, frente a lo que podria costar una TDM800P con sus 2 tarjetas FXS de 4 extensiones FXS cada una cuesta exactamente el triple. Y encima con el gateway conseguimos lo comentado anteriormente.

Lo mismo ocurriria con las lineas ISDN (RDSI). Un gateway normalito como podria ser un Epygi Quadro ISDN con 4 puertos BRI TE/NT cuesta exactamente lo mismo que una de las tarjetas mas baratas como la Beronet QuadBRI que en este caso ni siquiera tiene mucho mas que ofrecer por no ser propio de Digium, lo que da mucho que pensar si verdaderamente merece la pena. Tambien tenemos las tarjetas especificas Digium como la B410P que tampoco eleva el coste demasiado, pero considerando lo anterior, no es para menos.

Pero ya puestos un poco sobre antecedentes, y el porque de mi decision, ahora viene quiza lo mas interesante de este articulo: Las configuraciones de los Gateways. He conseguido hacerme con los dos gateways que puse de ejemplo. Para los puertos FXS disponia como opciones los Grandstrem, y para los BRI, disponia tambien como opcion los gateways Vegastream Europa. Concretamente los primeros en diversas pruebas se ha demostrado que reportan una muy inferior calidad comparativamente a los Linksys, con respecto a los segundos no puedo decir lo mismo, pero el costo en este caso hablaba por si solo (algo mas de un 20% para los 4 canales, similiar a las tarjetas especificas Digium).

En este caso mi idea de configuracion es muy sencilla:

En el gateway Epygi, montar en los dos primeros puertos, dos linea RSDI, que forman un grupo ISPBX reportado por la operadora, y en los dos segundos, montar dos Enlaces GSM cortesia de la operadora tambien, con puertos ISDN. Por tanto en ambos casos los cuatro puertos se configuran como TE (Terminal Equipment) puesto que son los que van a recibir el servicio.

La interfaz web del Epygi Quadro ISDN , es un poco escabrosa y bastante poco intuitiva pero cuando le coges el truco no desvela un gran misterio:

Primero hay que configurar las opciones ISDN. En el apartado Telephony -> ISDN Settings aparcen los 4 “troncales” numerados. Contamos con que en el troncal 1 y 2 montamos las RDSI y en el 3o y 4o montamos los enlaces GSM RDSI. Hay que configurarlos uno a uno, aunque tampoco es demasiado sofisticado

Pantalla Principal de configuración de los Puertos ISDN

Dentro del primer troncal, elegimos la interfaz tipo User porque esta conectado a la central (recordemos TE) y PTMP point to multipoint, realmente no va a cambiar mucho si ponemos PTP porque solo es un metodo de comprobacion que no tenemos el troncal ISDN conectado a mas sitios aparte de la Quadro, esto no va a generar ningun tipo de inconveniencia a priori, aunque sinceramente me queda investigar las posibles implicaciones colaterales e mantener esto en PTMP aun a riesgo de no tener por mi parte conectado el troncal ISDN a otros aparte del gateway y utilizar este modo.

Le damos a Next y en la siguiente parte, el Tipo MSN (multiple subscriber number), porque en caso de las RDSI es muy comun tener opcion a contratar multiples numeros que nos pasara la operadora y nosotros luego podremos enrutar en nuestra centralita para que se dirijan a una interfaz un a otra.

Seguimos adelante con Next, y aqui nos aparece toda la seleccion posible de MSN que tenemos a nuestra disposicion (las operadoras les llaman numeros DID (direct inward dialing) en este caso nuestro interes es mandarlo directamente a nuestra centralita Asterisk por esto seleccionamos la opcion por cada numero: Routing with inbound destination number

Tambien podemos poner el Caller ID por defecto en las llamadas salientes por este medio. En este caso el Caller ID debera ser uno de los MSN preferentemente el cabecera. Esta opcion no es imprescindible.

Y si continuamos a la siguiente pantalla sin haber marcado la opcion de Opciones Avanzadas (de momento sin entrar en mas materia no es necesario señalarla) ya habremos concluido la configuracion del primer troncal.

Para el segundo troncal exactamente lo mismo. Pero para el tercer y cuarto troncal seria bueno hacer una pequeña distincion. En estos casos, no es verdaderamente necesario señalar la opcion MSN (en este caso ponemos No MSN), ya que con los Enlaces GSM RDSI no se pueden aplicar multiples numeraciones. El resto es muy sencillo, la unica diferencia que no aparecer la lista en la que podemos ir señalando cada uno de los multi-numeros (como les llama Telefonica mas concretamente).

Para finalizar esta parte de la configuracion del Gateway finalmente, nos toca configurar en detalle como tratara el mismo las llamadas entrantes y salientes. Porque al igual que en un Plan de Marcacion, se pueden especificar rutas.

Todo esto se hace desde Telephony -> Call Routing -> Call Routing Table

Pantalla Principal de configuración de los enrutamientos de llamadas

Por un lado tenemos que configurar el camino Gateway -> Asterisk. Para ello pulsamos la opcion Add de añadir y seguimos con:

Enable Record activado
Tipo de llamada, SIP
Pattern: * (para que sean todas las llamadas sin distincion)
Descripcion: asterisk (aqui ponemos lo que queremos, yo pongo asterisk para saber hacia donde va)

Y seguimos hacia la siguiente pantalla, con Next:

Destination Host: Nuestro servidor Asterisk
Destination Port: El Puerto, por regla general 5060
Usuario y Contraseña, esto lo tendremos que configurar en el sip.conf!
Lo mas importante: FailOver Reason, Any o seleccionamos las que deseemos. Esto es por el hecho que vamos a decirle que en caso que el canal uno este ocupado los dos canales, automaticamente nos pase las llamadas al tercer y cuarto canales del troncal numero 2. El resto por defecto.

Seguimos adelante con Next hasta las opciones de llamada entrante:

Inbound Call Type: ISDN
Pattern: * (lo mismo que antes)
Number of Discard Symbols: 1 (si ponemos 1 en la mayor parte de los casos eliminamos una serie de informacion innecesaria para recibir el Caller ID)

Y ya el resto podemos seguir hasta el final con los parametros por defecto.

Por otro lado tenemos que configurar el camino Asterisk -> Gateway (trunks ISDN). En este caso nuestra intencion es que el 100% de las llamadas salgan por los Gateways GSM, pongamos por el hecho de que obtenemos una mejor tarifa a traves de ellos, o en otro caso podriamos configurar para salir por el troncal que deseemos en funcion de nuestro interes.

Lo curioso de esta centralita es que posee un pequeño handicap que tenemos que resolver a traves de patrones de llamada: No podemos de forma directa establecer un patron de rotacion entre canales mas alla del troncal en que nos encontremos, ya que por cada ruta, solo podemos asociar un unico Troncal. De aqui puede surgir la pregunta: ¿Y como pasamos las llamadas que no podemos atender con el troncal seleccionado, al siguiente libre? Sencillo: Simplemente establecemos una Razon de Failover dentro de la ruta del troncal desbordado, y automaticamente pasara a sucesivos troncales, en el orden en el que establezcamos las rutas. En este caso, segun vemos en la imagen, todas las llamadas saldrian por la ruta numero 2. Si los dos canales estuvieran usandose, entonces existiria una razon incondicional de failover, y saltarian automaticamente hacia el segundo troncal (en este caso Troncal numero 4), que estaria establecido en la ruta con identificador numero 3.

¿Como podriamos establecer un sistema de rotacion automatico? Si pusieramos un patron diferente en la ruta 2 y la ruta 3, ejemplo 2* y 3* (siendo asterisco, el numero que sea despues del 2 o el 3 respectivamente) entonces, podriamos realizar la decision previamente desde nuestra centralita y pasar el patron del numero con el prefijo 2 o 3 delante. Seria un pseudo mecanismo de rotacion, pero digamos, que esto podriamos incluirlo en el saco de las desventajas de los gateways, los firmwares tan “pesimos y limitantes” que suelen traer por defecto.

Pero igual, ¿como configurar esto aqui descrito?

Pulsamos la opcion Add como anteriormente y seguimos con:

Enable Record activado
Tipo de llamada, ISDN
Pattern: * (para que sean todas las llamadas sin distincion)
Descripcion: isdn 1 (aqui ponemos lo que queremos, yo pongo isdn 1 para saber que es el primer troncal de salida)

Seguimos hacia adelante con Next:

Port ID: Trunk 3 (recordemos que era el troncal 1 de nuestros Gateways GSM ISDN)
Failover Reason: Any (failover incondicional como explique antes)

Seguimos adelante,

Seleccionamos los dos Time Slots, y a continuacion:

Pattern: * (igual que siempre)
Inbound Call Type: SIP (justo al contrario que antes, la idea es conseguir SIP->ISDN en este caso)

Y para finalizar, en el siguiente paso: Inbound Host, seleccionamos la IP de nuestro servidor Asterisk y finalizamos

Para la segunda ruta, la del Trunk 4, todo se hace exactamente igual, a excepcion, de poner en Port ID: Trunk 4 (como es logico) y en la razon de Failover, None, para que no de mas vueltas si ya desbordamos a partir de ahi (¿a donde va a desbordar si no tenemos nada mas?) A mi solo se me ocurre una posibilidad: quiza podria ocurrir, que mientras los dos primeros canales estan ocupados, se ocupen los dos siguientes, y a la quinta llamada de salida, ocurra que uno de los dos primeros canales se liberase. En este caso podriamos poner Failover: Any tambien, y al volver a tratar de buscar un canal libre, encontraria uno de los dos del primer troncal. Asi que esto lo dejo abierto al gusto de cada uno.

Y ya esta por hoy. Tendriamos finalmente configurado nuestro Gateway ISDN Quadro de Epygi, muy robusto y la verdad, aun poco intuitiva interfaz, cuando le coges el truco, no tiene perdida como podéis observar.

En la proxima sesion de Gateways explicare como configurar el fichero sip.conf para asociarse con este troncal gateway (adelanto que es una configuracion MUY parecido a lo que podria ser un operador SIP como hablamos en anteriores entradas), y tambien como configurar el plan de marcacion, para aceptar llamadas entrantes de este gateway, y salientes a traves del mismo (mas de lo mismo que los operadores SIP, no tiene mucha perdida)

Y tambien incluire algo acerca del Linksys SPA8000, que aunque aun no domino a la perfeccion sobre para dar el servicio a nivel de funciones especiales para los telefonos analogicos, como teclas para Voicemail, transferencia de llamada, llamada en espera, etc y todavia estoy investigando acerca de esto, pero al menos para ir empezando, la configuracion basica para ponerlos en funcionamiento.

Con este blog, quiero recordar a cualquiera, que lo animo para montarse a muy bajo coste una potente centralita propia, y autogestionada, que como esta hoy el mercado de las PBX, supone un espectacular ahorro de costes para cualquier empresa, especialmente cuando hablamos de PYMES.