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

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 May 2020 14:08:22 +0000

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=[email-masked]<mailto:[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:

-          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:[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,

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Roman Shpount <[email-masked]>
Date: Fri, 15 May 2020 02:50:04 -0400

On Thu, May 14, 2020 at 10:08 AM Christer Holmberg <
[email-masked]> wrote:

> >1. Defining proxy behavior based on having a transaction in progress:
> This is hard to implement in practice since initial INVITE and UPDATE
>
> 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.
>
>
>
I have mentioned before that even requiring record-route would be
insufficient. First of all, having a transaction in progress for a proxy is
something that can be ambiguous due to network delays or message
re-ordering even if it is always on the dialog path. Second, the amount of
state maintained by proxy, if it needs to track transactions vs dialogs
increases significantly. Third, even if the proxy can be the same "logical
proxy", it can actually be multiple physical servers sharing an address
behind a load balancer, so UPDATE and INVITE transactions can end up on the
different servers.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 May 2020 06:58:32 +0000

Hi,

> I have mentioned before that even requiring record-route would be insufficient. First of all, having a transaction in progress for a proxy is something
> that can be ambiguous due to network delays or message re-ordering even if it is always on the dialog path. Second, the amount of state maintained
> by proxy, if it needs to track transactions vs dialogs increases significantly. Third, even if the proxy can be the same "logical proxy", it can actually be
> multiple physical servers sharing an address behind a load balancer, so UPDATE and INVITE transactions can end up on the different servers.

You could still configure those proxies to behave in the same way (insert/modify the S-E and Min-SE header field values in the same way) when it comes to the session-timer. 

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 15 May 2020 03:21:04 -0400

On Fri, May 15, 2020 at 2:58 AM Christer Holmberg <
[email-masked]> wrote:

> >> 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.
> >>
> something
> > that can be ambiguous due to network delays or message re-ordering even
> if it is always on the dialog path. Second, the amount of state maintained
> > by proxy, if it needs to track transactions vs dialogs increases
> significantly. Third, even if the proxy can be the same "logical proxy", it
> can actually be
> > multiple physical servers sharing an address behind a load balancer, so
> UPDATE and INVITE transactions can end up on the different servers.
>
> You could still configure those proxies to behave in the same way
> (insert/modify the S-E and Min-SE header field values in the same way) when
> it comes to the session-timer.
>
>
Absolutely correct. Having proxies use the same consistent rules should be
sufficient.

My point is that we cannot define proxy behavior based on having a
transaction in progress. This is only non-ambiguous and implementable for a
UA.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 May 2020 07:30:22 +0000

Hi,

> Absolutely correct. Having proxies use the same consistent rules should be sufficient.
>
> My point is that we cannot define proxy behavior based on having a transaction in progress. This is only non-ambiguous and implementable for a UA.

If the proxy is not aware of transactions, it could always behave in the same way, i.e., always insert/modify the same S-E and Min-SE header field values in INVITEs and UPDATEs.

I really see no reason why a proxy should suddenly change session timer behavior - especially a proxy that is not session aware, or aware of other ongoing transactions.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 15 May 2020 04:09:32 -0400

On Fri, May 15, 2020 at 3:30 AM Christer Holmberg <
[email-masked]> wrote:

> >>> that can be ambiguous due to network delays or message re-ordering
> even if it is always on the dialog path. Second, the amount of state
> maintained
> >>> multiple physical servers sharing an address behind a load balancer,
> so UPDATE and INVITE transactions can end up on the different servers.
> >>
> If the proxy is not aware of transactions, it could always behave in the
> same way, i.e., always insert/modify the same S-E and Min-SE header field
> values in INVITEs and UPDATEs.
>
> I really see no reason why a proxy should suddenly change session timer
> behavior - especially a proxy that is not session aware, or aware of other
> ongoing transactions.
>
>
Proxy can be dialog aware but not aware of all the transactions in the
dialog. Proxy behavior most likely must be defined in a way that the rules
by which it inserts S-E and Min-SE headers should be consistent
throughout the dialog. I do not see there is a reason for a proxy to
suddenly change session timer behavior during the dialog.

Behavior of UA should be defined in such a way that they can change S-E and
Min-SE headers, since B2BUA scenarios can cause such behavior. Doing this
can be limited in scope since UA are obviously both transaction and dialog
aware.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 May 2020 13:45:22 +0000

Hi,

>> I really see no reason why a proxy should suddenly change session timer behavior - especially a proxy
>> that is not session aware, or aware of other ongoing transactions.
>>
>> Proxy can be dialog aware but not aware of all the transactions in the dialog. Proxy behavior most likely must be defined in a way that the rules by which it inserts S-E and
>> Min-SE headers should be consistent throughout the dialog. I do not see there is a reason for a proxy to suddenly change session timer behavior during the dialog.
>
> Behavior of UA should be defined in such a way that they can change S-E and Min-SE headers, since B2BUA scenarios can cause such behavior. 
> Doing this can be limited in scope since UA are obviously both transaction and dialog aware.

Could you please start a separate thread ("4028bis: B2BUA assumption", or something) and describe such B2BUA use-case(s). I think it would be useful, and perhaps something we should document in the bis.

Regards,

Christer