If SIP clients are standard conform then it should work.
It may happen that crappy clients terminate the call after sending a
failure response (I have not seen that yet, but by having seens so many
crappy clients I would not be surprised if such clients exist).
regards
Klaus
On 02.05.2012
Hello,
several days ago, just before freezing the development for v3.3.0, I
added to dialog module the option to send keep alives for ongoing calls
in order to detect if caller/callee is gone.
SIP specs require to increment the CSeq for requests within dialog, but
because the keep alives
Hi Daniel,
we did something similar with Kamailio at Telefonica. But we chose a
little different approach:
Our OPTION-Request was in fact not associated with the Dialog at all,
thus we did not care about correct CSeq or anything at all. We just
sent the OPTIONs to the URI/Routes of the Dialog.
Hello,
OPTIONS out of dialog are ok to detect if the device is gone (e.g.,
network problem -- good for dispatcher case where it needs only to
figure out if gws are up).
Besides this one, I tried to figure out if the dialog is still active in
the end device, by setting dialog's call-id,
Isn't it a responsibility of SIP session timer?
On Wednesday 02 May 2012 15:07:50 Daniel-Constantin Mierla wrote:
Hello,
OPTIONS out of dialog are ok to detect if the device is gone (e.g.,
network problem -- good for dispatcher case where it needs only to
figure out if gws are up).
Hello,
On 5/2/12 3:14 PM, Sergey Okhapkin wrote:
Isn't it a responsibility of SIP session timer?
sip session timer support has to be implemented in end UA devices. To do
it in the server side, it will require a b2bua. The sst module in
kamailio adds headers to require UA to do re-INVITES
