Subject: [sipcore] session-timer fix

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Mar 2018 11:15:20 -0400

Here is the primary use case flow that has been reported as the 
motivating case for the draft. (I've reformatted it for ease in typing.)

  1) UA->Proxy: INVITE/SE:uac
  2) Proxy->AS: INVITE/SE:uac
  3) AS->Proxy: 18x/no-SE
  4) Proxy->UA: 18x/no-SE
  5) AS->Proxy: UPDATE/SE:uas
  6) Proxy->UA: UPDATE/SE:uas
  7) UA->Proxy: 200(UPDATE)/no-SE
  8) Proxy->AS: 200(UPDATE)/SE:uac
  9) AS->Proxy: 480(INVITE)
10) Proxy->UA: 480(INVITE)

Some observations on the above:

- in (5) the AS includes SE in the UPDATE, while in (7) the UA
   doesn't include SE in the response to the UPDATE. This seems
   to reflect a difference of opinion by the implementors of
   the UA and AS about what 4028 expects in this situation.
   This ambiguity needs to be resolved, and will require changes
   in some implementations.

- The 480 in (9) is caused by the AS objecting to the "uac"
   in (8) because it is in conflict with the "uas" in (5).
   This in turn is caused by the proxy including the "uac"
   in (8) because it is following the rules and thinks that
   the UA doesn't support S-T. This of course isn't the
   situation.

- There has been some discussion about whether the "uas"
   value in (5) is consistent with the "uac" value in (1).
   I think it is, since the uac/uas roles are relative to
   the direction of the individual request, and (5) is
   going in the opposite direction of (1). But this
   doesn't seem to affect the rest of the analysis.
   If the refresher in the UPDATE was inconsistent with
   that in the INVITE then I would expect the UA to send
   an error response to the UPDATE.

ISTM that at least part of the fix for this must be to fix the ambiguity 
about whether SE is to be included in an UPDATE and its response that 
are embedded in an INVITE transaction. The existing draft does address 
this one way.

Another way to address it would be to require SE to be included in both 
the UPDATE and its response, in a way consistent with what was in the 
INVITE and will eventually be in the response to the INVITE.

A much different way would be to require that the timer negotiation in 
an INVITE be completed in the first reliable response to the INVITE, 
either 2xx or reliable 1xx. Then any UPDATE that followed within the 
transaction would presumably start a new timer negotiation.

I'll also observe that this entire discussion has focused on the 
negotiation of the refresher. But there is a comparable issue around 
negotiating the duration of the timer. That ought to be sorted out as 
part of the same fix.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Mar 2018 20:48:32 +0000

Hi Paul,

You say (and it was indicated in the meeting):

   "I think it is, since the uac/uas roles are relative to
   the direction of the individual request,"

Assuming that the AS and UA are implemented that way, the problem still occurs when the AS receives (8), where the refresher 

