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 🙂

Combate Analogico: Primer Asalto

En estos dias, como ya adelante, he estado tratando de integrar la telefonia Analogica en la centralita de pruebas.

Para ello he utilizado la tarjeta que me ofrecieron en el curso, la Digium TDM410P y que nunca se llego a probar por problemas de tiempo (solo se explico por encima la idea de configuracion y varios de los atributos mas comunes).  Esta tarjeta trae dos modulos, uno Verde (FXS para conectar un telefono por ejemplo analogico) y una FXO (para conectar una fuente, una linea analogica de la PSTN, una extension de una centralita)

Como introduccion, comentar que en Asterisk, el mundo analogico se integra a traves de los modulos Dahdi, Dahdi-Linux-Complete fue el paquete que instale y que estaba compuesto por dos subpaquetes como comente en su dia

Por otro lado, hay que saber que Dahdi digamos que tiene dos formas de comunicacion: Una directamente con el sistema, con el Kernel de Linux, añadiendo los modulos y drivers de las tarjetas, y la configuracion especifica. La carga de modulos se especifica en el fichero /etc/dahdi/modules y los parametros de configuracion de las tarjetas en el Kernel en el fichero /etc/dahdi/system.conf

Concretamente en el fichero modules, el modulo que nos interesa seria el correspondiente a las tarjetas TDM410P, el wctdm24xxp. El resto los podriamos eliminar porque no vamos a usarlos eventualmente

Para la configuracion de la tarjeta, en el fichero system.conf  he utilizado lo siguiente, comentado, la explicacion sobre cada elemento:

# Puerto 1 tarjeta Analogica = Modulo FXS VERDE
fxoks=1
# Puerto 4 tarjeta Analogica = Modulo FXO ROJO
fxsks=4
loadzone=es
defaultzone=es
# Canceladores de Eco Software
echocanceller=mg2,1
echocanceller=mg2,4

Por otro lado, seria necesaria la configuracion del fichero que “intercomunica” los modulos de la tarjeta con nuestro sistema Asterisk. Esto se registra en el fichero /etc/asterisk/chan_dahdi.conf (Canal Dahdi, equivalente en este caso al Canal SIP que vimos con anterioridad).

Pero antes de esto estuve investigando a ver si realmente la tarjeta estaba totalmente operativa. Hay un comando, dahdi_tools que muestra el estado de la tarjeta y de sus modulos por encima, y pude observar como aparecia la Wildcard TDM410 correctamente.

Pero por otro lado, observe que conectando un telefono al puerto FXS, este no recibia ningun tipo de corriente. Entonces cai en la cuenta que era necesario aportarle corriente a la tarjeta TDM a traves de un conector Molex que integra la placa. Asi, hice la conexion oportuna y volvi a arrancar el sistema.

Y aqui empezó lo malo del dia: el telefono seguia sin recibir corriente. Dos de los LEDS de la tarjeta parecian encendidos indicando, que los modulos estaban operativos. Investigando un poco en los mensajes del Kernel durante el inicio (Comando: dmesg) encontre la siguiente Salida en relacion a la tarjeta

dahdi: Telephony Interface Registered on major 196
dahdi: Version: 2.3.0.1
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
wctdm24xxp 0000:05:08.0: PCI INT A -> Link[APC3] -> GSI 18 (level,
low) -> IRQ 18
wctdm24xxp 0000:05:08.0: ProSLIC on module 0 failed to powerup within
510 ms (0 mV only)
— DID YOU REMEMBER TO PLUG IN THE HD POWER CABLE TO THE TDM CARD??
wctdm24xxp 0000:05:08.0: Unable to do INITIAL ProSLIC powerup on
module 0
wctdm24xxp 0000:05:08.0: ProSLIC on module 0 failed to powerup within
510 ms (0 mV only)
— DID YOU REMEMBER TO PLUG IN THE HD POWER CABLE TO THE TDM CARD??
wctdm24xxp 0000:05:08.0: Unable to do INITIAL ProSLIC powerup on
module 0
wctdm24xxp 0000:05:08.0: Port 1: FAILED FXS (FCC)
wctdm24xxp 0000:05:08.0: Port 2: Not installed
wctdm24xxp 0000:05:08.0: Port 3: Not installed
wctdm24xxp 0000:05:08.0: Port 4: Installed — AUTO FXO (FCC mode)

