I created a new branch that implements Adobe’s RTMP (Real Time Media Protocol).

It allows Asterisk to connect as a client to an RTMP media server like Red5 or FMS (Flash Media Server), and then publish or receive media streams from such server. I only tested the connection with Red5.

To install the branch, you’ll need several libavcodec, included in FFMPEG version 0.6. Be careful to configure FFMPEG’s sources with the –enable-shared option activated in the configure script.

Prior to install Asterisk, you need to have librtmp on your system. librtmp is part of the rtmpdump program : http://rtmpdump.mplayerhq.hu/[^]

To install it :
# wget http://rtmpdump.mplayerhq.hu/download/rtmpdump-2.2e.tar.gz [^] [^]
# tar zxvf rtmpdump-2.2e.tar.gz
# cd rtmpdump-2.2e/
# make
# make install

To install Asterisk :
# svn co http://svn.digium.com/svn/asterisk/team/phsultan/rtmp-support [^] asterisk-rtmp
# cd asterisk-rtmp
# ./configure
# make menuselect [check here that chan_rtmp is eligible for installation]
# make
# make install

- phsultan -

https://issues.asterisk.org/view.php?id=15484

El vídeo lo podéis ver a continuación:

Entre las novedades que Asterisk 1.8 trae, la más interesante y que ya hemos contado varias veces es el tipo de versionado LTS (Long Term Support) de manera que cada versión nueva se considerará más estable que la anterior y su liberación no se basará en “fechas de publicación” si no en la verificación de estabilidad necesaria para ser publicada.

Esto seguramente haga que muchas personas pasen de Asterisk 1.4 directamente a Asterisk 1.8 sin pasar por Asterisk 1.6, pero esto tiene un gran problema: los cambios de la versión 1.8 con respecto a la versión 1.4 son muchos y bastante importantes que han ido evolucionando paulatinamente en Asterisk 1.6 pero que ya son requisitos básicos en Asterisk 1.8.

Por ejemplo, para reiniciar el sistema:

En Asterisk 1.4: restart now
En Asterisk 1.6: core restart now (aún admite 'restart now' como comando obsoleto)
En Asterisk 1.8: core restart now 

Hace unos días se hizo pública la versión Asterisk 1.8.0-beta1, y ayer salió la versión Asterisk 1.8.0-beta2 con las primeras correcciones de la beta1.

Se nota que los desarrolladores están ilusionados con esta nueva versión que incorpora muchas mejoras, algunas complejas de entender y utilizar (SRTP, Fax, CEL, IPV6, Jabber, AOC, iCal, y un largo etcétera que iremos viendo poco a poco) pero que es recomendable empezar a conocerlas y aprender a configurar y utilizarlas.

Acaba de publicarse también la beta del LibPRI 1.4.12-beta1 que incorpora el soporte de AOC, mejoras en el QSig y algunos cambios más, pero claro, de momento ya entramos en la “etapa beta” por lo que habrá que esperar a que sea estable antes de pasarlo a producción.

Muchos usuarios que no actualizaron a Asterisk 1.6 seguramente estén temerosos con la nueva versión por lo que podría retrasar la actualización, aunque los cambios y las mejoras realmente merecen la pena portar el sistema a 1.8, aunque lógicamente todo requiere de bastante tiempo de “adaptación” para los nuevos cambios, pruebas y más pruebas antes de pasar a producción.

Ahora hago este pequeño aporte avisando que ya es público el programa de firmware beta para actualizar dichos equipos.

Y este es su link: http://www.grandstream.com/BETATEST/GXV3140_Skype/

Como siempre, cuidado al actualizar los firmwares y disfruten su nuevo equipo con skype y GoogleTalk habilitado!!!!

Empezamos con un único artículo pero había tantas cosas que el artículo era excesivamente largo, por lo que hemos decido dividirlo e ir estudiando cada una de las mejoras/features más intersantes y controvertidas.

La primera de ellas es ¿un paso adelante? el hecho de no evitar poner la cadena register en el sip.conf, si no que se añaden nuevos parámetros al peer para permitir el registro, de esta forma la habitual cadena:

register => user@a.example.com@b.example.com

Es equivalente a :

[provider]

type=peer

register=yes

host=a.example.com

registrarhost=b.example.com

REGISTER sip:b.example.com SIP/2.0

To: sip:user@a.example.com

From: sip:user@a.example.com

…

Russell Bryant

Hay muchas novedades, entre ellas la nueva forma de versionado basado en LTS (Long Term Support) la forma de publicar nuevas versiones que ha demostrado ser la más interesante para mejorar la estabilidad.

Otra de las grandes novedades es el soporte de IPV6, mejoras en la gestión y tratamiento de faxes y nuevas aplicaciones que harán del sistema aún más completo que la versión de Asterisk 1.6.2, pero lo más importante es sin duda que existe una gran espectación sobre la estabilidad de esta nueva versión, ya que es sin duda el gran atractivo para sistemas en producción y que, en teoría, debería convencer a los usuarios de Asterisk 1.4 para actualizar Asterisk.

De momento, lo que falta es quizá la parte más importante para conseguir dicha estabilidad: desarrolladores y betatesters empiecen a hacer pruebas y reportar aquellos fallos o características que no funcionan correctamente para poder publicar una versión libre de fallos básicos, problemas heredados de otras versiones y lo más estable posible.

Es fácil criticar una nueva versión cuando tiene fallos, pero si no se reportan, estos seguirán ahí para las siguientes versiones, así que es el momento de probar y reprobar todas aquellas funciones que utilizamos generalmente y vamos a necesitar en el presente (y posiblemente en el futuro) para evitar sorpresas desagradables y disponer de una nueva rama tan estable como podamos entre todos.

En los vídeos presenta el nuevo terminal de GrandStream GXV3104 y los foneBridge2 de Redfone de una forma bastante sencilla y didáctica.

y la segunda parte …

Entre otras mejoras, la compatibilidad con Linux es una de las necesidades básicas y requerimientos mínimos por lo que dejé de probarlo, ahora por fin dispone de una versión Linux (hace ya tiempo, aunque no lo había vuelto a ver desde entonces).

La nueva versión 3 incorpora soporte de bases de datos MSSQL, MySQL, Postgres, Sybase, HSQL, … además de servicios y servidores de email como Gmail, Sendmail, Exim etc. a la vez que mejora la integración con otros interfaces y distribuciones como FreePBX, PBX-in-a-Flash, PIAF o Elastix.

Parece ser que han mejorado bastante la integración con Colas, faxes, CDR y soporte de DAHDI y SIP.

Como ya dije la otra vez, no soy muy amigo de los interfaces gráficos, simplemente porque creo que sabiendo cómo funcionan las cosas, es más rápido escribir con el teclado que moviendo el ratón y pulsando botones. Además los interfaces gráficos limitan bastante la potencia (pese a que todos mencionen el ‘*_custom.conf‘) soy de los que prefiero un dialplan sencillo, limpio y fácil de entender en lugar de algo “fácil de hacer” pero imposible de depurar, quizá por esto nunca me ha hecho gracia los interfaces web y mucho menos para algo profesional o del que dependa una empresa.

No obstante Visual Dialplan 3 combina ambos casos:

- No ensucia el dialplan (ya que no incluye nada propio, y únicamente traduce lo “visual” a “texto simple”).
- Es más atractivo para alguien acostumbrado a “los botones” y a manejarse con Windows.

Además incorpora de una ayuda contextual para aquellos que no sepan muy bien el funcionamiento de alguna aplicación o alguna función de Asterisk.

Podéis descargar una demo de 30 días para Windows o para Linux en su página web:
http://www.apstel.com/download/

La presentación está en inglés, pero como os daréis cuenta, se entiende bastante bien.

Enlace: https://www.brainshark.com/brainshark/vu/view.asp?pi=zHnzBv9g6z1rtuz0

Vía: VoipToday.org

i6Net acaba de desarrollar un canal especial de Asterisk para poder realizar conferencias de audio y vídeo vía web a través de Flash añadiendo soporte Flash/RTMP a Asterisk de forma que cualquier persona que disponga de un navegador web con soporte Flash pueda realizar videoconferencias de una forma fácil y rápida sin necesidad de configurar softphones ni forzar a Asterisk a realizar llamadas telefónicas vía PSTN.

We are please to announce a new important feature for voice & video services over VXI* 5.1 next release. Flash/RTMP for Asterisk / VXI* is an add-on channel driver for Asterisk-based PBX systems. Adding Flash/RTMP for Asterisk to any Asterisk server enables complete access to manage bi-directional video calls from a Web browser with a Flash player.

Flash/RTMP for Asterisk / VXI* is an add-on channel driver for Asterisk-based PBX systems. Adding Flash/RTMP  for Asterisk to any Asterisk server enables complete access to manage bi-directional video calls from a Web browser with a Flash player.

Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by Adobe Systems for streaming audio, video and data over the Internet, between a Flash player and a server. Adobe Flash, is the industry-leading web application environment, present in web browsers on 99% of the world’s computers. Flash can access the webcam and microphone on a PC and works through any firewall.

Features:

• • RTMP Video IN/OUT
  • RTMP Audio IN/OUT
  • DTMF

Flash/RTMP can send or receive video calls from/to:

• • Video 3G-324m
  • Video SIP
  • Video h323
  • Video Flash/RTMP

Sin duda, esto es lo que muchos conocidos estaban esperando que alguien desarrollase tarde o temprano, así que por fin lo tenemos aquí.

Pese a haber estado más de 10 años intensamente relacionado con el mundo Asterisk, a través de la empresa “Sokol & Associated” que justo hace 3 años fue adquirida por Digium y pasaron de ser consultores independientes y organizadores de la Astricon, a trabajar en distintos puestos de Digium (coordinadores de la comunidad, desarrolladores, director de productos, etc.) y ahora se embarca en un proyecto que está pasando por horas bajas: Fedora, que necesita un poco de aire fresco si desea innovar y ser una distribución que ofrezca algo diferente a otras y seguramente Jared Smith pueda traer algo de esto.

Los profesionales, en lugar de apostar por Fedora prefieren la seguridad de un sistema operativo con soporte como RedHat, y los usuarios que buscan una distribución parecida pero libre, suelen decantarse por otras CentOS, Mandriva o Ubuntu, por lo que Fedora, pese a ser una de las mejores y más sólidas distribuciones de Linux, llevaba algún tiempo en un silencio sospechoso, pero la incorporación de Jared seguro que será una buena señal.

Desde Sinologic le deseamos lo mejor y esperamos que aunque ahora esté ocupado con otros menesteres, pueda seguir dentro de la comunidad Asterisk y aportando su granito de arena que siempre ha sido importante.

Más información:
http://blogs.digium.com/2010/07/06/digiums-fond-farewell-to-jared-smith/
http://press.redhat.com/2010/06/29/introducing-fedora-project-leader-jared-smith/

Se trata de un módulo de Call Center sencillo, que aún así creo que cubre todas las funcionalidades básicas que puede requerir un pequeño Call Center. Muy fácil de instalar y configurar. Puede descargarse de la página de Elastix y actualmente se encuentra en la versión 1-5.3-5. Intuitivo, y de fácil gestión por parte de usuarios no avanzados. Permite gestión agentes, colas, campañas entrantes y salientes, desarrollo de formularios, llamadas predictivas y gestión de tiempos de descanso. Cuenta además con una serie de estadísticas básicas y opciones de monitorización en tiempo real, tanto de los agentes como de las llamadas entrantes.

Las campañas salientes funcionan generando llamadas de forma predictiva  a un listado de teléfonos. En el momento en que el cliente contesta la llamada, esta pasa a ser gestionada por una cola de agentes. Los formularios pueden ser asociados a las campañas salientes de forma que todos los datos recogidos en dichos formularios son guardados en base de datos y pueden ser descargados en formato csv desde el propio panel de gestión.

Las campañas entrantes son asignadas colas de agentes que atenderán las llamadas. Pueden darse de alta los clientes en el sistema, lo que permite una mejor atención al usuario en el momento de recibir la llamada. Tanto a las campañas entrantes como a las salientes pueden asociársele scripts que facilitan la gestión de las llamadas.

El módulo de Call Center cuenta con una consola de agente desde la que estos deberán loguearse. Desde dicha consola pueden gestionarse las campañas entrantes y salientes, mostrándose los scripts y formularios asociadas a las mismas en el momento de recepción de una llamada. Permiten además transferencia de llamadas, tiempos de descanso, y acceso al CRM Vtiger integrado con Elastix.

