OpenSIPS tiene ya más de 7 años, tiempo en el que ta tecnología ha ido cambiado y han ido surgiendo necesidades y problemas que antes no había. Intuyo que no habrá sido fácil decidir reescribirlo, ya que supone mucho esfuerzo, pero seguramente sea lo mejor para un futuro.

El nuevo diseño se basa en el patrón reactor asíncrono, gracias al cual no habrá problemas de bloqueo entre los procesos de OpenSIPS, algo que actualmente si que puede suceder al hacer operaciones como consultas a BBDD, etc. Además, habrá dos importantes partes: el core y el routing engine.

• SIP core: El encargado de realizar el procesamiento de SIP a bajo nivel. Su arquitectura se basa en capas, cada una de las cuales decidirá si tiene que hacerse cargo del mensaje SIP o delegará la tarea a la capa siguiente.

• Routing Engine: Encargado de gestionar la lógica de enrutado a alto nivel.

Otro importante cambio con respecto al diseño actual es la posibilidad de utilizar varios routing engines con un solo core, de manera que cada routing engine implemente un funcionamiento diferente, pero un único core se encargue del procesamiento SIP a bajo nivel.

Hasta ahora, la lógica de OpenSIPS se definía en un fichero cfg en una sintaxis similar a C, pero con el nuevo diseño tendremos dos opciones para definir el funcionamiento de nuestro servidor:

• Librería: La funcionalidad será una o varias capas adicionales del core, por lo que será compilada junto a el y formará parte del mismo ejecutable.
• Aplicación externa: Una aplicación externa será la encargada de realizar las operaciones de rutado comunicándose con el core. Al ser una identidad externa, la lógica podrá escribirse en un lenguaje “de verdad” como Python, de manera que la flexibilidad a la hora de configurar el servidor es la que te ofrezca el lenguaje que escojas. How cool is that?!

Éste post es solo un resumen del documento que podéis ver aquí. Os recomiendo echarle un vistazo, veremos que tal sale la cosa dentro de unos 12 meses.

Si tenéis alguna duda, mañana viernes 5 de Marzo el tema central de la VoIP Users Conference será el diseño de OpenSIPS, y como invitados estarán Bogdan-Andrei Iancu (CEO en Voice-System), Adrian Georgescu (CEO en AG Projects) y Flavio Golcalves (autor de ‘Building Telephony Systems with OpenSIPS 1.6′).

¿Te lo vas a perder?

Por último me gustaría felicitar al equipo de ‘arquitectos’ que ha diseñado el nuevo OpenSIPS: Bogdan Iancu, Anca Vamanu, Andrei Dragus y Dan Pascu, OpenSIPS 2.0, here we go!

Introducción

Interactive Connection Establishment (ICE) define un protocolo de actuación gracias al cual dos dispositivos SIP son capaces de mantener una sesión multimedia salvando todas las dificultades que el NAT pueda poner de por medio. Aún se encuentra en estado de draft (la última es la revisión 19), pero está en la cola para obtener un número de RFC.

ICE permite que los dispositivos involucrados en la sesión SIP prueben distintos medios o rutas para comunicarse entre sí y acuerden uno común. Gracias a ICE es posible que dos terminales que se encuentran en la misma LAN envíen el tráfico RTP de manera local, en lugar de utilizar un relay como MediaProxy o RTPProxy, sin realizar ninguna configuración exótica en el servidor. La inteligencia está en los terminales.

¿Cómo funciona?

ICE es un proceso bastante complejo que consta de 9 pasos que intentaré simplificar aquí. Para obtener una información más completa os recomiendo leeros el draft, que aunque es bastante denso describe el mecanismo completo.

Paso 1: Obtención de candidatos

En éste primer paso el llamante obtiene todos los candidados que pueda para posteriormente añadirlos al SDP. Lo habitual es que disponga de dos tipos de candidatos:

• Host candidates: candidatos que representan tarjetas de red del sistema, incluyendo enlaces VPN etc.
• Server reflexive candidates: candidatos obtenidos al realizar consultas a un servidor STUN. Lo habitual es obtener un único candidato de éste tipo con tu propia dirección IP pública.

Paso 2: Aplicar prioridades

Tras obtener la lista de candidatos se aplican prioridades, de manera que unos candidatos se prefieran frente a otros. Por ejemplo, la especificación indica que un candidato host ha de ser más prioritario que uno de tipo relayed, es decir, se prefiere mandar el audio por la LAN que a través de un servidor externo que encamina nuestro audio, lo cual tiene bastante sentido.

