Subject: Re: [sipcore] Draft new version: holmberg-sip-push-03 - URI parameters

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Dec 2017 12:55:24 +0000

Hi Mickey,

…

>Section 7
>I think the SIP parameters can be simplified here. Take the following cases, a UA using APNs would send the following parameters (from section 9):
>pn-type = apns:DEF123GHIJ.com.yourcompany.yourexampleapp

>pn-prid = 00fc13adff78512
>
>Given the description in Section 5.1:

>   In some cases the push notification provider can be retrieved from
>   the pn-prid URI parameter.  In other cases the pn-type URI parameter
>   is used to identity the push notification provider."
>
>I think a PNS that provides information based on a URI would look like this:
>pn-type = ???: <generic PNS token>
>pn-prid = genericPNS <URL>?
>
>How the data is handled is PNS specific, but in all cases the first thing any SIP proxy implementation would need to do is work out what type of push notification service is being used. I think it makes it simpler
>to read and implement (less escaping) if the pn-type is split into two URI parameters (possibly but not necessarily renamed). For APNs that would look something like this.
>pns-provider = apns

>pn-prid = 00fc13adff78512
>pns-param = DEF123GHIJ.com.yourcompany.yourexampleapp
>
>For the generic service is would look like
>pns-provider = genericPNS
>pn-prid = <generic PNS token>
>pns-param = <URL>

I had a look at this, and in general I have no problem to place the pns parameters in a separate URI parameter (pns-param).

However, I don’t think we can use <URL> syntax for the pns-param.  In the case of Firebase, the value represents the Sender ID, which is not a URL. I don’t even think the value in your apps example above is a valid URL, as it lacks the scheme :)

So, I suggest to keep pvalue:

       pns-param = pvalue    ;pvalue as defined in RFC 3261

Regards,

Christer

---

From: Mickey Arnold <[email-masked]>
Date: Fri, 8 Dec 2017 13:36:39 +0000

Hi Christer,

Thanks for the responses, I believe you've addressed everything. Similar to you, I've stripped out a lot of text here so let me know if I've missed anything this time!

> I don't think the document shall prevent people from implementing the PNG as part of the registrar, if that's what they want to do. Vendors and operators need to figure out what works best for them.

Agreed that it's fine if vendors wish to do so. I just wanted to highlight some of the flaws, as I don't think we should mandate it must be on the registrar which could have been the logical conclusion from me raising lots of concerns related to having the function on a non-registrar!

> The mapping table you mention would be an example of such "other mechanism", but I don't think that is something we want to standardize. And, there are also other mechanisms that can be used.

> I don't think the document shall prevent people from implementing the PNG as part of the registrar, if that's what they want to do. Vendors and operators need to figure out what works best for them.

Agree that it's good to be as permissive as possible, I was suggesting this as one of the additional mechanisms. Can I suggest you specifically highlight that a non-registrar proxy storing registration details is permissible in the next draft? With the text as written my understanding was that wasn't permissible.

> However, I don't think we can use <URL> syntax for the pns-param.  In the case of Firebase, the value represents the Sender ID, which is not a URL. I don't even think the value in your apps example above is a valid URL, as it lacks the scheme :)

This sounds good and I agree that pns-param shouldn't be restricted to being a URL. I was just using the URL as some example data, as you note that's not the case for APNs.

> The reason the PNS parameters are defined as URI parameters is because the registrar will store them, and include them in requests, using standard registrar procedures - we don't need to define new push-specific registrar functionality.

That was the behaviour that I expect some SIP Proxys or registrars not to adhere to. In practice some implementations of intervening SIP Proxys or registrars may remove parameters they don't support so as not to indicate capabilities they don't have or due to simply being a bad implementation. In the interests of being permissive, can we not allow the alternative where the SIP proxy sending the push notifications uses stored information rather than URI parameters? This could allow a SIP proxy at the edge of the network to function correctly despite a misbehaving core network. To clarify, I'm thinking of this as an alternative to the mechanism you've suggested, definitely not a replacement.

Thanks, Mickey