>Here is the primary use case flow that has been reported as the motivating case for the draft. (I've reformatted it for ease in typing.)
>

Correct. This is a case where UPDATE is received while the S-T negotiation is still ongoing.

>   the UA doesn't support S-T. This of course isn't the

Shouldn't the proxy know that the UA supports S-T, due to (1)?

>   going in the opposite direction of (1).

Let's assume it is like that.

> But this
> ISTM that at least part of the fix for this must be to fix the ambiguity about whether SE is to be included in an 
> UPDATE and its response that are embedded in an INVITE transaction. The existing draft does address this one way.

Yes.

> Another way to address it would be to require SE to be included in both the UPDATE and its response, in a way 
> consistent with what was in the INVITE and will eventually be in the response to the INVITE.

Yes.

> A much different way would be to require that the timer negotiation in an INVITE be completed in the first reliable
> response to the INVITE, either 2xx or reliable 1xx. Then any UPDATE that followed within the transaction would 
> presumably start a new timer negotiation.

Yes.

> I'll also observe that this entire discussion has focused on the negotiation of the refresher. But there is a comparable
> issue around negotiating the duration of the timer. That ought to be sorted out as part of the same fix.

Yes.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 11:56:14 +0000

Hi,

Ok, I checked some old e-mails, and had a chat with the internal people
that informed me about the problem.

The UPDATE request with refresher=uas is *NOT* the problem. They have the
same assumption as Paul, Jonathan etc - the value is indicated per
transaction. So, UPDATE with refresher=uas is ok. My apologies for mixing
that up.

It¹s the UPDATE 200 OK response, where the proxy inserts refresher=uac,
that causes the problem.

So, one alternative would be to allow UPDATE requests/responses sent while
the s-t negotiation is ongoing are handled as defined in RFC 4028, but
that the refresher value must not be changed.

In the case below, that means that the UA needs to include s-t information
in the UPDATE response (message #7).

Regards,

Christer

On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Assuming that the AS and UA are implemented that way, the problem still
>occurs when the AS receives (8), where the refresher
>
>
>
>
>> ISTM that at least part of the fix for this must be to fix the
>>ambiguity about whether SE is to be included in an
>> UPDATE and its response that are embedded in an INVITE transaction. The
>>existing draft does address this one way.
>
>Yes.
>
>>the UPDATE and its response, in a way
>>an INVITE be completed in the first reliable
>> response to the INVITE, either 2xx or reliable 1xx. Then any UPDATE
>>that followed within the transaction would
>>negotiation of the refresher. But there is a comparable
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Mar 2018 11:57:13 -0400

> in the UPDATE response (message #7).

That seems like a simpler and cleaner fix, at least for this case.

To go that way we need to consider other cases.

In particular, is the UA *required* to include the s-t stuff in the 
UPDATE if it supports s-t?

What if the UA had omitted the refresher in the INVITE? Presumably then 
the AS chooses and puts its choice in the UPDATE.

And once s-e in invite has been responded to with an s-e in an UPDATE, 
does that finish the negotiation? Then do subsequent messages within the 
invite transaction and embedded UPDATES repeat the agreed upon result? 
Or can they do the negotiation over?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 17:13:17 +0000

Hi,

>> Ok, I checked some old e-mails, and had a chat with the internal 
>> people that informed me about the problem.
>> 
>> The UPDATE request with refresher=uas is *NOT* the problem. They have 
>> the same assumption as Paul, Jonathan etc - the value is indicated per 
>> transaction. So, UPDATE with refresher=uas is ok. My apologies for 
>> mixing that up.
>> 
>> It¹s the UPDATE 200 OK response, where the proxy inserts 
>> refresher=uac, that causes the problem.
>> 
>> So, one alternative would be to allow UPDATE requests/responses sent 
>> while the s-t negotiation is ongoing are handled as defined in RFC 
>> 4028, but that the refresher value must not be changed.
>> 
>> In the case below, that means that the UA needs to include s-t 
>> information in the UPDATE response (message #7).
>
> In particular, is the UA *required* to include the s-t stuff in the UPDATE if it supports s-t?

Min-SE is currently MUST.

Session-Expires is currently SHOULD. I guess we could change that to MUST.

> What if the UA had omitted the refresher in the INVITE? Presumably then the AS chooses and puts its choice in the UPDATE.
>
> And once s-e in invite has been responded to with an s-e in an UPDATE, does that finish the negotiation?

Yes. The INVITE transaction itself does not matter - it depends on whether s-e is negotiated within the INVITE transaction or not that matters. If there is no s-e negotiation in the INVITE transaction, the UPDATE is treated as any mid-dialog request as far as s-e is concerned.

> Then do subsequent messages within the invite transaction and embedded UPDATES repeat the agreed upon result? 

Since there is no ongoing s-e negotiation, I see no reason why they can't.

In general, unless such text already exist, I think we should recommend against re-negotiating , unless there is a good reason for it.

Regards,

Christer

>> Assuming that the AS and UA are implemented that way, the problem 
>> still occurs when the AS receives (8), where the refresher
>>
>>
>>
>>
>>> ambiguity about whether SE is to be included in an UPDATE and its 
>>> response that are embedded in an INVITE transaction. The existing 
>>> draft does address this one way.
>>
>> Yes.
>>
>>> Another way to address it would be to require SE to be included in 
>>> both the UPDATE and its response, in a way consistent with what was 
>>> in the INVITE and will eventually be in the response to the INVITE.
>>
>> Yes.
>>
>>> A much different way would be to require that the timer negotiation 
>>> in an INVITE be completed in the first reliable response to the 
>>> INVITE, either 2xx or reliable 1xx. Then any UPDATE that followed 
>>> within the transaction would presumably start a new timer 
>>> negotiation.
>>
>> Yes.
>>
>>> negotiating the duration of the timer. That ought to be sorted out 
>>> as part of the same fix.
>>
>> Yes.
>>
>> Regards,
>>
>> Christer
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Mar 2018 16:06:15 -0400

> In general, unless such text already exist, I think we should recommend against re-negotiating , unless there is a good reason for it.

I guess I didn't make my concerns clear.

ISTM we could use O/A rules as a *model* here:

A negotiation initiated in an INVITE can be completed in a reliable 
response to the INVITE. Or it can be completed in an UPDATE. Once 
complete, another negotiation is forbidden within the same INVITE 
transaction. I guess we would change the rules a bit in that we don't 
allow the negotiation to be completed in a reliable provisional. (I 
would like to permit that, but I think it might be a step too far for 
compatibility.)

But, if we forbid further negotiation within the same INVITE, what do we 
do instead if there are further UPDATEs? With O/A we can just leave the 
offers out. With s-t, leaving it out normally means negotiating it off. 
So either we change that (which we have already explored), or else I 
guess we "negotiate" again but agree to only repeat what has already 
been negotiated. (And if we make that rule, what do we do if it is 
violated? Especially, what if a proxy violates it?)

Alternately, once the s-t negotiation has completed, we could simply 
allow another negotiation to be initiated within the same invite 
transaction, even though it seems like a stupid thing to do.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 20:51:45 +0000

Hi,

>>>> The UPDATE request with refresher=uas is *NOT* the problem. They 
>>>> have the same assumption as Paul, Jonathan etc - the value is 
>>>> indicated per transaction. So, UPDATE with refresher=uas is ok. My 
>>>> apologies for mixing that up.
>>>>
>> Yes. The INVITE transaction itself does not matter - it depends on whether s-e is negotiated within the INVITE 
>> transaction or not that matters. If there is no s-e negotiation in the INVITE transaction, the UPDATE is treated as 
>> any mid-dialog request as far as s-e is concerned.
>> 
> A negotiation initiated in an INVITE can be completed in a reliable response to the INVITE. Or it can be completed in an UPDATE. 
> Once complete, another negotiation is forbidden within the same INVITE transaction. I guess we would change the rules a bit in 
> that we don't allow the negotiation to be completed in a reliable provisional. (I would like to permit that, but I think it might be a step too far for
> compatibility.)
>
> But, if we forbid further negotiation within the same INVITE, what do we do instead if there are further UPDATEs? With O/A we can just leave the offers out. 
> With s-t, leaving it out normally means negotiating it off. 
> So either we change that (which we have already explored), or else I guess we "negotiate" again but agree to only repeat what has already been 
> negotiated. (And if we make that rule, what do we do if it is violated? Especially, what if a proxy violates it?)

My idea was that, if UPDATEs are send during an ongoing INVITE s-t negotiation, the s-t information in the UPDATEs must reflect the ongoing negotiation (similar as sending SDP in an unreliable 18x - it is not really an answer, but it must be a copy of the to-be-sent-answer). So, in my example, the s-t information in the UPDATE request from the AS must reflect what the AS will eventually send in the 200 OK to the INVITE. And, the s-t information in the UPDATE response from the UA must reflect what the UA sent in the INVITE. 

> Alternately, once the s-t negotiation has completed, we could simply allow another negotiation to be initiated within the same
> invite transaction, even though it seems like a stupid thing to do.

I agree.

Regards,

Christer

>>>> negotiation of the refresher. But there is a comparable issue 
>>>> around negotiating the duration of the timer. That ought to be 
>>>> sorted out as part of the same fix.
>>>
>>> Yes.
>>>
>>> Regards,
>>>
>>> Christer
>>>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Mar 2018 17:51:29 -0400

Paul and Christer,

First of all, I agree that in the initial scenario, UA in step 7 should
have responded with S-E:uas in 200 OK for Update.

Furthermore, if UA in step 7 did respond without S-E, or with S-E:uac, AS
should not have sent 480 in step 9. It should have sent S-E:uas.

Generally, what I am proposing is that, S-E header should be generated
based on the S-E status when request or response is generated. If there are
multiple inter-lapping transactions S-E state can change and S-E state in
the response should be set to the S-E value when response is generated, not
when the original request is received. In case of your example, S-E state
in step 9 should be based on results of the UPDATE transaction, not the
initial INVITE. This is why it should be sent to S-E:uas.

Furthermore, we should restrict (with SHOULD, not MUST since existing UA
already violate this) that UA should avoid generating requests which will
change the current S-E status when another transaction which negotiates S-E
is in progress. Specifically, in the example provided, UPDATE in step 5
should be generated with S-E:uas (as it was correctly generated in your
example). Responses generated when another transaction is in progress
should be generated in a way that avoids changing the current S-E status
(response in step 7 should have been  S-E:uas).

Finally, even with all of these restrictions there are situations when S-E
status is unclear due to timing. For instance when UPDATE changing the S-E
status is sent at roughly the same time as 200 OK for an INVITE. In this
case, UA cannot distinguish

Scenario A:
1) UA->AS: INVITE/SE
2) AS->UA: UPDATE/SE:uac
3) UA-> AS: 200(UPDATE)/SE:uac
4) AS-> UA : 200(INVITE) /SE:uac

