Re: [sipcore] 4028bis: memory refresh

Hi,

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

Section 8 of RFC 4028 says:

   “Proxies that ask for session timers SHOULD record-route, as they
   won't receive refreshes if they don't.”

In my opinion it should be possible to mandate that a proxy that asks for session timers, or modifies a session timer value (S-E or Min-SE), also record-route.

Regards,

Christer

On Mon, May 11, 2020 at 11:52 AM Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> 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:

-          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 <sipcore-bounces@ietf..org<mailto:sipcore-bounces@ietf.org>> on behalf of Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>>
Date: Monday, 11 May 2020 at 14.36
To: "sipcore@ietf.org<mailto:sipcore@ietf.org>" <sipcore@ietf.org<mailto:sipcore@ietf.org>>
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
sipcore@ietf.org<mailto:sipcore@ietf.org>
https://www.ietf.org/mailman/listinfo/sipcore

Re: [sipcore] 4028bis: memory refresh - proxy assumptions