Inconvenientes

Uno de los principales inconvenientes que le he encontrado a este módulo de Call Center consiste en que una vez que el agente se loguea (desde la consola de agente), su teléfono queda en línea y conectado a la cola. No puede colgar el teléfono en ningún momento, ya que esto le desconectaría de la cola. Las llamadas de campañas salientes y entrantes le entrarán a los distintos agentes en modalidad auto-answer. Por mi parte considero que resultaría más práctico para el agente que el teléfono quedará logueado en las colas sin necesidad de tenerlo continuamente descolgado y escuchando música en espera, y que las llamadas tanto entrantes como salientes sonarán primero en su teléfono, antes de establecerse.

Por otro lado, los formularios sólo se pueden asociar a campañas salientes, no a campañas entrantes. En campañas entrantes, la gestión de la llamada debe limitarse al uso de scripts o del CRM.

Los formularios son muy intuitivos y sencillos de desarrollar. Sin embargo, carecen de opciones condicionales, de forma que no es posible presentar una pregunta u otra dependiendo de las respuestas que el usuario haya dado a las preguntas anteriores del formulario.

Características

Las principales características del módulo de Call Center de Elastix son las siguientes:

• Marcador predictivo
• Soporte Do-Not-Call List
• Campañas entrantes y salientes
• Diseño de formularios
• Asociación de formularios a campañas
• Asociación de scripts a campañas
• Consola de agente
• Tiempos de descanso
• Estadísticas de llamadas y monitorización en tiempo real
• Integración con CRM
• Conexión a base de datos (Oracle, MS SQL, Mysql, PostgreSQL)

Además, este módulo de Call Center viene con un pequeño conjunto de estadísticas, que en caso de no ser suficientes para determinados Call Center, podrían complementarse con la instalación de un QueueMetrics, que resulta totalmente integrable con la solución de Elastix.

• Estadísticas de tiempos de descanso
• Llamadas por hora
• Llamadas por agente
• Tiempos de espera
• Tiempos de logueo
• Gráfico de llamadas por hora
• Monitorización de agentes
• Monitorización de llamadas entrantes
• Información del Agente
• Estadísticas de tiempos de conexión de agentes por día
• Estadísticas de usos de trunks por hora y día

Adjunto link del brochure así pueden ver que trae…

http://www.grandstream.com/products/gxv_series_phone/gxv3140/documents/gxv3140_brochure_spanish.pdf

Ahora vamos a lo que importa…luego de upgradear el firmware (no les puedo pasar el mismo por orden de Grandstream) Vemos en el teléfono este nuevo menú…

Podemos ver claramente los nuevos menúes Skype y Google Voice….Como los configuramos muy simple, en la interfaz gráfica solo insertamos nuestra cuenta actual de Skype o Google Voice (user y password) y listo….

Luego solo cargamos la app Skype por ejemplo…en este caso aparece nuestro gran amigo Elio!!!

Ahora se nos da la lógica…o sea elegimos a quien queremos llamar de nuestra lista o la agregamos y solo oprimimos el botón llamada y listo….llamando a nuestro amigo Elio (el cual estaba en Huelva en su hotel descansando a las 11 de la noche cuando haciendo estas pruebas lo molesté…sorry amigo!!! )

Aquí podemos ver la pantalla de la conversacion de voz en curso….

Digamos que una prueba de video a las 11 de la noche no podía ser efectuada por razones obvias de respeto al buen gusto humano…

Ahora si a lo importante…la calidad de voz…sacando algunos glitches de sonido que asumo debían ser por el wifi del hotel de Elio la calidad fue excelente en casi todo momento…luego probe con otros amigos la funcion de video y me sorprendio la calidad y la fluidez con solo 256kb de subida de datos….

Lo mismo casi exacto para google voice cuya app aqui podemos ver…

Realmente un thumbs up para Grandstream quienes se están luciendo cada día mas con equipos de bajo costo, muy alta calidad y con prestaciones al momento únicas para un equipo que ronda los 270/300 dólares por unidad lo cual lo hace especialmente interesante como plataforma multimedia de comunicaciones….

Skype ha sido una de las que más han hecho por promocionar este tipo de servicios (no en vano es uno de los proveedores de VoIP más grandes gracias la publicidad y al apoyo de sus incondicionales usuarios), pero uno de los principales factores que ha hecho que la videoconferencia empiece a despegar, ha sido gracias a la escasez de inconvenientes a la hora de hacer una.

No hay nada que perjudique la adopción de una tecnología que la imposibilidad por algún problema técnico de llevarla a cabo. Problemas como los producidos por una mala configuración de un router, un firewall obtusamente cerrado o incluso una incompatibilidad con el protocolo pueden ocasionar que alguien que se esté planteando adoptar una solución, abandone el intento tras ver que detrás hay demasiados engranajes que pueden soltarse y que pueden hacer perder el tiempo a todos si es demasiado complejo.

Cada vez hay más personas que utilizan Skype para hacer videoconferencia, no porque sea mejor, si no simplemente, porque es rápido y fácil, prácticamente el mismo motivo por el que Windows se utiliza en la mayoría de los ordenadores personales y es que, se ve que para que algo como la videoconferencia, que ya produce un cierto rechazo debido a la supuesta “invasión a la intimidad”, si además da problemas (hay que abrir puertos en el router, el firewall corta el audio, insuficiente ancho de banda, etc…) está claro que no despegará jamás.

No obstante, Apple acaba de hacer una de las mejores promociones de videoconferencia “móvil” gracias a su “spot publicitario” del iPhone 4 que ha dado la vuelta al mundo.

A los pocos días, nuestro compañero David Prieto nos enseñaba cómo se puede hacer prácticamente lo mismo mediante cualquier terminal con Android (salvo por la diferencia de la falta de una cámara frontal que ya traerán en próximas versiones).

Lo que llama la atención es, que mientras servicios de “videollamada” (vamos a llamarlo así por diferenciar) que ofrecían los operadores de telecomunicaciones eran “de baja calidad y bastante caros” (entre 45 y 60 céntimos de Euro por minuto), estoy convencido que en cuanto empiecen a aparecer terminales de nueva generación (tipo iPhone, Android, … Android… iPhone… ¿hay algún otro?. O:) con cámara frontal y capaces de realizar videoconferencias a través de redes Wireless o aprovechando la conexión a Internet mediante 3G (que no los servicios propios 3G de las operadoras) los usuarios preferirán llamarse “gratis” haciendo una videoconferencia, que pagar el coste de una llamada sólo para voz.

¿Tu utilizarías la videoconferencia en tu móvil si esta fuese completamente gratuita?

Hasta hace poco, el servicio de google, a través del cual se ofrecia un número único, estaba disponible en versión de beta solo para los usuarios americanos exclusivamente ademas por sistema de invitacion… No pocos, atraidos por lo que significa google, buscaron tretas para evitar el filtro que google imponia en su web de registro, en el cual solo permitia a usuarios con IP de USA acceder al servicio … permitiéndonos así probarlo y disfrutarlo sin dicha limitación..

El servicio promete.. recordemos ademas que la adquisición de Gizmo hace unos meses por parte de Google es un claro augurio de que el desembarco en el sector de VoIP, por parte de Google, va en serio…. y lo que hemos visto, promete…

Existen fuertes rumores de que Google quiere desembarcar en la telefonia empresarial este año, no solo con una aplicación específica de desktop (algo por lo que tiene mucho sentido la compra de Gizmo), sino tambien integrando en googleapps y en gmail dicho servicio.

Quien quiera probarlo personalmente, tanto en el blog de GoogleVoice como en su site, encontrará información detallada sobre las intenciones de google para abrir el servicio, y su disponibilidad.

UPDATE: Google acaba de publicar un update hace unos minutos en su web, aclarando (tal vez en reaccion ante el aluvion de resgistros) que aunque han abierto el programa en general sin requerir invitación, SIGUE por el momento limitado a usuarios americanos… asi que quien quiera anticiparse a probarlo, tendra que usar el link de “tretas” que adjuntaba arriba, y que en su día publicó saghul. Parece que por “ya disponible para todos” google se limitaba al usuario americano….

Existen en el mercado diversos software integrables con centralitas Asterisk que nos dan estas y muchas más funcionalidades. Yo personalmente he trabajado con los siguientes, que creo que constituyen un buen compendio de las diferentes alternativas que podemos encontrarnos.

Flash Operator Panel 2

El FOP 2 es el panel de operadora desarrollado por Nicolás Gudiño. Es la evolución del FOP,  el cual,  aunque cubría muchas de las necesidades de panel de operadora de pequeñas empresas, no era escalable para ser utilizado en grandes entornos con un gran número de extensiones.

FOP 2 es sin embargo un panel de operadora totalmente escalable, práctico para todo tipo de entornos en los que trabajemos con centralitas Asterisk y necesitemos de una monitorización en tiempo real del estado de extensiones, colas, agentes y trunks.

Cubre funcionalidades que abarcan formas de trabajo en entornos muy diferentes. Nos sirve tanto para recepcionistas, supervisores de call center, o usuarios finales. Es compatible con Asterisk y con soluciones basadas en Asterisk y FreePBX, como puede ser Trixbox o Elastix.

Está basado en web, con lo que puede ser accesible desde cualquier puesto de la compañía sin necesidad de instalar ningún tipo de software en puesto cliente. Permite además conexión a diferentes Asterisk, lo cual nos da la opción de utlizarlo en entornos multitenant o multiservidor.

Tiene un coste por servidor de tan sólo 40 $.

Características.

Recepcionistas

• Ver si una extension está o no disponible
• Transferencia directa a la extensión o al buzón de voz
• Captura de llamadas
• Búsqueda y filtrado de extensiones (escalable a cientos de extensiones)

Supervisores de call center

• Monitorizar agentes logueados en una cola
• Monitorizar estado de los agentes (logueados, pausados, inválidos)
• Monitorizar  llamadas en espera en colas, con tiempos asociados
• Gestión de agentes: añadir o quitar agentes de colas, pausar agente
• Filtrado de agentes en la lista de extensiones en un click
• Escucha o whisper a agentes

Usuarios finales

• Notificación de llamadas (identificación de llamante, llamadas de colas)
• Integración con directorio, búsqueda, y llamadas a números internos y externos
• Soporte .tel. Teclea el dominio .tel y obtendrás el número de teléfono que buscas, o podrás hacer incluso una llamada voip
• Control de llamadas: transferencia, colgado, captura, etc.
• Control de conferencias: bloquear, invitar, echar o silenciar a participantes

Isymphony

iSymphony es un panel de operadora desarrollado por i9technologies para entornos Asterisk. Está basado en software cliente-sevidor java, lo que implica la instalación de un software tanto en el servidor como en cada uno de los clientes que quieran poder utilizarlo. Es también compatible con centralitas basadas en Asterisk y FreePBX, como Trixbox.

Una de las ventajas de este programa es la facilidad de instalación y configuración que tiene. Es muy intuitivo y fácil de usar, y tiene un interfaz muy personalizable.

Características.

• Buzón de voz
  Es posible acceder a los mensajes del buzón de voz, escucharlos, organizarlos, borrarlos o enviarlos a otra extensión para que puedan escucharlos.

• Estadísticas de agentes y colas.
  Diferentes estadísticas de agentes y colas que nos permiten monitorizar nuestro call center.
• Interfaz configurable
  El interfaz te permite organizar y cambiar de tamaño las diferentes pestañas de forma personalizable, simplemente arrastrándolas de un punto a otro de la pantalla.
• Múltiples vistas
  Es posible configurar las vistas de forma que nos muestren las extensiones, tanto locales como remotas, de diversas formas, desde unas muy detalladas hasta otras más genéricas. 
• Multiempresa
  El programa puede conectarse con diferentes Asterisk conectados en diferentes lugares
• Vistas rápidas
  Vistas rápidas para todos aquellos módulos que el usuario utilice más frecuentemente.
• Permisos
  Diferentes permisos para diferentes usuarios muy granulados, administrables de forma sencilla.
• Salas de conferencia
  Monitorización de salas de conferencia, creación de salas, pasar llamadas en curso a salas, invitar a usuarios, etc…
• Colas y agentes
  Logueo y deslogueo de agentes. Vista del estado actual del agente y de las colas.
• Agendas de extensiones
• Interfaz de administración
• Chat
  Integración con Jabber para chat.