Al finalizar este paso se construye el SDP que será enviado. Veamos un ejemplo:

v=0
o=- 3476345811 3476345811 IN IP4 192.168.99.53
s=sipsimple 0.12.0
c=IN IP4 192.168.99.53
t=0 0
m=audio 60770 RTP/AVP 103 102 9 0 8 117 3 101
a=rtcp:60771 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:3e0cc9fc
a=ice-pwd:19d32c8c
a=candidate:Sc0a86335 1 UDP 1862270975 62.131.6.55 60770 typ srflx raddr 192.168.99.53 rport 48649
a=candidate:Hc0a86335 1 UDP 1694498815 192.168.99.53 48649 typ host
a=candidate:Ha45450a 1 UDP 1694498815 10.69.69.10 48649 typ host
a=candidate:Sc0a86335 2 UDP 1862270974 62.131.6.55 60771 typ srflx raddr 192.168.99.53 rport 48868
a=candidate:Hc0a86335 2 UDP 1694498814 192.168.99.53 48868 typ host
a=candidate:Ha45450a 2 UDP 1694498814 10.69.69.10 48868 typ host
a=sendrecv

Paso 3: Iniciación

En este paso simplemente se envía el INVITE al usuario correspondiente con el SDP creado en el paso 2. SIP atravesará el NAT mediante los mecanismos tradicionales (rport, etc.) por lo que no hay que hacer tratamiento de NAT para el SDP.

Paso 4: Obtención de candidatos (llamado)

Al recibir el INVITE con la oferta en el SDP, el llamado comienza a obtener sus propios candidatos de la misma manera que lo hizo el llamante. Una vez más, lo habitual es obtener candidatos host y server reflexive. Una vez se obtienen los candidatos, se aplican prioridades y se construye el SDP que será enviado.

Paso 5: Información

El llamado responde al INVITE con una respuesta (provisional o definitiva) y en su SDP habrá incluido sus candidatos.

NOTA: Aunque puede tener sentido enviar la respuesta en una respuesta provisional (18X) SIP no especifica como actuar ante la recepción de múltiples respuestas 18X con SDP, por lo que si encima añadimos ICE al asunto lo mas probable es que no podamos establecer la comunicación. En todas las pruebas que he hecho (y han sido muchas) la negociación ICE no lleva más de 2 segundos, por lo que hacerla tras el 200 OK no es un problema IMHO.

Paso 6: Verificación

Cada agente (llamado y llamante) involucrado en la comunación empareja sus candidatos con los candidatos remotos para formar parejas de candidatos. Éstas parejas serán evaluadas por orden de prioridad descendente por el agente controlador. Por simplificar, diremos que el agente controlador siempre el el llamante (esto puede variar, pero en casos bastante peculiares, que creo que añadirían demasiada confusión al tema).

En éste momento ambos agentes comienzan a realizar pruebas de conectividad cada 20ms. Éstas pruebas se llevan a cabo mediante paquetes especiales STUN que contienen binding requests. El agente remoto contestará con la IP y el puerto desde los que ha recibido dicha binding request y así el agente que ha enviado la petición sabrá que el test ha sido satisfactorio y marcará el candidato como válido.

Si uno de los agentes involucrados en la sesión se encuentra tras un NAT simétrico, esto será detectado al ver la diferencia entre el server reflexive candidate publicado y el origen del binding request que mandará. Entonces se crea un nuevo candidato de tipo peer reflexive, que contiene la IP y puerto donde estará el RTP (los test de conectividad de hacen enviando paquetes STUN a los puertos donde posteriormente habrá RTP). Gracias a esto es posible que un usuario tras NAT simétrico y otro tras un NAT no simétrico hablen entre si con audio de router a router. Increíble, ¿no?

Paso 7: Coordinación

Tras la negociación ambos agentes involucrados en ella han de terminar con un par de candidatos válidos por cada componente. Lo habitual es tener dos componentes por cada stream en el SDP: un componente para el RTP y otro para el RTCP.

El agente controlador (habitualmente el que realiza la llamada) elegirá un candidato. A éste proceso se le llama nominación. Para validar éste candidato se envía otra binding request (STUN) pero en esta ocasión se incluye un flag. Ambos agentes utilizarán el par de candidatos que ha pasado las pruebas de conectividad y que además esté nominado.

Recordemos que todo éste proceso ha sido realizado por los agentes utilizando paquetes STUN entre si, sin ninguna interacción por parte del servidor.

