3 May
2012
3 May
'12
10:07 a.m.
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 14:31, Daniel-Constantin Mierla wrote:
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 are sent from the sip server, it would results
de-synchronization of the CSeq values hold in phones themselves (e.g., a
BYE created by caller/callee after a keep alive will be with lower cseq
than the other side would expect and accept). One solution would be to
update cseq when BYE passes the server to the right value. This implies
more processing, as a call can have many re-INVITEs or other requests
within dialog sent by caller/callee, including periodic updates to
database to store cseq numbers.
So I went for a different approach, like stated in subject -- let's see
your opinion if you think is going to work. Practically the keep alives
will be OPTIONS with CSeq equal or lower than the last valid value
(e.g., the cseq of the INVITE creating the call).
If the caller/callee is gone, that is simply, the OPTION will be timed
out and dialog module will send BYE.
If the caller/callee are reachable, but for some reason the call was
destroyed (e.g., a crash and restart meanwhile), since there is a
To-tag, the OPTIONS should get a 481 Call/Leg transaction does not
exists. Again, a case when kamailio will end the dialog.
The one to be discussed here would be caller/callee are still on the call.
Based on RFC (and the feedback from people on another thread here), a
requests coming within a dialog with lower CSEq should be replies with
500. CSeq numbers are still ok in both sides (note that requests with
lower CSeq can happen in reality, like two fast re-INVITEs sent over
UDP, the second arriving first due to network transmission).
I tested with snom phones and jitsi so far, seems to be a working
solution (well, jitsi was replying 500 after 20secs to keep alive
OPTIONS request, not sure for what reason, just reported back to the
project).
Is anyone here seeing any possible issues with the approach?
Call are ended by dialog, with proper CSeq in the BYE, after 10seconds
from the moment 408 or 481 is received, no other replies are taken in
consideration for ending the dialog from server side.
Cheers,
Daniel