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

From: Mickey Arnold <[email-masked]>
Date: Wed, 6 Dec 2017 10:56:24 +0000

Hi Christer,

As we're considering adopting this draft (which I support), I reviewed it and had the following comments, which I'd like to see addressed once it's adopted. There's also a few smaller things that I think could use tweaking but those are mostly dependent on the overall solution so I'll save them for now.

General

  *   It would be useful to have a name for the logical function of sending the push notifications as it gets a bit confusing trying to refer to multiple SIP Proxys, some of which may be sending push notifications and/or be a SIP registrar. I'm going to use the term PNG (Push Notification Gateway) here to help disambiguate but I'd be perfectly happy with a different name .
  *   I believe the implication in this document is that the SIP UA must always have REGISTER requests sent via the PNG, please can you confirm?
  *   I'm a little confused about the overall design proposed here. So taking a step back, my understanding from your draft is the following.

The SIP registrar is responsible for:

     *   Keeping track of the state of the push notification subscriptions as communicated by the UA (as part of a SIP registration).
     *   Adding the correct URI parameters to SIP requests based on these subscriptions embedded in the SIP registrations.
     *   Serving information to the PNG to send push notifications for re-registrations.

The PNG is then responsible for:

  *   Prompting the UA to re-register based on information stored on the registrar.
  *   Taking URI parameters from SIP requests, generating the push notifications, then forwarding on the request once a re-registration is received.
With some optimisations if the PNG is also the SIP registrar.
However, in the case where the PNG is not also the SIP registrar I don't think this solution quite works, as I'll outline below.

Section 5.2

   If the SIP UA needs to perform periodic re-registrations, the SIP

   proxy needs to have information about when those re-registrations are

   to be performed.  The SIP proxy either needs to contain the SIP

   registrar functionality, or the SIP proxy needs to retreive the

   information from the registrar using some other mechanism.

If my view of the overall design above is correct then I think we've already hit a snag. If the PNG is on a non-registrar SIP Proxy then how does the PNG know what SIP UAs to query the registrar for? Given that the REGISTER requests must go through the PNG it seems simpler for the PNG to save off the push notification in a mapping with the registration and take responsibility for generating the push notification for refreshing the registration. This avoids adding another (presumably non-SIP?) interface between the registrar and the PNG.

If the PNG is also the registrar then it needs to generate notifications for each of its registrations every time a registration would expire. That's not a huge problem but does seem like a big increase in load on the registrar. I also don't think it's conceptually correct for the registrar in the core of the network to need to take responsibility for interoperating with devices that require push notifications to be able to communicate reliably.

Section 5.3

   When the SIP proxy receives a SIP request for a new dialog (e.g., a

   SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE

   request) aimed for a SIP UA, if the Request-URI of the request

   contains a pn-prid URI parameter, the SIP proxy triggers a push

   request towards the push notification server associated with the

   PRID.

If the PNG is also the registrar then the parameter won't be on the inbound SIP request and shouldn't be required to trigger a push notification. I suspect this is the intention but it would be good to have it clarified. Again, this also feels like the wrong place in the network for this functionality to be invoked and is a big load increase on the registrar.

If the PNG is on a non-registrar SIP Proxy then there is a reliance on the registrar to be compliant and store/add the push notification parameters and all intervening network elements to not remove the push notification parameters. In theory that should be fine but in practice requires a handful of other pieces of network equipment to be RFC compliant. Given my comments on section 5.2 I think it makes sense that if the PNG is on a non-registrar SIP Proxy then it is permitted to use  locally stored subscription details to generate push notifications when receiving inbound SIP requests, as an alternative to requiring URI parameters to be present. This allows a PNG on a non-registrar SIP Proxy that supports this standard to operate independently of a core network that doesn't support this standard. Given this is a relatively thin layer of access network functionality it will likely be easier for network operators to add in at the edge of their network rather than replace their registrar. The introduction's 5th paragraph also implies this is allowable so maybe this was the intention?

   If the proxy is not able to contact the push notification provider,

   or even determine which push notification provider to contact, it

   SHOULD reject the SIP request.

If the PNG is on a non-registrar SIP proxy and doesn't support a push notification service required by the UA then we get the following scenario:

*         UA registers successfully using a PNS that the PNG doesn't support.

*         Inbound call is routed to the UA.

*         PNG rejects the call.

*         UA requires being woken up to re-register.

*         PNG cannot contact the PNS to generate a notification to prompt for this.

I believe that the PNG needs to be able to reject register requests that require an unsupported push notification service. That gives immediate feedback to the UA rather than a "silent failure" case where the registration is successful but there's no way for the UA to reliably receive inbound calls.

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>

That nominally splits into:

  *   Name of provider, which the PNG can use to decide a) whether the service is supported b) how to handle it if it is.
  *   Token used to identify the SIP UA's subscription with the PNS.
  *   Extra PNS specific details used for contacting either the push notification service or the UA application on the target device.

Conclusion
I'd recommend allowing a PNG on a non-registrar SIP proxy to store off minimal details of push notification services in a mapping with the Contact header SIP URI from successful registration flows through the PNG. The PNG on a non-registrar SIP proxy can then handle re-registrations and outbound calls without any requirement on the capabilities of the rest of the network. This allows the work to be distributed across several such SIP Proxys at the edge of the core network, requires only one spec compliant network element and can easily be added on an existing, or new, light-weight SIP proxy without too much disturbance to the network.