and

Scenario B:
1) UA->AS: INVITE/SE
2) AS-> UA : 200(INVITE) /SE:uac
3) AS->UA: UPDATE/SE:uac
4) UA-> AS: 200(UPDATE)/SE:uac

Between those two scenarios, either AS or UA becomes a refresher based on
the message delivery timing.

These scenarios do not violate any of the proposed rules and can be encountered
with existing SIP implementations. Also, these ambiguity cannot be resolved
with refusing UPDATE request with retry after since UA does not know that
200 OK and UPDATE are sent close together.

My suggestion is to specify that 200 OK changing S-E status MUST NOT be
sent when UPDATE transaction is in progress. UPDATE changing S-E status
MUST NOT be sent when 200 OK was sent but ACK was not yet received.

I would be very interested if you can think of other, more robust ways to
detect and deal with this situation which require modifications only for
one of the SIP UA.

Regards,

_____________
Roman Shpount

On Wed, Mar 28, 2018 at 4:51 PM, Christer Holmberg <
[email-masked]> wrote:

> >>> What if the UA had omitted the refresher in the INVITE? Presumably
> then the AS chooses and puts its choice in the UPDATE.
> >>>
> does that finish the negotiation?
> >>
> >> Yes. The INVITE transaction itself does not matter - it depends on
> whether s-e is negotiated within the INVITE
> >> transaction or not that matters. If there is no s-e negotiation in the
> INVITE transaction, the UPDATE is treated as
> >> In general, unless such text already exist, I think we should recommend
> against re-negotiating , unless there is a good reason for it.
> >
> response to the INVITE. Or it can be completed in an UPDATE.
> > Once complete, another negotiation is forbidden within the same INVITE
> transaction. I guess we would change the rules a bit in
> > that we don't allow the negotiation to be completed in a reliable
> provisional. (I would like to permit that, but I think it might be a step
> too far for
> > compatibility.)
> >
> offers out.
> guess we "negotiate" again but agree to only repeat what has already been
> > negotiated. (And if we make that rule, what do we do if it is violated?
> Especially, what if a proxy violates it?)
>
> My idea was that, if UPDATEs are send during an ongoing INVITE s-t
> negotiation, the s-t information in the UPDATEs must reflect the ongoing
> negotiation (similar as sending SDP in an unreliable 18x - it is not really
> an answer, but it must be a copy of the to-be-sent-answer). So, in my
> example, the s-t information in the UPDATE request from the AS must reflect
> what the AS will eventually send in the 200 OK to the INVITE. And, the s-t
> information in the UPDATE response from the UA must reflect what the UA
> sent in the INVITE.
>
> allow another negotiation to be initiated within the same

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Mar 2018 11:07:57 +0000

