Conquistando el Dialplan I. Aplicaciones Asterisk: Voicemail

Como ya sabemos, el Dialplan, plan de marcación, es el esqueleto en esencia de Asterisk. A partir de este se abre el sin fin de posibilidades que nos ofrece este sistema.

Solo el que conoce lo que ofrece el Dialplan al 100%, es aquel que realmente conoce Asterisk de verdad. Por ello, las series de documentación sobre Dialplan serán mensajes mas cortitos pero no por ello menos interesantes  y que ayudaran a organizar mejor la información.

Realmente ya vimos parte del potencial del Dialplan, con la creación de una operadora automática de coste cero, ahora vamos a ver las funciones de Buzón de Voz para nuestras extensiones. Aquí básicamente hay dos actores principales. La Aplicación Voicemail, y el fichero voicemail.conf

El fichero voicemail.conf puede llegar a ser todo lo complejo que deseemos en función de nuestras necesidades, pero voy a comentar un caso práctico en el que podemos ver diversa funcionalidad que podemos llegar alcanzar. Como la mayoría de los ficheros de Asterisk, se divide en contextos, como casi siempre, general, suele ser el genérico que afecta a todos los contextos por igual.

[general]
format=wav
//Formato de las grabaciones para el buzon de voz. Se admiten otros formatos como gsm.
serveremail=direccion@queenvia.com
//Direccion del remitente de los envios
attach=yes
// Para enviar el fichero adjunto en los emails con el audio
delete=yes
// Para permitir la opción de borrado del mensaje de voz local en el servidor una vez enviado por correo eletronico
maxmsg=100
// Maximo numero de mensajes permitidos en la bandeja local por buzon
maxsecs=180
// Maximos segundos por mensaje
minsecs=2
// Minimos segundos por mensaje para desechar los mensajes vacios o casi vacios
skipms=3000
// Opciones del mensaje de audio, para indexarlo cara a desplazamientos X ms adelante o detrás cuando sea reproducido en el pc del destinatario
maxsilence=10

// Silencio máximo permitido, esto es importante cara a poder desconectar la llamada en caso de silencio antes de cumplir el máximo posible caso 180 segundos (en nuestro ejemplo)
silencethreshold=128
// Este es el umbral de audio para el que consideramos que es un silencio, de aquí podemos ir mas abajo o mas arriba en función de nuestra necesidad, no hay un valor “ideal”
maxlogins=3
// Intentos de acceso a voicemail, en caso de sobrepasarlos, Asterisk desconectara al usuario de su cuenta SIP/IAX
emailsubject=Nuevo Mensaje de ${VM_CALLERID}
emailbody=Buenos días ${VM_NAME},\n\nHemos recibido un mensaje en su buzon de voz…
// Esto seria el asunto y el cuerpo del mensaje email. Aquí se pueden aprovechar variables para poder formatear el correo y mostrar datos quizá interesantes para el destinatario. Algunas de estas variables de ejemplo:
${VM_CALLERID}: El numero identificador del llamante (el número de teléfono)
${VM_NAME}: El nombre del dueño del buzon (lo definiremos más adelante)
${VM_DUR}: Duracion del mensaje
${VM_DATE}: Fecha y hora de recogida del mensaje
Mas variables pueden encontrarse aquí: en su correspondiente sección (tampoco son muchas más)
emaildateformat=%A, %B %d, %Y at %r
// Formato de la fecha para el email. Para la variable VM_DATE. Consultar el manual de date para mas información (# man date)

Con esto tenemos más que suficiente para componer mensajes para el buzon de voz y enviarlos por email. Ahora vienen los contextos. Como siempre, si es [default] es el genérico, y luego los contextos específicos. En principio vamos a poner uno genérico y uno especifico.
[default]
1234 => 5678,Buzon de Ejemplo,ejemplo@buzones.com
– En primer lugar, el número del buzón, luego lo utilizaremos en el Dialplan para la aplicación Voicemail así referirnos a este buzón
– En segundo lugar, la contraseña para acceder al buzón. Tendremos que crear una “extensión” en el Dialplan para que el usuario pueda acceder a su buzón de forma interna. Esto solo es útil si no marcamos la opción de borrado de mensajes del buzón al ser enviados por email
– En tercer lugar, nombre del buzón que luego utilizaremos en variables como VM_NAME
– En cuarto lugar, Email del destinatario de los mensajes de este buzón

Este es un ejemplo muy sencillo, pero a esto podríamos aplicarle un poco mas de complejidad al asunto

