Subject: Re: [sipcore] Session timer fix

From: "Jesske, Roland" <[email-masked]>
Date: Thu, 2 Nov 2017 06:59:23 +0000

Hi,
I agree on Christer’s comment.
But nevertheless I would be happy to see a clear advice for the refresh mechanism when the S-E timer is switched off.
Perhaps an table and some text in section 7.4 for the refresh mechanism would help e.g.:

This is valid for UPDATE and INVITE refreshing a session where S-E is negotiated and the supported header with timer is set.

UAC supports?    SE parameter    S-E parameter        S-E
                  in request     in response      switched off
----------------------------------------------------------
      Y              Y                N                Y
      Y              N                Y                N
      Y              N                N                Y

                        Figure X Switch off S-E

When the when required timer set the S-E cannot be switched off.

What do you think?
Of course we could do the same for the initial negotiation to make everything clear.

Best Regards

Roland

Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Dienstag, 31. Oktober 2017 19:44
An: Roman Shpount <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; Jesske, Roland <[email-masked]>; [email-masked]
Betreff: RE: [sipcore] Session timer fix

Hi,

I may reply to Roman’s comments later.

But, at the end of the day I think what Paul said is what matters most: the procedures for turning session timer etc applies AFTER the session timer has been fully negotiated.

So, if the session timer is negotiated during the initial INVITE transaction, whatever UPDATEs are sent during that transaction will not contain session timer information, and they will have no impact on the session timer.

But, once the session timer has been negotiated (once the UAC has received the 200 OK, the rules regarding turning the session timer off etc applies.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 31 October 2017 20:21
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; Jesske, Roland <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Session timer fix

On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
My suggestion is that no-SE-in-response would switch off if SE was in the
request.

So, if there is no SE in the request, there is no switch off.

This will break pretty much every SE implementation. There are number of implementations where UA does not insert SE in the request. It is inserted either by proxies (actually this is the most common use case) or by the answering agent.

I think it would be much better to have a new header which will specify "do not update Session-Timer" in the offer.
This way if proxies insert Session-Timer, new header will overwrite.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Nov 2017 13:06:42 -0400

I might be missing something, but Session Timer is switched of by the last
success response to INVITE or UPDATE. Presence of Session-Expires in the
offer is irrelevant, so this table is wrong.

Also, Session Timer is primarily intended to be inserted by proxies. Its
main use case is to allow proxies to detect abandoned calls and expire any
state associated with these calls. User Agents do not really need Session
Timer, since they can detect abandoned calls by initiating Invite or Update
transactions on their own without negotiating anything.

Regards,

_____________
Roman Shpount

On Thu, Nov 2, 2017 at 2:59 AM, Jesske, Roland <[email-masked]> wrote:

> But nevertheless I would be happy to see a clear advice for the refresh
> mechanism when the S-E timer is switched off.
>
> This is valid for UPDATE and INVITE refreshing a session where S-E is
> negotiated and the supported header with timer is set.
>
>
>
>
>
> *Von:* Christer Holmberg [mailto:[email-masked]]
> *Gesendet:* Dienstag, 31. Oktober 2017 19:44
> *An:* Roman Shpount <[email-masked]>
> *Cc:* Paul Kyzivat <[email-masked]>; Jesske, Roland <
> [email-masked]>; [email-masked]
> *Betreff:* RE: [sipcore] Session timer fix
>
>
>
> Hi,
>
>
>
> But, at the end of the day I think what Paul said is what matters most:
> the procedures for turning session timer etc applies AFTER the session
> timer has been fully negotiated.
>
>
>
> So, if the session timer is negotiated during the initial INVITE
> transaction, whatever UPDATEs are sent during that transaction will not
> contain session timer information, and they will have no impact on the
> session timer.
>
>
>
> But, once the session timer has been negotiated (once the UAC has received
> the 200 OK, the rules regarding turning the session timer off etc applies.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* Roman Shpount [mailto:[email-masked] <[email-masked]>]
> *Sent:* 31 October 2017 20:21
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Paul Kyzivat <[email-masked]>; Jesske, Roland <
> [email-masked]>; [email-masked]
> *Subject:* Re: [sipcore] Session timer fix
>
>
>
>
>
> On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg <
> [email-masked]> wrote:
>
> This will break pretty much every SE implementation. There are number of
> implementations where UA does not insert SE in the request. It is inserted
> either by proxies (actually this is the most common use case) or by the
> answering agent.
>
>
>
> I think it would be much better to have a new header which will specify
> "do not update Session-Timer" in the offer.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Nov 2017 17:16:56 +0000

Hi,

> I might be missing something, but Session Timer is switched of by the last success response to 
> INVITE or UPDATE. Presence of Session-Expires in the offer is irrelevant, so this table is wrong.

I don't think we should talk about offers and answers, but requests and responses. This has nothing to do with offer/answer :)

Regards,

Christer

 
                        Figure X Switch off S-E

What do you think?
 
Best Regards
 
Roland

Hi,

 

Regards,
 
Christer

To: Christer Holmberg <[email-masked]>

On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg <[email-masked]> wrote:
My suggestion is that no-SE-in-response would switch off if SE was in the
request.

 
 
Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Nov 2017 13:53:24 -0400

On Thu, Nov 2, 2017 at 1:16 PM, Christer Holmberg <
[email-masked]> wrote:

> I don't think we should talk about offers and answers, but requests and
> responses. This has nothing to do with offer/answer :)
>

Agreed.  I meant to say presence of Session-Expires in the *request* is
irrelevant. Presence of Session-Expires in the success response to INVITE
or UPDATE modifies the Session Timer status.

The problem you are trying to solve requires some sort of indication to the
UAS that even if S-E is inserted in the request by some proxy on the path,
it should be ignored, since there is an INVITE transaction is progress
which should negotiate the Session Timer.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Nov 2017 16:39:40 -0400

> in request     in response      switched off

I don't find this table helpful because of the complex interactions with 
who is the refresher, and with what might be done by a proxy in the middle.

	Thanks,
	Paul

> *Von:*Christer Holmberg [mailto:[email-masked]]
> *Cc:* Paul Kyzivat <[email-masked]>; Jesske, Roland 
> <[email-masked]>; [email-masked]
> But, once the session timer has been negotiated (once the UAC has 
> received the 200 OK, the rules regarding turning the session timer off 
> etc applies.
> 
> Regards,
> 
> Christer
> 
> *From:*Roman Shpount [mailto:[email-masked]]
> *To:* Christer Holmberg <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>>; Jesske, Roland <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> implementations where UA does not insert SE in the request. It is 
> inserted either by proxies (actually this is the most common use case) 
> or by the answering agent.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Nov 2017 17:07:48 -0400

> received the 200 OK, the rules regarding turning the session timer off 

I don't think this is the right distinction, because it doesn't cover an 
update done in the midst of a re-INVITE transaction.

The key think is to treat an UPDATE in the midst of an INVITE 
transaction differently from an UPDATE outside of an INVITE.

And IMO this needs to have well defined behavior even if there is a 
proxy that doesn't support this revision.

I've been evolving my thinking as this discussion has continued. I see a 
couple of ways to go:

1) Specify that the negotiation in the INVITE transaction should be 
unaffected by whatever happens in an intervening UPDATE. Also specify 
how timer stuff should be handled in an UPDATE within an INVITE. For 
that I think what we have been converging on is:

- the UAC and proxies for the embedded UPDATE should not include S-E;
- the UAS should not include S-E in the UPDATE response,
   even if it gets one in the request;
- proxies should not add an S-E to an embedded UPDATE response;
- the UAC should ignore S-E in an embedded UPDATE response.

But the key here is the UAC ignoring it.

2) Specify that a UAC or proxy should duplicate in an embedded UPDATE 
whatever timer stuff they put in the enclosing INVITE transaction. And 
then the UAC for the INVITE should process the timer stuff in the 2xx 
response to the INVITE the same as if the UPDATE didn't happen. (What it 
does to process the timer stuff in the 200 for the UPDATE is irrelevant.)