Hi Roman,

> First of all, I agree that in the initial scenario, UA in step 7 should have responded with S-E:uas in 200 OK for Update.
>
> Furthermore, if UA in step 7 did respond without S-E, or with S-E:uac, AS should not have sent 480 in step 9. It should have sent S-E:uas.
>
> Generally, what I am proposing is that, S-E header should be generated based on the S-E status when request or response is generated. If there are multiple inter-lapping transactions S-E state can change and
> S-E state in the response should be set to the S-E value when response is generated, not when the original request is received. In case of your example, S-E state in step 9 should be based on results of the UPDATE
> transaction, not the initial INVITE. This is why it should be sent to S-E:uas.
>
> Furthermore, we should restrict (with SHOULD, not MUST since existing UA already violate this) that UA should avoid generating requests which will change the current S-E status when another transaction which negotiates S-E is in progress.
> Specifically, in the example provided, UPDATE in step 5 should be generated with S-E:uas (as it was correctly generated in your example). Responses generated when another transaction is in progress should be generated in a way that avoids
> changing the current S-E status (response in step 7 should have been  S-E:has).
>
>
>Finally, even with all of these restrictions there are situations when S-E status is unclear due to timing. For instance when UPDATE changing the S-E status is sent at roughly the same time as 200 OK for an INVITE. In this case, UA cannot distinguish
>
>Scenario A:
>1) UA->AS: INVITE/SE
>2) AS->UA: UPDATE/SE:uac
> Between those two scenarios, either AS or UA becomes a refresher based on the message delivery timing.

