[OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
16 Dec
2007
16 Dec
'07
2:27 p.m.
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
--
Iñaki Baz Castillo
16 Dec
16 Dec
6:49 p.m.
New subject: [OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
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.
--
Iñaki Baz Castillo
17 Dec
17 Dec
10:21 a.m.
New subject: [OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
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?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
11:31 a.m.
New subject: [OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
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.
11:50 a.m.
New subject: [OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
El Monday 17 December 2007 10:31:29 samuel escribió:
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
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,
noon
New subject: [OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
2007/12/17, Iñaki Baz Castillo <ibc(a)in.ilimit.es>es>:
El Monday 17 December 2007 10:31:29 samuel escribió:
los
Exactamente.
Y para el caller, en vez de enviar el exótico 302 "Contact: <http://...>"
lo
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 <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. 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
6214
days inactive
6215
days old
sr-users-es@lists.kamailio.org
5 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
samuel