Etiqueta: Asterisk 1.4

  • Asterisk 1.4 continuará viva hasta Asterisk 1.8

    Leif MadsenLeif Madsen acaba de publicar una nota en la que anuncia que el próximo mes de Junio, las versiones de Asterisk 1.6.0 y 1.6.1 pasarán a congelarse por lo que únicamente se le realizarán modificaciones para corregir los posibles bugs que se vayan encontrando.

    Asimismo, Asterisk 1.6.2 será la única versión que seguirá recibiendo actualizaciones normales hasta que aparezca por fín la esperada versión de Asterisk 1.8.

    Como nota curiosa: tanto Asterisk 1.4 como Asterisk 1.6.2 serán las únicas versiones que ampliarán el plazo para recibir mantenimiento hasta que el equipo de desarrolladores de Asterisk publique Asterisk 1.8.

    Release SeriesRelease TypeRelease DateSecurity Fix OnlyEOL
    1.2.X2005-11-212007-08-072010-11-21
    1.4.XLTS2006-12-232010-12-232011-12-23
    1.6.0.XStandard2008-10-012010-05-012010-10-01
    1.6.1.XStandard2009-04-272010-05-012011-04-27
    1.6.2.XStandard2009-12-182010-12-182011-12-28
    1.8.XLTSTBD (Goal: Q3 2010)TBD + 4 yearsTDB + 5 years

    Ya dicho sea de paso, acaban de publicarse las versiones candidatas: 1.4.32, 1.6.0.28, 1.6.1.20, y 1.6.2.8

    Vea la nota oficial:

    (más…)

  • Cómo verificar tu Asterisk para una instalación en producción

    Poco más de un año han tardado los desarrolladores en hacer realidad una petición bastante interesante que hicieran nuestros compañeros Jon Bonilla y Saúl Ibarra cuando, cansados de que cada nueva versión de Asterisk 1.4 que añadía una nueva característica, volvían a aparecer antiguos bugs que ya habían sido solucionado, las conocidas «regresiones» que aparecían en 1.4 y más intensamente en 1.6.

    El objetivo principal del debate era una crítica constructiva sobre el futuro del desarrollo de Asterisk y más concretamente la forma de publicación de versiones que defendía Russell Bryant de forma que varias ramas estuviesen en producción de forma simultaneamente como lo está haciendo la versión de Asterisk 1.6, así podemos ver Asterisk 1.6.0.26, 1.6.1.18 y 1.6.2.6 como versiones supuestamente estables.

    Finalmente se optó para la rama 1.8 como versión LTS (Long Term Support) quedando como única rama lo que hará que «en teoría» pasará a ser mucho más estable, pero mientras tanto, se siguió pensando en nuevos mecanismos que permitieran obtener versiones de Asterisk mucho más estables para entornos en producción.

    Tras esta discusión en la que participaron muchos desarrolladores explicando el porqué de la política de versiones que sigue Asterisk 1.6, y que era necesario algún cambio para evitar esas «regresiones» en futuras versiones, decidieron crear una API especial para que el sistema se testeara de forma automática para verificar que todas las características que funcionan en una versión, sigan funcionando en la siguiente.

    Poco más de un año ocurrió desde el primer mensaje, y se ve que han estado trabajando en ello porque ayer Leif Madsen ha publicado en el blog de Asterisk un ejemplo práctico sobre cómo ejecutar esos auto-tests para verificar que las características / servicios de las nuevas versiones sigan funcionando, así que ni cortos ni perezosos nos hemos puesto a probarlo nosotros mismos y verificar que realmente funciona como dice…

    (más…)

  • Asterisk 1.4.29 y 1.6.0.21 Released!

    Las nuevas versiones corrigen fallos reportados por la comunidad y son más estables que las anteriores versiones.

    Como viene siendo habitual cada 15 días, el equipo de desarrollo de Asterisk publica las modificaciones y una versión que recopila los parches que se han ido creando y que corrigen algunos bugs (algunos importantes y otros bastante más rebuscados).

    En esta ocasión, la actualización es para las versiones públicas:

    • Asterisk 1.4.29:
      • Corregido el bug que hacía que Asterisk «únicamente soportase»  6341 salas de conferencia.
        Imagínate que tienes 6341 conferencias, vas a crear una más y aquello falla… que rabia tiene que dar… 😀
      • Los mensajes del voicemail no se guardan cuando «format=wav|gsm|wav49«.
        No obstante, ¿para qué queremos que se guarden los mensajes en 3 formatos diferentes?
      • Los mensajes del CDR aparecen como NOANSWER cuando realmente son BUSY o FAILED
        Qué raro… el CDR…
      • El ChangeLog de la 1.4
    • Asterisk 1.6.0.21:

      (Como siga así, la rama 1.6.0 va a superar en número a la 1.4.)
    • Asterisk 1.6.1.13:
      • Solucionados algunos bugs en la aplicación app_queues.
      • Modificadas las locuciones cuando se aparcan las llamadas.
      • El ChangeLog de la 1.6.1.

    Para descargar cualquiera de estas versiones, recordad que se encuentran en:
    http://downloads.asterisk.org/

  • Nuevas versiones de Asterisk 1.4.28, 1.6.0.20 y la nueva 1.6.2.0

    Justo antes de navidad, el equipo de desarrollo de Asterisk tiene por costumbre lanzar nuevas versiones (como ya viene siendo habitual en estas fechas) y en este caso nos hemos encontrado con nuevas versiones de todas las ramas:

    Asterisk 1.4.28:

    Incluye cambios menores y bugs reportados por la comunidad ya corregidos.
    Podeis ver los cambios en este ChangeLog.

    Asterisk 1.6.0.20:

    Mejora en la documentación de los archivos de configuración, corregidos algunos bugs relativos a la música en espera y el BLF y algunas mejoras en el CDR y en el Manager.
    Podeis ver los cambios en este ChangeLog.

    Asterisk 1.6.1.12:

    Cambios muy similares  a los de la 1.6.0.20. (ChangeLog)

    Asterisk 1.6.2.0:

    Primera versión de la rama 1.6.2.0 que incluye algunas novedades como:

    • Soporte nativo del MFC-R2 (si Asterisk está compilado con soporte de LibOpenR2)
    • Opción faxdetect=yes|no en el sip.conf (muy interesante, habrá que probar si funciona bien)
    • Aplicación ConfBridge y Originate en el dialplan para la generación asíncrona de llamadas (un compañero del chan_local? ;D)
    • Nueva sintaxis con ‘same’ para indicar que vamos a utilizar la misma extensión que la línea anterior:
      exten => 123,1,NoOp(something)
      same => n,SomethingElse()
    • Posibilidad de configurar nuestros propios «alias» en la consola de Asterisk mediante el archivo de configuración cli_aliases.conf.
    • Soporte de monitorización de buzones de voz remotos mediante SIP.
    • Soporte del códec HD G.722 especial de Polycom (SirenX)

    Podeis ver todos los cambios y muchos más en este documento.

    En mi humilde opinión, Asterisk 1.4 sigue siendo la rama más estable, seguida muy de cerca por la 1.6.0.
    Si disponemos de tarjetas Digium quizá nos interesaría utilizar la versión 1.6.0, o si no, entonces la 1.4, no obstante yo hace tiempo que vengo trabajando con Asterisk 1.6 para habituarme con los nuevos archivos de configuración y los nuevos comandos de consola (que no son pocos) a la espera de que salga la versión de Asterisk 1.8 y veamos si es lo que promete ser.

    De poco sirve quedarse en la versión 1.4 si luego cuando queramos saltar a una versión posterior vamos a tener que aprender a hacerlo todo de nuevo debido a los cambios que han surgido en las versiones 1.6, así que… ahí dejo eso. ;D

    Como siempre, estas versiones o las superiores que vayan saliendo, se pueden descargar de:
    http://downloads.asterisk.org/

  • Cómo actualizar Asterisk

    Lo primero que hay que saber antes de actualizar un Asterisk es si la versión a la que vamos a actualizar es la más conveniente. Partiremos de la base de que cuanto más avanzada sea una versión, más estable será.

    Siempre hemos sido de la opinión que cuando un sistema funciona, no debemos cambiarla a menos que:
    – Exista un fallo de seguridad que esté solucionado en la siguiente versión.
    – Necesitemos alguna característica que no venga incluida en la versión actual.

    upgrade_AsteriskPara aquellos que trabajan con Asterisk 1.0 o incluso Asterisk 1.2 la actualización es prácticamente necesaria por las mejoras en el funcionamiento de muchos servicios y de hecho, se aconseja pasar a la 1.4 o incluso a la 1.6.

    Para aquellos que trabajan con Asterisk 1.4 la actualización debería ser siempre a la última disponible (cierto que han existido algunas versiones un poco ‘verdes’ -de la 1.4.23 a la 1.4.26- pero parece ser que cualquier otra versión superior se considerará suficientemente estable para un sistema en producción.
    Para aquellos que trabajan con Asterisk 1.6.0 la actualización debe seguir dentro de la misma rama (en un sistema en producción, nunca saltar a la 1.6.1 hasta que se considere estable).

    Si realmente estais interesados en actualizar Asterisk por algún motivo, vamos a ver qué tenemos que tener en cuenta y cómo podemos hacerlo.

    (más…)

  • Nueva actualización de Asterisk 1.4.27.1 y 1.6.0.9 corrige bugs en el SDP

    AsteriskLogoHacía tiempo que no publicábamos nuevas versiones, quizá un poco por lo tedioso que puede resultar anunciar cada 2 ó 3 semanas nuevas versiones de alguna de las diferentes ramas de Asterisk.

    Al principio era más o menos entretenido, salía una nueva versión cada 3 ó 4 semanas con algunas novedades que eran interesante destacar, uno llevaba prácticamente la cuenta o los apuntes de los cambios que iban sucediendo y las ventajas de una y otra versión a fín de que cuando a algún compañero se encontrase con algún problema, poder acudir a la base de datos de bugs resueltos y comprobar si dicho bug había sido corregido y en qué versión.

    Con la aparición de la rama de Asterisk 1.6, la publicación de nuevas versiones comenzó a volverse un poco para locos, ya no habían únicamente bugs corregidos en las nuevas versiones de Asterisk 1.4, si no que aparecían nuevas que no existían en 1.6.0 pero sí en 1.6.1 (WTF!) que eran corregidas en la re-revisiones posteriores 3 días después con nuevas revisiones y nuevas re-revisiones… en resumen, un caos y tras eso y algún que otro cambio personal, decidimos abandonar el seguimiento de versiones hasta nueva orden o hasta que realmente mereciera la pena (como la publicación de una nueva rama de Asterisk o similar).

    Tras el anuncio de la nueva rama de Asterisk 1.8, nos hemos vuelto a animar a publicar las actualizaciones por lo menos, de las ramas estables, aunque no desarrollemos el contenido y los cambios, sí que pondremos una pequeña nota para que aquellos que seguís Sinologic, esteis alerta.

    En este caso, un error de regresión en el SDP de la 1.4.27 ha hecho que aparezca la versión 1.4.27.1 que corrige este bug.

    Más información sobre este bug: https://issues.asterisk.org/view.php?id=16268
    y el documento oficial de Digium: http://downloads.asterisk.org/pub/security/AST-2009-010.pdf

    Así que, si teneis Asterisk 1.4.27, toca actualizar… 😉

  • Asterisk 1.8 seguirá la misma política de versiones que 1.4

    Según acabo de saber gracias a Saúl, en la lista de Asterisk-Dev, Russell Bryant acaba de publicar un cambio muy importante para los que nos dedicamos a la VoIP y a Asterisk, y es que la versión 1.6.2 será la última versión basada en 1.6 con la actual política de versiones, y todas las novedades y mejoras pasarán a unirse en la próxima versión de Asterisk: Asterisk 1.8.

    Mucho se ha hablado sobre la política de versiones de 1.6 el hecho de tener varias versiones de la misma rama que evolucionan a la vez es algo no sólo difícil de entender para muchos si no que pese a las críticas de estabilidad, velocidad de desarrollo y esfuerzos por parte de los desarrolladores, Russell continuaba defendiendo un modelo que en la opinión tanto de los usuarios como de muchos desarrolladores, era impracticable e ineficiente.

    Asterisk 1.6. continuará con sus sub-ramas Asterisk 1.6.0, 1.6.1 y 1.6.2 y pronto se empezará a unificar todas las características así como las nuevas que estaban planteadas en Asterisk 1.6.3 (CEL, un SIP bajo TCP y TLS en condiciones, y muchas mejoras más) en una nueva y única rama: Asterisk 1.8.

    (más…)

  • Cómo instalar una tarjeta RDSI BRI con DAHDI

    Un poco de Historia …

    Billion RDSI

    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.

  • 11.001 llamadas simultaneas con un único Asterisk

    La noticia ha resonado por toda la blogosfera y no es para menos, tras el concurso que promovió Digium para ver quién era la primera persona capaz de realizar más de 10.000 llamadas (5.000 conversaciones) con un único servidor Asterisk, parecía que todo estaba perdido hasta que hace un par de días leo por el twitter que Olle Johansson ha conseguido 11.001 canales simultaneos con un único Asterisk, algo realmente impresionante.

    La primera pregunta que a uno le viene a la cabeza es -«Cómo??» y tras recopilar un poco de información y traducir otro poco, tenemos algo más claro (aconsejo leerlo todo, el final es muy bonito):

    «Hola usuarios de Asterisk de todo el mundo!

    Recientemente, he estado trabajando en unas cuantas instalaciones de Asterisk bastante grandes. Unos 300 servidores corriendo Asterisk y Kamailio (OpenSER). Reemplazando grandes sistemas Nortel por unas pocas máquinas pequeñas y otras soluciones interesantes. Las pruebas han sido una gran parte de estos proyectos. ¿Cuánto podemos apretar a una única máquina con Asterisk?

    Hasta ahora, hemos sido capaz de conseguir 2.000 canales con G.711 en un QuadCore y con tarjetas de red Intel Pro/1000 en servidores IBM. En este momento, el sistema de balanceo de interrupciones (IRQ) se rinde y se va a la cama, y todo el tráfico es dirigido a un único núcleo por lo que el sistema también abandona. Hemos estado haciendo estas pruebas en varios sistemas, con varias tarjetas de red y hemos estado trabajando muy duro para mejorar el rendimiento. Nuevos drivers, nuevas tarjetas, nuevas herramientas. Pero todo parecía indicar que el problema estaba en la conexión entre la CPU (que es la que gestiona el tráfico de voz RTP) y Asterisk. Esto fue finalmente confirmado por algunos equipos de programadores diferentes.

    Imagina mi sorpresa este Lunes cuando yo instalé un típico y antiguo Asterisk 1.4 en un servidor HP, un DL380 G6, y enviando tráfico a varios viejos servidores IBM. 3 servidores reenviando llamadas entre ellos y conseguimos sobrepasar 10.000 canales sin problemas. Llamadas SIP a SIP, el puente P2P RTP, básicamente corriendo como un «media proxy». En este punto, nuestro switch gigabit fue el que se rindió, y por supuesto, las tarjetas de red. Empujar 850Mbits fue más que suficiente. Las CPUs (nosotros tuvimos 16 de ellas con hyperthreading) no estaban muy estresadas. Asterisk estaba ocupando algunas de ellas bastante bien, pero las demás estaban aburridas sin saber qué hacer.

    Así que, ayúdame. Necesito responderle a John Todds algunas preguntas mientras el me invita a un vino realmente caro en la próxima Astricon. ¿Qué fue lo que ocurrió? ¿Fueron las tarjetas de red Broadcom? ¿Fue la placa base Intel 5530? ¿o una combinación? también pudo haber sido el switch barato Netgear…

    Espero tener más acceso a estas máquinas, tres de ellas para hacer test con el último código. En esta versión tenemos nuevas tablas hash, todos los añadidos y cositas chulas que los desarrolladores de Digium han reescrito dentro de Asterisk. La versión Trunk probablemente será mucho mejor que la 1.4 ya que está mas orientada a grandes cargas y un mayor número de canales simultaneos.

    Está en nuestra mano construir nuevas generaciones de Asterisk, más allá de la versión 1.0. A la vez, los chicos del hardware no han estado durmiendo. Ellos son los encargados de hacer hardware barato que haga que nuestro software brille. Necesitamos probar otras cosas y ver cómo se portan el resto de sistemas Asterisk además de estas pruebas de llamadas. Manager, eventos, música en espera, agi, … Nuevos retos interesantes.

    Así que, toma uno de esos servidores de HP y monta un proveedor para un pueblo. Mientras estés en ello, compra otro de repuesto… el hardware puede fallar ( 😉 ).

    Pero eso sí, no digas que Asterisk no escala bien. Estos tiempos ya pasaron.

    /Olle

    (traducción del original en VentureVoIP)

  • 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