• Estados de presencia personalizados
  Es posible crear estados como fuera de oficina, comiendo, en una reunión, así como la hora a la que el usuario regresará a su puesto, e incluso una nota si así se desea. Esta información podrá ser vista por el resto de usuarios de isymphony.

Existen tres versiones diferentes del programa. Una gratuita, y dos de pago. En las de pago existe una versión estándar y una específica de Call Center. La comparativa entre las diferentes versiones podemos verla en la siguiente tabla.

Las versiones de pago tienen un coste por servidor y por programa en puesto cliente que instalemos. La versión de servidor tiene un coste de 595 $ y cada puesto cliente nos costará 19,95 $.  Una tabla más detallada de precios podemos encontrarla aquí.

Windows Operator Panel

El  Windows Operator Panel (WOP) es un programa de operadora para entornos Asterisk, que proporciona panel rápido de búsqueda, lo que hace sencillo buscar extensiones tanto por nombre, extensión o departamento.

Está preparado para funcionar en un entorno multirecepcionista, de forma que pueda haber varias recepcionistas atendiendo simultáneamente las llamadas, sin que ninguna de ellas pueda acceder equivocadamente acceder a otra llamada que ya está siendo atendida.  Nos da información también sobre usuarios de otras sedes, y la operadora puede transferir llamadas a estas delegaciones.

Es integrable con PhoneOCS, de forma que, además de compartir una agenda común,  la operadora puede interacturar con el usuario final y recibir los mensajes que el usuario quiera comunicar, como no pasar llamadas por estar en una reunión o cualquier mensaje específico que la operadora deba tener en cuenta si alguien le intenta localizar.

Características.

Versión Básica  (gratuita hasta 30 usuarios)

• Multilingüe
  Inglés, español.
• Monitorizacion de extensiones
  Permite visualizar el estado de las extensiones.
• Multisede y/o empleados remotos
  El programa permite tener un listado global de todos los empleados de la empresa, diferenciando a aquellos usuarios que están en otras sedes.
• Búsqueda rápida de usuarios
  Búsqueda por apellido, departamento o extensión.
• Transferencia con o sin consulta
• Parking
  Las llamadas pueden ser dejadas en espera
• Categorización
  Los diferentes usuarios pueden ser agrupados en diferentes pestañas por cada recepcionista
• Agenda Integrada
  La recepcionista dispone de una agenda para las llamadas entrantes.
• Ex-empleados
  El  programa permite visualizar usuarios que ya no estan activos en la empresa.
• WOP Admin
  Panel web de administración para alta de nuevas extensiones.
• Notas de Operadora
  A través del WOP Admin, la operadora puede adjuntar determinadas notas u observaciones a cada uno de los usuarios.

Cuenta con una versión gratuita, para menos de 30 extensiones, y dos versiones de pago. Las diferencias entre ellas, pueden verse aquí.

Los precios para las versiones de pago pueden consultarse a través del formulario de contacto de su página web.

Asterisk y la domótica son grandes amigos desde hace tiempo, pero como siempre faltan ver proyectos donde puedan ser utilizados y donde el coste final no haga que el proyecto finalice antes de tiempo.

Aquí os dejo el vídeo:

La versión 1.7 de AsteriskNow tiene como novedad principal un wizard que permite escoger una variedad de opciones diferentes en la instalación, desde el GUI a utilizar (el popular FreePBX, el antiguo interfaz, o incluso, para los puristas, ninguno), y la posibilidad de usar como base una versión 1.6.2 o partir de la mas conservadora 1.4

La instalación de AsteriskNow es increiblemente rápida, en menos de 30 minutos, y tras contestar unas cuestiones básicas, está instalado.

La instalación abarca un CentOS como linux base, el framework DAHDI, la consola administrativa del FreePBX, la base de datos MySQL, y el servidor web Apache.

Mas información, aquí

Entre esas peticiones destacan en primer lugar las que piden más información del proyecto, seguidas de las que solicitan información de como participar. También hemos recibido varios mails que nos piden más ejemplo prácticos que puedan implementar sin necesidad de adquirir equipamiento adicional, o por último, peticiones que nos piden que avisemos de próximos eventos y con más antelación.

Empezando por el primer punto, os recomendamos un vistazo a la siguiente presentación, que aporta una estupenda introducción de como integrar Asterisk con sistemas de Radio:

En cuanto a la segunda petición (como participar en el mismo o ampliar información), podemos usar las tradicionales listas de correo y grupos de google (mailing list), la información que se publica en las redes sociales a través de una página especifica en facebook, y por supuesto la propia página web del proyecto..

En respuesta al tercer punto, el avance y situación del proyecto, podemos mencionar que este avanza rápidamente, ya que poco a poco, se están uniendo un montón de nodos.  Además de Valencia, corazón y origen del proyecto, existen nodos en Madrid, Barcelona, Canarias, y ya cruzando el “charco”, el primer enlace “overseas”  …

Gráfico 1 - Situación Actual Red HSMMN

Además del gráfico anterior,  en flickr podemos encontrar interesantes gráficos y fotos sobre las instalaciones  y el estado actual del proyecto, incluyendo planos detallados y fotos de equipos, nodos, eventos, conferencias….

Para aquellos más inquietos que quieran empezar a ver posibilidades, os adjuntamos a continuación un código que podeis probar en vuestra propia centralita, y a través del cual, marcando la extensión 6000, podemos escuchar a la torre de control del aeropuerto de sevilla (TWR LEZL) . El código está preparado para recoger el audio en tiempo real de una fuente de streaming en internet donde la torre de radio deja sus emisiones, y como prueba de concepto nos permite ver alguna de las posibilidades del sistema sin necesidad de tener una radio en nuestro sistema. De esta forma, podemos asignar la música de fondo “radio” para cuándo entre una llamada por un DID, a una extension, o una cola de agentes.

En primer lugar, editamos el fichero musiconhold_custom.conf y añadimos lo siguiente:

[radio]
mode=custom
dir=/var/lib/asterisk/mohmp3/radio
application=/usr/bin/mpg123 -q -r 8000 -f 8192 -s –mono http://bos.liveatc.net/lezl

Volvemos a cargar la configuración de MoH en Asterisk

[user@asterisk] asterisk -vvvvvvr
voip*CLI> moh reload
== Parsing ‘/etc/asterisk/musiconhold.conf’: == Found
== Parsing ‘/etc/asterisk/musiconhold_custom.conf’: == Found
== Parsing ‘/etc/asterisk/musiconhold_additional.conf’: == Found

voip*CLI> moh show classes
Class: default
Mode: files
Directory: /var/lib/asterisk/moh
Class: none
Mode: files
Directory: /var/lib/asterisk/moh/.nomusic_reserved
Class: radio
Mode: custom
Directory: nodir
Application: /usr/bin/mpg123 -q -r 8000 -f 8192 -s –mono

http://bos.liveatc.net/lezl

Format: slin

voip*CLI> reload

Creamos una “custom extension” para este fin:

[root@asterisk] vi extensions_custom.conf
; Extension especial LiveATC
exten => 6000,1,Answer
exten => 6000,2,MusicOnHold(radio)

Por último, y en relación a los próximos eventos, mencionar que la próxima cita es la MercaHAM 2010, un importante evento que empieza el próximo dia 12 de junio en Cataluña, congrega a cientos de aficionados al mundo de la radio, y en el cual nuestro compañero Alex, dará una conferencia sobre las posibilidades de Asterisk en ese mundo, y sobre el proyecto en sí. Os recomendaria a todos los que tengais la posibilidad, que os asistais o informéis sobre el MercaHAM, un evento que supone para los usuarios de radio, lo que el VOIP2DAY supone para los usuarios de Asterisk, pero con el especial aliciente de que este año, gracias a Alex, Asterisk tendrá una importante presencia en el evento. Sin duda, un gran escaparate para que podamos ver las posibilidades de este proyecto.

Lo más llamativo de esta nueva versión es que añade la opción de Videollamada. En cuanto he visto el “changelog” y el video de demostración que hace su autor, no he podido esperar a probarlo y la verdad es que he quedado gratamente sorprendido:

Al principio pensé que “claro, claro… es la demo. Seguro que no va igual en la realidad”. Pero me equivoqué. En la realidad (por wifi) funciona, y muy bien.

He probado a hacer una llamada entre dos Android en la misma LAN (dos HTC Magic, que no destacan precisamente por su potencia) y el video era realmente fluido. También probamos a hacer una llamada entre un android y un softphone en el PC (xlite) a través de internet, comprobando que la compatibilidad es total.

Esperemos que el video-softphone del nuevo iPhone cumpla también con los estándares y podamos “ver” por fin una explosión de estos servicios.

Fotografía de engadget.com

Ayer Olle Johansson y Saúl Ibarra ya lo comentaron: Estos términos dejan claro que la VoIP es el método ideal para el futuro de las comunicaciones y de hecho se muestran bastante orgullosos de mostrarlo así: SIP, STUN, ICE, TURN, RTP, SRTP y códecs AAC y H.264.

Que el iPhone4 incorpore de serie un cliente SIP (de hecho la novedosa aplicación FaceTime no es más que un video-softphone SIP con vídeo). No obstante las ilusiones se caen cuando leemos que esta aplicación no tendrá apenas configuración, por lo que toda videollamada seguramente se haga mediante los propios servidores de Apple como un servicio propio. ¿Estamos ante lo que podría llamarse la “Introducción de la VoIP de Apple“? Recordamos que hace unos meses ya vimos que Apple tenía la intención de comprar una empresa dedicada a la VoIP.

La videoconferencia del iPhone4 de momento únicamente podrá realizarse mediante Wifi pero hay intenciones de que pueda llegar a utilizar 3G o HDSPA para realizar estas videoconferencias en un futuro próximo.

A continuación podéis ver un ejemplo de la videoconferencia del iPhone4:

Visto lo visto… me ha gustado que Apple lance este tipo de servicios, porque deja la puerta abierta a sus directos competidores Google y BlackBerry para que se pongan manos a la obra en igualar y mejorar este tipo de servicios en sus móviles.

¿Cómo será la tecnología móvil dentro de 10 años viendo la velocidad con la que ha avanzado en los últimos 3 años?

De momento parece que la idea ha surgido del estado de Nueva York, aunque tal y como está la economía no me extrañaría lo más mínimo que esta idea pudiera aplicarse a otros estados e incluso a otros países.

Resulta que en los callcenters se suele utilizar una técnica muy común gracias a la VoIP: El usuario llama a un número local, y mediante VoIP, dicha llamada es transferida a un callcenter situado en otros países donde la mano de obra es más económica.

Pues el Estado de Nueva York está preparando el terreno para que, cada llamada contestada en otro estado o país diferente al usuario, el responsable del callcenter pague una tasa de 25 céntimos por llamada.

Considerando que el servicio de atención al usuario de cualquier operador de telecomunicaciones suele rondar las 200.000 llamadas diarias por callcenter, eso daría un beneficio bastante jugoso para cualquier gobierno, y la solución para evitar pagar dicha tasa sería contratar a personas en el mismo país para atender a dichas llamadas, lo que fomentaría el empleo local y la satisfacción de los clientes.

Más información:
http://blog.connectedplanetonline.com/

Como “novato” en el mundo de la radio, me ha ido sorprendiendo gratamente el valor y las posibilidades de la combinación de ambos elementos. Así mismo, me ha sorprendido el interés tan alto que hay en la comunidad de radioaficionados sobre las posibilidades de Asterisk, y las increibles sinergias que pueden emplearse utilizando ambos términos.

Si a esto unimos, como pretende la red HSMMN, un sistema troncal, compuesto por varios Asterisk, podriamos conseguir que un radioaficionado de Madrid pudiera estar hablando con un radioaficionado de una recondita zona rural en el otro lado del globo, y como no, unir diferentes redes de radioaficionados. De hecho, la red HSMMN está consiguiendo expandirse muy rapidamente, y en los últimos días estan empezando a llegar voluntarios de varios países para unirse a la misma. Como ejemplo, podemos mencionar que a los nodos españoles, se le ha juntado recientemente uno en Colombia, y se está avanzando ya en los primeros acuerdos en Chile para establecer ahí uno nodo de acceso la a la red.

Sin embargo, el interés del sistema no acaba ahí. Es más, en mi caso, mi interés sobre este mundo subió de forma exponencial cuando hace pocos días, y gracias a la ayuda de Alex, realizamos una prueba en vivo de unos de estos sistemas en nuestras oficinas, con una prueba de concepto en la cual, un sistema de Asterisk podía escuchar y interactuar con una emisora de radio, descubriendo que solo estabamos ante la punta del iceberg. Las posibilidades y puertas que se nos abren son innumerables, y sobre todo para los sistemas de protección civil.

