Subject: Re: [sipcore] Session timer fix

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Dec 2017 08:00:02 +0000

Hi,

>>I don¹t think that (2) is enough. In the deployment case that triggered
>> the problem, there would never be a chance to send the clarification
>> UDPATE, because the INVITE is rejected.
>
>OK, that is an issue.
>
>> So, I still think we shall clarify the procedures, and restrict what can
>> be done in UPDATEs sent within INVITEs. For example, one must not change
>> the refresher etc., and whatever comes in the 2xx/INVITE matters. Again,
>> in the deployment case, that should be rather easy to fix, because the
>> impact will be on an limited number of application servers - not on
>> thousands of UAs.
>> 
>> Regarding Roland¹s proxy case, we can clarify that a proxy must not
>>change
>> the timer value in a response.
>
>More than that: If a proxy is going to insert or revise s-e or min-s-e
>in an UPDATE within an INVITE then it must do so consistently in the
>enclosing INVITE.

Correct.

Regards,

Christer

>>On 29/11/17 18:35, "Paul Kyzivat" <[email-masked]> wrote:
>> 
>>> We have wandered around quite a bit on this. I'm not sure if we are
>>> converging or not. I'm going to try to restate the problem, taking
>>> advantage of the insights that we've had in the discussion.
>>>
>>> The Problem:
>>>
>>> Even when all parties comply with RFC4028 it is possible to end with
>>> differences of opinion among the parties about the negotiated session
>>> timer values: the session expiration time, the min-s-e, and/or the
>>> refresher.
>>>
>>> In some cases these ambiguities are benign in that the session will
>>> still get refreshed by somebody who is willing to do so within a time
>>> interval that is acceptable to all. And the refresh may well clear up
>>> the ambiguity.
>>>
>>> However there are some cases that are not so benign. For instance, it
>>>is
>>> possible to arrive at a situation where neither UA believes it is the
>>> refresher, and so the session will never get refreshed.
>>>
>>> Possible Solutions (in the abstract):
>>>
>>> 1) Revise/clarify the rules of RFC4028 to eliminate the ambiguities.
>>>
>>> An issue with this is that it only eliminates all the problems if all
>>> the parties in the call (UAC, UAS, and proxies) implement this update.
>>> In principle Require and Proxy-Require could be used to ensure that all
>>> parties support the update. But in practice there is no good way to
>>>roll
>>> that out, and it is generally more important that calls succeed.
>>>
>>> 2) If a UA in the call detects that the call has ended up in a state
>>> that causes a non-benign ambiguity it should immediately initiate a
>>> session refresh to remove the ambiguity.
>>>
>>> In most cases it should be possible for at least one end to detect the
>>> situation. The only exception I can think of is when neither UA
>>>supports
>>> this extension but a proxy does. I think the proxy is helpless in this
>>> case and I don't see any fix other than the proxy causing the INVITE to
>>> fail.
>>>
>>> ISTM that doing (1) isn't a sufficient solution, while (2) is. So I
>>> think we should concentrate on that first.
>>>
>>> A really simple algorithm for this would be that if an UPDATE was used
>>> within an INVITE then once the INVITE completes then the end that
>>>thinks
>>> it is now UAS (non refresher) should immediately do a refresh using
>>> UPDATE. This would clarify who is refresher and fix the case where
>>> neither end think they are the refresher. And it would clarify any
>>> ambiguity in s-e and min-s-e.
>>>
>>> But that algorithm is inefficient in that it will be sent in many cases
>>> where it isn't needed. I think we can narrow the conditions when it
>>> needs to be sent, so that it is only sent if there actually is
>>> non-benign ambiguity.
>>>
>>> I think (2) is probably sufficient. If we wanted to go further, then we
>>> could *also* do (1).
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>
>>> On 11/29/17 2:31 AM, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> It is really difficult to reference specific messages when there is no
>>>> call flow.
>>>>
>>>> But, in my opinion, whatever is sent in the 2xx/INVITE matters.
>>>>
>>>> I also think it would be a good idea for the UAS to actually include a
>>>> timer value in the UPDATE request - the same timer value that it will
>>>> later include in the 2xx/INVITE. The proxy may still of course lower
>>>>the
>>>> value, but perhaps it would simply pass it.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>> On 29/11/17 03:37, "sipcore on behalf of Paul Kyzivat"
>>>> <[email-masked] on behalf of [email-masked]> wrote:
>>>>
>>>>> On 11/28/17 7:46 PM, [email-masked] wrote:
>>>>>> Hi Roman,
>>>>>>
>>>>>> Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass
>>>>>>towards
>>>>>> UAS.
>>>>>>
>>>>>> 1st negotiation is ongoing.
>>>>>>
>>>>>> 18x/PRACK/200OK(PRACK) is exchanged.
>>>>>>
>>>>>> Now UAS is sending UPDATE with a supported timer and Proxy adds S-E
>>>>>> due
>>>>>> to local policy with S-E 1800.
>>>>>
>>>>> If that is its policy, why didn't it also reduce the S-E to 1800 in
>>>>>the
>>>>> INVITE? If it had done that there wouldn't be a problem.
>>>>>
>>>>>> So what will the UAC do. The proxy has added the S-E.
>>>>>
>>>>> The case you presented, where the proxy is inconsistent between
>>>>>INVITE
>>>>> and UPDATE, does present a problem. The UA could send S-E 1800 in the
>>>>> 200/UPDATE. But what the other end does in that case is undefined.
>>>>>
>>>>> What you have demonstrated here is that there is an issue with the
>>>>>S-E
>>>>> value as well as with the refresher role.
>>>>>
>>>>>> UAC (Which has sent the INVITE) could ignore and send 200 OK without
>>>>>> any
>>>>>> S-E. i.e. ignoring UPDATE.
>>>>>>
>>>>>> In this case, what is the then proxy doing? Passing 200OK w/o S-E or
>>>>>> may
>>>>>> it add an S-E again? Assuming it adds S-E 1800 because it remembers
>>>>>> that
>>>>>> the UPDATE was received with supported timer.
>>>>>>
>>>>>> What does the UAS do? Ignoring the 200 OK with SE or accepting?
>>>>>>
>>>>>> And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600
>>>>>> as
>>>>>> proposed by the INVITE, because the UAS is ignoring the 200 OK
>>>>>> (UPDATE)
>>>>>> with S-E 1800?
>>>>>>
>>>>>> Or do you think that his is a wrong implementation.
>>>>>
>>>>> I think it is a stupid implementation. AFAIK there is nothing in 4028
>>>>> that says it is wrong.
>>>>>
>>>>> I think the fix I sketched in a mail a few hours ago can probably be
>>>>> extended to cover this case. Notably, if one side detects an
>>>>>ambiguity
>>>>> in one or more of the negotiated s-t values, and that ambiguity has
>>>>> negative consequences, then it should initiate an immediate s-t
>>>>>refresh
>>>>> to fix it.
>>>>>
>>>>> We just need to sort out what all the ambiguities are and how to
>>>>>detect
>>>>> them.
>>>>>
>>>>> 	Thanks,
>>>>> 	Paul
>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> Roland
>>>>>>
>>>>>> *Von:* sipcore [mailto:[email-masked]] *Im Auftrag von
>>>>>> *Roman
>>>>>> Shpount
>>>>>> *Gesendet:* Mittwoch, 29. November 2017 00:07
>>>>>> *An:* Jesske, Roland <[email-masked]>
>>>>>> *Cc:* SIPCORE <[email-masked]>
>>>>>> *Betreff:* Re: [sipcore] Session timer fix
>>>>>>
>>>>>> Roland,
>>>>>>
>>>>>> Please provide the exact scenario. What you seem to be describing
>>>>>>are
>>>>>> misconfigured proxies or clients that do not follow existing
>>>>>> specifications.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> _____________
>>>>>> Roman Shpount
>>>>>>
>>>>>> On Tue, Nov 28, 2017 at 5:33 PM, <[email-masked]
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>       Hi Paul,
>>>>>>       We have different issues where we have look on.
>>>>>>       And we see that we have UPDATE with an S-T causing a lot of
>>>>>> trouble.
>>>>>>       This is dependent on different use cases.
>>>>>>       One is that the UA does not support UPDATE.
>>>>>>       Yes that is true.
>>>>>>       But one of the main problems are the proxies in between.
>>>>>>       Either proxies do not react which is OK.
>>>>>>       And the UAC interpreting the 200OK.
>>>>>>       Also the direction of the UPDATE is important.
>>>>>>       Also the behavior of the proxy. We have seen proxies adding
>>>>>>S-T
>>>>>> to
>>>>>>       the UPDATE due to the fact that session timer supported is
>>>>>>set.
>>>>>> The
>>>>>>       S-T values where different to that set by the UAC.
>>>>>>
>>>>>>       So as you said we can identify all use cases. And I think
>>>>>>that is
>>>>>>       what we need or real clear rules for UAC/UAS and Proxy.
>>>>>>
>>>>>>       Best Regards
>>>>>>
>>>>>>       Roland
>>>>>>
>>>>>>
>>>>>>        > -----Ursprüngliche Nachricht-----
>>>>>>        > Von: Paul Kyzivat [mailto:[email-masked]
>>>>>>       <mailto:[email-masked]>]
>>>>>>        > Gesendet: Dienstag, 28. November 2017 21:31
>>>>>>        > An: Christer Holmberg <[email-masked]
>>>>>>       <mailto:[email-masked]>>; Roman Shpount
>>>>>>        > <[email-masked] <mailto:[email-masked]>>
>>>>>>        > Cc: Jesske, Roland <[email-masked]
>>>>>>       <mailto:[email-masked]>>; [email-masked]
>>>>>>       <mailto:[email-masked]>
>>>>>>        > Betreff: Re: [sipcore] Session timer fix
>>>>>>
>>>>>>        >
>>>>>>        > On 11/28/17 2:53 PM, Christer Holmberg wrote:
>>>>>>        > > Hi,
>>>>>>        > >
>>>>>>        > >>> 1. What happens when UAC receives a 2XX INVITE response
>>>>>> with
>>>>>> S-T
>>>>>>        > >>> that did not match the S-T value negotiated by UPDATE
>>>>>> transaction
>>>>>>        > during this INVITE transaction?
>>>>>>        > >>
>>>>>>        > >> Error case.
>>>>>>        > >>
>>>>>>        > >>> 2. What happens when UAC receives a 2XX UPDATE response
>>>>>> with
>>>>>> S-T
>>>>>>        > >>> that did not match the 2XX response for the previous
>>>>>> UPDATE
>>>>>>        > transaction?
>>>>>>        > >>
>>>>>>        > >> Error case.
>>>>>>        > >>
>>>>>>        > >> How do you want to handle these error cases? Two options
>>>>>> that
>>>>>>       I see are:
>>>>>>        > >> a. Terminate the dialog (hang up)
>>>>>>        > >> b. Issue a new UPDATE to set refresher to a known state.
>>>>>>        > >
>>>>>>        > > Those are two alternatives, yes. I don't think we need to
>>>>>>       mandate any
>>>>>>        > specific behaviour, as long as we make it clear that an
>>>>>>error
>>>>>> has
>>>>>>       occurred and
>>>>>>        > it needs to be taken care of SOMEHOW.
>>>>>>        >
>>>>>>        > Or you can just ignore the error and hope for the best.
>>>>>>        >
>>>>>>        > My intuition tells me that this will rarely cause a
>>>>>>problem.
>>>>>> Most
>>>>>>       of the time a
>>>>>>        > device that doesn't support the update will be compliant
>>>>>>with
>>>>>> the
>>>>>>       update by
>>>>>>        > accident. And in a bunch of the remaining cases ignoring a
>>>>>>       conflicting value in
>>>>>>        > the nested UPDATE won't matter because both ends will
>>>>>>settle
>>>>>> on
>>>>>>       what is in
>>>>>>        > the 200/INVITE. And the remaining cases will result in both
>>>>>> ends
>>>>>>       thinking
>>>>>>        > they are UAC or UAS. It isn't a problem if they both think
>>>>>> they
>>>>>>       are the UAC,
>>>>>>        > since then both will attempt to refresh. It is only a
>>>>>>problem
>>>>>> if
>>>>>>       they both think
>>>>>>        > they are UAS, since that is the only case when the session
>>>>>> won't
>>>>>> be
>>>>>>        > refreshed. If that happens, is it worse than having had the
>>>>>> call
>>>>>>       fail?
>>>>>>        >
>>>>>>        > If need be we can work through all the cases. But there are
>>>>>> quite
>>>>>>       a lot of
>>>>>>        > them.
>>>>>>        >
>>>>>>        >       Thanks,
>>>>>>        >       Paul
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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: Christer Holmberg <[email-masked]>
Date: Fri, 1 Dec 2017 08:12:18 +0000

Hi,

> I am not sure we can put a rule in the specification that prevents
>refusing INVITE requests randomly. It is not against any specification,
>just not extremely useful.
>
> Proposing that UA should not refuse INVITE transactions due to S-E
>settings mismatch and use an UPDATE transaction to clear S-E status (2)
>should be sufficient to address the original issue.

I am not suggesting the we prevent a UAS from rejecting an INVITE request
- a UAS can reject an INVITE whenever it wants, for whatever reasons.

My point was that only doing (2) would not fix the deployment problem, as
the INVITE is rejected before there is a chance to send a clarification
UPDATE.

> I think proxy should be consistent about how it is inserting or updating
>s-e or min-s-e in general. There is little or no reason why what proxy
>does should change from transaction-to-transaction.
>
> There is one case here which is tricky:
>
> 1. UAC sends an INVITE without S-E
> 2. Proxy inserts S-E set to 3600 since it expects dialogs to expire
>after an hour
> 3. Within INVITE transaction UAC sends an UPDATE with S-E set to 1800
> 4. Proxy does not update S-E in UPDATE since  dialog will be refreshed
>before it is expired by proxy
>
> UAS is confused since it got two messages, one with S-E 3600 and another
>with S-E 1800.

3) would not be allowed. The UDPATE must mirror the INVITE.