Paso 8: Comunicación

Ahora que ambos agentes saben cómo comunicarse, ya pueden enpezar ha hablar, y tenemos garantizado que habrá audio bidireccional, ya que las pruebas de conectividad se realizan en ambas direcciones.

Paso 9: Confirmación

Aunque toda la negociación ha tenido lugar entre los agentes es posible (y habitual) que haya otros agentes en el medio de la señalización, como por ejemplo proxys. Para que los proxys o las middle-boxes entre el llamado y el llamante estén al tanto de lo sucedido, se enviará un re-INVITE o un UPDATE con el resultado de la negociación en el caso de que el candidato seleccionado no sea el candidato por defecto (las líneas c y m del SDP).

¡Qué way!, esto funciona, ¿no?

Pues, para variar, no. Lo habitual para el tratamiento de NAT consiste en que el proxy modifica el SDP si detecta NAT e indica como origen del RTP y RTCP un servidor que hará las veces de media relay.

Al modificar el SDP, no habrá ningún candidato que corresponda a la IP y puerto de las líneas c y m del SDP, por lo que al recibir un INVITE así el otro extremo nos responderá con ésto en su SDP: a=ice-missmatch. Mal tema. ¡Hay que solucionarlo!

“Arreglando” la negociación ICE con OpenSIPS y MediaProxy

Para solucionar éste problema ha sido necesario modificar OpenSIPS y MediaProxy (los componentes con los que trabajo actualmente, pero lo mismo puede hacerse para Kamailio/SIP-Router y RTPProxy).

Resumiendo un poco (tenéis una explicación más completa aquí) lo que sucederá es que OpenSIPS añadirá un nuevo candidato de tipo relayed cuando modifique el SDP, de manera que corresponda con la IP y puerto de las líneas c y m. MediaProxy es ahora capaz de “dejar pasar” las pruebas de conectividad STUN, por lo que al modificar el INVITE inicial y su correspondiente respuesta habremos “engañado” a los agente insertando un nuevo candidato.

Mediante un parámetro es posible controlar la prioridad del candidato que OpenSIPS insertará, afectando así al resultado de la negociación.

Ahora sí, ¡funciona! puedo hablar con audio P2P en mi LAN aunque fuerce el uso de MediaProxy, porque al detectar una negociación ICE satisfactoria MediaProxy se “quita de en medio”. También he probado ha hablar con audio de router a router entre un NAT simétrico y otro de tipo port restricted. How f*c*i*g cool is that?

¡Quiero probarlo!

No tan rápido vaquero. Nos falta hablar de el tema más importante: los clientes SIP. Sólo conozco tres (en esencia uno) que implemente ICE correctamente. Y cuando digo correctamente es que me he leído el draft, el código y he probado que funciona Los clientes SIP con soporte ICE (draft versión 19) son PJSIP, SIPSIMPLE client (su core es PJSIP) y Blink (su core es SIPSIMPLE).

Si alguien descubre o está desarrollando un cliente SIP que cumpla la especificación ICE (draft 19) me encantaría probar la interoperabilidad con él.

Actualmente no hay ninguna versión (release) de OpenSIPS que incluya el parche para “solucionar” el problema de ICE, así que podéis parchear manualmente como se menciona aquí o podéis utilizar el servicio gratuito SIP2SIP, que ya dispone de todo lo necesario (parches para OpenSIPS y última versión de MediaProxy).

Conclusiones

Tras estar un mes con éste tema por fin he podido comprobar que funciona. No obstante, es triste ver que hay muy pocas implementaciones de ICE y que solo una funcione. Es cuanto menos sorprendente que softphones de pago de supuesto prestigio digan que soportan ICE y en el SDP se vea claramente no de la manera correcta.

Hay que agradecer a Benny Prijono y el equipo de PJSIP el buen trabajo que han realizado al respecto acudiendo en enumerosas ocasiones al SIPit para mejorar su SIP stack.

¡Joder que largo me ha quedado esto! Para más información podéis leer el draft y echarle un ojo a ésta presentación.

Happy ICE skating!

Para mejorar la duración de la batería en nuestro terminal Android vamos a ver cómo instalar un undervolted kernel en un Nexus One (si dispones de otro terminal Android busca un undervolted kernel adaptado a él).

