Internet DRAFT - draft-ivanov-sipcore-pnsip
draft-ivanov-sipcore-pnsip
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)
draft-ivanov-sipcore-pnsip-01
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 October 9, 2016.
Ivanov Expires October 9, 2016 [Page 1]
Internet-Draft SIP Push Notifications April 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
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5.1. URI parameters registry . . . . . . . . . . . . . . . . . 4
5.2. "pn-uri" parameter . . . . . . . . . . . . . . . . . . . 4
5.3. "pn-type" parameter . . . . . . . . . . . . . . . . . . . 4
5.4. "pn-methods" parameter . . . . . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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.
Ivanov Expires October 9, 2016 [Page 2]
Internet-Draft SIP Push Notifications April 2016
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.
Ivanov Expires October 9, 2016 [Page 3]
Internet-Draft SIP Push Notifications April 2016
5. IANA Considerations
5.1. URI parameters registry
This specification defines new SIP URI parameters that extend the
registry created by [RFC3969]:
+---------------+-----------------+---------------------------------+
| Parameter | Predefined | Reference |
| Name | Values | |
+---------------+-----------------+---------------------------------+
| pn-uri | No | [draft-ivanov-sipcore-pnsip-00] |
| pn-type | No | [draft-ivanov-sipcore-pnsip-00] |
| pn-methods | Yes | [draft-ivanov-sipcore-pnsip-00] |
+---------------+-----------------+---------------------------------+
Table 1
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.
Ivanov Expires October 9, 2016 [Page 4]
Internet-Draft SIP Push Notifications April 2016
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
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@alicemobile.example.com;
pn-type=acme;pn-methods="INVITE";
pn-uri="https://pn.acme.example.com/ZTY4ZDJlMzODE1NmUgKi0K">
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".
Ivanov Expires October 9, 2016 [Page 5]
Internet-Draft SIP Push Notifications April 2016
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,
<http://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,
<http://www.rfc-editor.org/info/rfc3261>.
[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,
<http://www.rfc-editor.org/info/rfc3969>.
7.2. Informative References
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009,
<http://www.rfc-editor.org/info/rfc5626>.
Author's Address
Viktor Ivanov
Securax
Sofia
Bulgaria
Email: viktor.ivanov@securax.org
Ivanov Expires October 9, 2016 [Page 6]