Aqui pude obsevar como exactamente, el puerto FXS no estaba recibiendo corriente. Investigando por el mundo Google, encontre, que podia ser causa de problemas en el conector Molex, que no estuviera recibiendo la corriente adecuada. Tenia yo la sensacion que esto no iba a ser cierto, ya que en esa misma maquina, otros Molex en otros dipositivos estaban funcionando perfectamente, y al conectar esos mismos Molex en la tarjeta seguian dando el mismo error.

Ademas para no desistir en el intento, probe varias combinaciones en los canales de la tarjeta, con los modulos, poniendo el FXS en practicamente los 4 canales, y lo mismo el FXO. El FXO daba el simbolo de correcto mientras que el FXS en todos los slots daba el mismo error.

Aun asi, todavia quedaban pruebas. Necesitaba comprobar que en el conector macho de la tarjeta, se estaba recibiendo la corriente necesaria para su fucionamiento (12V). Asi que me hice con un voltimetro para comprobar que efectivamente lo recibia perfectamente como se puede observar en las fotos siguientes:

Siguiendo en la insistencia, podia ser un problema (que dudaba en grandisima consideracion vista la ultima prueba), de falta de potencia de la fuente de alimentacion. Pero no queria desistir, y necesitaba -probarlo- todo. Asi que busque una fuente con 100W adicionales (la que hay montada es una Levicom 85+ Bronze de 350W que estoy seguro que le sobra potencia a patadas). Me hice con una fuente de 460W la conecte al equipo como puede observarse en la foto siguiente, y haciendo la misma prueba con el voltimetro que antes, se podia observar que llegaba la corriente adecuada:

Por esto, y en conclusion, me doy por vencido en este primer Asalto ya que no he conseguido configurar un Telefono Analogico a la centralita.

Proximamente, intentare configurar el Puerto FXO que parece ser que si funciona, para recibir como entrada una linea analogica que proviene de una centralita. De alguna forma quiero tratar de integrar esa centralita a traves de una de sus extensiones, con mi Centralita Asterisk, para ver si puedo emitir llamadas a otras extensiones de esa centralita, y ver si puedo recibir llamadas que vengan de esa centralita, en mi sistema y tratarlas, quien sabe, con una mini-operadora de pruebas.

Ademas esta prueba, me servira para comprobar si la tarjeta Digium esta en buenas condiciones, y plantear tramitar en Garantia el pequeño modulo verde FXS que estos problemas me ha dado.

Si se os ocurre cualquier idea que no haya probado aun, con el modulo FXS y que quiza se me haya escapado y pueda resolver mi problema, no dudeis en comentarlo, seria ampliamente agradecido por mi parte.

El dia del Protocolo SIP: Parte 2

Tras el pasado dia haciendo las configuraciones en el archivo de configuracion sip.conf del SIP CHAN ahora procedemos a conectar al sevidor Asterisk los 4 elementos que comentabamos.

En primer lugar, el gran telefono IP Polycom SoundPoint 331, segun el documento de TFOT comenta que la configuracion via administrador web resulta compleja, pero a mi no me lo parecio tanto.

Realmente solo tenemos que configurar con la interfaz del propio telefono, la direccion IP, y los parametros basicos de conexion TCP/IP. Acto seguido conectamos al telefono a traves de su interfaz web con la IP que le hayamos asignado (es conveniente que fuera estatica por si en un futuro necesitamos gestionarlo, o en otro caso asignarle un hostname y poder gestionarlo con nuestro DNS).

Los parametros de acceso por defecto en este tipo de telefonos Polycom son: Usuario “Polycom” y contraseña “456”. Es un poco innecesario que cuente como configure el telefono puesto que hay muchos telefonos diferentes SIP. Voy a comentar la idea en general, y luego nos servira para configurar los otros terminales disponibles.

Primero hay que configurar los parametros SIP. En este caso suelen ser el Outbound Proxy y el Dominio de conexion que son la direccion Ip de nuestro servidor Asterisk, asi mismo como el Puerto que suele ser el 5060 a no ser que por motivos de seguridad hayamos decidido cambiarlo.

Tambien en este caso en el telefono Polycom hay que configurarle las lineas que ofrece, se podrian configurar dos servidores diferentes, con los datos de conexion SIP, es decir el nombre de usuario y contraseña que especificamos antes en el fichero sip.conf y el servidor Asterisk con su puerto correspondiente. Tambien existe una opcion en el Polycom de intercambiar la tecla del segundo servidor (linea 2) para prepararlo como acceso directo al buzon de voz, o incluso otras funciones (Aunque la tecla auxiliar pone “Messages” esta pensado para esto).

