Mi Brain-Training Personal

Una de las cool features que SIP soporta desde un principio es el Parallel Forking. La idea es sencilla, podemos tener nuestra cuenta de usuario registrada desde diversas ubicaciones y cuando nos manden un INVITE el proxy se encargará de mandarlo a todas las ubicaciones a la vez, y el que primero conteste la llamada se la queda. De esta manera solo tenemos que gestionar una identidad,en lugar de tener varias cuentas SIP en plan «saghul_laptop» y «saghul_hardphone».

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…