Why would the AS send SE:mac in message 4)?
>
> These scenarios do not violate any of the proposed rules and can be encountered with existing SIP implementations. Also, these ambiguity cannot be resolved with refusing UPDATE request with retry after since UA does not know that 200 OK and UPDATE are sent close together.
>
> My suggestion is to specify that 200 OK changing S-E status MUST NOT be sent when UPDATE transaction is in progress. UPDATE changing S-E status MUST NOT be sent when 200 OK was sent but ACK was not yet received.
>
> I would be very interested if you can think of other, more robust ways to detect and deal with this situation which require modifications only for one of the SIP UA.

I am not sure whether your suggestion is any different than mine: UPDATE requests/responses sent within an going INVITE s-e negotiation must not change the roles – they must reflect whatever was sent in the INVITE request and will be sent in the 200 (INVITE) response.

Regards,

Christer

On Wed, Mar 28, 2018 at 4:51 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I agree.

Regards,

Christer

>> <[email-masked]<mailto:[email-masked]> on behalf of
>> [email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>> Hi Paul,
>>>
>>> [email-masked]<mailto:[email-masked]>

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Mar 2018 11:21:18 -0400

ISTM an important question is: when does the result of this negotiation 
take effect? Whenever that is, it overrides an prior s-t (or non-s-t), 
and presumably can no longer be rolled back if a (re)invite fails. This 
matters, because it establishes when the timer will expire.

For instance, if there is s-t in invite, and response to it in UPDATE, 
does the new timer start then? Or does it only start when the invite 
transaction is complete?

If it starts as soon as the response is sent in the UPDATE, then what is 
the significance of additional s-t headers in subsequent messages until 
the invite transaction is complete? They could be forbidden, or required 
to match the first "response", or we could allow them to carry out a 
completely new negotiation.

If it only starts when the invite transaction is complete, then any 
subsequent s-e and min-s-e could again be forbidden, or required to 
match the first "response", or carry out a completely new negotiation 
that, when completed would override the earlier negotiated value. But in 
this case, if the invite fails, none of that would change the s-t state 
in effect prior to the invite.

More inline

On 3/29/18 7:07 AM, Christer Holmberg wrote:
>  > S-E state in the response should be set to the S-E value when 
> response is generated, not when the original request is received. In 
> case of your example, S-E state in step 9 should be based on results of 
> the UPDATE
>  > Specifically, in the example provided, UPDATE in step 5 should be 
> generated with S-E:uas (as it was correctly generated in your example). 
> Responses generated when another transaction is in progress should be 
> generated in a way that avoids

Because the time value in the s-e is a duration, rather than a 
data-time, there is the question of when the conversion to date-time is 
done. If it is done when the s-e header is sent/received, then sending a 
exact copy of that same header still constitutes a change to the s-e status.

> status is unclear due to timing. For instance when UPDATE changing the 
> S-E status is sent at roughly the same time as 200 OK for an INVITE. In 
> this case, UA cannot distinguish
>>
>>Scenario  A:
>>1)  UA->AS: INVITE/SE
>>2)  AS->UA: UPDATE/SE:uac
>>2)  AS->UA: 200(INVITE)/SE:uac
>>3)  AS->UA: UPDATE/SE:uac
>>4)  UA->AS: 200(UPDATE)/SE:uac
>>

I don't think it scenario A should be valid. The UA indicates in (1) 
that it wants the AS to choose who is refresher. I don't think it should 
be able to change its mind about that. This is what is causing the problem.

>> These scenarios do not  violate any of the proposed rules and can be encountered with existing 
> SIP implementations. Also, these ambiguity cannot be resolved with 
> refusing UPDATE request with retry after since UA does not know that 200 
> OK and UPDATE are sent close together.
>>
>>  My suggestion is to specify that 200 OK changing S-E status MUST NOT 
> be sent when UPDATE transaction is in progress. UPDATE changing S-E 
> status MUST NOT be sent when 200 OK was sent but ACK was not yet received.

My comment above at least partly fixes this.

This ambiguity would also be fixed if we said that the new timer takes 
effect as soon as the "s-e-answer" is sent/received.

	Thanks,
	Paul