I think (1) is closer to what we have been converging on. But I am now 
thinking that (2) is more robust in the presence of some components that 
don't implement the revision.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Nov 2017 17:27:57 -0400

On Thu, Nov 2, 2017 at 5:07 PM, Paul Kyzivat <[email-masked]> wrote:

> And IMO this needs to have well defined behavior even if there is a proxy
> that doesn't support this revision.
>
> unaffected by whatever happens in an intervening UPDATE. Also specify how
> timer stuff should be handled in an UPDATE within an INVITE. For that I
> think what we have been converging on is:
>
> whatever timer stuff they put in the enclosing INVITE transaction. And then
> the UAC for the INVITE should process the timer stuff in the 2xx response
> to the INVITE the same as if the UPDATE didn't happen. (What it does to
> process the timer stuff in the 200 for the UPDATE is irrelevant.)
>

There are two requirements for this work:

1. UAC must ignore the S-T negotiation result when UPDATE is within INVITE
transaction
2. UAC and UAS mast agree on the negotiation results.

I was thinking that including some sort of header (or supported tag) in the
UPDATE request and mirroring the same header (or tag) in the response would
be the best way to achieve this result. In this case, it is irrelevant if
proxies inserted S-E in the request -- the new header will overwrite it.
Proxies can also detect that S-E will have no effect on this request or
response, since the extra header is present.

UAC and UAS will know that they behave the same way since they will both
see this header only if they both support it.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Nov 2017 17:47:40 -0400

On 11/2/17 5:27 PM, Roman Shpount wrote:
> On Thu, Nov 2, 2017 at 5:07 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     I've been evolving my thinking as this discussion has continued. I
>     see a couple of ways to go:
> 
>     unaffected by whatever happens in an intervening UPDATE. Also
>     specify how timer stuff should be handled in an UPDATE within an
>     INVITE. For that I think what we have been converging on is:
> 
>     2) Specify that a UAC or proxy should duplicate in an embedded
>     UPDATE whatever timer stuff they put in the enclosing INVITE
>     transaction. And then the UAC for the INVITE should process the
>     timer stuff in the 2xx response to the INVITE the same as if the
>     UPDATE didn't happen. (What it does to process the timer stuff in
>     the 200 for the UPDATE is irrelevant.)
> 
>     I think (1) is closer to what we have been converging on. But I am
>     now thinking that (2) is more robust in the presence of some
>     components that don't implement the revision.
> 
> 
> 1. UAC must ignore the S-T negotiation result when UPDATE is within 
> INVITE transaction
> I was thinking that including some sort of header (or supported tag) in 
> the UPDATE request and mirroring the same header (or tag) in the 
> response would be the best way to achieve this result. In this case, it 
> is irrelevant if proxies inserted S-E in the request -- the new header 
> will overwrite it. Proxies can also detect that S-E will have no effect 
> on this request or response, since the extra header is present.
> 

I'm not sure a tag adds much. It doesn't do anything for proxies unless 
we use Proxy-Require, and we don't want that. And what do you do if the 
tag isn't recognized by the UAS?

ISTM a way to approach this is to first specify our proposed behavior 
(as in (1) or (2)). Then we need to analyze it in the presence of one or 
more components that don't implement the revision, and with various 
plausible interpretations of the existing ambiguous specification.

And then see if the result is any worse for any components with the 
revision than it is without it. (And I guess we should also figure out 
if it is any *better* before going ahead and doing this.)

	Thanks,
	Paul

---

From: "Jesske, Roland" <[email-masked]>
Date: Fri, 3 Nov 2017 10:02:34 +0000

Hi Christer,
yes offer/answer has nothing to do with it. I meant Request.
The table was talking about Request and response.

So by taking your words. Independent what was stated within the REQUEST of the refresh if the RESPONSE does not contain the SE then the Session Time Mechanism is switched off.
Correct.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Christer
> Holmberg
> Gesendet: Donnerstag, 2. November 2017 18:17
> An: Roman Shpount <[email-masked]>; Jesske, Roland
> <[email-masked]>
> Cc: [email-masked]
> Betreff: Re: [sipcore] Session timer fix
> 
> Hi,
> 
> > I might be missing something, but Session Timer is switched of by the
> > last success response to INVITE or UPDATE. Presence of Session-Expires in the
> But, at the end of the day I think what Paul said is what matters most: the
> procedures for turning session timer etc applies AFTER the session timer has
> been fully negotiated.
> 
> So, if the session timer is negotiated during the initial INVITE transaction,
> whatever UPDATEs are sent during that transaction will not contain session
> timer information, and they will have no impact on the session timer.
> 
> <[email-masked]> wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Nov 2017 09:35:40 +0000

