[sipcore] proxy's behavior when uac does not support timer

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