Internet DRAFT - draft-arnold-sipcore-push-notification-gateway
draft-arnold-sipcore-push-notification-gateway
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
Arnold Expires May 20, 2018 [Page 1]
Internet-Draft Push Notification Gateway November 2017
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Avoiding misrouting as a SIP User Agent traverses a network . 5
4. SIP User Agent (UA) Behaviour . . . . . . . . . . . . . . . . 5
4.1. Registering . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Receiving a Push Notification . . . . . . . . . . . . . . 6
5. Push Notification Service (PNS) Behaviour . . . . . . . . . . 6
6. Push Notification Gateway (PNG) Behaviour . . . . . . . . . . 7
6.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 7
6.2. UA Registration . . . . . . . . . . . . . . . . . . . . . 7
6.3. Inbound INVITE or out-of-dialog requests . . . . . . . . 8
6.4. Prompting UA registration . . . . . . . . . . . . . . . . 9
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9.1. pn-svc . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. pn-app-id . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3. pn-token . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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:
Arnold Expires May 20, 2018 [Page 2]
Internet-Draft Push Notification Gateway November 2017
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 |
Arnold Expires May 20, 2018 [Page 3]
Internet-Draft Push Notification Gateway November 2017
| | | <------------- |
| 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].
Arnold Expires May 20, 2018 [Page 4]
Internet-Draft Push Notification Gateway November 2017
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.
Arnold Expires May 20, 2018 [Page 5]
Internet-Draft Push Notification Gateway November 2017
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
Arnold Expires May 20, 2018 [Page 6]
Internet-Draft Push Notification Gateway November 2017
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
Arnold Expires May 20, 2018 [Page 7]
Internet-Draft Push Notification Gateway November 2017
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.
Arnold Expires May 20, 2018 [Page 8]
Internet-Draft Push Notification Gateway November 2017
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
Arnold Expires May 20, 2018 [Page 9]
Internet-Draft Push Notification Gateway November 2017
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc3261>.
[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,
<https://www.rfc-editor.org/info/rfc3968>.
Author's Address
Michael Arnold
Metaswitch Networks
Email: Michael.Arnold@metaswitch.com
Arnold Expires May 20, 2018 [Page 10]
