Internet Engineering Task Force V. Ivanov
Internet-Draft Securax
Intended status: Informational April 7, 2016
Expires: October 9, 2016

Push Notifications in the Session Initiation Protocol (SIP)


The Session Initiation Protocol (SIP) allows User Agents to register for inbound requests. However, the existence of firewalls and Network Address Translators (NATs) prevent servers from reaching the User Agents unless the User Agents keep connections to the server alive.

To keep such connections alive User Agents employ various methods, most of which require constant uptime resulting in high energy cost. This is especially a problem on mobile platforms that operate entirely on battery power. To resolve these issues many mobile manufacturers have provided a cost effective way of pushing messages to their devices.

This specification defines behaviors for User Agents, registrars and proxy servers that allow a User Agent to provide a Push Notification Configuration to its Registrar.

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

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 October 9, 2016.

Copyright Notice

Copyright (c) 2016 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 ( 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. Introduction

As outlined in [RFC5626], there are many environments for SIP [RFC3261] deployments in which the User Agent (UA) can form a connection to a registrar or proxy but in which connections in the reverse direction to the UA are not possible. There are several ways to negotiate an outbound-only (from the point of view of the UA) communication with the server. All of them require the UA to keep a connection alive in some way which, for mobile platforms especially, is a huge energy drain.

Mobile platform OEMs have devised many ways to keep the battery drain to a minimum for such communications. One common solution is to provide OEM assisted service that can push notifications to a device in a suspended state.

This specification outlines the extensions to SIP that allow a User Agent to send Push Notification Configuration to its Register.

2. Conventions and Terminology

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

2.1. Definitions

User Agent
As defined by SIP [RFC3261].
Push Notification
High priority message that can be received by a suspended User Agent.
Push Notification Configuration
A set of parameters that allow a third party to send a Push Notification to a User Agent.
Push Notification Provider
A service maintained by a mobile device OEM that is able to produce Push Notification Configurations and handle Push Notification requests from third parties.

3. Overview

The purpose of this specification is to provide an easy to implement method of sending the Push Notification Configuration to a SIP server via URI parameters in the Contact header field of the REGISTER request.

4. Client Behavior

The client behavior affects the way User Agents maintain their bindings at SIP Registrars. This specification is intended to be fully backward compatible with SIP [RFC3261].

When a client wishes to send its Push Notification Configuration it SHOULD do so by updating its bindings. This is seen by the server as a regular binding refresh. Due to ambiguity in the way binding refresh is done in the presence of additional URI parameters, the User Agent MAY instead completely remove its old binding and register a new binding containing the Push Notification Configuration.

A User Agent MAY use Keep Alive techniques specified by [RFC5626] or other related documents.

5. IANA Considerations

5.1. URI parameters registry

This specification defines new SIP URI parameters that extend the registry created by [RFC3969]:

Parameter Name Predefined Values Reference
pn-uri No [draft-ivanov-sipcore-pnsip-00]
pn-type No [draft-ivanov-sipcore-pnsip-00]
pn-methods Yes [draft-ivanov-sipcore-pnsip-00]

5.2. "pn-uri" parameter

The "pn-uri" parameter contains a OEM-specific Push Notification Configuration URI given by the Push Notification Provider to the User Agent. This URI uniquely identifies the User Agent instance.

This is a required parameter.

5.3. "pn-type" parameter

The "pn-type" parameter identifies the OEM and can be used in combination with "pn-uri". It is up to the specific OEM Push Notification Configuration to make use of this parameter.

5.4. "pn-methods" parameter

The "pn-methods" parameter defines the User Agent preference for SIP Methods that will result in a Push Notification. It has the same syntax as the [RFC3261] "Allow" header field.

The default value for "pn-methods", when omitted is "INVITE,MESSAGE".

6. Example

In the example in Figure 1 the first User Agent (UA1) obtains a Push Notification Configuration from a Push Notification Provider server. Then it proceeds to register to a SIP server with the Push Notification Configuration extensions defined by this specification.

UA1            Push Srvr      SIP Srvr
| Request Push           |             |
| Configuration          |             |
|----------------------->|             |
|                        |             |
| Push Configuration     |             |
|<-----------------------|             |
|                        |             |
| F1: REGISTER w/ Push   |             |
| Configuration          |             |
|                        |   200 OK    |


An example usage of Push Notifications in SIP

Figure 1

Via: SIP/2.0/TCP;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <>
From: Alice <>;tag=456248
Call-ID: 843817637684230@998sdasdh09
Contact: <;
Expires: 7200
Content-Length: 0


Message F1 from Figure 1

Figure 2: Message F1

Note: The Contact header field in Figure 2 is all on one line and shown in multiple lines in this example only for the purpose of readability.

In the Example REGISTER message the selected SIP Methods that will result in a Push Notifications are limited to only "INVITE".

7. References

7.1. 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.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004.

7.2. Informative References

[RFC5626] Jennings, C., Mahy, R. and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009.

Author's Address

Viktor Ivanov Securax Sofia, Bulgaria EMail: