draft-ietf-sipcore-sip-push-06.txt   draft-ietf-sipcore-sip-push-07.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: August 18, 2018 Metaswitch Networks Expires: August 20, 2018 Metaswitch Networks
February 14, 2018 February 16, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-06 draft-ietf-sipcore-sip-push-07
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 awake suspended Session Initiation Protocol (SIP) User Agents used to awake suspended Session Initiation Protocol (SIP) User Agents
(UAs), for the UA to be able to receive and send SIP requests. The (UAs), for the UA to be able to receive and send SIP requests. The
document defines new SIP URI parameters and new feature-capability document defines new SIP URI parameters and new feature-capability
indicators that can be used in SIP messages to indicate support of indicators that can be used in SIP messages to indicate support of
the mechanism defined in this document, to exchange PNS information the mechanism defined in this document, to exchange PNS information
between the SIP User Agent (UA) and the SIP entity that will request between the SIP User Agent (UA) and the SIP entity that will request
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 18, 2018. This Internet-Draft will expire on August 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 16 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 7 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 8
5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 7 5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 8
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 7 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 8
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 8 5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 9
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 9 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 10
6. Network Address Translator (NAT) Considerations . . . . . . . 10 6. Network Address Translator (NAT) Considerations . . . . . . . 11
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. 555 (Push Notification Service Not Supported) Response 7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 11 7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 12
7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 11 7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 12
7.4. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11 7.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 13
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 12 7.5. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 13
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 14
9. pn-provider, pn-param and pn-prid URI Parameters for Apple 9. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 12 Push Notification service . . . . . . . . . . . . . . . . . . 14
10. pn-provider, pn-param and pn-prid URI Parameters for Google 10. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 13 Firebase Cloud Messaging (FCM) push notification service . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 14 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 14 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 16
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 14 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 16
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 15 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 16
12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 15 12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 16
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 15 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 17
12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 15 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 17
12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 16 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 17
12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 16 12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
In order to save resources (e.g., battery life) some devices In order to save resources (e.g., battery life) some devices
(especially mobile devices) and operating systems will suspend (especially mobile devices) and operating systems will suspend
applications when not used. In some cases, internal timers cannot be applications when not used. In some cases, internal timers cannot be
used to awake such applications, nor will incoming network traffic used to awake such applications, nor will incoming network traffic
awake the application. Instead, the only way to awake the awake the application. Instead, the only way to awake the
application is by using a Push Notification Service (PNS). Typically application is by using a Push Notification Service (PNS). Typically
each operating system uses a dedicated PNS. For example, Apple iOS each operating system uses a dedicated PNS. For example, Apple iOS
skipping to change at page 6, line 48 skipping to change at page 6, line 51
are Network Address Translators (NATs) between the UA and the proxy, are Network Address Translators (NATs) between the UA and the proxy,
the REGISTER request will create NAT bindings that will allow the REGISTER request will create NAT bindings that will allow
incoming SIP requests to reach the UA. Once the UA has received a incoming SIP requests to reach the UA. Once the UA has received a
2xx response to the REGISTER request, the UA might receive a SIP 2xx response to the REGISTER request, the UA might receive a SIP
request for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP request for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP
request (e.g., a SIP MESSAGE), if such SIP request triggered the push request (e.g., a SIP MESSAGE), if such SIP request triggered the push
notification request. Note that, depending on which transport notification request. Note that, depending on which transport
protocol is used, the SIP request might reach the UA before the protocol is used, the SIP request might reach the UA before the
REGISTER response. REGISTER response.
If the UA is able to generate re-registration REGISTER requests
without recieving push notifications (e.g., using a timer), the UA
MUST insert a 'sip.pnsreg' media feature tag [RFC3840] in the Contact
header field of each REGISTER request. Then, if the response to the
REGISTER request contains a 'sip.pnsreg' feature-capability indicator
with an indicator value, the UA MUST send REGISTER requests prior to
the registration expires. The indicator value indicates a minimum
time (given in seconds), prior to the registration expires when the
UA MUST send the REGISTER request. If the REGISTER response does not
contain a a 'sip.pnsreg' feature-capability indicator, the UA only
sends REGISTER requests when it receives a push notification.
Note that even if the UA is able to send re-registration REGISTER
requests without receiving push notifications, the UA MUST still send
a REGISTER request whenever it receives a push notification,
according to the procedures in this section.
NOTE: As described above, in some cases the UA might be able to use a
non-push mechanism (e.g., a timer) to awake and send re-registration
REGISTER requests. This allows the UA to e.g., use timers for
sending REGISTER requests, but to be suspended (in order to save
battery resources etc) between sending the REGISTER requests and use
push notification to awaken the UA to process incoming calls.
As long as the UA wants to receive push notifications (requested by As long as the UA wants to receive push notifications (requested by
the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
(if required for the specific PNS provider) SIP URI parameter in each (if required for the specific PNS provider) SIP URI parameter in each
re-registration REGISTER request. Note that, in some cases, the PNS re-registration REGISTER request. Note that, in some cases, the PNS
might update the PRID value, in which case the UA will include the might update the PRID value, in which case the UA will include the
new value in the pn-prid SIP URI parameter in the re-registration new value in the pn-prid SIP URI parameter in the re-registration
REGISTER request. REGISTER request.
If the UA no longer wants to receive push notifications (requested by If the UA no longer wants to receive push notifications (requested by
the proxy), the UA MUST send a re-registration REGISTER request the proxy), the UA MUST send a re-registration REGISTER request
skipping to change at page 8, line 8 skipping to change at page 8, line 34
retrieve the information from the registrar using some other retrieve the information from the registrar using some other
mechanism. Such mechanisms are outside the scope of this document. mechanism. Such mechanisms are outside the scope of this document.
When the proxy receives an indication that the UA needs to send a re- When the proxy receives an indication that the UA needs to send a re-
registration REGISTER request, the proxy requests a push notification registration REGISTER request, the proxy requests a push notification
towards the UA. towards the UA.
Note that the push notification needs to be requested early enough, Note that the push notification needs to be requested early enough,
in order for the associated re-registration REGISTER request to reach in order for the associated re-registration REGISTER request to reach
the SIP registrar before the registration expires. It is RECOMMENDED the SIP registrar before the registration expires. It is RECOMMENDED
that the proxy requests the push notification at least 10 seconds that the proxy requests the push notification at least 120 seconds
before the registration expires. before the registration expires.
If the UA has indicated, using the 'sip.pnsreg' media feature tag,
that it is able to sending re-registration REGISTER requests without
receiving push notifications, if the proxy does not receive a
REGISTER request prior to 120 seconds before the registration
expires, the proxy SHOULD request a push notification towards the UA,
to trigger the UA to send a REGISTER request.
NOTE: In some cases the UA might be able to use a non-push mechanism NOTE: In some cases the UA might be able to use a non-push mechanism
(e.g., a timer) to awake and send re-registration REGISTER requests. (e.g., a timer) to awake and send re-registration REGISTER requests.
Such REGISTER request will update the registration expiration timer, Such REGISTER request will update the registration expiration timer,
and the proxy does not need to request a push notification towards and the proxy does not need to request a push notification towards
the UA in order to awake the UA. The proxy will still request a push the UA in order to awake the UA. The proxy will still request a push
notification towards the UA when the proxy receives a SIP request notification towards the UA when the proxy receives a SIP request
addressed towards the UA (Section 5.3.2). This allows the UA to addressed towards the UA (Section 5.3.2). This allows the UA to
e.g., use timers for sending re-registration REGISTER requests, but e.g., use timers for sending re-registration REGISTER requests, but
to be suspended (in order to save battery resources etc) between to be suspended (in order to save battery resources etc) between
sending the REGISTER requests and use push notification to awaken the sending the REGISTER requests and use push notification to awaken the
UA to process incoming calls. UA to process incoming calls.
5.3. SIP Request 5.3. SIP Request
5.3.1. REGISTER Request 5.3.1. REGISTER Request
The procedures in this section apply when the SIP proxy receives a The procedures in this section apply when the SIP proxy receives a
SIP REGISTER request that contains a pn-provider SIP URI parameter SIP REGISTER request (initial REGISTER request for a registration, or
identifying a PNS. a re-registration REGISTER request) that contains a pn-provider SIP
URI parameter identifying a PNS. If the proxy receives a REGISTER
request that does not contain a pn-provider SIP URI parameter, or
that removes the registration, the proxy MUST NOT request push
notifications towards the UA associated with the REGISTER request, or
perform any other procedures in this section.
When the proxy receives a REGISTER request, if the REGISTER request When the proxy receives a REGISTER request, if the REGISTER request
contains a Feature-Caps header field with a 'sip.pns' feature- contains a Feature-Caps header field with a 'sip.pns' feature-
capability indicator, it indicates that an upstream proxy supports, capability indicator, it indicates that an upstream proxy supports,
and will request, push notifications towards the UA. The proxy MUST and will request, push notifications towards the UA. The proxy MUST
skip the rest of the procedures in this section, and process the skip the rest of the procedures in this section, and process the
REGISTER request using normal SIP procedures. REGISTER request using normal SIP procedures.
Otherwise, if the pn-provider SIP URI parameter identifies a PNS that Otherwise, if the pn-provider SIP URI parameter identifies a PNS that
the proxy does not support, or if the REGISTER request does not the proxy does not support, or if the REGISTER request does not
skipping to change at page 9, line 17 skipping to change at page 10, line 8
If the proxy inserted a Feature-Caps header field with a 'sip.pns' If the proxy inserted a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the REGISTER request (see above), feature-capability indicator in the REGISTER request (see above),
when the proxy receives (or, in case the proxy is the SIP registrar, when the proxy receives (or, in case the proxy is the SIP registrar,
creates) a 2xx response to the REGISTER request, the proxy MUST creates) a 2xx response to the REGISTER request, the proxy MUST
insert a Feature-Caps header field with a 'sip.pns' feature- insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the PNS. This will capability indicator in the response, identifying the PNS. This will
inform the UA that the proxy supports, and will request, push inform the UA that the proxy supports, and will request, push
notifications towards the UA. The proxy MUST only indicate support notifications towards the UA. The proxy MUST only indicate support
of the same PNS that was identified in the pn-provider SIP URI of the same PNS that was identified in the pn-provider SIP URI
parameter in the REGISTER request. In addition, if the proxy parameter in the REGISTER request.
supports, and will use, the VAPID mechanism, the proxy MUST insert a
Feature-Caps header field with a 'sip.vapid' feature-capability In addition, if the proxy supports, and will use, the VAPID
indicator in the response. The header field parameter contains the mechanism, the proxy MUST insert a Feature-Caps header field with a
public key identifying the proxy [RFC8292]. 'sip.vapid' feature-capability indicator in the response. The header
field parameter contains the public key identifying the proxy
[RFC8292].
In addition, if the proxy received a 'sip.pnsreg' media feature tag
in the REGISTER request, the proxy SHOULD include a 'sip.pnsreg'
feature-capability indicator with an indicator value bigger than 120
in the response, unless the proxy always want to request push
notifications to trigger the UA to send a REGISTER request.
5.3.2. Initial Request for Dialog or Stand-Alone Request 5.3.2. Initial Request for Dialog or Stand-Alone Request
The procedures in this section apply when the SIP proxy has indicated The procedures in this section apply when the SIP proxy has indicated
that it supports, and will request, push notifications towards the that it supports, and will request, push notifications towards the
SIP UA. SIP UA.
When the proxy receives (or, in case the proxy is the registrar, When the proxy receives (or, in case the proxy is the registrar,
creates) a SIP request for a new dialog (e.g., a SIP INVITE request) creates) a SIP request for a new dialog (e.g., a SIP INVITE request)
or a stand-alone SIP request (e.g., a SIP MESSAGE request) addressed or a stand-alone SIP request (e.g., a SIP MESSAGE request) addressed
skipping to change at page 9, line 46 skipping to change at page 10, line 45
parameter and the PNS identified by the pn-provider SIP URI parameter and the PNS identified by the pn-provider SIP URI
parameter. parameter.
The push notification will trigger the UA to send a re-registration The push notification will trigger the UA to send a re-registration
REGISTER request. The proxy will process the REGISTER request and REGISTER request. The proxy will process the REGISTER request and
the associated response as described in Section 5.3.1. In case of a the associated response as described in Section 5.3.1. In case of a
2xx response to the REGISTER request, once the proxy has forwarded 2xx response to the REGISTER request, once the proxy has forwarded
the REGISTER response towards the UA, if the contact in the REGISTER the REGISTER response towards the UA, if the contact in the REGISTER
response matches the Request-URI of the SIP request to be forwarded, response matches the Request-URI of the SIP request to be forwarded,
the proxy can also forward the SIP request towards the UA, using the proxy can also forward the SIP request towards the UA, using
normal SIP procedures. If the contact and Request-URI do not match, normal SIP procedures. If the contact of the most recent REGISTER
the proxy MUST reject the SIP request with a 404 (Not Found) 2xx response and Request-URI do not match, the proxy MUST reject the
response. SIP request with a 404 (Not Found) response.
NOTE: If the proxy is not the registrar, it needs to store (or be
able to retrieve) the contact of the most recent REGISTER 2xx
response, to be able to compare it with the Request-URI of the
request to be forwarded towards the UA.
In case of non-2xx response to the REGISTER request, the proxy MUST In case of non-2xx response to the REGISTER request, the proxy MUST
reject the SIP request with a 404 (Not Found) response. reject the SIP request with a 404 (Not Found) response.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST reject the SIP request documentation for details), the proxy MUST reject the SIP request
with a 555 (Push Notification Service Not Supported) response. with a 555 (Push Notification Service Not Supported) response.
NOTE: As described above, the reason the proxy needs to wait for the NOTE: As described above, the reason the proxy needs to wait for the
REGISTER response before forwarding the SIP request is to make sure REGISTER response before forwarding the SIP request is to make sure
skipping to change at page 10, line 35 skipping to change at page 11, line 40
of this document. of this document.
6. Network Address Translator (NAT) Considerations 6. Network Address Translator (NAT) Considerations
Whenever the SIP UA receives a push notification, if the UA is Whenever the SIP UA receives a push notification, if the UA is
located behind a Network Address Translator (NAT), the UA might need located behind a Network Address Translator (NAT), the UA might need
to take actions in order to establish a binding in the NAT, in order to take actions in order to establish a binding in the NAT, in order
for an incoming SIP request to reach the UA. By sending the re- for an incoming SIP request to reach the UA. By sending the re-
registration SIP REQUEST the UA will establish such a NAT binding. registration SIP REQUEST the UA will establish such a NAT binding.
If the UA and the SIP proxy are operating in an environment where one
or more NATs might be located between the UA and the proxy, when the
proxy receives a REGISTER request from the UA it can store the IP
address and port information from where it received the request.
Then, when the proxy forwards a SIP request towards the UA, it uses
that IP address and port, instead of the IP address and port
associated with the Request-URI of the request. If the REGISTER
request created one or more NAT bindings, this will ensure that the
SIP request reaches the UA.
7. Grammar 7. Grammar
7.1. 555 (Push Notification Service Not Supported) Response Code 7.1. 555 (Push Notification Service Not Supported) Response Code
The 555 response code is added to the "Server-Error" Status-Code The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server did not support the push notification indicate that the server did not support the push notification
service identified in a 'pn-provider' SIP URI parameter, or that the service identified in a 'pn-provider' SIP URI parameter, or that the
server failed to request a push notification from the push server failed to request a push notification from the push
notification service. notification service.
skipping to change at page 11, line 39 skipping to change at page 13, line 10
requesting push notifications towards the SIP UA associated with the requesting push notifications towards the SIP UA associated with the
SIP registration. The indicator value contains a public key SIP registration. The indicator value contains a public key
identifying the entity, that can be used by a SIP UA to restrict identifying the entity, that can be used by a SIP UA to restrict
subscriptions to that entity. subscriptions to that entity.
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
vapid = tag-value vapid = tag-value
; tag-value as defined in RFC 3840 ; tag-value as defined in RFC 3840
7.4. SIP URI Parameters 7.4. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator is used in a 2xx response
to a SIP REGISTER request to indicate that the entity associated with
the indicator expects to receive re-registration REGISTER requests
before the registration expires. The indicator value indicates the
minimum value (given in seconds) before the registration expireation
when the entity expects to receive the REGISTER request.
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT
7.5. SIP URI Parameters
The section defines new SIP URI parameters, by extending the grammar The section defines new SIP URI parameters, by extending the grammar
for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows:
uri-parameter =/ pn-provider / pn-param / pn-prid uri-parameter =/ pn-provider / pn-param / pn-prid
pn-provider = "pn-provider" EQUAL pvalue pn-provider = "pn-provider" EQUAL pvalue
pn-param = "pn-param" EQUAL pvalue pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue pn-prid = "pn-prid" EQUAL pvalue
; pvalue as defined in RFC 3261 ; pvalue as defined in RFC 3261
skipping to change at page 16, line 24 skipping to change at page 18, line 17
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when included in a
Feature-Caps header field of a REGISTER response, indicates that Feature-Caps header field of a REGISTER response, indicates that
the server supports the Voluntary Application Server the server supports the Voluntary Application Server
Identification (VAPID) mechanism, defined in RFC 8292. The value Identification (VAPID) mechanism, defined in RFC 8292. The value
is a public key of the server. is a public key of the server.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
12.4. PNS Sub-registry Establishment 12.3.3. sip.pnsreg
This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters.
Name: sip.pnsreg
Description: This feature-capability indicator, when included in a
Feature-Caps header field of a SIP REGISTER response, indicates
that the server supports the case where the client will send a
re-registration REGISTER request, without the use of a push
notification, before the registration expires. The indicator
value indicates the minimum time before the registration expires
that the server expects the client to send the REGISTER requests.
Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org)
12.4. SIP Media Feature Tag
12.4.1. sip.pnsreg
This section defines a new media feature tag that extends the "SIP
Media Feature Tag Registration Tree" sub-registry [RFC3840] under the
Media Feature Tag registry: https://www.iana.org/assignments/media-
feature-tags/media-feature-tags.xhtml.
Media feature tag name: sip.pnsreg
Summary of the media feature indicated by this feature tag: This
media feature tag, when included in a Contact header field of
a REGISTER request, indicates that the client is able to send
re-registration REGISTER requests without being awaken by a push
notification.
Values appropriate for use with this feature tag: none
Related standards or documents: [RFCXXXX]
Security considerations: This media feature tag does not introduce
new security considerations, as it simply indicates support for
a basic SIP feature. If an attacker manages to remove the media
feature tag, push notifications towards the client will be
requested.
Contact: IESG (iesg@ietf.org)
12.5. PNS Sub-registry Establishment
This section creates a new sub-registry, "PNS", under the sip- This section creates a new sub-registry, "PNS", under the sip-
parameters registry: http://www.iana.org/assignments/sip-parameters. parameters registry: http://www.iana.org/assignments/sip-parameters.
The purpose of the sub-registry is to register SIP URI pn-provider The purpose of the sub-registry is to register SIP URI pn-provider
values. values.
When a SIP URI pn-provider value is registered in the sub-registry, When a SIP URI pn-provider value is registered in the sub-registry,
it needs to meet the "Expert Review" policies defined in [RFC8126]. it needs to meet the "Expert Review" policies defined in [RFC8126].
skipping to change at page 17, line 34 skipping to change at page 20, line 34
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, <https://www.rfc-
editor.org/info/rfc3840>.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority [RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter (IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)", Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004,
<https://www.rfc-editor.org/info/rfc3969>. <https://www.rfc-editor.org/info/rfc3969>.
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
Indicate Support of Features and Capabilities in the Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809, Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012, <https://www.rfc- DOI 10.17487/RFC6809, November 2012, <https://www.rfc-
 End of changes. 17 change blocks. 
48 lines changed or deleted 179 lines changed or added

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