Subject: Re: [sipcore] session-timer fix - a new hope

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 13:12:50 +0000

Hi,

Trying to move this issue forward (it is creating problems), the last suggestion I had (and which I *think* is aligned with what Roman said) is:

“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

From: sipcore <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Thursday 29 March 2018 at 14:08
To: Roman Shpount <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] session-timer fix

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

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,

>>>> 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).
>>>
>>> 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?
>>
>> 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?
>>> Or can they do the negotiation over?
>>
>> 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.
>
> 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?)
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

> Regards,
>
> Christer
>
>
>
>> On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg"
>> <[email-masked]<mailto:[email-masked]> on behalf of
>> [email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>> 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.)
>>>>
>>>>    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.
>>>
>>> Correct. This is a case where UPDATE is received while the S-T
>>> negotiation is still ongoing.
>>>
>>>> - 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.
>>>
>>> Shouldn't the proxy know that the UA supports S-T, due to (1)?
>>>
>>>> - 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).
>>>
>>> Let's assume it is like that.
>>>
>>>> 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.
>>>
>>> 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
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Sep 2018 10:34:23 -0400

On 9/20/18 9:12 AM, Christer Holmberg wrote:
> Hi,
> 
> Trying to move this issue forward (it is creating problems), the last 
> suggestion I had (and which I **think** is aligned with what Roman said) is:
> 
> “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.”

This seems ok to me. But one point may still not be entirely clear:

If an INVITE contains a S-E, is it required that an UPDATE within that 
INVITE transaction also contain an S-E?

IMO the answer is YES, because not doing so implies a desire for no 
session timer. Conversely, if an INVITE contains no S-E, then an UPDATE 
within that transaction must also contain no S-E.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> *From: *sipcore <[email-masked]> on behalf of Christer 
> Holmberg <[email-masked]>
> *Date: *Thursday 29 March 2018 at 14:08
> *To: *Roman Shpount <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [sipcore] session-timer fix
> 
> 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
> 
>  > 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
> 
>>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
>> 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.
> 
>>
> 
> 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,
> 
>      >>> 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
>      >>> Then do subsequent messages within the invite transaction and
>     embedded UPDATES repeat the agreed upon result?
>      >> In general, unless such text already exist, I think we should
>     recommend against re-negotiating , unless there is a good reason for it.
>      >
>      > 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.
>      > 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
>      >> <[email-masked] <mailto:[email-masked]> on
>     behalf of
>      >>> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 16:54:16 +0000

Hi,

> If an INVITE contains a S-E, is it required that an UPDATE within that INVITE transaction also contain an S-E?
>
> IMO the answer is YES, because not doing so implies a desire for no session timer.

I'd have to refresh my memory, but that sounds correct.

> Conversely, if an INVITE contains no S-E, then an UPDATE within that transaction must also contain no S-E.

Again, I'd have to refresh my memory, but I think there were some discussions about a case where the INVITE would not contain S-E, but it would be negotiated in an UPDATE while the INVITE transaction is still ongoing. But, if that doesn't work, we may have to forbid it. I think we should try to keep things simple.

Regards,

Christer

> case of your example, S-E state in step 9 should be based on results 
> of the UPDATE
> 
>  > 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.
> 
>>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
>> These scenarios do not violate any of the proposed rules and can be 
>> encountered with existing SIP implementations. Also, these ambiguity
> I am not sure whether your suggestion is any different than mine: 
> UPDATE requests/responses sent within an going INVITE s-e negotiation 
> INVITE request and will be sent in the 200 (INVITE) response.
> 
> Regards,
> 
> Christer
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Sep 2018 13:44:44 -0400

Hi Christer,

I would really need to refresh my memory on this.

> INVITE request and will be sent in the 200 (INVITE) response.”
There are several issues we need to have addressed that go beyond this
statement:

1. UPDATE can be used by either party to negotiate session timer when
session timer was not present in the initial INVITE.
2. There are existing implementations that violate your proposal. What
should UA do when they receive an UPDATE that changes S-E status during the
INVITE transaction?

I was trying to come up with rules that deal with all of those cases.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 19:24:49 +0000

Hi,

Do you really think we will find a solution that nobody violates?

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 20 September 2018 20:45
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] session-timer fix - a new hope

Hi Christer,

On Thu, Sep 20, 2018 at 9:12 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Trying to move this issue forward (it is creating problems), the last suggestion I had (and which I *think* is aligned with what Roman said) is:

There are several issues we need to have addressed that go beyond this statement:

1. UPDATE can be used by either party to negotiate session timer when session timer was not present in the initial INVITE.
2. There are existing implementations that violate your proposal. What should UA do when they receive an UPDATE that changes S-E status during the INVITE transaction?

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Sep 2018 16:00:54 -0400

> Do you really think we will find a solution that nobody violates?
No, but what we can find is the proposal on how to deal with these
violations gracefully, so that if one of the UA implements the new
specification, there is a predictable behavior.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 20:02:29 +0000

So, are you aware of implementations that would send UPDATE in the backwards direction (towards the sender of the INVITE), while the INVITE is still ongoing, in order to negotiate session timer?

Regards,

Christer

Sent: 20 September 2018 23:01

On Thu, Sep 20, 2018 at 3:24 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Do you really think we will find a solution that nobody violates?

No, but what we can find is the proposal on how to deal with these violations gracefully, so that if one of the UA implements the new specification, there is a predictable behavior.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Sep 2018 16:09:09 -0400

On Thu, Sep 20, 2018 at 4:02 PM, Christer Holmberg <
[email-masked]> wrote:

> So, are you aware of implementations that would send UPDATE in the
> backwards direction (towards the sender of the INVITE), while the INVITE is
> still ongoing, in order to negotiate session timer?
>
>
>

I am aware of implementations that use UPDATE during the initial INVITE
transaction and include session timer headers in this UPDATE, specifically
OpenSIPS based scripts that put or update Session-Expires header on all
UPDATE or INVITE requests which pass through them.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 20:48:18 +0000

>> So, are you aware of implementations that would send UPDATE in the backwards direction 
>> (towards the sender of the INVITE), while the INVITE is still ongoing, in order to negotiate session timer?
>
> I am aware of implementations that use UPDATE during the initial INVITE transaction and include session timer 
> headers in this UPDATE, specifically OpenSIPS based scripts that put or update Session-Expires header on all 

Both endpoints send these UPDATEs?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Sep 2018 16:53:25 -0400

On Thu, Sep 20, 2018 at 4:48 PM, Christer Holmberg <
[email-masked]> wrote:

> backwards direction
> transaction and include session timer

There scenarios when either UA originating or accepting the call is sending
UPDATE messages. Neither initial INVITE no UPDATE message actually have the
S-E header, but it gets added to all INVITE or UPDATE requests by the proxy
which is located on the call path.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2018 06:30:02 +0000

Hi,

So, perhaps we could say:

If there is an ongoing s-e negotiation, any target refresh request sent when that negotiation is ongoing must reflect the s-e roles.

That would allow to negotiate s-e with UPDATE even if the INVITE did not include s-e.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Thursday 20 September 2018 at 23:53
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] session-timer fix - a new hope

There scenarios when either UA originating or accepting the call is sending UPDATE messages. Neither initial INVITE no UPDATE message actually have the S-E header, but it gets added to all INVITE or UPDATE requests by the proxy which is located on the call path.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Sep 2018 11:15:25 -0400

On 9/21/18 2:30 AM, Christer Holmberg wrote:
> If there is an ongoing s-e negotiation, any target refresh request sent 
> when that negotiation is ongoing must reflect the s-e roles.
> 

Then what happens in this case:

1) invite with no S-E
2) update with S-E
3) 200 update with S-E
4) 200 invite - what goes here?
5) afterwards, is timer active?

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> *From: *Roman Shpount <[email-masked]>
> *Date: *Thursday 20 September 2018 at 23:53
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [sipcore] session-timer fix - a new hope
> 
> On Thu, Sep 20, 2018 at 4:48 PM, Christer Holmberg 
>      >> (towards the sender of the INVITE), while the INVITE is still
>     ongoing, in order to negotiate session timer?
>      >
>      > I am aware of implementations that use UPDATE during the initial
>     INVITE transaction and include session timer
>      > headers in this UPDATE, specifically OpenSIPS based scripts that
>     put or update Session-Expires header on all
> There scenarios when either UA originating or accepting the call is 
> sending UPDATE messages. Neither initial INVITE no UPDATE message 
> actually have the S-E header, but it gets added to all INVITE or UPDATE 
> requests by the proxy which is located on the call path.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2018 15:48:34 +0000

