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 (more…)

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:

• http://en.wikipedia.org/wiki/Ipv6
• http://es.wikipedia.org/wiki/Ipv6

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

(more…)

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… (more…)

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.

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.

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

(more…)

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

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)

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.

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:

Después:

PopUp:

Hasta hace poco, solo había trabajado con OpenVPN. Es facil de configurar, y en la versión 2 habían incorporado el modo cliente-servidor, de forma que podíamos tener 1 servidor que interconectase a n clientes, con sus correspondientes redes.

Hasta aquí bien, aunque más de uno se dará cuenta del problema, y es que como te falle el servidor, la VPN se cae. Además, y esto también es importante en términos de latencia y ancho de banda, las comunicaciones entre clientes las enruta el servidor. No hay canreinvite en OpenVPN

La solución que se viene a la cabeza, es que todos los nodos sean servidores. Correcto. Pero el problema entonces viene por la escasa escalabilidad de la solución. Por cada nodo adicional que añadas a la VPN, tienes que configurar n+1 nodos (los n que ya había más el nuevo). Con 3 o 4 nodos se lleva bien, pero a partir de ahi olvídate.

Full-Mesh VPN

Y un día, buscando cómo hacía otra gente las VPN full-mesh (todos los nodos conectados directamente entre sí), descubrí tinc. Entre sus características:

1. Encryption, authentication and compression. Nada nuevo, encriptación para que nuestra información viaje segura por el medio inseguro (Internet). Autenticación, para que nodos desconocidos no puedan inyectar tráfico en nuestra red. Compresión, que nos permite sacar un poco más de partido a nuestra ADSL, comprimiendo los paquetes, antes de enviarlos.
2. Automatic full mesh routing. Aquí empieza lo bueno. Cada nodo en tinc se intercambia información de enrutamiento con el resto de nodos, de forma que cada uno se hace responsable de su subred (nodoa 192.168.0.0/24, nodob 192.168.1.0/24, etc). Cuando queremos acceder a una red en concreto, tinc contacta si puede con el nodo responsable de esa subred. Si no, utiliza un nodo intermedio para ello.
3. Easily expand your VPN. Para añadir un nuevo nodo, solo tenemos que configurar 2 nodos. El nuevo y uno de los que ya esté funcionando. Como la información de rutado se propagará por el resto de nodos automáticamente, esta es la configuración mínima que tendremos que hacer. Por supuesto, si configuramos dos o tres nodos, la VPN ganara en fiabilidad y robustez.

Escenario

Tenemos 3 sedes, cada una con su red privada y un acceso a internet:

• Sede A: 192.168.1.0/24. IP pública en Internet: 1.2.3.4
• Sede B: 192.168.2.0/24. IP pública en Internet: 2.3.4.5
• Sede C: 192.168.3.0/24. IP pública en Internet: 3.4.5.6

La máquina linux que corre tinc está siempre en la IP acabada en .1: 192.168.1.1, 192.168.2.1, 192.168.3.1.

En este ejemplo, por ser la configuración más común, la IP pública está asignada a un router ADSL. En este router, tendremos que configurar una nueva ruta, de forma que todo lo que llegue con destino a las otras sedes, se enrute por nuestro tinc. Algo como “route add -net 192.168.0.0 netmask 255.255.0.0 gw 192.168.1.1″. También abriremos el puerto 655 (TCP y UDP) redirigiéndolo a nuestra máquina con tinc.

Configuración

Creamos los directorios de configuración:

# mkdir /etc/tinc
# mkdir /etc/tinc/hosts


Creamos el fichero /etc/tinc/tinc.conf

Name = SedeA
Device = /dev/net/tun
ConnectTo = SedeB
ConnectTo = SedeC


Creamos el fichero /etc/tinc/hosts/SedeA

Subnet = 192.168.1.0/24
Address = 1.2.3.4
Compression = 10


Generamos el par de claves para este nodo:

# tincd -K
Generating 1024 bits keys:
..............++++++ p
..............++++++ q
Done.
Please enter a file to save private RSA key to [/etc/tinc/rsa_key.priv]:
Please enter a file to save public RSA key to [/etc/tinc/hosts/SedeA]:
Appending key to existing contents.
Make sure only one key is stored in the file.


Ahora configuramos el interfaz tun0. Tinc llamará al script “/etc/tinc/tinc-up” al arrancar:

