La semana pasada Elío Rojano comento un artículo en el que nos daba la noticia de que según la gente de Digium Asterisk seguiría viva hasta la salida de Asterisk 1.8
Maintenance of Asterisk 1.6.0 and 1.6.1 will move to security fixes only
in approximately one month. There are bug fix releases scheduled to be
released during the first half of May for both versions. After those
releases, Asterisk 1.6.0 and 1.6.1 will only receive security fixes.
The Asterisk development team recommends that all users of Asterisk 1.6.0
and 1.6.1 series move to the 1.6.2 series for continued bug fix support.
For more information on the maintenance schedule for Asterisk releases,
please see the following page:
http://www.asterisk.org/asterisk-versions
Note that the maintenance schedule for Asterisk 1.4 and 1.6.2 will
likely be extended, pending the final determination of the release
schedule for Asterisk 1.8.
Thank you for your continued support of Asterisk!
martes, 11 de mayo de 2010
miércoles, 5 de mayo de 2010
Sangoma anuncia su tarjeta de trascoding
Interesante artículo de Elio Rojano, les paso el detalle
Sangoma acaba de anunciar que próximamente pondrá a la ventauna nueva tarjeta de trascoding llamada Sangoma D100 que junto con un software especial será capaz de realizar el trascoding de hasta 480 llamadas simultaneas por cada tarjeta.
La Sangoma D100 estará disponible tanto para PCI como PCI Express utilizando un procesador incorporado en la tarjeta para realizar la conversión entre distintos códecs (como de G.711 a G.729) sin llegar a retrasar la comunicación ni cargar el propio procesador del sistema.
La tarjeta tendrá distintos niveles en función del número de canales simultaneos que se quiera convertir: 30, 90, 120, 240 ó 480 canales.
Además, el trascoding podrá realizarse desde cualquiera de los siguientes códecs sin que el códec original afecte al rendimiento ni al límite de canales:
Por último, añadir que estará soportado tanto Asterisk como FreeSWITCH e incluirá una API para que cualquier usuario pueda realizar desarrollos propios con ella.
La fecha de lanzamiento aún no ha sido anunciada, aunque se espera que esté disponible en pocas semanas y sobre el coste, el modelo básico de 30 canales costará unos $750, un poco cara en comparación con la tarjeta TC400B de Digium que por el mismo precio realiza el trascoding de 120 canales, aunque aún así, la D100 tampoco es la más cara del mercado.
Vía: http://www.telephonyware.com
Sangoma acaba de anunciar que próximamente pondrá a la ventauna nueva tarjeta de trascoding llamada Sangoma D100 que junto con un software especial será capaz de realizar el trascoding de hasta 480 llamadas simultaneas por cada tarjeta.La Sangoma D100 estará disponible tanto para PCI como PCI Express utilizando un procesador incorporado en la tarjeta para realizar la conversión entre distintos códecs (como de G.711 a G.729) sin llegar a retrasar la comunicación ni cargar el propio procesador del sistema.
La tarjeta tendrá distintos niveles en función del número de canales simultaneos que se quiera convertir: 30, 90, 120, 240 ó 480 canales.
Además, el trascoding podrá realizarse desde cualquiera de los siguientes códecs sin que el códec original afecte al rendimiento ni al límite de canales:
- G.711
- G.722
- G.722.1
- G.726
- G.729AB
- GSM-FR, GSM-EFR
- AMR, AMR-WB (G.722.2)
- iLBC
- L8 (Linear 8K), L16 (Linear 16K)
Por último, añadir que estará soportado tanto Asterisk como FreeSWITCH e incluirá una API para que cualquier usuario pueda realizar desarrollos propios con ella.
La fecha de lanzamiento aún no ha sido anunciada, aunque se espera que esté disponible en pocas semanas y sobre el coste, el modelo básico de 30 canales costará unos $750, un poco cara en comparación con la tarjeta TC400B de Digium que por el mismo precio realiza el trascoding de 120 canales, aunque aún así, la D100 tampoco es la más cara del mercado.
Vía: http://www.telephonyware.com
New open source linux VoIP monitoring tool with MySQL backand.
 VoIPmonitor is open source live network packet sniffer which analyze SIP and RTP protocol. It can run as daemon or analyzes already captured pcap files. For each detected VoIP call voipmonitor calculates statistics about loss, burstiness, latency and predicts MOS (Meaning Opinion Score) according to ITU-T G.107 E-model. These statistics are saved to MySQL database and each call is saved as pcap dump. Web PHP application (it is not part of open source sniffer) filters data from database and graphs latency and loss distribution.Voipmonitor also detects improperly terminated calls when BYE or OK was not seen. To accuratly transform latency to loss packets, voipmonitor simulates fixed and adaptive jitterbuffer. Key features: * Fast C++ SIP/RTP packet analyzer * Predicts MOS-LQE score according to ITU-T G.107 E-model * Detailed delay/loss statistics stored to MySQL * Each call is saved as standalone pcap file Download now! |