Hi,

I agree with Paul that new option-tags etc aren't going to help. Also, in general, I think we should try to limit to impacts on different types of nodes.

One suggestion would be to forbid the usage of UPDATE to change the refresher. If an endpoint wants to change the refresher it MUST send a (re-)INVITE to do so. And, new endpoints could discard the refresher value in received UPDATEs, which means they would work with legacy endpoints that may try to change the refresher in an UPDATE.

That way we may not have to separate UPDATEs sent inside INVITE transactions and UPDATEs sent outside INVITE transactions.

I think Paul more or less suggested the same thing earlier ("the peer must mirror the refresher value"), eventhough I believe he was only talking about UPDATEs inside INVITE transaction.

That would at least solve the problem that originally triggered all this. And, at least in the deployment I am aware of it would only impact an application server - there would be no need to change any proxies or terminals.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 02 November 2017 23:48
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Jesske, Roland <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Session timer fix

On 11/2/17 5:27 PM, Roman Shpount wrote:
> INVITE transaction 2. UAC and UAS mast agree on the negotiation 
> results.
> 
> I was thinking that including some sort of header (or supported tag) 
> in the UPDATE request and mirroring the same header (or tag) in the 
> response would be the best way to achieve this result. In this case, 
> it is irrelevant if proxies inserted S-E in the request -- the new 
> header will overwrite it. Proxies can also detect that S-E will have 
> no effect on this request or response, since the extra header is present.
> 
> UAC and UAS will know that they behave the same way since they will 
> both see this header only if they both support it.

I'm not sure a tag adds much. It doesn't do anything for proxies unless we use Proxy-Require, and we don't want that. And what do you do if the tag isn't recognized by the UAS?

ISTM a way to approach this is to first specify our proposed behavior (as in (1) or (2)). Then we need to analyze it in the presence of one or more components that don't implement the revision, and with various plausible interpretations of the existing ambiguous specification.

