Probando IPv6 Parte 2

Continuamos con el howto para “engancharnos” a internet mediante IPv6.

Si hemos seguido el post anterior, ya deberíamos tener conectividadad IPv6 en nuestro router, aunque solo para el router (solo una IP). Después de una semana sin probemas, ya tenemos créditos (ISKs) suficientes para solicitar una subreda a sixxs.

Vamos a suponer que nos han asignado la subred 2001:b18:baba::/48. Una red local tiene una dirección de red de 64 bits (/64), quedando el resto de la dirección (los otros 64) para el direccionamente en la red local. Esto quiere decir que nos han asignado una subred con soporte para 65536 subredes locales. Más que sufiente, creo yo ;) Leer más…

Escrito por julianjm el 20/11/2008. | Comments (0)
Tags: , ,

Probando IPv6 Parte 1

IPv6Llevamos tiempo oyendo sobre IPv6, de cómo se está agotando el espacio de direcciones de IPv4, y que el cambio será inevitable en los próximos años.

En la actualidad hay pocos ISP que den conectividad IPv6 de forma nativa (Telefónica, are you there?), así que la alternativa que tenemos es usar un tunel 6to4 con un ISP. En el caso que voy a comentar, utilicé SixXs.

Antes de embarcarse en esta cruzada, recomiendo encarecidamente leer el artículo sobre IPv6 de la wikipedia, para entender bien los tipos de direcciones, cómo se forman y cómo se enrutan los paquetes:

Escenario

  • Router flasheado con OpenWRT White Russian (Con Kamikaze también sirve)
  • Tunel IPv6 con un broker (www.sixxs.net)
  • Asignación de subred IPv6 para la LAN

Cualquier otra distribución de linux nos servirá… Los pasos a seguir variarán, pero el fondo es el mismo ;)

Leer más…

Escrito por julianjm el 17/07/2008. | Comments (2)
Tags: , ,

Configurar OpenWRT para QoS con Asterisk

WRT54GEn una centralita IP, sobre todo si usas proveedores IP, es fundamental tener un sistema de QoS (Calidad del Servicio, en inglés), que regule el tráfico de/hacia Internet, y priorice el tráfico importante del que no lo es tanto.

De nada sirve (aunque ayuda) tener una conexión de 20 “megas” si, cuando un usuario de la red enchufa el bittorrent, tu interlocutor se convierte en Robocop. Por ello, la principal función del router será discriminar los paquetes que salen (y llegan) de Internet, en distintas clases, de forma que los pertenecientes a las clases con alta prioridad salgan los primeros, y los menos importantes salgan cuando puedan o, directamente, no salgan. Que un email tarde 20 segundos más en enviarse es un problema menor. Que no te escuchen, o te escuchen mal, es inaceptable.

En el mercado hay multitud de dispositivos que permiten hacer QoS. Routers Cisco, HP, Dell, y un largo etcétera. En la mayoría de casos, caros, muy caros. Si he de ser sincero, debo decir que no tengo experiencia con ningún Router “con mayúscula”. Amigos, la pela es la pela.

Sigue leyendo… Leer más…

Escrito por julianjm el 28/04/2008. | Comments (17)
Tags: , , ,

Linksys/Sipura SPA9xx Provisioning

SPA962Para una instalación que tenemos que hacer, todo con teléfonos SPA922,SPA942 y SPA962, hemos actualizado el sistema de provisionamiento de los PAP2 que publiqué hace tiempo.

