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.

El dia del Protocolo SIP: Parte 1

Como suele ser comun pensar, que mejor que empezar las primeras andanzas en funcionamiento usando dispositivos SIP, realmente los menos costosos ya que practicamente estamos rodeados de ellos. Ademas en este caso seran la base de mis pruebas de momento, ya que aun no dispongo de electronica suficiente para probar otros modulos.

Parece ser que Asterisk se divide por canales, segun el canal, llamemosle via de comunicacion, va en funcion del tipo, en este caso, el canal sip, llamado SIP CHAN con su archivo de configuracion sip.conf es el que voy a tratar introductoriamente en el mensaje de hoy.

Combinando mi aprendizaje a traves del curso, y la lectura del buen libro, The Future of Telephony (una de los mejores bajo mi criterio), cree un fichero sip.conf desde cero, (los archivos de configuracion de Asterisk se encuentran dentro del directorio /etc/asterisk/ como la mayoria de los ficheros de configuracion de Linux. El contenido del mismo a nivel muy basico seria el siguiente, explicado linea por linea:

[general]
language=es

En primer lugar, tenemos los contextos, encuadrados entre corchetes. Concretamente este contexto podria llamarse contexto global ya que afecta por defecto a todo el resto de los contextos.El atributo language se explica por si solo

[extension](!)
type=friend
host=dynamic
dtmfmode=rfc2833
canreinvite=no
nat=no
qualify=yes
context=extensiones_internas
pickupgroup=1
callgroup=1

En este caso ya tenemos mas atributos complejos. En primer lugar el contexto “extension” tiene una peculiaridad y es que al ponerle (!) lo convertimos en plantilla que luego otros contextos podran utilizar para no tener que andar reescribiendo codigo a lo loco

Sobre los atributos, asi enumeradamente:
1. type tenemos tres posibilidades, friend, peer, user, para decidir si hara llamadas, recibira, o ambas. En este caso friend es ambas.
2. En host, dynamic, es un poco una version comoda de decir, que el otro punto que se conecte a asterisk sea el que provea toda la informacion acerca de la conexion
3. Acerca del dtmfmode, tendriamos que hablar del mundo de los Dual Tone Multi Frequency, hay varias opciones, pero la opcion rfc2833 es quiza la mas comun. Hablare en algun momento o quiza cuando llegue mas a la parte de telefonia analogica acerca de los DTMF
4. canreinvite, simplemente especifica, que los telefonos no puedan “reinvitarse” y realizar una comunicacion directa entre ellas sin pasar por asterisk. Esto quiza seria util en sedes remotas, para que pudieran hablar dos extensiones de la misma sede en local. Pero para ello hay mejores opciones aun si cabe que ya veremos en otro momento mas avanzado.
5. Sobre el nat, tiene que ver con las cabeceras del protocolo SIP y la informacion acerca del host que traen. Manteniendolo en no permitimos que estas cabeceras se conserven y se usen.
6. qualifiy sirve para mandar mensajes por el protocolo para confirmar si estan activos los otros puntos. Esto puede generar trafico indeseado en la red, por lo que en sedes remotas, quiza seria interesante desactivarlo
7. pickupgroup y callgroup van en conjunto. Callgroup define un grupo de llamadas dentro de las extensiones. Y pickupgroup define de que callgroup podria ser recogida una llamada con una marcacion especifica definida en otro fichero de configuracion (features.conf se vera mas adelante). En principio nos quedamos con *8 que es el que va por defecto
8. Finalmente el context quiza el atributo mas esencial, hace referencia a que contexto ira a mirar esta extension por defecto dentro del DialPlan (esto requiere mas de un mensaje asi que seguramente sea mañana cuando  escriba el primer DialPlan y una explicacion acerca de este). Dial Plan viene a referirse al plan de marcacion, a “que ocurre” cuando desde un telefono marcamos una combinacion de digitos u otra. Esta es la verdadera programacion del sistema Asterisk

[codecs](!)
disallow=all
allow=gsm
allow=ulaw

Semejante al anterior contexto y bastante explicatorio por si mismo. Bloqueamos todos los codecs y solo damos permiso a los que nos interesan, en este caso el GSM y el ULAW. Conforme voy recorriendo este fichero me voy dando cuenta de la cantidad de cosas que seria interesante explicar en futuros mensajes, porque todo guarda relacion directa con otros fundamentos basicos de la telefonia.

Finalmente los puntos SIP

[ext1000] (extension, codecs)
callerid = “Polycom” <1000>
defaultuser = ext1000
secret = 111111
mailbox = 1000@default

Solo pongo una de ejemplo, porque basicamente el resto son replicas modificando algunos detalles basicos para cada futura extension SIP

Aqui llamamos a las dos plantillas anteriormente creadas, y utilizamos atributos especificos que son:
1. callerid, es el nombre que le aparecera al receptor de la llamada cuando emitamos desde este punto
2. defaultuser y secret son el usuario y contraseña que deberemos utilizar para configurar los puntos SIP
3. mailbox, sera el buzon por defecto para esta extension, para el tema de los buzones de voz.

Y con esto ya tendriamos una configuracion basica preparada para empezar a configurar Terminales, y crear un pequeño DialPlan para cursar llamadas simples entre los mismos.

En la proxima parte seguiremos con mas, explicando acerca de la configuracion de varios tipos de terminales SIP que hemos puesto como ejemplo: Un software para Windows, un software para Linux, otro para un pequeño terminal Android y finalmente un grandioso telefono Polycom que me dieron en el curso.