30 Aug
2007
30 Aug
'07
5:04 a.m.
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?
--
Iñaki Baz Castillo
30 Aug
30 Aug
9:38 a.m.
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(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
10:07 a.m.
New subject: [OpenSER-Users-ES] ¿Posibilidad de monitorizar estado de diálogos mediante re-INVITE's?
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Hola,
Vaya, así que he aquí una utilidad para los OPTIONS in-dialog. Qué buena :)
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.
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.
--
Iñaki Baz Castillo
10:15 a.m.
New subject: [OpenSER-Users-ES] ¿Posibilidad de monitorizar estado de diálogos mediante re-INVITE's?
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?
--
Iñaki Baz Castillo
11:18 a.m.
Hola Iñaki,
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez
escribió:
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(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> 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?
11:26 a.m.
New subject: [OpenSER-Users-ES] ¿Posibilidad de monitorizar estado de diálogos mediante re-INVITE's?
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Hola Iñaki,
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.
--
Iñaki Baz Castillo
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez
escribió:
Así es como funcionan los session-timers:
http://tools.ietf.org/html/rfc4028
http://www.openser.org/docs/modules/1.2.x/sst.html > 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?
12:56 p.m.
New subject: [OpenSER-Users-ES] ¿Posibilidad de monitorizar estado de diálogos mediante re-INVITE's?
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
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
--
Iñaki Baz Castillo
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
6083
days inactive
6083
days old
sr-users-es@lists.kamailio.org
6 comments
2 participants
participants (2)
-
Iñaki Baz Castillo -
Jesus Rodriguez