Imaginemosnos una localidad, con sus Bomberos, Policia Local, y equipos de emergencia. Las radios son un mecanismo que de por si, son insustituibles… su cobertura y agilidad los hace ideales para poder moverse en cualquier situación, desde pasajes reconditos, edificios o sotanos sin cobertura, zonas rurales….. ademas son mucho más comodos, prácticos y habituales entre diferentes operativos, estan permanentemente abiertos (modo broadcast o inidvidual), y no tienen coste de llamada. Sin embargo, a pesar de esa gran ventaja que tienen sobre los teléfonos móviles, muchas veces son sistemas autónomos, en los que incluso determinados miembros de un equipo de emergencia utilizan diferentes sistemas de otros equipos, y es dificil hacer una actuación coordinada entre ellos ante una gran catástrofe… (uno de los ejemplos mas claros fue el 11-S, cuando se vio que no habia comunicación ni coordinación alguna entre las diferentes unidades operativas desplegadas).

Ademas, imaginemosnos que un coordinador de un sistema de emergencia, o una autoridad relevante, no tengan a mano una radio, sino que se encuentren desplazados (o simplemente de vacaciones) en un lugar remoto, donde eso si, tienen su teléfono movil a mano, pero no su emisora de radio (y mucho menos cobertura de radio desde ahi).  Los primeros instantes perdidos en cualquier situación de emergencia son críticos y es inadmisible que con los métodos actuales sean debidos a un problema de comunicación.

Asterisk puede darnos ahí gran valor. Simplemente utilizando sus posibilidades de integracion con radio, podemos utilizarlo como “switch” entre diferentes sistemas de radio, y incluso, abrir un canal que mediante un IVR, permita a un usuario autorizado (previamente identificado por el sistema), llamar con un teléfono tradicional y participar en las labores de emergencia, conectándose a los sistemas de radio. Gracias a Asterisk y al módulo app_rpt, podemos conseguir cosas que hasta ahora solo eran posibiles con caras pasarelas a través de E1, más limitadas, cerradas y desde luego, con precios muy superiores.

Estas ventajas han despertado el interés de la OIDETAM (Organización Internacion de Emergencias Terrestres Aereas y Maritimas), que ya ha mostrado su interés por hacer uso del proyecto HSMMN para sus operaciones.

Pero las ventajas no terminan en un “switch-multiplexador-gateway económico”, sino que son inimaginables… Hoy en día, por ejemplo, la grabación de llamadas es algo imprescindible en cualquier servicio de emergencia. Sin embargo, es raro encontrar una buena implementación, y suelen ser servicios duplicados. Por un lado, se graban las llamadas a la centralita telefonica que recoge el aviso o petición de auxilio, y por otro lado, se pone un sistema, habitualmente muy caro, para grabar las llamadas realizadas por radio. Todo eso podría simplificarte y abaratarse enormemente, usando un único Asterisk como centralita, que hiciera las labores de grabar ambos sistemas simultaneamente. Incluso aún en el caso de que por cualquier ciscunstancia mi centralita actual no fuera una asterisk (digamos que mi empresa aún esté “amortizando” su vieja centralita, o que tenga un sistema propietario como PBX), podría merecer la pena poner una nueva centralita asterisk de cabecera que hiciera de puente entre ambos sistemas.

Dándole una vuelta de tuerca mas, podriamos combinar radio con IVR avanzados, de forma que un oficial de policia, por ejemplo, podria usar su radio y teclear en el una matrícula, o un DNI, y que un sistema automatizado devolviera datos usando un ASR sobre la matrícula en cuestión. Recordemos que algunos terminales de radio (como los TETRA), además de encriptar las comunicaciones radiofónicas, tienen teclados numéricos, por lo que podrían incluso interacturar con dicho asterisk, solicitar una transferencia, datos, y todo lo que se puede hacer con un terminal telefónico. Seguro que a vosotros se os ocurren tambien un montón más de utilidades…¿no?

Para compartir esas ideas, nuestro compañero Alex suele dar conferencias, de forma habitual, por toda la geografía española, hablando de estas posibilidades, y de como participar en estos proyectos. Este próximo lunes, en valencia, ofrecerá una de ellas, de la que podeis obtener más información tanto en la página web del proyecto como estar informados sobre la misma a través del enlace público en facebook. 

A los que podaís, os recomiendo acercaros físicamente a dicho evento, estoy seguro que será muy interesante.

Creo que la inmensa mayoría de los lectores de Sinologic ya conocen el evento anual conocido como VoIP2DAY y que recoge a las principales empresas de VoIP del país y algunas empresas internacionales de importancia para mostrar las últimas novedades, productos y donde se invitan a conferenciantes para exponer algunos temas que puedan ser del interés de los visitantes.

Pues como novedad para este año, el VoIP2DAY se empezará a celebrar también en Portugal el próximo día 21 de Junio en el Museo das Comunicaçoes de Lisboa donde se darán cita empresas de Portugal y España dedicadas a la VoIP, charlas y como guinda de todo esto, Olle Johansson (gran amigo y gurú de Asterisk) ofrecerá un curso de 4 horas de duración sobre cómo configurar Asterisk correctamente y prestando especial cuidado a la seguridad, (nadie mejor que Olle Johansson para mostrarnos los trucos que nadie conoce respecto a seguridad) algo que cualquier administrador de sistemas debería saber y lamentablemente muy pocos conocen.

La entrada al VoIP2DAY es, como siempre, gratuita aunque hay que registrarse previamente para poder acceder al recinto.

Más información:
http://www.voip2day.net/2010pt/pt

Este softphone es completamente gratuito y soporta muchas más características y ventajas que muchos softphones comerciales actuales y que podéis ver a continuación:

• HD Audio (G722/Speex)
• PSTN Compatible (G711)
• Encryption (sRTP)
• NAT Traversal (ICE)
• Multi-Party Conferencing
• Chat Sessions (MSRP)
• SMS (SIP MESSAGE)
• Encryption (TLS)
• Rich-Text, Emoticons
• Composing Indication
• Presence Agent
• XCAP Storage
• Rich Presence
• Device Capabilities
• RLS Services
• Exchange Files (MSRP)
• Encryption (TLS)
• Drag and Drop Photos
• Works behind NAT
• Retry Transfers
• Help Family Remotely
• Collaboration at Work
• Surf Internet Together
• Integrated with Audio
• Works behind NAT

Con estas características y tras haberlo probado en varias ocasiones puedo asegurar que es de lo mejor que uno se puede encontrar en este sentido.

La única característica en contra de este softphone, es que únicamente es compatible con Mac, de momento, y es que la gente de AG-Projects han anunciado que muy pronto estará disponible esta fantástica aplicación para Windows y para Linux.

Por lo que ahora tan solo nos queda estar bien pendientes esperar que sea pronto.

La versión para Mac podéis descargarla de su web:
http://icanblink.com

Esta versión ha sido muy esperada por sus usuarios desde que se anunciara la nueva SDK y que se hiciera oficial la posibilidad de realizar llamadas por 3G.

Ya era posible a través de ciertas aplicaciones y en iPhones jailbrokeados hacer llamadas por VoIP a través de la red 3G, pero no para el público general.

No obstante, dicha actualización del softphone de Skype permite realizar llamadas 3G a otros softphones Skype, aunque esta característica será gratuita hasta finales del 2010 y habrá que pagar una cantidad aún no anunciada para poder utilizarlo.

Seguro que habrá muchos usuarios que el hecho de que no sea “gratis” no les habrá hecho mucha gracia, pero para ellos existen otras aplicaciones para el iPhone que sí son gratuitas y que ya podían utilizarlo desde hace tiempo.

Para descargarlo manualmente pulsa en el siguiente enlace:
http://itunes.apple.com/app/skype/id304878510?mt=8

Entre las correcciones a diversos bugs que hemos padecido (por suerte, bastante retorcidos), quizás lo más interesante es sin duda el completo soporte para tarjetas RDSI Básicas en modo NT y Punto-Multi-Punto, así como una solución para evitar que el operador nos descargue la capa 2 de la RDSI para ahorrar energía, así que por fín parece que tendremos el soporte RDSI que tanto tiempo hemos esperado.

También se solucionan bastantes bugs conocidos y otros nuevos pero muy, muy interesantes.

Hora de actualizar, y recordad que tras actualizar LibPRI, hay que recompilar Asterisk.

Podeis descargarlo de aquí:
http://downloads.asterisk.org/pub/telephony/libpri/

A traves de Manwe veo un fantástico tutorial paso a paso sobre cómo integrar Asterisk 1.6.2 con Kamailio 3.0 escrito por Daniel Constantin Mierla en la que nos explica cómo configurar Kamailio para registrar y gestionar las llamadas entre usuarios SIP mientras que reenvía ciertas peticiones SIP a Asterisk (para acceder a la red telefónica, por ejemplo).

El tutorial está hecho realmente para torpes y es que siguiendo los pasos cualquiera puede instalar su propio OpenSER como servidor de registro y conectarlo a Asterisk para utilizarlo como gateway o servidor de aplicaciones de voz, aunque lo verdaderamente interesante es que seguro que esto hará que muchos que ya conocéis Asterisk y queréis aprender cómo funciona una aplicación como  Kamailio servirá como punto de partida para algo práctico para continuar aprendiendo.

Seguramente, muchos lectores estarán deseando poner en práctica este tutorial, aunque debemos recordar que, de poco sirve hacer copy+paste de los comandos y de la configuración si no se entiende lo que se está haciendo y aunque parezca sencillo, realmente lo es, tan sólo hay que dedicarle su tiempo para leer la documentación y entender qué hace y porqué.

Daniel-Constantin, que estará el próximo mes de Julio en España junto con Olle Johansson para el SIP MasterClass, por si alguien quiere aprovechar para ver cómo mejorar esta estructura y aprender mucho más sobre Kamailio, SIPRouter y Asterisk.

El tutorial lo podéis encontrar en el wiki de Asipto:
http://kb.asipto.com/asterisk:realtime:kamailio-3.0.x-asterisk-1.6.2-astdb

Después de unos meses en los que Europa, todos los administradores de VoIP, así como los fabricantes europeos y asiáticos de productos de VoIP se pongan al día y solucionen algunos que otros problemas de seguridad, los administradores de sistemas VoIP adopten medidas seguras para la detección y bloqueo de posibles ataques, el FBI informa ahora que están empezando a recibir ataques a sistemas de VoIP de EEUU.

El modus operandi de los ataques anunciados por el FBI son exactamente los mismos registrados en Europa y están provocando cientos de miles de dólares en pérdidas por cada sistema atacado con éxito, lo que ha obligado al FBI a redactar una nota de prensa para advertir a todos los usuarios que vigilen sus sistemas y mejoren las medidas de protección ante descuidos como cuentas VoIP sin contraseñas o con contraseñas triviales ya que los atacantes utilizan el sistema de fuerza bruta para acceder a estas cuentas y poder realizar cientos de llamadas a la hora.

Ya hemos hablado bastante sobre este tema, dados multitud de consejos y trucos sobre seguridad, e incluso hemos desarrollado algunas herramientas como un tester básico de llamadas sin autentificación y un sistema de vigilancia contra ataques por fuerza bruta. Otros compañeros están desarrollando sistemas Honeywall para atrapar a los atacantes, limitando el número de llamadas internacionales, disponiendo de diversas formas de seguridad tanto activas como pasivas, pero como siempre se dice en estos casos, aunque la paranoia nunca es buena consejera, siempre es mejor prevenir que curar.

A veces uno siente cierta “envidia” sobre porqué un organismo com el FBI informa de este tipo de ataques y en cambio, las fuerzas de seguridad europeas no han dicho nada.

La nota de prensa del FBI:
http://newark.fbi.gov/pressrel/pressrel10/nk051110.htm

Estas dos semanas han sido bastante movidas en cuanto a algunas piezas clave de la VoIP como son los códecs, las patentes, permisos y licencias de manera que están surgiendo cambios que pueden hacer cambiar bastante el panorama actual tanto para bien como para mal.

