Las últimas versiones del firmware de Cisco para sus terminales Spa5xx (+7.4.7), nos permiten configurar un parámetro con el que podremos enviar toda la información relativa a la calidad del audio a un servidor tras finalizar una llamada (Terminales Snom con firmware +v8 parece que también lo soportan, pero no lo hemos probado). Se configura desde la propia web de forma muy sencilla:

Lo que hace el terminal en si es, enviar un mensaje SIP PUBLISH al servidor definido (P.Ej: collector@192.168.1.1:5060) conteniendo en el body datos relacionados de la llamada y la calidad de ésta.
Estos eventos están definidos en el RFC6035: Session Initiation Protocol Event Package for Voice Quality Reporting. Por si queréis echar un vistazo… ;P

Un ejemplo del mensaje que envía el terminal:

PUBLISH sip:collector@10.1.100.190:7060 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.180:5060;branch=z9hG4bK-e20d9c33.
From: <sip:terminalSIP@10.1.100.190>;tag=f23bbd323541b235.
To: <sip:terminalSIP@10.1.100.190>.
Call-ID: a01e12b6-6eb5ba81@10.10.0.180.
CSeq: 64175 PUBLISH.
Max-Forwards: 70.
Contact: <sip:terminalSIP@10.10.0.180:5060>.
Accept: application/sdp, message/sipfrag.
Event: vq-rtcpxr.
User-Agent: Cisco/SPA504G-7.4.7.
Content-Length: 802.
Content-Type: application/vq-rtcpxr.
.
VQSessionReport: CallTerm.
LocalMetrics:.
Timestamps:START=2011-5-11T11:20:18Z STOP=2011-5-11T11:20:19Z.
SessionDesc:PT=8 PD=PCMA SR=8000 FD=20 FO=8 FPP=10 PPS=100 PLC=3 SSUP=off.
CallID: e850c0fe-1e19aa0f@10.10.0.180.
FromID: <sip:terminalSIP@10.10.0.180:5060>.
ToID: <sip:5998@10.1.100.190:5060>.
OrigID: <sip:terminalSIP@10.10.0.180:5060>.
LocalAddr: IP=10.10.0.180 PORT=16824 SSRC=467580294.
LocalMAC: 00:02:fd:ff:d3:5a.
RemoteAddr: IP=10.1.100.190 PORT=13914 SSRC=510.
RemoteMAC: 0.
JitterBuffer:JBA=3 JBR=15 JBN=171 JBM=171 JBX=300.
PacketLoss:NLR=0 JDR=255.
BurstGapLoss:BLD=0 BD=0 GLD=0 GD=0 GMIN=16.
Delay:RTD=0 ESD=177 SOWD=88.
Signal:RERL=127.
QualityEst:RLQ=22 RCQ=20 MOSLQ=1.2 MOSCQ=1.2 QoEEstAlg=P.564.
DialogID:e850c0fe-1e19aa0f@10.10.0.180;to-tag=as0df6f540;from-tag=ea2ec326d50586bo0.


Si os fijáis, el servidor que recibe este PUBLISH está escuchando en el 5070 mientras la señalización de las llamadas (SIP) está en el puerto 5060. Sí, mientras Asterisk gestiona las llamadas necesitamos un OpenSIPS/Kamailio para gestionar estos PUBLISH.
¿Por qué?
Porque Asterisk hasta la versión 1.8 (quizá alguna versión de 1.6?¿) ni siquiera soportaba mensajes del tipo PUBLISH y a partir de la 1.8 los soporta pero no para estos eventos concretos (vq-rtcpxr). La respuesta de un Asterisk:

SIP/2.0 489 Bad Event.
Via: SIP/2.0/UDP 10.10.0.177:5061;branch=z9hG4bK-aea9a42c;received=10.10.0.177.
From: ;tag=11636c9b167e05fa.
To: ;tag=as0d04d7f8.
Call-ID: ae68d5ef-aadd8cb6@10.10.0.177.
CSeq: 1316 PUBLISH.
Server: "Irontec IVOZ".
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Length: 0.


A lo que vamos… vamos a configurar un OpenSIPS/Kamailio para recibir estos mensajes y hacer después con ellos lo que creamos oportuno (guardarlo en BBDD, ejecutar un script…).
No vamos a explicar como instalar el software ya que hay multitud de ‘HowTo’-s disponibles en la red. Vamos directamente a lo que nos interesa, el fichero de configuración. En este caso se ha utilizado OpenSIPS pero con Kamailio debería ser muy parecido si no igual. Es una instalación básica sin ningún módulo extra, ya que en este caso lo único que haremos será recibir los datos, ejecutar un script y responder con un OK.
“Dialplan” de opensips.cfg:

####### Routing Logic ########

route{

if (!mf_process_maxfwd_header(“10″)) {

sl_send_reply(“483″,”Too Many Hops”);
exit;

}

if (!is_method(“PUBLISH”))  ## Solo gestionaremos PUBLISH
{

sl_send_reply(“503″,”Not here please”);
exit;

}
if (!uri==myself)
{

sl_send_reply(“503″,”SIP Publish ok, but please use our domain”);
exit;

}
if (is_method(“PUBLISH”))
{

if (!$(hdr(Event)[-1]) == “vq-rtcpxr”)  ## Solo gestionamos este evento concreto. Audio quality
{

sl_send_reply(“503″,”Not here please”);
exit;

}

xlog(“EVENT: $(hdr(Event)[-1])”);   ##Un poco de log…
xlog(“Got a PUBLISH: $rb”);

exec_avp(“/root/testing/test.sh ‘$rb’”);  ##Ejecutamos un Script pasándole como variable el body del PUBLISH recibido. También se puede utilizar la función exec_msg
sl_send_reply(“200″, “Thanks for this stats”);  ##Respondemos con un 200
exit;

}

}

Como se puede ver en los comentarios del código anterior, es posible utilizar, además de ‘exec_avp’, la función ‘exec_msg’. La diferencia es que, en un caso se procesa la salida del comando (exec_avp) y en el otro no (exec_msg). Detalle importante: la variable ‘$rb’ (reference to message body) tiene que pasarse al script entre comillas, porque el cuerpo del mensaje contiene caracteres especiales y necesitamos que nuestro script los pueda interpretar. Más info al respecto aquí y aquí.

¿Que podemos hacer en este script externo? Pues, todo lo que necesitemos/queramos y nuestra imaginación nos permita. Por ejemplo, sacar informes de calidad de audio de llamadas representando estos datos en gráficas creadas con RRDtool…

Happy VoIP hacking !!! ;P

Aunque la funcionalidad de queuerules se aplicó en la versión de asterisk 1.6, como tantos otros, nosotros hemos empezado a utilizar las nuevas posibilidades que nos encontramos al migrar desde asterisk 1.4 (en nuestro caso 1.4-rsp) a la nueva versión 1.8.

Hoy en día cuando configuramos colas, estas están compuestas por miembros que las atienden. En las colas estos miembros están ordenados para atender llamadas y asterisk decide a quien debe de enviarle la llamada. Esta decisión la toma en base a unos parámetros como la estrategia, o la prioridad de los miembros en la cola. Para el caso que nos atañe, lo que nos interesa es la prioridad o penalty.

Gracias a la prioridad, podemos priorizar quien atenderá las llamadas. La forma común de comportarse una cola sería la siguiente:

Primero atenderán la llamada loa miembros que estén con prioridad “1”, si no hay nadie disponible con esta prioridad, atendrán la llamada los miembros con prioridad “2”, si no los de prioridad “3”, y así sucesivamente.

El problema está en colas con muchas llamadas. En este caso casi siempre los miembros con prioridad 1 están ocupados con lo que saltan a los miembros con prioridad 2. Si queremos que no les entre la llamada a los miembros con prioridad 2 hasta pasados X segundos, solo podíamos dirigirlos hacia otras colas con otros miembros con distinta prioridad, pero esto hace que la persona que ha entrado en la cola pierda su puesto en ella, ya que le mandamos a otra cola.

Pero ahora con podemos hacer que esa prioridad máxima y mínima de atención en la cola varíe en el transcurso de la llamada. Para esto tenemos las reglas de cambio de prioridad definidas en “queuerules.conf” y las variables de canal QUEUE_MIN_PENALTY QUEUE_MAX_PENALTY. Las variables definen la prioridad máxima y mínima de los agentes que atenderán la llamada y esta regla se puede aplicar de dos formas, en la opción “rule” de la aplicación Queue o bien en la opción de cola “defaultrule”.

Queuerules.conf

En este archivo de configuración podemos crear reglas para modificar las prioridades máxima y mínima que atenderán en la cola. Solo los miembros que estén entre estas prioridades máxima y mínima podrán recibir llamadas de la cola. Estas reglas se definen de la siguiente manera en queuerules.conf

; sintaxis
; penaltychange => ,[,cambio absoluto o relativo de QUEUE_MIN_PENALTY]
[myrule]
penaltychange => 30,+1 ; después de 30 segundos, incrementa QUEUE_MAX_PENALTY en 1 y deja QUEUE_MIN_PENALTY igual .
penaltychange => 45,5,2; después de 45 segundos, pone QUEUE_MAX_PENALTY a 5 y QUEUE_MIN_PENALTY lo pone a 2.
penaltychange => 75,,1; después de 30 segundos, deja QUEUE_MAX_PENALTY como estaba y QUEUE_MIN_PENALTY lo pone a 1.

Un ejemplo lógico sería:

Creamos una cola

[COLA1]
musicclass=default
strategy=rrmemory
joinempty=no
leavewhenempty=yes
ringinuse=no
defaultrule=miembros-prio

member => SIP/0000FFFF0001,0,Miembro 1 ; Prioridad 1
member => SIP/0000FFFF0002,1,Miembro 2 ; Prioridad 2
member => SIP/0000FFFF0003,2,Miembro 3 ; Prioridad 3

Tenemos como regla de prioridades en queuerules.conf lo siguiente:

[miembros-prio]
penaltychange => 30,+1
penaltychange => 60,+1

En el dialpan tendríamos esto:

[entrantes]
exten => X.,1,NoOp(Llamada entrante de ${CALLERID(num)})
exten => X.,n,Set(QUEUE_MIN_PENALTY=1)
exten => X.,n,Set(QUEUE_MAX_PENALTY=1)
;Queue(queuename[,options[,URL[,announceoverride[,timeout[,AGI[,macro[,gosub[,rule[,position]]]]]]]]]) con lo que se podría aplicarse la “rule” miembros-prio en esta aplicación ejem: exten => X.,n,Queue(COLA1,,,,,,,,miembros-prio). Como en queues.conf ya la hemos definido como regla por defecto, no hace falta.
exten => X.,n,Queue(COLA1)

Esto hará que primero busque a los miembros con prioridad 1, si están ocupados no busca a miembros con mayor prioridad hasta que pase 30 segundos que es cuando la regla que hemos definido aumenta el QUEUE_MAX_PENALTY a 2. En este momento buscará miembros con prioridad 2 y si están también ocupados no buscará los de más prioridad hasta pasados otros 30 segundos como está definido en la regla miembros-prio.

Empezamos:
1. Es necesario compilar la librería libSRTP para que Asterisk tenga el soporte SRTP.

wget http://srtp.sourceforge.net/srtp-1.4.2.tgz
tar zxvf srtp-1.4.2.tgz
cd srtp/
CFLAGS="-Wall -O4 -fexpensive-optimizations -funroll-loops -fPIC" ./configure
make && make install


2. Descargamos y Compilamos Asterisk: (Para este Post se utiliza la versión 1.8.2.3)

svn co http://svn.asterisk.org/svn/asterisk/tags/1.8.2.3/ asterisk18
cd asterisk18
./configure
make menuselect (nos aseguramos de que esté res_srtp activado en 'Resource Modules')

**Ahora es cuando tenemos que aplicar el parche anteriormente mencionado**
¿Porque? Es necesario parchear el código porque los terminales SPA5xx envían dos líneas con el atributo crypto, tal que:

a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:Ud154Hz42jLai6YI7RBcKtctTHBzIKjiHM6nGD36.
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Ud154Hz42jLai6YI7RBcKtctTHBzIKjiHM6nGD36.

y Asterisk no es capaz de negociar cual de los métodos (AES_32 o AES_80) se va a utilizar para la encriptación. De hecho, sólo escoge el primero y como podéis ver, los Cisco envían primero el AES_32.
Aquí está el problema. Asterisk es capaz de manejar ambos tipos, pero sólo ofrece uno de ellos, el AES_80. Por tanto, tenemos que parchear el código para que Asterisk ofrezca en la señalización encriptación AES_32. Si no, se cifrará el Audio en las dos patas con un tipo diferente y nos quedamos sin audio y con un mensaje eterno (30 por Seg.) en el CLI:

WARNING[25205]: res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: authentication failure

Más info al respecto en el Bugtracker de Digium
Un poco de SIP para ver “claro” el problema (primer INVITE e INVITE de Asterisk al destino):

INVITE sip:200@10.10.0.165 SIP/2.0.
From: ;tag=630e30c1d5621880o3.
To: "200" .
m=audio 16890 RTP/SAVP 8 0 9 18.
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:hE+4XPMbPaF9/XEgIek7rUJiqoTEpLGZ1YXNiJhS.
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:hE+4XPMbPaF9/XEgIek7rUJiqoTEpLGZ1YXNiJhS.

INVITE sip:200@10.10.0.177:5063 SIP/2.0.
From: "100" ;tag=as72caceda.
To: .
Contact: .
User-Agent: Asterisk PBX 1.8.2.3.
Remote-Party-ID: "100" ;party=calling;privacy=off;screen=no.
m=audio 12202 RTP/SAVP 8.
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5uWtfxfK0vE90lTrgLTr83bRWTL2nCEFJ6NlXWjq.


El parche es bien simple:

--- channels/sip/sdp_crypto.c 2010-06-08 07:29:08.708826000 +0200
+++ channels/sip/sdp_crypto.c 2011-02-24 17:37:00.514711568 +0100
@@ -287,7 +287,8 @@
int sdp_crypto_offer(struct sdp_crypto *p)
{
char crypto_buf[128];
- const char *crypto_suite = "AES_CM_128_HMAC_SHA1_80"; /* Crypto offer */
+ //const char *crypto_suite = "AES_CM_128_HMAC_SHA1_80"; /* Crypto offer */
+ const char *crypto_suite = "AES_CM_128_HMAC_SHA1_32"; /* Crypto offer */

if (p->a_crypto) {
ast_free(p->a_crypto);

Aplicamos el parche (lo hemos nombrado como sdp_crypto.patch):

patch -p0 < sdp_crypto.patch (suponiendo que estamos en /usr/src/asterisk18 y tenemos el parche en la misma carpeta)

Asterisk is patched!!!
Ya podemos compilar e instalar:

make && make install


3. Configuración (tanto para TLS como para SRTP)
**TLS**
-Primero nos generamos una clave pública y otra privada, las fusionamos en un único fichero y la guardamos en algún sitio conocido.
Hay formas mucho mejores y elegantes de hacerlo (léeme), pero esto sólo es para testing!

openssl genrsa 1024 > host.key
openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert
cat host.cert host.key > asterisk.pem
mv asterisk.pem /etc/asterisk/keys/


-Configuramos sip.conf para poder utilizar TLS:

tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/keys/asterisk.pem


-Configuramos los peers para que trabajen con TLS. Tanto en realtime como en raw en sip.conf hay que añadir:

transport=tls (por defecto es UDP)


-Configuramos nuestro SPA5XX para que utilice TLS:

Ya tenemos señalización segura entre Asterisk y los terminales!! ;P
Para asegurarnos capturamos en el puerto 5061 y no vemos “nada”:

....J...F..Mg|.L^
...E}.....A...d.|.~...... l..i9.j,..q"..............&./....5................0..~0...................0...*.H........0..1.0...U....ES1.0...U....Vizcaya1.0...U....Erandio1.0...U.
..Irontec1.0...U....VozIP1.0...U....Irontec1 0...*.H........vozip@irontec.com0...110215125446Z..210212125446Z0..1.0...U....ES1.0...U....Vizcaya1.0...U....Erandio1.0...U.
..Irontec1.0...U....VozIP1.0...U....Irontec1 0...*.H........vozip@irontec.com0..0...*.H............0........>.S.51...bND.J..Q..O.).-t.."~x..g&^t....E.*..@..n.jF...v.t.<....Zf...%Y.......[...[....HE.e....9..8...qc..|(...P.....*.c4>.V..........0..0...U.........En?.0.%.^......
.0....U.#...0.......En?.0.%.^......
.......0..1.0...U....ES1.0...U....Vizcaya1.0...U....Erandio1.0...U.
..Irontec1.0...U....VozIP1.0...U....Irontec1 0...*.H........vozip@irontec.com...........0...U....0....0...*.H............T.-F....R..2%.....T......=9.ye.z..6.0............i...O;.../s..e.........S.6.31......!iT......N....]........>XNt....Z...MHKH3...K.........


**SRTP**
-Para configurar SRTP tenemos que poner la directiva ‘encryption’ en los peers (ya sean realtime o en sip.conf)

encryption=yes

-En los SPA5XX hay que tocar 3 valores. Esto es configurable al menos, desde la versión 7.4.3 del firmware (OJO! que se aplica para todas las líneas configuradas):
+SRTP Method: s-descriptor

+Secure Call Serv: yes

+Secure Call Setting: yes

Voilá! Ya tenemos SRTP configurado!
DETALLE: No hay modo opcional de SRTP para Asterisk, es decir, si está encryption activado en el peer no aceptará audio no cifrado y al contrario. En los terminales en cambio, si está el cifrado configurado, pero no el peer como tal, las llamadas entrantes se establecerán sin problemas. No así, las salientes, porque el terminal hemos dicho que tenía SRTP activo y para Asterisk no. En los Snom se puede utilizar también el modo ‘Optional’ para el SRTP (envía dos atributos m=audio con y sin SRTP), pero Asterisk no sabe manejar estos SDP… :S

