Subject: Re: [sipcore] 4028bis: memory refresh

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 May 2020 15:51:54 +0000

Hi,

And, if you for whatever reason rather watch Tiger King than the IETF 102 SIPCORE session, below is basically what was suggested in order to solve the session-timer glare situation:

UAC:

-          If a UA inserts S-E in an INVITE request the UA MUST insert the same S-E in any UPDATE request it sends while the INVITE transaction is ongoing

-          If a UA has conflicting S-E information once the INVITE and UPDATE transaction have completed, it MUST send a new UPDATE with S-E, in order to “sync” the S-E state among all entities

PROXY:

Request handling:

-          MUST reject the request if the S-E value is too small

o   No matter if the request contains Supported:timer or not

-          If the proxy inserts/forwards/modifies the S-E in an INVITE request the proxy MUST identically insert/forward/modify the same S-E in any UPDATE request

o   The proxy MAY insert/modify the S-E if it knows that there is no active INVITE transaction

Response handling:

-          If response contains S-E, the proxy MUST NOT modify it

-          If response does not contain S-E, the proxy MAY insert S-E if it remembers that the associated request contained Supported:timer

UAS:

-          If request contains S-E:

o   The UAS copies the S-E value of the request into the response

o   The UAS MUST NOT reduce the S-E value in the response

§  If the UAS wants to change the S-E value, it later sends a request by its own

-          If the request does not contain S-E:

o   If the request contains Supported:timer, the UAS MAY include S-E in the response

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
Date: Monday, 11 May 2020 at 14.36
To: "[email-masked]" <[email-masked]>
Subject: [sipcore] 4028bis: memory refresh

Hi,

Now, when the sip-oauth draft is more or less done (in the RFC editor’s queue), I intend to take up the work on 4028bis (session-timer) again.

We previously had e-mail discussions and phone calls, there is an issue tracker on GitHub, and we discussed the suggested solutions at IETF#103. To refresh your memory, please take a look at the video: https://www.youtube.com/watch?v=C2yeckBmgPg (the session-timer presentation begins at around 7:30 minutes).

The decision to make a bis (instead of an update draft) has already been made, but please take a look at the technical suggestions for fixing the glare situation.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 11 May 2020 17:18:09 -0400

Hi Christer,

I have two issues with this proposal:

1. Defining proxy behavior based on having a transaction in progress: This
is hard to implement in practice since initial INVITE and UPDATE might not
even go over the same path and the same proxies.

2. Not allowing UAS to reduce the S-E: UAS can be just a half of the B2BUA
and might not have a choice in this matter.

I do not think these requirements are necessary. All we need to require is
consistent behavior for both proxies and UAS, i.e. that they always should
insert or reduce S-E to the same value.

Also, even with these requirements we need provisions for both UAC and UAS
to deal with race conditions when S-E value is ambiguous. When dealing with
legacy implementations which do not follow this newly propose
specifications both races are possible.
_____________
Roman Shpount

On Mon, May 11, 2020 at 11:52 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> Hi,
>
>
>
> And, if you for whatever reason rather watch Tiger King than the IETF 102
> SIPCORE session, below is basically what was suggested in order to solve
> the session-timer glare situation:
>
>
>
>
>
> UAC:
>
>
>
> -          If a UA inserts S-E in an INVITE request the UA MUST insert
> the same S-E in any UPDATE request it sends while the INVITE transaction is
> ongoing
>
> -          If a UA has conflicting S-E information once the INVITE and
> UPDATE transaction have completed, it MUST send a new UPDATE with S-E, in
> order to “sync” the S-E state among all entities
>
>
>
>
>
> PROXY:
>
>
>
> Request handling:
>
> -          If the proxy inserts/forwards/modifies the S-E in an INVITE
> request the proxy MUST identically insert/forward/modify the same S-E in
> any UPDATE request
>
> -          If response does not contain S-E, the proxy MAY insert S-E if
> it remembers that the associated request contained Supported:timer
>
>
>
> UAS:
>
>
>
> *From: *sipcore <[email-masked]> on behalf of Christer Holmberg
> <christer.holmberg=[email-masked]>
> *Date: *Monday, 11 May 2020 at 14.36
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[sipcore] 4028bis: memory refresh
>
>
>
> Hi,
>
>
>
> Now, when the sip-oauth draft is more or less done (in the RFC editor’s
> queue), I intend to take up the work on 4028bis (session-timer) again.
>
>
>
> We previously had e-mail discussions and phone calls, there is an issue
> tracker on GitHub, and we discussed the suggested solutions at IETF#103. To
> refresh your memory, please take a look at the video:
> https://www.youtube.com/watch?v=C2yeckBmgPg (the session-timer
> presentation begins at around 7:30 minutes).
>
>
>
> The decision to make a bis (instead of an update draft) has already been
> made, but please take a look at the technical suggestions for fixing the
> glare situation.
>
>
>
> Regards,
>
>
>
> Christer
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 May 2020 07:18:24 +0000