Hace unas semanas, toda la blogosfera se hizo eco de la guerra abierta entre Apple y Adobe por el soporte de Flash en los productos de Mac. El CEO de Apple (Steve Jobs) dirigió duras críticas sobre el formato de Adobe y el porqué no pensaba incluir este formato dentro de sus productos portátiles. De esta forma, defendía el uso de los estándares y el uso del códec H.264 para poder ver vídeos.

Por otro lado, Google fue más allá y no sólo defendió el uso de estándares si no que le puso nombre: HTML5 y Theora, un formato que es, de hecho, la alternativa libre al códec H.264 que estuvo muy cerca de ser completamente libre pero que al final, se ve que no pudo ser.

Apple y Microsoft defienden el códec H.264 como la próxima evolución del vídeo en internet, siempre y cuando aquella empresa que quiera implementar algún software con este códec pase por caja.

Antes que alguien lo pregunte, en Europa (donde no existen patentes software) sí que existen patentes por códecs ya que lo que se patenta no es el algoritmo, si no un “método matemático de compresión” y esta sí es patentable.

Asterisk se encuentra ahora con un dilema que deberá resolver, seguir utilizando H.264 como códec a utilizar en vídeo (desconozco si sería legal utilizarlo a la vista que no es libre), o bien saltar a otros códecs más libres como Theora.

Google acaba de anunciar la liberación de otro códec de vídeo llamado VP8 cuyo contenedor está basado en Matroska -Gracias Manwe- (los famosos archivos de vídeo con extensión ‘mkv‘) además de organizar una plataforma pro-estándares-libres para la web llamada WebM que seguro que dará que hablar los próximos días.

Para colmo, la noticia saltó hace unos días cuando Google anunció que ofrecía varios millones de dólares para poder comprar la famosa empresa Global IP Sound de la que ya hemos hablado en varias ocasiones y que se dedica a la creación de códecs de audio como los que hizo famoso a Skype y que utiliza actualmente GoogleTalk. La compra de GIPS por parte de Google junto con todos los servicios que rodean la VoIP del gigante (GoogleVoice, GoogleTalk, GoogleWave, …) podrían ser los movimientos que le faltan para empezar a comer piezas y quedarse con el tablero.

Como pensamiento en voz alta, tras ver todos estos movimientos, y siguiendo con la analogía de la partida de ajedrez, intento imaginar cual podría ser el último movimiento antes del final del ‘medio juego‘ y que todo esté potencialmente decidido: Google sólo le haría falta adquirir una empresa muy conocida, y que últimamente está dando pequeños pasos a favor del software libre, que empieza por S y termina por kype y, con esta empresa y con su antigua competencia (Gizmo5) bajo su techo, tiene toda las papeletas de ser el gran gigante de la VoIP mundial para el gran público. ¿o no?

Escenario:

• 1 Equipo de 4 tramas Redfone 750-5000
• Servidor asterisk basado en Centos 5.5
• Switch Estándar 10/100/1000
• 2 Cables cruzados de trama RJ 45 (pinout)

La idea para mostrar todos los escenarios es cruzar las tramas de port 1 al port 2 y del 3 al 4 del redfone de esta forma: PORT 1 y 2 Trama E1 MFC/R2 (variante argentina), PORT 3 y 4 ISDN PRI variante EuroISDN (cpe y net)…

Pasos a seguir:

1) Asterisk ya debe estar instalado y con soporte de Libopenr2 para nuestra MFC/r2 (ver www.libopenr2.org )… este caso asterisk 1.6.2.7 por ser la única con soporte R2 nativo…

2) Dahdi 2.3.0 instalado y compilado correctamente ya que es el que trae por default el soporte TDMoE Multiframe de los redfones.

3) En centos 5.5 sobre consola de root en el directorio de /usr/src/ en lo posible debemos bajar e instalar los 2 utilitarios de redfone para administrar los equipos:

# wget http://support.red-fone.com/downloads/fb_flash/fb_flash-2.0.0-19.i386.rpm
# rpm -ivh fb_flash-2.0.0-19.i386.rpm

y….

# wget http://support.red-fone.com/downloads/fonulator/fonulator-2.0.1-1.i386.rpm
# rpm -ivh fonulator-2.0.1-1.i386.rpm

Con esto ya estaríamos listos para comenzar a probar los equipos…el Redfone por defecto trae en sus 2  interfaces de red las direcciones 192.168.0.254 y 253 asi que por simplificación nuestro asterisk estará en la 192.168.0.250 conectado al switch y la interfaz FB-0 del redfone estará conectada tambien al switch…Conectamos los 2 cables E1 CrossOver en el Port 1 contra el 2 y 3 contra el 4…

Ahora vamos a configurar nuestro 1er. archvo el /etc/redfone.conf que tendrá la info de conexión a nuestro equipo…en este caso usamos el port 1 con IP 192.168.1.254 que se conectará a nuestro server en la tarjeta de red con mac 08:00:27:3D:27:80 que tiene la ip 250 y usando R2 CAS en los ports 1 y 2, y CCS ISDN en los 3 y 4…

IMPORTANTE: Nótese que 1 sólo reloj es usado como master ya que todas las tramas y el equipo asterisk en general usarán ese source de clock para sincronización…

[globals]
fb=192.168.1.254
port=1
server=08:00:27:3D:27:80

[span1]
framing=cas
encoding=hdb3
crc4
slave

[span2]
framing=cas
encoding=hdb3
crc4
slave

[span3]
framing=ccs
encoding=hdb3
crc4
slave

[span4]
framing=ccs
encoding=hdb3
crc4
master

Luego de guardar este archivo ejecutamos el siguiente comando….

[root@elastix ~]# fonulator -v
Detecting foneBRIDGE
Found a foneBRIDGE with 4 spans on 1 transceivers.
DSP Status: Available
Stopping foneBRIDGE TDMoE transmission
Detecting current foneBRIDGE link configuration
Stopping foneBRIDGE TDMoE transmission
WPLL Enabled
Starting foneBRIDGE TDMoE transmission
foneBRIDGE reconfigured!

Ahora podriamos grabar la config recién cargada en el redfone con el comando …

[root@elastix ~]# fonulator –write-config

y listo redfone configurado las 4 luces de estado de las tramas del equipo deberían estar ya en verde…ahora viene el dahdi….

Vamos a /etc/dahdi/system.conf y tendriamos que configurar algo asi…donde la mac address que cargamos en cada dynamic span es la mac del redfone que estaríamos usando…en este caso mi FB-0 del redfone seria 00:50:C2:65:D4:02…

loadzone=ar  # notar que uso variante ar de tonos porque lógicamente estoy en Argentina
defaultzone=ar
dynamic=ethmf,eth0/00:50:C2:65:D4:02/0,31,0 # eth0 de mi pc, trama 0 31 canales origen reloj 0 (esclavo)
cas=1-15:1101       # uso  cas y bits a 1101 blocked por ser trama r2
cas=17-31:1101
alaw=1-15
alaw=17-31
dchan=16
dynamic=ethmf,eth0/00:50:C2:65:D4:02/1,31,0 # eth0 de mi pc, trama 1 31 canales origen reloj 0 (esclavo)
cas=32-46:1101       # idem trama 1
cas=48-62:1101
alaw=32-46
alaw=48-62
dchan=47
dynamic=ethmf,eth0/00:50:C2:65:D4:02/2,31,0 # eth0 de mi pc, trama 2 31 canales origen reloj 0 (esclavo)
bchan=63-77    # ahora voy a usar nomenclatura standard de E1 isdn primario
dchan=78
bchan=79-93
dynamic=ethmf,eth0/00:50:C2:65:D4:02/3,31,1 # eth0 de mi pc, trama 3 31 canales origen reloj 1 (maestro)
bchan=94-108       # idem trama 2 ISDN primario
dchan=109
bchan=110-124

Y listo 2 tramas en R2 y 2 en ISDN y 1 solo origen de sincro de reloj MASTER y dahdi ya configurado…

Corremos ahora el arranque del servicio de dahdi

# service dahdi start

y luego…

# dahdi_tool

Si todo salió bien deberiamos ver los 4 Spans dínámicos y sus status en OK en los 4…

Por último configuramos asterisk con el /etc/asterisk/chan_dahdi.conf

[channels]
context=default
usecallerid=yes
callerid=asreceived
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
busydetect=yes
busycount=6

; trama R2 número 1 variante ar

context=from-pstn
group=0
echocancel=yes
signalling=mfcr2
mfcr2_variant=ar
mfcr2_get_ani_first=no
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_mfback_timeout=-1
mfcr2_metering_pulse_timeout=-1
channel =>1-15,17-31

; trama R2 número 2 variante ar

context=from-pstn
group=1
echocancel=yes
signalling=mfcr2
mfcr2_variant=ar
mfcr2_get_ani_first=no
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_mfback_timeout=-1
mfcr2_metering_pulse_timeout=-1
channel =>32-46,48-62

; trama ISDN número 1 en modo cliente

context=from-pstn
group=2
echocancel=yes
signalling=pri_cpe
switchtype=euroisdn
channel =>63-77,79-93

; trama ISDN número 2 en modo network

context=from-pstn
group=3
echocancel=yes
signalling=pri_net
switchtype=euroisdn
channel =>94-108,110-124

Y ahora si terminamos…ejecutamos el servicio de asterisk y deberiamos ver las 4 tramas arriba….

# service asterisk start
# asterisk -rvvv
CLI> mfcr2 show channels
CLI> pri show spans

Espero les sirva de ayuda…ya que estos equipos son una maravilla por su simplicidad, estabilidad y precio…

La verdad es que estos dispositivos suponen un gran ahorro en muchos casos sobre todo ahora con todas estas tarifas planas a moviles que ofertan las distintas compaías telefónicas.

Por lo que  claramente es algo que añadir a nuestro Asterisk y la forma en que lo hagamos dependerá de si nuestro trac  es analógico o rdsi, aunque en Sinologic ya estuvimos dando un repaso a distintos tipos de gateways, en esta ocasión nos vamos a centrar en párametros necesarios para que su funcionamiento sea correcto.

Nosotros en este artículo nos vamos a centrar en los Analógicos y es que en general son los que mayores problemas dan.

Claramente para conectar nuestro TRAC (Telefonía Rural por Acceso Celular) a Asterisk vamos a necesitar una tarjeta con un modulo FXO libre o bien un Gateway de FXO y conectarlo a nuestro dispositivo.

La configuración es muy sencilla, como una linea normal y corriente, pero en este caso habrá una serie de parámetros que tendremos que tener en cuenta.

La linea móvil, la parte GSM, no tiene inversión de polaridad, lo que siginifica que no habrá cambio de voltaje cuando la persona cuelgue, que es la forma tradicional en la que detecatamos cuando una llamada ha terminado, en este caso tendremos que quedarnos escuchando la linea y cuando Asterisk detecte los tonos de comunicnado es cuando debe proceder a realizar el cuelgue de la linea.

Por lo que para hacer la integración no vale solamente con el track y el fxo y que así se resuelva la integración tendremos que configurar correctamente los tonos y el modo del cuelgue de las llamadas.

Lo primero que tendremos que revisar si lo estamos haciendo ocn una tarjeta de FXO es que en el system.conf tenemos configurada loadzone=es y defaultzone=es, estos parámetros lo que hacen es cargar los tonos españoles justo lo que queremos, claramente esto depende de dónde sea el proveedor de nuestra linea. Si estamos en Portugal en este caso pondremos loadzone=pt.

Si no sabemos exactamente cuales son las siglas de nuestra zona, dentro de /etc/asterisk existe un fichero llamado indications.conf y podremos buscar nuestra zona junto con sus siglas correspondientes.

Lo siguiente que tendremos que configurar como siempre es el chan_dahdi.conf para decirle que se quede escuchando la linea y que proceda al cuelgue cuando haya detectado los tonos de ocupado.

Para ello existen 2 parámetros que tenemos que cambiar:

busydetect=yes

busycount=4

Como podeis inferir el primero de ellos será el que se quede esperando a que se produzcan los tonos de ocupado y el segundo el numero de tonos que va a esperar antes de hacer el release de la llamada.

Aunque en este caso estamos hablando de lineas GSM, claramente esta sería la misma configuración para toda linea analógica que no posea inversión de polaridad.

Una recomendación es no poner el busycount excesivamente bajo, por ejemplo 1 o 2 ya que si se detectase un falso tono de busy, por algun ruido de la linea procedería al corte de la llamada, por lo que tipicamente se suelen utilizar números como 4 o 5 para que el corte sólo se produzca cuando estamos seguros de que la llamada ya ha finalizado.