In the case of the PNG being on a non-registrar SIP proxy we'd then have the following responsibilities:
The SIP registrar is responsible for:

  *   Nothing special other than being a SIP registrar.
The PNG is then responsible for:

  *   Storing off push notification details on successful REGISTER requests flowing through the SIP proxy in a mapping with the registration.
  *   Keeping track of registration expiry and prompting the UA to re-register.
  *   Policing register requests to check that an acceptable push notification service is requested.
  *   Taking URI parameters from SIP requests, generating the push notifications, then forwarding on the request once a re-registration is received OR matching inbound SIP requests with stored registration details and generating push notifications.

I hope that's useful, please let me know if you have any questions or would like any clarifications.

Thanks very much,
Michael Arnold

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 23 November 2017 08:42
To: [email-masked]
Subject: [sipcore] Draft new version: holmberg-sip-push-03

Hi,

Based on the feedback in Singapore, and on the list, I have submitted a new version (-03) of draft-holmberg-sipcore-sip-push.

The draft now also covers re-registrations:

  *   UA performing re-registrations when a push notification is received.
  *   Proxy forwarding SIP request when it receives the re-registration request.
Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Dec 2017 16:59:59 +0000

Hi Mickey,

Thanks for your comments! Please see my replies inline.

General
> . It would be useful to have a name for the logical function of sending the push notifications as it gets a bit confusing trying to 
> refer to multiple SIP Proxys, some of which may be sending push notifications and/or be a SIP registrar. I'm going to use the 
> term PNG (Push Notification Gateway) here to help disambiguate but I'd be perfectly happy with a different name .

Unlike e.g., 3GPP, in IETF we normally don't define new SIP functions. We define SIP features, and then we describe the feature impacts on SIP UAs and/or SIP proxies.

> . I believe the implication in this document is that the SIP UA must always have REGISTER requests sent via the PNG, please can you confirm?

That is correct.

> . I'm a little confused about the overall design proposed here. So taking a step back, my understanding from your draft is the following. 
> o Keeping track of the state of the push notification subscriptions as communicated by the UA (as part of a SIP registration).
> o Adding the correct URI parameters to SIP requests based on these subscriptions embedded in the SIP registrations.
> o Serving information to the PNG to send push notifications for re-registrations.
> o Prompting the UA to re-register based on information stored on the registrar.
> o Taking URI parameters from SIP requests, generating the push notifications, then forwarding on the request once a re-registration is received.
>   registrar functionality, or the SIP proxy needs to retrieve the
> If my view of the overall design above is correct then I think we've already hit a snag. If the PNG is on a non-registrar SIP Proxy 
> then how does the PNG know what SIP UAs to query the registrar for? Given that the REGISTER requests must go through the 
> PNG it seems simpler for the PNG to save off the push notification in a mapping with the registration and take responsibility 
> for generating the push notification for refreshing the registration. This avoids adding another (presumably non-SIP?) interface 
> between the registrar and the PNG.
>
> If the PNG is also the registrar then it needs to generate notifications for each of its registrations every time a registration would expire. That's 
> not a huge problem but does seem like a big increase in load on the registrar. I also don't think it's conceptually correct for the registrar in the
> core of the network to need to take responsibility for interoperating with devices that require push notifications to be able to communicate reliably.

You raise concern about implementing the PNG as part of the registrar in a number of places, but I will address it here.

Section 5.2. allows the PNG to be part of the registrar, or to be part of a non-registrar - in which case it "needs to retrieve the information from the registrar using some other mechanism". 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.

> If the PNG is also the registrar then the parameter won't be on the inbound SIP request and shouldn't be required to trigger a 
> push notification. I suspect this is the intention but it would be good to have it clarified.

That's a good point. We need to clarify that.

> If the PNG is on a non-registrar SIP Proxy then there is a reliance on the registrar to be compliant and store/add the push 
> notification parameters and all intervening network elements to not remove the push notification parameters.

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.

> . UA registers successfully using a PNS that the PNG doesn't support.
> . Inbound call is routed to the UA.
> . PNG rejects the call.
> . UA requires being woken up to re-register.
> . PNG cannot contact the PNS to generate a notification to prompt for this.
> I believe that the PNG needs to be able to reject register requests that require an unsupported push notification service. 
> That gives immediate feedback to the UA rather than a "silent failure" case where the registration is successful but there's 
> no way for the UA to reliably receive inbound calls.

I agree. I was supposed to include text about that in the current version, but I realize I forgot.

There are also mechanisms (e.g., RFC 6809) that can be used to inform the UA what PNS the proxy supports.

> 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
> . Name of provider, which the PNG can use to decide a) whether the service is supported b) how to handle it if it is.
> . Token used to identify the SIP UA's subscription with the PNS.
> . Extra PNS specific details used for contacting either the push notification service or the UA application on the target device.

I will double check my notes at work tomorrow (I am out of office today), but from a first look I don't see any issues with your suggestion.

I did remove quite a bit of your text, as much was about the PNG-in-the-registrar. Please let me know if I forgot to address some of your comments - if I did, it was not on purpose :)

Regards,

Christer