
Vamos a imaginar que queremos crear un sistema disponible el 99,99…% del tiempo, bien porque es un servicio vital para la empresa, bien porque cualquier pérdida o corte, puede provocar pérdidas económicas o de cualquier otro tipo. ¿Qué hacemos entonces?
Para eso se suele configurar lo que se denomina un «sistema redundante», es decir dos o más sistemas configurados de forma que uno de ellos sea el que está en funcionamiento, y en el caso en que deje de funcionar por cualquier motivo, se active otro de los sistemas que hasta ese momento estaba «en espera» o «inactivo» tan rápidamente como sea posible. Mediante este sistema, incluso en el peor de los casos (la rotura de un disco duro, un desbordamiento de memoria que mate un proceso vital, o incluso que alguien le pegue una patada al cable) puede seguir funcionando gracias al siguiente equipo hasta entonces «dormido».
Linux ya cuenta con muchas herramientas de este tipo, y seguramente cualquier usuario que trabaje con Asterisk o con cualquier otro servicio importante ya conocerá algunas herramientas como Heartbeat, Corosync, PeaceMaker, etc… son las más utilizadas. No obstante, hay quien prefiere utilizar virtualización para dotar al sistema de una «seguridad», por lo menos a nivel lógico (poco se puede hacer si el servidor que hospeda las máquinas virtuales se quema por una subida de tensión), pero aún así siempre se puede poner un servidor de máquinas virtualizadas en modo redundante (la cosa se empieza a complicar… pero es muy, muy seguro).
Sea como fuere, suele ser necesario al menos dos sistemas y los resultados son muy interesantes. No es un servicio digamos «intuitivo», pero siguiendo cualquier tutorial que se puede encontrar en Internet, es bien sencillo hacer tu primera prueba. Con el tiempo, configurar un sistema redundante es algo que se hace ya casi de forma automática.
En sistemas de comunicaciones basados en Asterisk es muy interesante esta técnica de redundancia, ya que (por ejemplo) un callcenter basado en un único sistema, en caso de que la tarjeta de red deje de funcionar, tendríamos a varias personas completamente paradas y todo el tiempo en que se encuentran paradas, son pérdidas de todo tipo: económica, productivas, tiempo, etc… por lo que un callcenter que dependa de una única máquina es realmente un riesgo muy, muy grande.
No obstante, si aún así contamos con dos máquinas configuradas en modo redundante (por si a alguna le da por dejar de funcionar), nos encontramos con un problema extra: las líneas de comunicaciones.
Si utilizamos proveedores IP, o gateways, igual el problema no es tan grande pero viene por otro lado (pérdidas de la conexión a internet, dependencia del tráfico del proveedor, latencia, necesidad de más ancho de banda,…), pero si utilizamos líneas de primarios, analógicas o RDSI básicas, la complejidad es diferente… ¿cómo conectamos las líneas a ambas máquinas de forma que, en caso de una parada del sistema principal, se conecte automáticamente al siguiente sistema? Vamos a ver qué soluciones encontramos…
El título dCap no es difícil de obtener pero sí requiere de conocimientos técnicos suficientemente profundos de Asterisk sin llegar a desarrollador del código. No obstante, Digium sabe que la mayoría de los usuarios que utilizan Asterisk no tienen porqué tener dichos conocimientos («un usuario que quiera certificar que sabe instalar y configurar un Asterisk básico, no tiene sentido que estudie para obtener el certificado dCap»), por lo que crearon otro tipo de certificado para usuarios de Asterisk llamado dCAA (Digium Certificate Asterisk Administrator) más básico y orientado a todos los usuarios de sistemas Asterisk.
![]()
Una persona con el certificado dCAA, se supone que sabe:
Una persona con el certificado dCAP, además de saber todo lo anterior (de hecho, se da por perfectamente dominado), debe conocer además otros conceptos más profundos: comunicaciones PSTN de cualquier tipo, protocolos de VoIP a nivel intermedio, configuración avanzada de dialplan, conocimientos avanzados sobre seguridad en la VoIP, creación de AGI,… únicamente se excluye el desarrollo interno del código fuente de Asterisk, algo que probablemente solucionen con un posible y futuro título dCAD (Digium Certificate Asterisk Developer)
No obstante, si un usuario quiere obtener un certificado que indique es es un «profesional de Asterisk«, entonces no te queda otra que prepararte el examen de certificación dCap.
El pasado mes de Noviembre se celebró el Asterisk Advanced con el nuevo temario y el nuevo examen dCap que se actualiza a la versión de Asterisk a 1.8, por lo que las preguntas y pruebas están orientadas a esta versión. Como novedad con respecto a los anteriores exámenes, la corrección la hace íntegramente Digium (tanto la parte teórica como la práctica) de forma que así se «unifican» los requisitos y la «flexibilidad» a la hora de corregir. Esto no significa que sea más fácil o más difícil, cierto es que al ser un examen orientado a Asterisk 1.8, pueden preguntar cosas relacionadas con esta versión que pocos conocerán salvo que hayan trabajado con esta versión y sus novedades. También hay preguntas relacionadas con conceptos básicos y que proceden del examen dCAA.
Así que si estás pensando en obtener un título que acredite tus conocimientos sobre Asterisk, puedes optar primero por conseguir el dCAA.
Y si vas a trabajar profesionalmente con Asterisk, entonces prepárate para conseguir el dCAP. 🙂
Muchas veces hemos hablado de las ventajas que representa la VoIP, no únicamente en plan «mejores precios«, si no principalmente en servicios y nuevas posibilidades de comunicación: conexión con otros sistemas, bases de datos, mensajería, utilización de otras tecnologías, protocolos y servicios externos, facturación personalizada, y un larguísimo etcétera que daría para mucha literatura y un largo debate. Las empresas que hasta hoy trabajan en el mundo de las comunicaciones personales y empresariales se han encontrado de repente con un cambio tan radical en su «modus operandi» que se han visto obligados a plantearse algo importante: Mantener la tecnología y morir de viejo, o aceptar el cambio y empezar de nuevo intentando no llegar tarde y aprovechar la experiencia de usuario acumulada de tantos años.

