Re: [sipcore] Allowing "far" proxies in sip-push

[Christer Holmberg <[e-mail]>]

Hi,

>> But, if we want to cover your proxy-out-of-path scenario, we can do 
>> that in a separate draft (similar to the Outbound case). Because, 
>> based on the text above, I think it requires a little more thinking 
>> than simply defining a new pn-aor parameter. As I said when this work 
>> started, there is an industry need for a solution now, the window for 
>> providing a standard solution is narrow, and the assumptions in the 
>> current version of the draft meet need.
>
> I intensely dislike the scenario of "The industry needs a solution now, and this is what the > industry has implemented, and so we must approve it."  This is a situation where the IETF > cannot maintain quality control over what it approves.

This is not what the industry has implemented yet - this is what we are trying to get the industry to implement, instead of all kind of different proprietary solutions that I have seen flying around.

My point is that this is not a new fancy feature that operators "may implement at some point in the future" - it is a feature that is needed now.

And, as you have said yourself, your suggested extension does not change the basic mechanism.
 
>In this particular case, my opinion is that the use of URI-parameters is architecturally >undesirable.  (Compare that in RFC 5626, reg-id and
>+sip.instance are header parameters.)  The *only* reason to make the URI
>parameters is scenarios where the implementing proxy is far enough from the registrar >that the only information it has in the incoming request is the contact URI.

A proxy can be "far" from the registrar even if it receives the REGISTER/re-REGISTER requests. 

Even in your suggestion the proxy needs to be aware of the registration status. The only extra seems to be that the proxy does not receive all REGISTER/re-REGISTER requests.

>> I am not aware of any case where the proxy (no matter whether it is 
>> "far" or "near") would not receive the REGISTER/re-REGISTER requests.
>
> OK, but I can easily construct such cases.

That is why I am suggestion we write it down in a separate draft. I think there would be a need for call flows showing your scenario(s), you were talking about extending the 'reg' event package etc...

>> Also, in your "Due to the network architecture..." sentence you seem 
>> to imply that the proxy would not receive the initial REGISTER (which 
>> is the reason pn-aor is needed), but it could receive the re-REGISTER 
>> requests. I have never heard about such use-case.
>
>The proxy must have received a register at some time in the past, or otherwise it would >not be receiving the incoming request now.  But if the proxy is any sort of "edge proxy", >there's no reason to assume that it must receive the re-REGISTER.

Even without push, I have never heard of about such scenarios. REGISTERs and re-REGISTERs always traverse the same path. Even with Outbound, REGISTERs/re-REGISTERs associated with a given flow traverse the same path.

>> Also, if the proxy does not receive the re-REGISTER request, there may 
>> be NAT issues when the proxy is trying to forward the request (since 
>> there is no re-REGISTER, Outbound keep-alive etc opening the pin 
>> hole).
>
> Ah, but if the proxy knows that the re-REGISTER has happened, then the NAT must have 
> been taken care of.  In that case, it can forward the request to the *new* contact URI.

Sure, but depending on the NAT that doesn't mean that requests from the proxy will be allowed through the binding - only request from the IP address of whoever received the re-REGISTER will.

Regards,

Christer