[OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
Hola, estoy empezando a leer la doc de SipServlets [1] y me he atascado en un ejemplo muy chulo, el de "Call Schedule on Busy or No Answer".
El punto 11 no lo entiendo:
11. The service sends a SIP SUBSCRIBE request to Bob’s SIP UA. This will allow the service to know when Bob becomes available again. 12. Bob’s UA accepts the subscription.
El asunto es que el servidor de aplicaciones previamente, haciendo de B2BUA (aunque entiendo que no es necesario en este caso), había recibido un 486 del destino y lo había transformado en 302 para ofrecer al llamante la historia del formulario web y tal.
Entonces dice que el servidor de aplicaciones envía un SUBSCRIBE para recibir un NOTIFY del llamado cuando éste vuelva a estar disponible.
Me gustaría entender la naturaleza de este SUBSCRIBE ya que el tema de la presencia SIMPLE no está, que yo sepa, nada ligado a la disponibilidad de atender una llamada (depende de la implementación de cada UAS).
Es decir, que un teléfono no tenga líneas disponibles (o tenga "CallWaiting=no") no implica que cuando vuelva a estar disponible publique un nuevo estado de presencia.
De hecho, lo único que he visto que se le medio-parece es el XLite/Eyebeam que envía un PUBLISH ("online/offline" - "On the phone") cuando está en una llamada y al acaba dicha llamada envía un nuevo PUBLISH sin el "On the phone". Pero esto ni siquiera implica que no pueda aceptar llamadas en ese estado (CallWaiting=yes). En cualquier caso el servidor de aplicaciones sólo genera el SUBSCRIBE si había recibido 486 así que en este punto no hay problema.
Mi gran duda es: ¿se puede enviar un SUBSCRIBE a **cualquier** tfno SIP (los clásicos Linksys, Thomson, Snom, softphones...) y que dicho tfno envíe un NOTIFY cuando acepte llamadas? ¿Cómo es el "Event" de ese SUBSCRIBE?
He comprobado que muchos tfnos tienen un "Allow: [...] SUBSCRIBE", pero pensaba que era para el tema del REFER (notificación del resultado de la transferencia) no para el caso que comento.
Gracias por cualquier aclaración sobre esto y un saludo.
PD: No viene al caso, pero ahora que me fijo el "Allow" de un Linksys PAP2 no tiene SUBSCRIBE:
User-Agent: Linksys/PAP2-2.0.12(LS). Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
Sin embargo el REFER funciona perfectamente y esas cosas ¿?¿? (me tendré que leer de nuevo la teoría por si se me ha escapado algo).
[1] http://www.wesip.com/mediawiki/API/sipservlet-1.0-fcs.pdf
El Domingo, 16 de Diciembre de 2007, Iñaki Baz Castillo escribió:
Entonces dice que el servidor de aplicaciones envía un SUBSCRIBE para recibir un NOTIFY del llamado cuando éste vuelva a estar disponible.
Me gustaría entender la naturaleza de este SUBSCRIBE ya que el tema de la presencia SIMPLE no está, que yo sepa, nada ligado a la disponibilidad de atender una llamada (depende de la implementación de cada UAS).
Es decir, que un teléfono no tenga líneas disponibles (o tenga "CallWaiting=no") no implica que cuando vuelva a estar disponible publique un nuevo estado de presencia.
Me corrijo un poco: Obviamente si el servidor de aplicaciones manda un SUBSCRIBE al UA llamado lo que espera es que el UA le envíe un NOTIFY y no que publique (PUBLIHS) su estado.
Pero la duda es la misma: ¿dónde (RFC XXX) está recogido el poder subscribirse a un teléfono y que éste nos diga con un NOTIFY que está disponible para aceptar llamadas?
Y por cierto, otra parte vital del ejemplo de CSBNA es la de que el UAC recibe un 302 con el "Contact" apuntado a una web. ¿Suelen los softphones abrir un navegador web al recibir dicha respuesta? porque apuesto lo que sea a que la mayoría no :(
Saludos.
El Sunday 16 December 2007 13:27:22 Iñaki Baz Castillo escribió:
El asunto es que el servidor de aplicaciones previamente, haciendo de B2BUA (aunque entiendo que no es necesario en este caso), había recibido un 486 del destino y lo había transformado en 302 para ofrecer al llamante la historia del formulario web y tal.
Por cierto, esto lo hace enviando al callee un 302 con: Contact: http://webpage
Bien, esto no funciona en ningún softphone que haya probado, todos ellos hacen un INVITE a: sip:http://webpage (con el consiguiente error de servidor).
Mi pregunta entonces es: ¿Forma esto parte del mundo de la piruleta donde se explican funcionalidades exóticas poniendo como ejemplos cosas que no existen ni están implementadas?
Mi pregunta entonces es: ¿Forma esto parte del mundo de la piruleta donde se explican funcionalidades exóticas poniendo como ejemplos cosas que no existen ni están implementadas?
La teoria estáahí...implementaciones que funcionen..más bien pocas (o
ninguna en este caso). Para realizar la rellamada después de colgar se utiliza el Event dialog-info (mírate RFC 4235) que no he visto ningún teléfono que lo utilize (puede que lo haya, claroestá...). La teoria es que un teléfono se subscriba al estado del dialogo SIP del terminal llamada en caso que éste esté comunicando y cuando reciba que el diálogo se ha terminado, reiniciar el proceso de llamada.
Los teléfonos ponen Allow: SUBSCRIBE porque entienden el mensaje pero tendrías que mirar la cabecer Supported, que es la que indica cúales de los <ingles>Event Packages</ingles> soporta, como por ejemplo el dialog-info que te comentaba en el párrafo anterior.
Espero t sirva d algo, Samuel.
El Monday 17 December 2007 10:31:29 samuel escribió:
Mi pregunta entonces es: ¿Forma esto parte del mundo de la piruleta donde se explican funcionalidades exóticas poniendo como ejemplos cosas que no existen ni están implementadas?
La teoria estáahí...implementaciones que funcionen..más bien pocas (o
ninguna en este caso). Para realizar la rellamada después de colgar se utiliza el Event dialog-info (mírate RFC 4235) que no he visto ningún teléfono que lo utilize (puede que lo haya, claroestá...). La teoria es que un teléfono se subscriba al estado del dialogo SIP del terminal llamada en caso que éste esté comunicando y cuando reciba que el diálogo se ha terminado, reiniciar el proceso de llamada.
Los teléfonos ponen Allow: SUBSCRIBE porque entienden el mensaje pero tendrías que mirar la cabecer Supported, que es la que indica cúales de los <ingles>Event Packages</ingles> soporta, como por ejemplo el dialog-info que te comentaba en el párrafo anterior.
Espero t sirva d algo,
Gracias, me ha sido muy útil.
Al final supongo que lo que se hace para emular estas características es hacerlo a nivel de PBX, o sea, que sea un B2BUA el que en vez de enviar un SUBSCRIBE "dialog-info" al teléfono llamado sencillamente reaccione cuando dicho diálogo que él mantiene como UAC acabe y entonces originar la llamada.
Y para el caller, en vez de enviar el exótico 302 "Contact: http://..." lo que hará es rutar la llamada original a un servicio de media en el que suena una locución "El usuario llamado está ocupado, si desea realizar la llamada automáticamente cuando esté disponible pulse 1", y vía DTMF activar el servicio.
Supongo...
Saludos.
2007/12/17, Iñaki Baz Castillo ibc@in.ilimit.es:
El Monday 17 December 2007 10:31:29 samuel escribió:
Mi pregunta entonces es: ¿Forma esto parte del mundo de la piruleta donde se explican funcionalidades exóticas poniendo como ejemplos cosas que no existen ni están implementadas?
La teoria estáahí...implementaciones que funcionen..más bien pocas (o
ninguna en este caso). Para realizar la rellamada después de colgar se utiliza el Event dialog-info (mírate RFC 4235) que no he visto ningún teléfono que lo utilize (puede que lo haya, claroestá...). La teoria es que un teléfono se subscriba al estado del dialogo SIP del terminal llamada en caso que éste esté comunicando y cuando reciba que el diálogo se ha terminado, reiniciar el proceso de llamada.
Los teléfonos ponen Allow: SUBSCRIBE porque entienden el mensaje pero tendrías que mirar la cabecer Supported, que es la que indica cúales de
los
<ingles>Event Packages</ingles> soporta, como por ejemplo el dialog-info que te comentaba en el párrafo anterior.
Espero t sirva d algo,
Gracias, me ha sido muy útil.
Al final supongo que lo que se hace para emular estas características es hacerlo a nivel de PBX, o sea, que sea un B2BUA el que en vez de enviar un SUBSCRIBE "dialog-info" al teléfono llamado sencillamente reaccione cuando dicho diálogo que él mantiene como UAC acabe y entonces originar la llamada.
Exactamente.
Y para el caller, en vez de enviar el exótico 302 "Contact: http://..." lo
que hará es rutar la llamada original a un servicio de media en el que suena una locución "El usuario llamado está ocupado, si desea realizar la llamada automáticamente cuando esté disponible pulse 1", y vía DTMF activar el servicio.
esto es generalmente configurable dependiendo de la centralita que utilices..
Supongo...
Saludos.
Un saludo, Samuel
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
samuel