asterisk mal aterrizaje

Asterisk 13 ya esta apunto de aterrizar

asterisk 13 mal aterrizajeComo viene siendo ya costumbre en este blog en los últimos años, quiero anunciar que ya queda muy poco para que desembarque la nueva versión LTS, Asterisk 13 y esta vez, no viene excesivamente cargada de novedades. Quizá las mas esperadas por muchos van a seguir sin cubrirse. Aquí voy a hacer un breve resumen de que podemos atenernos en los próximos meses:

(Toda la información esta disponible en la wiki oficial)

En primer lugar, como no podía ser menos, vamos a hablar de la novedad estrella: ARI (Asterisk REST Interface)

Por fin podemos realizar llamadas a Asterisk 13 de manera externa, desde un servidor sin necesidad de tener que monitorizar resultados de la antigua Asterisk Manager Interface (que curiosamente también ha sido BASTANTE mejorada, añadiendo nuevos métodos y acciones a la larga lista de ya existentes).

Hay que tener en cuenta que eventualmente se puede hacer el 90% de la funcionalidad alcanzada a través de un dialplan corriente, aplicando este tipo de interfaces (como la AMI), pero todavía falta para poder llegar a cubrir el 100%. Afortunadamente poder cubrir con una interfaz REST dota de muchísima versatilidad al sistema, especialmente considerando que hoy en día, estamos hablando que estos sistemas son más un framework que un sistema standalone (o los famosos Servidores de Aplicaciones IMS). La verdad es que tengo muy descuidado el blog y lo reconozco, pero me apunto para hacer lo antes posible, un breve tutorial sobre el uso del ARI con un ejemplo práctico

Alguna funcionalidad destacable de Asterisk 13

Entre la nueva funcionalidad de Asterisk 13 más de campo tenemos:

  • Se ha mejorado el soporte de chan_dahdi al SS7
  • Se ha mejorado el soporte al nuevo stack SIP pjsip
  • Ahora necesitamos libxml2-dev para el menuselect
  • Voicemail ahora soporta el japones
  • Confbridge sigue evolucionando en detrimento del antiguo Meetme, y Directory sigue vivo
  • Varias aplicaciones como Chanspy ya se benefician del UniqueID
  • Atención también a la nueva especificación de CDR y CEL heredada de la versión estandar Asterisk 12

Finalmente como punto negativo, quiero destacar que no se ha prestado demasiada atención a la compatibilidad de Asterisk con las nuevas tecnologías WebRTC y los últimos cambios presentados por el estandar. Tampoco hay ninguna novedad sobre el soporte de OPUS que habían anunciado que para Asterisk 13 estaría resuelto lo que me resulta un disgusto bastante grande, más considerando que ya tendremos que esperar posiblemente a la próxima LTS Asterisk 15 para poder ver todo esto integrado en condiciones… si es que llega. Sinceramente, creo que se esta dando muchisimas vueltas con respecto al codec OPUS y la violación de las licencias como ellos justifican, realmente no es del todo cierta y habido bastante polémica en las listas al respecto. Veremos como evoluciona en el 2015 este asunto, bajo mi punto de vista, no haber tratado esto con prioridad da la sensación que la llegada de Asterisk 13 con un sistema WebRTC totalmente disfuncional es más bien un aterrizaje forzoso

Si estais interesados en que haga alguna review de algún aspecto en concreto de Asterisk, comentadme y lo voy viendo!

Advanced Asterisk. Days 4 y 5

Ya entrando en la recta final, continuamos con el tema de ayer de conexiones de tarjeteria y PSTN.

Primero van los conceptos teoricos sobre los tipos de sistemas digitales de telefonia Americanos (T1), Europeos (E1), las señalizaciones, los canales, servicios implementados como RDSI (ISDN), codificacion de las señales… realmente son temas que para un caso en concreto de uso hay que tenerlos claros.

Un ejemplo practico seria la interconexion duplex entre una centralita Asterisk y una Alcatel con tarjeteria en ambos lados. Para la comunicación de mensajes a nivel de servicios digitales, se implementa un protocolo de señalización llamado Q.931, pero mas concretamente de un protocolo variante especifico para esta funcionalidad de interconexión de centralitas, llamado Q.SIG.

Ahora vamos a la parte practica de configuracion, hay que considerar que existen dos tipos de configuraciones, la especifica para Estados Unidos y otra para Europa, en este caso voy a intentar de ir planteando las dos, porque cara a Digium la que se utiliza es la EEUU, pero para nuestros casos practicos seguramente sea la Europea.

Configuracion del /etc/dahdi/system.conf

Primero tenemos que configurar cada uno de los puertos

span = <numero_del_puerto>,<fuente_de_sincronizacion>,<line_built_out>,

Ejemplo americano:

span = 1,1,0,esf,b8zs

Ejemplo europeo:

span = 1,1,0,ccs,hdb3,crc4
– El 1 primero, es el numero del canal

– El 1 es para ser receptor de la fuente, y el 0 para ser el emisor
– El siguiente 0, es para no amplificar la señal si los cables son normales, o 1 si son demasiado largos (el cable que nos llega del operador esta en una ubicación muy apartada de donde esta nuestro equipo)
– ESF/CCS, las señalizaciones, americana y europea respectivamente
– B8ZS, y HDB3 son las codificaciones
– Finalmente CRC4, el sistema de control de errores

Luego se configuran, los bchan (canales de datos) y el dchan (canal de señalizacion)

bchan = 1-23
dchan = 24

– En modo americano

bchan = 1-15,17-31

dchan = 16

– En modo europeo

Y luego el loadzone = es/us y defaultzone=es/us es especialmente importante cuando se tratan de tarjetas digitales.