Está hecho con la simplicidad como objetivo, y tratando de facilitar futuras instalaciones. Para esto utilizamos un sistema de plantillas en cascada, es decir, empezamos con una plantilla general, y vamos añadiendo personalizaciones, hasta llegar a la última, en la que prácticamente sólo hay que especificar el número de extensión (usuario) y la contraseña.

  1. {modelo}-default.cfg: Esta plantilla contiene los ajustes por defecto del modelo de teléfono. {modelo} se reemplaza por 922, 942, 962, etc. Más adelante os comento cómo generar este fichero.
  2. global.cfg: Aquí indicamos, como instaladores, las modificaciones a los ajustes por defecto. Por ejemplo, la regionalización, diccionarios de idiomas, etc. Así evitamos tocar la plantilla anterior, que puede variar con cada actualización del firmware.
  3. site.cfg: Ajustes para una instalación concreta, es decir, la IP del proxy, servidor NTP, Syslog, Zona horaria, etc.
  4. {modelo}-site.cfg: Ajustes más específicos para una instalación y modelo. Por ejemplo, para las actualizaciones de firmware, usando el Upgrade_Rule.
  5. {modelo}-{mac}.cfg: Finalmente la configuración de cada teléfono. Si el resto se ha hecho bien, solo queda indicar la extensión y contraseña.

El fichero de ajustes por defecto se genera a partir del xml que proporciona el teléfono en http://x.x.x.x/admin/spacfg.xml. Hay un script (xml2cfg) que “parsea” el xml, y lo convierte en pares de clave:valor.

Paso 1. Servidor DHCP

Los SPA9xx, cuando arrancan por primera vez (o después de un “factory reset”), buscan un servidor DHCP que les asigne una dirección IP. A continuación, intentan descargar desde el servidor, mediante TFTP, un fichero de configuración: spa922.cfg, spa942.cfg, etc, según el modelo.

En esta primera instancia, lo que haremos será redirigir el teléfono (mediante el parámetro Profile_Rule), a un script en PHP que genere la configuración definitiva. Además, forzaremos al teléfono a que descargue esta configuración lo antes posible (10 segundos, en lugar de 1 hora).

El fichero /tftpboot/spa922.cfg, por ejemplo, quedaría así:

<flat-profile>
<GPP_A ua="na">x.x.x.x</GPP_A>
<Profile_Rule ua="na">http://$A/provisioning/config.php?model=$PSN&mac=$MA</Profile_Rule>
<Resync_Periodic ua="na">10</Resync_Periodic>
<Resync_Error_Retry_Delay ua="na">10</Resync_Error_Retry_Delay>
<Resync_Fails_On_FNF ua="na">Yes</Resync_Fails_On_FNF>
</flat-profile>

Vemos que se dirige a un script (config.php), y que se le pasa como parámetro tanto el modelo como la MAC del teléfono.

Paso 2. El servidor Web

Todo el meollo está en el script config.php. Lo dejamos en /var/www/html/provisioning/, o donde más os guste. Al recibir una petición para un modelo y MAC concretas, leerá las plantillas de ajustes que correspondan, y generará una configuración completa para el teléfono.

Paso 3. Las plantillas de ajustes

Como las plantillas se leen en un orden concreto, y cada plantilla va sobreescribiendo los ajustes de la anterior, bastará con tener una configuración base, la que trae de fábrica el teléfono, y luego sobre esta, ir haciendo las modificaciones que precisemos.

Para generar esta plantilla base, podemos usar un pequeño script que incluyo:

$ cd /etc/provisioning/
$ wget http://ip.del.sp.a/admin/spacfg.xml
$ xml2cfg spa.cfg > 922-default.cfg
$ rm spacfg.xml

El resto de ficheros siguen el mismo formato, Clave:Valor. En el fichero global.cfg, por ejemplo, nosotros incluimos los ajustes de regionalización (frecuencia y cadencia de los tonos de línea, ocupado, etc), y otros ajustes comunes a todas las instalaciones que haremos.