[extensiones]
1000 => 9878,Mr. Lenny, lenny@debian.net,,attach=yes|delete=1
– En quinto lugar, iria la dirección del Pager… muy poco utilizado a dia de hoy
– En último lugar, irían opciones especiales. En este caso, decimos que adjunto el mensaje, y lo borre a continuación. Si hemos activado las opciones en el contexto general, ira bien esto.

Si queremos hacer “broadcasting” de mensajes de buzon a varios emails, hay varios métodos pero el que a mi mejor me ha funcionado es hacerlo en combinación a aliases del servidor de correo (en nuestro caso al usar Ubuntu, por defecto, Postfix)

1001 => 8765, Dpto. de Botijos, botijos@nuestroservidor,,attach=yes|delete=1

Nos vamos a /etc/aliases y añadimos
botijos: sr.sanchez@botijoland.com,sr.perez@botijoland.com,sr.alvarez@botijoland.com

Y refrescamos aliases comando: # newaliases

Por ultimo no olvidemos recargar nuestro voicemail.conf #asterisk –rx ‘voicemail reload’

Ahora toca editar nuestro Dialplan para poder utilizar estos buzones recién configurados. Vamos al extensions.conf:

Si queremos por ejemplo hacer que los usuarios puedan dejar mensajes a nuestro contestador tenemos que utilizar la aplicación Voicemail
Ejemplo:

exten => 1000,1,NoOp()
exten => 1000,n,Dial(SIP/1000,30)
exten => 1000,n,Voicemail(1000@extensiones,u)
// En este caso, ponemos el número del buzón que pusimos antes @ el contexto al que pertenecía, adicionalmente ponemos una opción, para que antes de dar el pitido de “empezar a grabar” diga el mensaje de “en estos momentos no nos encontramos, deje su mensaje después de oír la señal”. Aquí tenemos varias, opciones, en vez de utilizar los mensajes por defecto que se pueden encontrar en la carpeta de sonidos /var/lib/asterisk/sounds/ todos los que empiezan por vm- tienen algo que ver con el buzón de voz y estas opciones. Las opciones posibles son:
sin opciones: se escuchan las instrucciones para dejar el mensaje
s: no se escucha nada (útil si queremos poner mensajes personalizados para cada usuario)
su: mensaje de no disponible
u: mensaje de no disponible + instrucciones
sb: mensaje de ocupado
b: mensaje de ocupado + instrucciones

Con esto también podemos jugar con las aplicaciones Playback y Record, para con la opción “s” crear un buzón acorde a las necesidades de un usuario en concreto

Por otro lado vendría la aplicación destinada a escuchar los mensajes guardados si no pusimos la opción de borrado automático: VoicemailMain. Tiene poca historia:
exten => 10001,1,VoicemailMain(1000@extensiones)
El tema es que a partir de ahí vendría un menú relativamente complejo, editable, y demás. Yo personalmente no lo utilizo ya que la función de envío a correo aparte de que me descarga el disco duro, hoy en día a la mayoría del personal le resulta formidable. Aun así, para aquellos que deseen profundizar, les dejo un enlace al manual por si acaso quieren probarlo. Cualquier consulta acerca de esto, no duden en comentármela!

En principio, con todo esto, ya se podrían componer sistemas de Buzón de voz bastante interesantes. Como ven no es demasiado complejo y existen muchas alternativas y opciones. Yo personalmente opino que las opciones de envío a correo, todavía están muy poco elaboradas, pese a que se ha profundizado en ellas. Yo personalmente no he encontrado opciones por ejemplo, de envío CC o CCO (BCC) para envíos broadcasting (lo cual me resultaría muy interesante). Supongo que sería una cuestión de apoyar programando, al proyecto Asterisk. Quien sabe, a lo mejor más adelante nos animamos a ello.

Preparando nuestro sistema de FAX en Asterisk: Hylafax + IAXModem

Hoy voy a tratar de explicar cómo crear un sistema de faxing a través de nuestro Gateway (o tarjeta) para poder recibir faxes a email, y poder enviar faxes con un software desde nuestros PCs. He observado múltiples manuales en la web, pero la verdad es que si no tienes “suerte” encontraras miles de problemas, especialmente en las últimas versiones de Ubuntu Server. Y la verdad es que cuantos más problemas mejor, así aprendemos más sobre el asunto que nos concierne.

En primer lugar toca configurar nuestro IAX.conf para añadir una extensión para el FAX

