Habitualmente, suelo encontrarme con CallCenters e instalaciones que hacen uso extensivo de grabaciones, y que muchas veces acuden desesperados con problemas de rendimiento. A partir de 40 o 50 llamadas simultaneas, empiezan a experimentar problemas de grabación, y la máquina sufre de“picos” en los cuales la llamada se entrecorta y tiene problemas de calidad.
Muchos de estos CallCenters automáticamente desisten de usar Asterisk para grabar grandes volumentes de información, al no ser capaz de conseguir sus objetivos en un simple Asterisk. Paradójicamente en la comunidad open-source, el tema hasta ahora parece no haber tenido mucho repercusión, y la comunidad ha respondido, por lo general, con silencio ante dichas peticiones, sin una solución GPL o similar que cubra este hueco de una manera efectiva.
En el lado del opensource, Orecx ha intentado hacerse un hueco con una solución gratuita (Oreka) pero se hecha de menos un mayor grado de compromiso y fiabilidad con este producto, algo descuidado al centrarse el fabricante sólo en su versión comercial (la versión opensource lleva años sin actualizarse, además de carecer de varias funcionades avanzadas de busqueda que solo se encuentran en las versiones comerciales del mismo). 
Por otra parte, de la mano de Avanzada7 , un nuevo producto, el Asterisk Recording Box, intenta hacerse un hueco en el sector, con un producto muy atractivo a un coste más que razonable, pero que depende de sus propios apliances pre-instalados (no existe versión opensource). Además de estas soluciones, varios fabricantes añaden la posibilidad de usar sus propios productos profesionales, pero ya los costes se empiezan a disparar. Extrañamente, no he encontrado en el mercado ninguna utilidad seria que, dentro de la filosofia opensource, permita esta escabilidad, garantizado que un call center puede grabar cientos de grabaciones simultaneas sin un importante desembolso económico, y sin depender de hardware o appliances externos.
Es curioso, porque a priori, implementar estas funcionalidades no parece complicadas, limitándose realmente el mayor trabajo a hacer un interfaz atractivo de busquedas (por supuesto usando AJAX / Dojo), y unas pocas funciones diferenciadoras (gestion de permisos, busquedas, archiving), ya que el principal escollo, la grabación escalable de cientos de llamadas en Asterisk, NO es díficil de conseguir con la máquinas actuales y por supuesto, con un experto consultor Asterisk que sepa realizar una configuración avanzada. De hecho, a muchos les cuesta creerme cuando les argumento que bien configurada, una centralita asterisk puede llegar a grabar hasta 500 conversaciones… y ahorrarse de esta forma el desenbolso (muchas veces muy importante) de terceros productos, pero os aseguro que es posible, y sin recurrir a complicadas técnicas, conseguir una solución totalmente gratuita. Para los incrédulos, una anotación: la forma de efectuar esta configuración está basada en un conocido post de Matt Roth, junto con el entorno de pruebas utilizado, y sus conclusiones (y diferentes configuraciones basadas en ellas) son utilizadas por numerosos call centers a lo largo del mundo.
¿ En que consisten estas técnicas avanzadas de grabación ?
El truco está en conocer bien las diferencias de las dos aplicaciones usadas por antonomasia para grabar en asterisk: El MixMonitor y Monitor, usándolas adecuadamente. Siempre que se graba en Asterisk (bien en colas, bien usando directamente dichos comandos, o bien en el dialplan), usamos estos comandos y de hecho, puede configurarse como se hace internamente uso de ellos. Recordemos que mientras el primer comando graba de forma automática ambos canales (el de salida y el de entrada), el último los hace de forma separada, uniéndolos solo al terminar la grabación, a través del SOX (una conocida utilidad Unix). El primero, por tanto, usa mas ciclos de CPU durante la grabación, el segundo, producidará un “pico” de esa CPU solo al final de la misma………dado que la potencia de las CPUs actuales han experimentado un continuo progreso sobre las que habia hace unos años, la tendencia habitual es usar directamente este primero (el MixMonitor), a priori, mas completo. Sin embargo, pocos conocen que la utilidad Monitor, nos da mucho más jugo, ya que nos permitirá usar unos “trucos” adicionales que se traducen en espectaculares aumentos en rendimiento.
La grabación, sufre más por el acceso continuo a disco que por uso de cpu. Un rápido I/O para realizar esa grabacion (discos rápidos) es imprescindible, pero a veces, incluso con discos muy rápidos, se produce una contención en el I/O que ralentiza toda la maquina, y que hace que asterisk “sufra”. ¿Solución? Usar un disco RAM, mucho mas rápido y eficaz, para la tarea de grabación, y una vez concluida esta, pasar la grabación a un dispositivo de disco (o base de datos) ya más adecuado, evitando el riesgo de tener la grabación en un dispositivo volátil.
En este último punto, es donde podemos usar de una forma sutil la aplicación Monitor. Usandolo de forma inteligente, podemos configurarlo para que a la finalización, no use SOX para unir los ficheros de grabación, sino que use un script que sustituya al SOX y que previamente habremos modificado para mover las grabaciones del disco ram a un directorio más adecuado, o incluso mejor, a una máquina aparte (mediante nfs) , donde tendremos los ficheros en formato “raw” (los 2 canales en diferentes ficheros). En un update a su previo post, Math nos explica además como configurar de forma adecuada el nfs para obtener buenos rendimientos en esta combinación.
Las ventajas de disponer de los ficheros en una máquina aparte, son obvias en cuanto a escabilidad se refiere. Este modo de actuar nos permite hacer el proceso de tratamiento de los ficheros de audio en un sistema aparte del asterisk, evitando hacer uso de ciclos de CPU para operaciones que consumen unos valiosos recusos. La máquina puedes ser una máquina virtual, e incluso, que la misma máquina se concentrara la informacion de varios asterisk. En esta nueva instancia, podremos hacer ya el uso de SOX para unir los canales, e incluso aprovechar que tenemos una máquina dedicada a las grabaciones para “exigirle más”, así que podríamos ampliar el script para usar herramientas de conversion del audio a M3 (lo que nos permite la interesante opción de ponerle tags en el mismo audio, especificando autor, fecha, llamante, descripción, etc), y ya rizando el rizo, pasarle un PGP para firmar el audio y poder así, estamparle una firma digital que garantice el origen y fecha del fichero (algo bastante práctico para asuntos legales, y habitualmente necesario en la banca).
Idealmente, esta segunda máquina, tendrá una base de datos donde se almacenarán las grabaciones, y un interfaz gráfico (un servidor web) que nos permita hacer busquedas sobre las mismas. La base de datos tendría campos para hacer busquedas basaádose en la fecha, hora, número llamante, número destino…. datos que figuraran en el nombre del fichero. Incluso en el raro caso de que antes de categorizar la llamada fuera necesario obtener algún nuevo dato de la misma, ese mismo script que se encargase de subir el fichero a dicha base de datos podría obtener o generar datos adicionales de la llamada apoyándose en los logs de Asterisk, posibilitando así realizar busquedas mucho más complejas y por multitud de detalles.
Lo que se trata es que el proceso grabador, haga el menor trabajo posible (los ficheros prácticamente en raw), ya será la segunda máquina, dedicada a consulta de grabaciones y almacenamiento de las mismas, quien dedique sus recursos a procesar toda esta información, y facilitar tanto la categorización de las llamadas, como la busqueda sobre las mismas. El script crearía ese wav, sus metadatos (para la base de datos), y lo subiria al servidor, o procesaria incluso .wav que vienieran de otros sistemas, de hecho, lo ideal sería que el fichero .wav se subiera a un servidor de busquedas, independientemente de como se ha capturado ese fichero .wav, que podría haber sido incluso capturado usando VOIPong, SipTap, o Oreka (lo que nos permitiría que nuestra aplicación de grabación valiera para todo tipo de entornos, incluidos los no asterisk).
Un buen resumen de estas técnicas de grabacion avanzada, las podemos encontrar en la siguiente presentación . Las posibilidades son inmensas, y la oferta para cubrirlas, muy limitadas. El desarrollo de un grabador/buscador, como vemos, no es complicado para un programador avispado, pero indudablemente, para tener resultados profesionales, si tiene un trabajo extenso que hacer (y un coste), por lo que en muchos casos, en vez de desarrollos propios, las empresas prefieren acudir a soluciones como las ya mencionadas al principio de este post (sobre todo cuando la relación calidad-precio, como en el caso del Asterisk Recording Box, es inmejorable, y el soporte comercial, aun mejor). La pregunta es… ¿alguien se anima a darnos lo mismo en GPL ?
Fuente: SINOLOGIC.NET
No hay comentarios.:
Publicar un comentario