Asterisk PBX 1.6.2.X: Como autorizar llamadas internacionales con un PIN utilizando una base de datos

Hace días quería compartir este artículo publicado en Voz to Voice, espero les guste más de uno puede implementar cosas interesante a partir de este ejemplo usando obdc que nos da mas flexibilidad

Porqué encontramos bugs en versiones estables

 

Asterisk es uno de los proyectos software orientados a comunicaciones más grandes que existen actualmente, por este motivo, es uno de los proyectos en los que la comunidad tiene más importancia de la que normalmente suele tener en estos proyectos dirigidos por empresas en los que se “inyecta” dinero para pagar a desarrolladores con objeto de continuar el desarrollo y solucionar los distintos fallos que se van encontrando continuamente. Cualquiera que haya estudiado programación, recordará que un programador puede, mediante un diseño estructurado, y una buena planificación, técnica y pruebas, evitar la aparición de bugs, pero jamás se puede garantizar la “no existencia” de estos, por lo que una vez entregado el proyecto, es común que los usuarios continúen aportando su “granito de arena” ofreciendo el famoso “feedback” consistente en comentarios acerca del buen o mal funcionamiento de las características de una aplicación software.

Asterisk, como gran proyecto formado por cientos de archivos, módulos, librerías y un largo etcétera, necesita continuamente el “feedback” de sus usuarios con el objeto de identificar tan pronto como sea posible cualquier comportamiento anómalo, no contemplado y perjudicial para la mayoría de los usuarios, por lo que se pone a disposición de todo el mundo, diferentes versiones -inicialmente inestables- de forma que los usuarios puedan probar dicha versión antes de que se convierta en una versión considerada como estable, pero ¿porqué si existen métodos de detección de errores antes de publicar una versión estable, encontramos bugs en estas últimas?

 

Existe unas versiones conocidas como “team“: http://svn.digium.com/svn/asterisk/team/ en las que los desarrolladores ponen a disposición de los usuarios versiones de Asterisk con nuevas características que estos han solicitado o que el desarrollador quiere implementar en Asterisk. De esta forma, lo que se busca es que los usuarios interesados en estas características, descarguen, prueben y verifiquen junto con el desarrollador que el funcionamiento de las nuevas características son correctas y lo más estable posible (considerando que los usuarios interesados son minoría).

Una vez verificado el funcionamiento de la nueva característica, los cambios que la conforman, son aplicados a una versión “inestable” llamada “Trunk“: http://svn.digium.com/svn/asterisk/trunk/. Esta versión es considerada la “versión de la comunidad” ya que si alguien quiere aportar su grano de arena en la evolución de Asterisk, esta es la versión que puede utilizar para la caza de bugs de forma que cualquier usuario que pruebe la versión Trunk y descubra un bug, debería informar sobre él (y sobre todo, cómo ha conseguido reproducirlo) en la webhttps://issues.asterisk.org/. De esta forma, y tras solucionar los bugs de la versión “trunk”, la versión “estable” (branch) ya no incluirá los bugs más fáciles de reproducir.

Ahora bien, a modo de autocrítica, comentar que el 90% de los usuarios de Asterisk jamás han instalado la versión Trunk, el 99% de los usuarios jamás han informado de un bug en la web https://issues.asterisk.org/ pero eso sí, cuando han encontrado un bug, la gran mayoría preguntan en foros, listas y webs para buscar una solución rápidamente ya que la detección ocurre cuando han realizado una instalación a un cliente y este empieza a enfadarse, lo que nos lleva a varias conclusiones:

1.- La mayoría de los usuarios de Asterisk únicamente les interesa el producto (ad hoc) y no tienen interés en colaborar instalando versiones “inestables” y reportando los bugs que se detectan. Es decir: lo mismo les daría utilizar Asterisk, un sistema propietario, comercial o incluso una solución franquiciada tipo centralita-de-toda-la-vida, mientras eso agrade al cliente y sea rentable económicamente.

2.- Una gran cantidad de supuestos profesionales, no prueban las necesidades del cliente ANTES, y por lo tanto se encuentran con los bugs cuando están en medio de la implementación (lo que se conoce coloquialmente como ‘en casa del cliente’). Esto puede ser tanto porque no se conocen bien las necesidades del cliente hasta el último momento (lo que implica una mala gestión) o bien porque el cliente cambia sus necesidades en el último momento (lo que implica un fallo en la parte de consultoría).

3.- Otro motivo puede ser la imposibilidad de hacer pruebas, bien porque el usuario de Asterisk no disponga en sus instalaciones de los recursos necesarios para estas pruebas (un simulador de líneas), tiempo suficiente o los conocimientos necesarios para simular la instalación en local ANTES de comenzar la implementación en el usuario final.

4.- Por último (y quizá este sea el  motivo más común) es que se peca de exceso de confianza, considerando que una versión “estable” ya ha sido probada por suficiente gente y por lo tanto, se puede ahorrar el hecho de revisar si todo funciona como debería ya que -“¿porqué va a fallar algo que ha estado funcionando perfectamente en todas las versiones anteriores?”- Una mezcla entre confianza ciega,despreocupación y cierto grado de vagueza que provoca que en el último momento, cuando el “cliente final” haga de betatester involuntario de la versión estable que le han instalado y configurado, descubra con una gran sorpresa que aquello que le dijeron que funcionaba, no lo hace como esperaba. Está claro que si esta es la razón del porqué existen bugs en las versiones “estables”, no es culpa de los desarrolladores, si no de varios motivos, empezando por aquellos usuarios que no han probado la versión Trunk lo suficiente, continuando por el usuario que instala el Asterisk y que no ha verificado que todo funcionaba correctamente y por último del cliente final por haber seleccionado a una empresa que no es todo lo responsable que debería.

Por estos motivos, y como siempre se suele decir: más vale prevenir que curar, se podrían dar varios consejos para evitar situaciones embarazosas a la vez que se colabora en la estabilidad del proyecto Asterisk:

• - Intentar obtener todos los datos posibles sobre las necesidades del cliente, configuraciones completas, terminales, funcionamiento estandar del sistema y elaborar una lista completa de “pruebas” de calidad que la solución deberá pasar antes de iniciar la implementación sin “obviar” ninguna características por muy probada que esté y muy común que esta sea. (por ejemplo: no es la primera vez que aparece una versión de Asterisk donde no funciona el Pickup y se detecta demasiado tarde por no haber hecho una simple prueba de 10 segundos).


• - Intentar formarse tanto técnica como comercialmente para conocer lo que se ofrece, conocer las limitaciones y las ventajas frente al resto de sistemas para evitar ofertar lo que no se sabe hacer y hacer el ridículo cuando el cliente vea cómo preguntan en las listas acerca de algo que en la página web de la empresa se dice que se domina perfectamente.


• - Intentar simular tan exactamente como sea posible toda la instalación de forma escalada (no hace falta desplegar 500 terminales SIP) pero sí probar todas las características de cada modelo de terminal y verificar la versión de firmware que cumple con todas las características que promete el fabricante.


• - Cuando se detecte un error en Asterisk, lo primero que hay que hacer es preguntar en las listas de usuarios (asterisk-users y Asterisk-ES) por si es un fallo de configuración  o bien es un verdadero “bug” de Asterisk, en cuyo caso debemos informar de este en https://issues.asterisk.org/, por lo que deberíamos analizar los pasos que hemos realizado y que nos ha producido ese error, de forma que los desarrolladores puedan reproducirlo y descubrir dónde está el error. En caso de que sea realmente un bug, serás recompensado como colaborador bug-hunter de la próxima versión estable. Por este motivo siempre es recomendable cazar los bugs en la versión “trunk”… para evitar que lleguen a la versión “estable”.

Así que la próxima vez que veas a alguien quejarse de que la versión estable tiene algún bug, párate a pensar por un momento la cantidad de personas que han descargado la versión anterior Trunk, y no lo han detectado, seguramente te de una idea de la cantidad de personas que, aun utilizando Asterisk, aprovechándose del trabajo de cientos de desarrolladores que dedican horas de forma totalmente desinteresada a este proyecto, realmente contribuyen a su desarrollo.

En una conversación en un grupo de usuarios de linux hubo una frase que me llamó la atención:

-”En el mundo del software libre, hay dos tipos de empresas: las que contribuyen de una forma u otra en el desarrollo del software libre, y las que únicamente les interesa la gratuidad del producto intentando conseguir todo el jugo posible del esfuerzo de los demás, pero que cuando les toca a ellos desarrollar algo, lo hacen como software privativo para que nadie más pueda usarlo.“

Fuente: Sinologic.net

Poderoso componente de .Net para controlar Asterisk

 

En voipinfo.org publicaron un nuevo componente, bastante interesante para el manejo del Asterisk de manera remota, bastante completo la verdad.

TELE DATA Inc. is pleased to announce the release of the AMIgo suite of components and controls for Microsoft .NET.

AMIgo offers a high level access to the Asterisk Manager Interface (AMI) and several users controls which give a visual status of the PBX elements and allows to interact with the extensions, channels, calls, queues, agents and conferences and to create, edit and manage them.

Solución PBX para el sector PYME basado en Asterisk

Le presentamos el nuevo modelo de  Centrales IP-PBX Xorcom Series XR1 con mejor desempeño y mas capacidad de llamadas concurrentes.

• La serie Xorcom  XR1 con mejorado desempeño y ahora con capacidad hasta 10 llamadas concurrentes y 50 usuarios registrados. 