Ejemplo de global.cfg: (Ajustes sacados de http://www.voipnovatos.es/item/2008/01/call-progress-tones-linksys-spa)

Dial_Tone:425@-10;10(*/0/1);
Outside_Dial_Tone: "425@-10;10(*/0/1);
Busy_Tone:425@-20;10(.2/.2/1);
Reorder_Tone:425@-10;10(0.2/0.2/1,0.2/0.2/1,0.2/0.6/1);
Off_Hook_Warning_Tone:425@-10;10(.25/.25/1);
Ring_Back_Tone:425@-10;10(1/4/1);
Call_Waiting_Tone:425@-20;10(0.175/0.175/1,0.0175/3.5/1);
Confirm_Tone:;
SIT1_Tone:950@-10,1400@-10,1800@-10;10(.33/0/1,.33/0/2,0.33/1/3);
SIT2_Tone:;
SIT3_Tone:;
SIT4_Tone:;
MWI_Dial_Tone:425@-10;10(1/0.1/1)" ;
Cfwd_Dial_Tone:425@-10;10(0.5/0.05/1)" ;
Holding_Tone:1400@-20;10(0.4/5/1)" ;
Conference_Tone:;
Secure_Call_Indication_Tone:;
Page_Tone:;

Ejemplo de site.cfg

Proxy_1_:x.x.x.y

Ejemplo de 922-AABBCCDDEE.cfg

Display_Name_1_:Julian
User_ID_1_:201
Password_1_:esunsecreto

Descargar el código

He montado un servidor SVN para éste y futuros proyectos, y para facilitar las mejoras (en forma de parches) que me enviéis ;). Se distribuye bajo licencia GPL:

$ svn co http://svn.julianmenendez.es/spa-provisioning/trunk spa-provisioning

Conclusión

Sé que hay muchas mejoras posibles, pero esto funciona, y al estar basado en plantillas de ajustes, realizar una instalación nueva solo requiere copiar los ficheros, ajustar el fichero site.cfg, y crear los diferentes ficheros de cada teléfono.

Como mejoras que me gustaría implementar, destacan:

  • Generación estática de los ficheros de configuración. Después de hacer un “make”, por ejemplo, el script generaría los ficheros directamente en /tftboot/{model}-{mac}.cfg, de forma que sólo se requeriría un servidor TFTP.
  • Interfaz web para gestionar las configuraciones
  • Autoprovisioning. Detectar los nuevos teléfonos, y desde la interfaz web, poder rápidamente asignarles usuario/contraseña. Plug&Talk :)

Julián J. M.

Escrito por julianjm el 28/04/2008. | Comments (1)
Tags: , , ,

Probando las Tarjetas OpenVox

Juan Carlos Valero, de Capatres, nos ha prestado un par de tarjetas de OpenVox, para poder probarlas, y de paso hacer un pequeño review. Las tarjetas son la B200P, para 2 puertos RDSI, y la A400P para hasta 4 puertos FXS/FXO.

OpenVox B200P OpenVox A400P

Jumpers de la OpenVox B200P OpenVox A400P con módulos

Las Tarjetas

La A400P es clavadita a la TDM400P. Lleva el chip TigerJet 320, admite hasta 4 módulos FXS y FXO. Para los primeros es necesario proporcionar alimentación adicional a la tarjeta, mediante un conector molex. Los módulos son compatibles con los de Digium. De hecho, en la foto de arriba, los del 1 y 4 son OpenVox, y los 3 y 4 Digium.

La B200P lleva el chip HFC-4S, que puede gestionar hasta 4 puertos. De hecho, si os fijáis, la diferencia es que no tiene soldados los componente de dos de los puertos. Alguien con tiempo libre, y sin miedo a perder la garantía, podría intentar habilitar estos dos puertos extra ;).

Lo bueno de la tarjeta, comparándola con la Billion HFC de un solo puerto, es que dispone de jumpers para seleccionar el modo de operación: TE, para conectarlo a un TR del operador, o NT para conectar un teléfono RDSI. Además, para este último caso, dispone de un conector molex, para poder proporcionar el voltaje necesario a la línea, y que los teléfonos tomen de ahi la energía.

Instalación y configuración