#!/bin/sh
ifconfig $INTERFACE 192.168.1.1 netmask 255.255.0.0


Marcamos el fichero como ejecutable:

# chmod +x /etc/tinc/tinc-up


Repetimos el proceso con las otras dos sedes, y como paso final, intercambiamos los ficheros SedeA, SedeB y SedeC entre todos los nodos, para que todos ellos se conozcan entre sí.

Finalmente, ejecutamos el demonio:

tincd


O si queremos depurar algun problema, lo ejecutamos con depuración y sin desconectarse de la consola:

tincd -d5 -D


Si todo va bien, desde cualquier equipo de la red podremos hacer ping a cualquier otro, aunque sea de otra sede:

Suerte.

Julián J. Menéndez

Actualización 08-09-2007: La versión de tinc en el respositorio ipkg de openwrt es la 1.0.4. La versión a día de hoy es la 1.0.8. Podéis encontrar el paquete para esta versión aquí: http://augsburg.freifunk.net/ipkg/

En una red local, no hay gran problema… cualquier red que se precie usa cable CAT5 y switches 10/100… más que de sobra como para que afecte ese extra de paquetes circulando. Sin embargo, cuando tenemos un asterisk en una sede, y varios teléfonos SIP en otra sede distinta (conectados mediante ADSL, por ejemplo), la cosa cambia.

El ancho de banda de una ADSL es asimétrico, y aunque tengamos 3 “megas” de bajada, la subida no suele pasar de unos míseros 320kbs (bits, no bytes). De ahi que sea un recurso muy valioso, como para malgastarlo cuando no es realmente necesario. Con este ancho de banda, podemos mantener unas 10 conversaciones con el códec G729, y unas 3 con G711. (Usando esta calculadora de ancho de banda)

Un caso típico

Imaginemos el siguiente escenario:

• Un servidor asterisk en la sede central
• Teléfonos SIP en la sede A (A1,A2,A3..An). Todos ellos configurados con nat=yes.
• Otros tantos en la sede B (B1..Bn).También con nat=yes.
• En ninguna de las dos sedes se abren puertos hacia los diferentes teléfonos.

Si impedimos el tráfico de paquetes de voz (RTP) directo entre teléfonos (canreinvite=no), al hacer una llamada interna, desde A1 a A2, habría dos flujos de paquetes:

1. Desde A1 hasta el servidor asterisk, y desde aquí de vuelta a A2
2. Justo el camino contrario, ya que la comunicación es full-duplex.

Fíjemonos que para una simple conversación entre extensiones, estamos utilizando nuestra conexión ADSL por partida doble. Estamos utilizando 2 de las llamadas simultáneas disponibles con nuestra humilde conexión a internet.

En una llamada desde A1 a B1 pasaría lo mismo, salvo que en este caso es lo que esperamos. A1 y B1 están en sedes distintas, y no hay forma de que se pueda establecer una comunicación directa entre ambos dispositivos. Lo que queremos es que asterisk haga de enlace entre ambos. Cada sede estará gastando un canal de los que tenga disponible.

Queremos evitar este consumo innecesario de ancho de banda cuando los dos teléfonos pueden establecer una comunicación RTP directa. Para ello, activaremos “canreinvite=yes” en la configuración de todos los dispositivos. Repetimos el experimento.

Llamamos desde A1 a A2. Asterisk, que hace de intermediario, indica a A1 que envíe su tráfico RTP a la dirección de A2, y hace lo propio con A2. Las direcciones IP utilizadas son las IP’s locales de cada teléfono (192.168.0.x, por ejemplo), y no la IP pública de la ADSL de la sede.

El beneficio es palpable, mientras asterisk se encarga de la señalización (indicando cuando un teléfono cuelga, cuando se hace una transferencia, etc), el tráfico RTP de voz va directamente de un teléfono a otro, sin salir a Internet en ningún momento, y sin gastar ningún canal.

Pero todo tiene un “pero”. Al hacer una llamada desde A1 a B1, asterisk también indicará a los dispositivos que se envíen el tráfico RTP directamente entre ellos. El problema está en que, al utilizar las IP’s privadas y ser dos redes distintas, separadas, que podrían incluso compartir la misma dirección de red, la llamada se establecerá pero no habrá audio en ningún sentido. Mal asunto.

