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.

Introduciendo un Proveedor SIP: Parte 1

Tras el duro combate sufrido estos ultimos dias con la tarjeta TDM410P, al final resulto no funcionar tampoco el modulo FXO asi que decidi tramitar la tarjeta en Garantia y que resultase lo que fuera.

Pero esto no ha impedido que siga trabajando por otra corriente. Esta vez, seguimos con el mundo SIP, y en este caso utilizando un llamado “SIP Trunk”, o lo que realmente viene a ser, un proveedor SIP de VoIP para llamar a la red PSTN y GSM a traves del mismo, con las extensiones de nuestra centralita Asterisk.

En este caso, lo que realmente me resulto algo complejo fue la eleccion del proveedor en cuestion. Tras analizar varios, conclui que el precio estaba estrictamente relacionado a la calidad del servicio. Por ejemplo, uno de los proveedores mas famosos, VozTelecom, tiene un servidor SIP ubicado en la direccion voztele.com. Desde mi servidor obtengo una latencia de entre 25-30ms, una latencia extraordinaria. Pero el coste de la llamada a fijos nacionales para estas fechas en la que estoy escribiendo este mensaje, es de 2 centimos/minuto, una tarifa un 25% mas alta que cualquier otro proveedor que ronda los 1,5 centimos/minuto.

Pero no solo estaba interesado en el servicio de llamadas externas, sino lo que verdaderamente me interesaba era el servicio de llamadas Entrantes. El coste de un DDI (Numero Geografico Nacional) segun la pagina web, es de 4 euros, no esta nada mal desde luego, pero combinado con el otro precio saliente no me resulto demasiado atractivo.

Luego di con otros operadores varios nacionales, ADAM, Telsome, … hasta al final encontrar uno ubicado en Malaga llamado Netelip con tarifas bastante competitivas. El principal problema: Una latencia media de unos 80ms, comparado con VozTelecom, bastante mala latencia. Pero eventualmente el coste por minuto era relativamente barato y el DDI se podia conseguir desde 2 euros un numero geografico virtual (que comieza por 851 pero al llamante le tarifica como una llamada nacional cualquiera). Los numeros geograficos provinciales si resultaban mas caros, y encima no ofrecian numeros de este tipo para mi provincia. Tampoco me importaba gran cosa, y con el DDI 851 podria ir tirando para realizar las primeras pruebas.

Ahora ya elegido el proveedor, tocaba configurarlo en mi central.

Por un lado como es corriente, lo primero seria configurar el chan sip desde el fichero sip.conf

En el contexto general creamos una regla para registrar el servidor SIP en nuestro sistema con las credenciales ofrecidas por el Operador IP:

[general]
register => usuario_del_proveedor_ip:contraseña_del_proveedor@direccion_del_proveedor/ddi
Ejemplo
register => sirlouen:1234@sip.netelip.com/851123456
Por otro lado necesitariamos crear un contexto para la informacion especifica de este “dispositivo virtual” SIP, la mayoria de los atributos ya los vimos el otro dia en el otro mensaje sobre SIP
[netelip]
type=friend
username=sirlouen
context=operadorip
host=sip.netelip.com
canreinvite=no
secret=1234
nat = yes
fromdomain=sip.netelip.com
disallow=all
allow=alaw
dtmfmode=inband
insecure=port,invite
fromuser=sirlouen
Lo unico asi en detalle, comentar que es necesario que sea de tipo friend por el hecho que debe recibir y enviar llamadas.
Tambien el parametro nat, debe ser yes por el hecho de que en este caso salimos por el Router para este peer.
En este caso los codecs y el dtmfmode son muy importantes ya que van a definir la calidad de la conexion de voz sobre Internet, que ya de por si tiene un gran handicap comparado a la comunicacion via red local. He elegido el codec alaw que no es que sea grandioso, y seguramente deberia cambiarlo proximamente, ya que la tasa de transferencia es bastante elevada, del orden de los 80kb/s incluyendo las cabeceras… una verdadera burrada, aun con calidad, para trabajar en el mundo de internet.
Por otro lado, el dtmfmode es muy sensible ya que al no trabajar en local, los tonos se confunden facilmente. Habia probado con el modo rfc2833 igual que en local, pero tuve problemas con la marcacion, por ejemplo del numero 1, ya que en la consola podia ver como trataba de transferirme con la regla del dialplan “11” (como dos marcaciones del 1). Tambien probe con el modo info que no es demasiado util en este caso. Al final con inband es con el modo que mejores resultados he conseguido. Tambien quiero comentar, que en el contexto general, puse el atributo “relaxdtmf=yes” que ayuda a que las marcaciones dtmf no sean tran estrictas, y que trate de interpretar la marcacion lo mejor que pueda aunque no tenga demasiada calidad.
Finalmente el atributo insecure=port,invite es una configuracion muy tipica en estos casos, ignora el puerto de entrada y tampoco pide invitacion del mensaje INVITE (mensajes que se trasmiten durante la comunicacion convencional)

Con esto ya quedaria totalmente configurado el peer netelip.

Ya solo quedaria montar las reglas dentro del DialPlan (extensions.conf) para marcacion de tipo nacional, movil a traves de este Proveedor IP y por otro lado, definir el contexto que puse antes “operadorip” para el reconocimiento de las llamadas entrantes, y su manipulacion.

Para esto aprovechare para introducir algunos temas nuevos del DialPlan asi como la creacion de un pequeño IVR (Contestador Automatico, Interactive Voice Response), en otro mensaje proximamente.

Estad atentos 🙂