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

Daniel-Constantin Mierla miconda at gmail.com
Wed May 2 15:31:28 CEST 2012


Hello,

On 5/2/12 3:14 PM, Sergey Okhapkin wrote:
>   Isn't it a responsibility of SIP session timer?

sip session timer support has to be implemented in end UA devices. To do 
it in the server side, it will require a b2bua. The sst module in 
kamailio adds headers to require UA to do re-INVITES based on session 
timer specs, but it does not do them itself.

Cheers,
Daniel

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




More information about the sr-users mailing list