Hola, casualmente he encontrado este texto en la web en construcción de B2BUA de Sippy Software: http://www.b2bua.org/wiki/B2BUADocumentation
-------------------------------------------------------------------------------------------------- Can the Sippy B2BUA determine if one of the peer in a session gone without a BYE message (eg. disconnected the network interface) and then send a BYE message to the other peer?
Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives), and another one is by monitoring state of the RTP session in the proxy. The first one is already supported by the B2BUA. --------------------------------------------------------------------------------------------------
¿Y no es posible esto con OpenSer? sería una funcionalidad muy interesante para el módulo "dialog", y tal vez para otros posibles módulos que en un futuro podrían depender de "dialog".
¿O es una idea feliz fruto de haber dormido poco?
Hola,
Hola, casualmente he encontrado este texto en la web en construcción de B2BUA de Sippy Software: http://www.b2bua.org/wiki/B2BUADocumentation
Can the Sippy B2BUA determine if one of the peer in a session gone without a BYE message (eg. disconnected the network interface) and then send a BYE message to the other peer?
Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives), and another one is by monitoring state of the RTP session in the proxy. The first one is already supported by the B2BUA.
¿Y no es posible esto con OpenSer? sería una funcionalidad muy interesante para el módulo "dialog", y tal vez para otros posibles módulos que en un futuro podrían depender de "dialog".
¿O es una idea feliz fruto de haber dormido poco?
Es una idea muy feliz :)
Hay otra opción para monitorizar el estado de un diálogo y es enviar un OPTIONS in-dialog. Si el díalogo al que está destinado el OPTIONS existe, el destinatario del OPTIONS tiene que responder con un 200. Si el díalogo no existe, responde con un 404.
Una cuarta opción, usada por los gateways Cisco, es que si durante varios segundos no te llega RTCP, consideras que la llamada se ha caído y envías un BYE.
Para la 1.3 se están haciendo varias cosas con el módulo dialog como poder terminar una transacción (BYE) desde el proxy y cosas así. De todas formas, eso es tender cada vez más a opciones de b2bua y no se si hay mucha disposición en los desarrolladores para seguir por ese camino.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Hola,
Hola, casualmente he encontrado este texto en la web en construcción de B2BUA de Sippy Software: http://www.b2bua.org/wiki/B2BUADocumentation
Can the Sippy B2BUA determine if one of the peer in a session gone without a BYE message (eg. disconnected the network interface) and then send a BYE message to the other peer?
Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives), and another one is by monitoring state of the RTP session in the proxy. The first one is already supported by the B2BUA.
¿Y no es posible esto con OpenSer? sería una funcionalidad muy interesante para el módulo "dialog", y tal vez para otros posibles módulos que en un futuro podrían depender de "dialog".
¿O es una idea feliz fruto de haber dormido poco?
Es una idea muy feliz :)
Hay otra opción para monitorizar el estado de un diálogo y es enviar un OPTIONS in-dialog. Si el díalogo al que está destinado el OPTIONS existe, el destinatario del OPTIONS tiene que responder con un 200. Si el díalogo no existe, responde con un 404.
Vaya, así que he aquí una utilidad para los OPTIONS in-dialog. Qué buena :)
Una cuarta opción, usada por los gateways Cisco, es que si durante varios segundos no te llega RTCP, consideras que la llamada se ha caído y envías un BYE.
Sí, pero en el caso del B2BUA que comento no se puede porque no sirve para pasar el RTP (ni tampoco es lo que yo necesitaba).
Para la 1.3 se están haciendo varias cosas con el módulo dialog como poder terminar una transacción (BYE) desde el proxy y cosas así. De todas formas, eso es tender cada vez más a opciones de b2bua y no se si hay mucha disposición en los desarrolladores para seguir por ese camino.
Ok, entendido.
Gracias.
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives),
Ahora que lo pienso, ¿no es un poco bestia que un proxy tenga que enviar re-INVITEs para comprobar el diálogo? quiero decir: un OPTIONS es algo "inofensivo" pero enviar un INVITE que no fastidie nada supone recordar como había sido el INVITE, tener en cuenta posibles re-INVITES que se hayan hecho los usuarios durante la llamada, etc. ¿no?
Hola Iñaki,
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives),
Ahora que lo pienso, ¿no es un poco bestia que un proxy tenga que enviar re-INVITEs para comprobar el diálogo? quiero decir: un OPTIONS es algo "inofensivo" pero enviar un INVITE que no fastidie nada supone recordar como había sido el INVITE, tener en cuenta posibles re-INVITES que se hayan hecho los usuarios durante la llamada, etc. ¿no?
Así es como funcionan los session-timers:
http://tools.ietf.org/html/rfc4028
http://www.openser.org/docs/modules/1.2.x/sst.html
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Hola Iñaki,
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives),
Ahora que lo pienso, ¿no es un poco bestia que un proxy tenga que enviar re-INVITEs para comprobar el diálogo? quiero decir: un OPTIONS es algo "inofensivo" pero enviar un INVITE que no fastidie nada supone recordar como había sido el INVITE, tener en cuenta posibles re-INVITES que se hayan hecho los usuarios durante la llamada, etc. ¿no?
Así es como funcionan los session-timers:
Pues como siempre gracias por la info.
PD: Ese módulo ya le había leído yo pero se me había olvidado por completo...
Gracias.
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Ahora que lo pienso, ¿no es un poco bestia que un proxy tenga que enviar re-INVITEs para comprobar el diálogo? quiero decir: un OPTIONS es algo "inofensivo" pero enviar un INVITE que no fastidie nada supone recordar como había sido el INVITE, tener en cuenta posibles re-INVITES que se hayan hecho los usuarios durante la llamada, etc. ¿no?
Así es como funcionan los session-timers:
Valeee, entendido.. es mucho mejor usar UPDATE (si el UAS lo soporta) que re-INVITE's porque el re-INVITE implica una oferta y debería replicar todo el SDP igual que estaba y tal.
http://tools.ietf.org/html/rfc4028 - 7.4 :
" A re-INVITE generated to refresh the session is a normal re-INVITE, and an UPDATE generated to refresh a session is a normal UPDATE. If a UAC knows that its peer supports the UPDATE method, it is RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can make this determination if it has seen an Allow header field from its peer with the value 'UPDATE', or through a mid-dialog OPTIONS request. It is RECOMMENDED that the UPDATE request not contain an offer [4], but a re-INVITE SHOULD contain one, even if the details of the session have not changed. In that case, the offer MUST indicate that it has not changed. In the case of SDP, this is accomplished by including the same value for the origin field as did previous SDP messages to its peer. The same is true for an answer exchanged as a result of a session refresh request; if it has not changed, that MUST be indicated. "
Supongo que si estos mensajes los debe enviar el proxy SIP (en caso de que los UAC's no los soportaasen) entiendo que usar re-INVITE significa memoría para recordar cada SDP de cada diálogo vivo, mientras que un UPDATE sería más económico. ¿Es así? Bueno, nada, cuando me acabe de leer ese RFC ya lo sabré XD
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Jesus Rodriguez