En el caso en que tuviesemos un gateway FXO lo que tendremos que configurar es exactamente lo mismo, por un lado los tonos o parametros regionales, estos deben ser los tonos de la zona en la que nos encontremos.  Cada fabricante tiene una forma diferente de especificar los tonos, por lo que este paso depende del dispositivo del que hablemos.

Tras esto, desactivaremos la inversión de polaridad, ya que no la tenemos, al hacerlo autmaticamente el gateway proederá a realizar el cuelgue mediante los tonos, en la mayoria de los casos.

Y con esto ya tenemos nuestro Asterisk preparado para trabajar con lineas de móviles.

Por último comentaros que mucho de los tracs que  ofrecen las comapañías de teleféfonos pueden configurarse para que sean ellos los que detecten que se ha producido el cuelgue de la llamada en la parte gsm y generen un cambio de polaridad en la linea analógica. Aunque por defecto viene deshabilitado, si nuestro trac lo permite es la mejor forma de configurarlo y evitar de esta forma toda esta configuración que en ciertos gateways es algo rebuscada.

Por lo general, esto no es en absoluto erróneo, entra dentro de la filosofía de la VoIP que podamos admitir llamadas anónimas desde otros sistemas para poder ponerlas en contacto con usuarios que tengamos registrados en nuestro Asterisk, pero conociendo la cantidad de usuarios que permiten esto (apenas un 5%), el resto se podría considerar que utilizan un interfaz web como FreePBX que configura por defecto el famoso parámetro ‘allowguest=yes’ en lugar de rechazarlo.

Asterisk 1.4 y 1.6 también configuran por defecto este parámetro, pero por supuesto es responsabilidad de cada uno conocer el significado de estos parámetros y actuar en consecuencia.

Durante una charla/debate/brainstorming que tuvimos en el último curso de Asterisk Advanced en Bilbao, aparecieron algunas ideas bastante interesantes y que nos gustaría compartir desde aquí:

• Utilizar la aplicación ‘Authenticate’ con un código PIN conocidos por todos los usuarios y que se ejecute antes de hacer una llamada internacional:

Por ejemplo, algo como esto:

exten => _00X.,1,NoOp(Calling International number: ${EXTEN})
exten => _00X.,n,Authenticate(0173)
exten => _00X.,n,Dial(SIP/${EXTEN}@InterProvider)

Esto ya haría que el usuario llamante que envía dicha llamada, necesite conocer nuestro código de autentificación (0173) para poder realizar dicha llamada. Este código deberán conocerlo todos los usuarios y, aunque retrase un poco el establecimiento de la llamada por tener que marcar 4 números más, seguro que el hecho ampliar dicha seguridad es algo que merece la pena hacer.

• Evitar el acceso externo del 5060 mediante el propio firewall de Linux:

Este, sin duda es el que menos me gusta, ya que es muy interesante poder recibir llamadas a nuestros usuarios sin necesidad de tener que llamarles vía red telefónica.
Es decir, si yo desde mi softphone llamo a: SIP:jackoman@asterisk.jackoman.com suene correctamente la extensión de mi amigo sin tener que llamarlo al móvil o a su número fijo.
No obstante, si cierro el puerto 5060/UDP vía firewall, jamás podría hacerlo algo que rompería con toda la filosofía de lo que es la VoIP y una de sus principales ventajas.

• Una configuración adecuada del dialplan:

Generalmente este es el principal error, las llamadas entrantes sin autentificar en el SIP.conf son dirigidas al contexto ‘default’ del extensions.conf.
Si el extensions.conf NO lo hemos configurado como nos han enseñado, podríamos llegar a tener algo como esto:

[default]
exten=>s,1,NoOp(Llamadas desde el exterior)
exten=>s,n,Dial(SIP/100,20)
exten=>s,n,VoiceMail(100,u)

include=>salientes ;; <<<< MUY MAL! Añadimos el contexto ‘salientes’ dentro del ‘default’
…

[salientes]
exten=>_1XX,1,Dial(SIP/${EXTEN})
exten=>_9X.,1,Dial(DAHDI/g1/${EXTEN})
exten=>_00X.,1,Dial(SIP/${EXTEN})    ;; <<<<< Esto es lo que hará que puedan hacer llamadas desde fuera.

De esta manera, nuestro sistema estará completamente configurado para que cualquier persona pueda llamar a costa nuestra a donde quiera.

Ante esto, un consejo… NUNCA utilizar ‘includes’ si no sabemos exactamente qué estamos haciendo.

Existen muchas otras soluciones para hacer que nuestra seguridad se refuerce un poco, aunque existe un problema mayor:

Los usuarios maliciosos incluso se autentifican y registran en nuestro sistema para hacerse pasar por una extensión con permisos y poder hacer llamadas como un usuarios normal y corriente.

Ante esto ¿qué podemos hacer?. Pues está claro que lo primero es mejorar la seguridad básica:

• La típica extensión 100 con contraseña 100, es tan vulnerable como no poner ninguna contraseña, por lo que debemos cambiarla a algo más robusto: algo como eLnsAaLiyÑ100.  (la ñ y la ç son letras muy útiles para las claves)
• Cuando estos usuarios intentan registrarse desde nuestras propias cuentas, utilizan un sistema de ‘fuerza bruta‘ para buscar las contraseñas, así que de poco nos servirá algo como esto: Usuario 100, contraseña 100100, ya que tan solo van a necesitar un par de horas de intentos para conseguir registrarse y empezar a hacer llamadas.
• Evitar a toda costa eso que hacen los interfaces de configurar todas las extensiones como nat=yes, este parámetro sólo debe estar para aquellas extensiones que realmente se encuentren detrás de NAT que realmente son las más vulnerables.

No obstante, durante el curso de Asterisk Advanced aparecieron varias ideas más entre las que había una que no me disgustó:

• Comprobar en el log del Asterisk los intentos fallidos de autenticación y en el caso de varios intentos, añadir de forma automática en el IPTables la dirección IP de nuestro ‘supuesto’ atacante.

Lo de ‘de forma automática‘ es imprescindible, ya que los ataques suelen producirse cuando nuestro sistema es más vulnerable: los fines de semana, de forma que no les prestemos atención a los logs hasta que el administrador de sistemas vuelva el lunes, de esta forma los atacantes tienen varios días para su ataque por fuerza bruta.Así que,  analizando el log y documentándonos un poco vimos que Asterisk loguea los intentos fallidos de registro SIP como mensajes de tipo NOTICE (algo que viene por defecto en el logger.conf y que nos permite monitorizar quien se ha intentado registrar casi siempre).

A la vista de esta última idea, desarrollamos  un script que, añadido al crontab, analizaba el archivo ‘messages’ del Asterisk en busca de intentos fallidos y cuando este número superase una cantidad considerable, el script añadiría dicha IP en el IPtables para que el sistema le prohibiese acceder al puerto 5060/UDP.

El script lo podéis encontrar aquí y para activarlo, tan sólo tenéis que copiarlo al directorio /usr/local/bin y llamarlo cada cierto tiempo en el crontab editando el archivo /etc/crontab y añadiendo una línea como esta:

00 *     * * *    root   /usr/local/bin/sipcheck.pl messages

De esta forma, evitaremos que un atacante pueda conocer la contraseña de nuestras extensiones que están detrás de nat y pueda hacer llamadas internacionales a través nuestra.

Por defecto, el número de intentos fallidos antes de ser añadido automáticamente al IPTables es de 200, suficientes para detectar un ataque por fuerza bruta sin que añada extensiones que han fallado por escribir mal la contraseña. Este número se puede cambiar dentro del código.

Las direcciones IP atacantes se añaden al firewall ya existente, permitiendo “limpiar” estas direcciones con el parámetro ‘clear‘ sin que afecte al resto de la configuración del IPTables.

Por supuesto, se le pueden hacer muchas mejoras, pero de momento, esta primera versión servirá para aquellos que quieran asegurar su sistema un poco más.

Si te gusta el script y lo quieres mejorar, acuérdate de enviarme los cambios para que pueda servir a otras personas (para eso es GPL).

El script lo podeis descargar de aquí: sipcheck

Únicamente nos falta agradecer a los asistentes al curso de Asterisk Advanced Bilbao 2010 por ese BrainStorming antes de quedar para cenar que fomentó hacer el script que ha conseguido que en algunos sistemas conocidos donde instalé este script para pruebas, ya haya capturado varias direcciones IP. ;D

Leif Madsen

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.

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:

Submitted by asteriskteam on Wed, 03/31/2010 – 14:02

iChat de la versión de MacosX Tiger

Leo en Engadget que Skype planea publicar una nueva versión donde uno de los mayores atractivos es justamente el de poder hacer videoconferencia con hasta 5 personas simultaneamente.
Ya me llamó la atención poder hacer una videoconferencia con varias personas a través del cliente de mensajería que trae Apple MacOSX: iChat, que, para el que no lo sepa, funciona con un SIP bastante modificado y unos servidores especiales para poder retransmitir de forma fluida varias videoconferencias, así como una presentación o incluso un archivo de vídeo a suficientes frames por segundo como para poder ver una película.

No obstante, aunque con software libre hay algunos productos opensource como los de fontventa o algún otro, pero aún no he conseguido ver una multi-videoconferencia VoIP basada en SIP donde se puedan ver varias personas a la vez de una manera fluida.

Quizá (y sólo quizá) tenga algo que ver el hecho de que para disponer del ancho de banda suficiente para recibir varias transmisiones de vídeo a la vez hace falta comprimir bastante bien el vídeo y para esto, el códec necesario suele estar licenciado con patentes de forma que no es viable crear un software libre que utilice este tipo de códecs.

No obstante, existen alternativas libres como Theora, que ya sea dicho de paso, últimamente está siendo objeto de varios FUDs por parte de grandes empresas que intentan sembrar duda y miedo amenzando a las pequeñas empresas con acciones legales debido a la infracción de derechos de patentes (entra aquí para saber de lo que estamos hablando).

Con todo este jaleo de patentes, de códecs, y si realmente tiene éxito el tema de la multi-videoconferencia entre los usuarios, quizá sea hora de prestarle más atención a estos avances de forma que pueda lograrse desarrollar algo basado en estándares abiertos y que permita a varias personas tener una reunión sin necesidad de desplazarse físicamente.

Skype está realizando movimientos bastante inteligentes, primero atrayendo a empresas a utilizar sus servicios (mediante el Skype4Asterisk y luego mediante el SkypeToSIP) y ahora ofreciendo servicios bastante exclusivos como este.
Para completar el tema, Skype anuncia que la semana que viene publicará nuevos planes de llamadas para 170 países con tarifas bastante competitivas, por lo que parece que espera convertirse, tras este anuncio, en el principal proveedor de VoIP.

Más información, la próxima semana.

Sangoma

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

Casos como la venta de Ericsson, Nortel y cierres de algunas divisiones de Siemens, son algunos de los ejemplos que hemos visto en Sinologic de cómo empresas aferradas a la telefonía tradicional y con un tratamiento “desganado” hacia otras tecnologías como los protocolos abiertos (o el término cada vez más común: Open Communications) han terminado con pérdidas millonarias y posterior venta al mejor postor, lo que en el mejor de los casos se traduce en varios millones de euros en la compra de una ingeniería desfasada y sin nada nuevo que atraer al usuario.

Por suerte, hay casos en los que algunas empresas que continúan aferradas en su modelo de negocio, hacen algunos intentos por lanzar productos basados en protocolos abiertos como SIP intentando comprobar si es cierto que la “VoIP Free” tiene mercado y es entonces cuando nos encontramos productos como terminales SIP compatibles únicamente con la centralita de turno (aunque en su especificación afirman ser compatibles “SIP Compliant” con el RFC3261) el 90% de los servicios asociados al terminal únicamente son válidos si el servidor al que se conectan es de la misma marca.

Otros casos: aparecen terminales SIP puntuales que sí son compatibles con otros sistemas y es entonces cuando aparecen campañas publicitarias, emails de marketing proclamando a los 7 vientos que tal marca disponen “también” de terminales SIP que se pueden utilizar en sistemas como Asterisk o bien OpenSER, intentando formar parte de un mercado ya asentado pero muy competitivo de los fabricantes de dispositivos y terminales IP.
Una de estas empresas es Siemens y  sus terminales SIP DECT de la gama C470 que tienen una buena crítica por los comentarios de algunos usuarios que conozco.

