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.

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.