• El sistema soporta hasta 16 puertos analógicos en modalidad FXO y/o FXS y puede ser instalado en paredes o rack, además puede ser configurado con puertos tipo I/O. y hasta 8 puertos RDSI BRI.

Release de Digium's Fax For Asterisk 1.2

Hola luego de varios días de no publicar nada de Voz Ip y Asterisk hoy volvemos con varios post con respecto a este tema, espero que los disfruten  los hallen de utilidad, aquí esta la versión en ingles la verdad me dió pere traducir la madre jajajaja

In Digium’s continuing quest to deliver you, our users of Free Fax For Asterisk, and our customers of Fax For Asterisk, with the best possible solution, we are pleased to announce the availability of version 1.2 of…(drum roll without suspense) Fax For Asterisk.

How has this version improved? Why, with new features, of course, hence the title of this blog post.

New features include:

DAHDI Buffer Policy Implementation -Currently requiring the trunk version of Asterisk, in addition to the 1.2 release of Fax For Asterisk, new dialplan functions to allow the setting of buffer policies to prevent fax failures on higher latency systems, e.g.:
exten => 1234,Set(CHANNEL(buffers)=”12,half”)

where “12? represents a number of buffers (each buffer is 20ms), configurable between 4 and 32, and where “half” represents the policy implementation, configurable as “immediate,” “full,” or “half.”

To use, simply set your buffer policy in your dialplan before any send/receive fax operation across a DAHDI channel.

SIP Fax Detection Options -At present, also requiring the trunk version of Asterisk in addition to the 1.2 release of Fax For Asterisk, new options are available related to T.38 session initiation. Older releases of Fax For Asterisk only detect T.38 fax upon the receipt of CNG. In practice, we’ve discovered that a number of T.38 providers send T.38 invites immediately, and never send CNG to initiate a T.38 session. Thus, the faxdetect option in sip.conf can now be set to:
no – To disable all fax detection

cng – To trigger fax detection based on the receipt of a CNG tone

t38 – To trigger fax detection based on the receipt of a SIP T.38 invite, without CNG tone

yes – To trigger fax detection based on the receipt of either a CNG tone or a SIP T.38 invite.

These changes should improve our compatibility with the wild, wild west of T.38 implementations.

New CLI Commands -New Asterisk command line interface commands are available to display the settings configured in res_fax and res_fax_digium, simply run:
fax show settings

to see your current settings.

Asterisk CLI Type Column -A “Type” column is now displayed when “fax show sessions” is run on the Asterisk CLI, informing the user whether the fax is of type “G.711? or of type “T.38.”
ECM Configuration per Provider / Peer & Configuration Moved -Error correction mode may now be configured on a per provider / peer basis. This proves useful in the case that a provider does not implemented T.38 ECM properly. Digium has observed that ECM must be disabled for T.38 faxing to work properly with Gafachi.
Configuration of error correction mode has moved from res_fax_digium.com into the res_fax.conf configuration file. Note that the default setting is still to enable ECM.

SendFax initiate T.38 re-invite -Digium observed that a number of providers or far-end systems did not send a T.38 re-invite and instead waited for the local system (Asterisk) to send it instead. The SendFax application now supports the “z” option to enable this feature. If the “z” option is set during a SendFax, then res_fax will initiate the T.38 re-invite if it is not received in 10 (ten) seconds from the far end. Digium observed that the “z” option must be used for T.38 faxing to work properly with Gafachi.
Send / ReceiveFax G.711 Fallback mode -A new fallback option “f” has been added to the SendFax and ReceiveFax applications. In the event that T.38 negotiation fails, enabling this option will cause Asterisk to revert to audio fax mode. Digium has observed this is required for some providers, like BroadVox, who provide T.38 for inbound faxing, but accept only audio faxing for outbound.
Please note that audio faxing over the Internet is very unreliable, and Digium cannot provide support for fax failures due to poor Internet connections.

New Debugging utilities -In order to make debugging easier, we’ve added two new command line capture options, one for audio faxes and one for T.38 faxes.
For audio capture, do “set fax g711cap on” in the Asterisk CLI and a stereo wav file will be created for each fax session. The resulting files will be saved in /var/log/asterisk/g711cap. To stop capture, do “set fax g711cap off.”

For T.38 capture, do “set fax t38cap on” in the Asterisk CLI and a Wireshark compatible pcap file will be created for each fax session. The resulting files will be saved in /var/log/asterisk/t38cap. To stop capture, do “set fax t38cap off.”

Ready to upgrade? Run right over to the Fax For Asterisk Download Selector and grab the new release.

Release de Fax para Asterisk version 1.1.6 liberada

Digium acaba de anunciar la nueva release del modulo de Fax para Asterisk, versión 1.1.6