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

[Sergey Okhapkin]

 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).
> 
> Besides this one, I tried to figure out if the dialog is still active in
> the end device, by setting dialog's call-id, from-tag and to-tag (e.g.,
> like when the device (crashed and) is restarted between keepalives -- it
> is still reachable but no dialog anymore). A request with unknown To-tag
> should be rejected with 481.
> 
> My doubts were related to what would be the behaviour of getting a lower
> cseq when dialog is active (callid, from-tag and to-tag mach).
> 
> Cheers,
> Daniel
> 
> On 5/2/12 2:52 PM, Carsten Bock wrote:
> > 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. All the device had
> > to do, was to reply in one way or another to that OPTIONs Request.
> > That worked pretty well with all kinds of Devices, ranging from Zyxel
> > CPE's, Snom phones, AVM boxes, Asterisk, Symbian built-in and many
> > more.
> > Some very rare crappy network devices (i think, we saw this issue only
> > once, it was a SIP-Client for Symbian, open-source, discontinued)
> > however simply ignored the OPTIONs, but that was anyway a
> > non-supported device. Probably, it would also ignore the OPTION
> > request, if it was with a call-id, cseq, totag, etc.
> > This is similar to the behaviour used by the Dispatcher module.
> > 
> > Just my $0,02,
> > Carsten
> > 
> > 2012/5/2 Daniel-Constantin Mierla<miconda at gmail.com>:
> >> 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
> >> 
> >> --
> >> Daniel-Constantin Mierla - http://www.asipto.com
> >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> >> 
> >> 
> >> _______________________________________________
> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >> sr-users at lists.sip-router.org
> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users