De repente, los que trabajamos con VoIP y telefonía tradicional nos encontramos con una separación infranqueable: la telefonía tradicional es completamente distinta a la VoIP. No solo a bajo nivel (señalización), si no en la forma de funcionar: No es cuestión de conectar un cable, en el mundo de la VoIP «ya no se conectan teléfonos», se conectan ordenadores con forma de teléfono. Ordenadores pequeños, computadoras, sistemas empotrados con varios tipos de servicios: web, telnet, ssh, ftp, tftp, dhcp, etc… que tienen su lógica de red como un concepto fundamental (dirección IP, máscara de red, clientes NTP,…) que tienen un firmware que realmente es un sistema operativo con una programación bastante compleja y que incluyen estructuras y librerías tan «difíciles de entender» como una pila SIP para poder mantener una conversación con otro sistema situado en cualquier punto de la red o incluso con otro terminal SIP sin necesidad de una centralita ni ningún otro tipo de sistema. (más…)
Una de las cosas recomendadas para ver el potencial de Asterisk, comprobar si todo funciona correctamente y hacer pruebas, es instalar la última versión disponible, aplicarle una configuración que tengamos ya, adaptarla a la nueva versión y ver los cambios que trae dicha versión, para ver cómo poder exprimir estos cambios, con objeto de aplicarlo a los distintos proyectos que surgen.
En muchas ocasiones, la última versión no es seguramente la más idónea para utilizar en un proyecto, pero es imprescindible conocer el comportamiento, las características y las novedades que trae la última versión. Si un cliente nos pidiera una característica que únicamente trae la última versión, ¿le vas a decir que no se puede porque no viene implementada en la versión antigua que utilizas habitualmente? muy al contrario, lo importante es conocer las novedades, ir siempre un paso por delante y hacer el mayor número de pruebas posibles para cuando la versión se convierta en «estable», poder utilizarla con conocimiento.
Vamos a explicar los pasos que hay que seguir para tener un sistema completo con la mayor cantidad de características posibles habilitadas. Esto seguramente no sea práctico ¿para qué queremos un sistema Asterisk con absolutamente todas las características habilitadas?, pero bueno, seguramente para hacer alguna prueba o una demostración, nos puede servir. 🙂
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.


Pese a que la tarjeta tenga 4 puertos, el hecho es que utiliza un conector especial para conectar dos primarios por cada conector. (cada primario necesita 4 señales de los 8 pines que dispone el conector – el resto de pines se utilizan normalmente como masa) por lo que en este caso, todos los pines del conector se podrán utilizar para duplicar el número de primarios que pueden ir por cada puerto.
Las nuevas TE820 únicamente tienen una versión: PCI-Express (PCIe) y no PCI normal de 5V. o 3,3V. por lo que suponemos que es debido al ancho de banda necesario para trabajar con 8 E1 (16Mb/sec) aunque hoy día cualquier placa base ya trae soporte para este tipo de slots.
Recuerda que una tarjeta PCI-Express de 1X es compatible con slots PCI-Express de 2X, 4X, 8X y 16X, aunque siempre hay que tener en cuenta que algunas placas base tienen un slot PCI-Express orientado únicamente a instalar una tarjeta gráfica por lo que ese slot no suele servir.
Hace tiempo que Digium no anunciaba nuevos productos y eso es porque la investigación y desarrollo es un factor que lleva su tiempo y una fuerte inversión económica. Crear una tarjeta con capacidad para 8 primarios, 240 llamadas simultaneas (en modo E1) es algo bastante complejo y que muy pocas empresas pueden necesitar, pero que permitirá ahorrar costes y sobre todo evitar problemas frente a la utilización de dos o más tarjetas de 4 primarios unidas por el bus como aparece en la imagen. La utilización del bus sirve justamente para compartir la señal de reloj entre los distintos primarios y evitar que se des-sincronicen y existan cortes de llamadas. Con la nueva tarjeta (que también dispone de soporte para este bus) el número de primarios soportados aumenta considerablemente permitiendo utilizar una gran cantidad de primarios con menos sistemas lo que reduce el coste global de la infraestructura y mejorar el rendimiento.
El blog de la CMT nos muestra la reacción de las operadoras ante la VoIP en un estudio bastante descriptivo donde se puede ver perfectamente cómo muchas de las operadoras europeas han pasado de «prohibir rotundamente» hacer uso de softphones y protocolos de VoIP, a adquirir empresas, proveedores y ofrecer servicios basados en esta tecnología.
Por desgracia, España sigue estando a la última (a la última en la cola) de los países innovadores y pocas operadoras permiten abiertamente esta tecnología que, a pesar de que Europa haya prohibido cualquier técnica de filtrado, control y gestión de paquetes, se permite bajo condiciones tiránicas como tarifas planas abusivas de más de 60€/mes o teniendo que utilizar puertos no estándares para evitar el «bloqueo» o «limitación de velocidad».
Aquí os dejo la gráfica:

Aprovechamos la ocasión para comentar que la VoIP es casi un tema tabú en España por los mismos operadores que ofrecen estos servicios en otros países bajo una marca. No hay más que ver Orange o Telefónica, que ofrecen VoIP en Francia y Gran Bretaña, pero en España hay que adquirir tarifas planas especiales (en el mejor de los casos) para obtener una respuesta afirmativa ante la posibilidad de utilizar un software de VoIP. Si alguien quiere hacer la prueba, que llame a su operadora y pregunte si puede hacer llamadas por VoIP y verá qué respuesta obtiene (sería interesante que en los comentarios publiquéis qué os han respondido las diferentes compañías)
Además, han hecho un estudio muy completo sobre el futuro de la VoIP móvil y los movimientos que las operadoras tendrán que ir haciendo poco a poco si no quieren quedarse atrás:
ADL_OTT_Disruptive_threat_or_innovative_opportunity_v2

Desde hace varias semanas, en la barra de menú de Sinologic hemos tenido puesto un enlace al mayor evento de VoIP que se celebra en Sudamérica y uno de los más importantes de Latinoamérica: 4K-Conference.