Hi Paul,

Without having the RFC in front of me my initial reaction regarding 4) would be that whatever is in the 200 INVITE is irrelevant and can be discarded.

Regards,

Christer 

Sent from my iPhone

> On 21 Sep 2018, at 18.29, Paul Kyzivat <[email-masked]> wrote:
> 
>> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> On Thu, Sep 20, 2018 at 4:48 PM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:

---

From: OKUMURA Shinji <[email-masked]>
Date: Sun, 23 Sep 2018 14:20:42 +0900

Hi,

This is generally a matter of a negotiation, therefor it is desirable 
not to deviate from rules about an offer-answer and a target-refresh.
So, I think that it is better to return 200 response without SE to 
UPDATE received by caller.

Regards,
Shinji

On 2018/09/22 0:48, Christer Holmberg wrote:
> [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Sun, 23 Sep 2018 01:37:43 -0400

On Sun, Sep 23, 2018 at 1:20 AM, OKUMURA Shinji <[email-masked]>
wrote:

> This is generally a matter of a negotiation, therefor it is desirable not
> to deviate from rules about an offer-answer and a target-refresh.
> So, I think that it is better to return 200 response without SE to UPDATE
> received by caller.
>

This is not always possible. S-E is added by proxy which has no way of
knowing if UDPATE is sent during or outside of the INIVITE transaction.
Since UPDATE can turn session timer on or off, S-E is added to UPDATE
request by the proxy.

Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Sun, 23 Sep 2018 15:45:43 +0900

Hi Roman,

Does it mean that there is no way to stop the timer reliably?

Regards,
Shinji

On 2018/09/23 14:37, Roman Shpount wrote:
> On Sun, Sep 23, 2018 at 1:20 AM, OKUMURA Shinji <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     This is generally a matter of a negotiation, therefor it is
>     desirable not to deviate from rules about an offer-answer and a
>     target-refresh.
> knowing if UDPATE is sent during or outside of the INIVITE 
> transaction. Since UPDATE can turn session timer on or off, S-E is 
> added to UPDATE request by the proxy.
>
> Regards,
> _____________
> Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 23 Sep 2018 14:52:50 +0000

Hi,

The proxy knows if the INVITE request contained S-E, doesn’t it?

If so, it would know that it is not relevant what is in the 200 OK.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 23 September 2018 08:38
To: OKUMURA Shinji <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] session-timer fix - a new hope

On Sun, Sep 23, 2018 at 1:20 AM, OKUMURA Shinji <[email-masked]<mailto:[email-masked]>> wrote:
This is generally a matter of a negotiation, therefor it is desirable not to deviate from rules about an offer-answer and a target-refresh.
So, I think that it is better to return 200 response without SE to UPDATE received by caller.

This is not always possible. S-E is added by proxy which has no way of knowing if UDPATE is sent during or outside of the INIVITE transaction. Since UPDATE can turn session timer on or off, S-E is added to UPDATE request by the proxy.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 23 Sep 2018 18:44:28 -0400

> If so, it would know that it is not relevant what is in the 200 OK.

Proxy knows that it added S-E in the INVITE request but it does not
necessarily knows that UPDATE transaction was processed.

In Paul's example 200 OK response to INVITE should negotiate the same thing
that 200 OK to UPDATE. It is the S-E header in 200 OK which will control
the session timer state at the end, so it it changes the refresher or stops
the session timer, it will modify the session timer for the entire dialog.

This is no different then target refresh. UPDATE request or success
response update target. INVITE request or success response update target.
The last one of those that UA got contains the Contact header which dialog
should use. I believe the same logic should apply to session timer.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Sep 2018 06:16:45 +0000

Hi,

Why is there such a need to re-negotiate/remove the session timer while the initial INVITE transaction is still ongoing???

Anyway, I have no problem including the value in the INVITE 200 OK, if that works better.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Monday 24 September 2018 at 01:44
To: Christer Holmberg <[email-masked]>
Cc: OKUMURA Shinji <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] session-timer fix - a new hope

On Sun, Sep 23, 2018 at 10:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
The proxy knows if the INVITE request contained S-E, doesn’t it?

Proxy knows that it added S-E in the INVITE request but it does not necessarily knows that UPDATE transaction was processed.

