Etiqueta: RDSI

Asterisk 1.4 o mejor Asterisk 1.6 para entorno en producción?
En los últimos meses, asistimos a un momento bastante movido en que coexisten Asterisk 1.4 y Asterisk 1.6 ambas como versiones «estables» e ideales para un entorno en producción (un sistema estable que requiere que su funcionamiento sea lo más estable posible) por lo que es habitual hacernos la trivial pregunta: ¿Utilizamos Asterisk 1.4 ó mejor Asterisk 1.6?
Por lo general, y viendo muchos de los comentarios de usuarios de Asterisk (y Asterisk-ES) la versión más estable sigue siendo Asterisk 1.4 (concretamente los usuarios dudan entre la versión 1.4.17 y 1.4.24.2) por diferentes bugs que se han encontrado (bugs en el protocolo SIP e IAX principalmente) y que su solución no ha sido incluida en posteriores versiones. Asterisk 1.6 en cambio, sí incluye estas correcciones y algunas mejoras sustanciales en componentes tan importantes como el CDR y el soporte con MySQL.
Por contra, el mundo de los callcenters ha cambiado radicalmente en 1.6 debido principalmente a la «desaparición del agente» (componente principal en todo callcenter desarrollado en Asterisk y uno de los cambios más importantes de esta versión) del que el sustituto aconsejado no termina de agradar a las empresas que trabajan implementando este tipo de soluciones, pese a que el nuevo sistema potencia enormemente las posibilidades de desarrollo, aunque eso sí, sin el conocido «Agent/xxxx». A todo cuesta acostumbrarse, pero está claro que tarde o temprano habrá que pensar en actualizarse.
Mejoras como el soporte nativa en DAHDI de señalización BRI (para las tarjetas RDSI Básicas como la B410P) son bien soportadas en 1.6 mientras que en 1.4 seguimos necesitando el conocido mISDN (que dejó de ser estable con las últimas versiones del kernel de Linux) por lo que todo este tema se complica si nos empecinamos en utilizar Asterisk 1.4 con alguna distribución actual.
Además, Asterisk 1.4 ha sido ya considerada (muy a mi pesar) «frozen release«, esto es… ningún añadido nuevo será incluido, únicamente modificaciones para mejorar la estabilidad, por lo que si algo no terminaba de funcionar (como era el CDR) el parche no será incluido si modifica el comportamiento, así que podemos olvidarnos de encontrar una versión de 1.4 que soporte BRI mediante DAHDI a no ser que apliquemos el parche a mano.
Asterisk 1.6 por contra, incluye muchas novedades aún bastante verdes y para nada deseable de ser utilizada en un entorno en producción como el «chan_mobile», el «API Calendar» o incluso alguna feature interesante como SIP bajo TCP y TLS tampoco termina de ir todo lo bien que desearíamos.
Volvemos de nuevo a la pregunta… ¿Asterisk 1.4 ó 1.6?
Yo ando en un pequeño conflicto personal, Asterisk 1.4 lo conozco mejor, conozco sus trucos y sé por donde me puede salir en un momento dado, (después de 2 años trabajando a diario con esta versión, es normal) pero tras dar los cursos de Asterisk Avanzado en Alicante (2008) y en Bilbao (2009) y viendo las ventajas y la facilidad con la que los asistentes le cogen «el truquillo» a esta nueva versión y las distintas pruebas y perrerías que le hacen durante el curso, creo que 1.6 está bastante más maduro de lo que la gente cree.
En datos contundentes: en bugs.digium.com ahora mismo hay:
52 bugs abiertos sobre la versión 1.4.24
1 bug abierto sobre la versión 1.6.0.9
Por lo que, está claro que o hay pocos usuarios enviando bugs sobre la versión 1.6, o los desarrolladores se están centrando en resolver más rápidamente estos bugs, pero se ve que tarde o temprano habrá que actualizarse y es menos traumático actualizar de 1.6.X a 1.6.X+1 que de 1.4 a 1.6, por lo que personalmente recomiendo ir empezando a meterle mano y pensar en serio lo de utilizar Asterisk 1.6 en sistemas en producción porque es evidente que 1.4 va a dejar de tener soporte en muy poco tiempo.
Como escuché una vez a un colega programador: -«A ningún desarrollador le gusta la tarea de arreglar fallos que han provocado otros, pero aún es peor si además es sobre una aplicación ya desfasada«.
¿Y tú? ¿qué versión de Asterisk utilizas?
2009-04-29
Resumen de la VoIP en este 2008
El 2007 fue un año bastante plagado de novedades, un gran boom que sirvió para dar a conocer a muchísima gente los beneficios de la VoIP, pero el 2008 tampoco se ha quedado atrás y pese a que muchas empresas no han anunciado muchas novedades por culpa de la crisis mundial, no ha dejado de ser un año con bastantes novedades.
Enero:
– Asterisk 1.4.17
– VicidialNOW, la distribución de Vicidialer
– Zoiper pasa a soportar T.38
– Monitorizando Asterisk con Monit
– Zaptel soporta 120 canales G729 en la TC400B
– Digium: Nuevas tarjetas PCIe de primarios y analógicas.
– Publicado AstJaBot v.0.1
– GrandStream lanza sus gateway 24 FXS

