Etiqueta: RDSI

Sistemas redundantes y Failover, qué son y cómo funcionan.
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…
(más…)
2011-12-15
Especificación de las líneas telefónicas en España
Muchas veces necesitamos saber valores (voltajes, frecuencias, primitivas, comandos, etc…) para entender cómo funciona una línea o porqué nuestro dispositivo no funciona como debería. Para ello, además de entender cómo funciona una línea analógica o una RDSI (ISDN) debemos conocer ciertas características fundamentales y que en determinadas ocasiones, ni los propios operadores conocen (o si lo conocen, no lo cumplen lo que provoca grandes quebraderos de cabeza).
Todos sabemos que existen unas tablas de «tonos» para que un dispositivo (véase un gateway, una PBX, etc) debe tener configurado correctamente para que cuelgue, descuelgue, detecte si comunica, si está ocupado, etc. Estas tablas en muchos interfaces se conocen con el nombre de «Regional Settings» o «Parámetros Regionales» y aunque muchos de ellos son bastante similares, hay ocasiones en que según lo estricto que sea nuestro dispositivo, y lo tremendamente variable que sea nuestro operador, puede llegar a hacernos perder el tiempo intentando hacer que un gateway cuelgue correctamente o nos envíe una señal de «usuario ocupado» de forma adecuada.
Para ello, en el caso de una línea analógica, lo ideal sería disponer de un osciloscopio electrónico y un polímetro para medir la señal de nuestra línea analógica (voltajes, frecuencias y amperaje en cada estado) y en función de los resultados obtenidos, configurar nuestro gateway correctamente, aunque no todo el mundo dispone de estas herramientas y mucho menos, de los conocimientos suficientes para obtener los datos necesarios.
En una línea digital, el tema varía bastante, ya que el protocolo de comunicación no se transmite con cambios de voltaje, amperaje y frecuencias, si no de información binaria que suele corresponderse con comandos, instrucciones que se envía el sistema del usuario con el sistema del operador. Si la comunicación entre ambos sistemas no se basan en un estándar conocido, entonces debemos saber qué ~~idioma habla~~ protocolo utiliza el operador para poder configurar nuestro dispositivo en función de los parámetros que nos ofrezca. Conectar un sistema sin conocer qué hay al otro lado y cómo funciona es como buscar una aguja en un pajar, aunque siempre podemos basarnos en el estándar.
En España, el hecho que la antigua Telefónica fuera un monopolio estatal creada con el dinero de todos los ciudadanos, sirvió para que la CMT estableciera los parámetros propios de las líneas como estándar, de esta forma, una línea analógica de la antigua Telefónica, debía funcionar exactamente igual a cualquier otra, con los mismos datos de frecuencia, voltaje, y amperaje; las líneas RDSI por su lado, se basan en el mismo principio y todas las líneas funcionan y son configuradas de igual forma.
(más…)
2011-08-25
Adiós a mISDN, Beronet finaliza el desarrollo
Los lectores más nuevos seguramente no sabrán que hace 3 ó 4 años, para que Asterisk fuese compatible con las tarjetas de comunicaciones RDSI, hacía falta un canal llamado chan_capi, del que hemos hablado en alguna otra ocasión y cuya instalación era un proceso complejo, anti-intuitivo, y no precisamente estable. Este canal era el utilizado por las tarjetas Eicon Diva, las AVM Frizt y muchas otras. Junghanns vió muy pronto que, si sus tarjetas dependían de este módulo, su implementación sería demasiado costosa y desarrolló su propio módulo QoZAP compatible con Zaptel, mientras que Beronet hizo lo correspondiente desarrollando su propia librería RDSI llamada mISDN, la misma que posteriormente utilizaron todas las tarjetas RDSI posteriores: Digium, AVM, OpenVOX, etc.
No obstante, tras la aparición del driver DAHDI y el soporte BRI incluido en el chan_dahdi de la versión de Asterisk 1.6, era mucho más sencillo configurar las tarjetas RDSI, pero recordemos que el chan_dahdi de Asterisk 1.4 no soportó señalización BRI, por lo que si queríamos tener soporte de RDSI Básicas, necesitábamos actualizar a Asterisk 1.6 o bien utilizar RSP. No obstante, como ya vimos en la conferencia del VoIP2DAY 2010, el 75% de los usuarios (o por lo menos, de los que estaban en la charla) continúan utilizando Asterisk 1.4 lo que implica que, si quieren utilizar señalización RDSI Básica, deben hacerlo a través del driver mISDN.
La empresa Beronet acaba de publicar el fin del desarrollo de sus tarjetas en el driver mISDN:
On December 31, 2010, beroNet will end all public support for mISDN and chan_mISDN for the passive BNxS0, BNxS0e, BNxE1 and BNxS0mini.
Esto quiere decir que, Beronet, como principal desarrollador de mISDN (hasta el logotipo de mISDN es similar al formato de Beronet) dejará de dar soporte a estas tarjetas en favor de las nuevas tarjetas Berofix que no requieren de ningún tipo de driver ya que funcionan de forma parecida a las Sangoma (simulando el comportamiento de un gateway), únicamente que, en lugar de utilizar un módulo compatible con H.323 (el famoso Wanpipe/Wanrouter), las Berofix utilizan el protocolo SIP.
mISDN dejó de ser utilizado de forma general cuando se hizo incompatible con kernel de linux superiores a la versión 2.6.18 a partir de la cual, requería de un compilador superior a una versión, con la que mISDN fallaba al compilar (vamos, toda una odisea), por lo que la mayoría de los usuarios empezaron a utilizar el nuevo chan_misdn, pero esto no convenció a la gente de Beronet y desarrollaron la nueva Berofix, por lo que ahora mISDN se queda sin desarrollador principal y, de momento, sin nadie que lo actualice.
Vía: VoIPNovatos
2010-12-13
Publicado LibPRI 1.4.11
Hace ya bastante tiempo que esperábamos que saliera una nueva versión principalmente por el conocimiento de algunos bugs que afectaban a la 1.4.10.2 y que únicamente estaban resueltos en la versión Trunk. No obstante, la espera se ha terminado y por fín tenemos la versión 1.4.11.
Entre las correcciones a diversos bugs que hemos padecido (por suerte, bastante retorcidos), quizás lo más interesante es sin duda el completo soporte para tarjetas RDSI Básicas en modo NT y Punto-Multi-Punto, así como una solución para evitar que el operador nos descargue la capa 2 de la RDSI para ahorrar energía, así que por fín parece que tendremos el soporte RDSI que tanto tiempo hemos esperado.
También se solucionan bastantes bugs conocidos y otros nuevos pero muy, muy interesantes.
Hora de actualizar, y recordad que tras actualizar LibPRI, hay que recompilar Asterisk. 😉
Podeis descargarlo de aquí:
http://downloads.asterisk.org/pub/telephony/libpri/
2010-05-26
Probamos el nuevo FoneBRIDGE2 single port E1/T1
Por fin hemos recibido el primer «foneBridge2 single port E1» que ha pisado nuestras fronteras y del que ya hablamos en exclusiva, y hemos decir que nos ha sorprendido bastante, no únicamente por su nuevo aspecto físico, si no por su sencillez de configuración ya que, al tener un único puerto, la configuración, que de por sí era bastante sencilla, se simplifica aún más.
Para los que no lo conozcan, repetir que los foneBridge2 no son un gateway, si no una especie de tarjeta que, en lugar de ir conectada diréctamente en un slot PCI, se conecta a la red y el sistema Linux, la detecta como si fuera otro dispositivo hardware más, por lo que no tiene interfaz web de configuración, ni le hace falta ya que, tal y como vamos a ver, tanto su instalación como su configuración es muy sencilla.
Este modelo tiene como principal ventaja su utilidad, y es que está pensado para montar sistemas redundantes ya que, al no estar «colocada» dentro de un sistema, puede ser utilizado por varios equipos en modo «Activo/Pasivo» e incluso teniendo varios equipos en modo Pasivo. No obstante, otra de sus ventajas es su precio, y es que llega incluso a ser un poco más económico que una tarjeta de un primario, por lo que seguro que será una estupenda opción.
Si te parece interesante este nuevo dispositivo, no te pierdas la siguiente review y el tutorial sobre cómo se configura.
(más…)
2010-01-28
Asterisk 1.8 se publicará el segundo trimestre de 2010
Uno de los grandes inconvenientes que ha tenido Asterisk 1.6, es el hecho de tener que leer el ChangeLog, cientos y cientos de líneas para descubrir en qué versión de Asterisk se encuentra una característica que buscamos, es algo tan tedioso que al final terminamos por desechar, bien porque no es imprescindible, bien porque la versión donde se encuentra no se ajusta a la que nos gustaría utilizar.
Russel Bryant acaba de publicar el estado actual del proyecto Asterisk donde explica el incremento del número de desarrolladores en estos últimos meses, así como una explicación mucho más completa de la política de versiones de Asterisk, cuándo han aparecido las distintas versiones de Asterisk, y cuando necesitamos esperar para la próxima versión de Asterisk 1.8.
Si hay algo que me ha gustado, es saber que la próxima rama de Asterisk 1.8 se publicará el segundo trimestre de 2010 con bastantes cambios como son:
– Habrá una única rama 1.8 a la que se le irán añadiendo las distintas correcciones y mejoras simultaneamente.
– Una vez finalizado el desarrollo de 1.8, se mantendrá esta rama durante 4 años únicamente para corrección de bugs.
– Un año después se dará por concluida esta versión.
¿Qué se consigue con esto?
En mi opinión, creo que más tranquilidad a la hora de actualizar, menos líos (ya que la última versión debería ser la más estable), y la seguridad que dispondremos siempre de todos los añadidos que vayan desarrollándose.
¿Qué desventajas tiene?
A nivel de desarrollo, corregir un bug no es tan divertido como desarrollar una nueva característica, por lo que muchos desarrolladores quizá vean que no se añaden nuevas características tan frecuentemente como se hacía con la anterior versión de 1.6.
Por último, algo que me ha gustado ha sido un resumen bastante interesante de las características que trae Asterisk 1.6 (y próximamente 1.8) bastante mejor explicada que en el ChangeLog.
Como es un tema que personalmente me interesa mucho, me he tomado la molestia de «traducirlo» para todos los que leeis Sinologic, aportando en algún que otro caso alguna aclaración o una traducción que se comprenda mejor… aquí la teneis:
(más…)
2009-11-10
Cómo instalar una tarjeta RDSI BRI con DAHDI
Un poco de Historia …
Las líneas RDSI Básicas siempre han sido una gran alternativa a las líneas analógicas por muchos motivos: flexibilidad, calidad de audio, ausencia de ruidos, ausencia de problemas de eco, y un largo etcétera que forman una de las mejores alternativas calidad-precio para aquellas empresas que quieren tener varias líneas con el mismo número.