And, even if 3) happens, the UAS would discard the S-E 1800.

> It would be hard for the proxy to track what S-E value was used in the
>INVITE, since proxies are generally not dialog statefull. Even if proxy
>did track that value, it cannot simply increase the S-E in client UPDATE.
>
> Proposed solution -- UAS should pick the smallest S-E value and use that.

I doubt ANY UA does that today, which means that EVERY deployed UA would
have to be updated in order for that to work.

In addition, it’s not only about the timer value. What if the UAC changes
the refresher value in the UPDATE? The UAS will receive “uac” in the
INVITE, and “uas” in the UPDATE? What does it do?

So, I still think the easiest solution is to simply say that the
UPDATE-inside-INVITE must mirror the INVITE.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 1 Dec 2017 13:10:02 -0500

> UPDATE-inside-INVITE must mirror the INVITE.

But the MUST will only apply to UAs that implement this revision. For 
maximum effect I think we need to specify how to patch things up when 
only one end supports it and the other end (or a proxy) is behaving in a 
problematic way.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 1 Dec 2017 14:14:15 -0500

On Fri, Dec 1, 2017 at 1:10 PM, Paul Kyzivat <[email-masked]> wrote:

> maximum effect I think we need to specify how to patch things up when only
> one end supports it and the other end (or a proxy) is behaving in a
> problematic way.
>