En segundo lugar voy adelante con la configuración de un cliente SIP para Linux. En este caso el cliente por defecto que trae el sistema Gnome es Ekiga. Tampoco posee grandes funcionalidades, pero es suficiente como para establecer una conexion SIP a nuestro servidor Asterisk, y su configuracion resulta a priori, extremadamente sencilla. Una nota curiosa que nos comentaron durante el curso en relacion al Ekiga utilizandolo (caso extraño), en el propio servidor donde esta instalada la maquina Asterisk, es que por defecto, realiza la escucha en el Puerto 5060, justamente el mismo puerto SIP que utiliza Asterisk como escucha. Esto provoca una pequeña incompatibilidad que es necesario cambiar, forzando el cambio sea al sistema Asterisk (en el contexto general del sip.conf que comentamos el otro dia, el atributo port=), o cambiandolo en las configuraciones de gnome (comando: gconftool-2 -t integer -s /apps/ekiga/protocols/sip/listen_port 5070).

La cuenta SIP se configura desde Edit > Accounts >> Add.
En nombre ponemos lo que queramos
Protocolo: SIP
Registrar: IP del servidor Asterisk
User: Usuario que hayamos asignado a la extension que deseamos configurar
Password: La contraseña que asignamos

Asimismo resulta sencillo configurar otros softphone para otros sistemas como Windows, el elegido SJ-Phone. Se puede descargar desde la web: http://www.sjlabs.com/sjp.html

Tambien existe un completo manual para Windows: http://www.sjphone.org/doc/SJphone_User_Guide.pdf

Considerar que este softphone tambien sirve para otros sistemas tipo Windows Mobile (Windows CE) y la configuracion resulta igual de sencilla.

En la opciones del programa, la pestaña Profiles (Perfiles), Agregamos uno nuevo del tipo Calls through SIP Proxy. Ahi realmente hace falta configurar poco para que funcione. En Initialization, es interesante picar todas las tres cajas de las dos primeras opciones (Account y PassworD). En la pestaña SIP Proxy solo hace falta rellenar en la mayoria de los casos Domain/Realm con nuestro servidor Asterisk, y opcionalmente el puerto con el formato IP:Puerto. Acto seguido, al guardar la configuracion, e intentar conectar, un cuadro de dialogo aparecera solicitando usuario y contraseña. Aqui es cuando nos validamos con el usuario y la contraseña de la extension configurada en el sip.conf a la que pretendemos acceder.

Finalmente el ejemplo de configuracion de un softphone para Android, el elegido, el famoso SIPDroid que tampoco tiene gran misterio. En el programa, accedermos a Settings > SIP Account Settings.
En Authorization Username, el usuario de la extension y en Password mas de lo mismo
En Server or Proxy, la direccion IP del servidor Asterisk.

El resto probablemente dejandolo como esta sera suficiente, quiza cambiar el puerto SIP del servidor Asterisk si es que es diferente.

Una vez configuradas todas las extensiones, voy a poner aqui un fichero extensions.conf de ejemplo con el que podriamos realizar las primeras llamadas entre extensiones. Proximamente me adentrare mas en el fichero extensions.conf que es el lugar donde se configura el Plan de Marcacion, o DialPlan como comunmente suele llamarse. Este podria considerarse, el cerebro del Asterisk. Es importante manejarse bien en este fichero porque lo aqui puesto, dependera del 90% del exito de nuestro sistema y las posibilidades que a este podramos otorgarle.

El ejemplo sencillo para nuestras nuevas extensiones, ext1000 (Polycom), 1001 (Ekiga), 1002 (SJPhone) y 1003 (SIPDroid). Todavia no me centrare en los contextos, y atributos especificos