>>  I would be very interested if you can think of other, more robust ways 
> to detect and deal with this situation which require modifications only 
> for one of the SIP UA.
> 
> I am not sure whether your suggestion is any different than mine: UPDATE 
> requests/responses sent within an going INVITE s-e negotiation must not 
> change the roles – they must reflect whatever was sent in the INVITE 
> request and will be sent in the 200 (INVITE) response.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> On Wed, Mar 28, 2018 at 4:51 PM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi,
> 
>     negotiation, the s-t information in the UPDATEs must reflect the
>     ongoing negotiation (similar as sending SDP in an unreliable 18x -
>     it is not really an answer, but it must be a copy of the
>     to-be-sent-answer). So, in my example, the s-t information in the
>     UPDATE request from the AS must reflect what the AS will eventually
>     send in the 200 OK to the INVITE. And, the s-t information in the
>     UPDATE response from the UA must reflect what the UA sent in the INVITE.
> 
>     >> <[email-masked] <mailto:[email-masked]> on behalf of
>     >> [email-masked] <mailto:[email-masked]>>
>     >> wrote:
>     >>
>     >>> Hi Paul,
>     >>>
>     >>> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/sipcore>
>     >>
>     >>
>     >
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/sipcore>
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2018 11:57:33 -0400

> Why would the AS send SE:mac in message 4)?

Scenario A is not entirely legal but Scenario B can look like Scenario A
due to message re-order. Scenario B is legal and can happen when let's say
B2BUA is switching a call to a new destination right after the INVITE
transaction was completed and needs for some reason to change S-E role at
the same time.

> request and will be sent in the 200 (INVITE) response.

I agree with your suggestion except that I think  UPDATE requests/responses
sent within an going INVITE s-e negotiation SHOULD NOT change the roles.
Furthermore there are existing implementations that break this restriction,
so we need to define how compliant implementations should handle such
requests. Refusing UPDATE is not always an option since, for instance in my
Scenario A, UA does not know S-E: header value for 200 OK in advance. I
just think UA should not hang up the call when 200 OK in step 4 with
non-matching S-E is received and deal with this situation gracefully.

Regards,
_______________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2018 12:20:23 -0400

Hi Paul,

On Thu, Mar 29, 2018 at 11:21 AM, Paul Kyzivat <[email-masked]>
wrote:

> take effect? Whenever that is, it overrides an prior s-t (or non-s-t), and
> presumably can no longer be rolled back if a (re)invite fails. This

I think the negotiation takes place when success response is sent or
received. UPDATE within INVITE transaction are two different S-E
negotiations.

For instance, if there is s-t in invite, and response to it in UPDATE, does
> the new timer start then? Or does it only start when the invite transaction
> is complete?
>

There is no response for S-T in INVITE in UPDATE request. These are two
independent negotiations.

What I meant by S-T state is refresher role and expiration duration. Timer
starts when success message is sent or received. New timer starts on each
successful response message even if S-E refresher role or expiration
duration did not change.

> the significance of additional s-t headers in subsequent messages until the
> invite transaction is complete? They could be forbidden, or required to
> match the first "response", or we could allow them to carry out a

As I have said, I think S-E timer should start when success response is
sent or received. For UPDATE within INVITE transaction timer starts first
on UPDATE success response and then restarted on INVITE success response.
UPDATE transactions within INVITE transaction can negotiate S-T.

One valid example is as follows:

1)  UA->AS: INVITE/supported:timer
2)  AS->UA: 183(INVITE)
3)  UA->AS: UPDATE/SE:uac
4)  AS-> UA: 200(UPDATE)/SE:uac
5)  AS-> UA : 200(INVITE) /SE:uac

Initial INVITE indicates support for session timer but no session
expiration. UPDATE initiates initiates the session timer expiration which
is accepted by AS.  TImer starts when message in step 4 is sent/received.
S-T is renegotiated when message in step 5 is sent received and timer is
restarted even though SE header is exactly the same in steps 4 and 5 and
refresher and SE duration did not change.

Because the time value in the s-e is a duration, rather than a data-time,
> there is the question of when the conversion to date-time is done. If it is
> done when the s-e header is sent/received, then sending a exact copy of
> that same header still constitutes a change to the s-e status.
>

As I have mentioned above, what I meant by s-t state is  refresher role and
expiration duration. These SHOULD NOT be changed by UPDATE messages within
the INVITE transaction. TImer is re-started with current expiration
duration whenever any success response is sent or received.

