La versión 1.8 de Asterisk ha aportado nuevas features interesantes, como por ejemplo, CEL, SRTP, soporte para fax, calendarios compartidos, soporte IPv6…
En este caso nos vamos a centrar en una feature simple pero que los clientes que provienen de centralitas comerciales suelen echar en falta. La actualización del CLID en transferencias. Hablamos en todo momento de transferencias atendidas y realizadas mediante REFER-s, es decir, transferencias a través del propio terminal y no a través de las features nativas de Asterisk.
Para que funcione, hay que configurar un par de cosas en sip.conf:
- Si queremos utilizar la cabecera SIP Remote-Party-ID:
sendrpid=yes o sendrpid=rpid (es lo mismo) - Si queremos utilizar la cabecera SIP P-Asserted-Identity:
sendrpid=pai - Obligatoriamente:
directmedia=update
Es necesario configurar directmedia a update (además del sendrpid) para que Asterisk envíe mensajes SIP de tipo UPDATE ya que si envía INVITE-s (re-invites para decir que el audio está en otro punto) recibimos un mensaje 500 (Internal Server Error) por parte del terminal de destino final. Es decir, cuando se hace el REFER Asterisk le envía un INVITE al destino final diciendo que el audio lo tiene él, para acto seguido enviarle otro INVITE (CSeq+1) diciendo que el audio está en otro terminal (PtP audio). A este segundo INVITE es al que el terminal responde con un 500.
Espero que en la siguiente imagen se entienda mejor:
Ahora la captura SIP completa con “directmedia=yes” & “sendrpid=yes” donde:
- Asterisk => 10.10.0.165
- C phone (300) => 10.10.0.142
- B phone (200) => 10.10.0.177
- A phone (100) => 10.10.0.167
Esta vez, la captura SIP completa con Ngrep y “directmedia=update” & “sendrpid=yes/pai” donde:
- Asterisk => 10.10.0.165
- C phone (300) => 10.10.0.142
- B phone (200) => 10.10.0.177
- A phone (100) => 10.10.0.167
No me es posible presentar la captura con una imagen como la superior (el software omnipeek no “ve” los UPDATE-s), así que os dejo unas trazas en los siguientes enlaces:
Traza SIP con sendrpid=yes
Traza SIP con sendrpid=pai
Después de tanta traza SIP, comentar también que no sirve cualquier terminal (o mejor dicho cualquier firmware¿?), tiene que aceptar UPDATEs. Con los Cisco SPA5xx funciona a la perfección. Los Linksys SPA9xx no aceptan Updates y algunos Snom y Aastra tampoco… aunque tampoco me he puesto a jugar demasiado con la configuración de estos últimos.
Como se ha comentado en la entradilla del post, aquí se habla en todo momento de transferencias atendidas. En el caso de transferencias semi-atendidas (xfer->dial->xfer sin haber establecido la segunda llamada) funciona a la perfección en cualquier caso. Me explico, utilicemos audio PtP o no, bien con UPDATEs, bien con INVITEs, Asterisk envía un UPDATE para actualizar los datos de sesión cuando la segunda llamada no ha sido establecida, por lo que el CLID se actualiza sin problemas. Las transferencias ciegas también funcionan correctamente (en la versión 1.8.0 había un Bug que se solucionó más tarde).
Espero haberme explicado bien. Estamos aquí para cualquier duda/sugerencia o corrección.
Un saludo.



Muy buen artículo,
En el VoIP2DAY tuve la oportunidad de hablar con varias personas sobre esta característica, y si bien a algunos no les gustó la idea que no se basara en el estandar que define esta característica (no recuerdo ahora mismo qué RFC era el encargado de modificar el CallerID durante la realización de un canal), Olle Johansson comentó que era la forma (si, bastante chapucera, es cierto) más sencilla de hacer esta característica compatible con la mayoría de los terminales existentes actualmente.
Así que, mientras la gente se decide o no a utilizar Asterisk 1.8, los que seguimos testeándolo nos seguimos sorprendiendo con estas características que bien debían haber estado implementadas hace tiempo.
Excelente artículo información muy útil la verdad. Un saludos
como habilito ipv6 en asterisk 1.8
@ipv6 aquí tienes un buen howto de como habilitar ipv6 en asterisk 1.8, suerte con ello
http://saghul.net/blog/2010/08/05/probando-el-soporte-ipv6-de-asterisk-1-8/
Con polycom IP 330 funciona a la perfección.
Los snom m3 efectivamente no lo recogen.
Muchas gracias por el post, es muy claro.