Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the DISCUSS issues Part 2

[Christer Holmberg <[e-mail]>]

Hi,


>>>>> I think you need a different discovery mechanism here -- either have
>>>>> one that has the client offering multiple PNS protocols and the proxy
>>>>> responding with one, or have one in which the proxy indicates all of its
>>>>> supported services in a response, and the client chooses one to use in
>>>>> its next REGISTER message.
>>>>
>>>> I suggest the first option, where the client can offer multiple PNS protocols
>>>> (pn-provider values) and the proxy responds with one.
>>>
>>> There could be a situation where there are multiple proxies on the path, each
>>> supporting a different mechanism.
>>> Then what happens? Does the first proxy "win", or the last one?
>>>
>>> If this starts with the proxies each indicating their support, then the client gets
>>> to choose the one he prefers. This also means the client doesn't need to include
>>> any additional information until it knows that it will be supported. Of course this
>>> requires a double registration at startup, but considering the number of register
>>> requests that will be used during the session this doesn't seem a huge burden.
>>
>> If a proxy has indicated support of push, another proxy should not do it. The current
>> syntax doesn't allow it.
>>
>> Also, I am not aware of any scenario where there would be multiple proxies supporting
>> push, so I don't think it is a real-life issue. Even if a network support multiple PNSs, they
>> will all be handled by the same proxy.
>
>That seems unfortunate. It may be that there is no single proxy
>implementation that supports all the different, while there might not be
>a single PNS that all the clients support. What is the deployment to do
>in that case? Deploying multiple proxies on the path, supporting
>different PNSs would be a solution. It wouldn't be too burdensome
>because only the chosen one would need to stay on the path.
>
>But apparently that option is currently not supported.

Yes, it is. If a proxy receives a REGISTER with an indication of a PNS that it does not support, the current solution DOES allow it to forward the REGISTER request, if it "knows" that another proxy might support the PNS.

But, some operators do not want the REGISTER to reach the registrar if no proxy supports the PNS.

So, an operator can configure its network to act in a desired way.

Regards,

Christer