[iaxmodem]
type=friend
username=iaxmodem
//secret=contraseña_de_la_extension
secret=fax
qualify=yes
notransfer=yes
disallow=all
allow=ulaw
host=dynamic
context=extensions
callerid=”FAX” <100>
requirecalltoken=no
// esta línea ultima es muy importante rebaja la seguridad de IAX para esta extensión, pero sino lo ponemos no funcionara IAXmodem en concreto

Acto seguido vamos a configurar nuestro Dialplan para a través de un número DID que tenemos disponible o línea analógica conectada (como hemos visto en anteriores mensajes, configuraciones relacionadas al Gateway RDSI, o relacionadas al módulo DAHDI desde chan_dahdi.conf), indiquemos a que extensión se deben enviar los FAXes (en este caso IAX2/iaxmodem) que es nuestra extensión IAX para el FAX. Esto se añadiría en el contexto que se envían las llamadas de nuestra PSTN (en nuestro caso desde-isdn)

exten => 123123123,1,NoOp()
exten => 123123123,n,Answer()
exten => 123123123,n,Wait(3)
exten => 123123123,n,Dial(IAX2/iaxmodem)

Quiero recordar que cuando hagamos modificaciones en los ficheros es necesario “Recargar” nuestro asterisk para que tome los cambios. No estoy seguro en este punto, si ni siquiera lo comente alguna vez!

# asterisk –x dialplan reload
# asterisk –x iax2 reload

(Recargamos el extensions .conf modificado y el iax.conf modificado)

Ahora toca configurar un modem capaz de reconocer los “tonos” de los faxes, a través de nuestra extensión IAX recién creada. Todo a través de software. La aplicación en cuestión, se llama IAXmodem

Podemos descargarla desde aquí:  http://sourceforge.net/projects/iaxmodem/files/iaxmodem/

Ahora la descomprimimos:

# tar –xvf iaxmodem-versionquesea.tar.gz
# cd iaxmodem-versionquesea
Necesitamos alguna librería adicional en nuestro sistema para poder compilar:

# aptitude install libtiff-dev libtiff-tools
# ./configure
# make

Con esto creamos el binario iaxmodem. Lo copiamos en el path de ejecución de binarios, generalmente /usr/bin o /usr/local/bin o /usr/local/sbin

# cp iaxmodem /usr/local/bin

Y ahora nos toca configurar un puerto virtual para que iaxmodem sea capaz de generar la señal, tendriamos que crear el archivo /etc/iaxmodem/ttyIAX con la siguiente información:

device /dev/ttyIAX
owner asterisk:asterisk
mode 660
port 4570
refresh 300
server 127.0.0.1
peername iaxmodem
secret fax
cidname FAXIAX
cidnumber 100
codec ulaw

Es muy importante asignar un Puerto diferente al de IAX (4569) para que funcione puesto que esta extensión estará siempre en activo como veremos ahora. Sería necesario configurar un script de arranque event.d para que esto ocurra. Dentro de /etc/init/
#vim /etc/init/iaxmodem.conf

start on startup
respawn
exec /usr/local/bin/iaxmodem ttyIAX

Probamos para ver si hemos configurado bien iaxmodem:
# iaxmodem ttyIAX
Si aparece: Registration completed successfully.
Entonces hemos tenido éxito en la configuración.

Después arrancamos el “servicio” con el comando:
# start iaxmodem

ATENCION: Este sistema de scripting es el sistema por defecto de las últimas versiones de Ubuntu, concretamente es Upstart, para más información: http://upstart.ubuntu.com/getting-started.html.  Anteriormente esto se hacia dentro /etc/event.d  en versiones anteriores a la 9.10 e incluso antes esto se hacía en inittab, clásico de sistemas Debian. Parece que se mantendrá ahora así, pero como Ubuntu va cambiando constantemente, obliga a tenernos actualizados constantemente, y por tanto esto está sujeto a modificaciones.  Si no os arranca automáticamente, investigad un poquito, o mandadme un comentario a ver si os pudiera ayudar y/o actualizar este mensaje.

Ahora viene la instalación de Hylafax para manejar los FAXes que entren por este modem.

Primero descargamos las fuentes:
# wget ftp://ftp.hylafax.org/source/hylafax-6.0.5.tar.gz
# tar –xvf hylafax-versionquesea.tar.gz
# cd hylafax-versionquesea

Y compilamos como casi siempre