And then see if the result is any worse for any components with the revision than it is without it. (And I guess we should also figure out if it is any *better* before going ahead and doing this.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Nov 2017 13:26:22 -0500

> I think Paul more or less suggested the same thing earlier ("the peer must mirror the refresher value"), eventhough I believe he was only talking about UPDATEs inside INVITE transaction.

UPDATE *within* INVITE and UPDATE *outside* INVITE are two distinct 
cases. Banning use of UPDATE outside for this purpose is a more extreme 
case. (IMO, once you have a session, using an offerless UPDATE for s-t 
refreshes is preferable unless you happen to also need a concurrent O/A.)

So I hesitate to ban that case unless allowing it causes some problem. 
The only possible problem I can see is if the two ends might disagree on 
whether the UPDATE is within an INVITE. This might occur if one end 
sends reINVITE and the other sends UPDATE more-or-less concurrently. But 
ISTM that case should be treated as glare. I think this can be covered 
by adding some text to the new draft talking about this case and 
spelling out that 491 should be used if this occurs.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 19 Nov 2017 02:36:02 +0000

Hi,

>> I agree with Paul that new option-tags etc aren't going to help. Also, in general, I think we
>> should try to limit to impacts on different types of nodes.
>> 
>> One suggestion would be to forbid the usage of UPDATE to change the refresher. If an endpoint 
>> wants to change the refresher it MUST send a (re-)INVITE to do so. And, new endpoints could discard 
>> the refresher value in received UPDATEs, which means they would work with legacy endpoints that may
>> try to change the refresher in an UPDATE.
>> 
>> I think Paul more or less suggested the same thing earlier ("the peer must mirror the refresher value"), eventhough 
>> I believe he was only talking about UPDATEs inside INVITE transaction.
>
> UPDATE *within* INVITE and UPDATE *outside* INVITE are two distinct cases. Banning use of UPDATE outside for 
> this purpose is a more extreme case. (IMO, once you have a session, using an offerless UPDATE for s-t refreshes is 
> preferable unless you happen to also need a concurrent O/A.)

I am not suggesting that we ban usage of UPDATE for s-t refreshes. My suggestion is that we ban usage of UPDATE for changing the refresher role (uac->uas etc).

Regards,

Christer

So I hesitate to ban that case unless allowing it causes some problem. 
The only possible problem I can see is if the two ends might disagree on whether the UPDATE is within an INVITE. This might occur if one end sends reINVITE and the other sends UPDATE more-or-less concurrently. But ISTM that case should be treated as glare. I think this can be covered by adding some text to the new draft talking about this case and spelling out that 491 should be used if this occurs.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Nov 2017 15:25:49 -0500

> I am not suggesting that we ban usage of UPDATE for s-t refreshes. My suggestion is that we ban usage of UPDATE for changing the refresher role (uac->uas etc).

(I figured you were going to say that.)

The problem with that is that the rules are then even more complicated. 
If the refresher parameter is omitted then it is offering to negotiate 
who does it. If it includes the refresher parameter then what value it 
uses has to be compared to the last negotiated refresher to determine if 
this is a change.

As the rfc is written it only discusses what should be done when 
refreshing. It doesn't explicitly talk about cases where reINVITE/UPDATE 
are being used primarily for other purposes. The case where the end that 
is *not* the refresher needs to send a reINVITE/UPDATE should be 
explicitly discussed. Such a case *does* refresh (or cancel) the session 
timer, and does have the potential to reassign the refresher.

IMO it is easier (and will make for clearer text) to make the UPDATE 
within INVITE the special case, and leave UPDATE outside of INVITE alone.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Nov 2017 05:26:25 +0000

Hi,

>>>> I agree with Paul that new option-tags etc aren't going to help. 
>>>> Also, in general, I think we should try to limit to impacts on different types of nodes.
>>>>
>>>> One suggestion would be to forbid the usage of UPDATE to change the 
>>>> refresher. If an endpoint wants to change the refresher it MUST send 
>>>> a (re-)INVITE to do so. And, new endpoints could discard the 
>>>> refresher value in received UPDATEs, which means they would work with legacy endpoints that may try to change the refresher in an UPDATE.
>>>>
>>>> I think Paul more or less suggested the same thing earlier ("the 
>>>> peer must mirror the refresher value"), eventhough I believe he was only talking about UPDATEs inside INVITE transaction.
>>>
>>> cases. Banning use of UPDATE outside for this purpose is a more 
>>> extreme case. (IMO, once you have a session, using an offerless 
>>> UPDATE for s-t refreshes is preferable unless you happen to also need 
>>> a concurrent O/A.)
>> 
>> I am not suggesting that we ban usage of UPDATE for s-t refreshes. My suggestion is that we ban 
>> usage of UPDATE for changing the refresher role (uac->uas etc).
>
> If the refresher parameter is omitted then it is offering to negotiate who does it. If it includes the 
> refresher parameter then what value it uses has to be compared to the last negotiated refresher to determine if this is a change.

The receiver anyway needs to have the previously negotiated value stored, in order to know whether it is the refresher or not.

> As the rfc is written it only discusses what should be done when refreshing. It doesn't explicitly talk about cases where reINVITE/UPDATE
> are being used primarily for other purposes. The case where the end that is *not* the refresher needs to send a reINVITE/UPDATE should
> be explicitly discussed. Such a case *does* refresh (or cancel) the session timer, and does have the potential to reassign the refresher.

Not if they don't change the value.

And, if an UPDATE is sent without the refresher value, the receiver would not be allowed to change the previously negotiated one.

> IMO it is easier (and will make for clearer text) to make the UPDATE within INVITE the special case, and leave UPDATE outside of INVITE alone.

So, just to make sure we are one the same page, how would that special case work?

Regards,

Christer

>> Cc: Christer Holmberg <[email-masked]>; Jesske, 
>> Roland <[email-masked]>; [email-masked]
>> revision than it is without it. (And I guess we should also figure 
>> out if it is any *better* before going ahead and doing this.)
>>
>> 	Thanks,
>> 	Paul
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Nov 2017 16:18:20 -0500

> So, just to make sure we are one the same page, how would that special case work?

My earlier message had a couple of alternative proposals for this:

https://mailarchive.ietf.org/arch/msg/sipcore/f3whYmpCxFLfWulW7ZE3xsURQfs

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Nov 2017 07:56:50 +0000

Hi,

>From an implementation perspective, isn¹t alternative 2 more or less what
I also suggest? The only difference is that I suggest to apply to rule to
every UPDATE - no matter whether it¹s embedded in an INVITE or not.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2017 09:49:25 -0500

> every UPDATE - no matter whether it¹s embedded in an INVITE or not.

The rules in (2) don't work for UPDATEs outside an INVTE. (When sending 
an UPDATE *outside* an INVITE you can't include the same s-t stuff as in 
the *enclosing* INVITE because there is no enclosing INVITE.) Also, with 
an UPDATE within an INVITE, whatever happens as a result of the UPDATE 
will quickly be overridden when processing the 200 for the INVITE.

Also, it is important here to analyze what happens when one or more of 
the parties in the dialog don't support this revision. I think (2) is in 
pretty good shape in that case.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 Nov 2017 13:32:27 -0500

On Tue, Nov 21, 2017 at 9:49 AM, Paul Kyzivat <[email-masked]> wrote:

> The rules in (2) don't work for UPDATEs outside an INVTE. (When sending an
> UPDATE *outside* an INVITE you can't include the same s-t stuff as in the
> *enclosing* INVITE because there is no enclosing INVITE.) Also, with an
> UPDATE within an INVITE, whatever happens as a result of the UPDATE will
> quickly be overridden when processing the 200 for the INVITE.
>
> Also, it is important here to analyze what happens when one or more of the
> parties in the dialog don't support this revision. I think (2) is in pretty
> good shape in that case.
>
>
How would the proxy know that UPDATE is outside of INVITE transaction? This
is not a very simple thing to determine for the proxy, especially if it is
a stateless proxies distributed across several servers. Such proxies do no
track transaction state and modify all SIP messages in stateless manner.

Also, If UPDATE is sent by the UAS from the INVITE transaction, there are
multiple race conditions, where UPDATE can be received by the other user
agent or a proxy before the 200 OK for the INVITE transaction.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2017 13:43:35 -0500

On 11/21/17 1:32 PM, Roman Shpount wrote:
> On Tue, Nov 21, 2017 at 9:49 AM, Paul Kyzivat <[email-masked] 
>                     within INVITE the special case, and leave UPDATE
>                     outside of INVITE
>                     alone.
> 
> 
>                 So, just to make sure we are one the same page, how
>                 would that special
>                 case work?
> 
> 
>             <https://mailarchive.ietf.org/arch/msg/sipcore/f3whYmpCxFLfWulW7ZE3xsURQfs>
> 
> 
>     The rules in (2) don't work for UPDATEs outside an INVTE. (When
>     sending an UPDATE *outside* an INVITE you can't include the same s-t
>     stuff as in the *enclosing* INVITE because there is no enclosing
>     INVITE.) Also, with an UPDATE within an INVITE, whatever happens as
>     a result of the UPDATE will quickly be overridden when processing
>     the 200 for the INVITE.
> 
>     Also, it is important here to analyze what happens when one or more
>     of the parties in the dialog don't support this revision. I think
>     (2) is in pretty good shape in that case.
> 
> 
> How would the proxy know that UPDATE is outside of INVITE transaction? 
> This is not a very simple thing to determine for the proxy, especially 
> if it is a stateless proxies distributed across several servers. Such 
> proxies do no track transaction state and modify all SIP messages in 
> stateless manner.

Stateless proxies shouldn't be messing with session timers. Isn't the 
whole point that they need the session timer so they can know when to 
discard state? If no state then no need for the timer.

> Also, If UPDATE is sent by the UAS from the INVITE transaction, there 
> are multiple race conditions, where UPDATE can be received by the other 
> user agent or a proxy before the 200 OK for the INVITE transaction.