4. Pruebas
Para probar todo esto lo más fácil es capturar tráfico en la red y después verificar con WireShark, OmniPeek o cualquier otro software si vemos la señalización en claro y si podemos escuchar las conversaciones.
En los test realizados en nuestro lab, nos encontramos con un Warning (no siempre) en el CLI, pero en principio todo funciona como debe.

WARNING[25205]: res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: authentication failure

Estamos debuggeando este último punto para ver que puede estar provocándolo…

**Curiosidad**
Los CiscoSPA5XX cuando están con SRTP activado, reproducen una especie de “beep” tres veces al principio de la conversación y muestran en pantalla un $ como símbolo de conversación encriptada. Un ejemplo:

Al final ha quedado un post un tanto largo… pero bueno, esperemos que sirva a alguien! ;P
Como siempre, cualquier duda/consulta/crítica será bienvenida.

Un saludo!

Por nuestra parte, todas las instalaciones y proyectos que realizamos los basamos (entre otros temas) en Asterisk RSP , que funciona a las mil maravillas.

En las instalaciones grandes, hay muchos puntos que deben ser controlados al milímetro, para que salga a la perfección, pero a parte de “funcionar”, la preocupación obvia es la estabilidad. Así que hemos decidido ir publicando un poco nuestros pasos y experiencias, que estamos teniendo en “pequeños” proyectos, que no utilizan todo Asterisk en sí o no son permanentes.

Por el momento, hemos utilizado Asterisk 1.8 en dos proyectos:

• Votaciones para Bandenlehia 2010
• Karaoke 2.0 multitudinario 2.0 en Santo Tomás para Xaramela

La experiencia ha sido muy positiva, no hemos tenido ningún problema especial. Eso si, no utilizábamos ni real time, ni CDR de transferidas, ni pickup, ni mil BLFs, ni nada típico de PBX …

Lo que hemos utilizado en el primer caso ha sido:

• Recepción vía ITSP (SIP) de varios números (vinculados a 900).
• AGI’s simples para guardar / checkear intervalos, etc …
• En total, se recibieron 41.300 llamadas aprox en apenas 3 horas.

En el segundo caso:

• Recepción vía TDM, de 16 PRIs (EuroISDN).
• Grabación concurrente simúltaneas de todas las llamadas (utilizando Ramdisk a tope).
• (luego todo un tema de ffmpeg/sox del mágico Fabrice Bellard, pero no es de Asterisk )

Como véis, la experiencia no es que sea totalmente concluyente y todos a migrar a 1.8, pero es un primer pasito, para ir viendo datos de lo que se puede hacer. La verdad, es que ambos casos eran para eventos muy concretos y nos la jugamos un poco, pero todo salió bien, con fé ciega . Las funciones o módulos involucrados no son numerosos, pero la cantidad de llamadas procesadas sí. Está claro que es cuando mezclas muchas partes de Asterisk cuando puedes tener una race condition, un memory leak perdido o algo díficil de detectar, pero bueno, vamos viendo luz

De cara a ir migrando nuestra solución IVOZ , e ir haciendo proyectos de IP PBX Corporativo o Callcenter, todavía queda mucho (CEL, TLS/SRTP, …), pero poco a poco iremos testeando cada parte, para ver si podemos llegar a tener ciertas certezas:)

En este caso nos vamos a centrar en una feature simple pero que los clientes que provienen de centralitas comerciales suelen echar en falta. La actualización del CLID en transferencias. Hablamos en todo momento de transferencias atendidas y realizadas mediante REFER-s, es decir, transferencias a través del propio terminal y no a través de las features nativas de Asterisk.
Para que funcione, hay que configurar un par de cosas en sip.conf:

• Si queremos utilizar la cabecera SIP Remote-Party-ID:
  sendrpid=yes o sendrpid=rpid (es lo mismo)
• Si queremos utilizar la cabecera SIP P-Asserted-Identity:
  sendrpid=pai
• Obligatoriamente:
  directmedia=update

Es necesario configurar directmedia a update (además del sendrpid) para que Asterisk envíe mensajes SIP de tipo UPDATE ya que si envía INVITE-s (re-invites para decir que el audio está en otro punto) recibimos un mensaje 500 (Internal Server Error) por parte del terminal de destino final. Es decir, cuando se hace el REFER Asterisk le envía un INVITE al destino final diciendo que el audio lo tiene él, para acto seguido enviarle otro INVITE (CSeq+1) diciendo que el audio está en otro terminal (PtP audio). A este segundo INVITE es al que el terminal responde con un 500.
Espero que en la siguiente imagen se entienda mejor:

Ahora la captura SIP completa con “directmedia=yes” & “sendrpid=yes” donde:

Asterisk => 10.10.0.165

C phone (300) => 10.10.0.142

B phone (200) => 10.10.0.177

A phone (100) => 10.10.0.167

Esta vez, la captura SIP completa con Ngrep y “directmedia=update” & “sendrpid=yes/pai” donde:

Asterisk => 10.10.0.165

C phone (300) => 10.10.0.142

B phone (200) => 10.10.0.177

A phone (100) => 10.10.0.167

No me es posible presentar la captura con una imagen como la superior (el software omnipeek no “ve” los UPDATE-s), así que os dejo unas trazas en los siguientes enlaces:
Traza SIP con sendrpid=yes
Traza SIP con sendrpid=pai

Después de tanta traza SIP, comentar también que no sirve cualquier terminal (o mejor dicho cualquier firmware¿?), tiene que aceptar UPDATEs. Con los Cisco SPA5xx funciona a la perfección. Los Linksys SPA9xx no aceptan Updates y algunos Snom y Aastra tampoco… aunque tampoco me he puesto a jugar demasiado con la configuración de estos últimos.