En la 4K-Conference nos invitan al evento con una nota de prensa bastante explicativa, así que tampoco nos vamos a recrear en decir más de lo necesario. Aquel que quiera disfrutar de 4 días de formación, estar entre otros usuarios, proveedores y gurús de la VoIP, tiene la oportunidad de hacerlo en este marco incomparable que ha preparado la organización y los patrocinadores. (más…)
Skype hace oficial su alternativa para ofrecer servicios de operador IP a cualquier tipo de sistema que soporte el protocolo SIP, abriendo (no literalmente) su plataforma a conexiones diferentes a su conocido softphone con su conocido protocolo cerrado.
Skype sabía muy bien a qué jugaba cuando no renovó el acuerdo con Digium que permitía a este último utilizar el software Skype4Asterisk para conectar sistemas Asterisk a la red Skype.

Puede que haya utilizado la técnica del «pruebe ahora y compre después», permitió que los usuarios de Asterisk vieran las ventajas de conectarse a la red de Skype, poder utilizar softphones Skype de rápido y fácil acceso y conectarlos a la infraestructura de comuncaciones propia de la empresa, para después eliminar esa posibilidad, dejando a los usuarios con una fecha límite de finalización del servicio tras lo cual y, antes de que llegue esta fecha, ofrecer su producto estrella para empresas: Skype Connect.
De momento, este servicio está orientado únicamente a audio (nada de texto ni vídeo conferencia) y pese cualquier operador IP ofrece los mismos servicios a la mitad de precio, seguro que más de uno estará interesado en utilizar este servicio pese a costar prácticamente lo mismo que una llamada vía red telefónica normal y corriente.
Más información: http://www.skype.com/intl/es-es/business/skype-connect/
Siguiendo una línea de opinión personal, y tal y como prometí en el anterior artículo Porqué recomiendo Debian y no CentOS, escribo sobre porqué es mejor configurar Asterisk mediante archivos de configuración y no mediante un intefaz web generalista como FreePBX.
Como digo, esta es una opinión personal, no es una tautología ni espero llevar razón en todo. Cuando hablo de interfaces web, hablo principalmente de interfaces web de configuración de Asterisk de forma generalista: FreePBX, Asterisk-GUI, y en cierta medida, el interfaz web de configuración de Elastix entre otros, por ser los más comunes. Fuera quedan interfaces web propios, desarrollados con una orientación especial por empresas para sus clientes, o incluso otros generalistas pero orientados de forma particular tal y como explicaré a continuación que si bien me parecen sistemas ideales para alguien que quiere configurar «su propio Asterisk» para hacer pruebas, o incluso para su propia empresa, no lo veo eficiente, serio ni profesional como para ser incluido dentro de un sistema profesional de comunicaciones.
Dar gracias a todos aquellos que esperaban impacientemente un artículo como este, bien por ser un «tema flame» que causa ampollas entre los defensores de los interfaces webs y los defensores de la línea de comandos. No hay necesidad de ser extremo en ningún punto, ni ser «pro-interfaces» ni ser «pro-consola«, aquellos que son «pro-interfaces» saben que a menudo (y más frecuentemente de lo que quisieran) necesitan de una consola, y aquellos que son «pro-consola» seguro que tienen instalado un interfaz gráfico donde impera KDE o Gnome o incluso XFce o WindowMaker.
Quiero dejar claro que trabajo a diario con interfaces webs, por lo que conozco bastante FreePBX, Asterisk-GUI y otros interfaces generalistas de facturación, de grabación y algunos otros, menos conocidos, que considero proyectos perfectos para la función que deben tener: un sistema de comunicaciones pequeño, bien controlado, bien configurado y sabiendo qué hacen y cómo lo hacen además hacer lo que debe hacer. Este artículo va en otro sentido, y no critico ningún proyecto opensource que, como siempre dijo, merecen todo mi respeto y admiración tanto por parte de sus desarrolladores como el de sus usuarios.
Cuando hablo de «editar tus propios archivos de configuración» me refiero principalmente a crear tu propia configuración a mano, y no crearlo utilizando un interfaz web, no significa que la configuración deba ser mediante archivos de configuración, también puede ser vía base de datos o cualquier otra forma de configuración que permita realizar cualquier acción que deseemos o necesitemos y podamos controlar a la perfección tal y como a continuación explico.