Subject: [sipcore] Session-timer: Min-SE in 2xx

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 10 Oct 2018 12:02:18 +0900

Hi,

According to the current RFC, only the UAS knows the maximum Min-SEC finally determined.
In order to advertise this information to proxies and the UAC, I think that the UAS may copy the Min-SE from the 2xx response request.

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2018 00:54:05 -0400

> In order to advertise this information to proxies and the UAC, I think that the UAS may copy the Min-SE from the 2xx response request.

Why is it necessary for the proxies and UAC to know this as long as they 
know the S-E that has been determined?

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 10 Oct 2018 16:01:08 +0900

Hi Paul,

7.4.  Generating Subsequent Session Refresh Requests

   The value of the Min-SE header field present in a session refresh
   request MUST be the largest value among all Min-SE header field
   values returned in all 422 responses or received in session refresh
   requests, on the same dialog, if a dialog has been established.  If
   no dialog has been established, the Min-SE header field value is set
   to the largest value among all Min-SE header field values returned in
   all 422 responses for an INVITE request with the same Call-ID.  A
   result of this rule is that the maximum value of the Min-SE is
   effectively 'cleared' once the dialog is established, and from that
   point on, only the values from proxies known to be on the proxy path
   will end up being used.

To be honest, I do not really understand the meaning of "cleared",

IIUC, UAC and UAS seem to be expected to have a shared view for Min-SE.
And at the beginning of writing, this RFC seems not to assume that the Min-SE header is changed through the transaction.
Needless to say, if the Min-SE header is not changed through the transaction, UAC and UAS have a shared view for Min-SE.
So that, the answer to your question is the same as the reason UAC MUST add the maximum Min-SE header to the request.
If UAC needs not to know theshared view for Min-SE, it needs not to add the maximum Min-SE.

Regards,
Shinji

On 2018/10/10 13:54, Paul Kyzivat wrote:
> Why is it necessary for the proxies and UAC to know this as long as they know the S-E that has been determined?
>
>     Thanks,
>     Paul
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2018 14:27:31 -0400

> To be honest, I do not really understand the meaning of "cleared",

Nor do I. But we can try to figure out what it was trying to say.

The rfc seems to envision proxies forcing renegotiation by sending a 422 
response, in the expectation that this will force a retry that will 
result in a larger S-E value. For this to work, the UAC must remember 
the Min-SE in the 422, and reuse it in retries. If there are multiple 
retries due to multiple 422 responses (from proxies further along the 
route), the max of these must be used in subsequent retries.

The text in 7.4 seems to also be intending that the final Min-SE then be 
used in refresh requests within the dialog once established. It isn't 
clear to me why that is necessary, as long as the S-E value is 
preserved. I don't see why Min-SE is required at all within an 
established dialog, unless there is an intent to renegotiate the timer. 
If that is the intent, then ISTM it would be better to release all 
constraints and simply do the whole negotiation over. (But this could 
cause serious trouble of it causes reINVITE or UPDATEs to fail with 422.)

I also suspect that forking was not considered with this was written. If 
there is forking along the path and proxies on one or more paths return 
422, then the forking proxy is forced to hold those responses until it 
has heard from all forks, and it then can only return a single 422. If 
more than one fork returned 422, then the forking proxy ought to return 
a 422 with the largest Min-SE value.

"Clearing" once the dialog is established seems to me to be talking 
about cleaning up irrelevant information that may have been received as 
a result of forking during initial dialog establishment, when there 
might be multiple paths, and also proxies that don't record-route and so 
aren't on the path once the dialog has been established.

Does that make any sense? I don't think so.

Once a successful response is received, I think we can assume that the 
Min-SE value the UAC used in the request must have been required to 
establish the dialog, and to have come from a proxy on the path to the 
selected UAS. I see nothing to "clear" here.

Or perhaps it is trying to address a case where there was a proxy on the 
path that inserted a Min-SE (or increased it) but that proxy didn't 
record route and so isn't on the path for refreshes. But ISTM that it 
would be improper for a proxy to take any part in timer negotiation if 
it won't be on the path for the dialog. So I don't see need for any 
"clearing" there either. Perhaps we could add a MUST NOT for proxies 
that won't be on the path just to make this clear.

> IIUC, UAC and UAS seem to be expected to have a shared view for Min-SE.

I still don't understand why there is need for anything other than the 
UAS (or the final proxy prior to a UAS that lacks support) to know what 
the final Min-SE value was. Its only need is to select the final S-E value.

> If UAC needs not to know theshared view for Min-SE, it needs not to add the maximum Min-SE.

Clearly proxies can change (increase) the value as they forward the 
transaction.

I don't understand why there need be any carryover of the Min-SE value 
from the initial establishment to subsequent refresh transactions. Or 
even why Min-SE would be used at all in refresh requests. It should not 
be needed as long as S-E is preserved and the proxies don't change their 
mind about their needs.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Oct 2018 15:18:48 +0900

Hi,

I agree with your commentary.
We may have to change the rules that the Min-SE value MUST be the largest one.

For example, the following modifications

A UA should send an "Min-SE" that indicates what it, and its user, are
interested in using/doing at that time, without regard for what the
other party in the call may have indicated previously.

What do you think?

Regards,
Shinji

P.S.
> Clearly proxies can change (increase) the value as they forward the transaction.

