[SR-Users] dialog - keep alives with lower cseq

[Klaus Darilion]

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
>