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
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@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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.
El Jueves, 19 de Febrero de 2009, Alex Hermann escribió:
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.
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.
On Wed, Feb 18, 2009 at 1:23 PM, Noel R. Morais noelrocha@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
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 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@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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).
On 02/18/2009 09:01 PM, Iñaki Baz Castillo wrote:
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.
... 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
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).
-
Alex Hermann -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Luciano Afranllie -
Noel R. Morais -
Ovidiu Sas