The current RFC forbids this behaviour if UAC does not support session-timer.
But I think this is necessary.

On 2018/10/11 3:27, Paul Kyzivat wrote:
> The rfc seems to envision proxies forcing renegotiation by sending a 422 response, in the expectation that this will force a retry that will result in a larger S-E value. For this to work, the UAC must remember the Min-SE in the 422, and reuse it in retries. If there are multiple retries due to multiple 422 responses (from proxies further along the route), the max of these must be used in subsequent retries.
>
> The text in 7.4 seems to also be intending that the final Min-SE then be used in refresh requests within the dialog once established. It isn't clear to me why that is necessary, as long as the S-E value is preserved. I don't see why Min-SE is required at all within an established dialog, unless there is an intent to renegotiate the timer. If that is the intent, then ISTM it would be better to release all constraints and simply do the whole negotiation over. (But this could cause serious trouble of it causes reINVITE or UPDATEs to fail with 422.)
>
> I also suspect that forking was not considered with this was written. If there is forking along the path and proxies on one or more paths return 422, then the forking proxy is forced to hold those responses until it has heard from all forks, and it then can only return a single 422. If more than one fork returned 422, then the forking proxy ought to return a 422 with the largest Min-SE value.
>
> "Clearing" once the dialog is established seems to me to be talking about cleaning up irrelevant information that may have been received as a result of forking during initial dialog establishment, when there might be multiple paths, and also proxies that don't record-route and so aren't on the path once the dialog has been established.
>
> Once a successful response is received, I think we can assume that the Min-SE value the UAC used in the request must have been required to establish the dialog, and to have come from a proxy on the path to the selected UAS. I see nothing to "clear" here.
>
> Or perhaps it is trying to address a case where there was a proxy on the path that inserted a Min-SE (or increased it) but that proxy didn't record route and so isn't on the path for refreshes. But ISTM that it would be improper for a proxy to take any part in timer negotiation if it won't be on the path for the dialog. So I don't see need for any "clearing" there either. Perhaps we could add a MUST NOT for proxies that won't be on the path just to make this clear.
>
> I still don't understand why there is need for anything other than the UAS (or the final proxy prior to a UAS that lacks support) to know what the final Min-SE value was. Its only need is to select the final S-E value.
>
> Clearly proxies can change (increase) the value as they forward the transaction.
>
> I don't understand why there need be any carryover of the Min-SE value from the initial establishment to subsequent refresh transactions. Or even why Min-SE would be used at all in refresh requests. It should not be needed as long as S-E is preserved and the proxies don't change their mind about their needs.
>
>     Thanks,
>     Paul
>
>
>> Regards,
>> Shinji
>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Oct 2018 17:05:52 +0900

> The current RFC forbids this behaviour if UAC does not support session-timer.

[It is correct as follows]

The current RFC forbids this behaviour if UAC support session-timer.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2018 09:10:44 +0000

Hi,

Could you create an issue in GitHub for this?

The IETF meeting is coming up, and when I do my slides etc I don't want to go through tons of e-mails in order to make sure I get all suggested changes etc :)

Regards,

Christer

On 12/10/2018, 11.06, "sipcore on behalf of OKUMURA Shinji" <[email-masked] on behalf of [email-masked]> wrote:

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Oct 2018 23:54:32 +0900

Hi,

It got bigger than the original intention...

=========================
BACKGROUND:

Section 7.3 of RFC 4028 says about a processing a 422 response
Section 7.4 of RFC 4028 says about a session refresh request within a
established dialog and a retry of initial session refresh request due to
422 responses.

SUGGESTION:
We modify section 7.3 to explain a processing a 422 response and a retry
of initial session refresh request due to 422 responses.
And we modify section 7.4 to explain a session refresh request within a
established dialog.

-------------------------
7.3. Processing a 422 Response Before the dialog is established

If the response to a session refresh request is a 422 (Session Interval
Too Small) response message, then the UAC MAY retry the request.

This new request constitutes a new transaction and SHOULD have the same
value as the Call-ID, To, and From of the previous request, but the CSeq
should contain a new sequence number that is one higher than the previous.

The values of Supported, Require, and Proxy-Require used in this new
request MUST be equal to the values of the previous request.

A UAC MUST insert the Min-SE header field into this new request and the
value of the Min-SE header field is set to the largest value among all
Min-SE header field values returned in all 422 responses for sequential
INVITE requests with the same Call-ID.

The UAC may have its own opinions about the minimum session interval. In
that case, the UAC MAY increase the value of the Min-SE header field.

In this request, the Session-Expires header SHOULD be present and it's
value SHOULD be equal to the maximum of the Min-SE header field.

-------------------------
7.4. Generating Session Refresh Requests within a Established Dialog

The values of Supported, Require, and Proxy-Require used in the initial
Session refresh request MUST be used.

The UAC SHOULD insert the Session-Expires header field, and it's value
SHOULD be equal to the current session interval.

The UAC MAY insert the Min-SE header field into a session refresh request.

Once the dialog is established, the maximum value of the Min-SE is
cleared and a UA may decide the Min-SE header field value without regard
for the Min-SE header received previously.

If the UAC receives 422 response for a session refresh request, the
behavior of UAC conforms to section 7.3.

(snipping)
=========================

Regards,
Shinji