Configuración SPA3102 con Asterisk 1.6.2.20

Hoy instalé un SPA3102 en mi oficina para gestionar las llamadas de la línea telefónica directamente desde los teléfonos SIP. De esta forma ya no necesito tener teléfonos analógicos. La configuración que sigue abarca solamente la parte FXO ya que no no me interesa tener un teléfono analógico conectado al puerto FXS del ATA. Por defecto el SPA3102 no permite conectarse a la pagina de administración desde remoto, así que lo primero que hay que hacer es activarla.

Digium publica su tarjeta de 8 primarios: TE820

Después de mucho tiempo sin anunciar nuevas tarjetas, Digium lanza su primera tarjeta de 8 primarios: Digium TE820, una tarjeta que permite configurar y gestionar hasta 240 llamadas simultaneas con la misma seguridad y facilidad que las de 4 primarios. La tarjeta dispone de un zócalo donde poder conectar un cancelador de eco especial para 240 canales simultaneos.

Asterisk y Arduino: la unión software-hardware perfecta

Por todo lado hay gente haciendo cosas ingeniosas, en esta ocasión Elio Rojano nos comparte el trabajo de uno de sus colegas, mezclando la electronica con Asterisk, super interesante.

Importante falla de seguridad descubierta en Interfaces Web sobre CentOS 5.x 6.x

Fernando Villares publicó un aviso de una falla de seguridad en Centos con Free PBX, he aquí la noticia:

Y Google liberó al sustituto de Skype… GoogleVoice con Asterisk

 

Google acaba de publicar en España (y en otros países) la posibilidad de hacer llamadas a cualquier número de la red telefónica desde la web, concretamente desde tu cuenta de GMail y utilizando el gadget de GoogleTalk.

Soluciones de Grabación Profesional para CallCenters (silencio, se graba)

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.

Aplicaciones XML para teléfonos Cisco SPA 5XX / 3XX con Asterisk

Cisco ha liberado un conjunto de interesantes aplicaciones para Asterisk, basadas en XML, que os pueden ayudar al desarrollo de nuevas, y/o bien a integrar interesantes aplicaciones como:

Multi-videoconferencia móvil con Fring

 

Estos de Fring no paran de innovar y es que a partir de la versio? 1.5 de su cliente para Android han lanzado una característica bastante deseada: multivideoconferencia.

No hay mucho más que decir, salvo que se recomienda un móvil con Android y con un procesador mínimo de 1Ghz. Recibe 4 señales, por lo que también es recomendable tener al menos cobertura HDSPA para que el vídeo vaya más o menos fluido.

Aquí os dejo el vídeo promocional que merece la pena ver:

Más información: http://www.fring.com

Fuente: Sinologic.net

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

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.

Mediatrix: Gateways potentes y fiables a un buen precio

 

Los gateways Mediatrix están orientados a la pequeña y mediana empresa, con capacidades que rondan desde el modelo más básico de 1 RDSI Básica hasta 2 RDSI Primarios (2xE1).