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

[Daniel-Constantin Mierla]

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
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda