On 2/20/12 8:43 AM, Brett Tate wrote:
>> The RFC 4028 allows 2 simultaneous session timer
>> negotiations i.e with Re-Invite and Update. So the following
>> combinations are possible for session refresh request.
>
> <snip>
>
>> The session timers (session interval and session expires)
>> will be started based on the session expires header values
>> in the 2xx response of refresh request.
>>
>> The cross over of the response messages is also possible
>> (Response for the first refresh request received after the
>> response for the second refresh request).
>
> Correct. As discussed within the following and related threads, this is one
> of the potential SIP race conditions.
>
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-October/025881.html
>
>
>> The session expires in the 2xx response must be validated
>> by the stack as per the rules defied in RFC4028.
>>
>> What would be the most elegant way of handling such scenarios:
>
> Assume that the latest received/sent 2xx is the most accurate. If overly
> concerned that the race condition may cause the session to not be refreshed
> in time, you can do something like pick the lowest interval among the choices
> and act as the refresher.
>
> If you want to see the issue fixed or addressed as a BCP, you might raise the
> issue within the dispatch or sipcore working groups to see if anyone else
> wants this and similar race condition ambiguities resolved. If I recall
> correctly, this was not one of the issues fully addressed by RFC 6141 or RFC
> 5407.
I'm generally supportive of working out all the ambiguities in the sip
specs. But some cases are so minor and theoretical that they don't
warrant the work required to work out and publish the clarification. I'd
be interested in hearing descriptions of instances of this problem "in
the wild".
It would be appropriate to file an errata against the draft. That will
mean that the issue will at least be addressed if/when the draft is
revised in the future.
(BTW, Its my impression that session timer is vastly over-used. There is
no need for two UAs to use session timer to monitor the session between
them: each may send an in-dialog request at any time to verify it. The
primary value of session timer if for record-routed proxies.)
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