In Paul's example 200 OK response to INVITE should negotiate the same thing that 200 OK to UPDATE. It is the S-E header in 200 OK which will control the session timer state at the end, so it it changes the refresher or stops the session timer, it will modify the session timer for the entire dialog.

This is no different then target refresh. UPDATE request or success response update target. INVITE request or success response update target. The last one of those that UA got contains the Contact header which dialog should use. I believe the same logic should apply to session timer.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 24 Sep 2018 11:24:00 -0400

On Mon, Sep 24, 2018 at 2:16 AM, Christer Holmberg <
[email-masked]> wrote:

> Why is there such a need to re-negotiate/remove the session timer while
> the initial INVITE transaction is still ongoing???
>

There is no need to re-negotiate the session timer while initial INVITE
transaction is still ongoing. Typically there is a need to keep session
timer running and it is hard for the proxy to know that initial transaction
is still ongoing.

Anyway, I have no problem including the value in the INVITE 200 OK, if that
> works better.

I think the best approach here is to require consistency. Success responses
to INVITE or UPDATE should all include the currently negotiated session
timer status, even if they are repeated. UPDATE requests during INVITE
transaction should include S-E and Min-SE headers from initiate INVITE
request if sent by UAC in INVITE transaction or  include S-E and Min-SE
headers which would be in 2XX response to initial INVITE if sent by UAS in
INVITE transaction.

The second big question is to define what happens when UA gets inconsistent
session timer results, like refresher change between 200 OK responses to
INVITE and UPDATE which happened during INVITE transaction. For all I care,
UA can declare this an error hang up the call or initiate a new UPDATE that
re-negotiates session timer to something consistent.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Sep 2018 18:31:07 +0000

Hi,

One of the clarification in the current version of the draft says that a 2xx response without S-E terminates the session timer only if the associated request contained S-E.

That means that it would be ok to send UPDATEs without S-E, both inside and outside of an ongoing INVITE transaction.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 24 September 2018 18:24
To: Christer Holmberg <[email-masked]>
Cc: OKUMURA Shinji <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] session-timer fix - a new hope

On Mon, Sep 24, 2018 at 2:16 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Why is there such a need to re-negotiate/remove the session timer while the initial INVITE transaction is still ongoing???

There is no need to re-negotiate the session timer while initial INVITE transaction is still ongoing. Typically there is a need to keep session timer running and it is hard for the proxy to know that initial transaction is still ongoing.

I think the best approach here is to require consistency. Success responses to INVITE or UPDATE should all include the currently negotiated session timer status, even if they are repeated. UPDATE requests during INVITE transaction should include S-E and Min-SE headers from initiate INVITE request if sent by UAC in INVITE transaction or  include S-E and Min-SE headers which would be in 2XX response to initial INVITE if sent by UAS in INVITE transaction.

The second big question is to define what happens when UA gets inconsistent session timer results, like refresher change between 200 OK responses to INVITE and UPDATE which happened during INVITE transaction. For all I care, UA can declare this an error hang up the call or initiate a new UPDATE that re-negotiates session timer to something consistent.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 24 Sep 2018 14:35:29 -0400

On Mon, Sep 24, 2018 at 2:31 PM, Christer Holmberg <
[email-masked]> wrote:

> One of the clarification in the current version of the draft says that a
> 2xx response without S-E terminates the session timer only if the
> associated request contained S-E.
>
>
>
> That means that it would be ok to send UPDATEs without S-E, both inside
> and outside of an ongoing INVITE transaction.
>
>
>
I do not think this is a good idea, primarily since INVITE request may
contain or not contain S-E header at different points when it is
transferring multiple proxies. As a result, session timer might be
considered terminated or not terminated at the same time.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2018 08:20:19 +0000

Hi,

> I do not think this is a good idea, primarily since INVITE request may contain or not contain S-E header at different points when it is 
> transferring multiple proxies. As a result, session timer might be considered terminated or not terminated at the same time.

I think we had already agreed on this already, and I think it is strange to mandate S-E in the response if it is not in the request. Do you have a case where it doesn't work?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Sep 2018 11:41:55 -0400

> and outside of an ongoing INVITE transaction.

