Hi,
Paul Kyzivat <[email protected]>
Wed, 22 Feb 2012 15:35:28 -0500
>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.
There is another crossing case.
A B
| |
|re-INV |
|------------------------------>|
| 18x-rel|
b1|<------------------------------|b1
| 2xx|
| /-------------|b2/s1
| / UPD|
b3/s2|<==============/===============|b3/s2
|2xx(UPD) / |
|=============/================>|
| / |
b2/s1|<----------/ |
|ACK |
|------------------------------>|
| |
The simplest rule I think is,
between sending 2xx to INVITE and receiving ACK,
1. UA does not send an UPDATE.
2. UA does not respond 2xx to an UPDATE.
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
