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

[Paul Kyzivat <[e-mail]>]

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.

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

	Thanks,
	Paul