Una vez pinchadas en sendos slots PCI, así es como las detecta el sistema operativo:
$ lspci
[...]
03:08.0 Communication controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface
03:09.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01)
[...]

La primera de ellas es la A400P, y la segunda la B200P.

A400P

La configuración de la A400P es exactamente igual a la TDM400P de Digium. Es decir, definimos en /etc/zaptel.conf los módulos instalados, en nuestro caso un FXS en el puerto 1 y un FXO en el 4:

loadzone = es
defaultzone=es
fxoks=1 ; La señalización es justo al contrario
fxsks=4

En /etc/asterisk/zapata.conf :

[channels]
language=es
signalling=fxo_ks
context=from-internal
callerid=Extension Zap <201>
channel=>1
;
signalling=fxs_ks
context=from-pstn
answeronpolarityswitch=yes
hanguponpolarityswitch=yes
polarityonanswerdelay=1
channel=>4

Comprobamos en asterisk que los puertos estén disponibles:

tamaja*CLI> zap show channels
Chan Extension Context Language MOH Interpret
pseudo from-pstn es default
1 from-internal es default
4 from-pstn es default

Las llamadas desde la extensión se dejan en el contexto from-internal. Las llamadas desde la red telefónica entran por from-pstn.En /etc/asterisk/extensions.conf:

; Dialplan minimalista
[from-internal]
exten => _[6789]XXXXXXXX,1,Dial(Zap/4/${EXTEN})
;
[from-pstn]
exten => s,1,Dial(Zap/1)
exten => s,n,Hangup

B200P

Seguimos con la B200P. Podemos usar tanto el parche Bristuff, como tirar de chan_misdn. Yo prefiero la segunda opción.

Descargamos e instalamos mISDN (modulos del kernel) y mISDNUser (aplicaciones) desde http://www.misdn.org. El script misdn-init, que se instala en /etc/init.d/ nos permite detectar las tarjetas compatibles y generar el fichero de configuración. Además, usado en el arranque y parada del servidor, carga y descarga los módulos.

$ /etc/init.d/misdn-init scan
[OK] found the following devices:
card=1,0x4
[ii] run "/usr/sbin/misdn-init config" to store this information to /etc/misdn-init.conf
.
$ /etc/init.d/misdn-init config
[OK] /etc/misdn-init.conf created. It's now safe to run "/usr/sbin/misdn-init start"
[ii] make your ports (1-4) available in asterisk by editing "/etc/asterisk/misdn.conf"

Editamos el fichero de configuración /etc/misdn-init.conf. En primer lugar, desactivamos los puertos 3 y 4, ya que esta tarjeta no los tiene. Además, dado que las dos RDSI están configuradas en grupo, en modo PTP, tendremos que modificar ese parámetro:

card=1,0x4
te_ptp=1,2 ; solo dos puertos, yen modo PTP
poll=128
dsp_poll=128
dsp_options=0
dtmfthreshold=100
debug=0

Arrancamos el servicio, para que se carguen los módulos:

$ /etc/init.d/misdn-init start
-----------------------------------------
Loading module(s) for your misdn-cards:
-----------------------------------------
/sbin/modprobe --ignore-install hfcmulti type=0x4 protocol=0x22,0x22,0x2,0x2 layermask=0xf,0xf,0xf,0xf poll=128 debug=0
/sbin/modprobe mISDN_dsp debug=0x0 options=0 poll=128 dtmfthreshold=100
[i] creating device node: /dev/mISDN

Copiamos ahora el fichero de configuración de misdn que viene con asterisk, y lo adaptamos. Básicamente, añadimos esta sección al final:

[telefonica]
ports=1,2
msns=*
context=from-pstn
echocancel=yes

Hemos definido un grupo (telefonica), que utilizará los puertos 1 y 2 de la tarjeta. Aceptará todos los MSN (o DID’s), y entrarán las llamadas al contexto from-pstn.

