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.