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

Abstract

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.

Status of This Memo

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 Notice

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.


Table of Contents

1. Overview

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:

  1. A SIP UA capable registering for push notifications and adding details of push notification subscriptions to SIP REGISTER requests.
  2. 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.
  3. 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.

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

2. Conventions

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].

3. Avoiding misrouting as a SIP User Agent traverses a network

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.

4. SIP User Agent (UA) Behaviour

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].

4.1. Registering

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.

4.2. Receiving a Push Notification

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.

5. Push Notification Service (PNS) Behaviour

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:

  1. 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.
  2. 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.
  3. The generated push notification MUST immediately schedule the application and allow it to process the notification.
  4. The PNS MUST allow push notifications to be generated from devices other than the device making the subscription.

6. Push Notification Gateway (PNG) Behaviour

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:

  1. Store a mapping between SIP registrations and any push notification configuration parameters included on the REGISTER requests.
  2. 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.

6.1. Configuration

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.

6.2. UA Registration

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.

6.3. Inbound INVITE or out-of-dialog requests

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:

  1. It MUST immediately send a 100 response for the request.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

6.4. Prompting UA registration

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.

7. Grammar

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

8. Security Considerations

Security of messages sent through the PNS is subject to the implementation of the PNS and is therefore beyond the scope of this document.

9. IANA Considerations

This specification defines new SIP Contact header parameters that extend those defined in [RFC3968]

9.1. pn-svc

Header Field: Contact

Parameter Name: pn-svc

Predefined Values: No

9.2. pn-app-id

Header Field: Contact

Parameter Name: pn-app-id

Predefined Values: No

9.3. pn-token

Header Field: Contact

Parameter Name: pn-token

Predefined Values: No

10. Normative References

[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.

Author's Address

Michael Arnold Metaswitch Networks EMail: Michael.Arnold@metaswitch.com