No obstante, el hecho que en EEUU y en algunos países de sudamérica las RDSI Básicas (también conocidas como BRI) no sea un tipo de línea muy extendido ha hecho que muchos fabricantes no lo hayan tomado en serio a la hora de desarrollar sus soluciones hardware, es por esto por lo que los primeros fabricantes que ofrecieron tarjetas RDSI Básicas compatibles con Asterisk a bajo coste fueron justamente los alemanes Junghanns y Beronet, un país donde las líneas BRI son tan habituales como las analógicas en cualquier otro país.

Estos fabricantes no sólo crearon el hardware necesario si no también desarrollaron los drivers necesarios para utilizar dichas tarjetas con Asterisk. Así Junghanns creó su famoso paquete BriStuff y Beronet se centró en otro sistema llamado mISDN.
Cuando Digium lanzó su conocida tarjeta B410P, se tuvo que decantar por utilizar el sistema de Junghanns o el de Beronet y finalmente se decidió por mISDN, un controlador RDSI BRI basado en estándares abiertos y compatible no únicamente con Asterisk si no con otras aplicaciones.
Sangoma también creó su tarjeta A500 para RDSI BRI y en lugar de utilizar las opciones disponibles, continuaron utilizando su propio paquete de drivers basados en la idea de que sirviera no solo para voz, si no también para datos: wanpipe.
Junghanns dejó de ofrecer actualizaciones de su BriStuff tan habitualmente como lo venía haciendo y se echaba en falta drivers para utilizar sus tarjetas con las últimas versiones de Asterisk. Beronet por contra utiliza mISDN que actualmente no tiene apenas actualizaciones y tras las últimas versiones de Kernel de Linux (los kernels superiores al 2.6.18) ha perdido la compatibilidad y no funciona como se espera.
En este momento de incertidumbre, varios desarrolladores Digium, Xorcom, y algunos más empezaron a desarrollar los nuevos drivers para tarjetas BRI bajo DAHDI basándose en el driver de Junghanns (qozap y zaphfc) para crear el nuevo driver para la B410P bajo el nombre wcb410x dentro del paquete DAHDI.
Pero ocurre que este añadido, suponía darle soporte de BRI también al Asterisk 1.4 cuando esta versión había sido «congelada» y únicamente se puede modificar para solucionar bugs y no para añadir nuevas características, así que el soporte BRI de DAHDI sólo está disponible para Asterisk 1.6.
Entonces ahora mismo nos encontramos con un kernel >2.6.18, Qozap con una versión para Asterisk 1.2 o Asterisk 1.4 compatible sólo para tarjetas Junghanns, mISDN que no funciona corréctamente y el soporte BRI en DAHDI sólo para Asterisk 1.6. ¿Qué hacemos si queremos instalar una tarjeta RDSI BRI en 1.4?
Ahí es donde buscamos las soluciones y hay dos posibilidades:
– Actualizar a Asterisk 1.6.0.
Con lo que ya tendríamos soporte BRI con DAHDI y las tarjetas BRI serían dispositivos del mismo tipo que cualquier tarjeta analógica.
– Actualizar a Asterisk-ES-RSP 1.4.
Con lo que tendremos una versión de Asterisk 1.4 modificado con el soporte para tarjetas y señalización BRI.
Esta es sin duda la elección a tener en cuenta ya que el resto de opciones son bastante más complicadas (como por ejemplo desactualizar el kernel para que mISDN siga funcionando, o utilizar una versión antigua de Asterisk para utilizar BriStuff).
La pega de estas soluciones es que el soporte de BRI en DAHDI, tanto en 1.6 como en 1.4 es que cada fabricante utiliza un identificador para cada versión de su tarjeta, y DAHDI aún no las tiene todas, de manera que, aunque DAHDI sea compatible con Junghanns y Beronet, puede que haya una versión de la tarjeta que aún no haya sido incluida como soportada.