Pues bien, según leo en el blog de Tom Keating, Panasonic es otra de las empresas que se apuntan a la fabricación de terminales DECT basados en el protocolo SIP y para ratificar su buen comportamiento con sistemas abiertos, ha llegado a un acuerdo de homologación con Digium mediante el cual se garantiza que dichos terminales de Panasonic son perfectamente compatibles con Asterisk:

“We are excited to work with Digium and their fast growing base of customers using open source, standards-based business phone systems,” said Kim Murtagh, Director, Panasonic System Networks Company of America. “As the market leader, Panasonic is committed to delivering innovative features and superior performance.”

“The Digium and Panasonic interoperability partnership and certification of IP phones opens new opportunities for Digium channel partners and integrators,” said Digium’s David Hardy, Director of Business Development. “The Panasonic global footprint and commitment to SIP telephony excellence creates exciting sales opportunities for our partner community and for businesses using Asterisk.”

Estos terminales que acaban de anunciarse, se corresponden con la serie TGP500:

KX-TGP500
The system features a wall-mountable base unit and one cordless handset. It is expandable up to 6 DECT 6.0 cordless handsets and supports up to 8 phone numbers and 3 simultaneous calls. It boasts Wide Band Audio (G.722) and 5 hours Talk Time, 10 days Standby. Its elegant design features a white backlit large LCD on the handset and a Handset locator button on the base unit. It also has a handset speakerphone, 2.5mm headset jack and belt clip.

KX-TGP550
The KX-TGP550 has all the features and benefits of the KX-TGP500 and adds a corded base unit with a large white backlit LCD and 5 hours Talk Time, 10 days Standby, plus a Hands-Free Speaker phone, Handset Call Button on the base unit, and one-touch call transfer with Busy Lamp Indication.

KX-TPA50
The TGP500 systems can be expanded up to a total of 6 cordless handsets by adding the KX-TPA50 cordless handset.

Lo más interesante es sin duda el soporte para audio de alta calidad mediante el códec G.722 que se está convirtiendo en todo un valor añadido para cualquier infraestructura que se precie. Lo demás es bastante común con otros terminales DECT del mercado como el de los Snom m3/m9, Siemens C4xx o Aastra.

El mercado no para de moverse y por si alguien aún no se ha enterado, es época de cambios…

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.

Así que, esto va tomando forma ¿o no?

Basado en el artículo de Leif Madsen en Digium

A partir de este lunes el ADSL de Vodafone utilizará exclusivamente VoIP para las llamadas de voz y reservará la red móvil como backup de voz en caso de que falle la línea fija.
Con este cambio Vodafone quiere evitar los problemas que presenta la red GSM al emular el servicio fijo.

• Al realizar una llamada, el destinatario verá una numeración fija. Actualmente, aunque el cliente recibe las llamadas en un número fijo, las llamadas salientes muestran un número de móvil, lo que representa un inconveniente para muchos usuarios.
• Desaparecen los problemas de cobertura en interiores, que por lo visto ha sido uno de los males de cabeza constantes para Vodafone.
• Si se cae la línea fija, las llamadas de voz seguirán funcionando, enrutadas a través de el módem USB conectado al router. Se trata de un backup de voz similar al backup de internet que se activa cuando falla el ADSL.
• Desaparecen las incompatibilidades con faxes, telealarmas, TPV y otros sistemas similares.

Más información: Banda Ancha.eu

Esta versión es quizá más esperada de lo que la mayoría de usuarios creen y aunque las distribuciones enlatadas están empezando a plantearse Asterisk 1.6, es un movimiento complicado ya que en cuanto aparezca Asterisk 1.8 va a traer tantas modificaciones que para el usuario final que no haya trabajado antes con Asterisk 1.6, le va a resultar especialmente complicado adaptarse a esta nueva versión.

No obstante, hemos hecho una recopilación de las principales novedades y las hemos reunido en este artículo para que cualquiera que esté interesado en adentrarse en esta nueva versión y que conozca bien las anteriores versiones, pueda darse cuenta de lo que va a tener que aprender si va a querer aprovechar al máximo las características de esta nueva versión.

Por supuesto, los cambios son principalmente internos a nivel de desarrollo, aunque me ha llamado la atención algunas de las novedades que Kevin P. Flemming anunció que está planteado incluir en Asterisk 1.8 que como mínimo son impresionantes…

Vamos a verlas…

• Soporte para el tan esperado “cifrado del audio” mediante SRTP será añadido finalmente al chan_sip.
• Soporte para PacketCable NCS 1.0 para redes Docsis/Eurodocsis en MGCP del que ya anunciamos el desarrollo.
• Añadidas nuevas opciones para el modulo chan_spy:
  • Añadida opción c() para permitir DTMF para seleccionar el próximo canal disponible a escuchar. Por defecto actualmente es ‘*’.
  • Añadida la opción x() para salir de la aplicación al pulsar una tecla.
  • Añadida la opción S para salir de la aplicación cuando no haya más canales a los que poder escuchar.
  • Añadida la opción E para escuchar un canal y salir de la aplicación cuando este canal finalice.
• La aplicación Meetme dispone de una función DENOISE() que elimina el ruido de fondo y obtiene sonido más límpio.
• Soporte para el nuevo interfaz CEL (Channel Event Logging), se introduce oficialmente aquí. CEL loguea todos los eventos tal y como lo hace el AMI, pero CEL está más orientado a lo que hace el CDR.
• Soporte de integración con calendarios. Nuevas aplicaciones permitirán obtener fechas y ejecutar acciones cuando ocurran eventos programados en el calendario.
• El nuevo motor RTP permitirá Multicast, ideal para cuando trabajamos con altavoces que escuchan este tipo de paquetes y queremos lanzar avisos.
• Para el app_queue, ahora se puede especificar la posición en la que un llamante ingresa en la cola y así poder dar prioridades a ciertas personas que entren en la cola.
• Soporte para actualizar dinámicamente la información de una llamada. Esto permitirá cambiar parámetros como el CallerID durante una llamada, ideal para cuando hacemos una transferencia o un desvío.
• Añadida una nueva característica llamada “call completion” o “informe de llamada” que permite a un usuario informar a otro que está disponible cuando deje de estar ocupado.
• Mejora del soporte de faxes que ya comentamos en este post.
• Soporte nativo para IPV6 (por fín!).

Además de todas las novedades de las últimas versiones de Asterisk 1.6 (que no son pocas).

Aunque quizá lo más interesante de esta nueva versión, es la forma en la que se desarrolla, el esperado LTS (Long Term Support) y que viene a ser que durante varios años se mantendrá y funcionará una única rama: Asterisk 1.8 y las modificaciones y correcciones se harán siempre en la misma rama de forma que tanto los desarrolladores como los usuarios se centrarán en mejorar esta única versión, por lo que se espera que esta versión sea además de la más completa, la más estable de las actuales (incluso más estable que la 1.4) ya que durante el desarrollo de las últimas versiones de la 1.4, muchos desarrolladores empezaron modificar la nueva versión 1.6 y por esto, dejaron de lado a la rama más estable y se centraron en las nuevas características que hay actualmente.

No obstante, RIM acaba de anunciar dos nuevos móviles los BlackBerry Pearl 3G y BlackBerry Bold 9650, además de BlackBerry Mobile Voice System 5, un servicio de voz sobre WiFi para usuarios empresariales que permitirá conectar la BlackBerry mediante VoIP.

Por supuesto, esta novedad es exclusiva para los nuevos dispositivos de manera que muchos ya estarán pensando en actualizar su móvil de empresa para poder hacer uso de esta característica.

No obstante, parece ser que RIM no tiene claro lo que son “usuarios empresariales” ya que en la nota de prensa dejan claro funciona unicamente con Cisco Unified Communications Manager y por otro lado dicen que es “SIP compliant” por lo que no me termina de quedar claro si será o no, compatible con otros sistemas SIP o requerirá forzosamente un Cisco.

El Mobile Voice System 5, permite a los usuarios utilizar un único número entre su línea de teléfono y un smarpthone Blackberry a través de una conexión WiFi. Alguna de las características clave de BlackBerry MVS 5, que estará disponible a finales de año, incluyen filtrado de llamadas, ajustes de preferencia de red o control de acceso a la red WiFi. BlackBerry MVS 5 estará disponible a finales de año.

Leif Madsen

Entre las novedades que destaca Leif, las más interesantes son:

• Utilización de una variable de canal ATTENDED_TRANSFER_COMPLETE_SOUND que, ajustando el valor a una locución, esta será reproducida al destino de la transferencia atendida (quien recibe la llamada). -Función muy parecida a la del ParkAndAnnounce-
• Soporte de monitorización MWI en servidores remotos y estado disponible como buzón de voz (ya no haría falta que nuestro terminal esté registrado en el Asterisk que almacena el mensaje del buzón de voz, podremos ver la indicación aunque se almacene en otro sistema conectado por SIP)
• Soporte completo para los códecs estándar ITU G.722.1 y G.722.1C (Siren7 y Siren14)
• Chan_DAHDI soporta nativamente Open MFC/R2 del que ya hablamos hace algún tiempo.
• Adiós a la dependencia de DAHDI para la obtención de una señal de timming, Asterisk genera la suya propia gracias al módulo res_timing_pthread.
• Añadida nueva aplicación del Dialplan CURLOPT que permite añadir valores para mejorar la funcionalidad de la aplicación CURL como soporte para cookies, proxies, contraseñas, etc.
• Mejora en la depuración de las aplicaciones de ODBC.
• func_odbc soporta transacciones mediante varias querys.
• Añadido nuevo motor llamado ConfBridge que permite realizar conferencias sin depender de DAHDI.
• Simplificación del dialplan mediante el uso de la palabra “same” para referenciar “la misma extensión”:

     exten => 123,1,NoOp(something)
     same =>     n,SomethingElse()

• Con la nueva versión de Asterisk, muchos comandos del CLI han sido modificados, aunque existe un nuevo archivo de configuración llamado cli_aliases.conf que nos permitirá configurar la “compatibilidad” del CLI con la versión que queramos, y poder hacer el paso de una versión a otra de una forma menos traumática.

Unos cuantos cambios que seguro que se agradecen… aunque no tanto como los que se esperan para la futura (y confiemos que más estable) versión de Asterisk 1.8.

ERROR[6542] chan_zap.c: !! < Unknown IE 26 (cs5, len = 4)

Lo curioso es que este ensaje de error se repetía cada muy poco tiempo, así que un poco mosqueado, pese a que todo el sistema funcionaba correctamente, decidí investigar el porqué de este mensaje.

Tras hace un ‘pri intense debug span 1‘ durante varios minutos y revisar toda esa cantidad ingente de datos llegué al mensaje que provocaba el error:

< Informational frame:
 < SAPI: 00  C/R: 1 EA: 0
 <  TEI: 000        EA: 1
 < N(S): 022   0: 0
 < N(R): 061   P: 0
 < 20 bytes of data
 Handling message for SAPI/TEI=0/0
 -- ACKing all packets from 60 to (but not including) 61
 -- Something left to transmit (61), restarting T200 counter
 < Protocol Discriminator: Q.931 (8)  len=20
 < Call Ref: len= 2 (reference 610/0x262) (Terminator)
 < Message type: INFORMATION (123)
 < [28 08 20 30 20 50 41 53 4f 53]
 < Display (len=  [  0 PASOS ]
 < [95]
 < Locking Shift (len=01): Requested codeset 5
 < [1a 02 c4 00]
 [Jun  5 11:52:03] ERROR[6542]: chan_zap.c:8248 zt_pri_error: !! <  Unknown IE 26 (cs5, len = 4)
 -- Processing IE 40 (cs0, Display)
 -- Processing IE 26 (cs5, Unknown Information Element)
 !! Unknown IE 26 (cs5, Unknown Information Element)
 Sending Receiver Ready (23)

Fotografía de VentureVoIP

Por lo que me dí cuenta que ese error era simplemente la interpretación de un tipo de mensaje AOC (Advise of Charge) dentro del conjunto de mensajes ‘cs5‘ definidos como “Mensajes personalizados del Proveedor”, por lo que estaba claro, un tipo de mensaje que envía el proveedor para informar los “pasos” o los “momentos en los que aumenta el coste de esa llamada” a fin de que el sistema pueda reconocerlo y sea capaz de mostrar el coste de la llamada en tiempo real (por ejemplo para una cabina de teléfono, un locutorio o cualquier otro caso).

Asterisk no lo reconocía como tal, así que rellené el ticket en issues.asterisk.org para comentar este mensaje y que, por lo menos dejase de aparecer como “mensaje de error“.

Pues me entero gracias a la lista Asterisk-DEV y a la web VentureVoIP que David Vossel está desarrollando el soporte de AOC para Asterisk de forma que sea capaz de entender y actuar en función de los mensajes que reciba del proveedor, por lo que David está interesado en encontrar a gente que necesite de este soporte para que pueda probar lo que lleva hecho y así que el soporte de esta característica sea lo más real, efectivo y útil posible.

Os dejo el mensaje que ha publicado:

Hello!

Good news for those of you who are interested in Advice Of Charge support in Asterisk, the AOC branches are ready for testing! Below are the locations of the LibPRI and Asterisk components of this feature.

Asterisk Branch: http://svn.digium.com/svn/asterisk/team/dvossel/generic_aoc
LibPRI Branch: http://svn.digium.com/svn/libpri/team/dvossel/aoc_send

A help document explaining how AOC works in Asterisk can be found in ‘docs/advice_of_charge.txt‘ within the root directory of the Asterisk checkout.

If you are interested in generating your own AOC using Asterisk, I am especially interested in how you imagine doing that. At the moment AOC-E and AOC-D can be generated via an AMI action (this is all documented in the help document), but we still haven’t decided on how we would like to expose AOC-S message generation. An AMI action is probably not a good option for AOC-S because AOC-S must be generated before call-setup takes place. I was thinking a dialplan function would be nice. This would allow the generation of the AOC-S message on the channel before calling the Dial app. Would that be useful to anyone? Is there anyone even interested in generating AOC-S? Any other suggestions are more than welcome!

We look forward to your feedback and any help you can offer to make this new feature set more useful!

David Vossel
Digium, Inc. | Software Developer, Open Source Software

Kevin P. Flemming anunciaba el otro día que varios desarrolladores de Digium se habían puesto manos a la obra para plantear y empezar a desarrollar un soporte en condiciones para los faxes (pese a que utilizar faxes, es y seguirá siendo, una tecnología totalmente obsoleta y que debería desaparecer).

Gracias a la experiencia obtenida por el desarrollo del módulo comercial Fax for Asterisk de Digium que mejora considerablemente la velocidad y la calidad de envío y recepción de faxes (que por cierto, parece ser que ya es compatible con sistemas de 64bits), Asterisk 1.8 contará con una implementación similar utilizando un stack propio de forma que este soporte sí se pueda licenciar como un producto GPL y pueda integrarse en la próxima versión de Asterisk.

De forma que, aunque en Asterisk 1.6 el soporte de Faxes es ya bastante bueno, Asterisk 1.8 contará con un soporte mucho mejor y que hará las delicias de aquellos usuarios que utilicen faxes.

Si no teneis miedo a perder la garantia de vuestro iPhone, y alguien se anima a hacer una particion dual, para que su iphone pueda arrancar en cualquiera de ambas opciones, puede encontrar las instrucciones detalladas aquí. De hecho, sé de alguien que se va poner con esa instalación de inmediato, para demostrarnos que “multitarea” es mejor, la de iphone o la del droid, y poder seguir con nuestro particular y amistoso pique…. o no, rodrigo ?

Me imagino que esto será además el principico, a este paso… no me extrañaría ver también un iPod “Androiozado” dentro de poco… (y quien dice un iPod, dice un iPad).

Este evento se realiza semanalmente y básicamente responde a estas preguntas:

- ¿Qué es Asterisk?
- ¿Qué puedo hacer con Asterisk?
- ¿Qué beneficios tiene el software libre para mí?
- ¿Qué versión de Asterisk es la más adecuada?
- ¿Dónde puedo conseguir ayuda y soporte profesional?
- ¿Cómo puedo empezar?

Si conoces a alguien que aún no conozca las respuestas a estas y otras preguntas puede interesarle este webminar completamente gratuito y que únicamente hace falta registrarse para recibir la dirección web para acceder.

El próximo webminar será el próximo 22 de Abril (mañana) de 19:00 a 20:00 GMT+1 y podeis inscribiros en esta web:

https://www1.gotomeeting.com/register/989760528

Es esta una discusión controvertida, y sobre todo muy habitual cuando juntas a gente de ambos mundos.

Unos te hablan de un software más económico y accesible, que no se basa en estándares propietarios y es por lo tanto integrable con todas aquellas soluciones basadas en estándares. Un software que puede ser mejorado y modificado por cualquier usuario para adaptarlo a sus necesidades específicas. Sin necesidad de pago de licencias, y con un soporte extendido y basado en una amplia comunidad de usuarios. La existencia de esta comunidad permite que el software sea muy diverso y eficiente,  ya que los usuarios que lo desarrollan tienen necesidades muy variadas y al tratarse de un grupo tan ingente de técnicos, puede obtenerse una muy buena optimización del software, además de una rápida resolución de los bugs que puedan surgir.

Otros te hablan de grandes empresas que te proporcionan respaldo y mantenimiento a sus aplicaciones. De casos de éxito en todo el mundo. De empresas que invierten una gran cantidad de recursos en conseguir un software fiable y estable, haciendo además mucho hincapié en su usabilidad. De que este tipo de software suelen tener una menor curva de aprendizaje que los softwares libres. Que suelen ser más amigables y orientados al usuario final, con interfaces gráficas mejor diseñadas, y con una menor variedad de distribuciones que pueden confundir al usuario.

En mi opinión, hay un factor muy importante a tener en cuenta a la hora de decidir entre un software libre y un software propietario. El mercado. Según el mercado al que nos queramos orientar en cada momento, la solución que más se puede adaptar a sus necesidades puede ser en unos casos una solución basada en software libre, y en otros, una solución basada en software propietario. Debemos ser capaces de adaptarnos a las diferentes coyunturas, tanto económicas, como políticas o sociales de cada cliente, para ofrecerle la solución que mejor encaje en su entorno. Incluso en muchos casos, podemos tener que llegar a una solución mixta, con ciertas partes basadas en software libre y otras en software propietario.

Lo fundamental es, en mi opinión, no quedarse nunca en los extremos. No quedarnos sólo con una de las dos soluciones, y ser en cambio capaces de ver en cada momento los beneficios que ambos mundos nos ofrecen, y adpatar nuestra solución al mercado que nos rodea.

Asterisk Bilbao 2010 durante un laboratorio

Esta semana se ha celebrado el curso oficial de Digium Asterisk Advanced en Bilbao con la inestimable ayuda de la gente de Irontec, y que gracias al buen ambiente de los asistentes, ha sido una semana realmente divertida y muy productiva.

El temario es similar al de otras ocasiones, donde se cubren los principales aspectos básicos de Asterisk como programación de dialplan, telefonía, VoIP, callcenters, redes orientadas a VoIP, desarrollo con Asterisk y algunas curiosidades y ejemplos interesantes sobre las posibilidades de Asterisk en diferentes infraestructuras y con un gran número de casos particulares.

Cualquier momento es bueno para hacer una pregunta, exponer un problema y sobre todo conseguir una respuesta, algo que realmente se consigue gracias a momentos especiales como la hora de la comida, la cena o el “descanso” de 15 minutos para un café. Uno en esos momentos se da cuenta lo importante que es el trato amigable que tanto valor da a estos cursos y por el que es uno de los preferidos por los usuarios.

De poco sirve un temario ultra-completo, unos conceptos teóricos excepcionales, si no se consigue ilusionar a una persona que asiste al curso de forma que llegue a entender, comprender y captar, aunque sea durante unos instantes, la filosofía que hay detrás de todo un sistema software libre como es Asterisk. De poco sirve un profesor que sepa muchísimo si no sabe ponerse a la altura de la gente, mirar arriba y ser capaz de enseñar a alguien a levantarse. De poco sirve un curso si cuando termina, no se ha aprendido nada.

Al final de la semana, como viene siendo tradición en estos cursos, se celebra el examen de certificación dCap para todo aquel que, estando o no, en el curso, quiera realizar el examen para obtener la certificación de profesional de Asterisk de la mano de Digium, así que suerte a todos!

Esto y mucho más es el curso de Asterisk Advanced, un curso que, además de completo y centrado en Asterisk, y donde se aprende tanto los conceptos básicos como los más minúsculos detalles que pueden salvarnos en un momento crítico y donde el estado de ánimo es esencial para enmarcar un curso de caracter avanzado y donde al final la gente no son “alumnos” si no grandes colegas con un interés común como es Asterisk.

He pasado una semana realmente agotadora, pero sin duda, con una excelente compañía.

Gracias a todos los que habeis venido y espero que nos veamos pronto!

Goruntz!

Actualmente existen en mercado diferentes soluciones de call center integrables con Asterisk, que nos darán un entorno de call center plenamente funcional y con una amplia variedad de funcionalidades, para poner en marcha nuestro negocio.

De entre todas las soluciones existentes en el mercado, yo personalmente destacaría tres:

• ICR Evolution
• Altitude VBox
• Zasylogic AIBE

Todas ellas integran módulos CTI, pop-ups de pantallas a la recepción de llamadas, marcación automática predictiva, gestión de campañas y desarrollo de argumentarios, almacenamiento de datos de clientes y llamadas en bases de datos, y módulos de monitorización y estadísticas.

Las principales diferencias entre ellas podrían resumirse de la siguiente forma:

• ICR Evolution está basado en servidores Windows y bases de datos  SQL. Carece de licenciamiento, excepto en su modalidad Enterprise. Por lo tanto, se trata de un software gratuito, que tan sólo tiene un coste de mantenimiento, en caso de querer contratarlo con fabricante. Se integra fácilmente con Asterisk, delegando en la PBX todas las funcionalidades de centralita, alta y gestión de agentes y colas.
• Altitude VBox, es en sí misma una centralita basada en Asterisk y optimizada para call center, con lo que no precisa de una centralita Asterisk adicional con la que integrarse. Sin embargo, esta integración es interesante en el caso de que queramos cubrir tanto la telefonía corporativa de la empresa como el call center, ya que la VBox de Altitude es una centralita preparada para dar funcionalidades únicamente de call center.
• Zasylogic AIBE es un sistema de call center basado en un software propietario de Zasylogic. Se integra con Asterisk, haciendo esta de centralita y gestionando agentes y colas, al igual que en el caso de ICR. Tiene, a diferencia de ICR un coste de licenciamiento, además del coste anual de mantenimiento.

Otra solución para call center basada en Asterisk, consistiría en utilizar únicamente las funcionalidades de call center que nos da esta PBX, su gestión de colas y de agentes, y añadirle un módulo de estadísticas como podría ser QueueMetrics. En este caso no contaríamos con las funcionalidades de campañas y argumentarios que nos ofrecen el resto de soluciones, pero en casos de call centers pequeños (por ejemplo un departamento de telemarketing de una empresa), podría ser más que suficiente esta solución.

Un de los “mínimos inconvenientes” a la hora de instalar un foneBridge2 es, sin duda, tener que utilizar un paquete DAHDI especial que siempre se ha venido descargando de la página de soporte de Redfone, y gracias a la documentación y a los distintos paquetes que podemos encontrar, la instalación siempre ha sido bastante sencilla y rápida. No obstante el uso de un foneBridge2 siempre ha requerido de algunos “trucos” que nos pueden extrañar poco habituales como la obligación de desinstalar el script de inicio que incluye DAHDI cuando se instala el paquete y sustituirlo por uno especial de Redfone para evitar mensajes extraños o fallos de incompatibilidad entre el módulo tdmoe que ya trae DAHDI con el módulo tdmoe multiframe que es el que utiliza Redfone, algo que podremos evitar una vez sea incluido en el driver oficial.

Esto sin duda mejorará el soporte y la sensación general de que nuestro dispositivo está bien soportado. Ya lo estaba por supuesto ya que hay una gran cantidad de usuarios con excelentes opiniones y críticas sobre este dispositivos, y aquellos que tienen alguna incidencia, la gente del soporte técnico de Redfone hace lo imposible para que el cliente quede satisfecho. Esto es realmente digno de admirar hoy día y ofrece una total tranquilidad y seguridad a aquellos usuarios que optan por esta solución.

En la página de cuestiones de Asterisk se puede ver el nuevo módulo que ha sido añadido por JBenden al trunk de Asterisk: https://issues.asterisk.org/view.php?id=13483

Muchas gracias a Jorge Churio por el aviso.

Espero os guste…