Ya hemos visto algunos servicios que permiten conectar la web a servicios de VoIP para permitir llamadas de forma nativa, no obstante, el tipo de tecnología que se intenta unificar (web-voip) son bastante diferentes entre sí y esto complica su integración de una forma fácil y cómoda para el usuario. Hasta ahora, conocíamos algunos softphones webs que hacían uso de ActiveX (unicamente funcionan en Internet Explorer) o bien Java (lo que obliga a tener la máquina virtual instalada) de forma que el usuario necesita cumplir con unos requisitos previos que no siempre se garantizan cuando el visitante de una web puede ser cualquiera.
El tema de los softphones web es algo muy interesante y es que cada vez son más las empresas que quieren atraer a clientes potenciales mediante su web y una forma muy práctica de hacerlo es hablando directamente con él mediante VoIP pero esto es, o incompatible con todo, o bastante caro, por lo que al final, el usuario que quiere implementar un click2call termina utilizando el “botón Skype” o a “phono.com” por lo que está obligado a depender de un servicio que ofrece una empresa externa. Pero esto está muy próximo a acabar y es que el próximo objetivo de los desarrolladores de navegadores está orientado a implementar nativamente el soporte para VoIP (tanto audio como vídeo).
Para aquellos que no estén familiarizados con el mundo de la web, comentaré que todas las páginas webs utilizan un lenguaje llamado HTML donde se definen si el texto va en negrita, subrayado, el color, y muchas otras cosas. Este “lenguaje” ha ido evolucionando con el tiempo, de forma que actualmente la mayoría de los navegadores utilizan la versión 4 (HTML4) y algunas características de la versión 5 (HTML5) de forma experimental. Esta versión HTML5 es la que permite visualizar vídeos en la web mediante la etiqueta <video>.
Pues poco a poco, el HTML se está modificando para adaptar las nuevas tecnologías a la web y que tanto los desarrolladores web como programadores de servicios puedan utilizar la web como un aliado y no como “algo a lo que integrar” de forma que puedan ser implementado en los navegadores y los usuarios puedan utilizar dichos servicios sin necesidad de ningún tipo de plugin.
Un ejemplo de esto es la implementación de VoIP con vídeo que están desarrollando el I+D de Ericsson, de forma que están implementando en el motor HTML que utiliza Chrome y Safari posibilidades de VoIP bastante interesantes como podéis ver en el siguiente vídeo:
http://labs.ericsson.com
No obstante, no son los únicos y es que poco a poco se están haciendo avances en este sentido, de forma que para hacer una llamada de teléfono o una videoconferencia, tan solo tengamos que abrir una web.
El mundo de la web es altamente confuso, existen varias capas de desarrollo (html, javascript, php/ruby/python, frameworks, …) además de requerir conocimientos de todo tipo (bases de datos, diseño, animaciones, usabilidad, seguridad, etc…) y a todos nos gusta entrar en una página y poder hacer muchas cosas, pero el día que la web permita mantener conversaciones, conferencias, y videoconferencias, ese día creo que podremos decir con total tranquilidad, que la telefonía ha muerto y ya tiene sustituto.
Fuente: Sinologic.net
viernes, 3 de diciembre de 2010
Phono - Integracion Voip a nuestro Website
De vuela por estos rumbos pero siempre en el mundo de la voz ip :P un poco ajetreado con la empresa Voip Systems he dejado de lado lo que es el blog pero trataré de retomarlo de nuevo. Saludos a todos los visitantes y gracias por sus comentarios :)
Bueno empecemos con la carnita leyendo en Sinologic.net nos muestran un sitio que nos ayuda a integrar un boton click to call a nuestras webs.
Hace tiempo que tenía pendiente hablar sobre un servicio de la empresa Voxeo llamado phono.com y que permite integrar telefonía VoIP (pstn/sip) mediante código HTML y Javascript que, unido a un poco de Flash integrado de forma transparente por el servicio, nos permite crear click2call fácilmente en nuestras webs.
En la web de Saúl podéis leer un estupendo artículo con un ejemplo sobre cómo programar con JQuery y un poco de HTML un Click2Call para poder hacer una llamada sin necesidad de que el usuario tenga que poner su número de teléfono si no que pueda hablar desde la propia web como si estuviese conectado a un softphone. De hecho, aprovechando el artículo de Saúl, me he animado a comentarlo por aquí también.
Para que este servicio de Voxeo pueda funcionar, se requiere que el navegador sea compatible con Flash
he de decir que lo he probado unas cuantas veces y con un resultado bastante satisfactorio, tanto en calidad de sonido como en usabilidad y es que el código que hay que añadir tan solo requiere de una conexión a Internet y tener acceso al sistema de Phono.com (si, por desgracia es dependiente de un servicio externo).
Para que veáis lo fácil que es, además de poder ver una demo en el artículo de Saúl
Fuente: http://www.sinologic.net/blog/2010-12/phono-com-te-ayuda-a-integrar-voip-con-tu-website/
Bueno empecemos con la carnita leyendo en Sinologic.net nos muestran un sitio que nos ayuda a integrar un boton click to call a nuestras webs.
Hace tiempo que tenía pendiente hablar sobre un servicio de la empresa Voxeo llamado phono.com y que permite integrar telefonía VoIP (pstn/sip) mediante código HTML y Javascript que, unido a un poco de Flash integrado de forma transparente por el servicio, nos permite crear click2call fácilmente en nuestras webs.
En la web de Saúl podéis leer un estupendo artículo con un ejemplo sobre cómo programar con JQuery y un poco de HTML un Click2Call para poder hacer una llamada sin necesidad de que el usuario tenga que poner su número de teléfono si no que pueda hablar desde la propia web como si estuviese conectado a un softphone. De hecho, aprovechando el artículo de Saúl, me he animado a comentarlo por aquí también.
Para que este servicio de Voxeo pueda funcionar, se requiere que el navegador sea compatible con Flash
he de decir que lo he probado unas cuantas veces y con un resultado bastante satisfactorio, tanto en calidad de sonido como en usabilidad y es que el código que hay que añadir tan solo requiere de una conexión a Internet y tener acceso al sistema de Phono.com (si, por desgracia es dependiente de un servicio externo).Para que veáis lo fácil que es, además de poder ver una demo en el artículo de Saúl
Fuente: http://www.sinologic.net/blog/2010-12/phono-com-te-ayuda-a-integrar-voip-con-tu-website/
viernes, 6 de agosto de 2010
De vuelta :)
Hola luego de como 3 meses de no postear nada aqui volvemos jeje, hay muchos cambios que han habido en Asterisk ya fue liberada la rama 1.8 beta y bueno estamos muy contentos. Exitos y saludos
martes, 11 de mayo de 2010
Asterisk 1.4 continuará viva hasta Asterisk 1.8
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!
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!
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)