tamaja*CLI> misdn show stacks
BEGIN STACK_LIST:
* Port 1 Type TE Prot. PTP L2Link DOWN L1Link:DOWN Blocked:0 Debug:0
* Port 2 Type TE Prot. PTP L2Link DOWN L1Link:DOWN Blocked:0 Debug:0

Aún no hemos conectado las líneas, por eso aparecen DOWN.

Así quedaría nuestro dialplan de ejemplo, en /etc/asterisk/extensions.conf:

; Dialplan minimalista
[from-pstn]
exten => 928000000,1,Dial(Zap/1)
exten => 928000000,2,Hangup
[from-internal]
exten => _[6789]XXXXXXXX,1,Set(CALLERID(num)=928000000)
exten => _[6789]XXXXXXXX,n,Dial(mISDN/g:telefonica/${EXTEN})

Estamos usando el grupo que definimos antes para realizar las llamadas. También podríamos utilizar un puerto específico (mISDN/1/${EXTEN} o mISDN/2/${EXTEN}).

Conclusión

Las tarjetas funcionan, el aspecto y fabricación son buenos. Queda eso sí, probarla durante un tiempo en una centralita en producción, pero tengo la sensación de que no darán problemas. Si los hubiese, seríais los primeros en saberlo ;)

En definitiva, si todo sigue como hasta ahora, y teniendo una empresa en España que distribuya las tarjetas y gestione las garantías (en lugar de reclamar directamente a los chinos de OpenVox), son una opción igual de válida, pero más económica, que las originales.

Escrito por julianjm el 10/04/2008. | Comments (14)
Tags: , , ,

Usando la red DUNDi en Asterisk

Este mes toca darle un repaso a DUNDI, un protocolo de localización de servicios telefónicos.

Básicamente, DUNDI nos permite crear una red P2P de centralitas, donde cada una “publica” números de teléfono para los que es responsable, como sus extensiones locales, números para la que es la ruta de menor coste, etc.

Dos ejemplos

El ejemplo típico es el de la empresa multisede. Cada sede publica sus extensiones propias, de forma que el resto pueda localizarlas. ¿Quién tiene la extension 329? Esta consulta se enviaría, directa o indirectamente, a todos los equipos (peers) de la red DUNDI. La centralita que sirva esa extensión responderá algo como “IAX2/usuario:clave@1.2.3.4/329″, que es la forma de llamar a dicha extensión. La centralita que hizo la consulta utilizará esa información para llamar efectivamente a la extensión 329.

Aún en el caso de que cada sede tenga asignado un rango de extensiones, DUNDI nos resultará útil, porque evitaremos llamar a la centralita remota si la extensión buscada no está creada aún, aunque esté en su rango. Podremos gestionar el error localmente.

En otro ejemplo de uso, las diferentes centralitas publican los números de teléfonos locales. Tenemos la sede A en Asturias, la B en Barcelona y la C en Canarias.

Pongamos que un usuario de la sede C llama a Asturias, al 985123123. Estamos hablando de llamada nacional, que si no tenemos tarifa plana, no es barata. La centralita, antes de marcar usando las líneas propias, hará una consulta DUNDI, para ver si alguien puede terminarnos la llamada. La centralita A nos responderá con IAX2/usuario:clave@sedea.empresa.es/985123123.

Cuestiones a tener en cuenta

El protocolo DUNDi utilizar por defecto el puerto 4520/UDP. Habrá que abrirlos en los firewalls. Es independiente de IAX, es decir, la cadena de conexión devuelta en una consulta puede hacer referencia a cualquier tipo de canal (IAX2, SIP, H323, etc), aunque normalmente se usa el IAX2.

Manos a la obra

Leer más…

Escrito por julianjm el 17/12/2007. | Comments (23)
Tags: ,

Llamadas a bajo coste desde el móvil

Hoy en día, todo el que tenga una ADSL tiene además una tarifa plana para llamadas a fijos nacionales. Con determinadas operadoras incluso incluyen las llamadas a móviles. Si queremos hacer llamadas internacionales, usamos un operador de telefonía IP.

La idea, como se comentaba en la lista de correo asterisk-es, es poder utilizar estos servicios desde cualquier lugar, y de forma sencilla, usando nuestro teléfono móvil.

Casi todos los operadores nacionales permiten contratar “tarifas planas”, o tarifas reducidas para llamadas a uno o varios números de teléfono (normalmente fijos). Este punto depende de si somos particulares, autónomos, empresas, ya que las tarifas y promociones cambian.

Nuestro objetivo sera conseguir llamada gratuitas (o casi) en llamadas desde el móvil a nuestra centralita. Una vez conectados, las llamadas que realicemos se originarán en ésta última, y saldrán por la ruta de menor coste que tengamos configurada.

Escenario

Conseguimos una tarifa plana a un número fijo geográfico. No queremos usar el de nuestra línea fija, porque entonces las llamadas a fijo tendrían que salir por otro operador, y seguramente no entraría en la tarifa plana nacional.

Contrataremos, pues, un número DID en cualquiera de los proveedores IP que dan este servicio (telsome, azulcom, peoplecall, voxbone, etc). Como las llamadas entrarán vía internet, tendremos la línea convencional libre para sacar las llamadas a fijos nacionales.

La “tecla” P

En los teléfonos móviles, pulsando 4 veces la tecla asterisco *, nos aparece la letra P. Indica al teléfono móvil que llame al número de teléfono que la precede, espere a que contesten, y acto seguido enviar mediante tonos DTMF todo lo que sigue. Por ejemplo, 928999999P900502010. Si nuestra centralita está configurada correctamente, debería descolgar, y escuchar los tonos que se le envíen, para luego iniciar la llamada.

Configuración básica

Nuestro nuevo DID será el 928999999. Cuando nos llamen a este número, la llamada entrará al contexto from-pstn. El número de nuestro móvil es el 653000000. Las llamadas desde este número se envían al contexto directdial. Contestará la llamada y esperará los tonos DTMF del verdadero destino. La llamada se efectuará como si estuviésemos marcando desde una extensión.

extensions.conf

[from-pstn]
exten => 928999999/653000000,1,Goto(directdial,s,1)
... (resto del contexto de entrada)...
;
[directdial]
exten => s,1,Answer
exten => s,n,Set(TIMEOUT(response)=5)
exten => s,n,Background(silence/1&beep)
exten => s,n,Disa(no-password|from-internal)

Como véis no tiene mucha complicación. Ahora para los paranóicos de la seguridad, cualquiera que sepa vuestro número DID, y pueda falsificar su callerid (y hacerse pasar por vuestro móvil), podría efecturar llamadas a vuestra costa. Creo que es una situación bastante poco probable. Aún así, vamos a ver una posible solución.

Alguno estará tentado de cambiar ese “no-password”, por una clave numérica. Si bien es posible, cada vez que queramos cambiar la clave, tendríamos que modificar toda nuestra agenda de teléfonos para hacerlo constar. Esta clave se pide antes de que leamos los tonos.

extensions.conf

[directdial]
exten => s,1,Answer
exten => s,n,Set(TIMEOUT(response)=5)
exten => s,n,Background(silence/1&beep)
exten => s,n,Disa(no-password|from-internal-authenticate)
;
[from-internal-authenticate]
exten => _[X*].,1,Authenticate(1234)
exten => _[X*].,2,Goto(from-internal,${EXTEN},1)

De esta forma, la clave nos la pedirá justo antes de efectuar la llamada.

Conclusión

Sé que no es cosa del otro mundo, pero seguro que más de uno puede ahorrarse unos euros. En cualquier caso, documentado queda.

Ah, y no se os olvide leer bien la letra pequeña de las diferentes tarifas de móviles, que siempre hay algo ;)

