Push Notifications in the Session Initiation Protocol (SIP)
draft-ivanov-sipcore-pnsip-00

Abstract

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 http://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 September 1, 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 (http://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. Introduction
• 2. Conventions and Terminology
• 2.1. Definitions
• 3. Overview
• 4. Client Behavior
• 5. IANA Considerations
• 5.1. URI parameters registry
• 5.2. "pn-uri" parameter
• 5.3. "pn-type" parameter
• 5.4. "pn-methods" parameter
• 6. Example
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

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

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

        

            
REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@192.0.2.4;
  pn-type=acme;pn-methods="INVITE";
  pn-uri="https://pn.acme.example.com/ZTY4ZDJlMzODE1NmUgKi0K">
Expires: 7200
Content-Length: 0