Fuente: VOIPTODAY
Cómo verificar tu Asterisk para una instalación en producción
En sinologic publicaron este excelente post que se acopla con el post de hace unos dias de la test suite de Asterisk
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 Ibarracuando, 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…
Para comprobar una versión estandar, Leif ha escogido la versión 1.6.2 y ha instalado todas las dependencias que hacen falta para ejecutar este sistema de auto-verificación:
Esto debería ejecutarse correctamente y sin darnos ningún error.
En el caso en que nos dé algún error de que nos falta alguna librería, necesitaremos instalarla y volver a ejecutar el ./configure
Continuaremos en el directorio testsuite:
Una vez ejecutado esta aplicación python, podremos irnos a tomar un café mientras el sistema empieza con sus tests con las herramientas que hemos instalado y que utilizará para hacer toda clase de pruebas.
Cuando volvamos unos minutos después (depende de la velocidad de nuestro sistema), y si todas las dependencias han sido instaladas correctamente y no hay mensajes que indiquen lo contrario, deberíamos ver el resultado de las pruebas una a una.
Leif comenta que el test completo debe tardar poco más de unos 2 minutos, aunque unos mensajes de timeout en la conexión con el AMI nos relentiza la salida además que nos devuelve unos mensajes extraños:
Aunque estos mensajes salen por unos motivos desconocidos, el resto de pruebas deben salir satisfactorias y deben aparecer con el mensaje: test passed. No obstante la salida es tan larga que no tiene sentido ponerla entera aquí, así que pondré algún trozo según lo que me ha ido saliendo:
Cada vez que se ejecuta un test diferente, el sistema borra toda la configuración y la vuelve a crear con los parámetros que le hace falta, por lo que es interesante tener a buen recaudo la configuración original que hayamos hecho o nos quedaremos sin ella.
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 Ibarracuando, 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…
Para comprobar una versión estandar, Leif ha escogido la versión 1.6.2 y ha instalado todas las dependencias que hacen falta para ejecutar este sistema de auto-verificación:
apt-get install libxml2-dev build-essential subversion libncurses5-dev python-yaml
apt-get install lua5.1 liblua5.1-0-dev libpcap-dev libpcap0.8-dev gcc g++ libxml2-dev; Instalamos el starpy
cd /usr/src/
wget "http://downloads.sourceforge.net/project/starpy/starpy/
1.0.0a13/starpy-1.0.0a13.tar.gz?use_mirror=kent"
tar xvfz starpy-1.0.0a13.tar.gz
cd starpy-1.0.0a13
python setup.py install; Instalamos el sipp
cd /usr/src
wget http://sipp.sourceforge.net/snapshots/sipp.2009-07-29.tar.gz
tar zxvf sipp.2009-07-29.tar.gz
cd sipp.svn
make pcapplay
cp sipp /usr/bin/
; Instalamos Asterisk utilizando subversion pero la rama "estable" 1.6.2
cd /usr/src
mkdir asterisk-complete
cd asterisk-complete
mkdir asterisk
cd asterisk
svn co http://svn.asterisk.org/svn/asterisk/branches/1.6.2 1.6.2-vanilla
cd 1.6.2-vanilla
svn co http://svn.asterisk.org/svn/testsuite/asterisk/trunk testsuite
./configure
make && make install
; Esto no será necesario, pero por si acaso hace falta...
if [ ! -e /etc/asterisk ]; then make samples; fi
Esto debería ejecutarse correctamente y sin darnos ningún error.
En el caso en que nos dé algún error de que nos falta alguna librería, necesitaremos instalarla y volver a ejecutar el ./configure
Continuaremos en el directorio testsuite:
cd testsuite
cd asttest
make && make install
cd ..
./runtests.py
Una vez ejecutado esta aplicación python, podremos irnos a tomar un café mientras el sistema empieza con sus tests con las herramientas que hemos instalado y que utilizará para hacer toda clase de pruebas.
Cuando volvamos unos minutos después (depende de la velocidad de nuestro sistema), y si todas las dependencias han sido instaladas correctamente y no hay mensajes que indiquen lo contrario, deberíamos ver el resultado de las pruebas una a una.
Leif comenta que el test completo debe tardar poco más de unos 2 minutos, aunque unos mensajes de timeout en la conexión con el AMI nos relentiza la salida además que nos devuelve unos mensajes extraños:
...
Installing Asterisk …
Installing sample configuration …
Running ['tests/cdr/console_fork_after_busy_forward/run-test', '-v', \
'SVN-branch-1.6.2-r260441'] …
AMI Login attempt #1
AMI Login attempt #2
AMI Login attempt #3
AMI Login attempt #4
AMI Login attempt #5
AMI login failed after 20 second timeout ???????
–> Running test ‘cdr/console_fork_before_dial’ ...
Aunque estos mensajes salen por unos motivos desconocidos, el resto de pruebas deben salir satisfactorias y deben aparecer con el mensaje: test passed. No obstante la salida es tan larga que no tiene sentido ponerla entera aquí, así que pondré algún trozo según lo que me ha ido saliendo:
--> Running test 'manager-action-events-response' ...
Uninstalling Asterisk ...
Installing Asterisk ...
Installing sample configuration ...
Running ['tests/manager-action-events-response/run-test', '-v', \
'SVN-branch-1.6.2-r260441'] ...
testing with brokeneventsaction off (default)
sending 'EventMask: '
sending 'EventMask: ON'
sending 'EventMask: yes'
sending 'EventMask: all'
sending 'EventMask: all,user'
sending 'EventMask: system,user,agent'
sending 'EventMask: off'
sending 'EventMask: none'
sending 'EventMask: yeah whatever'
sending 'EventMask: 1'
testing with brokeneventsaction on
sending 'EventMask: '
sending 'EventMask: ON'
sending 'EventMask: yes'
sending 'EventMask: all'
sending 'EventMask: all,user'
sending 'EventMask: system,user,agent'
sending 'EventMask: off'
sending 'EventMask: none'
sending 'EventMask: yeah whatever'
sending 'EventMask: 1'
test passed
Cada vez que se ejecuta un test diferente, el sistema borra toda la configuración y la vuelve a crear con los parámetros que le hace falta, por lo que es interesante tener a buen recaudo la configuración original que hayamos hecho o nos quedaremos sin ella.
Suscribirse a:
Entradas (Atom)