18 Feb
2009
18 Feb
'09
4:23 p.m.
Hi Guys,
I would like to know if is possible to make a keepalive for active
calls (dialog module)?
Well, I think it is but is there a better way than making a selec into
the dialog table and building the INVITEs?
Thanks,
Noel
18 Feb
18 Feb
4:47 p.m.
The issue here is that if you send in-dialog requests from a proxy,
you break the CSeq for all the subsequent in-dialog requests sent by
endpoints.
Regards,
Ovidiu Sas
On Wed, Feb 18, 2009 at 10:23 AM, Noel R. Morais <noelrocha(a)gmail.com> wrote:
Hi Guys,
I would like to know if is possible to make a keepalive for active
calls (dialog module)?
Well, I think it is but is there a better way than making a selec into
the dialog table and building the INVITEs?
Thanks,
Noel
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
19 Feb
19 Feb
10:23 a.m.
On Wednesday 18 February 2009 16:47:36 Ovidiu Sas wrote:
The issue here is that if you send in-dialog requests
from a proxy,
you break the CSeq for all the subsequent in-dialog requests sent by
endpoints.
Isn't the whole point of the dialog module that it keeps track of the dialog
state (including the CSeq)?. It could increase/replace it in passing requests
when necessary.
Alex.
7:58 p.m.
El Jueves, 19 de Febrero de 2009, Alex Hermann escribió:
On Wednesday 18 February 2009 16:47:36 Ovidiu Sas
wrote:
It's not so easy. dialog module just takes in account one dialog while an
INVITE would generate various early-dialogs.
In one of those early-dialog there could be an in-dialog request (INFO,
PRACK...) so the CSeq must be incremeted *just* for that early dialog.
This would totally fail with the current dialog module implementation.
Also, if there is a PRACK the proxy should also handle the RSeq header.
In conclusion, a proxy CANNOT generate in-dialog requests safely. It could
work just in a few escenarios.
--
Iñaki Baz Castillo
The issue here is that if you send in-dialog
requests from a proxy,
you break the CSeq for all the subsequent in-dialog requests sent by
endpoints.
Isn't the whole point of the dialog module that it keeps track of the
dialog state (including the CSeq)?. It could increase/replace it in passing
requests when necessary. 
18 Feb
18 Feb
5:28 p.m.
On Wed, Feb 18, 2009 at 1:23 PM, Noel R. Morais <noelrocha(a)gmail.com> wrote:
Hi Guys,
I would like to know if is possible to make a keepalive for active
calls (dialog module)?
Well, I think it is but is there a better way than making a selec into
the dialog table and building the INVITEs?
Thanks,
You can use a B2BUA for this. For example, Sippy B2BUA (www.b2bua.org)
supports keepalive.
Regards
Luciano
7:22 p.m.
El Miércoles, 18 de Febrero de 2009, Noel R. Morais escribió:
Hi Guys,
I would like to know if is possible to make a keepalive for active
calls (dialog module)?
Well, I think it is but is there a better way than making a selec into
the dialog table and building the INVITEs?
A proxy shouldn't generate in-dialog requests, it would break CSeq numbers
(and in case of PRACK the issue is worse).
--
Iñaki Baz Castillo
7:50 p.m.
I didn't understand the problem regarding CSeq...
A lot of solutions use keepalives with INVITES ...
Thanks,
Noel
On Wed, Feb 18, 2009 at 3:22 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
El Miércoles, 18 de Febrero de 2009, Noel R. Morais
escribió:
Hi Guys,
I would like to know if is possible to make a keepalive for active
calls (dialog module)?
Well, I think it is but is there a better way than making a selec into
the dialog table and building the INVITEs?
A proxy shouldn't generate in-dialog requests, it would break CSeq numbers
(and in case of PRACK the issue is worse).
--
Iñaki Baz Castillo
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
8:01 p.m.
El Miércoles, 18 de Febrero de 2009, Noel R. Morais escribió:
I didn't understand the problem regarding CSeq...
Well, read in RFC 3261 about CSeq and how it's used to order in-dialog
requests.
A lot of solutions use keepalives with INVITES ...
But NEVER sent by a proxy. A keepalive can only be performed by an endpoint or
a B2BUA (an endpoint in fact).
--
Iñaki Baz Castillo
8:27 p.m.
On 02/18/2009 09:01 PM, Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
El Miércoles, 18 de Febrero de 2009, Noel R. Morais
escribió:
... and the short version is that each party in a call keeps track of
CSeq numbers from remote side. Newer request must have the CSeq higher
that the previous one to be considered valid.
If you are proxy in the middle: [caller] ---- [proxy] ----- [callee]
when you send a new sip request to callee (just for example), then the
callee will update the remote CSeq. When the caller sends a request,
does not have any idea that the proxy sent intermediate requests and
will use a CSeq number lower that what the callee expects, therefore
callee will just drop it. In this way, the BYE might not be accepted.
But, as Inaki pointed, you should go over the SIP RFC, you will get it
better from there and will help to configure properly kamailio sip server.
Cheers,
Daniel
I didn't understand the problem regarding
CSeq...
Well, read in RFC 3261 about CSeq and how it's used to order in-dialog
requests.
A lot of solutions use keepalives with INVITES
...
But NEVER sent by a proxy. A keepalive can only be performed by an endpoint or
a B2BUA (an endpoint in fact).
5552
days inactive
5553
days old
8 comments
6 participants
participants (6)
-
Alex Hermann -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Luciano Afranllie -
Noel R. Morais -
Ovidiu Sas