La semana pasada fué aceptado para ser probado un nuevo CDR handler para Asterisk que escribà para soportar la base de datos SQLite3. Son cambios simples al anterior manejador existente para SQLite2, pero nos permitirá mantener nuestro Asterisk lo mas apegado posible a la distribución oficial.
Si alguien se encuentra interesado en probar esta funcionalidad, chequen SQLite3 CDR
Hace rato termine el documento donde describo brevemente el protocolo MFCR2 y mis experiencias con avantel. Espero le sean de utilidad a alguien para que resuelva sus conflictos y no invierta tanto tiempo, como los varios dias de investigación que tuve que invertir. Aunque ciertamente no hubiera aprendido lo mismo si hubiera existido un documento similar en la red.
Liga al documento:
Notas Sobre MFCR2 – Asterisk – Unicall
Ligas que pueden resultar de interés por su relación con el documento:
Adicionalmente aqui hay una liga a un archivo TAR donde incluyo el testcall.c modificado para recibir el parámetro del archivo de configuración como argumento y copia de algunos archivos de configuración.
Durante la semana antepasada tuvimos problemas muy latosos con una nueva troncal E1 contratada con Avantel. Utilizamos una tarjeta Digium de 4 puertos. El problema era que en ocasiones las llamadas se quedaban a medias al iniciar su establecimiento, a veces se concretaban pero se escuchaba entrecortado. Inicialmente pensamos que era un problema de hardware, sin embargo el problema continuaba aún con una tarjeta Sangoma. Después de seguirle la pista a la salida del magnifico comando strace descubri que el problema se encontraba en que algunas llamadas al sistema por medio de write() regresaban argumento inválido. Pasé muchas horas buscando la causa sin encontrarla. Después de muchas horas encontré que el driver de zaptel regresa argumento inválido si el buffer a escribir tiene longitud de cero. Con esto descarté cualquier problema en el driver, asi que el responsable era claramente libmfcr2, por que pasaba para su escritura un buffer con longitud de cero. El buffer provenÃa de una codificación por medio de ALAW de un tono generado por spandsp. Para no hacerla larga encontré el error en libmfcr2 y contacté a steve underwood, a quien ya habÃa contactado con anterioridad, pero nunca me hizo caso hasta que le envié el parche. Me indico que mi parche, a pesar de solucionar el problema, no era confiable, por que generaba un tono algo intermitente. Me dijo que en unos dias sacarÃa una versión nueva de unicall para resolver ese problema, y al fin lo ha hecho. Durante esta semana aprendà varias cosas sobre la forma de comunicación de los drivers con el kernel linux, asi como el funcionamiento interno de unicall y como se comunica con zaptel y asterisk. Aprendà también cosas interesantes sobre MFCR2. He escrito un documento que publicaré esta semana donde describo el funcionamiento de MFCR2 y como encaja en Asterisk utilizando Unicall.
Em, ya rato sin escribir, pero es que no tengo internet en casa de momento y aqui en la oficina a veces no me doy el tiempo para escribir algo en el blogg. Ahora tengo bastates cosas que decir, empezando por mostrar mis parches para Asterisk. Para ser aceptados en el repositorio oficial me han pedido firmar un “Disclaimer” y enviarlo por fax, luego que tenga chance lo envio. De momento aqui estan los parches.
1. Este parche permite definir variables del canal peer desde el canal origen. Personalmente lo hice para poder definir TRANSFER_CONTEXT desde que se origina la llamada. Pero puede ser util para otras variables.
Peer Vars Patch
2. Este parche soluciona un grave error en app_voicemail.c al pasar un puntero nulo a strcasecmp(), asi como otros errores menores en cuanto a audio
voicemail fix
3. Aqui doy soporte para una extension del comando meetme list. Con este parche se puede pasar el argumento “concise” y mostrara la informacion en un formato facilmente manejable desde lenguajes de scripting. Hecho para mostrar conferencias en curso desde interface web.
meetme list concise patch
4. Con este fix, pbx_spool.c no borra los callfiles si su timestamp cambia durante el curso de la llamada.
PBX spool fix
5. Simple parche para la funcionalidad de “attended transfer”. Lo hice por que tomamos en cuenta primero el contexto de transferencia del transferer, no del transferee. Ademas se inicializa una variable en el nuevo canal para identificar al canal que transfiere originalmente.
ATXFER fix
Los siguientes dos parches fueron modificados para aplicar a la version 1.2.1 de Asterisk
1. Soporte para MAGI(), este comando no parece haber tenido aceptacion en la comunidad, sin embargo lo considero extremadamente util. La siguiente version de nuestro sistema de ruteo esta totalmente basada en el. Permite ejecutar comandos de AGI() desde AMI.
MAGI support
2. Soporte para silence supression, altamente experimental
Silence Suppression support
es todo, el siguiente articulo incluirá un parche que modifiqué para el kernel 2.6.14, para soportar un modulo experimental de Netfilter.
saludos,
Estos dias estuve buscando como resolver la necesidad de un “timer” para que funcione la aplicación de Asterisk “app_meetme”, un módulo que te permite crear y moderar cuartos de conferencias con tantos canales como tu procesador y ancho de banda te permitan.
Existen 2 aplicaciones bien conocidas para realizar mas o menos las mismas funciones: la antes mencionada Meetme() y Conference(). Conference() hace un uso mucho mas eficiente del procesador, y no requiere de un timer; sin embargo la migración no la tenemos contemplada, asi que fué mas sencillo utilizar el driver ztdummy de Zaptel para utilizarlo como timer.
En gentoo todo lo que hay que hacer es
emerge zaptel
modprobe ztdummy
Para mayor facilidad se puede agregar en autoload para que se cargue automaticamente cuando el servidor inicie. En gentoo
echo ztdummy >> /etc/modules.autoload.d/kernel-2.6.
Si cuentas con tarjetas como FXO, E1 lo anterior no es necesario, el timer es proveido por las interfaces Zaptel.
Si se te muestra el error:
FATAL: Error inserting ztdummy (/lib/modules/2.6.x.x/misc/ztdummy.ko): Unknown symbol in module, or unknown parameter (see dmesg)
Significa que no tienes compilado tu kernel con CONFIG_CRC_CCITT=y