Escrito por julianjm el 26/11/2007. | Comments (15)
Tags: , ,

Reconocmiento de voz en asterisk con Lumenvox

Hoy toca ración de reconocimiento de voz :). Hace tiempo compré una licencia de evaluación (50$) para hacer pruebillas e impresionar al personal. En su día solo tenían el modelo de voz Inglés Americano, y para reconocer palabras en español tenías que hablar como un expresidente del gobierno ;). Pero han estado trabajando en ello, y ya tienen modelos específicos para español de Mejico y de Colombia.

Os voy a poner una ejemplo muy simple: el dialplan, la gramática, y un softphone web para que lo probéis de viva voz.

Paso 1: Instalar Lumenvox

Como he comentado antes, es un programa de pago,a sí que tendréis que adquirir al menos el Speech Starter Kit. La instalación y validación es algo cansina, pero que se le va a hacer. Seguid al pie de la letra las instrucciones que os llegarán por email. Básicamente se reduce a:

  1. Descargar e instalar el License Server.
  2. Generar el fichero de instalación (Info.bts), enviarlo a Lumenvox mediante el formulario web, y descargar el fichero con la licencia (License.bts). Estará asociado a la MAC de la tarjeta de red.
  3. Descargar e instalar el SRE (Speech Recognition Engine)
  4. Instalar el “Asterisk Connector Bridge”, que enlaza los servicios de voz de asterisk con el SRE de lumenvox.

Paso 2: Gramática

El sistema tiene que saber las frases que queremos detectar. Ejemplo:

root $frase
$sujeto = Pedro | Juan
$verbo = programa | estudia | sueña
$predicado = [ en ] C | PHP | AEL
$frase = $sujeto $verbo $predicado

Esta gramática reconocería frases como “Juan sueña en PHP”, “Pedro estudia C”, etc

Aquí es donde gana importancia el modelo de voz. Si usasemos el model Inglés, en vez de Pedro, habría que pronunciar algo como “Pedrou” ;), para que el sistema lo reconociese mejor.

Las gramáticas pueden ser muy complejas. Hay un ejemplo en la web de Lumenvox que simula la atención al cliente de una Pizzería, donde puedes realizar un pedido hablándole a la máquina (que miedo), aunque para el ejemplo que voy a mostraros, simplemente reconocerá una serie de nombres.

Paso 3: El Dialplan

Asterisk 1.4 ya incorpora funciones de reconocmiento de voz. Solo necesita de un motor que haga el reconocimiento y devuelva la información. Ejemplo:

exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,SpeechCreate
exten => s,n,SpeechActivateGrammar(migramatica)
exten => s,n,SpeechStart
exten => s,n(otravez),SpeechBackground(beep)
exten => s,n,NoOp(${SPEECH_TEXT(0)})
exten => s,n,Goto(otravez)

Paso 4: El Ejemplo

Será un directorio de blogs con temática voip ;). El sistema reconocerá una serie de nombres, y contestará con la dirección del blog/página web. Para finalizar, se podrá decir “hasta luego” o “ya es suficiente”. Después de cada reconocimiento, se escuchará la calidad del resultado (de 0 a 1000).

No se por qué, pero he tenido que utilizar fonemas para que me reconociese bien todos los nombres. Debería bastar con el nombre directamente, pero bueno. Con frases más largas funciona mejor.

Descarga la gramática asteriskes.gram

Prueba el sistema en vivo y en directo: Abrir jiaxclient (a ver si no se satura la ADSL)

También podeis llamar desde asterisk:

exten => 123,1,Dial(IAX2/jiaxclient@voip.julianmenendez.es/demo)

Escrito por julianjm el 19/10/2007. | Comments (10)
Tags: , , , ,

Bug en manejo de eventos rfc2833 en asterisk

Desde que migré a Asterisk 1.4 no he podido usar mi cuenta de Azulcom para hacer llamadas salientes. No ha sido hasta hoy, después de confirmar que el problema era Asterisk 1.4, que he encontrado la causa del problema.