Febrero:
– Digium: Lanzamiento de la TDM410P
– Digium y Sangoma aumentan la garantía de sus tarjetas
– Asterisk 1.4.18
– FreeSwitch soporta SIP bajo TCP
– Siemens abandona la fabricación de centralitas
Marzo:
– Ericsson deja la fabricación de centralitas
– Diferencia entre G729 comercial y el G729 gratis
– Elastix lanza su propia appliance

Abril:
– Tutorial: Analizando datos con Wireshark
– Asterisk 1.4.19
– Curso de Asterisk en la Bootcamp Bilbao
– Asterisk-ES en LinkedIn
– Elastix 1.0 por fin estable

Mayo:
– Comparación entre H264 y Theora
– Curso de Asterisk y OpenSer en la SIP MasterClass en Barcelona
– Tutorial: Grabando tráfico RTP con RTPBreak
– LibPri soporta ISDN Básicas (BRI)
– OpenSER 1.3.2
– Se anuncia la desaparición de Zaptel en favor de DAHDI
– TrixBox deja FreePBX
– Nortel se pasa al Software Libre
– Asterisk 1.4.20
– Lanzamiento del Snom m3
– FreeSwitch 1.0 por fín estable

Junio:
– Mark Spencer en Bilbao
– Celebración del Asterisk-Tag en Berlín
– Asterisk 1.4.21
– Malos tiempos para TrixBox y Fonality
– Tutorial: Cómo testear una tarjeta de primarios
– Curso de Asterisk en Madrid (Bootcamp Madrid 2008)
– Elastix 1.1
Julio:
– Tutorial: Cómo configurar exim con Asterisk
– II Premios Digium a la innovación
– FreeSwitch 1.0.1
– Tutorial: Cómo configurar Asterisk con T.38
– OpenSer pasa a llamarse Kamailio

Agosto:
– Tutorial: Cómo instalar Asterisk y Asterisk-GUI en 20 minutos
– Asterisk-GUI 2.0
– El interés por Asterisk se duplica

Septiembre:
– Elastix 1.2
– Skype contrata a Digium para desarrollar un Chan_Skype oficial
– Curso de Asterisk en la Bootcamp Lisboa
– Cisco compra Jabber Inc.

Octubre:
– Asterisk 1.6 por fin ve la luz
– Tutorial: Todo lo que siempre has querido saber de DAHDI (I)
– Primeros tropiezos con DAHDI y Asterisk 1.4
– Fring para el iPhone
– Adiós SIMO, hola VoIP2DAY
– Snom presenta Snom 820
– Tutorial: Todo lo que siempre has querido saber de DAHDI (II)
– Monitorizar Asterisk con Nagios
– Sinologic celebra su 2º aniversario
Noviembre:
– mISDN 2.0 Released
– GMail se pasa a la VideoConferencia
– Primer libro dedicado a Elastix y gratuito
– Primer curso de Asterisk Advanced en Europa y en Madrid
– Celebración del VoIP2DAY
– Sinologic regala a sus visitantes por su 2º aniversario
Diciembre:
– Tutorial: Instalando Asterisk+FoneBridge2+Asterisk-GUI
– Asterisk cumple 9 años
– Tutorial: Todo lo que siempre has querido saber de DAHDI (III)
– Nuevos libros sobre Asterisk
– DAHDI 2.1.0
– Fin del Año para Sinologic
Este año, no ha sido tan abundante en noticias como los anteriores pero no obstante nos hemos divertido viendo la evolución de Asterisk, DAHDI, los constantes cambios de nombres de OpenSER y cómo las empresas de telefonía tradicional cierran y las grandes empresas se reposicionan ante lo que se podría considerar una partida de ajedrez donde todo apoyo es necesario y solo cuenta una cosa: La VoIP.
Veremos qué novedades trae el 2009 para la VoIP, pero lo que es seguro (confío, espero y deseo) es que este año sea recordado, entre otras cosas por el año en que acabó la crisis y las empresas puedan sacar nuevos productos, invertir en mejoras y novedades y poder disfrutar viendo cómo son.
No obstante, como todo, siempre hay algunos perjudicados y parece que todo se normaliza bastante bien, donde podemos conocer uniones de empresas, compañeros que se «mudan» y un movimiento bastante sano en esto de la VoIP, por lo que mis deseos para este año que entra es que sea mucho mejor que este, que nos traiga salud para todos nuestras personas queridas, que la gente vuelva a continuar con su trabajo o se recicle para continuar avanzando, y que haya trabajo y dinero para todos.
Empezaremos el año con un par de cosillas que he ido preparando y que tengo en el tintero desde hace algún tiempo, pero eso son sorpresas que me gusta dar poco a poco y que habrá que esperar un poco para conocerlas.
Así que, no me enrollo más, y desearos a todos, una muy buena entrada de año y un feliz y próspero Año Nuevo 2009.

2008-12-31
DAHDI 2.1.0 Released!
Esta nueva versión incluye:
- El nuevo driver wcb4xxp para dar soporte a las tarjetas RDSI (basados en el chipset HFC)
- Mejorada la integración con el cancelador de eco OSLEC
- Corregidos algunos bugs
Para ver la lista completa de cambios:
http://downloads.digium.com/pub/telephony/dahdi-linux/ChangeLog-2.1.0
Puedes descargarlo de:
http://downloads.digium.com/pub/telephony/dahdi-linux-complete/
2008-12-10
Todo lo que has querido saber de DAHDI (III)
Visto el éxito de los anteriores artículos, esta es la tercera edición de «Todo lo que has querido saber de DAHDI» y como se lo he prometido a mi colega Silvia aquí viene la tercera. 😛
Después de una semana dando el curso de Asterisk Advanced, el primer punto que me asustó fue leer «Asterisk 1.6 y DAHDI» en las primeras páginas del curso, algo que actualmente nadie en su sano juicio recomendaría en un entorno en producción y en cambio el curso se centra en estos dos «soles«.
Claro, considerando que no he llegado a tener tiempo más que para echarle un vistazo más que por encima a Asterisk 1.6 y darme cuenta de cosas «curiosas» y algo más (por cuestión de trabajo) a DAHDI, me encuentro que tengo que aprender, no únicamente cómo funciona, si no detectar cualquier problema que pudiera ocasionar a los alumnos del curso para solucionarlo antes de que ellos lo encuentren y no sepa donde meterme.
Tras una semana, explicando y resolviendo las posibles dudas sobre las diferencias físicas y lógicas entre Zaptel y DAHDI me doy cuenta que DAHDI está más avanzado de lo que en un principio pensaba y es que, no solo es perfectamente compatible con las tarjetas con las que damos el curso (primarios y analógicas) si no que en muchos aspectos es mucho más interesante que Zaptel.
Mi propuesta como logo de DAHDI. 🙂
Como ya comenté, el archivo zaptel.conf es sustituido por /etc/dahdi/system.conf y aunque son prácticamente iguales por dentro, hay un pequeño detalle interesante, el cancelador de eco que se puede cargar y descargar dinámicamente y seleccionar independientemente para cada canal DAHDI, así si tenemos un primario E1 (30 canales de voz) podemos utilizar un cancelador de eco para los 10 primeros canales, otro cancelador de eco para los 10 siguientes y otro diferente para los 10 últimos. ¿utilidad? pues no se ahora mismo, pero seguro que alguien se lo encuentra. Por todo lo demás, es exáctamente igual. 🙂
Por otro lado, el archivo zapata.conf ha pasado a ser /etc/asterisk/chan_dahdi.conf y le ocurre lo mismo, es prácticamente igual por dentro, las diferencias son mínimas y algunas bastante curiosas que os lo dejo para que lo descubrais vosotros. ;P
Entre todas las personas que conozco que instalan Asterisk, en estos momentos «especiales» todas tienen algo en común: pese a existir la versión Asterisk 1.4.22, TODAS utilizan la versión de Asterisk 1.4.21.1 ¿porque? por que esta versión no incluye el zapata.conf.sample ni el chan_zap.so, si no chan_dahdi.conf y chan_dahdi.so. (WTF!)
La próxima versión (la 1.4.23 que saldrá en breve), funcionará exáctamente igual que la 1.4.22 ¿que harán entonces? seguramente muchos empiecen a dar el salto, otros seguirán clavados en la 1.4.21.1 y así hasta que terminen dando el salto irremediablemente, porque nos guste o no… queridos amigos… Zaptel, ha muerto.
Ahora bien, entramos en un punto curioso donde el 99% de las veces funciona todo como debe ser, pero existe un 1% donde ocurre algo donde las líneas RDSI Básicas, BRI, ISDN 2B o como quieran llamarla, aquella línea más utilizada en las empresas europeas que las propias analógicas se encuentran en un momento clave:
– Por un lado, Junghanns continúa con su BriStuff (impasible ante todo lo que ocurra fuera).
– Sangoma con sus drivers que, continúan siendo Beta y que lo van modificando (que no siempre arreglando) a medida que la gente encuentra fallos.
– mISDN 2.X.X, que aunque soluciona algunos problemillas de la 1.1.X, aún no está lo suficientemente maduro para lo que uno desea en este tipo de sistemas.
– CAPI, ¿CAPI sigue vivo?
– mISDN 1.1.X, el driver BRI más popular actualmente y que con las últimas versiones (>= 1.1.8) con algunas versiones de kernel, con algunas líneas, en las noches de luna llena, cuando saturno, venus y mercurio se alinean,… hacen raros (gestión extraña de capas, etc…)
– alguna más…?
… y de repente aparece otra alternativa, un nuevo archivo wcb4xxp.c en el arbol de desarrollo de DAHDI (Trunk), un driver DAHDI indicado para la tarjeta B410P de Digium y por lo general para cualquier otra que tenga el driver HFC con uno o más conectores. Aún está en desarrollo e incluso el actual DAHDI no la trae, ya que están haciéndole pruebas antes de lanzarla como versión estable en la siguiente versión y es entonces cuando se me plantean varias dudas o mejor dicho, una reflexión:
Si en los EEUU no utilizan este tipo de líneas y nosotros sí ¿quien debería probar este driver y empezar a sacarle los posibles fallos antes de que lo saquen como versión estable y sea más difícil de corregir? ¿no deberíamos ser los que peleamos a diario con este tipo de tarjetas y estas líneas los que deberíamos ver dónde falla con nuestras penosas líneas de Telefónica, Tele2, Orange, Jazztel, etc… y colaborar para que solucionen los posibles fallos y que corrijan el driver de una vez por todas para que sea más que nunca un driver verdaderamente compatible con nuestras propias líneas?
En principio este driver no va a hacer exclusiones de ningún tipo, por lo tanto llegará a ser un driver compatible con todo tipo de tarjetas HFCMulti, pero creo que ahora estamos en un momento idóneo para empezar a sacarle punta a este driver, antes de que lo terminen de «pulir» y veamos con desilusión que tiene más espinas de las que debería tener.
Instalar DAHDI de la rama subversion no se tarda ni 3 minutos, en conectar la tarjeta a la línea y ver si falla, menos aún, si funciona será algo que tenemos ganado, si no lo hace o no lo hace corréctamente será el momento de hacer de «usuarios beta-tester» de los que tanto se enorgullece la comunidad y empezar a enviar lo que encontremos a Digium para que hagan un driver en condiciones. ¿o no? 🙂
¿y tú? ¿Has probado ya DAHDI con Asterisk 1.6?
2008-12-02
mISDN v.2.0.0 Released!
Me comenta mi compañera Rosa que hace un par de días la gente de mISDN publicaron las últimas herramientas de la versión 2.0 de estos módulos para tarjetas RDSI. La verdad es que la versión la publicaron hace algún tiempo atrás, pero estaba en una versión bastante inestable y se ve que por fín empieza a tomar forma con los nuevos comandos que han añadido estos días.
Aún no lo he probado, pero leyendo las pocas novedades que han actualizado en la web me sorprenden con varias cosas:
– Soporte de LCR (Linux Call Router) en Asterisk.
Esto permite la gestión tanto de líneas como de teléfonos RDSI (algo que parece ser antes no soportaba), mediante un nuevo canal llamado chan_lcr.
– Más tarjetas RDSI soportadas.
Entre las que ya funcionaban, se incluyen algunas muy interesantes:
+ Todas las Junghanns (incluidas las unoBRI, las duoBRI y las SingleE1 y DoubleE1 –las quadBRI y las octoBRI ya funcionaban-)
+ Mejorada la compatibilidad con las tarjetas 1 RDSI (también conocidas como HFC-PCI)
– Adiós a la necesidad del CAPI del Kernel.
Hasta ahora era necesario disponer de un kernel con soporte CAPI2.0, ahora ya no es necesario, ya trae su propio sistema para evitar esta necesidad.
y algunos cambios más… que aún no están documentados…
habrá que probarlo a ver qué tal va y si soluciona algunos bugs que se están detectando últimamente…
Enlace: http://www.misdn.org/index.php/MISDN_Release_Notes
2008-11-03
Todo lo que has querido saber de DAHDI (II)
Tras la primera parte del artículo que escribí, continuo peleándome con DAHDI y pese a que intenta ser «simplemente un cambio de nombre«, está claro que Zaptel es un sistema con muchos años de evolución y DAHDI no es simplemente un cambio de nombre si no una reprogramación bastante seria donde aprovechan algunos módulos de Zaptel, pero realmente se ha producido cambios importantes tanto en el comportamiento como en la forma.
Los módulos del kernel de DAHDI que hace que Linux detecte las tarjetas parecen basados íntegramente de sus correspondientes módulos de zaptel, por lo que la detección y configuración del sistema udev funciona de forma similar.
No así las utilidades que aún las veo algo verdes y falta de la potencia que tienen sus correspondientes en zaptel.
Como ejemplo: En zaptel, la utilidad ztcfg -v nos permite cargar la configuración del zaptel.conf y ztcfg -s para descargarla. En DAHDI disponemos de la utilidad dahdi_cfg –v para cargar la configuración del system.conf pero aún no existe parámetro para descargar dicha configuración. (Algo muy recomendable si queremos apagar el servicio zaptel sin que se nos queden canales ‘bloqueados’). Aún no he tenido ocasión de freir a pruebas al DAHDI, pero echo en falta esta opción.
Otra opción que también hecho en falta es la posibilidad de descargar y compilar los drivers mISDN directamente desde el directorio zaptel-x.y.z con el comando: make b410p. Esto no es posible con DAHDI, imaginamos que porque tienen pensado integrar el soporte BRI en el DAHDI mediante el LibPRI como ya nos comentó Mark en Bilbao cuando le preguntamos, pero por el momento esto es algo que está parado y «sin noticias en el frente«, tan solo un par de mensajes en la lista de Asterisk-Dev y algún que otro bug probando la señalización eurobri del libpri.
Investigando un poco, me encuentro un texto de Russell Bryant sobre este tema:
With Zaptel it was possible to install mISDN and the B410P driver by typing
‘make b410p’ from the command-line. This is no longer possible with DAHDI as
part of the changes to make DAHDI friendlier to binary packagers. If you
would like to install support for the B410P with asterisk you will need to
install it manually. Please see http://www.misdn.org for more information, but
the following sequence of steps is roughly equivalent to ‘make b410p’ from
previous releases.
wget http://www.misdn.org/downloads/releases/mISDN-1_1_8.tar.gz
wget http://www.misdn.org/downloads/releases/mISDNuser-1_1_8.tar.gz
You will then also want to make sure /etc/init.d/misdn-init is started
automatically with either ‘chkconfig –add misdn-init’ or ‘update-rc.d
misdn-init defaults 15 30’ depending on your distribution.
NOTE: At the time this was written, misdn-1.1.8 is not compatible the
2.6.25 kernel. Please use a kernel version 2.6.25 or earlier.
Por lo que, se puede ver que se está trabajando en ello, pero para ser algo tan útil y frecuentemente utilizado como es el soporte de líneas BRI (RDSI Básicas), me parece que se deberían darse más prisa.
Como «exclusiva Sinologic«, decir que DAHDI traerá soporte nativo para la Digium B410P como canal DAHDI, lo que ya no sabemos qué compatibilidad tendrá dicho módulo con otras tarjetas basadas en el driver HFC, pero bueno, ahí queda eso, habrá que esperar a que lo hagan público. 🙂
Por suerte, y viendo como está estructurada la configuración de las últimas versiones de Asterisk, existen dos posibilidades:
- Utilizar Zaptel
  Con esta opción, nuestro flamante Asterisk 1.4.22 o superior, no traerá por defecto archivo zapata.conf, por lo que tendremos que crearlo nosotros tomando como base el archivo /etc/asterisk/chan_dahdi.conf aunque Asterisk seguirá buscando el archivo ‘/etc/asterisk/zapata.conf’.