[general]
static=yes
writeprotect=no
clearglobals=no
[globals]
POLYCOM => SIP/ext1000
EKIGA => SIP/ext1001
SJPHONE => SIP/ext1002
SIPDROID => SIP/ext1003
[extensiones]
exten => s,1,NoOp()
exten => s,n,WaitExten(8)
exten => 1000,1,NoOp()
exten => 1000,n,Answer
exten => 1000,n,Dial(${POLYCOM})
exten => 1000,n,Hangup
exten => 1001,1,NoOp()
exten => 1001,n,Answer
exten => 1001,n,Dial(${EKIGA})
exten => 1001,n,Hangup
exten => 1002,1,NoOp()
exten => 1002,n,Answer
exten => 1002,n,Dial(${SJPHONE})
exten => 1002,n,Hangup
exten => 1003,1,NoOp()
exten => 1003,n,Answer
exten => 1003,n,Dial(${SIPDROID})
exten => 1003,n,Hangup
Con esto podremos realizar llamadas sencillas marcando una u otra extension, desde una hacia otra sin problemas. Esto es todo por hoy. Estoy dudando cual sera el proximo paso, configuracion de extensiones analogicas con el canal DAHDI o si empezar las primeras andanzas y pruebas con el mundo de los DialPlan. Cualquiera de las dos igual de importante y prioritaria, sera cuanto antes!

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.

Manos a la Obra con Asterisk

Por fin, despues de pasar mucho tiempo dando vueltas con el hardware, el software, y tratando de aprender lo maximo para optimizar el resultado hasta donde fuera posible, llego el momento de ponerse los guantes y entrar en serio en el proposito de este blog.

Parece ser que ha llovido un poco desde el primer comentario inaugural de este blog, en el que se comentaba que las dos opciones principales en el mundo Asterisk, a nivel de versiones, eran la 1.4 como robusta (y de ahi el branch Rock Solid Patchset para esta version),y la 1.6 como “novedosa”.

Pues bien, a dia de hoy, por fin podria decir, que la 1.6. subdividida en varias “subversiones”, la 1.6.0 (que pasa a ser la nueva rock solid), la 1.6.2, nueva version bastante estable, y finalmente la nueva version inestable y supernovedosa, 1.8.

Puestos a elegir, en este caso, y sirviendo un poco los propositos de testeo, lo logico hubiera sido aventurarme en la version 1.8. Pero dado que mi curso fue especializado en la version 1.6 y realmente aun me queda mucho camino por recorrer antes de empezar a indagar en las novedades de la ultima version (que seguramente para entonces ya haya salido la version 1.8.0-current y sera muy estable migrar a esa opcion).

Por tanto a la hora de la instalacion del sistema Asterisk los paquetes elegidos seran:

Asterisk 1.6.2
Asterisk Addons 1.6.2 (¿es coincidencia? son los ultimos mas estables)
Libpri 1.4 que es tan estable, y tiene muy pocas intenciones de actualizarse, que ahi quedo
Pack Dahdi Completo (Dahdi Linux + Dahdi Tools)

El metodo de compilacion, instalacion, y en caso del paquete Asterisk y Asterisk Addons, instalacion de los ficheros ejemplo orientativos, se puede encontrar en multiples sitios.

Pero aqui lo interesante es conseguir una manera de que todo instale lo suficientemente “suave” para no andar teniendo problemas a la hora de compilar, y especialmente configurar el “make” con el Autotools, exigiendo dependencias a cada momento.

Esta lista, extraida de varios sitios, entre ellos el curso al que asisti en su dia, son los paquetes necesarios para realizar una instalacion integral de todos los paquetes necesarios:

– Lo basico para compilar

build-essential linux-headers-‘uname -r’ flex bison gawk

– Herramientas adicionales del Servidor

ssh unixodbc unixodbc-dev subversion mc pciutils doxygen

– Librerias multiples

libxml2-dev libmysqlclient-dev libcurl4-openssl-dev curl libncurses5-dev libiksemel-dev libspeex-dev libsm1-dev  libssl-dev libvorbis-dev libsnmp-dev libsctp-dev libsctp1 libnewt-dev lksctp-tools

Todo esto se puede instalar directamente sea con yum (CentOS, RedHat), o con aptitude que es en este caso, el sistema que aqui nos trata (Ubuntu Server, Debian).
Con Debian quedaria algo asi:
aptitude install ssh mc pciutils build-essential libxml2-dev libnewt-dev libssl-dev libmysqlclient-dev libcurl4-openssl-dev curl libncurses5-dev libiksemel-dev libspeex-dev libgsm1-dev unixodbc-dev flex bison gawk subversion libvorbis-dev libsnmp-dev libsctp-dev libsctp1 lksctp-tools unixodbc doxygen linux-headers-`uname -r`

Realmente es muy probable que no todo esto vaya a ser necesario en nuestro sistema, pero tampoco es que vayamos a derrochar recursos haciendo esta instalacion, y nos va a quitar a priori de muchos problemas durante la compilacion.