This was my point exactly. We should suggest the behavior which will result
in highest chance of success if only one of the UA implements it. I think
there are still scenarios which will break, like UA which simply refuse the
INVITE transaction with S-E if they got an UPDATE with S-E during this
transaction (even if S-E values matched). If only one UA implements the
update, all we hope for is to minimize the number of failures. From this
point of view, I am not sure, what would be better:

a. Refusing UPDATE with mismatching S-E during INVITE transaction
b. Accepting UPDATE and have some sort of logic which makes the safest
possible choice between the messages  (pick smallest S-E, pick largest
Min-S-E, pick refresher option where current UA is doing the refreshing)

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 1 Dec 2017 16:06:00 -0500

On 12/1/17 2:14 PM, Roman Shpount wrote:
> On Fri, Dec 1, 2017 at 1:10 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     But the MUST will only apply to UAs that implement this revision.
>     For maximum effect I think we need to specify how to patch things up
>     when only one end supports it and the other end (or a proxy) is
>     behaving in a problematic way.
> 
> 
> This was my point exactly. We should suggest the behavior which will 
> result in highest chance of success if only one of the UA implements it. 
> I think there are still scenarios which will break, like UA which simply 
> refuse the INVITE transaction with S-E if they got an UPDATE with S-E 
> during this transaction (even if S-E values matched). If only one UA 
> implements the update, all we hope for is to minimize the number of 
> failures. From this point of view, I am not sure, what would be better:
> 