El concepto de un undervolted kernel es sencillo: consiste en mantener el procesador trabajando a la velocidad original, pero utilizando menos voltaje para ello. Al utilizar menos voltaje, obtendremos una mayor duración de la batería. Esto no es posible con todos los terminales, pero con el Nexus One al menos si, así que ¡vamos a ello!

Necesitamos tener instalada la ROM CyanogenMod 5.0.3.1, y los pasos a seguir son sencillos: descargar el kernel, flashearlo desde fastboot, reiniciar el terminal y habilitar el módulo de WiFi:

wget http://kmobs.scepterr.info/kernels/zImage33UV.zip
unzip zImage33UV.zip -d uvkernel
(reiniciamos el androide en modo fastboot)
./fastboot flash zimage uvkernel/zImage33UV
./fastboot reboot
(una vez ha arrancado normal)
./adb remount
./adb push uvkernel/b*.ko /system/lib/modules
./adb reboot

Happy undervolting!

Hoy os voy a contar un poco como veo el panorama de aplicaciones relacionadas con VoIP en Android, tras llevar jugando unas semanas

SIP

Hay unos cuantos softphones SIP, pero en realidad solo uno es el que vale (hay otros que a su vez son medio-forks de éste): SIPdroid. Se integra perfectamente con la agenda de contactos y funciona en segundo plano. Imprescindible. La calidad de audio es bastante buena (soporta los codecs G711a y G711u) e incluso soporta vídeo en H263 (vale, no es H264, pero ¡funciona!). Como punto negativo, comentar que no dispone de soporte para más de una cuenta SIP, pero el autor comenta que lo añadirá. Cuando lo haga será el softphone SIP definitivo para Android.

Skype

Suponiendo que también consideremos Skype VoIP, es curioso que la aplicación oficial solo soporte chat mientras que Fring y Nimbuzz también soportan voz. Solo he probado Fring, pero el resultado es muy bueno. Funciona en background y la calidad de audio hablando por WiFi es buena. Como algunos sabréis Fring (y creo que Nimbuzz también) soporta SIP, leed el siguiente apartado.

Fring cargando…

Fring permite chat y llamadas de voz

Que aplicaciones NO utilizar

Como he comentado antes, Fring también soporta SIP, pero NO utilicéis Fring con vuestra cuenta SIP. Fring intercepta todas las comunicaciones SIP y las hace pasar por sus servidores para supuestamente ayudar con el NAT. ¿Qué majos eh? A cambio de ese arreglo toda nuestra privacidad es vulnerada además de que el retardo es mayor, dado que nuestra llamada tiene que rebotar en sus servidores.

El combo: ENUMdroid + SIPdroid

Si no has leído el post sobre ENUM ¡corre a leerlo! Bien, ahora que sabes lo que es ENUM vamos a ver una aplicación muy interesante que nos permitirá integrar ENUM con la agenda de contactos y demás aplicaciones: ENUMdroid.

Si por ejemplo llamamos al número Rumano que comenté en el post sobre ENUM se realizará la consulta correspondiente y en un par de segundos nos saldrá una ventana como ésta:

Como veis se muestra toda la información contenida la respuesta ENUM. Al seleccionar las URLs se abrirá el navegador, al pinchar en la URL de geolocalización (es una URL de Google Maps acortada) se abrirá la aplicación Maps con una chincheta en la posición correspondiente y al pinchar en la URI SIP se abrirá SIPdroid y comenzará ha hacer la llamada. Yo a eso lo llamo integración, y me encanta.

Más ENUM

No mola tanto como ENUMdroid (todavía) pero mere la pena mencionar ENUM Discoverer. Tuve la ocasión de presenciar una presentación sobre ésta aplicación en la fiesta anual organizada por la ISOC Holandesa y he de decir que el concepto es bueno, aunque habría que pulirlo un poco. A diferencia de ENUMdroid, ENUM Discoverer funciona en segundo plano haciendo consultas periódicamente y actualizando la agenda de contactos con la información que encuentra. ENUM permite agregar servicios custom como Twitter, Facebook, etc. y ENUM Discoverer permite es capaz de visualizarlos, pero al no ser registros estándar dudo que mucho gente los añada. Por otro lado, ENUM Discoverer no está en el Android Market, es necesario bajarse el apk de la web, y eso echará para atrás a más de uno…

Otras aplicaciones

En la búsqueda también me he encontrado con AsteriskDialer, una aplicación para hacer un simple Originate a través del Manager de Asterisk. Al menos soporta SSL, aunque ¿quién quiere hacer un originate si puedes llamar directamente por SIP?

Interfaz principal

Configuración

Conclusión

Como habréis visto hay bastante con lo que jugar, ¡y encima funciona! así que en general estoy contento, sobre todo por la integración que muestran las aplicaciones. Si me he dejado alguna que consideráis importante dejad un comentario, siempre mola descubrir alguna nueva

Njoy!

PD: Las capturas las he hecho con drocap2, porque hacerlas con el ADB es un coñazo.

DISCLAIMER: No soy un super-mega-experto conocedor de la tecnologia en sí, pero la he utilizado y la entiendo, espero que os sea util

ENUM o tElephone NUMber mapping es un sistema que nos permite utilizar el sistema DNS para hacer consultas en base a numeros de telefono. Ein?! Normalmente hacemos consultas DNS sobre un dominio para saber cual es la IP a la que apunta, su servidor de correo, o si usa SRV hasta cual es su servidor SIP. Con ENUM hacemos la consulta DNS (de tipo NAPTR) en base a un numero de telefono y podremos obtener informacion como una URI SIP, información de geolocalización, blog, twitter, … Lo interesante es que podemos obtener una URI SIP a la que podemos llamar en lugar de al número, por lo que el coste de la llamada quedaría reducido a 0. How cool is that?

Como siempre que hay algo gratis involucrado, surgen los problemas: ¿quién llena las bases de datos ENUM? ¿está la gente interesada? ¿y las grandes telcos? Seguramente el principal problema de la no expansion de ENUM sea que es un servicio que no se puede cobrar, por lo que es algo que se hace pero que no retorna un beneficio ni inmediato ni directo. Por otro lado, para poder introducir tus datos en ENUM es necesario contactar con la autoridad responsable y demostrar que tal número es tuyo. El proceso implica demostrar mediante facturas, etc. que eres el usuario de dicho número, pero esto no es como darte de alta en Twitter, y la gente no suele querer perder el tiempo… Ademas, las grandes operadoras obviamente no quieren que la gente use ENUM, porque entonces no facturarias las llamadas que gracias a ENUM se hacen por SIP.

¿Entonces quién usa ENUM? ENUM tiene un árbol publico (e164.arpa) pero nadie te impide tener tu propio árbol ENUM privado, por lo que es posible utilizar ENUM internamente dentro de un ITSP por ejemplo, de manera que antes de sacar la llamada de un cliente a PSTN podemos consultar en ENUM si la llamada es para otro usuario de nuestra red, y enrutarla a coste 0 (esto se puede hacer de muchas maneras, ENUM es una de ellas).

Bueno, tras la brasa inicial vamos a ver si algo de lo que he dicho es verdad. Para ello vamos a ver un ejemplo real, con el siguiente numero: +40317105163. Se trata de un DID de Rumania que apunta a la cuenta SIP de mi trabajo asi que absteneos de intentar venderme viagra a las 4 de la mañana Para ver qué información tiene asociado ese número de telefono haremos una consulta DNS de tipo NAPTR al arbol e164.arpa:

Como se puede apreciar en la imagen la consulta devuelve 4 resultados: una URI SIP, dos direcciones web y una dirección de geolocalización. Al parecer esto del ENUM no es del todo mentira

El Capitán Obvio me ha dicho que esto no tiene sentido a menos que la gente introduzca ahí su número, y claro está que no es algo que muchos particulares estén dispuestos a hacer, pero para empresas, y mas concretamente las del sector de las comunicaciones y/o VoIP podria resultar interesante (en realidad para los que les llaman).

En el siguiente post comentaré que utilidad podemos darle a ENUM desde un móvil con Android, stay tuned!

Unos links de interés:

http://es.wikitel.info/wiki/Enum
http://en.wikipedia.org/wiki/Enum

http://www.e164.org/
https://secure.dns-hosting.info/enum_lookup.phtml

Hoy haremos el Nexus One un poco menos “aburrido” El Market tiene muchas aplicaciones, sí, pero no somos root, no podemos hacer tethering, ni tener OpenVPN… ¡asi que toca flashear!

Para poder tener una mayor libertado sobre nuestro terminal y poder flashear cualquier ROM primero flashearemos una recovery image, de manera que podamos hacer una copia de seguridad de todo el firmware y jugar sobre seguro. El asunto es que para poder instalar esta recovery image será necesario desbloquear el bootloader, algo que invalida la garantía, así que si no os importa ese pequeño detalle seguimos adelante.

En este post haremos lo siguiente: desbloquear el bootloader, flasear la ROM CyanogenMod 5.0 beta3 y por ultimo flashear una nueva imagen del kernel que permite direccionar más RAM, de manera que el terminal se movera mas ‘fresco’. No será necesario hacer nada especial para hacernos root en el terminal, ya que la ROM que vamos a instalar ya lo trae de serie. ¡Vamos al lio!

Descargar el software necesario

• Fastboot
• Recovery Image
• ROM CyanogenMod 5.0 beta3
• Aplicaciones de Google
• Kernel 2.6.29.6-highmem

Desbloquear el bootloader

Con el terminal apagado, mantenemos pulsado el trackball y pulsamos el boton de encendido para entrar en el menu del bootloader. Una vez alli utilizaremos la herramienta fastboot para desbloquear el bootloader:

./fastboot-linux oem unlock

Al ejecutar el comando nos saldra una ventana advirtiendonos de las consecuencias. El Capitán Obvio nos ordena que aceptemos.

El zip de fastboot tambien contiene los binarios para Windows y Mac, usad el que corresponda.

Instalar el Recovery Image

Flasheamos la imagen de recovery con fastboot (tenemos que estar en el menu del bootloader igual que antes):

./fastboot-linux devices (nos aseguramos de que nuestro androide es detectado)
./fastboot-linux flash recovery recovery-RA-nexus-v1.5.3.img

Instalar la ROM CyanogenMod 5.0 beta3

Primero tenemos que copiar los ficheros zip de la ROM de Cyanogen y las aplicaciones de Google a la raiz de la tarjeta SD.

Llegado este punto lo mejor es hacer un backup completo del terminal, seleccionando la opción “Nand backup”.

Antes de proceder a flashear nada es necesario que hagamos un wipe del terminal (al loro, que se borra TODO). Para ello iniciamos el terminal en el menu del bootloader y seleccionamos la opción recovery y luego “Wipe data/factory reset”.

Una vez hecho el wipe podemos proseguir a flashear, primero la ROM de Cyanogen y luego las aplicaciones de Google. Para ello utilizaremos la opción “Flash zip from sdcard”.

¡Más RAM por favor!

El Nexus One tiene mucha RAM, pero nunca hay demasiada RAM asi que vamos a instalar un nuevo kernel con soporte para direccionar más memoria, de manera que podamos tener más aplicaciones abiertas simultánemente sin que se nos ralentice el sistema.

./fastboot-linux flash zimage zImage-2.6.29.6-highmem

Yo he notado muchísima diferencia, así que os lo recomiendo.

Bueno, esto es todo por hoy, en el proximo post hablaremos de VoIP en Android, stay tuned!

Fuentes:

http://android.modaco.com/content/google-nexus-one-nexusone-modaco-com/299241/05-jan-1-5-3-ra-nexus-recovery-image/
http://android.modaco.com/content/google-nexus-one-nexusone-modaco-com/299078/how-to-unlock-the-bootloader-on-your-nexus-one/
http://n0rp.chemlab.org/android/nexus/testing/
http://forum.xda-developers.com/showthread.php?t=623496

Como no podía ser de otra manera Asterisk no soporta parallel forking, pero veremos más delante cómo algo tiene que decir en el tema del post.

En el diagrama de abajo podéis ver el flujo SIP de una llamada de Alice a Bob a través de un proxy (las respuestas provisionales se han omitido para simplificar):

Bob se encuentra registrado en 2 ubicaciones, por lo que los dos terminales comienzan a sonar. Bob contesta en la oficina, por lo que el proxy genera un CANCEL al INVITE que va a casa, para que el terminal deje de sonar. Hasta aquí todo va bien, pero al volver a casa Bob verá que tiene X llamadas perdidas, llamadas que en realidad ha atendido desde la oficina. ¿Cómo solucionamos esto? ¡El RFC3326 viene al rescate!

E RFC3326 define una nueva cabecera para el método CANCEL: “Reason”. Mediante esta cabecera podemos indicar al terminal la causa de la cancelación:

Reason: SIP ;cause=200 ;text="Call completed elsewhere"

De esta manera el terminal puede saber si el CANCEL ha sido debido a que el llamante ha decidido cancelar la llamada o si ha sido el proxy el que ha generado el CANCEL porque la llamada ha sido contestada en otra ubicación. ¿A que mola?

OpenSIPS añade esta cabecera a los CANCEL que genera desde la versión 1.6 y Kamailio si no lo hace ya lo hará pronto (he visto esta feature request propuesta por un tal ibc ). Sorprendentemente ¡Asterisk también soporta esto! Es decir, si haces un Dial(SIP/saghul&SIP/manwe&SIP/ibc) los CANCEL generados para los que no cojan la llamada tendrán esta cabecera presente. Es el parallel forking de los pobres, pero mola que Asterisk lo soporte.

¿Cual es el problema entonces? Pues que los fabricantes no implementan este RFC, que tiene 8 páginas, ¡8 jodidas páginas! Por lo que veo Snom es el único que lo soporta desde su versión 7 del firmware, así que si alguien lo prueba que me lo comente pliz Y si encontráis otro terminal que lo implemente ¡comentad también!

Sin la implementación de este RFC el parallel forking pierde todo el carisma e incluso puede que gente lo vea como algo molesto. Por lo que a mi respecta voy a implementar el soporte para esto en cierto softphone, pero manda huevos que mi Cisco 7960 de Jack Bauer no lo haga…

Proceso de compra

Un 10 para Google. Hice el pedido un domingo por la tarde y el martes a las 9 de la mañana ya tenía el jueguete. Puedes seguir vía web por dónde va tu paquete, joder ¡solo falta el DNI de las personas que lo manipulan! ¡Y encima con mi nombre inscrito detrás! Me lo trajeron sin problemas al hotel, así que si váis de viaje a Estados Unidos por más de dos días no dudéis ni un segundo

Unboxing y primer contacto

Al abrir la caja te encuentras con un embalaje bastante similar el iPhone, sencillo, sin manual. Cuando te compras un Nokia u otro móvil te viene con un super-manual de 100 páginas que no se lee nadie. Cuando te compras un iPhone o un Nexus One no viene manual. Porque no hace falta. Es tan fácil de usar que no necesitas manual, y eso aunque a alguno le parezca un bug es  una feature.

El feeling del terminal es muy bueno: no pesa, parece consistente y robusto… pero le falta algo. Es dificil de explicar, pero podría decirse que veo el Nexus One como diseñado por un ingeniero mientras que el iPhone esta diseñado por alguien con más arte, por decirlo de alguna manera. No obstante, no echarás de menos tu iPhone, créeme.

Pantalla

Aunque la pantalla del N1 es solo 0,2 pulgadas más grande que la de el iPhone da la sensación de ser mucho más grande. Las fuentes son muy claras (de hecho es la que uso en mi desktop, ttf-droid) y se puede visualizar mucha más información que en el iPhone. Parece como si tuviera el doble de resolución o algo. :-O

Aplicaciones

Queridos señores de Apple, más vale que el iPhone OS 4.0 tenga multi-tasking, porque sino… El hardware del N1 es muy potente (procesador a 1GHz y 512MB de RAM) por lo que puedes tener muchas aplicaciones abiertas a la vez y ni te enteras. Personalmente siempre tengo un softphone SIP y un cliente de Jabber funcionando, y no tiene sentido abrir las aplicaciones solo cuando tu quieras hacer una llamada o mandar un mensaje, tienes que poder recibir llamadas…

“Apertura”

Vale, el iPhone funciona con un sistema operativo propietario y el N1 con uno libre, pero me he encontrado con las mismas trabas en ambos casos: si quieres hacer cosas diferentes con tu N1 tienes que ser root, y para eso tienes que realizar un proceso (habrá otro post ) que invalida la garantía. Lo mismo que hacer el famoso jailbreak, así que no por utilizar un sistema operativo libre tienes todo el control sobre el terminal… ¿got root?

Concluyendo…

No os rallo más, pero si tenéis la oportunidad de haceros con uno (566$ libre) cogedlo, además ¡ser un early adopter siempre mola! He dejado unas fotos aquí en Flickr.

Todos los viernes a las 18:00 (hora de Bilbo) tiene lugar el VUC. Consiste en una conferencia de audio a la que cualquiera se puede unir. Esta multiconferencia la dirige Randy Resnick (al que tuve ocasion de conocer en el AMOOCON) y obviamente trata de VoIP. Cada día hay algun invitado que habla sobre un tema en concreto, por ejemplo hoy Alex Balashov ha hablado sobre Kamailio/OpenSER.

Tras una hora de conversación con en invitado (cualquiera puede participar haciendo preguntas u aportaciones) da comienzo la parte mas distendida en la que la gente simplemente comenta temas de actualidad relacionados con VoIP, como eventos, nuevos productos, etc.

La conferencia se hospeda en el servicio ZipDx y es posible unirse mediante SIP, Skype o la PSTN. Aunque la hora no es la mejor del mundo, os recomiendo que os paséis por allí un dia, siempre se comenta algo interesante y se pasa un rato entretenido escuchando o hablando sobre VoIP. Además de por VoIP, tambien mola conectarse al canal de IRC del VUC (#vuc) ya que alli tiene lugar una conversación paralela en la que la gente comenta lo hablado en la conferencia o simplemente chatea sobre VoIP.

La duración es indeterminada, de hecho el record esta en ¡8 horas! Así que si os encontráis aburridos un viernes por la tarde conectaos al VUC!

Antes de ponernos manos a la obra un poco de teoria rápida. Todo el mundo parece saber que necesitas tener una tarjeta o el driver dummy de DAHDI en Asterisk, pero no todos saben porque. Asterisk necesita una fuente de timing para lo siguiente:

• Generar el audio saliente. Asterisk utiliza la fuente de tiempo disponible a la hora de enviar los paquetes de audio saliente. En ausencia de una fuente de tiempo fiable Asterisk puede utilizar el audio entrante como referencia, pero si el audio entrante viene con jitter por ejemplo, el saliente tambien lo tendrá, por lo que no es una buena idea ir por la vida sin una fuente fiable de tiempo.
• IAX trunking. El IAX trunking es un método gracias al cual Asterisk puede ahorrarnos algo de ancho de banda en un enlace entre dos servidores ya que si tenemos 10 llamadas entre el servidor A y el servidor B nos ahorramos mandar 9 de las 10 cabeceras. Para que esto funcione correctamente la temporizacion ha de ser precisa, por lo que necesitaremos una fuente fiable de tiempo. ¿Pero quién usa IAX? Esto en realidad no nos interesa.

Alguno pensara que me he olvidado de MeetMe. Pues no. MeetMe necesita DAHDI por otra razón: el motor de conferencias que usa MeetMe se encuentra en DAHDI. Podría decirse que MeetMe es un wrapper de la aplicación de conferencias de DAHDI. Por lo tanto, MeetMe siempre dependerá de DAHDI, aunque ya veremos que hay algunas alternativas.

Las mejoras de Asterisk 1.6.2 en cuanto a timing

Asterisk dispone de un API genérico de timing desde la version 1.6.1. La idea es disponer de diversos módulos que provean a Asterisk de una fuente de tiempo fiable, siendo DAHDI un simple módulo más. En Asterisk 1.6.2 tenemos lo siguiente módulos de timing:

• res_timing_dahdi (desde Asterisk 1.6.1): Utiliza DAHDI como fuente de tiempo. Si no tenemos tarjetas podemos utilizar este módulo junto a dahdi_dummy para tener timing fiable.
• res_timing_pthread (desde Asterisk 1.6.1): Utiliza la librería POSIX pthread para obtener el timing. Su rendimiento no es el tan bueno como el de DAHDI, pero tiene una ventaja importante: es portable. Con ésta fuente de tiempo es posible utilizar IAX trunking en FreeBSD o MacOSX por ejemplo. How cool is that?!
• res_timing_timerfd (nuevo en Asterisk 1.6.2): Éste es el bueno. Utiliza TimerFD, un nuevo mecanismo del Kernel de Linux (>= 2.6.27) para proporcionar timing. También necesita de una version reciente de glibc (>= 2.8) pero a cambio nos ofrece una fuente de tiempo muy fiable y sin DAHDI. dahdi_dummy, te quedan dos telediarios.

Sustituyendo MeetMe

Hasta ahora he comentado el nuevo API de timing, pero no hemos solucionado el que MeetMe dependa de DAHDI. Obviamente no podemos utilizar MeetMe así que tenemos un par de alternativas:

• AppKonference: Digamos que es un MeetMe con esteroides. Soporta VAD y video y no necesita DAHDI. El único problema (si es que lo consideramos un problema) es que no es una aplicación oficial.
• ConfBridge: Se trata de una nueva aplicación que incluye Asterisk 1.6.2 perteneciente al nuevo API de bridging. No he hecho unas pruebas demasiado intensas, pero de momento no he tenido problemas.

Habilitar el timing interno

Para terminar, tenemos que habilitar el timing interno en Asterisk. Para ello editamos el fichero asterisk.conf y descomentamos la opción internal_timing=yes de la sección [opcions].

Esto es todo por hoy, es una buena excusa para probar Asterisk 1.6 ¿no?