Using a Push Notification Gateway to improve session initiation with SIP user agentsMetaswitch NetworksMichael.Arnold@metaswitch.comSIPCOREThis document describes how a Push Notification Gateway (PNG) network element can be used to allow SIP User Agents (UA) to run on devices where background processing and monitoring is limited. In these circumstances, it cannot be assumed that the SIP UA can regularly REGISTER with the network or be able to detect inbound messages. A PNG stores details provided to it by the UA during registration to prompt a Push Notification Service (PNS) to generate a real-time notification for the UA to REGISTER with the network and therefore be available for inbound SIP messages.Some mobile Operating Systems require or recommend that applications do not persistently monitor for specific network events.
These Operating Systems may additionally or alternatively limit the amount or frequency of background processing. This presents
problems for SIP User Agents (UAs) running on such devices which necessarily need to monitor for changes in the network, for
inbound SIP messages and to re-register with the network at regular intervals.This specification outlines a method whereby SIP UAs that can receive requests from a Push Notification Service (PNS) can
leverage push notifications to ensure availability for receiving standard SIP messages from the VoIP network.This solution requires the following network elements (fully defined below) to be present:A SIP UA capable registering for push notifications and adding details of push notification subscriptions to SIP REGISTER
requests.A Push Notification Service (PNS) capable of accepting subscriptions from applications (in this context the SIP UA) and
providing a unique token to that application that can be used to create a non-end-user generated real-time notification to the
application.A Push Notification Gateway (PNG). This new network element is in the signalling path between the UA and the SIP registrar.
The PNG is capable of storing PNS details provided by a SIP UA in a map with its registrations. The PNG is capable of generating
push notifications to the UA by invoking the PNS.During registration, the SIP UA adds details of the type of push notification service and any PNS tokens to the Contact
header on its SIP REGISTER request. The PNG receives the REGISTER, stores off the SIP UA's PNS details and passes the
REGISTER through as a SIP Proxy.The PNG can then contact the PNS to generate a push notification for the SIP UA, this forces the UA to re-register with the
network. The PNG can perform this procedure to ensure the SIP UA registers in a timely manner if the UA cannot schedule a background
task to do so itself. The PNG can also perform this procedure when it receives a SIP INVITE or out-of-dialog request that needs to
be routed to the SIP UA. In this instance the PNG will store the SIP request, solicit a push notification for the UA from the PNS,
await a successful REGISTER flow from the UA and then forward or reroute the suspended SIP message. This ensures the UA is scheduled
to process the inbound message and that the PNG has the most up-to-date network information for the UA prior to sending the message. Illustrates mainline scenario for Push Notification Gateway. | | |
| Accept (token) | | |
| | REGISTER |
| | | (token) |
| | | -------------> |
| | | 200 |
| | | |
| | Notification | |
| | (token) | |
| | | |
| | | REGISTER |
| | | (token) |
| | | -------------> |
| | | 200 |
| | | | |
| 200 | |
| ------------------------------------> | |
| | | 200 (INV) |
| | | -------------> |
| | | ACK |
| ACK |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
As most push notification services are provided for use on mobile devices it is
possible that the device has moved access networks or has had a Network Address Transversal
(NAT) pinhole close since it last registered. On some platforms SIP UA applications
may not be or cannot be alerted to these changes in network conditions.To address this problem, this specification sets out a method whereby all inbound SIP INVITE or out-of-dialo
requests to the SIP UA are preceded by the Push Notification Gateway (PNG) sending a
push notification via the Push Notification Service (PNS) prompting the SIP UA to
re-register with the network. This re-registration provides up-to-date contact details as well as ensuring that
any required NAT functionality is in place in the access network. Once this REGISTER
flow has completed successfully then the SIP PNG can contact the device successfully.This specification follows the guidance provided by Mobile OS providers for waking
OTT VoIP applications to handle incoming call requests. The SIP UA must be a SIP client
conforming to .If a SIP User Agent wishes to receive push notifications prior to inbound INVITE or out-of-dialog requests it MUST include pn-svc, pn-app-id and pn-token URI parameters on the Contact header of its REGISTER requests. The details of how these fields are generated during the process of the SIP UA registering with the PNS are implementation specific and are beyond the scope of this document. The pn-svc parameter MUST contain the push notification service identifier. This is an identifier which uniquely identifies a push notification service that has been configured on the PNG. The pn-token parameter MUST contain the push notification service token. This is a token that the PNG can provide to the PNS to generate a notification to the device running the SIP UA.The pn-app-id parameter MUST contain the push notification service app id. This is a unique indicator for the SIP UA so that the operating system on the device correctly serves the notification to the SIP UA. The combination of pn-app-id and pn-token must contain enough information to uniquely define the SIP user agent among all functions with push notification subscriptions on the service.If a UA wishes to receive push notifications using a fictional push notification service "abc" then an example Contact header on a REGISTER request would be the following:Contact: "Alice"<sip:SIPUA@11.22.33.44:5060>;expires=3600;pn-svc=abc;pn-app-id=1234.com.sipua.application;pn-token=abcdef1234567890These fields being present indicates that the user agent MUST be sent a push notification prior to receiving any inbound messages. These parameters MUST either all be present on a REGISTER request or all absent. Subsequent REGISTER requests from the SIP UA MAY add, remove or modify these parameters to reflect changes in the UA's capabilities or requirements. If a notification is not received prior to a dialog creating inbound SIP message then the UA SHOULD handle the request normally if possible.Each SIP registration can support at most one push notification association. If a user agent requires notification through multiple different services it MUST include the details in separate SIP registrations.On receipt of a push notification the User Agent MUST immediately attempt to send a REGISTER request to its SIP registrar refreshing the registration that matches the received token. This MUST be done regardless of the amount of time left until the registration expires. The user agent MAY subsequently carry out processing based on any payload attached to the push notification. The user agent MUST NOT process any SIP messages encoded in push notifications.It is expected that different push notification services will have varying designs and implementations for their interfaces. For a PNS to conform to this specification it MUST meet the following criteria:The PNS MUST accept subscriptions for specific applications on specific devices, returning to the application a unique token specific to that application on that device.The PNS MUST generate a push notification for that application and device that is served to the application in real-time when the token generated during the subscription process is provided in a pre-defined format to the PNS.The generated push notification MUST immediately schedule the application and allow it to process the notification.The PNS MUST allow push notifications to be generated from devices other than the device making the subscription.The PNG is a network element that acts as a SIP proxy transparently routing SIP traffic with the following additional functionality. The PNG MUST do the following:Store a mapping between SIP registrations and any push notification configuration parameters included on the REGISTER requests.Send push notifications for inbound dialog creating, or out of dialog, SIP requests to such registrations and delay the request until the device has re-registered through the PNG.Additionally the PNG MAY use the PNS to ensure reliability of reREGISTERs for SIP registrations it has a stored push notification mapping for.The PNG MUST be configured with a method of contacting push notification servers for each push notification server type supported by the PNG. The exact method for contacting these services is expected to vary between the service implementations. The PNG MAY be configured such that it rejects REGISTER requests based on either support or lack of support for a particular push notification service. Alternatively the PNG MAY choose to ignore services it does not recognise or does not support. The PNG MAY base decisions on whether a push notification service is required or not based on other information in the REGISTER, e.g. User-Agent value.When the SIP UA registers with the network it will include information relating to the push notification service as parameters on the Contact header. The PNG MUST save off this information in association with the SIP registration. The PNG MAY pass this information on to the SIP registrar function in the network or MAY remove it. If a UA attempts to register with an unacceptable push notification service then the PNG MAY reject the request, if it does so it MUST send a SIP 503 error response.On receipt of an inbound SIP INVITE or out-of-dialog request the PNG MUST check whether the request is for a registration for which there is valid stored push notification information. If so then the PNG MUST do the following:It MUST immediately send a 100 response for the request. It MUST NOT immediately send on the inbound INVITE or out-of-dialog request to the UA. Instead the PNG MUST store this message. The PNG SHOULD begin a timer between 5 seconds and 30 seconds in duration.It MUST attempt to contact the push notification server configured for the type of push notification stored in association with the UA's registration. The content and delivery of this message will vary between push notification services. As part of this transaction it is expected that the PNG will use the push notification service name to decide which service to contact and the push notification token and application id to signal which user agent to notify. This message MAY contain an arbitrary message body with additional instructions to the UA. This message MUST NOT contain the SIP message that has been stored. If the push notification server returns an error code or cannot be contacted the PNG should send a 503 response to the SIP request and cease processing it.It MUST await a successful registration flow for a SIP UA matching the aor on the inbound request URI. Once such a flow is complete the PNG MUST amend the stored INVITE or out-of-dialog request so that any SIP headers containing URI's related to the UA use updated routing information. If the timer expires before a successful registration flow completes the PNG SHOULD reject the SIP request with a SIP 503 response and cease processing it.The PNG MUST then send the INVITE or out-of-dialog request on to the UA and cancel the timer.If the PNG does not have any push notification service configuration stored for this UA or the request is not an INVITE or out-of-dialog, then it should pass through the request transparently.The PNG MAY choose to send a push notification even if there is no INVITE or out-of-dialog request outstanding. This mechanism can be used to ensure that a SIP UA remains registered to the network.The section defines new SIP URI parameters, by extending the grammar for "uri-parameter" as defined in RFC3261. The ABNF is as follows:Uri-parameter = / pn-svc / pn-app-id / pn-tokenpn-svc = "pn-svc" EQUAL pvaluepn-app-id = "pn-app-id" EQUAL pvaluepn-token = "pn-token" EQUAL pvalueSecurity of messages sent through the PNS is subject to the implementation of the PNS and is therefore beyond the scope of this document. This specification defines new SIP Contact header parameters that extend those defined in Header Field: ContactParameter Name: pn-svcPredefined Values: NoHeader Field: ContactParameter Name: pn-app-idPredefined Values: NoHeader Field: ContactParameter Name: pn-tokenPredefined Values: No