Como se ha comentado en la entradilla del post, aquí se habla en todo momento de transferencias atendidas. En el caso de transferencias semi-atendidas (xfer->dial->xfer sin haber establecido la segunda llamada) funciona a la perfección en cualquier caso. Me explico, utilicemos audio PtP o no, bien con UPDATEs, bien con INVITEs, Asterisk envía un UPDATE para actualizar los datos de sesión cuando la segunda llamada no ha sido establecida, por lo que el CLID se actualiza sin problemas. Las transferencias ciegas también funcionan correctamente (en la versión 1.8.0 había un Bug que se solucionó más tarde).

Espero haberme explicado bien. Estamos aquí para cualquier duda/sugerencia o corrección.

Un saludo.

Tal y como comentábamos en su inicio, Asterisk-ES-RSP continua aportando su granito de arena corrigiendo bugs que reporta la comunidad e implementando funcionalidades interesantes, inexistentes en la versión base de esta release.

Para aquellos que aún no lo sepáis, el código fuente de Asterisk se descarga ahora del repositorio de Digium y después son aplicados los parches creados por el grupo. Todo esto se lleva a cabo a través del autopatcher. Después de la descarga del código y la aplicación de parches, la instalación de Asterisk no varía con respecto al método habitual.

Recién salidos del horno, comentamos tres nuevos parches ya commiteados y otros dos a la espera de ser probados por todo aquel que esté interesado en ellos. Esta vez nos hemos centrado en la cara más ‘callcenter’ de Asterisk. Los últimos parches commiteados son los siguientes:

- Bugfix: Solución del segfault generado al hacer una transferencia en asterisk-es-rsp desde una sala de conferencias.

Una pequeña modificación en el parche chan_sip-ironxfers.patch evita los segmentation faults en este escenario.

- Feature: Backport del soporte de shared_lastcall para colas.

Seguramente más de uno de vosotros ha tenido problemas al tener un agente atendiendo varias colas  con diferente tiempo administrativo. Asterisk consulta el tiempo de la última llamada atendida por el agente y verifica si éste es superior al tiempo administrativo (wrapuptime) de la cola que se tiene que atender ahora, sin tener en cuenta el wrapuptime de la cola donde fue atendida.

Desde las versiones más recientes de Asterisk, nos hemos traído esta funcionalidad que hace cuadrar los tiempos administrativos de los agentes en este escenario.

Esta funcionalidad hace que la disponibilidad del agente sea calculada en función del tiempo administrativo de la última cola atendida y no aquel de la cola que se quiere atender.

1 Point!

- Feature: Backport de la opción ‘R’ de la aplicación ‘Queue’.

Para aquellos que buscáis el comportamiento de los callcenters tradicionales, esta funcionalidad hace que el llamante escuche tono de llamada en lugar de música en espera cuando el terminal del agente está sonando.

Ya podéis disfrutar de estás funcionalidades siguiendo estas instrucciones.

Recordad que el branch a descargar sería el siguiente: http://asterisk-es-rsp.irontec.com/svn/asterisk-es-rsp/branches/asterisk/1.4.24.1/autopatcher/

A continuación listamos los nuevos parches subidos al team doktore y que están siendo probados  antes de ser commiteados:

- Feature: Backport de la función QUEUE_MEMBER.

Nos gusta saber si hay agentes disponibles antes de meter la llamada en cola. Por ello hemos añadido esta funcionalidad. Si conocemos la disponibilidad de los agentes antes de entrar en cola, podemos mandar la llamada a otra cola donde sí pueda ser atendida inmediatamente y así mejorar el nivel de servicio. Por otra parte, si sabemos antes de entrar en la cola que todos los agentes están ocupados podemos advertírselo al llamante con una locución antes de ejecutar la aplicación ‘Queue’.

Como aditivo a la función original, este parche hace uso de la funcionalidad shared_lastcall comentada anteriormente para tener en cuenta los escenarios de agentes atendiendo múltiples colas.

- Feature: Mostrar el ‘state_interface’ del miembro de la cola al hacer un ‘queue show’ desde el CLI.

Esteroides para complementar el primer parche de asterisk-rsp (app_queue-state_interface.patch). El nuevo parche (app_queue-state_interface-queueshow.patch) nos permite ver desde consola el interfaz de estado de un miembro definido como Local/ y así conocer el terminal desde donde está atendiendo las llamadas. Supongo que aquellos que trabajéis con grandes callcenters lo agradeceréis!

Para aquellos que queráis probar estos dos últimos parches podéis descargaros este autopatcher modificado que los aplica y después instalar Asterisk  del mismo modo que siempre.

Esto es todo! Felicidades a asterisk-es-rsp y gracias por vuestro feedback y vuestros bug reports!

En una palabra (en inglés): awesome! Creo que no podía haber estado mejor. Me lo he pasado en grande y he tenido la ocasión de conocer a gente muy interesante y de poder intercambiar experiencias con otros tantos AstriFrikis.

El plato fuerte del AstriCon suelen ser las charlas y así ha sido éste año. No obstante, éste año no han ido tan ligadas al lado técnico y he tenido la ocasión de asistir a charlas extrañamente interesantes como por ejemplo chan_skype + Google Wave (con IAX2 de por medio) y el API de calendarios de Asterisk. He podido comprobar (con alegría) que finalmente el API de calendarios de Asterisk no es nada intrusivo con el core y se ha quedado en cuatro resource modules. Bien. También me sorprendió mucho la charla sobre OpenBTS, pero hay charlas y charlas y esa si que era de las segundas.

Otro de los puntos importantes era el hecho de que Asterisk cumpliera 10 años. Se armó una buena fiesta, con concurso, tarta, ¡y salchichas para todos! No faltó de nada, hasta nos dieron una medalla y un collar a lo hawaiano

Por último he de agradecer a todos el apoyo mostrado antes y tras el par de charlas que tuve la ocasión de dar. No me lo esperaba así ni en el mejor de mis sueños, ¡gracias!

A todo esto, ¿ya sabréis donde hay que ir de vacaciones el año que viene no? ¡Al AstriCon 2010!

Lo que vamos a intentar es tener controlado el log de todo el sistema, incluyendo Asterisk, su dialplan, los agis y cualesquira herramientas que usemos. Los objetivos son claros:

• Tener todos los logs relevantes en un lugar unificado de tal forma que podamos seguir la pista a las llamadas o a los errores sin tener que hacer merges mentales de múltiples fuentes.
• Tener los logs marcados y clasificados de tal forma que podamos encontrar de forma cómoda y sencilla cualquier información puntual que necesitemos.
• Loguear todo lo que ocurre en la plataforma remotamente relacionado con el flujo de las llamadas y el correcto funcionamiento de las mismas.

En este post vamos a ver un ejemplo de cómo hacer esto con un criterio arbitrario. Se pretende que cualquira pueda adaptar este ejemplo a sus necesidades. En este ejemplo vamos a querer:

1. Los logs generales del sistema para ver que todo es correcto. Esto es, el syslog. Deberemos filtrar cúales de los servicios del sistema que loguean al syslog queremos ver y cuáles no.
2. Los logs relacionados con el flujo de una llamada. En este caso vamos a suponer que dialplan y agis.

Todo esto lo vamos a hacer a través del syslog del sistema y las opciones que nos brinda para filtrar y etiquetar los logs.  ¡Manos a la obra!

Logger de Asterisk

Asterisk tiene una herramienta para configurar los logs que genera. Se configura en el fichero logger.conf. En el fichero podemos configurar los niveles de log que queremos que asterisk muestre en consola, en el fichero messages y en el syslog. Independientemente de lo que habilitemos para consola y para el fichero messages -nunca hay suficientes logs- vamos a activar y configurar el logging a syslog de tal forma que asterisk loguee ahí los errores y los warnigs. No nos interesa más información porque el log de los flujos de llamada lo vamos a gestionar de forma manual a fin de tener la información que nosotros deseamos de una forma más limpia.

Como se puede ver, las dos primeras líneas hacen referencia al CLI y al log normal de Asterisk. La última línea, que es la que usaremos, indica a Asterisk que loguee los mensajes de severidad Error y Warning a syslog con la facility Local5. De esta forma ya podremos ver en el syslog errores de parseo, de los channels, si no hemos cerrado un paréntesis y demás. Pero no podremos seguir el flujo de las llamadas ya que no tenemos ni verbose ni debug.

Este sería un ejemplo de lo que aparece en syslog cuando se hace un dialplan reload de Asterisk:

Oct 16 09:51:35 callcenter asterisk[15238]: WARNING[15309]: pbx_config.c:2276 in pbx_load_config: No closing parenthesis found? 'Macro(setgroup-in'

En vez de ver todo el reload en la consola con todas las extensiones, veo que me he dejado un paréntesis sin cerrar en el dialplan. Lo mismo pasaría para el resto de errores y warnings comunes durante las llamadas.

Log de los Agis

Cada vez más, a medida que desarrollamos nuestro Asterisk para darle más funcionalidades, debemos ejecutar más Agis. Los Agis son parte normal del flujo de una llamada y por tanto es de esperar que si queremos seguir la pista a cuanto ocurre en las llamadas de la centralita, sepamos lo que pasa dentro de esos Agi.

Todos los leguajes de programación tienen sus funciones para loguear a syslog. En este ejemplo vamos a usar Agis escritos en PHP. Generamos una pequeña clase que gestione los logs tal y como queremos que aparezcan en nuestros ficheros:

Tenemos una función doLog a la que podremos llamar para que loguee lo que nosotros le pasemos como parámetro al Syslog. Además, enviará un correo por todo mensaje que no sea de tipo DEBUG para avisar de que algo no funciona como debería. Sólo queda ver hacer llamadas de log en los Agi para tener el flujo controlado y logueado. Por ejemplo:

Este sencillo Agi, comprueba si un usuario dado como parámetro existe en la tabla tablausuarios y setea la variable de canal EXISTE_USUARIO a “SI” o “NO”. Como podemos ver, se hacen múltiples llamadas a la clase de log a lo largo del Agi para poder seguir el flujo de la llamada en el mismo y no hacer que éste sea una caja negra desde que se le llama en el Dialplan hasta que termina y devuelve el control. Las llamadas a la función de log reciben como parámetros:

• Uniqueid de la llamada para poder discriminar fácilmente entre las mismas. Ya samos que no es único pero también sabemos que es lo bastante único.
• Nombre del fichero Agi.
• Línea en el fichero Agi en el que se encuentra el log.
• Severidad del mensaje. Cuando no hay un problema ponemos LOG_DEBUG ya que en nuestro caso cualquier otro causa además del log, un envío de correo avisando de que algo ha ido mal. Existen diferentes niveles de severidad que vienen dados por las funciones de llamada a syslog del lenguaje en particular.
• Mensaje que queremos que se grabe.

Una vez tenemos los Agi bien comentados y las llamadas al log bien pensadas, podemos ver cuanto pasa en un Agi mirando el Syslog:

Como podemos ver, hemos llamado al Agi y le hemos preguntado por un usuario que no existe. En el log podemos ver:

• Fecha del log.
• Nombre del host.
• SyslogTag, una marca para poder clasificar los logs, en este caso “ivozlog”.
• Uniqueid de la llamada, para poder trackear una llamada en concreto.
• Nombre del fichero de Agi que ha generado este log.
• Línea dentro del Agi donde estaba el mensaje de log, muy útil en Agis grandes.
• Mensaje informativo.

Como podemos ver, tenemos toda la información necesaria para poder ver el flujo que ha seguido una llamada en concreto en los Agi por los que ha pasado. Sin embargo, no hemos terminado con los Agi ya que sólo hemos controlado errores de programación y de conexión. Tenemos controlados los errores y los flujos pero no estamos aún preparados para los errores incontrolados tales como excepciones.

La librería de Agi más popular es sin duda phpagi. Esta librería permite además avisar de errores incontrolados y fallos en la comunicación con Asterisk mediante un correo electrónico. Es muy sencillo modificar la función de manejo de errores de phpagi.php para que loguee a syslog con el tag y el facility que nosotros queramos:

Y por fin lo único que quedaría sería decir al propio PHP que loguease los errores propios del lenguaje en syslog para de esta forma terminar de controlar todo lo que puede pasar en un AGI. Esto ya es propio de cada instalación de php en cada distribución así que símplemente lo dejamos como comentario.

Log del dialplan de Asterisk

Como hemos comentado, sólo tenemos de Asterisk los errores y los warnings. No tenemos información detallada de lo que pasa con una llamada ya que en alta carga el log de Asterisk y la consola se vuelven a efectos prácticos, inusables. Casi todos hemos usado la aplicación NoOp para ir poniendo mensajes que más tarde nos ayuden a debuguear visualmente el flujo de las llamadas. En este caso y dado que lo que queremos es unificar los logs en el syslog, vamos a reemplazar Noop por una aplicación que loguee a Syslog.
Asterisk dispone de la aplicación Log, que usa el logger de Asterisk para hacer sus cosas. Sin embargo, esta función nos deja poco control y es poco flexible para nuestras necesidades. En su lugar vamos a usar una aplicación  que aunque no es oficial de asterisk,  es fácilmente integrable en cualquier asterisk 1.4 y además ya viene se serie en asterisk-es-rsp: app_syslog.
La función app_syslog se pensó para poder loguear al Syslog directamente desde dialplan. Acepta gran cantidad de parámetros y al llamar directamente a Syslog y no usar el log de asterisk es enormemente rápida, ligera y flexible. Para instalarla símplemente hay que copiar el app_syslog.c a la carpeta apps de Asterisk (a no ser que tengamos las últimas versiones del branch principal de asterisk-es-rsp) y escoger su compilación al hacer “make menuconfig”, ya que al no ser una aplicación oficial de asterisk se decidió que no se compilase por defecto.

El uso de la aplicación es bastante sencilla:

En este caso, no vamos a cambiar de facility, ni de tag… por lo que los parámetros los guardaremos en variables globales y haremos las llamadas a Syslog desde nuestro dialplan de forma sencilla:

Y El resultado en el Syslog sería tal que:

De tal forma que ahora sí que podemos seguir un flujo de llamada de forma ordenada desde el Syslog del sistema.

Poniendo orden en el Syslog

Hemos hecho que nuestra centralita loguee todo al Syslog del sistema. Tenemos enormes cantidades de información en el fichero /var/log/syslog, pero esa información únicamente está marcada. Aún nos queda poder filtrarla (sin greps por favor), y tenerla en tamaños manejables ya que la inspección del fichero de syslog va a ser un caos mucho mayor que mirar la consola de asterisk, cosa que queríamos evitar desde un inicio.
Como herramienta de Syslog vamos a usar rsyslog, el programa de viene por defecto en Debian. Vamos a repartir los logs entre diferentes ficheros de tal forma que tengamos todo un poco más repartido. ¿Repartido? ¿No queríamos unificar todo?
En estos momentos tenemos los siguientes logs marcados de la siguiente manera:

• Log de errores de Asterisk con facility Local5, tag “asterisk”.
• Log de los agis con facility Local6, tag “ivozlog”.
• Log de errores de phpagi con facility Local6 y tag “phpagi”
• Log del dialplan de Asterisk con facility Local5 y tag “asterisk”
• Todos los demás logs del sistema con sus facilitys, y sus tags

Vamos a hacer que los errores (Local6) vayan a un fichero y los mensajes de flujo de llamadas (Local5) vayan a otro fichero. De esta forma tendremos más separado lo que es el error incontrolado de lo que es un debug o error controlado (que por otra parte ya se nos notifica por correo).

En el fichero /etc/rsyslog.conf tenemos la configuración por defecto de un syslog. No vamos a comentar todo lo que hace el sistema ya que el manejo de syslog es algo que todos los administradores de sistemas conocen a la perfección. Símplemente modificaremos las líneas necesarias para que los logs con determinada facility sean desviados a otros ficheros y no aparezcan en el log principal mezclados con todo lo demás.
Localizamos la línea

Y la reemplazamos por

De esta forma hacemos que todos los logs con facility Local5, Local6, Local0 no aparezcan en el fichero de syslog y cada uno se escriba en su propio fichero. Tenemos las cosas más separadas pero aún así podemos ver el flujo de llamadas y errores de forma ordenada y cada uno en su sitio.
¡No hemos acabado! Tenemos ingentes cantidades de información que van a generar ficheros enormes que van a acabar por hacerse demasiado pesados amén de llenarnos el disco duro. Los logs hay que rotarlos. Nada más sencillo que crear unas rotaciones con el fichero /etc/logrotate.d/asterisk :

Esto ya va tomando forma
Del mismo modo que hemos marcado y desviado los logs de Asterisk y de nuestra programación, podemos hacer lo propio con otros servicios de tal forma que la ingente cantidad de información -nunca hay demasiada- pueda ser más manejable y tratable. Podemos quedarnos aquí o podemos ir a hacerlo mejor:

Syslog a Mysql

¿No sería mucho más manejable disponer de todos los logs en una base de datos? De esta forma podríamos integrar visores y filtros en webs de gestión de una forma mucho más sencilla, amén de hacer todas las tareas de mantenimiento más sencillas al pobre administrador que no va a tener que lidiar con docenas de ficheros o dar acceso a los logs a gente que no debe tener acceso al sistema.
Rsyslog hace esto sencillo. Lo que vamos a necesitar es:

1. Dar soporte mysql a rsyslog.
2. Crear la base de datos y hacer que rsyslog escriba en ella lo que nosotros queramos.
3. Hacer que la base de datos sea manejable.

Lo primero no puede ser más sencillo:
apt-get install rsyslog-mysql

Durante la instalación de rsyslog-mysql nos saldra un “ncurses” donde nos preguntará si queremos configurar una bases de datos … le decimos que no, que lo haremos manualmente ya que nos vamos a crear una tabla normal sino una tabla del tipo merge. Esto lo explicamos más adelante.

Vamos a crear digamos 28 tablas se1-se28 idénticas en todo excepto en el nombre, en una base de datos llamada log y creada para este propósito:

Después creamos la tabla SystemEvents que es una tabla merge de las 28 anteriores:

¿Qué hemos hecho? Hemos creado una tabla que es una unión de otras 28 tablas. Cuando hagamos un SELECT de la tabla SystemEvents, estaremos buscando en las 28 tablas y cuando hagamos un INSERT en la tabla estremos escribiendo en la tabla se1 (la primera).
Ya tenemos la tabla, ahora toca hacer que rsyslog escriba en ella los logs del sistema que nosotros queremos. Para ello vamos a crear un fichero de configuración aparte /etc/rsyslog.d/mysql.conf. Lo primero de todo es decirle a rsyslog que incluya la configuración de ese fichero. Vamos al final del fichero /etc/rsyslog.conf y añadimos (si no la tenemos ya) la línea
$IncludeConfig /etc/rsyslog.d/*.conf
En el nuevo fichero le diremos a rsyslog que cargue el módulo mysql y que loguee ciertas cosas a la base de datos log, tabla SystemEvents:

Este fichero loguea todo lo que iría al fichero normal de syslog más los facility 5 y 6 a la base de datos. Se podría haber hecho todo en una sola línea y el uso del template no es en realidad necesario (ya que usamos el esquema estandar para las tablas, el que rsyslog usa por defecto) pero de esta forma se puede tocar después de una forma más cómoda. En la web de rsyslog hay mucha documentación acerca de cómo configurar este comportamiento.
Sólo nos queda dar permisos al usuario “rsysloguser” con contraseña “rsyslogpass” en la base de datos “log” para poder reiniciar rsyslog y ver los logs en la base de datos.
¡Tampoco hemos terminado!
Por lo que hemos visto, los INSERT de Mysql se hacen en la tabla se1, por lo que las otras 27 tablas están vacías y no sirven de nada. Además, a medida que pasa el tiempo y los logs se acumulan, la tabla SystemEvents se va haciendo más y más grande y el rendimiento empieza a degradarse. Para eso hemos hecho 28 tablas: Al igual que rotamos los ficheros de log vamos a rotar las tablas de log de tal forma que todos los días vamos a:

• Eliminar la tabla se28
• Rotar todas las tablas una posición a la derecha
• Volver a crear la tabla se1

De esta forma consevaremos en base de datos los logs de las últimas 4 semanas siempre, una tabla por cada día. Además borrar una tabla es mucho más eficiente que borrar sus registros. Un pequeño script puesto en cron nos va a permitir hacer esto de forma automática:

Nota: El usuario rsyslog ha de tener el privilegio global RELOAD para que esta rotación funcione correctamente.

¿Hemos acabado ya? Realmente… sí.
Ya sólo nos quedaría usar una aplicación que nos permita ver y filtrar los logs de una forma sencilla. Podemos usar nuestra propia aplicación o usar alguna ya hecha a tal efecto como phplogcon. Este programa, no vamos a meternos en su instalación ya que es bastante sencilla y sería repetir lo que ya está explicado en su web, dispone de una potente interfaz para ver y gestionar los logs. Cada uno que use el que más le guste

phplogcon

sí que me encuentro.

Éste año se celebra la décima edición, por lo que el evento promete. Habrá charlas (como siempre) pero se ha reducido la concurrencia, ya que el año pasado había demasiadas a la vez. También tendrá su sección de expositores, donde diversas empresas expondrán sus productos y servicios. ¡Y el AstriContest!, el concurso de dialplan que éste año se realizará con terminales analógicos (are you from the past?!) y que como primer premio tendrá un terminal con Android libre. ¡Habrá que intentarlo!

Además de porque es la décima edición y porque repito (el año pasado también tuve la suerte de poder venir) éste año el AstriCon me hace especial ilusión, porque en el call for papers me aceptaron ¡dos charlas! ¡El día que recibí el mail de John Todd no pude ni dormir! Por suerte las tengo el segundo y el tercer día, así mañana puedo ir viendo cómo va el tema

Aprovechando que he venido sólo (éste año Manwe no me acompaña y he venido con familia, pero se quedan en San Francisco) voy a sacar el FanBoy que hay en mi, que una vez al año no hace daño.

Subiré fotos, twittearé, bloguaré, … vamos un eco-pack del Web2.0, stay tuned!

Es por ello, que a raíz de unas de estas discusiones se decidió crear el grupo de asterisk-es-rsp, como un proyecto de la comunidad hispana para unificar nuestros esfuerzos en tener una solución común probada, estable y participada por todos.

Asterisk-RSP NO es un fork de Asterisk. Es un branch en el que empresas y particulares aportamos parches y testing con el fin de disponer de una versión base de Asterisk realmente testeada y adaptada a las necesidades de la comunidad.

Después de varias semanas de desarrollo, el proyecto comienza a dar sus frutos. Actualmente existe un branch principal de Asterisk 1.4.24 y dahdi-linux+dahdi-tools que incluye bastantes bugfixes y funcionalidades extra respecto a la versión 1.4.24 original. Algunas de ellas contemplan:

• Soporte de RDSI BRI (tarjetas Digium, OpenVox, Beronet y Junghanns) mediante DAHDI.

• App_pickup2

• Queue_log realtime mediante UnixODBC

• Montones de bugfixes portados de las versiones 1.4.25, 1.4.26RC1 y svn-trunk

• func_devstate

• PickUp en terminales Thomson

Para aquellos que quieran participar o informarse sobre el proyecto existe una lista de correo en la que se discute el desarrollo del mismo. Un wiki está en construcción (aún está muy verde) para documentarlo, pero como siempre el log de svn es lo más actualizado que se puede encontrar.

Para descargar las fuentes:

svn co http://dev2.irontec.com/svn/asterisk-es-rsp/branches asterisk-es-rsp – -username guest – -password guest

svn co http://asterisk-es-rsp.irontec.com/svn/branches asterisk-rsp

Para ver el log:

svn log http://dev2.irontec.com/svn/asterisk-es-rsp/branches  – -username guest – -password guest

http://asterisk-es-rsp.irontec.com