On 2/22/12 5:54 AM, OKUMURA Shinji wrote:
> Hi Paul,
>
> I think that the following rule should be applied to Session-Expires.
>
> RFC3311/5.1 Sending an UPDATE
> If a UA
> uses an UPDATE request or response to modify the remote target while
> an INVITE transaction is in progress, and it is a UAS for that INVITE
> transaction, it MUST place the same value into the Contact header
> field of the 2xx to the INVITE that it placed into the UPDATE request
> or response.
>
>
> But a particular crossing case is not avoidable as yet.
>
> A B
> | |
> |re-INV |
> |------------------------------>|
> | 18x-rel|
> b1|<------------------------------|b1
> | 2xx|
> | /---------------|b2/s1
> |UPD / |
> |=============/================>|
> | / 2xx(UPD)|
> b3/s2|<==========/===================|b3/s2
> | / |
> * b2/s1|<--------/ |
> |ACK |
> |------------------------------>|
> | |
>
> UA-A may need a new UPDATE or re-INVITE to confirm a common view
> of Session-Expires.
In this case, only B has enough info to realize there is a problem.
So if it discovers that there is an ambiguity it would need to initiate
another session timer refresh.
Thanks,
Paul
> Regards,
> Shinji.
>
> Paul Kyzivat<[email protected]>
> Mon, 20 Feb 2012 12:24:08 -0500
>> 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