Refusing an UPDATE within an INVITE has all sorts of nasty implications. 
It may be doing more than just the s-t stuff. E.g. I might be doing 
preconditions. IMO this is a bad path to pursue.

Aside from accepting the UPDATE I don't think it matters much what 
assumptions you make about how it impacts the s-t negotiations. Whatever 
you assume has a chance to be right or wrong. Better to simply do a s-t 
refresh immediately after the INVITE. Your guessing can then be limited 
to what values to use in that refresh. (Note that my use of "refresh" if 
the end doing this was not clearly chosen as the refresher. So maybe it 
would be better to call it something else.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Dec 2017 11:11:54 +0000

Hi,

>only one end supports it and the other end (or a proxy) is behaving in a

Again, the only impacted UAs that we are currently aware of (there may of
course be others) are to be fixed.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Dec 2017 11:20:09 +0000

Hi,

>>         In addition, it¹s not only about the timer value. What if the
>>         UAC changes
>>         the refresher value in the UPDATE? The UAS will receive ³uac²
>>in the
>>         INVITE, and ³uas² in the UPDATE? What does it do?
>> 

I don¹t understand why you are trying to create problems that we don¹t
even know exist.

So far, we are aware of an application server that sends UPDATE with
changed S-E. By saying that it must not do so, we will fix that problem,
because the application server is to be updated based on the correction.

When you say ³one UA², it is a huge difference if that UA is an endpoint
of which there may be thousands of deployments, or if that UA is a much
smaller number of network elements (that typically are also easier to
update).

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 11 Dec 2017 22:58:21 +0900

Hi, Roman

 > 1. Define conditions when S-E state is dangerously ambiguous and 
recommend for UA to send an UPDATE to clarify the S-E state

During a successful INVITE transaction(between INVITE and ACK),
when UA sends or receives UPDATE and the transaction has succeeded as a 
result,
if interval or refresher are semantically different from those of 200 
response for the INVITE,

According to the Session-Expires header in 200 response for the INVITE, 
refresher(?) is recommended to send an UPDATE immediately(or within 
10-30 seconds?).
After waiting 30(?) seconds for the session refresh request, if 
non-refresher has not received that, it is recommended to send an UPDATE 
immediately.

 > 2. Define recommended rules for UA and Proxies to avoid ambiguous 
situations

My suggestion:
Additional rules allow proxies to add or increase Min-SE header in a 
request.
Additional rules allow uas to add Min-SE header in 200 response.
UA should not change semantically the interval or refresher of 
Session-Expires header in a request and 200 response.

Regards,
Shinji

On 2017/11/30 3:38, Roman Shpount wrote:
> Paul,
>
> I generally agree. I think the path forward should be:
>
> 1. Define conditions when S-E state is dangerously ambiguous and recommend
> for UA to send an UPDATE to clarify the S-E state
> 2. Define recommended rules for UA and Proxies to avoid ambiguous situations
>
> 1 should be sufficient to provide resilient implementations. 2 should help
> to avoid the extra UPDATE.