- Utilizar DAHDI
  Con esta opción, nuestro Asterisk 1.4.22 o superior, se deberá configurar en el /etc/dahdi/system.conf con una configuración prácticamente igual a la del zaptel.conf, y seguidamente el /etc/asterisk/chan_dahdi.conf para definir los canales que Asterisk va a utilizar.
Como se puede observar, los que estamos acostumbrados a Zaptel, el cambio en esta versión seguramente hará cabrear a más de uno pese y acordarse de la frase «es simplemente un cambio de nombre».
Está claro que de ahora en adelante, DAHDI va a tener que hacerse con el espacio que hasta ahora tenía Zaptel, pero para que llegue a hacerlo, DAHDI deberá ser un sistema tan estable y fácil de instalar y configurar como lo es Zaptel actualmente. Está claro que Zaptel todavía le lleva mucha ventaja a DAHDI, pero el equipo de desarrolladores está trabajando en recortar «distancia» a gran velocidad.
Ya veremos que ocurre cuando salgan las siguientes versiones de DAHDI y Asterisk.
2008-10-29
Probando la nueva interfaz Asterisk-GUI 2.0
Por el blog de Saghul me entero que acaban de lanzar una nueva versión del Asterisk-GUI 2.0. No soy amigo de los interfaces, aunque reconozco que muchos conocidos los utilizan por «facilitarse la labor» de desarrollar configuraciones «en serie» algo con lo que comparta o no, hay que respetar.
A la vista del comentario de Saúl, daba la impresión de que habían cambiado el aspecto visual, por lo que, recordando lo sencillo que era instalarlo y aprovechando que tengo varios Asterisk para mis pruebas, y como la curiosidad mató al gato, lo he instalado para verlo.
Para empezar, la instalación no puede ser más sencilla:
En la consola, ejecutar:
svn co http://svn.digium.com/svn/asterisk-gui/branches/2.0 asterisk-gui-2.0
Una vez descargado, toca instalarlo, para ello ejecutamos:
cd asterisk-gui-2.0 && make && make install && make samples && make checkconfig
Con este ultimo comando (el make checkconfig) confirmaremos que la configuracion es la correcta, por lo que nos dara algun mensaje de error. Tan solo deberemos asegurarnos que esta habilitado el manager en el puerto 5038 asi como que existe un usuario valido en el manager.conf y haber descomentado los parametros en el archivo http.conf, reiniciamos Asterisk y listo. 🙂
Para probar, recomiendo configurar el parametro bindaddres con valores 0.0.0.0, de manera que una vez lo podamos ver, lo configuremos de acorde a donde vayamos a conectarnos (127.0.0.1 si es desde la propia maquina, o 192.168.0.0 desde la red local o 0.0.0.0 para cualquier sistema desde Internet).
Una vez tengamos todo correctamente configurado, pasamos a entrar en el sistema, para ello, abrimos el navegador web y escribimos la direccion de Asterisk en el puerto que hayamos definido en el archivo http.conf, por defecto el 8088 (http://laipdenuestroasterisk:8080), lo que nos redireccionara a la direccion correcta (http://laipdenuestroasterisk:8088/asterisk/static/config/index.html).
Los cambios son pocos pero destaca alguno que otro si hemos seguido de cerca el interfaz en su version anterior:
Visualmente no se aprecia muchos cambios, aunque a medida que uno va saltando por las opciones, puede notar la experiencia adquirida tras la primera versión (algo verde en mi opinión).
Donde realmente me ha llamado la atención es en la auto-preparación, de manera que se modifican los archivos de configuración necesarios para poder utilizar todo el potencial de este interfaz, detección de hardware (incluyendo, como no, soporte para tarjetas basadas en mISDN) y algunas opciones básicas que ya traía de serie la versión 1.0, por lo que nada destacable por ahora.
Por supuesto, la versión que he probado, además de ser descargada por subversión, podría clasificarla como pre-pre-alfa, por lo que aun no está lista para ser utilizada, de hecho aún no funcionan botones básicos (sobre todo el de añadir), pero seguro que pronto lo arreglan.
Lo «bueno» de este interfaz, es que lee la configuración que hemos escrito a mano, la entiende y permite gestionarla vía web, algo que aún no he encontrado ningún interfaz que lo haga (siempre machacan los cambios o acuden a archivos externos incluidos para saltarse esta dificultad, en lugar de plantarle cara).
Lo «malo» de este interfaz, que, como todos los interfaces, hay limitaciones que el usuario probablemente puede requerir, pero para eso está el ‘vi’. 🙂
El día que este interfaz funcione como debe, creo que habremos dado con uno que realmente merezca la pena de verdad. 🙂
Digium tiene Switchvox como interfaz web profesional (y comercial) para la gestión de Asterisk, por lo que si realmente queremos una versión en condiciones del Asterisk-GUI (opensource y libre), más nos vale empezar a aportar nuestro granito de arena tanto en el desarrollo como en la verificación de funcionamiento y búsqueda de bugs.
Por cierto, a veces ocurre un error: Could not connect to Server, que se solucionará con una versión del Asterisk-GUI más estable y dándole al botón Retry. 😛
2008-08-09
Cómo testear una tarjeta de primarios en Asterisk
Cuando vamos a instalar un Asterisk, comprobamos que el sistema operativo tiene las últimas versiones de los paquetes estables, que tenemos una versión de Asterisk marcada como estable (nada de trunk, team o release candidate), revisamos varias veces la configuración del dialplan, comprobamos que Asterisk se registra corréctamente con el proveedor IP y probamos a hacer llamadas y recibirlas para asegurarnos que todo marcha como debería hacerlo.
Pero a menudo nos encontramos con un inconveniente a la hora de probar la conexión con una tarjeta de comunicaciones, esto se puede hacer de las siguientes maneras:
- Conectándole una línea directa con el proveedor de telefonía.
  Esto sería lo ideal, aunque no siempre es posible.
- Conectando un simultador de líneas.
  La pega es que estos dispositivos son bastante caros y complejos para alguien no acostumbrado a estos temas.
- Conectándole otro sistema con señalización contraria que simule ser el proveedor.
  El resultado de la prueba dependerá de cómo tengamos configurado el sistema contrario, lo que puede darnos un resultado nada concluyente.
Cuando vamos a probar una tarjeta analógica, no es difícil encontrar una línea directa con el proveedor de telefonía que nos suministre el voltaje necesario, los tonos y los cambios de polaridad necesarios para probar la tarjeta o bien algún tipo de dispositivo que genere el voltaje necesario y nos simule una línea (un spa3000, un grandstream fxs, o cualquier otro. De la misma manera aunque un poco más complicado es con una RDSI Básica, o bien tenemos una disponible, o bien tendremos que buscar algo que nos permita simular este tipo de líneas.
Lo que es bastante más complicado es disponer de un primario, y si no tenemos la suerte de tener otra tarjeta de primarios configurada en modo proveedor (NET) y que nos suministre la señal de timing, tendremos que buscar otra manera de comprobar que la tarjeta funciona corréctamente.
Para ello, podemos utilizar lo que se llama un «conector nulo» que no es más que un cable con unos pines conectados entre sí de manera que cualquier señal que enviemos por la tarjeta (puertos TX1 y TX2) la recibiremos por los pines destinados a la recepción (RX1 y RX2). Este método no nos va a permitir comprobar si la configuración del primario es correcta (ya que para eso necesitaremos del primario con sus parámetros y su configuración establecida por el proveedor) pero sí nos va a permitir asegurarnos que la tarjeta funciona correctamente.
Tendremos que utilizar el siguiente esquema con los pines indicados unidos entre sí, cargar el módulo necesario para la tarjeta (que creará los dispositivos /dev/zapX) y, con Asterisk descargado, utilizar la herramienta ‘patlooptest’ que viene en el paquete zaptel.
La aplicación patlooptest enviará secuencias de 1’s y 0’s aleatorias a través de los pines TX y esperará a recibir la misma secuencia por los RX.
De esta manera, comprobamos que:
– La tarjeta es capaz de enviar una secuencia binaria desde una aplicación hacia el exterior.
– La tarjeta es capaz de recibir la misma secuencia desde el exterior y hasta la aplicación.
El resultado de la prueba es trivial, si lo que enviamos es igual a lo que recibimos, entonces la tarjeta es correcta. Si lo que enviamos es distinto a lo que recibimos, entonces puede ser porque la tarjeta tenga algún tipo de fallo.
Si Asterisk está cargado al hacer el test, la prueba no será válida ya que Asterisk está continuamente enviando datos a través del primario para llegar a conectarse a un primario de verdad, por lo que, además de la secuencia que envíe el patlooptest, Asterisk enviará la suya, y la aplicación no recibirá únicamente los datos que espera si no también recibirá intercalados los datos que envía Asterisk y que no están controlados.
Las tarjetas no suelen entender de señalización (qsig, euroisdn, etc…) únicamente entiende de 1’s y 0’s, por lo tanto si en el arranque del módulo de la tarjeta (que ejecuta varios tests internos) el módulo no indica que la tarjeta esté mal, y al hacer el patlooptest los datos son correctos, entonces si la conexión con el primario no funciona, seguramente se deba a un fallo en la configuración o en los valores que tenga configurado el proveedor.
Si con este conector nulo encendemos Asterisk, nos encontraremos que Asterisk mostrará un mensaje de error al detectar que el «otro lado» tiene la misma configuración que nosotros, es decir: Si hemos configurado la tarjeta como PRI_CPE, entonces en el otro lado también será PRI_CPE en lugar de PCI_NET.
2008-06-24
Resumen de la conferencia de Mark Spencer en Bilbao
Acabo de llegar de Bilbao, concretamente de la conferencia que Mark Spencer ha dado en el museo Guggenheim, una mezcla entre tecnología aplicada a las comunicaciones basadas en software libre y lo más de lo más en el arte. Como decía un amigo: «la programación es un arte» 🙂
Aquellos que no han tenido la suerte de venir, han podido seguirlo en directo mediante streamin g en la página de Irontec y si aún así os lo habeis perdido, entonces aun tenéis la oportunidad de verla en la página de Alberto que la tiene grabada.
La conferencia ha sido todo un éxito, tanto por parte de Mark que ha sabido exponer este software como nadie, como por la parte de la organización que ha conseguido (no sin dificultad) una excelente localización, así como los mejores medios (traducción simultanea inglés-español) y un ambiente comunitario sin igual donde curiosos y expertos encontraban el lugar perfecto para compartir experiencias y conocerse.
Con respecto a la conferencia, Mark ha sabido darle ese toque mágico que suele dar cuando un jóven se sube a un escenario y empieza hablar sobre cómo se ha llegado en apenas 9 años a movilizar a tantas y tantas personas convirtiendo al movimiento Asterisk en uno de los más premiados y valorados incluso por las grandes empresas fabricantes de dispositivos de telecomunicaciones.
Entre los puntos a destacar:
– Las ventajas de Asterisk y el OpenSource en las comunicaciones.
Aquí comentó las ventajas que dispone una empresa en modificar el código para ofrecer soluciones altamente personalizadas, a la vez de contribuir para el desarrollo de esta aplicación y mantener vivo el movimiento del software libre. La retroalimentación inteligente provocada por la aportación de la comunidad de software libre y la aportación económica que ofrecen las empresas que utilizan esta aplicación adquiriendo hardware lo que lo convierte en un proyecto doblemente impulsado.
– Asterisk como sistema ideal en entornos con requisitos específicos y nada generales.
Empresas que han desarrollado con Asterisk soluciones muy específicas y curiosas, incluso algunas de las que ya hemos hablado en Sinologic: Asterisk como cuidador de plantas, Asterisk como puerta de acceso telefónico para acceder a eBay, y un largo etcétera que provocó alguna que otra carcajada como la anécdota que contó en la entrevista de Asterisk-Tag sobre la cola de espera con preguntas del trivial y que, a medida que la gente respondía corréctamente, avanzada en la posición de la cola, mientras que si respondían mal, descendía posiciones. 🙂
– Digium como «sponsor benevolente de Asterisk».
Explicaba que Digium, al ser el creador de Asterisk, busca el equilibrio entre desarrolladores de la comunidad y desarrolladores propios de Digium para poder crear un sistema tan comercial como comunitario y que todos puedan sacar provecho de esto. Explicó el papel que realiza Digium, el éxito arrollador que está teniendo las soluciones opensource en las comunicaciones actuales, tanto en sistemas en pequeñas y medianas empresas como en soluciones altamente competitivas.
En el turno de preguntas, algunas bastante curiosas, Mark se «soltó» lo que hizo que mucha gente se animara a preguntar cosas tan curiosas como el papel de Asterisk frente a las soluciones propietarias de Nortel, Avaya, Cisco y Microsoft, ventajas de utilizar Asterisk, fecha de publicación de Asterisk 1.6, a lo que respondió que saldrá cuando los desarrolladores consideren que debe salir. ;), también se preguntó sobre el soporte para el chan_sip3 (codename Pineapple) donde comentó que es un proyecto que está en desarrollo de la mano de Olle Johansson y que no sabe cuando podría estar listo.
Fuera de la conferencia, aprovechando que lo tenía cerca, le pregunté un par de dudas que tenía desde hace algún tiempo:
– Diferencias que habrá entre Zaptel y DAHDI cuando finalmente vea la luz.
En principio, DAHDI es simplemente un cambio de nombre del paquete Zaptel como ya sabemos por temas de registros de marcas, aunque sí comentó que se está desarrollando un soporte propio para las tarjetas ISDN Bri que verá la luz muy pronto y que podría sustituir al mISDN que tantos dolores de cabeza está dando a tanta gente con kernels de Linux demasiado nuevos. (>= 2.6.24)
– Tras 4 años de espera con el draft, para cuando el RFC de IAX.
De momento no puede decir mucho, tan solo que pronto puede haber noticias… (aunque eso se lleva diciendo desde hace 3 años) 😛
Además de todo esto, algunas anécdotas bastante curiosas y graciosas que seguro que tardaremos en olvidar y desde aquí, felicitar de todo corazón a la gente de Irontec y de Avanzada7 que han permitido, no solo dar a conocer a más gente este fantástico mundo de comunicaciones opensource, si no también permitirme conocer un poquito Bilbao al que prometo volver pronto.
2008-06-02
LibPri 1.4.4: Soporte de RDSI Bri y TBCT QSig
Esta semana, siguiendo los hilos de la lista Asterisk-Dev, me he encontrado con un anuncio que marqué para analizar cuando tuviera más tiempo. El anuncio lo daba Matthew Fredrickson de Digium, ya que es uno de los desarrolladores que se ocupa de mantener al día el paquete Zaptel y el LibPRI.
Concretamente, el anuncio iba sobre el nuevo paquete LibPri (1.6.0) así lo anunciaban aunque finalmente ha pasado a ser el LibPri 1.4.4 y que incluye dos añadidos bastante interesantes que explicaré ahora.
– Soporte de tarjetas RDSI Bri:
Algo que iba siendo hora, ya que en la actualidad, el soporte de RDSI Bri está en mano de mISDN y aunque es un driver que suele funcionar bien, el hecho de incorporar el soporte BRI al Zaptel es algo que mejora la «centralización» en la corrección de bugs, algo que actualmente no se hace.
Si hay algún bug en mISDN, los encargados de arreglarlo son los desarrolladores de mISDN, no los del paquete Zaptel, aunque si el error está en el archivo ‘chan_misdn’ entonces sí.
De momento, creo que solo permiten modo Punto-multi-punto.
– Soporte de TBCT/2BCT en QSig:
Esto es algo muy interesante, que muchas personas lo han pedido y hasta ahora únicamente funcionaba en pocos sistemas.
Cuando conectamos Asterisk a una PBX con extensiones, y estas extensiones se llaman entre sí, la llamada no tiene porqué llegar a Asterisk, pero si la llamada, después de una transferencia comienza y acaba en la PBX, Asterisk pasa a ocupar dos canales (uno para el origen y otro para el destino).
Con el soporte TBCT, Asterisk reconoce que el origen y el destino vienen de la misma PBX y puentea los canales liberando ambos canales ocupados, permitiendo que el tráfico no llegue a Asterisk.
Llevan preparando esta feature desde la Astricon del 2005. 😛
Podeis descargar esta versión aquí:
http://downloads.digium.com/pub/libpri
2008-05-10