Finalmente tras compilar, instalar, etc los paquetes en el orden siguiente:
1. Libpri
2. Dahdi
3. Asterisk
4. Asterisk-Addons

Comprobamos que la instalacion de asterisk, de momento funciona con el comando

# asterisk -r

Y entraremos en la consola de Asterisk.

De hecho si reiniciamos el servidor, en teoria Asterisk ya deberia estar funcionando en background. Con el comando:

# ps -e | grep asterisk

Deberia aparecer ya la instancia en funcionamiento. Toda lista y preparada para la siguiente fase: La configuracion de algunas primeras extensiones de ejemplo y prueba.

Primer Sistema Base: Ubuntu Server y Md Raid

Despues de haber comentado hace unas semanas acerca de la seleccion de Servidor, ahora tocaba la eleccion del Sistema… en este sentido solo habia una cosa clara: El sistema base iria sobre GNU/Linux, el tema a tocar, seria: ¿sobre que distribucion?

Realmente hoy en dia todas las distribuciones son validas, incluso distribuciones basadas en UNIX, desde Open Solaris, incluso distribuciones para dispositivos con un sistema operativo embebido, y cualquier otra distribucion Linux tipo RedHat, OpenSuse y demas.

Pero en el mundo Asterisk tras varias indagaciones y lo aprendido hasta la fecha, las distribuciones mas reconocidas son CentOS y Debian por igual. De todas formas esto no resulta nada nuevo ya que hoy en dia, Centos y Debian se reparten el pastel de los servidores, incluso por encima de Fedora y RedHat Enterprise (se ve que eso de tener casi todo lo de RedHat Enterprisa gratuitamente tira mas que dos carretas… ¿o era otra cosa lo que tiraba mas que dos carretas?).

Debian es para mi personalmente, la distribución que mas he rozado desde mis inicios en el mundo Linux. Coincido con mucha gente decidiendome para todas mis inicios en cualquier sistema basado en Linux por decantarme siempre por Debian. En el ejemplo de la Virtualizacion que puse la semana pasada, KVM alojado en Linux, y adoptado por RedHat, yo lo utilizo personalmente sobre maquinas Debian, concretamente una distribucion basada en esta ultima llamada Proxmox que agrega multiples funcionalidades especificas de la virtualizacion con KVM en si.

Pero realmente, existe una distribución dentro del mundo Debian que simplifica masivamente la vida de configuracion a nivel Hardware. Esta es Ubuntu Server como indica el titulo. Es cierto que a dia de hoy no es una personoficacion de la optimizacion de los recursos del sistema ya que de por si añade un consumo “cabecera” (overhead) a la CPU que no es nada positivo para un sistema especifico con una funcion especifica, como cumplira en este caso lo que aqui estamos tratando, un sistema PBX.

Pero ahora volviendo atras al momento de la decision de configuracion de Hardware me encontraba con una simple cuestion: nuestra maquina de pruebas, tampoco iba a servir como un sistema de proposito especifico y de alto rendimiento. No es mi intencion de servir como Call Center para cubrir 500 llamadas simultaneas. Ademas Asterisk infraescalado, ni aun con un sistema como Ubuntu, seria capaz de soportar esto. Es por esto quiza, por lo que la facilidad de “auto”-configuracion del Hardware en el sistema fue por ultimo mi decision final de utilizar Ubuntu Server como sistema.