If the recipient UA gets the UPDATE before the INVITE has completed then 
it can reject it as glare situation.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 Nov 2017 14:06:51 -0500

> it can reject it as glare situation.

UA might not always have a valid reason to reject the UPDATE, especially if
UPDATE does not carry SDP. Even if US rejects the UPDATE,  proxy would
still need to deal with this ambiguity when processing the UPDATE request,
which is hard to resolve even for state-full proxies that track
transactions.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2017 15:38:46 -0500

On 11/21/17 2:06 PM, Roman Shpount wrote:
> On Tue, Nov 21, 2017 at 1:43 PM, Paul Kyzivat <[email-masked] 
>         Also, If UPDATE is sent by the UAS from the INVITE transaction,
>         there are multiple race conditions, where UPDATE can be received
>         by the other user agent or a proxy before the 200 OK for the
>         INVITE transaction.
> 
> 
>     If the recipient UA gets the UPDATE before the INVITE has completed
>     then it can reject it as glare situation.
> 
> 
> UA might not always have a valid reason to reject the UPDATE, especially 
> if UPDATE does not carry SDP. Even if US rejects the UPDATE,  proxy 
> would still need to deal with this ambiguity when processing the UPDATE 
> request, which is hard to resolve even for state-full proxies that track 
> transactions.

I think we would need to include a new reason for generating 491 as part 
of this revision/clarification of s-t.

IIUC your concern is with proxies (presumably dialog-stateful) that want 
to request a s-t and also comply with this revision. I think they 
actually don't need to do anything different than they are already doing 
unless they have *not* made a s-t request in an INVITE and then *do* 
decide they want to do that when an UPDATE is sent within that UPDATE. I 
find that to be a far fetched situation. If they simply always request 
the same thing in every INVITE and UPDATE that goes by then they will be 
in compliance.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Nov 2017 08:55:35 +0000

Hi,

>the *enclosing* INVITE because there is no enclosing INVITE.)

When sending UPDATE *outside* an INVITE you include whatever s-t stuff has
been negotiated.

> Also, with an UPDATE within an INVITE, whatever happens as a result of
>the UPDATE

Correct, and that’s why an UPDATE within an INVITE should reflect whatever
will be in the 200 for the INVITE. It’s like sending SDP in an unreliable
18x - it’s not the official answer, but the content must still be the same
as in the answer :)

So, assume Alice sends INVITE with s-t;refresher=uac.

Bob will eventually send 200 OK with refresher=uac.

However, before the 200 OK, Bob sends an UPDATE, with refresher=uac.

>pretty good shape in that case.

I agree that such analyse is very important.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Nov 2017 10:13:52 +0000

Hi Paul,

Your proposal says:

"2) Specify that a UAC or proxy should duplicate in an embedded UPDATE
whatever timer stuff they put in the enclosing INVITE transaction. And
then the UAC for the INVITE should process the timer stuff in the 2xx
response to the INVITE the same as if the UPDATE didn't happen. (What it
does to process the timer stuff in the 200 for the UPDATE is irrelevant.)²

If I understand the text, I DO agree with it.

The difference is that I suggest that UPDATEs should never be allowed to
change the refresher value: inside an INVITE transaction they simply
mirror what is in the INVITE request, and outside an INVITE transaction
they mirror what has been negotiated. That way, I don¹t think entities
need to know whether the UPDATE is sent inside or outside an INVUTE
transaction, because the UPDATE is not allowed to change anything.

Regards,

Christer

---

From: <[email-masked]>
Date: Thu, 23 Nov 2017 10:43:49 +0000

Hi Christer et all,

What is if the SE in the UPDATE is changed?
Ignore?
I know exactly that we will have in reality. Big problems due to the fact that we will have all possible combinations of INVITE/UPDATE during the initial negotiation of the SE. 

So from my point of view we need clear statements.
Either do not allow SE in UPDATE during initial negotiation but with all possible combinations of SE settings and the expected reaction of the UAC/UAS/Proxy.
Or ignore everything within UPDATE and 200OK (UPDATE) according to SE within the initial negotiation of the session timer. And other messages (e.G PRACK ) send between INVITE with SE and 200 OK (INVITE) with the final negotiated SE.

Seen from this I would like to have Solution 1 from Paul. Extending to all other messages that could appear.

i.e.

Thank you and Best Regards

Roland

> Gesendet: Donnerstag, 23. November 2017 11:14
> An: Paul Kyzivat <[email-masked]>; Roman Shpount
> <[email-masked]>
> Cc: Jesske, Roland <[email-masked]>; [email-masked]
> whatever timer stuff they put in the enclosing INVITE transaction. And then the
> UAC for the INVITE should process the timer stuff in the 2xx response to the
> INVITE the same as if the UPDATE didn't happen. (What it does to process the
> timer stuff in the 200 for the UPDATE is irrelevant.)²
> 
> change the refresher value: inside an INVITE transaction they simply mirror
> what is in the INVITE request, and outside an INVITE transaction they mirror
> what has been negotiated. That way, I don¹t think entities need to know
> whether the UPDATE is sent inside or outside an INVUTE transaction, because
> the UPDATE is not allowed to change anything.
> 
> Regards,
> 
> Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 23 Nov 2017 15:20:45 -0500

On Tue, Nov 21, 2017 at 3:38 PM, Paul Kyzivat <[email-masked]> wrote:

> to request a s-t and also comply with this revision. I think they actually
> don't need to do anything different than they are already doing unless they
> have *not* made a s-t request in an INVITE and then *do* decide they want
> to do that when an UPDATE is sent within that UPDATE. I find that to be a
> far fetched situation. If they simply always request the same thing in
> every INVITE and UPDATE that goes by then they will be in compliance.
>

I think asking proxies to consistently add the same things to all UPDATE
and INVITE messages that are processed by proxies is the only possible
solution. Asking proxies to do things differently based on dialog state
would be impossible to implement.

Having more consistent rules for UAC/UAS on handling UDPATE during INVITE,
including dealing with potential collisions which can cause inconsistent
state, will be helpful .
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 23 Nov 2017 15:28:00 -0500

> transaction, because the UPDATE is not allowed to change anything.