# ./configure
Aquí nos muestra  los directorios donde se encuentran aplicaciones básicas, decimos que si a todo si estamos conformes (que creo que lo estaremos casi siempre)
# make
# make install

Ahora necesitamos que faxgetty (para recibir faxes) funcione automáticamente como hicimos antes con iaxmodem. Lo mismo, introducimos el fichero de configuración en /etc/init:

# nano /etc/init/ttyIAX.conf
start on startup
respawn
exec /usr/local/sbin/faxgetty ttyIAX

Y arrancamos con start ttyIAX igual que antes. Ahora tocaría configurar un poco el sistema de fax con faxsetup. En general todas las opciones por defecto, pero hay ciertas preguntas que debemos responder para mejorar la fiabilidad del sistema:
Serial port that modem is connected to []?
Ponemos ttyIAX que es nuestro iaxmodem

También configuramos parámetros de número de fax y demás, no es que sea crucial pero cara al envío es importante puesto que en las cabeceras de los FAX esto es lo que aparece.

Otra pregunta importante:
Rings to wait before answering [1]?
Ponemos “2” para asegurarnos que pasa un poco antes de empezar a recepcionar el FAX. No es fundamental, pero ayuda a que fallen menos Faxes por experiencia.

Seguimos adelante hasta que nos pida configurar otro modem y decimos que no para terminar: Do you want to run faxaddmodem to configure another modem [yes]?

Ahora vamos a probar que todo quedo bien configurado. Llamemos al teléfono que hemos configurado el FAX 123123123. Y si todo fue bien, oiremos los típicos pitidos de FAX.

Por defecto, todos los faxes van a parar a /var/spool/hylafax/recvq en formato TIFF.

Si queremos que el FAX recibido se envíe automáticamente, adjuntando la imagen TIFF en formato PDF, y utilizando una plantilla de envío en Español, tenemos que editar un fichero dentro de /var/spool/hylafax/etc/FaxDispatch y añadimos:

TEMPLATE=es;
FILETYPE=pdf;
NOTIFY_FAXMASTER=errors;
FROMADDR=email.que@envia.com
case “$DEVICE” in
ttyIAX)
TOADDR=email.que@recibe.com;SENDTO=email.que@recibe.com;;
esac

Si fallara por cualquier razón, estaría bien que pusiéramos un email de administrador. En /etc/aliases hay que incluir la línea
FaxMaster: nuestroemail@de.administrador

Y “refrescar” los aliases: # newaliases

Es importante respetar los ‘;’ y sin espacios donde no tiene que haberlos. Considerar que es importante definir un FROMADDR exclusivamente, cuando utilicemos un Smarthost en nuestro servidor de correo que requiera autenticación, ya que por defecto se enviara el correo con el usuario “fax”. Todos los parámetros por defecto que no incluyamos en este fichero los recogerá de /var/spool/hylafax/bin/faxrcvd

Si teníamos la ruta de uuencode en setup.cache funcionara correctamente. Básicamente las instrucciones estas pueden encontrarse aquí

Ahora viene la parte, para enviar un FAX, tenemos múltiples opciones. Vamos a considerar en principio que nos encontramos ante una red común en Windows, con máquinas Windows XP.  Existe un software que carga un puerto de impresión para poder enviar Faxes como si de una impresión se tratase por una “impresora” virtual sobre este puerto. De este tipo hay varias opciones, pero la que vamos a tratar aquí de ejemplo es Winprint Hylafax.

La página oficial de descarga es: http://winprinthylafax.sourceforge.net/

ACTUALIZACION: Ya existe version de Winprint Hylafax para Windows 7!: http://sourceforge.net/projects/wphfforwin7/files/

Y sobran las explicaciones de configuración, ya que en la propia página aparece un pequeño manual con capturas de pantalla. Pero este manual solo explica como configurar la interfaz en Windows. Por otro lado tenemos que tomar algunas consideraciones para hacerlo funcionar.

Por un lado tenemos el fichero de configuración de “hosts” permitidos, usuarios y contraseñas. Se encuentra en /var/spool/hylafax/etc/hosts.hfaxd. El formato para registrar nuevos se puede consultar en la página de manual de este fichero man hosts.hfaxd

Básicamente se trata de una expresión regular bien explicada, en la que introduciremos la red, para la cual será permitido enviar FAXes con este software. Ejemplo:

localhost
127.0.0.1
fax@10.158.[0-9]+.[0-9]+::
// Con esta línea sería equivalente a dar permiso a todos los equipos de la subred 192.168.1.0/24, además en la última pantalla de configuración, estaremos obligados a poner un usuario “fax” pero no necesariamente una contraseña.

Lo más importante es especificar en la primera línea de la pantalla de configuración, el servidor Asterisk. Aparte sería interesante especificar el modem que vamos a utilizar para enviar (en nuestro caso ttyIAX)

Tenemos otras opciones como Default Notify, que sería el correo de confirmación de entrega o error, también Address Book Format (dos ficheros o un fichero CSV para almacenar nuestra libreta de direcciones) y la ruta de nuestro ordenador donde queremos guardar la libreta (ejemplo C:\libreta), y finalmente parámetros de calidad y tipo de papel.

Con esto, al imprimir una hoja por esta impresora, nos pedirá los datos de envío y procederemos con el mismo

Por último, si queremos que las notificaciones lleguen en español necesitamos crear un fichero dentro de /var/spool/hylafax/etc/FaxNotify y añadimos:
TEMPLATE=es;
Muy parecido a lo que hicimos en el FaxDispatch

Voy a comentar un aspecto que puede ser interesante para muchos, ya que el envío de FAX y la recepción suele traer muchos quebraderos de cabeza. Las líneas RDSI, primarios, y líneas analógicas, es decir, el mundo PSTN es realmente la única vía aceptable para poder manejar la señal de FAX sin grandes complejidades. El envío a través de proveedores SIP, o a través de enlaces GSM puede dar lugar a problemas y errores que son bastante difíciles de solucionar, y yo personalmente aún no he conseguido aliviar, aunque la verdad es que resultaría bastante interesante profundizar sobre este tema.

Concretamente si leísteis mensajes anteriores, veréis como todas las salidas de mi central de pruebas son a través de enlaces GSM. Esto quiere decir, que he tenido que hacer modificaciones específicas en el Gateway Epygi, y en el Dialplan, para poder enviar Faxes específicamente, por las líneas RDSI que a priori, iban a estar exclusivamente dedicadas para la recepción de llamadas.

Para ello aquí van las dos modificaciones de ejemplo que tuve que hacer:

1.       Por un lado en el extensions.conf, cree una regla adicional sobre la que ya había, para salida al exterior:

exten => _3[9]ZXXXXXXX,1,NoOp()

exten => _3[9]ZXXXXXXX,n,Dial(SIP/${EXTEN}@my-isdn,30)

exten => _3[9]ZXXXXXXX,n,Hangup()

Con esto estoy diciendo, que para mandar un fax, primero hay que marcar el número 3. Así le mandaremos al Epygi un número del tipo “3987654321”

2.       Ahora en el Epygi, como vimos, en Call Routing -> Call Routing Table vamos a crear una ruta equivalente a las otras dos que hicimos, pero saliendo por uno de os troncales donde teníamos conectado una línea ISDN (en nuestro caso por ejemplo, el troncal 2). La única diferencia es que en la primera parte de la configuración pondríamos:
Enable Record activado
Tipo de llamada, ISDN
Pattern: 3* (para que sean todas las llamadas que empiecen por 3, es decir las que vienen para FAXes)
Number of Discarded Symbols: 1 (para que descarte el primer símbolo, el 3, a la hora de hacer la llamada a través del ISDN)

Description: isdn fax (aquí ponemos lo que queremos, yo pongo isdn 1 para saber que troncal de fax)

El resto, todo igual que los otros que ya configuramos. Incluso podríamos hacer otra línea equivalente, con razón de Failover igual, para tener la opción de ocupar múltiples troncales RDSI en caso que los otros estuvieran ocupados.

Si quisiéramos enviar un FAX de prueba utilizaríamos la herramienta sendfax con el siguiente comando:

$ sendfax -n -d 33987654321 /etc/issue.net
// Enviaríamos la información de /etc/issue.net simbólicamente

Seguramente recibamos un error con la métrica de fuentes Courier Bold. Necesitamos  instalar las fuentes ghostscript para ello podemos descargarlas y descomprimirlas en el directorio /usr/local/lib/ghostscript/fonts que es el que por defecto utiliza Hylafax para estas fuentes (sino existe podemos crearlo)
# mkdir /usr/local/lib/ghostscript/
# cd /usr/local/lib/ghostscript/
# wget http://ghostscript.googlecode.com/files/ghostscript-fonts-std-8.11.tar.gz
# tar –xvf ghostscript-fonts-std-8.11.tar.gz