Tras instalar Ubuntu Server pude comprobar como practicamente todo el Hardware fue reconocido, y autoconfigurado, desde la Controladora RAID, hasta la VGA en alta resolucion (no es gran cosa, pero personalmente me resulta muy util trabajar en 1920×1080 incluso en consola si el sistema ofrece esta posibilidad como es el caso. Solo le hubiera faltado reconocer la tarjeta Digium B410P (hubiera sido el colmo ya).

La segunda parte quiza mas significativa de la configuracion del sistema fue la del planteamiento de estabilidad del sistema a nivel de Disco Duro. Comente en su dia que disponia de dos discos duros de semejantes caracteristicas, por lo que se veia forzada la necesidad de montar un RAID. Pero tras mucho indagar me di cuenta, que las mayoria de las placas base, a pesar de traer un controlador RAID, realmente no es un controlador puro y dedicado como podrian ser los controladores PERC de Dell. Considero un controlador dedicado, a ese controlador capaz de liberar a la CPU de la carga de realizar todas las tareas para que el RAID se viera satisfecho. En este caso mi intencion era montar un RAID 1.

En general la mayoria de las placas base suelen traer controladores Silicon Image, ATI Nvidia, VIA, etc, pero realmente no dejan de ser controladores de tipo software, gestionados desde la BIOS con solo las caracteristicas basicas para poder proveer de informacion suficiente de como deberia trabajar (pero no capaces de trabajar por si mismos). Esto podria resultar interesante, excepto por una cuestion muy importante: Si esta controladora se averiase (o si la misma placa se averiase), necesitariamos para recomponer ese RAID una controladora Exactamente Igual, o de semejantes caracteristicas, capaz de recomponer eso. Hoy en dia, esto puede resultar excesivamente dificil, ya que la mayoria de las piezas quedan descatalogadas en apenas 2 años, y pese a que continua su produccion, a partir de los 4 años es practicamente imposible conseguir una a no ser que la busquemos a traves de un Broker, o la localicemos de casualidad de Segunda Mano o que la pidamos a la marca BAJO DEMANDA (con un coste 10 veces mas caro de lo que costo originalmente). Esta dependencia al Hardware, para mi me resulta inviable. Si tuvieramos la opcion de tener controladoras especificas como las PERC de Dell que siguen ciertos estandares al menos dentro de la misma marca, y que su produccion se extiende mas alla de los 5 años, ademas de ofrecer un hardware dedicado y liberando a la CPU de esta carga, entonces definitivamente si podria decidir, que merece totalmente la pena.

Entonces, si tengo dos discos duros iguales, y mi intencion es montar un RAID 1 …. ¿cual es la resolucion?

Pues volviendo al titulo, GNU/Linux provee la solucion, Md Raid, con mdadm. El RAID software por excelencia de Linux.

Vamos un poco a la practica. Para configurar esto en un sistema de “bajo calibre” la idea es muy sencilla:

Ubuntu ofrece en el propio instalador la opcion de configurar esto de manera grafica. En cualquier caso, por si a alguien le interesara configurarlo en modo Consola la idea seria la siguiente:

1. Para cada disco tenemos que crear primero una particion de tipo RAID arrancable (exactamente iguales, ocupando el disco completo, y con el flag B de bootable).
Podriamos utilizar una herramienta de particionado tipo cfdisk. Simplemente, toca, crear una nueva particion con new, en Tipo, ponerle fd (Particion Linux Raid), en flag, ponerle bootable, y finalmente “Write” para escribir las modificaciones sobre la particion. Repetir este proceso para el otro disco.

2. En segundo lugar, toca “instalar” el Raid software con mdadm. En el instalador simplemente hay que especificar algunos parametros, como el tipo de raid (1, mirror, espejado, misma informacion en los dos discos duros), el numero de discos involucrados, el numero de discos sobrantes (Spares, como en el sistema JBOD por si acaso) y seleccionar los discos involucaros. Y el sistema raid estara listo en unos segundos.
En el caso shell es quiza aun mas sencillo:
Considerando que los discos son SDA y SDB (sata disk A y sata disk B siendo ambos discos tipo sata, si fuera IDE/PATA, seria hda, y hdb)
mdadm –create /dev/md0 –level=1 –raid-devices=2 /dev/sda1 /dev/sdb1 (el 1 es la particion 1 que creamos anteriomente, una sola particion).
En este caso habremos llamado a nuestro recien creado RAID md0 a nivel de sistema.

3. Acto seguido, toca particionar nuestro recien creado RAID. En este caso, seria como si tuvieramos un solo disco duro. Podriamos directamente particionarlo con ReiserFS, Ext3 o Ext4, o podriamos elegir un formato mas avanzado como LVM2. Yo personalmente soy mas partidario de utilizar LVM a cualquier costa. ¿Porque? Por la opcion de hacer una copia de seguridad del sistema completo utilizando Snapshots.

Recuerden, un RAID1 aunque ayuda al uptime del servidor, ya que aunque haya un error de disco, el sistema seguria en pie, no asegura que la informacion se destruya en un momento determinado (o peor aun, se corrompa). La unica forma de preservar la fiabilidad de la informacion (y de echar marcha atras rapidamente en caso que un dia hagamos algo indebeido), es utilizar las copias de seguridad. Y los snapshots de LVM son la forma idonea de realizarlas sin tener que parar el sistema, y mantener el 100% de Uptime en nuestro sistema.

Eso es todo por hoy. Seguramente haya obviado algunos detalles interesantes. Cualquier sugerencia para explicacion, no dudeis en comentarla!

Extra:

Hoy 30 de Agosto 2010, escribo un pequeño Plus para este Sistema. El metodo de Particionamiento dentro del sistema LVM que yo he seguido

En primer lugar, una particion para el sistema de arranque. Esto no es estrictamente necesario pero, realmente es una buena practica poner el sistema de arranque en un tipo de particion mas sencilla como ext2 que la particion del sistema principal, que en este caso seria ext4. Yo suelo darle bastante cantidad de espacio, del orden de 10 veces mas de lo que necesita. Con 50 Mb es suficiente, pero si en un momento determinado vamos cargando multiples kernels para cualquier asunto, o actualizaciones sucesivas, y no tener la necesidad de ir borrando lo antiguo, suelo poner 512Mb. Con los discos duros de hoy en dia no supone un gasto indebido y me curo en salud

En segundo lugar el espacio Swap. Hay que considerar una cosa: Si tenemos que utilizar el sistema Swap en nuestra maquina Asterisk, vamos a tener SERIOS problemas. Yo personalmente podria 0 Mb. Pero con mi politica de reservar memoria para todo y que en un momento dado, aunque el sistema vaya mal, al menos no vaya a Pique con facilidad, me gusta reservar tanta memoria Swap como memoria RAM disponible haya.

El resto, volumen principal, en ext4 que es el mas nuevecito en estos momentos, y funciona perfectamente. Los sistemas Ubuntu lo permiten y Asterisk funciona perfectamente en este tipo de sistema.

Sabia que podia completar mas este mensaje, y asi lo he hecho.

Uno de los nuevos grandes Dilemas: Xen o KVM?

Hace mucho tiempo surgia KVM como nuevo competidor. Tenia serias dificultades para entrar en el mercado dominado por VMWare en el mundo propieatario, y Xen en el mundo opensource. Por otro lado tambien emergian nuevas soluciones como VirtualBox que darian mucho que hablar.

Pero entre lo que mas quiero destacar, fueron los inconvenientes que se extrajeron de la competicion opensource Xen vs KVM:

Claro está, tiene sus inconvenientes

  • necesitas tener un procesador con soporte para virtualización por hardware, como son los procesadores con tecnología AMD-V e Intel-VT
  • no tiene el soport ni el número de seguidores que tiene Xen
  • no tiene el apoyo económico que tiene Xen: Red Hat, Novell, Citrix
  • no tiene el apoyo tecnológico que tiene Xen: Red Hat, Novell, Citrix
  • no tiene interfaces gráficas bonitas y sencillas de usar para configurar y administrarlo

Hoy en dia, todos los procesadores soportan virtualizacion por hardware. A lo mejor maquinas antiguas sufren esto, pero ya es realmente raro mantener un servidor de tal antigüedad con semejantes caracteristicas, y ni siquiera plantearse el hecho de mandarlo a la guerra de las maquinas virtuales con semejante antiguedad

Es curioso como la curva de seguidores, en una balanza, empieza a inclinarse a favor de KVM. Desde la lectura de estas lineas KVM ha superado ampliamente a la comunidad de XEN, de hecho XEN cada vez pierde mas “seguidores” a costa de KVM como puede verse en la mayoria de las estadisticas.

Sobre los apoyos tecnologicos, economicos, y tecnicos, la verdad es que KVM empezo a gozar del apoyo del monstruo de Linux, RedHat, y desde entonces empieza a hacerle frente al todopoderoso VMWare

Y conjunto a esto, tambien han surgido las interfaces graficas para dar un apoyo definitivo e impulso al sistema KVM, con sus bonitas GUIs web y demas.

Hay que decir para terminar que KVM es de los pocos sistemas de virtualizacion que soporta el PCI Passthrough, esto es, la opcion de poder soportar PCIs “raras”, como tarjetas de sonido, o lo que aqui nos atañe, las bienamadas tarjetas del sistema Asterisk. Con esto, Asterisk podria obtener un reloj de sincronizacion puro, y podrian verse las funciones que hasta la fecha eran imposibles o demasiado complejas para verse implementadas directamente en Maquinas Virtuales.

Algun dia hablare porque es mucho mejor tener un Asterisk en las SOHO y PYMEs virtualizando que directamente sobre la maquina