¿Por qué? En la actualidad, cuando ambos dispositivos están configurados con “canreinvite=yes”, asterisk obedece y siempre que puede intenta que se envíen el tráfico RTP entre ellos directamente. Lamentablemente, cuando están en redes distintas, es imposible. La solución estaría en comprobar, cuando los dispositivos están detrás de routers haciendo NAT, si la dirección IP pública de ambos coincide. Si fuese el caso, podremos estar seguros de que están en la misma red, y podrán encontrarse. Si la IP pública es diferente, asterisk simplemente debe quedarse en medio.

Las llamadas dentro de cada sede funcionarán bien, sin malgastar ancho de banda de la ADSL, mientras que las llamadas entre sedes pasaran a través de asterisk.

Una solución

Y después de esta soberana paliza (que no se cuántos habréis aguantado), os dejo aquí el parche para la revisión r79171 del svn de asterisk/branches/1.4.

Descargar asterisk_nat_rtp_recv_patch_v3.diff

Para aplicar

$ cd /usr/src/asterisk
$ patch -p0 < /ruta/a/asterisk_nat_rtp_recv_patch_v3.diff
$ make
$ make install

Añadimos natonlyreinvitesameip=yes a la sección [general] de nuestro sip.conf.

No he podido testear a fondo este parche, así que si alguien puede reproducir este escenario, agradecería comentarios sobre si funciona o si es una soberana estupidez

De hecho, en la versión 0.27, ha incluido un nuevo control flash (comunicator.swf), que elimina la parte gráfica, y se convierte en un simple interfaz entre nuestro asterisk y el código javascript de nuestra página. Este control es ideal para integrar en aplicaciones CRM (Customer Relationship Management), como puede ser SugarCRM.

Lo que voy a mostrar en este post son los requisitos mínimos para que esto funcione. Voy a eliminar todo lo superfluo, de modo que sea más fácil de integrar con cualquier aplicación ya existente, que es lo que de verdad nos dará la utilidad a este sistema.

Instalar/Actualizar FOP a la versión 0.27

La última versión de FreePBX ya incorpora esta versión. Si no está instalada, tendremos que descargarnosla de http://www.asternic.org/, y reemplazar los siguientes ficheros:

• op_server.pl
• operator_panel.swf
• op_lang*

Tendremos que añadir unas líneas a op_buttons.cfg:

[AUTO/SIP/.*]
Context =${CONTEXT}
Extension=${CHANNEL}
Label =${CHANNEL}
Icon =1
Starting_Position=1
Server=1
Panel_Context=popup

Con esto crearemos un nuevo contexto (popup) para nuestro monitor de extensiones.
También añadiremos las siguientes líneas a op_server.cfg

[popup]
flash_dir=/var/www/html/popuptest/

De forma que nos guarde en ese directorio un fichero (variablesPOPUP.txt) con la información sobre nuestras extensiones.

Instalar los scripts

Creamos el directorio /var/www/html/popuptest y descomprimimos en él el siguiente fichero: popup-sample-v1.tgz

mkdir /var/www/html/popuptest
cd /var/www/html/popuptest
tar -zxvf /ruta/al/fichero/popup-sample-v1.tgz

Abrimos el navegador, y nos vamos a http://1.2.3.4/popuptest (sustituir 1.2.3.4 por la IP de vuestra máquina). Nos pide la extensión a monitorizar. En la siguiente página, si hacemos o recibimos llamadas en esa extensión, debería actualizarse en tiempo real su estado.

Si, además, queremos que en las llamadas entrantes se nos abra un popup a otra página, que nos haga por ejemplo una búsqueda en una base de datos, editamos el fichero monitor.php y definimos la variable popupurl:

var popupurl=null; //Si esta null, no haremos popup
popupurl="http://192.168.0.1/buscarnumero/find.php?q=";

Recargamos la página, y probamos a recibir una llamada. Si todo ha ido bien, y el navegador permite el popup, debería abrirnos la dirección http://192.168.0.1/buscarnumero/find.php?q=XXXXX, siendo XXXXX el número de teléfono que nos llama.

Conclusion

He intentado reducir el ejemplo a su mínima expresión, para que sea más sencillo adaptarlo a una aplicación real. La versión completa está en los fuentes del FOP. Revisad el fichero js/operator.js, porque ahí está el meollo de la cuestión