That can't be right. It would mean that there is no way to for a UAC to 
cause the termination of a currently established session timer.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> *From:*Roman Shpount [mailto:[email-masked]]
> *Sent:* 24 September 2018 18:24
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* OKUMURA Shinji <[email-masked]>; SIPCORE <[email-masked]>
> *Subject:* Re: [sipcore] session-timer fix - a new hope
> 
> On Mon, Sep 24, 2018 at 2:16 AM, Christer Holmberg 
>     Why is there such a need to re-negotiate/remove the session timer
>     while the initial INVITE transaction is still ongoing???
> 
> timer running and it is hard for the proxy to know that initial 
> transaction is still ongoing.
> 
> I think the best approach here is to require consistency. Success 
> responses to INVITE or UPDATE should all include the currently 
> negotiated session timer status, even if they are repeated. UPDATE 
> requests during INVITE transaction should include S-E and Min-SE headers 
> from initiate INVITE request if sent by UAC in INVITE transaction or 
>   include S-E and Min-SE headers which would be in 2XX response to 
> initial INVITE if sent by UAS in INVITE transaction.
> 
> The second big question is to define what happens when UA gets 
> inconsistent session timer results, like refresher change between 200 OK 
> responses to INVITE and UPDATE which happened during INVITE transaction. 
> For all I care, UA can declare this an error hang up the call or 
> initiate a new UPDATE that re-negotiates session timer to something 
> consistent.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> 
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 25 Sep 2018 11:52:13 -0400

On Tue, Sep 25, 2018 at 4:20 AM, Christer Holmberg <
[email-masked]> wrote:

> >> One of the clarification in the current version of the draft says that
> a 2xx response without S-E terminates the session timer only if the
> I think we had already agreed on this already, and I think it is strange
> to mandate S-E in the response if it is not in the request. Do you have a
> case where it doesn't work?
>

I do not think we agreed about this. This is a breaking change and it is
not how session-timer currently works. Session timer serves almost no
purpose for UA. It is needed for proxies to maintain state. Because of
this, UA almost always sends initial INVITE without S-E. S-E header is
added by proxies to requests, and negotiation is done based on presence of
S-E in the success response regardless of presence of S-E in the request.

Because of this:
1. S-E should cause session timer renegotiation based on its presence (or
absence) in any success response to INVITE of UPDATE
2. If session timer is negotiated, S-E should be present in any INVITE or
UPDATE request with the current refresher role

The only things which are in play are:
1. Should S-E be present in the UPDATE request or success response which is
sent while INVITE transaction (re-)negotiating session timer is still in
progress?
2. What should UA do when it gets ambiguous S-E header values in
intersecting INVITE and UPDATE transactions?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2018 16:22:44 +0000

Hi,

>> That means that it would be ok to send UPDATEs without S-E, both 
>> inside and outside of an ongoing INVITE transaction.
>
> That can't be right. It would mean that there is no way to for a UAC to cause the termination of a currently established session timer.

How does the UAC currently terminate the timer? Not including S-E in a request does not terminate the timer, AFAIK.

Regards,

Christer

> There is no need to re-negotiate the session timer while initial 
> INVITE transaction is still ongoing. Typically there is a need to keep 
> session timer running and it is hard for the proxy to know that 
> initial transaction is still ongoing.
> 
> requests during INVITE transaction should include S-E and Min-SE 
> headers from initiate INVITE request if sent by UAC in INVITE 
> transaction or
> inconsistent session timer results, like refresher change between 200 
> OK responses to INVITE and UPDATE which happened during INVITE transaction.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Sep 2018 13:00:22 -0400

> How does the UAC currently terminate the timer? Not including S-E in a request does not terminate the timer, AFAIK.

The only way the UAC can *force* the termination of the timer is to 
cease declaring support for it.

But if it doesn't want it, it can *try* by sending a new INVITE/UPDATE 
without S-E. If none of the proxies on the path now request one then it 
can go away. I would expect that a UA that prefers not to have a timer 
will do this at every opportunity - every time it sends an 
INVITE/UPDATE. But this is a place where we have the opportunity to say 
what it should do when sending an UPDATE within an INVITE.

As Roman has noted, the UAC can't know if S-E was added to the original 
request by a proxy, and so it can't use the presence of S-E in the 
request it sent to determine whether the absence of S-E in a response 
should cancel the timer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2018 12:03:50 +0000

Hi,

> cease declaring support for it.

I don't think that is explicitly described in the RFC - may it is something we need to clarify.

>    request it sent to determine whether the absence of S-E in a response 
  
Fair enough.

Regards,

Christer