Subject: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue]

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Sep 2017 09:36:55 +0000

Hi,

I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00,
that describes the problem, and updates RFC 4028 based on the suggested
solution presented earlier.

Now, if people think an errata is more appropriate I have no problem with
that. However, I think we DO need to fix this, because it is causing
problems in deployed networks.

https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt

For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race

Regards,

Christer

On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Hi,
>
>>> seen from my point of view the UAC should ignore the Session timer
>>>proposal within the UPDATE.
>>> As long as the negotiation is  ongoing.
>>> 
>>> Nevertheless we have also observed this curious session timer behavior
>>>in our network.
>>> 
>>> I think we need some clarifications to the RFC. Perhaps also to other
>>>sections to make it more readable.
>>> My experience is that people have problems in following how the
>>>session timer should work within a complex SIP networks (e.g. IMS).
>>> 
>>> What is about updating the RFC4028.
>>
>> Like most of the older SIP RFCs, it probably deserves an update. The
>>problem is whether going to the trouble will have any effect on
>>implementations. I think the most we > should hope to do is *clarify* in
>>cases where there is ambiguity, so that when interoperability problems
>>arise it is clear who needs to change.
>
>Yes. In my case, implementation(s) WILL be changed. The question is WHICH
>implementation(s) :)
>
>So, my suggestion would be:
>
>1)	Specify/clarify that SE must not be sent during session-timer
>negotiation
>2)	Specify that one must send a 491 (or some other more appropriate code)
>response if receiving SE during session-timer negotiation
>
>For the above, I think we can do it using an errata.
>
>Regards,
>
>Christer
>
>
>
>>> -----Ursprüngliche Nachricht-----
>>> Von: sipcore [mailto:[email-masked]] Im Auftrag von
>>> Christer Holmberg
>>> Gesendet: Donnerstag, 7. September 2017 11:34
>>> An: Paul Kyzivat <[email-masked]>; [email-masked]
>>> Betreff: Re: [sipcore] Session-timer issue
>>>
>>> Hi,
>>>
>>>>> The following issue has been around for some time already (there is
>>>>> also  an errata #4744), and as it causes problems (the INVITE is
>>>>> rejected with a
>>>>> 480 response) in deployed networks, so I think it needs to be fixed.
>>>>> People seem to have different opinions on which node is acting
>>>>> wrongly, so  I hope we can sort it out :)
>>>>
>>>> This is an interesting problem. I agree that it is unclear exactly
>>>> what ought to happen in this case. (But I don't understand why
>>>> someone thinks a 480 is a good way to resolve it.)
>>>
>>> Whether 480 is the best solution or not is not the issue, in my
>>>opinion.
>>> One could also claim that the UPDATE should be rejected. Etc.
>>>
>>> The issue is that there is a session-timer negotiation "race
>>> condition", and we should forbid that (rejecting the UPDATE could be
>>>part of such solution).
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>>> Below is a call flow showing the problem:
>>>>>
>>>>>
>>>>> UA                Proxy                AS
>>>>>
>>>>> ------------------->
>>>>> INVITE (#1)
>>>>> Supported:timer
>>>>> SE:refresher=uac
>>>>>
>>>>>                       ------------------->
>>>>>                       INVITE (#2)
>>>>>                       Supported:timer
>>>>>                       SE:refresher=uac
>>>>>
>>>>>
>>>>>                       <-------------------
>>>>>                       18x (#3)
>>>>>
>>>>> <-------------------
>>>>> 18x (#4)
>>>>>
>>>>> ++++++ early dialog established +++++++
>>>>>
>>>>>                       <-------------------
>>>>>                       UPDATE (#5)
>>>>>                       Supported:timer
>>>>>                       SE:refresher=uas
>>>>>
>>>>> <-------------------
>>>>> UPDATE (#6)
>>>>> Supported:timer
>>>>> SE:refresher=uas
>>>>>
>>>>>
>>>>> ------------------->
>>>>> 200 (UPDATE) (#7)
>>>>>
>>>>>                       ------------------->
>>>>>                       200 (UPDATE) (#8)
>>>>>                       Require:timer
>>>>>                       SE:refresher=uac
>>>>>
>>>>>
>>>>>                       <-------------------
>>>>>                       480 (INVITE) (#9)
>>>>>
>>>>> <-------------------
>>>>> 480 (INVITE (#10)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> A few things to note:
>>>>>
>>>>>
>>>>> N1:	The 18x does not contain the SE (Session-Expires) header field,
>>>>>           because according to section 4 of RFC 4028 the header
>>>>> field is only
>>>>>           allowed in INVITE, UPDATE and 2xx. So, when the UPDATE
>>>>>request
>>>>>           (#5) is sent, the initial session timer negotiation is
>>>>>still
>>>>>           ongoing.
>>>>>
>>>>>
>>>>> N2:	The UPDATE request (#5) contains a Session-Expires header field.
>>>>>           Section 7.4 of RFC 4028 says:
>>>>>
>>>>> 	     "In a session refresh request sent within a dialog with an
>>>>>active
>>>>> 	      session timer, the Session-Expires header field SHOULD be
>>>>> present."
>>>>>
>>>>> 	Now, a dialog (early) HAS been established when the UPDATE
>>> request is
>>>>>           sent, but as the initial session timer negotiation is still
>>>>>           ongoing, I assume the session timer isn¹t yet "active"?
>>>>>
>>>>>
>>>>> N3:	The UPDATE 200 response (#7) does not contain the Session-Expires
>>>>>           header field. It is added by the proxy, based on the
>>>>> procedures in
>>>>>           Section 8.2 of RFC 4028:
>>>>>
>>>>>                "Because there is no Session-Expires or Require
>>>>> header field
>>>>>                 in the response, the proxy knows that it is the first
>>>>>                 session-timer-aware proxy to receive the response.
>>>>> This  proxy
>>>>>                 MUST insert a Session-Expires header field into the
>>>>> response
>>>>>                 with the value it remembered from the forwarded
>>>>>request.
>>>>> It
>>>>> MUST
>>>>>                 set the value of The 'refresher' parameter to 'uac'.
>>>>> The  proxy MUST
>>>>>                 add the 'timer' option tag to any Require header
>>>>> field in  the
>>>>>                 response, and if none was present, add the Require
>>>>> header  field with
>>>>>                 that value before forwarding it upstream."
>>>>>
>>>>>
>>>>> Now, one could argue that the UA should include something in the
>>>>> UPDATE response (#7), but I think that is not a solution as the UA
>>>>> may be confused.
>>>>> Instead, based on my understanding of the text in section 7.4 (see
>>>>> above) the UPDATE request (#5) should not contain any session timer
>>>>> information. This is also more or less what the errata suggests.
>>>>>
>>>>> Comments?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: "VAN GEEL Jan (SPC/CSP)" <[email-masked]>
Date: Wed, 13 Sep 2017 12:28:56 +0000

I support this draft

Kind regards

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday 13 September 2017 11:37
To: [email-masked]
Cc: Ben Campbell <[email-masked]>; [email-masked]
Subject: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue]

Hi,

I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00,
that describes the problem, and updates RFC 4028 based on the suggested solution presented earlier.

Now, if people think an errata is more appropriate I have no problem with that. However, I think we DO need to fix this, because it is causing problems in deployed networks.

Regards,

Christer

wrote:

>>> Nevertheless we have also observed this curious session timer
>>>behavior in our network.
>>>
>>> I think we need some clarifications to the RFC. Perhaps also to
>>>other sections to make it more readable.
>>implementations. I think the most we > should hope to do is *clarify*
>>in cases where there is ambiguity, so that when interoperability
>>problems arise it is clear who needs to change.
>
>1)Specify/clarify that SE must not be sent during session-timer
>negotiation
>2)Specify that one must send a 491 (or some other more appropriate code)
>>>>> The following issue has been around for some time already (there
>>>>> is also  an errata #4744), and as it causes problems (the INVITE
>>>>> is rejected with a
>>>>> N1:The 18x does not contain the SE (Session-Expires) header field,
>>>>> N2:The UPDATE request (#5) contains a Session-Expires header field.
>>>>> N3:The UPDATE 200 response (#7) does not contain the Session-Expires
>>>>>                 MUST insert a Session-Expires header field into
>>>>>the  response
>>>>> above) the UPDATE request (#5) should not contain any session
>>>>> timer information. This is also more or less what the errata suggests.
>>>>>
>>>>> Comments?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>

________________________________

***** Disclaimer *****
http://www.proximus.be/maildisclaimer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Sep 2017 10:24:40 -0400

Hi Christer,

> https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt

I agree that something should be done about this. But it may be possible 
to make things clearer. The fuzzy area is whether there is an ongoing 
negotiation of a session timer, and the fuzzy point there is that the 
two sides might have different understandings of this due to race 
conditions.

AFAICT the only way this comes up is when using UPDATE. There are two 
clearly distinct uses of UPDATE - within or outside an INVITE 
transaction. When one UA sends an UPDATE it has a clear understanding of 
which of these cases applies, and I think the recipient can also figure 
out which usage the sender thought it was.

I'll propose that the session timer negotiation never be done with an 
UPDATE within an INVITE transaction. (Regardless of whether than INVITE 
is negotiating a session timer or not.) I think this resolves the 
problem that you have encountered. (Or we could require that the UPDATE 
and response care consistent session timer signaling with what is 
carried in the INVITE and its responses.)

That still leaves the actual glare conditions where the two sides each 
try to start a new session timer negotiation concurrently. Those can 
properly be handled with 491 responses. This may result in some new 
cases for use of 491 and some ambiguity about that the 491 signifies. 
These might be clarified with a Reason header.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Sep 2017 14:47:48 +0000

Hi Paul,

>carried in the INVITE and its responses.)

If people are ok with simply disallowing UPDATE + Session-Expires while
there is an ongoing (re-)INVITE transaction (no matter if the INVITE
contained Session-Expires or not) I think that would be the easiest
solution.

At least I have never heard about a case where one would send INVITE
without Session-Expires, and then send UPDATE + Session-Expires while the
INVITE transaction is still ongoing.

>These might be clarified with a Reason header.

Correct.

Regards,

Christer

>>>>>behavior
>>>>in
>>>>>>>the

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Sep 2017 10:07:28 -0500

My rule of thumb is that errata exist to fix places where the RFC does not correctly reflect the intent of the WG at the time of publication. They are not appropriate for cases where we learned from experience that the text as originally intended itself has flaws.

Which category does this fall into? It seems borderline. OTOH, you’ve already created a draft :-)

Ben.

> On Sep 13, 2017, at 4:36 AM, Christer Holmberg <[email-masked]> wrote:
> 
> 
> Hi,
>

---

From: N WEINRONK <[email-masked]>
Date: Wed, 13 Sep 2017 19:49:02 +0100 (BST)

I recently came across:

https://www.rfc-editor.org/errata_search.php?eid=4744

Thanks,
Nigel
----Original message----
>From : [email-masked]
Date : 13/09/2017 - 10:36 (GMTDT)
To : [email-masked]
Cc : [email-masked], [email-masked]
Subject : [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue]

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Sep 2017 18:55:26 +0000

Hi Nigel,

>https://www.rfc-editor.org/errata_search.php?eid=4744

Yes, we filed this errata some time back.

However, when I started to look into the issue again, I realized that solving the issue may require additional changes in the RFC, and that's why I put together the draft :)

Regards,

Christer

----Original message----
From : [email-masked]
Date : 13/09/2017 - 10:36 (GMTDT)
To : [email-masked]
Cc : [email-masked], [email-masked] Subject : [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue]

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Sep 2017 05:44:18 +0000

Hi,

>My rule of thumb is that errata exist to fix places where the RFC does
>not correctly reflect the intent of the WG at the time of publication.
>They are not appropriate for cases where we learned from experience that
>the text as originally intended itself has flaws.
>

Initially I thought an errata would be enough, since we only suggested a
small change to one paragraph.

But, since we now suggest modifications to more paragraphs, and add some
clarification procedures, we thought a draft would be more appropriate.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Sep 2017 06:56:20 +0000

Hi,

…

>carried in the INVITE and its responses.)

I had a chat with some product people, and they said that there actually
ARE cases where the session timer is negotiated using UPDATE when the
initial INVITE transaction is still ongoing. There are cases where the
INVITE only contains Supported:timer, but the actual negotiation is done
using UPDATE.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Sep 2017 11:11:22 -0400

Christer,

> INVITE only contains Supported:timer, but the actual negotiation is done

Interesting! (I wonder why.)

That sequence itself presents some ambiguities. The way I have always 
described how the session timer negotiation works is that *every* INVITE 
and UPDATE transaction affects s-t - it either negotiates it *on* or 
else it negotiates it *off*. (IMO this makes it very easy to understand.)

That presents issues when you have an update nested inside of an invite. 
In the case you describe I might expect that the update would negotiate 
the timer on, and then the completion of the invite would negotiate it 
off again.

How would the case you describe work if a proxy inserted S-E in INVITE? 
In that case, the UAC doesn't know about it until the 2xx from the 
invite. Before then it might try enabling a timer using UPDATE.

I am inclined to keep things simple by saying that the 2xx response to 
every INVITE or UPDATE redefines the state of the session timer, either 
on or off. That will of course break the use case you describe above.

	Thanks,
	Paul