Saludos
Julián J. Menéndez

En un intento de no despistar a los que vienen desde los buscadores (que sois unos cuantos), el parche actualizado estará disponible en el post anterior, Nuevo parche polaridad para Asterisk 1.4

Volvemos a la carga. Desde que actualizar a la 1.4.x he notado que en ocasiones las llamadas entrantes que colgaban mientras estaban en cola, llegaban a sonar en los teléfonos. Pasaba pocas veces, quizás recibo pocas llamadas ;), pero después de recibir correos apuntando en la misma dirección, me dispuse a revisar el amado y odiado chan_zap.c. (Por cierto, en openpbx^H^H^H^H^H callweaver lo están reescribiendo desde 0)Resulta que se revirtieron algunos cambios necesarios para que funcione bien en las líneas de Telefónica de España. Las llamadas entrantes, una vez que se descuelgan con Answer(), no detectan el cuelgue remoto. No ocurría lo mismo con las llamadas que no se han contestado aún.

En cualquier caso, aquí os dejo el parche. Si va bien, lo intentaremos meter de nuevo en el svn ;)Parche chan_zap.c rama 1.4 version4

Descargar chan_zap.c-1.4-polarity-v5.diff

Para aplicarlo:

$ cd /usr/src/asterisk$ patch -p0 < /ruta/al/chan_zap.c-1.4-polarity-v5.diff

A continuación, recompilar, reinstalar y reiniciar asterisk, probar si funciona, y dejar un comentario

Versiones anteriores:

• chan_zap.c-1.4-polarity-v1.diff
• chan_zap.c-1.4-polarity-v2.diff
• chan_zap.c-1.4-polarity-v3.diff
• chan_zap.c-1.4-polarity-v4.diff

Actualizado (5 horas después de la publicación) : Como casi siempre, las primeras versiones nunca fueron buenas… Al corregir este fallo, introduje otro con las llamadas salientes… Corregido en la versión 2 del parche.

Actualización (12 de mayo): Según confirme Jose L. Villalon en los comentarios, el parche también funciona con asterisk 1.2.18. Habrá que ver a partir de qué versión de asterisk es necesario parchear.

Actualización (25 de junio): Gracias a SuD, que nos comenta acerca de un parámetro, polarityonanswerdelay, que tiene un valor por defecto demasiado alto, y que podría traer problemas al ignorarse ciertos cambios de polaridad. Para resultados óptimos, añadir polarityonanswerdelay=1 a vuestro zapata.conf (antes de la línea channel=> correspondiente).

Actualización (29 de junio): Adaptado a asterisk svn r72609. No se pierden los valores de answeronpolarityswitch, hanguponpolarityswitch ni polarityonanswerdelay al hacer un reload. Se contenmpla la detección de colgado dentro de la rutina de detección de callerid, según parche proporcionado por SuD.

Actualización (19 de julio): Adaptado a asterisk svn r75893.

Actualización (20 de julio): He abierto el bug #10238 en bugs.digium.com, para intentar que incluyan este parche en el código de asterisk y no tener que parchear cada nueva versión. Si estás interesado, deja allí tu experiencia con el parche.

Hace ya mucho tiempo que soy un escéptico en cuestiones de telefonía, y siempre desconfío… siempre hay trampa. Ayer “escuchando” la tele, oigo que movistar saca un nuevo plan de datos, al estilo Yoigo, en el que solo pagas 1€ al día, y sólo si te conectas. La verdad es que en el momento me hizo ilusión, poder tener una conexión de banda ancha cuando estoy fuera de casa (Yoigo es solo GPRS en Fuerteventura). Así que me dispongo a llamar a atención al cliente, y después de sonsacar a la operadora, que parece que no quería darme cifras concretas, me dice que la tarifa es 1€ por cada 10Mb, con un máximo de 10€ diarios.

Coño, de 1€ a 10€ diarios, hay una diferencia importante… tanta como que pasamos de 30€ a 300€ mensuales, si le damos un uso importante.

Y sí, en la web de movistar, después de profundizar un poco, te dan las condiciones reales, pero viendo esto, ¿qué pensaríais? Por si quitan ese anuncio, esto es lo que dice, literalmente:

Nueva tarifa diaria Internet Móvil

