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