Todo viene por el tratamiento de eventos RFC2833. Cuando tenemos dtmfmode=rfc2833, cuando asterisk recibe uno de estos paquetes RTP, lo “decodifica”, y se lo reenvía a la otra parte. Es en este momento cuando asterisk interpreta que todo lo que sea RFC2833 debe ser un dígito multifrecuencia (0123456789*#ABCDX, la X es un hook flash), cuando la realidad es que hay muchísimos más eventos que estos 16, y no deben ser interpretados como DTMF.

En el caso concreto que comento, llegaba un evento 0×8f (143), que según el RFC, corresponde a “MF S3″. No sé para qué sirve, pero esta claro que no puede dejarme sin comunicación.

He notificado el bug (#10877) , donde está el parche para descargar, por si alguno está en la misma situación.

Mola el Software Libre, o no? ;)

Actualización 4-10-2007: Ya está arreglado en el trunk, y en la rama 1.4.

Escrito por julianjm el 3/10/2007. | Comments (0)
Tags: , , , , ,

Click2Dial automático en Firefox

Actualizado 24-09-2007: Nueva versión. Mejoras en la deteccion de numeros. Añadidos todos los prefijos de paises. Mi idea es poder adaptar la detección a números locales de cada país. En la actualidad funciona con números en formato internacional, y números españoles.

Actualizado 24-09-2007: Sí, otra actualización :). Mejorada la presentación, al no permitir el salto de línea. A veces se quedaba la bandera en una línea y el número en otra. También se ha añadido el nombre completo del país. Se puede ver dejando el ratón unos segundos encima del icono de llamada .

A raíz de un mensaje en la lista de correo de asterisk-es, intenté encontrar un sistema similar, pero que no dependiese de Skype o similares. La idea era que se detectasen los números de teléfono que hubiese en una página web, y automáticamente convertirlos en un enlace a un servicio click2dial.

Greasemonkey es una extensión para Firefox, que permite ejecutar codigo javascript en la página que está cargando. Estos scripts permiten analizar y modificar la página web, y como son persistentes, se ejecutan cada vez que se carga.

Existe ya un script, Skype Linkify, que sustituye los números que encuentra por un enlace a “skype:elnumero?call“. Lo he tomado como base, para hacerle unas mejoras:

  • Soporte de números en formato internacional +34 928000000, 00 34 928000000, 011 34 928000000.
  • Soporte para números españoles: [6-9]xxxxxxxx.ww
  • Se añade una banderita con el país al que pertenece el número de teléfono, que queda muy mono ;)

Instalación

  1. Instalar la extensión Greasemonkey
  2. Descargar e instalar el script PhoneLink (original, eh?)
  3. En Greasemonkey, editar el script, y modificar las variables “myExt” y “url”. La primera corresponde a tu extensión. Si pones 201, el canal utilizado será SIP/201. La segunda corresponde al script (en php por ejemplo) que se llamará cuando pulséis en un teléfono. %DEST% se sustituye por el número de teléfono solicitado.
  4. Abrir una página que tenga números de teléfono.

Por supuesto, tendréis que tener alojado un php o similar que inicie la llamada en asterisk. El que he usado para pruebas (cuidado con dejarlo accesible, que no es seguro) es este: webcall.php

Ejemplos de patrones que se detectan bien:

  • +34 928 00 00 00
  • 0034 928000000
  • +1 212-000-1234
  • 928000000
  • 91-800-00-00
  • 928.00.00.00

Seguro que falla con otros, y que da falsos positivos en determinados casos. La expresión regular tiene bastante margen de mejora.

Screenshots ;)

Antes:

Página original

Después:

Página después de ser procesada por PhoneLink

PopUp:

Popup de información

Escrito por julianjm el 20/09/2007. | Comments (18)
Tags: , , ,

Next Page »