Internet Engineering Task Force                                V. Ivanov
Internet-Draft                                                   Securax
Intended status: Informational                         February 29, 2016
Expires: September 1, 2016


      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.







Ivanov                  Expires September 1, 2016               [Page 1]


Internet-Draft           SIP Push Notifications            February 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 September 1, 2016               [Page 2]


Internet-Draft           SIP Push Notifications            February 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 September 1, 2016               [Page 3]


Internet-Draft           SIP Push Notifications            February 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 September 1, 2016               [Page 4]


Internet-Draft           SIP Push Notifications            February 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@192.0.2.4;
     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 September 1, 2016               [Page 5]


Internet-Draft           SIP Push Notifications            February 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 September 1, 2016               [Page 6]