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,

Follow-up to my previous reply at the end.

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

I was mixing up the parameters. The syntax does allow indicating support of multiple PNS.

But, the procedures are based on the assumption that only one proxy inserts PNS information, and I don't think we should change that.

And, as I said in my previous e-mail, in all cases I am aware of there is anyway only one proxy doing the PNS stuff.

Regards,

Christer