Hi Roman,

>1. Defining proxy behavior based on having a transaction in progress: This is hard to implement in practice since initial INVITE and UPDATE might >not even go over the same path and the same proxies.
>
>2. Not allowing UAS to reduce the S-E: UAS can be just a half of the B2BUA and might not have a choice in this matter.
>
>I do not think these requirements are necessary. All we need to require is consistent behavior for both proxies and UAS, i.e. that they always >should insert or reduce S-E to the same value.
>
>Also, even with these requirements we need provisions for both UAC and UAS to deal with race conditions when S-E value is ambiguous. When >dealing with legacy implementations which do not follow this newly propose specifications both races are possible.
The text says that, if the value is ambiguous, the UAC will send a new S-E once the INVITE transaction has completed. I guess we could say the same thing for the UAS.

Regards,

Christer

On Mon, May 11, 2020 at 11:52 AM Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

UAC:

PROXY:

Request handling:

Response handling:

UAS:

•  If the UAS wants to change the S-E value, it later sends a request by its own

Regards,

Christer

From: sipcore <sipcore-bounces@ietf..org<mailto:[email-masked]>> on behalf of Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>>
Date: Monday, 11 May 2020 at 14.36
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sipcore] 4028bis: memory refresh

Hi,

Regards,

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

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 20 May 2020 17:24:11 +0900

Hi,

> PROXY:
>
> Request handling:
>
> -MUST reject the request if the S-E value is too small
>
> oNo matter if the request contains Supported:timer or not
>
If the request does not contain Supported:timer, the S-E was inserted by 
one of the proxies in the path.
In this case, RFC4028 says
"the proxy cannot usefully reject the request,"
In my interpretation, this "usefully" means that the rejection(422) is 
unreasonable for the UAC.
Because it is the proxy that created the cause of the rejection, and UAC 
can not recognize the cause for the rejection.

I have two solutions.

1. If the request does not contain Supported:timer, a proxy MAY insert 
Min-SE header, SHOULD NOT insert S-E header and SHOULD NOT reject by 422.

2. A proxy MAY reject this request by 422, and the proxy that inserted 
the S-E header MUST send new INVITE that has a bigger S-E value.

Regards,
Shinji

On 2020/05/12 0:51, Christer Holmberg wrote:
>
> Hi,
>
> And, if you for whatever reason rather watch Tiger King than the IETF 
> 102 SIPCORE session, below is basically what was suggested in order to 
> solve the session-timer glare situation:
>
> UAC:
>
> -If a UA inserts S-E in an INVITE request the UA MUST insert the same 
> S-E in any UPDATE request it sends while the INVITE transaction is ongoing
>
> -If a UA has conflicting S-E information once the INVITE and UPDATE 
> transaction have completed, it MUST send a new UPDATE with S-E, in 
> -MUST reject the request if the S-E value is too small
>
> oNo matter if the request contains Supported:timer or not
>
> -If the proxy inserts/forwards/modifies the S-E in an INVITE request 
> the proxy MUST identically insert/forward/modify the same S-E in any 
> UPDATE request
>
> oThe proxy MAY insert/modify the S-E if it knows that there is no 
> active INVITE transaction
>
> Response handling:
>
> -If response contains S-E, the proxy MUST NOT modify it
>
> -If response does not contain S-E, the proxy MAY insert S-E if it 
> remembers that the associated request contained Supported:timer
>
> UAS:
>
> -If request contains S-E:
>
> oThe UAS copies the S-E value of the request into the response
>
> oThe UAS MUST NOT reduce the S-E value in the response
>
> §If the UAS wants to change the S-E value, it later sends a request by 
> its own
>
> -If the request does not contain S-E:
>
> oIf the request contains Supported:timer, the UAS MAY include S-E in 
> the response
>
> Regards,
>
> Christer
>
> *From: *sipcore <[email-masked]> on behalf of Christer 
> Holmberg <christer.holmberg=[email-masked]>
> Now, when the sip-oauth draft is more or less done (in the RFC 
> editor’s queue), I intend to take up the work on 4028bis 
> (session-timer) again.
>
> We previously had e-mail discussions and phone calls, there is an 
> issue tracker on GitHub, and we discussed the suggested solutions at 
> IETF#103. To refresh your memory, please take a look at the video: 
> The decision to make a bis (instead of an update draft) has already 
> been made, but please take a look at the technical suggestions for 
> fixing the glare situation.
>
> Regards,
>
> Christer
>
>