Dando soporte a una tarjeta BRI no reconocida por DAHDI…
Para ello, si disponemos de una tarjeta con chipset HFC y DAHDI no la reconoce podemos añadirle nosotros mismos el soporte de manera temporal editando el código fuente del driver y haciendo una simple modificación:
(Odicha tiene una explicación bastante más técnica en su página)
En el directorio del código fuente de DAHDI:
```
root@localhost:/usr/src/dahdi-linux-2.x.x.x/# cd drivers/dahdi/wcb4xx
root@localhost:/usr/src/dahdi-linux-2.x.x.x/drivers/dahdi/wcb4xx/# ls -la
total 132
drwxr-xr-x  3 root root  4096 2009-08-25 12:40 .
drwxr-xr-x 15 root root  4096 2009-08-25 12:40 ..
-rw-r--r--  1 root root 83581 2009-08-25 12:40 base.c
-rw-r--r--  1 root root   116 2009-08-25 12:40 Kbuild
-rw-r--r--  1 root root   181 2009-08-25 12:40 Makefile
-rw-r--r--  1 root root 20494 2009-08-25 12:40 wcb4xxp.h
```
Con el comando de Linux ‘lspci -vb‘ buscamos nuestra tarjeta:
```
02:0b.0 ISDN controller: Digium, Inc. Unknown device b410 (rev 01)
     Subsystem: Digium, Inc. Unknown device b410
     Flags: medium devsel, IRQ 10
     I/O ports at e400
     Memory at fbffb000 (32-bit, non-prefetchable) [disabled]
     Capabilities: [40] Power Management version 2
```
Nos fijamos en la posición que ocupa esta tarjeta (02:0b.0) y volvemos a ejecutar el comando con otros parámetros ‘lspci -vn’:
```
02:0b.0 0204: d161:b410 (rev 01)
     Subsystem: d161:b412
     Flags: medium devsel, IRQ 10
     I/O ports at e400 [size=8]
     Memory at fbffb000 (32-bit, non-prefetchable) [disabled] [size=4K]
     Capabilities: [40] Power Management version 2
```
Apuntamos el texto marcado en ‘azul’ y el ‘verde’ nos fijamos en el archivo base.c y casi por el final del archivo nos encontraremos con unas líneas como estas:
```
static struct pci_device_id b4xx_ids[] __devinitdata =
{
{ 0x1397, 0x16b8, 0x1397, 0xb552, 0, 0, (unsigned long)&hfc8s },
{ 0x1397, 0x08b4, 0x1397, 0xb520, 0, 0, (unsigned long)&hfc4s },
{ 0x1397, 0x08b4, 0x1397, 0xb556, 0, 0, (unsigned long)&hfc2s },
```
…
Cada línea representa el identificador que buscará el driver para reconocerlo como una tarjeta compatible de manera que creamos una nueva línea con la misma forma que las anteriores y colocamos los valores que nos han salido en el ‘lspci’ en las posiciones correctas.
```
static struct pci_device_id b4xx_ids[] __devinitdata =
{
{ 0xd161, 0xb410, 0xd161, 0xb412, 0, 0, (unsigned long)&wcb4xxp },
{ 0x1397, 0x16b8, 0x1397, 0xb552, 0, 0, (unsigned long)&hfc8s },
{ 0x1397, 0x08b4, 0x1397, 0xb520, 0, 0, (unsigned long)&hfc4s },
{ 0x1397, 0x08b4, 0x1397, 0xb556, 0, 0, (unsigned long)&hfc2s },
```
…
El último campo (el de color violeta) corresponde al tipo de tarjeta que vamos a configurar:

– Las Digium: ‘wcb4xxp‘
– Las Junghanns 2 puertos: ‘hfc2s‘, Junghanns 4 puertos: ‘hfc4s‘, Junghanns 8 puertos: ‘hfc8s‘
– Las Beronet 2 puertos: ‘hfc2s_BN‘, Beronet 4 puertos: ‘hfc4s_BN‘, Beronet 8 puertos: ‘hfc8s_BN‘
– Las Openvox 2 puertos: ‘hfc2s_OV‘, 4 puertos: ‘hfc4s_OV‘, 8 puertos ‘hfc8s_OV‘
– etc.
De esta manera, ya sea la versión de la tarjeta que queramos añadir (siempre que el fabricante esté soportado) podemos modificar el driver para darle soporte.
Para terminar, tan solo debemos compilar DAHDI y probar a cargar el módulo:
```
/etc/init.d/dahdi restart
```
Y al ejecutar el comando ‘dmesg’ debemos ver que la tarjeta ha sido encontrada corréctamente:
```
[122429.745539] wcb4xxp 0000:09:01.0: Identified Wildcard B410P (controller rev 1)
[122429.745539] wcb4xxp 0000:09:01.0: VPM 0/1 init: chip ver 33
[122429.759405] wcb4xxp 0000:09:01.0: VPM 1/1 init: chip ver 33
[122429.771406] wcb4xxp 0000:09:01.0: Hardware echo cancellation enabled.
[122429.771406] wcb4xxp 0000:09:01.0: Port 1: TE mode
[122429.771406] wcb4xxp 0000:09:01.0: Port 2: TE mode
[122429.771406] wcb4xxp 0000:09:01.0: Port 3: TE mode
[122429.771406] wcb4xxp 0000:09:01.0: Port 4: TE mode
```
Mi idea no es dar un curso sobre programación ni sobre DAHDI, tan solo mostrar cómo saltar un pequeño obstáculo que puede complicar la existencia a más de uno.
Configurando DAHDI para utilizar la tarjeta con Asterisk …
Una vez que veamos en el ‘dmesg’ que la tarjeta ha sido reconocida corréctamente, necesitamos configurarla, para ello vamos a editar el archivo ‘/etc/dahdi/system.conf’ y añadir las siguientes líneas para una tarjeta de 4 puertos:
```
span=1,1,0,ccs,ami
span=2,2,0,ccs,ami
span=3,3,0,ccs,ami
span=4,4,0,ccs,ami

bchan=1,2
hardhdlc=3

bchan=4,5
hardhdlc=6

bchan=7,8
hardhdlc=9

bchan=10,11
hardhdlc=12

loadzone = es
defaultzone = es
```
Si tuviesemos una tarjeta con 2 puertos, sería más simple:
```
span=1,1,0,ccs,ami
span=2,2,0,ccs,ami
```
```
bchan=1,2
hardhdlc=3

bchan=4,5
hardhdlc=6
```
```
loadzone = es
defaultzone = es
```
Para una OctoBRI pues puedes usar el sentido común para averiguar cómo sería el system.conf. ;P
El archivo /etc/asterisk/chan_dahdi.conf es prácticamente igual que cualquier zapata pero con algunas diferencias:
Para crear un grupo con nuestros canales ya configurados tan solo debemos añadir algo como esto:
```
group=1
switchtype=euroisdn
signalling=bri_cpe  ;; bri_cpe si son punto-a-punto ó bri_cpe_ptmp si son punto-multi-punto.
context=default
callgroup=1
pickupgroup=1
channel => 1,2,4,5,7,8,10,11
```
Fácil ¿verdad? 🙂
Reiniciamos de nuevo DAHDI y Asterisk y deberíamos tener ya la tarjeta perféctamente configurada y funcionando. 😀
Puedes probarlo entrando en la consola de Asterisk y escribiendo…
```
asterisk*CLI> dahdi show status
Description                 Alarms IRQ
B4XXP (PCI) Card 0 Span 1   OK     0
B4XXP (PCI) Card 0 Span 2   OK     0
B4XXP (PCI) Card 0 Span 3   RED    0
B4XXP (PCI) Card 0 Span 4   RED    0
```
Si teneis algún problema, no dudeis en dejar un comentario.
2009-08-27
Asterisk-ES-RSP: Un Asterisk ideal para producción
Hace varios meses Saúl Ibarra y Jon Bonilla propusieron una idea para un proyecto muy interesante:
Congelar una versión de Asterisk y aplicar los parches necesarios para conseguir una versión verdaderamente estable y lo más segura posible basándose en las características más comunes para un Asterisk que funcione como centralita de comunicaciones.
Quizá el debate en este sentido está servido, la versión de Asterisk que Saúl y Jon parchean está basado en Asterisk 1.4, actualmente la rama más peleada y conocida y por este motivo, esta versión pasó a llamarse Asterisk-ES-RSP (Rock Solid Patchset) y consiste en un Asterisk 1.4 con todo lo necesario que solucionan los bugs que se encuentren en las características más utilizadas como SIP, features, y DAHDI.
Nuestro compañero Odicha, una mente inquieta que empezó desarrollando algunos parches para completar el soporte de tarjetas RDSI Básicas (BRI) en Asterisk 1.4 y que hoy día es de los desarrolladores más activos de la comunidad Asterisk-ES participa también en este proyecto aportando su granito de arena para conseguir facilitar la vida a aquellos que trabajan con estas tarjetas BRI y desean utilizar DAHDI.
Otros como Javier Ximenez, desarrollando el soporte del cancelador de eco comercial SoftEco e integrándolo para simplificar el tiempo de instalación para los integradores.
Y muchas otras personas (como Silvia, Ramoncio, Ramses, y un largo etcétera) que, a través de sus pruebas, comentario y sobre todo tiempo, han venido colaborando para documentar, detectar y mejorar todo lo posible esta versión.
Cómo no, es mandatory decir que Asterisk-ES-RSP no es un fork ni tiene la intención de serlo, si no una versión de Asterisk a la que se le aplican las modificaciones para corregir los más pequeños errores que pueda tener sin añadir nuevas features que puedan provocar nuevos errores, Asterisk-ES-RSP no pertenece a ninguna empresa aunque muchas apoyan esta iniciativa, y está abierto a todo aquel que quiera participar mediante su lista de correos o su página web.
Después de 6 meses de continuo testeo, pruebas y conversión de parches es de recibo reconocer la buena labor que estas personas están desarrollando, no sólo para conseguir una versión optimizada y segura, si no además la brillante intención de ponerlo a disposición de todos aquellos que quieran probarlo y utilizarlo en entornos de producción.
Podría decir que actualmente Asterisk-ES-RSP es la versión de 1.4 más fiable que existe y la única que permite utilizar tarjetas RDSI Básicas basadas en el chipset HFC (Beronet, Digium, Junghanns, Billion, Openvox, etc) con DAHDI de una manera sencilla y sin líos de Kernel ni con el mISDN.
Si estás interesado en probarlo, tan solo debes seguir los siguientes pasos:
http://www.asterisk-es-rsp.org/doku.php/instalacion:instalacion_asterisk-es-rsp
2009-08-24
Nueva tarjeta revolucionaria de Beronet (BRI+PRI+GSM)
Pese a que conocía ya esta tarjeta, me he esperado a conocer todos los detalles, y es que Beronet llevaba prácticamente un año anunciando una tarjeta verdaderamente revolucionaria y solo disponible para betatesters y es que esta tarjeta tiene tantas novedades que hacía falta estudiarla tranquilamente y en serio para llegar a descubrir las ventajas y novedades que incorpora.
Para empezar, comentar que esta tarjeta no es como el resto de las tarjetas que conocemos, es un nuevo concepto muy interesante y que si tiene acogida, seguramente lo veremos más a menudo con otros modelos y marcas.
Se podría decir que, tras el fiasco de mISDN con los nuevos kernels, Beronet está preparando una tarjeta mucho más fácil de configurar que las anteriores, sin necesidad de compilar ningún módulo y que funciona, no sólo con Asterisk, si no también con otras aplicaciones como Kamailio, SER, y otras de dudosa calidad.
Por lo tanto, Beronet ha lanzado la primera «tarjeta-gateway» del mercado: la Beronet Berofix.
Una tarjeta con un comportamiento bastante interesante:
Cuando instalamos esta tarjeta en nuestro equipo, el sistema la reconoce como una tarjeta de red conectada a un gateway SIP, la gran sorpresa es que el gateway SIP se encuentra dentro de la propia tarjeta.
Otra de las novedades es que utiliza módulos como los de las tarjetas analógicas de Digium, pero en esta ocasión los módulos son BRI, PRI y próximamente GSM, pudiendo disponer de una tarjeta con soporte BRI y PRI sin necesidad de disponer de 2 tarjetas diferentes.
La conexión con Asterisk es trivial, tan solo debemos acceder vía web a la dirección IP de la tarjeta Berofix y configurar el gateway que incorpora para conectarse con un Asterisk, un Kamailio o incluso otro servidor situado en otro punto de la red (siempre que configuremos las rutas de red adecuadamente), por lo que esta tarjeta parece ideal para que varios equipos puedan hacer uso de la misma línea y no únicamente el que la tiene instalada.
Más curiosidades (que esta tarjeta tiene bastantes novedades):
- Soporta faxes mediante T.38 (V.27,V.29 y V.17)
- Soporta QSig bajo BRI y PRI (implementación independiente de la que trae el LibPRI) y antes de que alguien me lo pregunte… no, no soporta Call Replacement en BRI. 🙁 por lo que es prácticamente la misma implementación del LibPRI pero con soporte para BRI. 🙂 (CNIP,CNIR,CONP)
- Cancelador de eco hardware (1024 taps = 128ms) – tener un buen eco cancel hardware merece la pena. 🙂
- Dispone de 2 slots para módulos y existen módulos de 2, 4 BRI y 1, 2 y 4 PRI, y dentro de poco, módulos GSM, por lo que podríamos tener una tarjeta con 4 BRI y 4 PRI, o bien con 2 módulos de 4 PRI, una tarjeta de 8 PRI… 🙂
- Capacidad de trascoding G.723.1 y Anexo A, G.729a, G.726, alaw y ulaw
- Como dispone de un gateway interno en la tarjeta, todo el cálculo, se realiza DENTRO de la propia tarjeta, así que podemos olvidarnos de la carga del procesador.
- El interfaz web de la tarjeta nos permite configurar un dialplan, pero es muy, muy básico… prácticamente nulo… como el de los gateways. 🙂
- Soporta SIP bajo TCP y TLS.
- Bus que permite conectar esta tarjeta con otras del mismo tipo y así hacer de puente sin llegar a enviar tráfico al sistema donde está hospedado (esto realmente lo traen todas las tarjetas, tanto de beronet, como de Digium y Junghanns, pero es la primera vez que se anuncia como tal).
Si quereis ver la lista de especificaciones completa, teneis disponible la hoja de presentación.
La tarjeta saldrá oficialmente a la venta en Agosto de este año y sobre cuanto cuesta… esa es una «sorpresa» que dejaré que descubrais vosotros cuando salga. 😉
2009-07-09
Preparado para la SIP MasterClass 2009
Como ya comenté en el artículo SIP MasterClass 2009 en Málaga, mañana dará comienzo el curso Maestro sobre SIP donde se darán cita dos grandes gurús de este mundo y más concretamente del mundo SIP: Olle Johansson y Daniel-Constantin Mierla y donde los asistentes tendrán la extraordinaria oportunidad de aprender los entresijos de SIP junto con las dos herramientas más utilizadas: Asterisk y OpenSER. Aprender los secretos del protocolo SIP y la potencia de la coordinación entre estas dos aplicaciones.
En el mundo de las comunicaciones actuales existen dos ramas bastante diferentes y que se unen para ofrecer al usuario una transición lo más suave posible: comunicaciones basadas en redes de telecomunicaciones (analógicas, digitales, gsm, etc.) y comunicaciones basadas en protocolos de redes informáticas (sip, iax, h323, etc.).
Todos conocemos las ventajas de las redes de telecomunicaciones, las tenemos en casa, en el trabajo, nos permiten contactar con nuestros familiares y hablar desde cualquier sitio mediante los móviles.
En las redes informáticas, el audio y el vídeo son convertidos a datos binarios y manejados automaticamente por aplicaciones y dispositivos que se encargan de calcular prioridades, comprimir los datos y confirmar la recepción de dichos datos en el envío, aunque la principal ventaja consiste en ofrecer servicios similares a las redes de datos que ya conocemos como Internet o las redes locales permitiéndonos conectar cualquier dato que circule por esta red (música, voz, vídeo, mensajería instantanea, etc.) a cualquier otro servicio de red mucho más conocido (http, ftp, jabber, etc.).
Los proveedores de telecomunicaciones habituales ya conocen las ventajas de las redes de datos en comparación con las redes de telecomunicaciones y hace varios años comenzaron la migración de sistemas tradicionales por sistemas basados en software que manejaban protocolos IP, en lugar de protocolos ISDN, manejaban tramas de paquetes binarios, en lugar de ondas y esto lo hacen totalmente transparente para el usuario final.
Una de las ventajas de las redes de datos consiste en el ahorro en la inversión de infraestructura ya que es muchísimo más económico un sistema capaz de manejar datos que un sistema capaz de manejar líneas de telecomunicaciones y por lo tanto, nuevos proveedores llevan surgiendo desde hace tiempo aprovechando ese ahorro en la inversión y obteniendo un resultado similar al de las tradicionales empresas de telecomunicaciones, pero con un ahorro considerablemente inferior.
Universidades, administraciones y grandes empresas con decenas o miles de usuarios han aprendido la ventaja de convertir sus comunicaciones a datos y aprovechar sus redes ethernet y de Internet para realizar llamadas telefónicas y enviar faxes en el mismo medio físico por el que viajan emails y otros servicios, a la vez que permiten un control mayor y ofrecer servicios a sus usuarios que con las redes de telecomunciaciones son prácticamente prohibitivas económicamente o requieren de un nuevo sistema.
En las redes de datos, la voz y el vídeo son convertidos a datos y de su gestión se ocupa un protocolo que ha pasado a convertirse en el estandar por excelencia para este tipo de comunicaciones: SIP (Session Initiation Protocol) un estandar aprobado por el IETF (Internet Engineering Task Force) y aprobado su RFC donde se dictamina qué debe enviar y recibir para que se lleve a cabo una comunicación correcta SIP.
Los secretos de este protocolo, así como su funcionamiento y configuración en las dos aplicaciones de código abierto y libres más utilizadas del mundo, serán las bases del curso que comienza mañana en Torremolinos (Málaga), un marco ideal, ameno y atractivo donde se verán una gran cantidad de conceptos y utilidades que muchas empresas necesitan y que constituirán un antes y un después en la forma de desarrollar sus infraestructuras de comunicaciones.
En la medida de mis posibilidades, intentaré comentar desde aquí mi experiencia durante este curso que, pese a celebrarse una vez al año en España, es sin duda uno de los más duros, específicos y profesionales que existen en el mundo de las comunicaciones VoIP.
2009-06-21