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<mico...@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@lists.sip-router.org > >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
