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,

A follow-up on one issues.

§4.2:

>>>  The UA can do so by only including the pn-provider  SIP URI 
>>> parameter in the SIP Contact header field URI of the REGISTER  
>>> request, but without including the pn-prid SIP URI parameter.
>>
>> Unless I'm mistaken, this is a barrier to interoperation.
>>
>> It's not 100% clear, but I suspect the intended implication is that 
>> the pn-provider parameter here will contain a single value? The syntax of the 
>> parameter certainly seems to imply that. This seems to be a pretty big problem, since 
>> it presupposes that the client will know which PNSes the Proxy supports.
>> Consider, for example, an iOS client that can use any of RFC 8030, FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
>> If the client doesn't know a priori what the proxy supports (and this 
>> entire section only makes sense if that's true), then it won't know which of those three services to 
>> indicate in its REGISTER request. If it guesses wrong, this mechanism simply fails.
>>
>> 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. 

The text in the draft says:

"The proxy MUST indicate support only of the same PNS that was identified
 in the pn-provider SIP URI parameter in the REGISTER request."

So, in the query case, if the UA indicates support of multiple PNS, I guess the proxy could do the same. The UA will then choose one.

I assume what you meant with your second alternative is that a proxy would indicate every PNS it supports no matter what the UA indicates. I could live with that. In that case we don't need to change the syntax of pn-provider - we could say that the single PNS indicated by the UA is the "preferred one", or something like that.

Regards,

Christer



Regards,

Christer