Re: [sipcore] RFC4028 : Very basic question in 8.1

[Paul Kyzivat <[e-mail]>]

On 7/11/20 12:11 AM, OKUMURA Shinji wrote:
> Hi,
> 
> On 2020/07/11 0:26, Paul Kyzivat wrote:
>> On 7/10/20 10:56 AM, OKUMURA Shinji wrote:
>>> On 2020/07/10 2:11, Paul Kyzivat wrote:
>>>>> What I am trying to avoid is ending up with a non-obvious set of 
>>>>> changes to an existing specification which will act as a barrier to 
>>>>> implementation. Letting proxies increase SE would be an example of 
>>>>> such change.
>>>>
>>>> Upon rereading 4028 I was surprised to discover that proxies MAY 
>>>> increase SE to the extent necessary to conform with an increased 
>>>> Min-SE! I hadn't remembered that part. But AFAIK that is the only 
>>>> case where it is allowed.
>>>
>>> In fact, proxy is conditionally allowed to increase SE directly 
>>> without renegotiation. And RFC does not specify the procedure to 
>>> reject if too large.
>>
>> Where do you find this in 4028.
> 
> P.13
>     If the value of the Session-Expires header field is lower
>     than the value of the Min-SE header field (possibly because the proxy
>     increased the value of the Min-SE header field, as described below),
>     the proxy MUST increase the value of the Session-Expires header field
>     to make it equal to Min-SE header field value.
> 
> Of course, negotiation with downstream proxies and UAS will occur.

OK. But that only allows increasing up to the value of Min-SE. It 
doesn't otherwise allow increasing SE.

>>> This is why I interpret the RFC does not attach importance to 
>>> increase of SE.
>>>
>>> And you said,
>>>> If the Min-SE and SE are higher than one of the proxies desires, 
>>>> then it is pretty much out of luck. In some sense this is futile for 
>>>> it to complain because the timer refreshes are only part of the 
>>>> traffic.
>>>
>>> So, I want to know why must a proxy not increase SE-value?
>>> I think this is a very basic and important premise of RFC, but there 
>>> is no specific explanation.
>>> I say again, this is not a suggestion, but a question.
>>
>> If proxies along the path (and the UAS) could both increase and 
>> decrease the value of SE, then you don't have a negotiation. Rather, 
>> those further along the path have priority over the earlier ones.
>>
>> By having both SE and Min-SE, with SE only being reduced and Min-SE 
>> only increased, everybody on the path has input into the final result.
> 
> I understand the basic policy, but when the UAC that received the 422 
> response retransmits the INVITE with a larger SE and MSE set, the proxy 
> cannot reduce the SE. I think the result will be the same as if the 
> proxy increased SE.

But this requires that the 422 be issued, and that the UAC be willing to 
retry with the values it contains. Until we get to this point everybody 
gets to have their vote counted.

The bottom line is that when there is a conflict, with some parties 
requiring that SE be larger and some requiring it to be smaller, the 
larger preference wins. This is effectively valuing efficiency of 
processing over cost of saving state longer, or if you prefer, valuing 
UAs over proxies.

But this tradeoff only occurs if there is no happy medium that all can 
live with.

	Thanks,
	Paul