There are cases when UPDATE is being used a simply "lighter" version of
re-INVITE with SDP. You can do the same things using UPDATE as you do using
re-INVITE, but you can do it using twice fewer messages. Breaking this
because of some corner case in Session-Timer negotiation greatly diminishes
UPDATE message utility.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Nov 2017 07:12:52 +0000

Hi,

Your proposal says:

> There are cases when UPDATE is being used a simply "lighter" version of re-INVITE with SDP. You can do the same things using UPDATE as you do using re-INVITE,
> but you can do it using twice fewer messages. Breaking this because of some corner case in Session-Timer negotiation greatly diminishes UPDATE message utility.

So, how often is the refresher changed during a call? As far as I know, in the vast majority of cases the session-timer negotiation takes place during the initial INVITE, and then it doesn’t change during the call.

Regards,

Christer

---

From: <[email-masked]>
Date: Fri, 24 Nov 2017 08:08:40 +0000

Hi Christer,
normally the refresher do not change you are right. But I have also seen cases where the refresher is toggling.
And it was working over hours.

There are also cases that both sides are sending refreshes. i.e they don't care.

Of course this use case is pointing to implementations which are not really compliant. But e Re-INVITE can be sent in each situation of the call.

Best Regards

Roland
Von: sipcore [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Freitag, 24. November 2017 08:13
An: Roman Shpount <[email-masked]>
Cc: [email-masked]; Jesske, Roland <[email-masked]>
Betreff: Re: [sipcore] Session timer fix

Hi,

Your proposal says:

> but you can do it using twice fewer messages. Breaking this because of some corner case in Session-Timer negotiation greatly diminishes UPDATE message utility.

So, how often is the refresher changed during a call? As far as I know, in the vast majority of cases the session-timer negotiation takes place during the initial INVITE, and then it doesn't change during the call.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sat, 25 Nov 2017 12:05:00 -0500

On Fri, Nov 24, 2017 at 2:12 AM, Christer Holmberg <
[email-masked]> wrote:

> So, how often is the refresher changed during a call? As far as I know, in
> the vast majority of cases the session-timer negotiation takes place during
> the initial INVITE, and then it doesn’t change during the call.
>
>
One possible reason for refresher change can be third party call control.
You have a B2BUA which is mostly stateless and relies on one of the user
agents to send session refresh. If as a result of B2BUA activity two
previously connected calls are connected to each other, both can previously
be refresher s (or neither of them would be a refresher), and refresher
role would need to be renegotiated.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Nov 2017 07:14:43 +0000

Hi,

Ok, so what making the restriction for UPDATEs sent inside (re-)INVITE transactions, as suggested by Paul (alternative #2)?

I.e., when an UPDATE is sent inside a (re-)INVITE transaction, the s-t values must reflect the values sent in the INVITE request/responses.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Saturday 25 November 2017 at 19:05
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Session timer fix

On Fri, Nov 24, 2017 at 2:12 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
So, how often is the refresher changed during a call? As far as I know, in the vast majority of cases the session-timer negotiation takes place during the initial INVITE, and then it doesn’t change during the call.

One possible reason for refresher change can be third party call control. You have a B2BUA which is mostly stateless and relies on one of the user agents to send session refresh. If as a result of B2BUA activity two previously connected calls are connected to each other, both can previously be refresher s (or neither of them would be a refresher), and refresher role would need to be renegotiated.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 27 Nov 2017 16:54:20 -0500

Hi,

I think restriction that UPDATE sent within (re-)INVITE must match the
Session-Timer value sent in INVITE request/responses should work. The
question is how do you deal with 2XX responses from non-compliant
implementations.

To summarize, what you are proposing :

1. When UAC is sending UPDATE during INVITE transaction, it should put the
same value in S-T as it put in the original INVITE
2. When proxy adds S-T header to UPDATE, is should add it in such as way
that it would match S-T header added by this proxy to INVITE
3. UAS should respond to UPDATE with the same S-T header value as for the
2XX response in enclosing INVITE transaction.
4. When sending UPDATE during INVITE transaction UAS should add the same
S-T header value as for the 2XX response in enclosing INVITE transaction.
5. If during INVITE transaction UA receives an UPDATE which does not match
S-T header of the INVITE message, it should send 491 (or other new error)
response to UPDATE

Questions:

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

Regards,

_____________
Roman Shpount

On Mon, Nov 27, 2017 at 2:14 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> Ok, so what making the restriction for UPDATEs sent inside (re-)INVITE
> transactions, as suggested by Paul (alternative #2)?
>
> I.e., when an UPDATE is sent inside a (re-)INVITE transaction, the s-t
> values must reflect the values sent in the INVITE request/responses.
>
> Regards,
>
> Christer
>
> From: Roman Shpount <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
>> So, how often is the refresher changed during a call? As far as I know,
>> in the vast majority of cases the session-timer negotiation takes place
>> during the initial INVITE, and then it doesn’t change during the call.
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Nov 2017 07:51:53 +0000

Hi,

> I think restriction that UPDATE sent within (re-)INVITE must match the Session-Timer value sent in INVITE request/responses should work.
> The question is how do you deal with 2XX responses from non-compliant implementations.
>
> 1. When UAC is sending UPDATE during INVITE transaction, it should put the same value in S-T as it put in the original INVITE

Yes.

> 2. When proxy adds S-T header to UPDATE, is should add it in such as way that it would match S-T header added by this proxy to INVITE

Yes.

The RFC already says:

'The proxy MUST NOT insert or modify the value of the 'refresher' parameter in the Session-Expires header field.'

…so as long as the UA doesn’t change the ‘refresher parameter it shouldn’t be a problem.

> 3. UAS should respond to UPDATE with the same S-T header value as for the 2XX response in enclosing INVITE transaction.

Yes.

> 4. When sending UPDATE during INVITE transaction UAS should add the same S-T header value as for the 2XX response in enclosing INVITE transaction.

Yes.

> 5. If during INVITE transaction UA receives an UPDATE which does not match S-T header of the INVITE message, it should send 491 (or other new error) response to UPDATE

Yes.

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

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Nov 2017 14:48:56 -0500

Hi,

On Tue, Nov 28, 2017 at 2:51 AM, Christer Holmberg <
[email-masked]> wrote:

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

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Nov 2017 19:53:19 +0000

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

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.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2017 15:30:49 -0500

> 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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Nov 2017 15:38:24 -0500

On Tue, Nov 28, 2017 at 3:30 PM, Paul Kyzivat <[email-masked]> wrote:

>>>> not match the S-T value
>> 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.
>>
>
> 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.
>

The safest option is to ignore the error if the end point thinks that
refresher is UAC and do an UPDATE transaction if end point thinks refresher
is UAS. This looks like a better option then hang up or simply ignoring the
error.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2017 15:54:57 -0500

On 11/28/17 3:38 PM, Roman Shpount wrote:
> On Tue, Nov 28, 2017 at 3:30 PM, Paul Kyzivat <[email-masked] 
>                 1. What happens when UAC receives a 2XX INVITE response
>                 with S-T that did not match the S-T value
>                 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.
> 
>         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.
> 
> 
>     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.
> 
> 
> refresher is UAC and do an UPDATE transaction if end point thinks 
> refresher is UAS. This looks like a better option then hang up or simply 
> ignoring the error.

Refining that a bit:

If the INVITE transaction completes with a 2xx, then the UA that is 
nominated to be the UAS based on the 200/INVITE should consider if there 
was an intervening UPDATE that asked that UA to be the UAC. If so, then 
it should initiate a new UPDATE transaction to verify the roles. In that 
request, if it can do either role then it should not specify and thus 
let other end decide.

Perhaps we can refine this so that we can avoid being any more normative.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Tue, 28 Nov 2017 22:33:47 +0000

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

> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Dienstag, 28. November 2017 21:31
> An: Christer Holmberg <[email-masked]>; Roman Shpount
> <[email-masked]>
> >>> 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.
> >>
> specific behaviour, as long as we make it clear that an error has occurred and
> it needs to be taken care of SOMEHOW.
> 
> 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?
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Nov 2017 18:06:41 -0500

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]> wrote:

> 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
>
>
> time a
> of

---

From: <[email-masked]>
Date: Wed, 29 Nov 2017 00:46:19 +0000

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.

So what will the UAC do. The proxy has added the S-E.
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.

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,

Best Regards

Roland

> Von: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
> 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]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Nov 2017 20:04:26 -0500

Roland,

This is not exactly wrong but this User Agent is asking for trouble and
should be fixed.

1. UAC should not send INVITE with Session Expires header unless it was
previously negotiated. User Agents do not need Session Expires, it was
designed for proxies to deal with dialog expiration. User Agent can send
re-INVITE or UPDATE at any time on its own to check the presence of the
dialog. There is no need negotiate this.

2. If UAC does send Session Expires in the INVITE (sometimes is needed by
B2BUA with limited state), it should add the same S-E header to UPDATE --
this will prevent proxy from adding S-E to UPDATE. *If you are going to fix
one thing, fix this.*

3. Proxy should never modify S-E in the response. This is against the
specifications.

For User Agent which got two responses with different Session Timer values,
it is safe to pick the smaller if it is a refresher or larger, if other UA
is a refresher. If it got responses that have different refresher values,
it is safe to assume that UA is the refresher. Also, after INVITE
transaction completes, when in doubt, UA can send a new UPDATE without
refresher value and S-E header to sort this thing out.

Regards,

_____________
Roman Shpount

On Tue, Nov 28, 2017 at 7:46 PM, <[email-masked]> wrote:

> 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.
>
>
>
> 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?
>
>
>
> *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,
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2017 20:25:41 -0500

Roland,

I will reply to your later messages in this thread, but also have a 
comment here.

> One is that the UA does not support UPDATE.

If UPDATE isn't supported by one of the UAs then it won't be sent, and 
none of the issues we have been discussing come into play.

> Also the direction of the UPDATE is important.

Why? It has subtle distinctions, but IIUC the issues we have been 
concerned with are the same.

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

If the proxy inserts the same S-E in the UPDATE and INVITE then I don't 
see a problem.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 29 Nov 2017 01:27:24 +0000

Hi Roman,
Yes that is what I would like to see but reality is something other.

So the UAC/UAS could be some border element within your network. In ours the S-E will be negotiated by the first proxy within the network.
We have interconnection situations where we have no influence on other proxies.

That what I have described is conformant with RFC4028.

See below

>Von: Roman Shpount [mailto:[email-masked]] 
>Gesendet: Mittwoch, 29. November 2017 02:04
>This is not exactly wrong but this User Agent is asking for trouble and should be fixed.
 >

>1. UAC should not send INVITE with Session Expires header unless it was previously negotiated. 
>User Agents do not need Session Expires, it was designed for 
>proxies to deal with dialog expiration. User Agent can send re-INVITE or UPDATE 
>at any time on its own to check the presence of the dialog. There is no need 
>negotiate this.

[RJ] Section 7.1 ... A UAC MAY include the Min-SE header field in the initial INVITE
   request....

>2. If UAC does send Session Expires in the INVITE (sometimes is needed by B2BUA with limited state),
> it should add the same S-E header to UPDATE -- this will 
>prevent proxy from adding S-E to UPDATE. *If you are going to fix one thing, fix this.*

[RJ] In this case the UPDATE is sent by the UAS with a supported "timer" so the proxy has added the S-E.
Yes I agree that the UPDATE sent should have then the S-E but this needs to be clarified.

>3. Proxy should never modify S-E in the response. This is against the specifications.

[RJ] There is no modification within the 200 OK since this use case assumes that the UA does not add any S-E because of ignoring the UPDATE.
But the Proxy is following this rule out of RFC4028 8.1:

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

So the Proxy remembers the value it has put by itself into the UPDATE.

>For User Agent which got two responses with different Session Timer values
>,it is safe to pick the smaller if it is a refresher or larger, if other UA is a refresher.
> If it got responses that have different refresher values, it is safe to assume that UA is the refresher.
> Also, after INVITE transaction completes, when in doubt, UA 
>can send a new UPDATE without refresher value and S-E header to sort this thing out.

Regards,

_____________
Roman Shpount

On Tue, Nov 28, 2017 at 7:46 PM, <mailto:[email-masked]> wrote:
Hi Roman,

 

 

Best Regards
 
Roland

Von: sipcore [mailto:mailto:[email-masked]] Im Auftrag von Roman Shpount
Gesendet: Mittwoch, 29. November 2017 00:07
An: Jesske, Roland <mailto:[email-masked]>
Cc: SIPCORE <mailto:[email-masked]>

Roland,

Regards,
_____________
Roman Shpount
 
On Tue, Nov 28, 2017 at 5:33 PM, <mailto:[email-masked]> wrote:
Hi Paul,

Best Regards

Roland

> Von: Paul Kyzivat [mailto:mailto:[email-masked]]
> An: Christer Holmberg <mailto:[email-masked]>; Roman Shpount
> <mailto:[email-masked]>
> Cc: Jesske, Roland <mailto:[email-masked]>; mailto:[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Nov 2017 20:37:50 -0500

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

> 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

>     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
> 
> 
>      > An: Christer Holmberg <[email-masked]
>     <mailto:[email-masked]>>; Roman Shpount
>      > <[email-masked] <mailto:[email-masked]>>
>      > Cc: Jesske, Roland <[email-masked]
>     mandate any

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Nov 2017 07:31:36 +0000

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:

>> UAC (Which has sent the INVITE) could ignore and send 200 OK without
>>any 
>> S-E. i.e. ignoring UPDATE.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Nov 2017 11:35:04 -0500

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 29 Nov 2017 13:38:45 -0500

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.

Regards,
_____________
Roman Shpount

On Wed, Nov 29, 2017 at 11:35 AM, Paul Kyzivat <[email-masked]>
wrote:

> 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.
>
> 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
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>>>>       > specific behaviour, as long as we make it clear that an error
>>>> has
>>>>      occurred and
>>>>       > 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
>>>>       > If need be we can work through all the cases. But there are
>>>> quite
>>>>      a lot of
>>>>       > them.
>>>>       >
>>>>       >       Thanks,
>>>>       >       Paul
>>>>
>>>>
>>>>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 29 Nov 2017 13:48:48 -0500

Roland,

Two more comments about your original scenario:

4. Proxy is not behaving in a consistent manner. If proxy needs expires the
dialog after 1800 seconds, it should reduce the S-E value in INVITE to 1800
seconds. If proxy expires the dialog after 3600 seconds, it should insert
3600 in UPDATE.

5. UAS knows the expiration time for the dialog when it processed the
request. It should respond with the dialog refresh value, not the value
from request. Since, in your example, dialog expiration time got set to
1800 by UPDATE transaction, it should respond with 1800 to both UPDATE and
INVITE regardless of the S-E value in INVITE.

If you look at the rules that we are proposing, you will see that if either
UAC or UAS followed these rules, the problem would not occur.

Regards,

_____________
Roman Shpount

On Tue, Nov 28, 2017 at 8:27 PM, <[email-masked]> wrote:

> So the UAC/UAS could be some border element within your network. In ours
> the S-E will be negotiated by the first proxy within the network.
> previously negotiated.
> B2BUA with limited state),
> [RJ] There is no modification within the 200 OK since this use case
> assumes that the UA does not add any S-E because of ignoring the UPDATE.

---

From: <[email-masked]>
Date: Thu, 30 Nov 2017 01:32:26 +0000

Hi Paul,
Thank you for your comments.
At least I fully agree with you assumption and I think we need then a proper description. To avoid such stupid implementations.

Best Regards

Roland

> Von: sipcore [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Mittwoch, 29. November 2017 02:38
> An: [email-masked]
> 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.
> 
Yes that would be the correct way, but this is not described within RFC4028 fo rthe proxy behavior.
We should add this.
> What you have demonstrated here is that there is an issue with the S-E value
> as well as with the refresher role.
> 
> > 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.
> >
> > 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?
> >
> 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.
> 

I fully agree.
> 
> 	Thanks,
> 	Paul
> 
> > Best Regards
> >
> > Roland
> >
> > *Von:* sipcore [mailto:[email-masked]] *Im Auftrag von
> > *Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Nov 2017 08:39:04 +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.

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.

Regards,

Christer

On 29/11/17 18:35, "Paul Kyzivat" <[email-masked]> wrote:

>>>> Now UAS is sending UPDATE with a supported timer and Proxy adds S-E
>>>>due
>>>> to local policy with S-E 1800.
>>>
>>>> may
>>>>as
>>>>*Roman
>>>>with
>>>> S-T
>>>>with
>>>> S-T
>>>>       > >> How do you want to handle these error cases? Two options
>>>>that
>>>>      I see are:
>>>>       > 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?
>>>>       >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Nov 2017 11:38:25 -0500

> UDPATE, because the INVITE is rejected.

OK, that is an issue.

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

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Nov 2017 14:43:47 -0500

>> UDPATE, because the INVITE is rejected.

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.

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

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.

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.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Nov 2017 15:43:54 -0500

On 11/30/17 2:43 PM, Roman Shpount wrote:
> 
> On Thu, Nov 30, 2017 at 11:38 AM, Paul Kyzivat <[email-masked] 
> 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.

IIUC, Christer is saying that an existing implementation is failing the 
INVITE after getting conflicting values in the UPDATE. And so he is 
proposing that we revise things so that if at least one side supports 
the revision that won't happen.

> 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.
> 
>     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.
> 
> 
> s-e or min-s-e in general. There is little or no reason why what proxy 
> does should change from transaction-to-transaction.
> 
> 2. Proxy inserts S-E set to 3600 since it expects dialogs to expire 
> after an hour
> 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.

A proxy that isn't dialog stateful should not be messing with s-t, nor 
should it need to.

> Proposed solution -- UAS should pick the smallest S-E value and use that.

This of course won't work if the UAS doesn't support the update. There 
is nothing that the UAC or the Proxy could do to salvage this case.

I think it should be our goal to make things work with the minimum 
number of the participants supporting the revision, but clearly this is 
a case where the UAS must support the revision.

OTOH, if the UAS had happened to simply accept *either* the 3600 or 1800 
value, then the UAC would be able to fix it with a followon UPDATE.

So I think it will be important to state what this revision can and 
cannot do.

	Thanks,
	Paul