> I don't think it scenario A should be valid. The UA indicates in (1) that
> it wants the AS to choose who is refresher. I don't think it should be able
> to change its mind about that. This is what is causing the problem.

Scenario B can end up looking like scenario A due to message re-order.
Scenario
B is legal and can happen when let's say B2BUA is switching a call to a new
destination right after the INVITE transaction was completed and needs for
some reason to change S-E role at the same time. Furthermore, Scenario A
can happen with legacy SIP implementations and I think we need to provide
guidance how this should be gracefully handled.

Regards,
______________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Mar 2018 12:19:28 +0000

Hi,

>> ISTM an important question is: when does the result of this negotiation take effect? Whenever 
>> that is, it overrides an prior s-t (or non-s-t), and presumably can no longer be rolled back if a (re)invite fails. 
>> This matters, because it establishes when the timer will expire.
>
> I think the negotiation takes place when success response is sent or received. UPDATE within INVITE transaction are two different S-E negotiations. 

I agree. I don't think a s-e negotiation should span multiple SIP transactions. That would complicate things even further, IMO...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Mar 2018 12:34:56 -0400

> I agree. I don't think a s-e negotiation should span multiple SIP transactions. That would complicate things even further, IMO...

I don't understand what you mean here. If you offer s-e in invite, and 
then send an update (which is another transaction) with s-e, then ISTM 
you necessarily have an s-e negotiation spanning multiple sip transactions.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 30 Mar 2018 12:43:03 -0400

On Fri, Mar 30, 2018 at 12:34 PM, Paul Kyzivat <[email-masked]>
wrote:

>> I agree. I don't think a s-e negotiation should span multiple SIP
>> transactions. That would complicate things even further, IMO...
>>
>
> then send an update (which is another transaction) with s-e, then ISTM you
> necessarily have an s-e negotiation spanning multiple sip transactions.
>

I think having multiple transaction going on at the same time means
multiple S-T negotiations. Each negotiation takes effect when final success
response for this transaction is sent.

For instance here:

1)  UA->AS: INVITE/supported:timer
2)  AS->UA: 183(INVITE)
3)  UA->AS: UPDATE/SE:uac
4)  AS-> UA: 200(UPDATE)/SE:uac
5)  UA->AS: UPDATE/SE:uac
6)  AS-> UA: 200(UPDATE)/SE:uac
7)  AS-> UA : 200(INVITE) /SE:uac

There are 3 S-T negotiations: 2 for UPDATE transactions and 1 for INVITE.
Session timer is (re-)started 3 times: in steps 4, 6, and 7.

Also, as things are defined now, each of these transactions (both UPDATES
and the INVITE) can change refresher role and session expires interval.
Each of those changes takes effect when final success response is either
sent or relieved in steps 4, 6, and 7.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 31 Mar 2018 11:32:36 -0400

See below.

On 3/30/18 12:43 PM, Roman Shpount wrote:
> On Fri, Mar 30, 2018 at 12:34 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>             I think the negotiation takes place when success response is
>             sent or received. UPDATE within INVITE transaction are two
>             different S-E negotiations.
> 
> 
>         I agree. I don't think a s-e negotiation should span multiple
>         SIP transactions. That would complicate things even further, IMO...
> 
> 
>     I don't understand what you mean here. If you offer s-e in invite,
>     and then send an update (which is another transaction) with s-e,
>     then ISTM you necessarily have an s-e negotiation spanning multiple
>     sip transactions.
> 
> 
> multiple S-T negotiations. Each negotiation takes effect when final 
> success response for this transaction is sent.
> 
> For instance here:
> 
> There are 3 S-T negotiations: 2 for UPDATE transactions and 1 for 
> INVITE. Session timer is (re-)started 3 times: in steps 4, 6, and 7.
> 
> Also, as things are defined now, each of these transactions (both 
> UPDATES and the INVITE) can change refresher role and session expires 
> interval. Each of those changes takes effect when final success response 
> is either sent or relieved in steps 4, 6, and 7.

I'll grant you that this definition is unambiguous. But it seems 
nonsensical in practice. It means that the s-t negotiated by an UPDATE 
within an INVITE will never extend beyond the end of the invite 
transaction. This is true even if the INVITE did not include s-e, 
because in that case the end of the invite transaction will turn off the 
s-t.

A problem here is that 4028 provided no way to do an invite or update 
that leaves the s-t state untouched. If we had that then it would make 
all of this simpler.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sat, 31 Mar 2018 15:04:29 -0400

On Sat, Mar 31, 2018 at 11:32 AM, Paul Kyzivat <[email-masked]>
wrote:

> transaction. This is true even if the INVITE did not include s-e, because
> in that case the end of the invite transaction will turn off the s-t.
>

I think there is a slight point of confusion here. Normally initial INVITE
sent by UA does not include S-E. This INVITE includes Supported: timer and
potentially Min-SE. S-E header is added by either proxy or answering UA. It
is the INVITE success response which results in S-T negotiation. The only
way for an offering agent to turn off S-T is to sent an INVITE or UPDATE
without S-E and Supported: timer.

The situation I am describing here is a bit extreme but not nonsensical.
There are existing UA that can send the initial INVITE and then send an
UPDATE during this transaction to negotiate S-T. The purpose of the UPDATE
transactions is to negotiate S-T (refresher and expires) early, before
INVITE transaction was completed, similar to early media. Well behaving UA
should simply send the current S-T state (refresher and expires), in
subsequent transactions embedded in the INVITE transaction or in INVITE
transaction final success response. This will initiate a timer re-start
but, I would say, this is within the spirit of session timer, since UA and
proxies got a recent message indicating that dialog is still active and
timer can continue.

> A problem here is that 4028 provided no way to do an invite or update that
> leaves the s-t state untouched. If we had that then it would make all of
> this simpler.
>

I fully agree here. Unfortunately, since there is no way to send invite or
updates without changing s-t state untouched, the next best thing is to
recommend that in case s-t state should not be changed, INVITE or UPDATE
requests and success responses SHOULD include currently negotiated
refresher and expires.

Regards.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 31 Mar 2018 18:02:52 -0400

On 3/31/18 3:04 PM, Roman Shpount wrote:
> On Sat, Mar 31, 2018 at 11:32 AM, Paul Kyzivat <[email-masked] 
>     nonsensical in practice. It means that the s-t negotiated by an
>     UPDATE within an INVITE will never extend beyond the end of the
>     invite transaction. This is true even if the INVITE did not include
>     s-e, because in that case the end of the invite transaction will
>     turn off the s-t.
> 
> 
> I think there is a slight point of confusion here. Normally initial 
> INVITE sent by UA does not include S-E. This INVITE includes Supported: 
> timer and potentially Min-SE. S-E header is added by either proxy or 
> answering UA. It is the INVITE success response which results in S-T 
> negotiation. The only way for an offering agent to turn off S-T is to 
> sent an INVITE or UPDATE without S-E and Supported: timer.

OK, sorry, I agree. The sender of an INVITE can't both indicate support 
for timer and force it not to be used.

> UPDATE during this transaction to negotiate S-T. The purpose of the 
> UPDATE transactions is to negotiate S-T (refresher and expires) early, 
> before INVITE transaction was completed, similar to early media. Well 
> behaving UA should simply send the current S-T state (refresher and 
> expires), in subsequent transactions embedded in the INVITE transaction 
> or in INVITE transaction final success response. This will initiate a 
> timer re-start but, I would say, this is within the spirit of session 
> timer, since UA and proxies got a recent message indicating that dialog 
> is still active and timer can continue.

Then IIUC you are saying that if a s-t has been negotiated by a UPDATE 
within an INVITE then the UAS for the INVITE SHOULD send the same values 
in the 200 INVITE as were in the last 200 UPDATE.

(If there had been no Supported:timer in the INVITE then I guess we 
presume that there is to be no s-t negotiation in UPDATEs either.)

I suspect there are cases possible here, where a s-e expiration value 
that is compatible with the INVITE is incompatible with the UPDATE. 
These would be pathological, but ought to be investigated before we are 
done.

While writing this response I realized another flaw in 4028. The rules 
for generating subsequent refreshes seem to assume that once it has been 
determined that both ends support s-t that this will continue to be 
true. For instance this must be so when the refresh request says 
refresher=uas. But in the presence of a B2BUA that passes s-t through 
rather than managing each side separately, after a 3pcc transfer this 
may not be true.

	Thanks,
	Paul

>     A problem here is that 4028 provided no way to do an invite or
>     update that leaves the s-t state untouched. If we had that then it
>     would make all of this simpler.
> 
> 
> I fully agree here. Unfortunately, since there is no way to send invite 
> or updates without changing s-t state untouched, the next best thing is 
> to recommend that in case s-t state should not be changed, INVITE or 
> UPDATE requests and success responses SHOULD include currently 
> negotiated refresher and expires.
> 
> Regards.
> _____________
> Roman Shpount
>