En el fichero /etc/dahdi/modules, hay que levantar el modulo especifico de la tarjeta de T1/E1 llamado wcte12x (primario con 1 puerto T1/E1 o wct4xxp (2 o 4 puertos T1/E1), y si hablamos de puertos BRI seria el modulo wcb4xxp

Finalmente se configura el chan_dahdi.conf muy parecido a las tarjetas analogicas Podemos empezar a amplicar elsistema de “contextos” para este fichero de configuracion.

[channels]

[Primarios]
callerid=asreceived
contexto=llamadas_entrantes
signaling= //Aqui va la configuracion especifica de los primarios, hay opciones como pri_cpe (si recibimos de un operador) o pri_net (si somos los emisores de la señal)
switchtype = //Otro especifico, teoricamente existen multiples tipos de primarios, la red National, la red de AT&T en estados unidos, o la unificada de Europa EuroISDN, los valores posibles, “national”, “euroisdn”, etc. Y en el caso que estemos interconectando dos centralitas, por ejemplo a la Alcatel que hablabamos antes, pues aquí se pone “qsig”
dahdichan=1-23 //los canales de datos que antes configuramos en el system.conf, caso Americano
dahdichan=1-15,17-31 //los canales caso Europeo
group = 1 //esto es practico para no tener que estar definiendo un canal en el extensions.conf para cada canal, se utiliza un “generico” que se aplica al “grupo de canales”, y se define como gX (siendo X el numero del grupo). Para este ejemplo una opcion seria: DAHDI/g1

Ademas un tema importante de los grupos es que se pueden configurar los mecanismos de selección de canal dentro del grupo. Se pueden aplicar distintas tecnicas de selección, como la secuencial empezando por el canal primero, por el final, metodo round-robin, etc. Esto se configura, al configurar el tipo de grupo en el extensions.conf. Antes puse DAHDI/g1, pero podria ser G1, r1 y R1 (la r es el metodo Round Robin)

Una gran diferencia con respecto a las lineas analogicas, es que las llamadas no entran a la extension start del dialplan, sino entran al telefono (DID) al que es llamado por tanto en el dialplan la extension “entrante” se define con el numero del DID

Ejemplos:

exten => 919191919,1,Dial(SIP/mitelefono)

exten => 929292929,1,Dial(SIP/tutelefono)

Pero esto ya lo vimos cuando trabajabamos con el Gateway de puertos BRI, Epygi, que tenia un mecanismo muy similar aunque se configurara externamente.

– Fax en Asterisk

A raiz de la version 1.8 mejoro bastante el soporte “nativo” para FAX con respecto a las versiones anteriores, tanto a nivel Passthrough por el protocolo T.38, como utilizando la maquina Asterisk como gestora de FAX. Pero realmente para esto segundo, el soporte de FAX por Asterisk es limitado o de pago si queremos utilizarlo en produccion. Aquí hay una explicacion detallada del tema

En nuestro caso ya explicamos como tener un sistema completo y libre utilizando Hylafax con el IAXModem bastante efectivo. A raiz del mensaje de Enesoluciones (ahora Fundacion Guadalux) pense que el sistema nuevo de Asterisk sustituiria el Hylafax brutalmente, pero parece que no va a ser asi de momento,por el tema este de las licencias de pago que hablaba (aunque al parecer Digium ofrece una unica licencia gratuita para solo 1 llamada concurrente, que seguramente en muchas instalaciones para PYMES sea suficiente).

– Asterisk Database (AstDB)

Asterisk implementa un sistema de bases de datos muy sencillo para almacenar informacion relativamente poco compleja. Es mas comodo que tener que andar trabajando con conectores ODBC y demas historias siempre y cuando busquemos aplicaciones concretas donde haga falta almacenar valores y acceder a ellos facilmente, pero especificamente del propio sistema de configuracion de Asterisk (ejemplo las Listas Negras de llamantes, familia blacklist)

Las funciones de lectura y escritura son extremadamente sencillas (totalmente integradas en el sistema Asterisk). Basicamente son usos de la aplicación Set y manejo de variables pero con la funcion DB() cubriendo esta nueva “variable”.

La variable esta compuesta por familia/clave/valor por ejemplo users/mitelefono/SIP/mitelefono

En este caso la clave mitelefono dentro de la familia, users, tendra el valor SIP/mitelefono (que por ejemplo es el canal SIP que utiliza nuestro telefono SIP).

Ejemplos:

Asignar a un registro de la base de datos: Set(DB(users/mitelefono)=’SIP/mitelefono’)

Consultar el registro: ${DB(users/mitelefono)}

Con todo esto parece que podemos “recortar” en variables globales dentro de los ficheros de configuracion basicamente. A lo mejor seria interesante montar algo serio que utilice esto a mayor escala como lo que comentaba esto de los Blacklist, aunque realmente tampoco tendra mucho misterio, algunas lineas. Me lo apunto como futura practica.

– Ultimo dia. 5: Seguridad en Asterisk

Para finalizar, y dar cierre al Asteirsk Advanced, el ultimo dia se trataron multiples temas relacionados con la seguridad en Asterisk

Sobre este tema tengo que hacer un comentario: justamente, ahora que estoy bastante desconectado del mundo “tecnologico” a nivel profesional, no tengo tanto acceso como antes a tarjeterias, equipos de trabajo y demas historias que me hacian el mundo facil en el progreso Asterisk.  Pero concretamente acerca de la seguridad en Asterisk, supuestamente el sistema mas “peligroso” en el que montar un Asterisk es abierto a Internet. Por ello en las proximas entradas, voy a estar focalizando en esta idea, ya que mi forma de “progresar” de ahora en adelante va a ser montando una maquina Asterisk en Casa y ofreciendo servicios concretos a individuales, a mi empresa (de forma altruista) y a otras empresa que quiza pudieran interesarme por el potencial (¿patrocinio o algo asi?) que pudieran ofrecerme (especialmente por los recursos economicos que pudieran aportar al tema).

El tema de seguridad en Asterisk tomaba dos perspectivas: el tipo de securizacion que habia que tomar en consideracion por niveles de “inseguridad” (desde el montaje de una maquina aislada de la red, hasta el montaje de una maquina publicado a internet), y por otro lado, todos la securizacion de todos los componentes del sistema (desde los accesos a la propia maquina hardware, pasando por el sistema operativo, hasta el mismo dialplan).

– Conclusiones y Consideraciones Finales sobre el Curso

Como comentaba el segundo dia debo determinar y concluir que el curso ha satisfecho mis expectativas, ya que realmente el interes de hacer un curso de este calibre, no ha suele ser tanto, la cantidad de informacion recibida, sino la posibilidad de “expandir” conceptos acerca de la especialidad en concreto que viene a tratarse, a traves de los profesores y los compañeros. Hay que considerar que el precio realmente no cubre solo las horas de enseñanza, sino tambien las horas de “relacion”. Es cierto que para “conectar” con otros individuales especialistas o no especialistas en un sector, no es realmente necesario hacer un curso, y que para el aprendizaje por ese precio se podrian llegar a conseguir incluso, horas de enseñanza particulares por internet pactando con algun profesional un precio por hora (algun dCAP) sin excesiva dificultad. Pero mas alla de estas dos posibilidades, y la primera en particular, tambien hay que considerar que el perfil de alumno que va a un curso de este tipo, no suele ser de “Lurker” ya que al costar (bastante) dinero, suelen ser o aportes profesionales (empresas que quieren formar a sus trabajadores especialistas), o aportes personales (autonomos o como yo esta vez, especialmente interesados en el sector).

Proxima parada: Examen dCAP. No se donde sera, pero desde hoy ya toca empezar a practicar y estudiar como el que mas. Segun parece, por los alumnos que se presentaron, el nivel del examen practico ha aumentado a practicamente al doble de dificultad que las ultimas convocatorias, y sobre el teorico no pude enterarme, ya que tuvimos que irnos a comer porque el examen se alargaba demasiado.

Asterisk Advanced. Day 3

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

– Teoría de Macros en el DialPlan

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

Dos conceptos basicos

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

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

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

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

Ejemplo:

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

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

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

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

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

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

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

– Asterisk Realtime

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

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

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

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

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

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

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

Ahora sobre la configuración los ficheros involucrados

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

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

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

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

En el ejemplo que estamos siguiendo:

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

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

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

Y finalmente /etc/odbcinst.ini

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

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

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

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

– CDR y CEL

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

– El mundo de las Tarjetas Analogicas

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

Algunos conceptos novedosos y no vistos hasta la fecha:

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

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

Ejemplo:

[channnels]
usecallerid = yes
transfer = yes

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

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

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

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

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

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

Asterisk Advanced. Day 2

Pasado el primer dia “introductorio” se empiezan a ver conceptos y aplicaciones mas interesantes para nuestro sistema Asterisk. Una de las conclusiones que he sacado en favor del curso, algo que personalmente me suele costar bastante sacar de la mayoria de los cursos que he ido, es que la verdadera utilidad del curso no reside en el material que puedes encontrar en cualquier pagina medianamente buena que trate sobre asterisk como www.voip-info.org, sino realmente en la cantidad de aplicaciones practicas que surgen a raiz de la experiencia del profesor, y tambien de los compañeros del curso.

Realmente Asterisk, exceptuando la idea basica de una centralita, o del concepto generico de “quiero montar un callcenter” o “quiero montar una centralita para mi empresa”, sin ideas practicas de calidad, es totalmente inutil. Pero es cuando las ideas empiezan a ebuillar cuando se pueden empezar a pensar en infinidad de aplicaciones para la vida diaria que pueden resultar extremadamente utiles.

Por eso mas que escribir sobre teoria que se ha visto, y puede consultarse como dije, en VoipInfo, voy a comentar algunas que fueron surgiendo:

– Sistemas de Monitorizacion de llamadas

Seguramente todo buen conocedor de Asterisk (que no es mi caso) sepa, que existen aplicaciones para la grabacion de llamadas. Pero ya que el canal de llamadas puede ser “escuchado” para ser grabado en un fichero de audio, tambien podria ser “escuchado” en tiempo Real. Ahi es donde entran las aplicaciones “Espias” como ExtenSpy y ChanSpy. Dos aplicaciones muy faciles de utilizar en un dialplan:

exten => 100,1,Answer()
exten => 100,n,ChanSpy()
exten => 100,n,Hangup ()

Y simplemente accediendo a la extension 100, tenemos “barra libre” para escuchar todos las conversaciones en el canal SIP de nuestra maquina Asterisk pasando de una a otra desde el telefono a traves del boton “*”

– Generacion de llamadas Automaticas

Por otro lado, algo tambien muy interesante, es la posibilidad de generar llamadas automaticas a traves de un fichero de “llamada” que se introduce en un directorio que esta siendo constantemente “monitorizado” por un demonio de Asterisk que lo ejecuta, y procesa los comandos de la llamada.

Esto por ejemplo puede ser util, a traves de un script autoejecutado en el arranque del sistema, cuyo procedimiento sea, si por ejemplo se cae un servicio critico del servidor, y tenemos instalado un minimo asterisk en ese servidor al que hemos conectado una extension SIP nuestra para alertas, hacemos que cree un fichero de llamada a medida y lo movemos al directorio que comentaba antes ( el directorio exacto es /var/spool/asterisk/outgoing). En este caso, lo que haria seria generar la llamada a nuestra extension alertandonos que el servicio se cayo. Muy practico porque eventualmente todos sabemos que el telefono suele ser de prioridad nivel maxima mientras que el correo electronico (como aplicaciones tipo Nagios que generan y envian correos de alerta), suele ser de prioridad media o medio baja dependiendo el caso. O perfectamente podriamos combinar sistemas como Nagios y Asterisk para diseñar un sistema de alertas mediante mensajes de voz a un telefono provenientes del servidor.

El formato de estos ficheros de llamada es muy sencillo. Un fichero de texto con los posibles siguientes comandos:

Channel: SIP/mi_telefono //El canal a traves del que se cursara la llamada
Application: Playback //Queremos que ejecute la aplicacion Playback para reproducir un mensaje automatico a voluntad
Data: windows-server-caido //El fichero de audio que vamos a lanzar con la aplicacion Playback, en este caso tiene que encontrarse en el correspondiente directorio de sonidos de Asterisk en un formato permitido para su reproduccion por ejemplo windows-server-caido.wav
Codecs: g729, ulaw, gsm // Codecs permitidos por el canal
MaxRetries: 3 // Numero de intentos que se tratara de realizar la accion con exito

– Edicion y personalizacion del Features.conf

Por otro lado, tambien hoy se vio el fichero de configuracion, features.conf, en el que basicamente se definen la utilidad de las pulsaciones de botones DMTF y como seran interpretados por las aplicaciones que conllevan especialmente servicios de llamada como Dial y Queues.

Basicamente ya es sabido que existen en ese fichero una serie de definicios por defecto para realizar “Features” (Caracteristicas) como la transferencia de llamadas, el Parking de llamadas, etc, que quiza comente mas en detalle en un futuro.

Pero siguiendo con la linea practica, un ejemplo que se probo en la clase, fue la posibilidad de crear “Features” a medida, como por ejemplo, mapear dos combinaciones de teclas para subir y bajar el Pitch del canal de audio (para los entendidos en efectos de sonido, es la escala de frecuencia). Esto quiere decir que por ejemplo si tenemos a un operador en la oficina que tiene una voz muy aguda, y queremos dotarle de una voz mas grave sin tener que prescindir de esta persona para llamadas determinadas, le podemos configurar en su telefono la posibilidad de bajar 4 o 5 puntos el nivel de frecuencia, y sonaria tal y como deseamos para el receptor de la llamada. Asunto resuelto, ya tenemos un locutor de radio instantaneo a coste 0.

¿Como se consigue este efecto?

Primero en features.conf bajo el contexto [applicationmap] definimos algo asi:

pitchUp => #1,self/both,Set(PITCH_SHIFT(both)=high)
pitchDown => #2,self/both,Set(PITCH_SHIFT(both)=low)

Con esto decimos que para conseguir alcanzar la caracteristicas “pitchUp” pulsando almohadilla + 1 subimos la frecuencia (tonalidades agudas) y al pulsar # + 2 bajamos la frecuencia (tonalidades graves)

Ahora para que esto sea aplicable a una aplicacion de llamada, es necesario modificar una variable general de Asterisk llamada __DYNAMIC_FEATURES (atencion a las dos _ del comienzo de la variable).

exten => 100,1,Set(__DYNAMIC_FEATURES=pitchUp#pitchDown)
exten => 100,n,Dial(SIP/mitelefono)
exten => 100,n,Hangup()

Ahora al llamar a la extension 100 y contactar con ese canal ahi definido, ambos interlocutores de la conversacion podran manipular su voz pulsando las combinaciones de teclas anteriormente descritas. Todo un lujo de goce y disfrute para la conversacion.

– Importante Novedad de la version 1.8 de Asterisk

Finalmente para terminar, aun a sabiendas que me quedan mil cosas en el tintero que podria escribir, quiero comentar algo nuevo que ha surgido en las ultimas versiones de Asterisk y SIMPLIFICA los Dialplans una burrada.

Hablo de “SAME”. Esto simplamente permite el hecho de poder obviar el exten => junto al numero de extension que vamos repitiendo en un flujo de llamada para una extension concreta

Antes:

exten => _6XX32XZ1X,1,NoOp()
exten =>  _6XX32XZ1X,n,Dial(${Troncal}/${EXTEN})
exten => _6XX32XZ1X,n,Hangup

Ahora:

exten => _6XX32XZ1X,1,NoOp()
same => n,Dial(${Troncal}/${EXTEN})
same => n,Hangup

Definitivamente MUY comodo. Gracias al iluminado por implementar esta mejora.

Eso es todo por hoy, mañana espero, mucho mas.

Asterisk Advanced. Day 1

Primer dia del Asterisk Advanced. Se han visto por lo general temas basicos introductorios del sistema. Todo aquel que hubiera realizado un Fast Start, puede sobrellevar este dia sin despeinarse. Muchos conceptos teoricos sobre Asterisk, curiosidades, producto Digium y alguna terminologia basica en lo referente al protocolo SIP. Nada que merezca por mi parte la pena destacar.

Configurar una extension, un pequeño IVR (como ya hemos visto en anteriores entradas de este blog), y una comunicacion con un proveedor SIP. Me hubiera gustando poder volver a escribir un buen articulo en representacion al dia de hoy, pero no hay suficiente material interesante, que no haya sido visto hasta la fecha.

Solo una cosa tengo que reconocer. Estos meses de inactividad me han hecho olvidar gran parte del sistema de configuracion, y porque no decirlo, esta clase me ha servido para poner un poco al dia mi actividad mental asteriskera, para volver un poco a la carga.

Seguiremos informando!

Volviendo a Asterisk casi 1 Año despues

Mucho ha llovido (no tanto en realidad) desde la ultima vez que publique algo en este Blog. Pensaba que seria mas costante y no dejaria de publicar cosas a lo largo del tiempo, pero se ve que los avatares de la vida te obligan a tener que dejar cosas de lado como esta por muy interesantes que resulten.

El tema es que mañana, 14 de noviembre, empieza el curso en Malaga Asterisk Advanced y se me ocurrio la genial idea de apuntarme para volver a coger el ritmo. Ya por entonces cuando empezaba mi andadura, el evento que motivo mi “carrera asteriskera” fue el curso Fast Start (que publicidad a Avanzada 7 mas desmedida!) pero ahora, creo que ya ha llegado el momento de empezar a tomar un curso mas serio, y empezar a plantear una alternativa “profesional” con vistas puestas en el certificado Digium CAP (dCAP). Esta vez no voy a hacer el examen porque no tengo muy claro que vaya a aprobar mas sabiendo que hace mucho tiempo que no toco una maquina Asterisk.

Pero esperemos que este curso ya me sirva de lanzadera para llegar al siguiente objetivo. Por ahora tratare de ir resumiendo los proximos 5 dias de mi andadura por el curso (alerta SGAE!) por si pudieran servir de experiencia para cualquiera que como yo quiera plantearse dar el paso a alcanzar el dCAP.

Conectandonos al mundo Real: El planeta Gateway II

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

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

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

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

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

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

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

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

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

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

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

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

–          Usuario Basico

–          Usuario Avanzado

–          Administrador Basico

–          Administrador Avanzado

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

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

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

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

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

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

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

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

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

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

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

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

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

Introduciendo un Proveedor SIP: Parte 2

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

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

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

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

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

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

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

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

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

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

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

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

Una Nueva Maquina para el Sistema

Por razones de la vida, he encontrado una maquina HP Proliant ML 110 de Cuarta Generacion (G4), abandonada en una de las instalaciones. Realmente no estaba abandonada, pero estaba siendo infrautilizada, asi que he decidido tomarla prestada, para cambiarla por el servidor que actualmente estoy utilizando, que es parecido, pero no es HP.

Realmente este servidor no trae nada especial, ya que en realidad la serie ML110 vienen a ser Workstations con procesadores de Servidor, y en este caso una placa que soporta hasta 8GB de memoria ECC DDR2. De igual forma como de momento no estoy llevando el servidor a niveles de produccion, he preferido instalarle buena cantidad de memoria no-ECC para que resulten las cosas como corresponden, ya que originalmente solo traia un modulo de 512Mb DDR2 PC5300 ECC que aunque sea Linux, ya no me convence esta cantidad demasiado para ninguna labor de hoy en dia. He montado 2 memorias de 2Gb DDR2 PC6400 no-ECC en Doble Canal. El resto por defecto de fabrica. Llegado el momento, aqui tambien montare la Tarjeta Digium que envie el otro dia en Garantia ya que posee varios slots  PCI, mas que el PC-Workstation que estaba utilizando con anterioridad (y quiza en un futuro tambien poder montar alegremente la tarjeta de Primario para las pruebas correspondientes)

Este mensaje realmente lo escribo como una primera aproximacion de lo que seria una rapida migracion de sistema, para demostrarme a mi mismo, que aun bajo una caida de mi centralita, la reposicion seria cuestion de minutos/horas desde mi atencion.

En primer lugar, instalo Ubuntu Server, monto el sistema RAID con mdadm y LVM2 encima en tres particiones tal y como se explico en el mensaje:
http://www.10000horas.com/2010/08/08/primer-sistema-base-ubuntu-server-y-md-raid/

En segundo lugar, la instalacion del Sistema Asterisk, paso facil y bastante “automatizado” de momento:
http://www.10000horas.com/2010/08/09/manos-a-la-obra-con-asterisk/

En tercer lugar, en el servidor antiguo simplemente copio los directorios que han incurrido en posibles modificaciones (realmente son unos pocos ficheros, pero me gustaria conservar todos los pequeños cambios y no quiero que se me olvide nada). En modo super usuario en el servidor antiguo:

# cd etc
# tar -cf asterisk.tar asterisk/
# scp asterisk.tar ipdelnuevoservidor:/tmp/
# tar -cf dahdi.tar dahdi/
# scp dahdi.tar ipdelnuevoservidor:/tmp/

NOTA (26/10/2010): Tras ampliar mi abanico de conocimientos he observado que se requieren mas carpetas para migrar el sistema completo. La verdad es que no me lei a fondo la documentacion con respecto a los directorios que utiliza el sistema Asterisk por defecto.

El comando “magico” (agradecimientos a Elio Riojano) para conseguir un backup completo de asterisk: tar cvfj asterisk-backup-`date +%Y%m%d-%H%M%S`.tgz /etc/asterisk /var/lib/asterisk /var/spool/asterisk /etc/dahdi
Seguramente se pueda completar aun mas, pero para mis propositos actuales, me sobra y me basta.

Finalmente, copiamos estos ficheros de nuevo a nuestro directorio /etc del nuevo servidor Asterisk. Aqui voy a dar algunos pasos innecesarios realmente, pero que podrian ser utiles y no son dañinos realmente

# cd /etc
# mv /tmp/asterisk.tar /etc/
# mv /tmp/dahdi.tar /etc/
# mv asterisk/ asterisk.old/ (opcional)
# mv dahdi/ dahdi.old/  (opcional)
# tar -xf dahdi.tar
# tar -xf asterisk.tar

Ahora ya tenemos configurado el sistema tal y como lo teníamos antes. Probamos si funciona y si esta todo correcto, podriamos borrar esos directorios .old o mantenerlos por si necesitamos mirar algo (aunque en teoria para eso esta el directorios de ejemplos (samples) que creamos durante la compilacion, asi que estos datos dejarlos ahi seria innecesario realmente).

Finalmente y opcional hasta este punto, copiar las grabaciones que hicimos (si son de calidad, no es mi caso en este momento)

# tar -cf sounds.tar /var/lib/asterisk/sounds/
# scp sounds.tar ipdelnuevoservidor:/tmp/

Y luego justo al reves, copiamos de tmp a sounds en nuestro nuevo servidor, exactamente igual que hicimos antes con las configuraciones

Hacemos algunas llamadas de pruebas, tanteamos nuestro servidor SIP externo, y en teoria ya deberia estar todo funcionando.

Tiempo estimado total: 2 horas, de las cuales 1 hora y media son desatendidas entre instalaciones y compilaciones.

La verdad que con esta gestion he conseguido autodesmitificarme que la migracion ante una posible incidencia grave, resulta verdaderamente sencilla. Y en este caso ya hemos identificado tres directorios que seriainteresante tenerlos en una rutina de backup eventual para poder reestablecer el sistema en caso de tener problemas, quiza con cron. Ya veremos resumidamente algunas rutinas basicas con cron, para establecer entre otras cosas, actualizaciones de sincronizacion de hora efectivas, y como aqui planteado, backups automaticos.

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 🙂