| SIPCORE | M. Arnold |
| Internet-Draft | Metaswitch Networks |
| Intended status: Standards Track | November 16, 2017 |
| Expires: May 20, 2018 |
Using a Push Notification Gateway to improve session initiation with SIP user agents
draft-arnold-sipcore-push-notification-gateway-00
This 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
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.
Figure 1 Illustrates mainline scenario for Push Notification Gateway.
SIP UA PNS SIP PNG Core Network + + + + | Subscribe | | | | ----------------> | | | | Accept (token) | | | | <----------------- | | | | REGISTER (token) | | | +------------------+----------------> | REGISTER | | | | (token) | | | | -------------> | | | | 200 | | | | <------------- | | 200 | | | <------------------------------------ | | | | | | / / / / / / / / | | | INVITE | | | | <------------- | | | | 100 | | | | ------------> | | | Notification | | | | (token) | | | | <--------------- | | | Notification | | | | (token) | | | | <----------------- | | | | | | | | REGISTER (token) | | | +-----------------------------------> | | | | | REGISTER | | | | (token) | | | | -------------> | | | | 200 | | | | <------------ | | 200 | | | <------------------------------------ | | | | | | | INVITE | | | <------------------------------------ | | | 100 | | | ------------------------------------> | | | 200 | | | ------------------------------------> | | | | | 200 (INV) | | | | -------------> | | | | ACK | | ACK | <------------- | | <------------------------------------ | | + + + +
Figure 1: PNG Mainline Scenario
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 [RFC2119].
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 [RFC3261].
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=abcdef1234567890
These 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 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:
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:
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-token
pn-svc = "pn-svc" EQUAL pvalue
pn-app-id = "pn-app-id" EQUAL pvalue
pn-token = "pn-token" EQUAL pvalue
Security 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 [RFC3968]
Header Field: Contact
Parameter Name: pn-svc
Predefined Values: No
Header Field: Contact
Parameter Name: pn-app-id
Predefined Values: No
Header Field: Contact
Parameter Name: pn-token
Predefined Values: No
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002. |
| [RFC3968] | Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004. |