Conéctate donde quieras por 1€ al día.
Y si no te conectas, no pagas.

Vodafone, Orange, Yoigo… no sé cuál, pero la portabilidad está cerca.

Actualizacion 5 de junio de 2007: Parece que no soy el único que piensa igual

Una llamada en RDSI es una comunicación de datos 64kbps full duplex, es decir, 8Kb/s en cada sentido, e independientes, utilizando el codec G711a. O funciona, o no funciona, pero no produce eco por que se mezcle el canal de ida con el de vuelta. Así que realmente da lo mismo qué tarjeta RDSI utilices, si funcionan las llamadas de voz, tendrás exactamente el mismo tipo de eco, tengas una HFC de 1 puerto, o una OctoBRI. Ojo, que no hablo de tarjetas activas, con su DSP y demás florituras, sino de Billions y AVM Fritz! y similares. Continúa:

(more…)

De cualquier modo, no era una situación sostenible, ya que era bastante molesto. Buscando un poquillo en google y voip-info.org (para variar), me encontré con esta página sobre fxotune http://www.voip-info.org/wiki/view/Asterisk+fxotune. Copio y pego:

fxotune optimizes the line characteristics of a TDM device to minimize the *source* of echo. This is generally referred to as ‘balancing the hybrid’ and is quite important in echo cancellation. Once the hybrid is properly balanced, software echo cancellers will work very nicely.

No soy teleco, pero ese balanceo del híbrido, viene a ser ajustar la impedancia (resistencia) del puerto FXO, para que coincida con la de la línea, y evitar que se refleje lo menor posible la señal enviada o recibida. Si estoy metiendo la pata hasta el fondo, hacédmelo saber jeje. También ajusta los coeficientes de eco, aunque aquí sí que estoy totalmente perdido.

Por cierto, las clónicas vienen configuradas con una impedancia fija (no configurable) de 600 ohmnios, que está bien para las líneas americanas, no así para las españolas y gran parte de Europa. Si tienes una clónica, no te molestes.
(more…)

Escenario:

• Teléfono IP en 192.168.0.201, registrado directamente en un ITSP (Peoplecall, Azulcom, Telsome, etc, etc)
• Router (Gateway) en 192.168.0.254
• Máqina (linux) desde la que queremos analizar el tráfico: 192.168.0.1

  Necesitaremos tener instalados Ethereal (ahora Wireshark), y Ettercap

Si estos 3 dispositivos estuviesen conectados a un HUB, solo tendríamos que ejecutar:

tshark -i eth0 -w captura.log ip host 192.168.0.201

Luego, ya con calma y desde otra máquina incluso, analizaríamos ese fichero de captura.

En cambio, si estamos en un switch, el tráfico entre el teléfono SIP y el router no “llega” a la máquina línux. En estos casos, una buena solución es el Arp Spoofing (en español), que consiste en engañar a ambos dispositivos, haciendoles creer que somos el otro, y luego reenviando los paquetes.

Es muy sencillo de implementar, con Ettercap. Ejecutamos el siguiente comando en un terminal:

echo 1 > /proc/sys/net/ipv4/ip_forward
ettercap -o -T -P repoison_arp -M arp:remote /192.168.0.254/ /192.168.0.201/

Es importante activar el ip_forward, ya que de otro modo, los paquetes no se reenviarían a su destino original. Mientras se ejecutar el ettercap, todo el tráfico que exista entre esos dos dispositivos, pasará por nuestra máquina, y podremos capturarlo y analizarlo, con el comando que vimos antes (tshark -i eth0….)

Actualización 11-enero-2007: Hay que activar el ip_forward en nuestra máquina, para que nuestro equipo reenvíe los paquetes a su destinatario real.

Algunas pasarelas mail2fax:

• email2fax: Programado en bash. Muy simple. Este fue mi punto de partida.
• AsterFax: Parece muy completo, está escrito en Java. No me gusta el licenciamiento que utilizan. Usan software GPL, pero luego te limitan a una sola línea de fax simultánea… Muy oscuro

Requisitos

• Un subdominio (fax.dominio.com)
• Un servidor Postfix (Se agradecerán las instrucciones para sendmail)
• Hylafax ya instalado y funcionando. Podéis echar un vistazo a esta página para integrarlo con Asterisk
• Paciencia

(more…)