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(a)gmail.com>om>: >> 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(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users