draft-ietf-sipcore-sip-push-27.txt   draft-ietf-sipcore-sip-push-28.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. Arnold Intended status: Standards Track M. Arnold
Expires: September 5, 2019 Metaswitch Networks Expires: September 11, 2019 Metaswitch Networks
March 4, 2019 March 10, 2019
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-27 draft-ietf-sipcore-sip-push-28
Abstract Abstract
This document describes how a Push Notification Service (PNS) can be This document describes how a Push Notification Service (PNS) can be
used to wake a suspended Session Initiation Protocol (SIP) User Agent used to wake a suspended Session Initiation Protocol (SIP) User Agent
(UA) with push notifications, and also describes how the UA can send (UA) with push notifications, and also describes how the UA can send
binding-refresh REGISTER requests and receive incoming SIP requests binding-refresh REGISTER requests and receive incoming SIP requests
in an environment in which the UA may be suspended. The document in an environment in which the UA may be suspended. The document
defines new SIP URI parameters to exchange PNS information between defines new SIP URI parameters to exchange PNS information between
the UA and the SIP entity that will then request that push the UA and the SIP entity that will then request that push
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2019. This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 16 5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 16
5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16 5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16
5.6.2. Initial Request for Dialog or Stand-Alone Request . . 19 5.6.2. Initial Request for Dialog or Stand-Alone Request . . 19
6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 21 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 21
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 23 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 23 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 23
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 24 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 24
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 24 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 24
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 24 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 24
6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 25 6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 25
7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 26 7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 25
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. 555 (Push Notification Service Not Supported) Response 8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 26 8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 26
8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 27 8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 27
8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 27 8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 27
8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 28 8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 28
8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 28 8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 28
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 28 8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 28
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 29 9. PNS Registration Requirements . . . . . . . . . . . . . . . . 29
skipping to change at page 3, line 24 skipping to change at page 3, line 24
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 32 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 32
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33
14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33 14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 33 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 33
14.2.1. 555 (Push Notification Service Not Supported) . . . 33 14.2.1. 555 (Push Notification Service Not Supported) . . . 33
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 33 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 33
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 33 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 33
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 34 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 34
14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35 14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 36 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 35
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36
14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 36 14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 36
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . 37 16.1. Normative References . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . 39 16.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
skipping to change at page 12, line 37 skipping to change at page 12, line 37
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
To: Alice <sip:alice@example.com>;tag=123987 To: Alice <sip:alice@example.com>;tag=123987
From: Alice <sip:alice@example.com>;tag=456248 From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09 Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com; Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme; pn-provider=acme;
pn-param=acme-param; pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>; pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg +sip.pnsreg
Feature-Caps: *;+sip.pns="acme",*;+sip.pnsreg="121" Feature-Caps: *;+sip.pns="acme";+sip.pnsreg="121"
Expires: 7200 Expires: 7200
Content-Length: 0 Content-Length: 0
Figure 3: SIP REGISTER When Using Non-Push Mechanism Example Figure 3: SIP REGISTER When Using Non-Push Mechanism Example
4.1.5. Query Network PNS Capabilities 4.1.5. Query Network PNS Capabilities
This section describes how a SIP UA can query the types of PNSs This section describes how a SIP UA can query the types of PNSs
supported by a SIP network, and PNS-related capabilities (e.g., supported by a SIP network, and PNS-related capabilities (e.g.,
support of the VAPID mechanism). When a UA performs a query, it does support of the VAPID mechanism). When a UA performs a query, it does
skipping to change at page 13, line 30 skipping to change at page 13, line 30
If the UA receives a 2xx response to the REGISTER request, the If the UA receives a 2xx response to the REGISTER request, the
response will contain one or more Feature-Caps header fields with a response will contain one or more Feature-Caps header fields with a
'sip.pns' feature-capability indicator, indicating the types of PNSs 'sip.pns' feature-capability indicator, indicating the types of PNSs
supported by the SIP network. If the UA inserted a pn-provider SIP supported by the SIP network. If the UA inserted a pn-provider SIP
URI parameter value in the REGISTER request, the response will only URI parameter value in the REGISTER request, the response will only
indicate whether the SIP network supports the type of PNS supported indicate whether the SIP network supports the type of PNS supported
by the UA. by the UA.
If the UA receives a 555 (Push Notification Service Not Supported) If the UA receives a 555 (Push Notification Service Not Supported)
response to the REGISTER request, the response will contain one or response to the REGISTER request, and if the UA inserted a pn-
more Feature-Caps header fields with a 'sip.pns' feature-capability provider SIP URI parameter in the REGISTER request, the response
indicator, indicating the types of PNSs supported by the SIP network. indicates that the network does not support the type of PNS that the
UA indicated support of. If the UA did not insert a pn-provider
parameter in the REGISTER request, the response indicates that the
network does not support any type of PNS, while still supporting the
555 (Push Notification Service Not Supported) response.
NOTE: It is optional for a UA to perform a query before it requests NOTE: It is optional for a UA to perform a query before it requests
push notifications from the SIP network. push notifications from the SIP network.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. PNS Provider 5.1. PNS Provider
The type of PNS is identified by the pn-provider SIP URI parameter. The type of PNS is identified by the pn-provider SIP URI parameter.
In some cases there might only be one PNS provider for a given type In some cases there might only be one PNS provider for a given type
skipping to change at page 17, line 6 skipping to change at page 17, line 11
section. If the proxy knows (by means of local configuration) section. If the proxy knows (by means of local configuration)
that no other proxies between itself and the registrar support the that no other proxies between itself and the registrar support the
type of PNS supported by the UA, the proxy MAY send a SIP 555 type of PNS supported by the UA, the proxy MAY send a SIP 555
(Push Notification Service Not Supported) response instead of (Push Notification Service Not Supported) response instead of
forwarding the request. forwarding the request.
o If the proxy supports the type of PNS supported by the UA, but o If the proxy supports the type of PNS supported by the UA, but
considers the requested binding expiration interval [RFC3261] to considers the requested binding expiration interval [RFC3261] to
be too short (see below), the proxy MUST either send a 423 be too short (see below), the proxy MUST either send a 423
(Interval Too Brief) response to the REGISTER request or forward (Interval Too Brief) response to the REGISTER request or forward
the request towards the registrar and skip the rest of the the request towards the registrar and skip the rest of the
procedures in this section. If the proxy sends a 423 (Interval procedures in this section.
Too Brief) response, the proxy SHOULD insert one or more Feature-
Caps header fields with a 'sip.pns' feature-capability indicator
in the response, indicating each type of PNS that the proxy
supports.
o If the proxy supports the type of PNS supported by the UA, the o If the proxy supports the type of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the the REGISTER request before it forwards the request towards the
registrar. This will inform proxies between the proxy and the registrar. This will inform proxies between the proxy and the
registrar that the proxy supports the type of PNS supported by the registrar that the proxy supports the type of PNS supported by the
UA, and that the proxy will request that push notifications are UA, and that the proxy will request that push notifications are
sent to the UA. sent to the UA.
A binding expiration interval MUST be considered too short if the A binding expiration interval MUST be considered too short if the
binding would expire before the proxy can request that a push binding would expire before the proxy can request that a push
notification be sent to the UA to trigger the UA to send a binding- notification be sent to the UA to trigger the UA to send a binding-
refresh REGISTER request. The proxy MAY consider the interval too refresh REGISTER request. The proxy MAY consider the interval too
short based on its own policy so as to reduce load on the system. short based on its own policy so as to reduce load on the system.
If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD indicate each type of PNS that
the proxy supports in the response.
When a proxy receives a 2xx response to the REGISTER request, if the When a proxy receives a 2xx response to the REGISTER request, if the
proxy indicated support of a type of PNS in the REGISTER request (see proxy indicated support of a type of PNS in the REGISTER request (see
above), the proxy performs the following actions: above), the proxy performs the following actions:
o If the proxy considers the binding expiration interval indicated o If the proxy considers the binding expiration interval indicated
by the registrar too short (see above), the proxy forwards the by the registrar too short (see above), the proxy forwards the
response towards the UA and MUST skip the rest of the procedures response towards the UA and MUST skip the rest of the procedures
in this section. in this section.
o The proxy MUST indicate support of the same type of PNS in the o The proxy MUST indicate support of the same type of PNS in the
REGISTER response. In addition: REGISTER response. In addition:
skipping to change at page 18, line 40 skipping to change at page 18, line 40
o If the proxy does not support the type of PNS supported by the UA, o If the proxy does not support the type of PNS supported by the UA,
and if the REGISTER request does not contain Feature-Caps header and if the REGISTER request does not contain Feature-Caps header
fields indicating support of one or more types of PNSs, the proxy fields indicating support of one or more types of PNSs, the proxy
MUST either forward the request towards the registrar, or send a MUST either forward the request towards the registrar, or send a
SIP 555 (Push Notification Service Not Supported) response towards SIP 555 (Push Notification Service Not Supported) response towards
the UA. The proxy MUST NOT send a SIP 555 (Push Notification the UA. The proxy MUST NOT send a SIP 555 (Push Notification
Service Not Supported) response unless it knows (by means of local Service Not Supported) response unless it knows (by means of local
configuration) that no other proxy supports any of the types of configuration) that no other proxy supports any of the types of
PNSs supported by the UA. PNSs supported by the UA.
If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD indicate each type of PNS that
the proxy supports in the response.
When a proxy receives a REGISTER request, and the pn-provider SIP URI When a proxy receives a REGISTER request, and the pn-provider SIP URI
parameter does not contain a parameter value, the proxy MUST indicate parameter does not contain a parameter value, the proxy MUST indicate
support of each type of PNS supported by the proxy before it forwards support of each type of PNS supported by the proxy before it forwards
the request towards the registrar. the request towards the registrar.
When a proxy receives a 2xx response to the REGISTER request, if the When a proxy receives a 2xx response to the REGISTER request, if the
proxy had indicated support of one or more types of PNSs in the proxy had indicated support of one or more types of PNSs in the
REGISTER request (see above), the proxy MUST indicate support of the REGISTER request (see above), the proxy MUST indicate support of the
same set of types of PNSs in the response. In addition, if the proxy same set of types of PNSs in the response. In addition, if the proxy
supports the VAPID mechanism for one or more types of PNSs, the proxy supports the VAPID mechanism for one or more types of PNSs, the proxy
skipping to change at page 26, line 52 skipping to change at page 26, line 46
The use of the SIP 555 response code is only defined for SIP REGISTER The use of the SIP 555 response code is only defined for SIP REGISTER
responses. responses.
8.2. sip.pns Feature-Capability Indicator 8.2. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator, when inserted in a Feature- The sip.pns feature-capability indicator, when inserted in a Feature-
Caps header field of a SIP REGISTER request or a SIP 2xx response to Caps header field of a SIP REGISTER request or a SIP 2xx response to
a REGISTER request, indicates that the entity associated with the a REGISTER request, indicates that the entity associated with the
indicator supports the SIP push mechanism and the type of push indicator supports the SIP push mechanism and the type of push
notification service indicated by the indicator value. When inserted notification service indicated by the indicator value. The values
in a 555 (Push Notification Service Not Supported) response to a defined for the pn-provider SIP URI parameter are used as indicator
REGISTER request, the indicator indicates that the entity associated values.
with the indicator supports the SIP push mechanism, and the type of
push notification service identified by the indicator value. The
values defined for the pn-provider SIP URI parameter are used as
indicator values.
pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT
pns = tag-value pns = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.3. sip.vapid Feature-Capability Indicator 8.3. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator, when inserted in a SIP The sip.vapid feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, denotes that the entity 2xx response to a SIP REGISTER request, denotes that the entity
skipping to change at page 34, line 12 skipping to change at page 34, line 12
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pns Name: sip.pns
Description: This feature-capability indicator, when inserted in a Description: This feature-capability indicator, when inserted in a
Feature-Caps header field of a SIP REGISTER request or a SIP 2xx Feature-Caps header field of a SIP REGISTER request or a SIP 2xx
response to a REGISTER request, denotes that the entity response to a REGISTER request, denotes that the entity
associated with the indicator supports the SIP push mechanism associated with the indicator supports the SIP push mechanism
and the type of push notification service conveyed by the and the type of push notification service conveyed by the
indicator value. When inserted in a 555 (Push Notification indicator value.
Service Not Supported) response to a REGISTER request, the
indicator denotes that the entity associated with the
indicator supports the SIP push mechanism, and the type of push
notification service conveyed by the indicator value.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
14.3.2. sip.vapid 14.3.2. sip.vapid
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
 End of changes. 12 change blocks. 
35 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/