¿Qué ocurriría si deseáramos auto enviarnos faxes con motivo de pruebas? Al enviar a través de la extensión iaxmodem, daría comunicando. Como es gratis tener múltiples instancias de iaxmodem (aunque no sean gratis los canales subyacentes a estas instancias, damos por supuesto que nos sobran para este supuesto), pues vamos a ello (aunque también se podría hacer que la extensión IAX fuese capaz de recibir y enviar múltiples llamadas sin dar comunicando, pero yo no lo he conseguido aun, quizá exista un parámetro para el contexto en el iax.conf que desconozco).

En primer lugar debemos crearnos otro modem IAX como vimos antes, otra extensión IAX. De momento para simplificar el iax.conf vamos a crear una máscara basándonos en el contexto [iaxmodem] que creamos antes. Cambiamos [iaxmodem] por [modem] y le añadimos (!)

[modem](!)
//con los mismos parámetros que antes, sacamos username, secret y callerid
[iaxmodem](modems)
// y aquí ponemos esos tres parámetros específicos del modem primero que creamos
[iaxmodem2](modems)
// Lo mismo que para iaxmodem pero nuevos parámetros
username=iaxmodem2
secret=fax
callerid=”Fax 2″ <101>

Luego copiamos el ttyIAX y lo modificamos el nuevo ttyIAX2
# cd /etc/iaxmodem/ttyIAX
# cp ttyIAX ttyIAX2

Ejemplo:
device /dev/ttyIAX2
owner asterisk:asterisk
mode 660
port 4571
refresh 300
server 127.0.0.1
peername iaxmodem2
secret faxiax
cidname iaxFAX 2
cidnumber 101
codec ulaw

Y lo probamos # iaxmodem ttyIAX2 y creamos el archivo para autoejecucion en /etc/init y demás:

#  cp/etc/init/iaxmodem.conf /etc/init/iaxmodem2.conf
Editamos el iaxmodem2.conf y cambiamos el final por iaxmodem ttyIAX2
# start iaxmodem2

Necesitamos configurar también Hylafax para la gestión de envío de estos faxes, para ello copiamos el archivo de configuración del otro modem. Realmente no necesitamos editar nada relacionado a faxgetty puesto que no tendríamos, al menos en este caso, recibir faxes por este canal de fax.

#cd /var/spool/hylafax/etc/
#cp config.ttyIAX config.ttyIAX2

Y finalmente # faxaddmodem ttyIAX2 y dejamos todos los parámetros por defecto tal cual se nos presentan. Para inicializarlo # faxmodem ttyIAX2. Podemos crear un script como el de faxgetty que creamos antes para la recepción de faxes equivalente. En /etc/init creamos el fichero ttyIAX2.conf con:

start on startup
respawn
exec /usr/local/sbin/faxgetty ttyIAX2

Realmente faxgetty es el único comando que funciona a modo “demonio” y sirve tanto para hacer que el modem IAX pueda tanto recibir como enviar. En este caso vamos a usar ttyIAX2 para enviar pero igualmente podría recibir.

Si pusiéramos en consola #faxmodem ttyIAX2, también resultaría para enviar, pero este comando no funciona para ser utilizando para dejarlo en background como demonio. Si alguien conoce alguna forma de conseguir este mismo efecto sin ponerlo en escucha con faxgetty actualizaría este mensaje con la novedad.

Y ahora por fin si:
$ sendfax -n -d 3987654321 -h ttyIAX2@localhost /etc/issue.net

Y finalmente recibiremos nuestro propio FAX como corresponde comprobando que todo está correcto y funcionando.

Debo decir que realmente esto se podría haber resumido bastante si hubiéramos utilizado los paquetes de los repositorios de hylafax y demás, pero la verdad es que haciéndolo a mano como comentaba al principio se ve en detalle como operada cada uno de los sistemas involucrados y si tenemos un problema, sabremos donde ir a buscar con más sencillez. Exactamente lo mismo que ocurre con el propio sistema Asterisk, cuando lo compilamos desde las fuentes al principio de todo.

Seguramente salgan 1001 problemas más que yo no haya contemplado aquí. Si tenéis alguna inconveniencia escribidla y trataremos de analizarla en el detalle para perfeccionar este mensaje al máximo.

De nuevo, agradezco vuestro interés por Asterisk y por este blog, al igual que vosotros agradeceréis el interés aquí mostrado. No nos dejes caer en la tentación y líbranos del mal. Amén.

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.

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.