[要約] RFC 8599は、SIPを使用したプッシュ通知に関する仕様です。このRFCの目的は、SIPセッションの状態変化を通知するためのプッシュ通知メカニズムを提供することです。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8599 Ericsson
Category: Standards Track M. Arnold
ISSN: 2070-1721 Metaswitch Networks
May 2019
Push Notification with the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）によるプッシュ通知
Abstract
概要
This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.
このドキュメントでは、プッシュ通知サービス（PNS）を使用して、中断されたセッション開始プロトコル（SIP）ユーザーエージェント（UA）をプッシュ通知でウェイクアップする方法と、UAがバインディングリフレッシュREGISTERリクエストを送信して受信を受信する方法について説明します。 UAが一時停止される可能性のある環境でのSIP要求。このドキュメントでは、UAとSIPエンティティの間でPNS情報を交換するための新しいSIP URIパラメータを定義し、プッシュ通知のUAへの送信を要求します。また、このようなプッシュ通知要求をトリガーするパラメーターも定義します。このドキュメントでは、このメカニズムのサポートを示すために使用できる新しい機能機能インジケータも定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8599.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8599で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 8
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 9
4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Request Push Notifications . . . . . . . . . . . . . 9
4.1.2. Disable Push Notifications . . . . . . . . . . . . . 11
4.1.3. Receive Push Notifications . . . . . . . . . . . . . 11
4.1.4. Sending Binding-Refresh Requests Using Non-push
Mechanism . . . . . . . . . . . . . . . . . . . . . . 11
4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 13
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 14
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 14
5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 15
5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 15
5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 15
5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 16
5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 17
5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 17
5.6.2. Initial Request for Dialog or Standalone Request . . 20
6. Support of Long-Lived SIP Dialogs . . . . . . . . . . . . . . 23
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 25
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 25
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 25
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 26
6.2.3. Mid-dialog Request . . . . . . . . . . . . . . . . . 26
7. Support of SIP Replaces . . . . . . . . . . . . . . . . . . . 27
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. 'sip.pns' Feature-Capability Indicator . . . . . . . . . 28
8.3. 'sip.vapid' Feature-Capability Indicator . . . . . . . . 28
8.4. 'sip.pnsreg' Feature-Capability Indicator . . . . . . . . 28
8.5. 'sip.pnsreg' Media Feature Tag . . . . . . . . . . . . . 29
8.6. 'sip.pnspurr' Feature-Capability Indicator . . . . . . . 29
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 29
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 30
10. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
Apple Push Notification service . . . . . . . . . . . . . . . 30
11. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
Google Firebase Cloud Messaging (FCM) Push Notification
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
RFC 8030 (Generic Event Delivery Using HTTP Push) . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 33
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 33
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 33
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33
14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 34
14.2.1. 555 (Push Notification Service Not Supported) . . . 34
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 34
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 34
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 35
14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 36
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36
14.5. PNS Subregistry Establishment . . . . . . . . . . . . . 36
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
In order to save resources such as battery life, some devices (especially mobile devices) and operating systems will suspend an application that is not in use. A suspended application might not be able to wake itself with internal timers and might not be awakened by incoming network traffic. In such an environment, a Push Notification Service (PNS) is used to wake the application. A PNS is a service that sends messages requested by other applications to a user application in order to wake the user application. These messages are called push notifications. Push notifications might contain payload data, depending on the application. An application can request that a push notification be sent to a single user application or to multiple user applications.
バッテリー寿命などのリソースを節約するために、一部のデバイス（特にモバイルデバイス）とオペレーティングシステムは、使用されていないアプリケーションを一時停止します。一時停止されたアプリケーションは、内部タイマーではそれ自体を起動できず、着信ネットワークトラフィックによって起動されない場合があります。このような環境では、アプリケーションを起動するためにプッシュ通知サービス（PNS）が使用されます。 PNSは、ユーザーアプリケーションを起動するために、他のアプリケーションから要求されたメッセージをユーザーアプリケーションに送信するサービスです。これらのメッセージはプッシュ通知と呼ばれます。アプリケーションによっては、プッシュ通知にペイロードデータが含まれる場合があります。アプリケーションは、プッシュ通知を単一のユーザーアプリケーションまたは複数のユーザーアプリケーションに送信するように要求できます。
Typically, each operating system uses a dedicated PNS. Different PNSs exist today. Some are based on the standardized mechanism defined in [RFC8030], while others are proprietary. For example, Apple iOS devices use the Apple Push Notification service (APNs) while Android devices use the Firebase Cloud Messaging (FCM) service. Each PNS uses PNS-specific terminology and function names. The terminology in this document is meant to be PNS-independent. If the PNS is based on [RFC8030], the SIP proxy takes the role of the application server.
通常、各オペレーティングシステムは専用のPNSを使用します。今日、さまざまなPNSが存在しています。 [RFC8030]で定義された標準化されたメカニズムに基づくものもあれば、独自のものもあります。たとえば、Apple iOSデバイスはAppleプッシュ通知サービス（APN）を使用し、AndroidデバイスはFirebase Cloud Messaging（FCM）サービスを使用します。各PNSは、PNS固有の用語と機能名を使用します。このドキュメントの用語は、PNSに依存しないことを意味しています。 PNSが[RFC8030]に基づいている場合、SIPプロキシはアプリケーションサーバーの役割を果たします。
When a Session Initiation Protocol (SIP) User Agent (UA)[RFC3261] is suspended in such an environment, it is unable to send binding-refresh SIP REGISTER requests, unable to receive incoming SIP requests, and might not be able to use internal timers to wake itself. A suspended UA will not be able to maintain connections, e.g., using the SIP Outbound Mechanism [RFC5626], because it cannot send periodic keep-alive messages. A PNS is needed to wake the SIP UA so that the UA can perform these functions.
このような環境でセッション開始プロトコル（SIP）ユーザーエージェント（UA）[RFC3261]が一時停止されている場合、バインディングリフレッシュSIP REGISTERリクエストを送信できず、着信SIPリクエストを受信できず、内部を使用できない場合があります。タイマーがそれ自体を起こします。中断されたUAは、定期的なキープアライブメッセージを送信できないため、たとえばSIPアウトバウンドメカニズム[RFC5626]を使用して接続を維持できません。 UAがこれらの機能を実行できるように、SIP UAを起動するにはPNSが必要です。
This document describes how a PNS can be used to wake a suspended UA using push notifications, so that the UA can send binding-refresh REGISTER requests and receive incoming SIP requests. The document defines new SIP URI parameters and new feature-capability indicators [RFC6809] that can be used in SIP messages to indicate support of the mechanism defined in this document; be used to exchange PNS information between the UA and the SIP entity (realized as a SIP proxy in this document) that will request that push notifications are sent to the UA; and be used to request such push notification requests.
このドキュメントでは、PNSを使用して、プッシュ通知を使用して中断されたUAをウェイクアップし、UAがbinding-refresh REGISTER要求を送信し、着信SIP要求を受信できるようにする方法について説明します。このドキュメントは、新しいSIP URIパラメータと、このドキュメントで定義されているメカニズムのサポートを示すためにSIPメッセージで使用できる新しい機能機能インジケータ[RFC6809]を定義しています。 UAとSIPエンティティ（このドキュメントではSIPプロキシとして実現）の間でPNS情報を交換するために使用され、プッシュ通知がUAに送信されることを要求します。そのようなプッシュ通知要求を要求するために使用されます。
NOTE: Even if a UA is able to be awakened by means other than receiving push notifications (e.g., by using internal timers) in order to send periodic binding-refresh REGISTER requests, it might still be useful to suspend the UA between the sending of binding-refresh requests (as it will save battery life) and use push notifications to wake the UA when an incoming SIP request UA arrives.
注：定期的なbinding-refresh REGISTERリクエストを送信するために、プッシュ通知を受信する以外の方法で（たとえば、内部タイマーを使用して）UAを呼び起こすことができる場合でも、送信から送信までの間にUAを一時停止すると役立つ場合がありますバインディング更新リクエスト（バッテリー寿命を節約するため）と、着信SIPリクエストUAが到着したときにプッシュ通知を使用してUAをウェイクアップします。
When a UA registers with a PNS (Figure 1), it will receive a unique Push Resource ID (PRID) associated with the push notification registration. The UA will use a REGISTER request to provide the PRID to the SIP proxy, which will then request that push notifications are sent to the UA.
UAがPNSに登録すると（図1）、プッシュ通知登録に関連付けられた一意のプッシュリソースID（PRID）を受け取ります。 UAは、REGISTER要求を使用してPRIDをSIPプロキシに提供し、次に、プッシュ通知がUAに送信されるように要求します。
When the SIP proxy receives a SIP request for a new dialog or a standalone SIP request addressed towards a UA, or when the SIP proxy determines that the UA needs to send a binding-refresh REGISTER request, the SIP proxy will send a push request containing the PRID of the UA to the PNS, which will then send a push notification to the UA. Once the UA receives the push notification, it will be able to send a binding-refresh REGISTER request. The proxy receives the REGISTER request from the UA and forwards it to the SIP registrar [RFC3261]. After accepting the REGISTER request, the SIP registrar sends a 2xx response to the proxy, which forwards the response to the UA. If the push notification request was triggered by a SIP request addressed towards the UA, the proxy can then forward the SIP request to the UA using normal SIP routing procedures. In some cases, the proxy can forward the SIP request without waiting for the SIP 2xx response to the REGISTER request from the SIP registrar. Note that this mechanism necessarily adds delay to responding to requests requiring push notification. The consequences of that delay are discussed in Section 5.6.2.
SIPプロキシが新しいダイアログのSIPリクエストまたはUA宛のスタンドアロンSIPリクエストを受信した場合、またはSIPプロキシがUAがbinding-refresh REGISTERリクエストを送信する必要があると判断した場合、SIPプロキシは以下を含むプッシュリクエストを送信します。 UAのPRIDからPNSへ。PNSは次に、UAにプッシュ通知を送信します。 UAがプッシュ通知を受信すると、バインディングリフレッシュREGISTERリクエストを送信できるようになります。プロキシはUAからREGISTERリクエストを受信し、それをSIPレジストラ[RFC3261]に転送します。 REGISTER要求を受け入れた後、SIPレジストラは2xx応答をプロキシに送信し、プロキシは応答をUAに転送します。プッシュ通知要求がUA宛てのSIP要求によってトリガーされた場合、プロキシは通常のSIPルーティング手順を使用してSIP要求をUAに転送できます。場合によっては、プロキシはSIPレジストラからのREGISTER要求に対するSIP 2xx応答を待たずにSIP要求を転送できます。このメカニズムは、プッシュ通知を必要とするリクエストへの応答に必然的に遅延を追加することに注意してください。その遅延の結果については、セクション5.6.2で説明します。
If there are Network Address Translators (NATs) between the UA and the proxy, the REGISTER request sent by the UA will create NAT bindings that will allow the incoming SIP request that triggered the push notification to reach the UA.
UAとプロキシの間にネットワークアドレストランスレータ（NAT）がある場合、UAによって送信されたREGISTER要求は、プッシュ通知をトリガーした着信SIP要求がUAに到達できるようにするNATバインディングを作成します。
NOTE: The lifetime of any NAT binding created by the REGISTER request only needs to be long enough for the SIP request that triggered the push notification to reach the UA.
注：REGISTER要求によって作成されたNATバインディングの存続期間は、プッシュ通知をトリガーしたSIP要求がUAに到達するのに十分な長さである必要があります。
Figure 1 shows the generic push notification architecture supported by the mechanism in this document.
図1は、このドキュメントのメカニズムでサポートされている一般的なプッシュ通知アーキテクチャを示しています。
The SIP proxy MUST be in the signaling path of REGISTER requests sent by the UA towards the registrar, and of SIP requests (for a new dialog or a standalone) forwarded by the proxy responsible for the UA's domain (sometimes referred to as home proxy, Serving Call Session Control Function (S-CSCF), etc.) towards the UA. The proxy can also be co-located with the proxy responsible for the UA's domain. This will also ensure that the Request-URI of SIP requests (for a new dialog or a standalone) can be matched against contacts in REGISTER requests.
SIPプロキシは、UAがレジストラに向けて送信するREGISTER要求のシグナリングパス、およびUAのドメインを担当するプロキシ（ホームプロキシと呼ばれることもある）によって転送されるSIP要求（新しいダイアログまたはスタンドアロン用）のシグナリングパスに存在する必要があります。コールセッション制御機能（S-CSCF）など）をUAに提供します。プロキシは、UAのドメインを担当するプロキシと同じ場所に配置することもできます。これにより、SIPリクエストのRequest-URI（新しいダイアログまたはスタンドアロン用）をREGISTERリクエストの連絡先と確実に一致させることができます。
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| Subscribe | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | SIP INVITE (PRID) |
| | |<==================|
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| SIP INVITE | | |
|<===================================| |
| | | |
------- Push Notification API
======= SIP
Figure 1: SIP Push Information Flow
図1：SIPプッシュ情報フロー
Example of a SIP REGISTER request in the flow above:
上記のフローのSIP REGISTERリクエストの例：
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-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
Expires: 7200
Content-Length: 0
Figure 2: SIP REGISTER Example
図2：SIPレジスタの例
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
When a SIP UA registers with a PNS it receives a unique Push Resource ID (PRID), which is a value associated with the registration that can be used to generate push notifications.
SIP UAがPNSに登録すると、一意のプッシュリソースID（PRID）を受信します。これは、プッシュ通知の生成に使用できる登録に関連付けられた値です。
The format of the PRID varies depending on the PNS.
PRIDの形式はPNSによって異なります。
The details regarding discovery of the PNS, and the procedures regarding the push notification registration and maintenance, are outside the scope of this document. The information needed to contact the PNS is typically preconfigured in the operating system of the device.
PNSの検出に関する詳細、およびプッシュ通知の登録と保守に関する手順は、このドキュメントの範囲外です。 PNSへの接続に必要な情報は、通常、デバイスのオペレーティングシステムで事前設定されています。
This section describes how a SIP UA sends SIP REGISTER requests (either an initial REGISTER request for a binding or a binding-refresh REGISTER request) in order to request and disable push notifications from a SIP network, and to query the types of PNSs supported by the SIP network.
このセクションでは、SIPネットワークからのプッシュ通知を要求および無効化し、サポートされるPNSのタイプを照会するために、SIP UAがSIP REGISTER要求（バインディングの最初のREGISTER要求またはバインディングリフレッシュREGISTER要求のいずれか）を送信する方法について説明しますSIPネットワーク。
Unless specified otherwise, the normal SIP UA registration procedures [RFC3261] apply. The additional procedures described in this section apply when the REGISTER request contains a 'pn-provider' SIP URI parameter in the Contact header field URI (Figure 2).
特に指定のない限り、通常のSIP UA登録手順[RFC3261]が適用されます。このセクションで説明する追加の手順は、REGISTER要求のContactヘッダーフィールドURIに「pn-provider」SIP URIパラメータが含まれている場合に適用されます（図2）。
The procedures in this section apply to individual bindings [RFC3261]. If a UA creates multiple bindings (e.g., one for IPv4 and one for IPv6), the UA needs to perform the procedures for each binding.
このセクションの手順は、個々のバインディング[RFC3261]に適用されます。 UAが複数のバインディングを作成する場合（IPv4用とIPv6用など）、UAは各バインディングの手順を実行する必要があります。
NOTE: Since a push notification will trigger the UA to refresh all bindings, if a SIP UA has created multiple bindings, it is preferable if one can ensure that all bindings expire at the same time to help prevent some bindings from being refreshed earlier than needed.
注：プッシュ通知はUAをトリガーしてすべてのバインディングを更新するため、SIP UAが複数のバインディングを作成した場合、すべてのバインディングが同時に期限切れになることを確認して、一部のバインディングが必要以上に早く更新されるのを防ぐことができれば望ましいです。 。
For privacy and security reasons, a UA MUST NOT insert the SIP URI parameters (except for the 'pn-purr' parameter) defined in this specification in non-REGISTER requests in order to prevent the PNS information associated with the UA from reaching the remote peer. For example, the UA MUST NOT insert the 'pn-prid' SIP URI parameter in the Contact header field URI of an INVITE request. REGISTER requests will not reach the remote peer, as they will be terminated by the registrar of the UA. However, the registrar MUST still ensure that the parameters are not sent to other users, e.g., using the mechanism defined by the SIP event package for registrations [RFC3680]. See Section 13 for more information.
プライバシーとセキュリティ上の理由から、UAは、UAに関連付けられたPNS情報がリモートに到達しないようにするために、この仕様で定義されているSIP URIパラメータ（「pn-purr」パラメータを除く）を非REGISTERリクエストに挿入してはなりません（MUST NOT）。ピア。たとえば、UAは「pn-prid」SIP URIパラメータをINVITEリクエストのContactヘッダーフィールドURIに挿入してはなりません（MUST NOT）。 REGISTERリクエストは、UAのレジストラによって終了されるため、リモートピアに到達しません。ただし、レジストラは、たとえば、登録用のSIPイベントパッケージ[RFC3680]で定義されたメカニズムを使用して、パラメータが他のユーザーに送信されないようにする必要があります。詳細については、セクション13を参照してください。
This section describes the procedures that a SIP UA follows to request push notifications from the SIP network. The procedures assume that the UA has retrieved a PRID from a PNS. The procedures for retrieving the PRID from the PNS are PNS-specific and outside the scope of this specification. See PNS-specific documentation for more details.
このセクションでは、SIP UAがSIPネットワークからのプッシュ通知を要求するために従う手順について説明します。この手順では、UAがPNSからPRIDを取得したと想定しています。 PNSからPRIDを取得する手順はPNS固有であり、この仕様の範囲外です。詳細については、PNS固有のドキュメントを参照してください。
This specification does not define a mechanism to explicitly request push notifications from the SIP network for usages other than triggering binding-refresh REGISTER requests (e.g., for sending periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does it describe how to distinguish push notifications associated with such usages from the push notifications used to trigger binding-refresh REGISTER requests. If a SIP UA wants to use push notifications for other usages, the UA can perform actions associated with such usages (in addition to sending a binding-refresh REGISTER request) whenever it receives a push notification by using the same refresh interval that is used for the binding refreshes.
この仕様は、バインディングリフレッシュREGISTERリクエストのトリガー以外の用途（たとえば、定期的なサブスクリプションリフレッシュSUBSCRIBEリクエスト[RFC6665]の送信）について、SIPネットワークからプッシュ通知を明示的にリクエストするメカニズムを定義していません。また、プッシュを区別する方法についても説明していません。 binding-refresh REGISTERリクエストをトリガーするために使用されるプッシュ通知からのそのような使用に関連付けられた通知。 SIP UAが他の用途にプッシュ通知を使用したい場合、UAは、（バインディングリフレッシュREGISTERリクエストの送信に加えて）その用途に関連付けられているアクションを実行できます。バインディングが更新されます。
To request push notifications from the SIP network, the UA MUST insert the following SIP URI parameters in the SIP Contact header field URI of the REGISTER request: 'pn-provider', 'pn-prid', and 'pn-param' (if required for the specific PNS). The 'pn-provider' URI parameter indicates the type of PNS to be used for the push notifications.
SIPネットワークからのプッシュ通知を要求するには、UAは次のSIP URIパラメーターをREGISTER要求のSIP ContactヘッダーフィールドURIに挿入する必要があります： 'pn-provider'、 'pn-prid'、および 'pn-param'（if特定のPNSに必要です）。 'pn-provider' URIパラメーターは、プッシュ通知に使用されるPNSのタイプを示します。
If the UA receives a 2xx response to the REGISTER request that contains a Feature-Caps header field [RFC6809] with a 'sip.pns' feature-capability indicator, with an indicator value identifying the same type of PNS that was identified by the 'pn-provider' URI parameter in the REGISTER request, it indicates that another SIP Proxy in the SIP network will request that push notifications are sent to the UA. In addition, if the same Feature-Caps header field contains a 'sip.vapid' feature-capability indicator, it indicates that the proxy supports use of the Voluntary Application Server Identification (VAPID) mechanism [RFC8292] to restrict push notifications to the UA.
UAが、 'sip.pns'機能能力インジケーターを備えたFeature-Capsヘッダーフィールド[RFC6809]を含むREGISTER要求に対する2xx応答を受信した場合、インジケーター値は、 'で識別されたのと同じタイプのPNSを識別します。 REGISTER要求のpn-provider 'URIパラメーター。これは、SIPネットワーク内の別のSIPプロキシがプッシュ通知をUAに送信するよう要求することを示します。さらに、同じFeature-Capsヘッダーフィールドに 'sip.vapid'機能機能インジケーターが含まれている場合は、プロキシが自発的アプリケーションサーバー識別（VAPID）メカニズム[RFC8292]の使用をサポートして、UAへのプッシュ通知を制限していることを示します。 。
NOTE: The VAPID-specific procedures of the SIP UA are outside the scope of this document.
注：SIP UAのVAPID固有の手順は、このドキュメントの範囲外です。
If the UA receives a non-2xx response to the REGISTER, or if the UA receives a 2xx response that does not contain a Feature-Caps header field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA MUST NOT assume the proxy will request that push notifications are sent to the UA. The actions taken by the UA in such cases are outside the scope of this document.
UAがREGISTERに対して2xx以外の応答を受信した場合、またはUAが 'sip.pns'機能能力インジケーターを備えたFeature-Capsヘッダーフィールド[RFC6809]を含まない2xx応答を受信した場合、UAはプロキシがプッシュ通知がUAに送信されることを要求すると仮定します。そのような場合にUAが取るアクションは、このドキュメントの範囲外です。
If the PRID is only valid for a limited time, then the UA is responsible for retrieving a new PRID from the PNS and sending a binding-refresh REGISTER request with the updated 'pn-*' parameters. If a PRID is no longer valid, and the UA is not able to retrieve a new PRID, the UA MUST disable the push notifications associated with the PRID (Section 4.1.2).
PRIDが限られた期間のみ有効である場合、UAはPNSから新しいPRIDを取得し、更新された「pn- *」パラメーターを使用してbinding-refresh REGISTER要求を送信します。 PRIDが有効でなくなり、UAが新しいPRIDを取得できない場合、UAはPRIDに関連付けられたプッシュ通知を無効にする必要があります（セクション4.1.2）。
When a UA wants to disable previously requested push notifications, the UA SHOULD remove the binding [RFC3261], unless the UA is no longer able to perform SIP procedures (e.g., due to a forced shutdown of the UA), in which case the registrar will remove the binding once it expires. When the UA sends the REGISTER request for removing the binding, the UA MUST NOT insert the 'pn-prid' SIP URI parameter in the Contact header field URI of the REGISTER request. The lack of the parameter informs the SIP network that the UA no longer wants to receive push notifications associated with the PRID.
UAが以前に要求されたプッシュ通知を無効にしたい場合、UAは（たとえば、UAの強制シャットダウンが原因で）UAがSIP手順を実行できなくなった場合を除き、バインディングを削除する必要があります[RFC3261]。この場合、レジストラ有効期限が切れると、バインディングが削除されます。 UAがバインディングを削除するためにREGISTER要求を送信するとき、UAは「pn-prid」SIP URIパラメータをREGISTER要求のContactヘッダーフィールドURIに挿入してはなりません（MUST NOT）。パラメータの欠如は、UAがPRIDに関連付けられたプッシュ通知を受信する必要がなくなったことをSIPネットワークに通知します。
When a UA receives a push notification, the UA MUST send a binding-refresh REGISTER request. The UA MUST insert the same set of 'pn-*' SIP URI parameters in the SIP Contact header field URI of the REGISTER request that it inserted when it requested push notifications (Section 4.1.1). Note that, in some cases, the PNS might update the PRID value, in which case the UA will insert the new value in the 'pn-prid' SIP URI parameter of the binding-refresh REGISTER request.
UAがプッシュ通知を受信すると、UAはbinding-refresh REGISTER要求を送信する必要があります。 UAは、プッシュ通知をリクエストしたときに挿入したものと同じ「pn-*」SIP URIパラメータのセットをREGISTERリクエストのSIP ContactヘッダーフィールドURIに挿入する必要があります（セクション4.1.1）。場合によっては、PNSがPRID値を更新する場合があることに注意してください。その場合、UAはbinding-refresh REGISTERリクエストの「pn-prid」SIP URIパラメータに新しい値を挿入します。
Once the UA has received a 2xx response to the REGISTER request, the UA might receive a SIP request for a new dialog (e.g., a SIP INVITE) or a standalone SIP request (e.g., a SIP MESSAGE) if such a SIP request triggered the proxy to request that the push notification was sent to the UA. Note that, depending on which transport protocol is used, the SIP request might reach the UA before the REGISTER response.
UAがREGISTER要求に対する2xx応答を受信すると、そのようなSIP要求によってトリガーされた場合、UAは新しいダイアログ（SIP INVITEなど）のSIP要求またはスタンドアロンSIP要求（SIP MESSAGEなど）を受信することがあります。プッシュ通知がUAに送信されたことを要求するプロキシ。使用されるトランスポートプロトコルによっては、SIP要求がREGISTER応答の前にUAに到達する場合があることに注意してください。
If the SIP UA has created multiple bindings, the UA MUST send a binding-refresh REGISTER request for each of those bindings when it receives a push notification.
SIP UAが複数のバインディングを作成した場合、UAはプッシュ通知を受信したときに、それらの各バインディングに対してbinding-refresh REGISTER要求を送信する必要があります。
This specification does not define any usage of push-notification payload. If a SIP UA receives a push notification that contains a payload, the UA can discard the payload but will still send a binding-refresh REGISTER request.
この仕様は、プッシュ通知ペイロードの使用法を定義していません。 SIP UAがペイロードを含むプッシュ通知を受信した場合、UAはペイロードを破棄できますが、バインディングリフレッシュREGISTER要求を送信します。
If a UA is able to send binding-refresh REGISTER requests using a non-push mechanism (e.g., using an internal timer that periodically wakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag [RFC3840] in the Contact header field of each REGISTER request.
UAが非プッシュメカニズムを使用して（たとえば、定期的にUAをウェイクアップする内部タイマーを使用して）バインディングリフレッシュREGISTER要求を送信できる場合、UAは 'sip.pnsreg'メディア機能タグ[RFC3840]を各REGISTERリクエストの連絡先ヘッダーフィールド。
If the UA receives a 2xx response to the REGISTER request that contains a Feature-Caps header field with a 'sip.pnsreq' feature-capability indicator, the UA MUST send a binding-refresh REGISTER request prior to binding expiration. The indicator value indicates the minimum time (given in seconds), prior to the binding expiration when the UA needs to send the REGISTER request.
UAが 'sip.pnsreq'機能能力インジケーターを持つFeature-Capsヘッダーフィールドを含むREGISTER要求に対する2xx応答を受信した場合、UAはバインディングの有効期限が切れる前にbinding-refresh REGISTER要求を送信する必要があります。インジケータ値は、UAがREGISTERリクエストを送信する必要がある、バインディングの有効期限が切れるまでの最小時間（秒単位）を示します。
If the UA receives a 2xx response to the REGISTER request that does not contain a Feature-Caps header field with a 'sip.pnsreq' feature-capability indicator, the UA SHOULD only send a binding-refresh REGISTER request when it receives a push notification (even if the UA is able to use a non-push mechanism for sending binding-refresh REGISTER requests) or when there are circumstances that require an immediate REGISTER request to be sent (e.g., if the UA is assigned new contact parameters due to a network configuration change).
UAが「sip.pnsreq」機能能力インジケーターを持つFeature-Capsヘッダーフィールドを含まないREGISTER要求に対する2xx応答を受信した場合、UAはプッシュ通知を受信したときにのみバインディングリフレッシュREGISTER要求を送信する必要があります（UAが非更新メカニズムを使用してbinding-refresh REGISTERリクエストを送信できる場合でも）、または即時のREGISTERリクエストを送信する必要がある状況がある場合（たとえば、UAに新しい連絡先パラメーターが割り当てられている場合）ネットワーク構成の変更）。
Even if the UA is able to send binding-refresh REGISTER requests using a non-push mechanism, the UA MUST still send a binding-refresh REGISTER request whenever it receives a push notification (Section 4.1.3).
UAが非プッシュメカニズムを使用してbinding-refresh REGISTER要求を送信できる場合でも、UAはプッシュ通知を受信するたびに（セクション4.1.3）常にbinding-refresh REGISTER要求を送信する必要があります。
NOTE: If the UA uses a non-push mechanism to wake and send binding-refresh REGISTER requests, such REGISTER requests will update the binding expiration timer, and the proxy does not need to request that a push notification be sent to the UA in order to wake the UA. The proxy will still request that a push notification be sent to the UA when the proxy receives a SIP request addressed towards the UA (Section 5.6.2). This allows the UA to, e.g., use timers for sending binding-refresh REGISTER requests but be suspended (in order to save battery resources, etc.) between sending the REGISTER requests and using push notifications to wake the UA to process incoming calls.
注：UAが非プッシュメカニズムを使用してバインディングリフレッシュREGISTER要求を起動および送信する場合、そのようなREGISTER要求はバインディングの有効期限タイマーを更新し、プロキシはプッシュ通知をUAに送信するように要求する必要がありません。 UAを起こします。プロキシは、UA宛てのSIPリクエストを受信したときに、UAにプッシュ通知を送信するように要求します（セクション5.6.2）。これにより、UAは、例えば、タイマーを使用してバインディングリフレッシュREGISTERリクエストを送信しますが、REGISTERリクエストを送信してからプッシュ通知を使用してUAをウェイクして着信コールを処理するまでの間に（バッテリーリソースを節約するために）一時停止できます。
Example of a SIP REGISTER request including a 'sip.pnsreg' media feature tag:
「sip.pnsreg」メディア機能タグを含むSIP REGISTERリクエストの例：
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-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Expires: 7200
Content-Length: 0
Example of a SIP REGISTER response including a 'sip.pnsreg' media feature tag and a 'sip.pnsreq' feature-capability indicator:
「sip.pnsreg」メディア機能タグと「sip.pnsreq」機能機能インジケーターを含むSIP REGISTER応答の例：
SIP/2.0 200 OK
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
To: Alice <sip:alice@example.com>;tag=123987
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Feature-Caps: *;+sip.pns="acme";+sip.pnsreg="121"
Expires: 7200
Content-Length: 0
Figure 3: SIP REGISTER When Using Non-push Mechanism Example
図3：非プッシュメカニズムを使用する場合のSIPレジスタの例
This section describes how a SIP UA can query the types of PNSs supported by a SIP network, and PNS-related capabilities (e.g., support of the VAPID mechanism). When a UA performs a query, it does not request push notifications from the SIP network. Therefore, the UA can perform the query before it has registered to a PNS and received a PRID.
このセクションでは、SIP UAがSIPネットワークでサポートされているPNSのタイプ、およびPNS関連の機能（VAPIDメカニズムのサポートなど）を照会する方法について説明します。 UAがクエリを実行するとき、SIPネットワークからのプッシュ通知を要求しません。したがって、UAはPNSに登録してPRIDを受信する前にクエリを実行できます。
In order to perform a query, the UA MUST insert a 'pn-provider' SIP URI parameter in the Contact header field URI of the REGISTER request:
クエリを実行するために、UAは 'pn-provider' SIP URIパラメータをREGISTERリクエストのContactヘッダーフィールドURIに挿入する必要があります。
o If the UA inserts a 'pn-provider' parameter value, indicating support of a type of PNS, the SIP network will only inform the UA whether that type of PNS is supported.
o UAが「pn-provider」パラメータ値を挿入し、あるタイプのPNSのサポートを示している場合、SIPネットワークはそのタイプのPNSがサポートされているかどうかをUAに通知するだけです。
o If the UA does not insert a 'pn-provider' parameter value (i.e., it inserts an "empty" 'pn-provider' parameter), the SIP network will inform the UA about all types of PNSs supported by the network. This is useful, e.g., if the UA supports more than one type of PNS. Note that it is not possible to insert multiple parameter values in the 'pn-provider' parameter.
o UAが「pn-provider」パラメーター値を挿入しない場合（つまり、「空の」「pn-provider」パラメーターを挿入する場合）、SIPネットワークは、ネットワークでサポートされるすべてのタイプのPNSについてUAに通知します。これは、UAが複数のタイプのPNSをサポートする場合などに便利です。 「pn-provider」パラメーターに複数のパラメーター値を挿入することはできないことに注意してください。
The UA MUST NOT insert a 'pn-prid' SIP URI parameter in the Contact header field URI of the REGISTER request.
UAは、REGISTERリクエストのContactヘッダーフィールドURIに「pn-prid」SIP URIパラメータを挿入してはなりません（MUST NOT）。
If the UA receives a 2xx response to the REGISTER request, the response will contain one or more Feature-Caps header fields with a 'sip.pns' feature-capability indicator, indicating the types of PNSs supported by the SIP network. If the UA inserted a 'pn-provider' SIP URI parameter value in the REGISTER request, the response will only indicate whether the SIP network supports the type of PNS supported by the UA.
UAがREGISTER要求に対する2xx応答を受信した場合、応答には、SIPネットワークでサポートされているPNSのタイプを示す「sip.pns」機能能力インジケーターが付いた1つ以上のFeature-Capsヘッダーフィールドが含まれます。 UAがREGISTER要求に「pn-provider」SIP URIパラメータ値を挿入した場合、応答は、UAがサポートするPNSのタイプをSIPネットワークがサポートするかどうかのみを示します。
If the UA receives a 555 (Push Notification Service Not Supported) response to the REGISTER request, and if the UA inserted a 'pn-provider' SIP URI parameter in the REGISTER request, the response 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.
UAがREGISTER要求に対する555（プッシュ通知サービスはサポートされていません）応答を受信し、UAがREGISTER要求に「pn-provider」SIP URIパラメータを挿入した場合、その応答は、ネットワークがUAがサポートを示したPNS。 UAがREGISTER要求に「pn-provider」パラメータを挿入しなかった場合、応答は、ネットワークがどのタイプのPNSもサポートしていないが、555（プッシュ通知サービスはサポートされていない）応答をサポートしていることを示しています。
NOTE: It is optional for a UA to perform a query before it requests push notifications from the SIP network.
注：SIPネットワークからのプッシュ通知を要求する前に、UAがクエリを実行することはオプションです。
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 of PNS, while in other cases there might be multiple providers. The 'pn-param' SIP URI parameter will provide more details associated with the actual PNS provider to be used.
PNSのタイプは、「pn-provider」SIP URIパラメータによって識別されます。特定の種類のPNSに対してPNSプロバイダーが1つしかない場合もあれば、複数のプロバイダーが存在する場合もあります。 'pn-param' SIP URIパラメーターは、使用される実際のPNSプロバイダーに関連する詳細を提供します。
The protocol and format used for the push notification requests are PNS-specific, and the details for constructing and sending a push notification request are outside the scope of this specification.
プッシュ通知要求に使用されるプロトコルと形式はPNS固有であり、プッシュ通知要求の作成と送信の詳細はこの仕様の範囲外です。
When a SIP proxy receives a SIP request addressed towards a UA, that will trigger the proxy to request that a push notification be sent to the UA. The proxy will place the request in storage (referred to as the SIP Request Push Bucket) and the proxy will start a timer (referred to as the Bucket Timer) associated with the transaction. A SIP request is removed from the bucket when one of the following has occurred: the proxy forwards the request towards the UA, the proxy sends an error response to the request, or the Bucket Timer times out. The detailed procedures are described in the sections below.
SIPプロキシがUA宛てのSIP要求を受信すると、プッシュ通知をUAに送信するように要求するプロキシをトリガーします。プロキシは要求をストレージ（SIPリクエストプッシュバケットと呼ばれる）に配置し、プロキシはトランザクションに関連付けられたタイマー（バケットタイマーと呼ばれる）を開始します。次のいずれかが発生すると、SIPリクエストがバケットから削除されます。プロキシがリクエストをUAに転送する、プロキシがリクエストにエラー応答を送信する、またはバケットタイマーがタイムアウトする。詳細な手順については、以下のセクションで説明します。
Exactly how the SIP Request Push Bucket is implemented is outside the scope of this document. One option is to use the PRID as a key to search for SIP requests in the bucket. Note that mid-dialog requests (Section 6) do not carry the PRID in the SIP request itself.
SIPリクエストプッシュバケットの正確な実装方法は、このドキュメントの範囲外です。 1つのオプションは、バケット内のSIPリクエストを検索するためのキーとしてPRIDを使用することです。ダイアログ中のリクエスト（セクション6）では、SIPリクエスト自体にPRIDは含まれません。
By default, a SIP proxy uses the URI comparison rules defined in [RFC3261]. However, when a SIP proxy compares the Contact header field URI of a 2xx response to a REGISTER request with a Request-URI of a SIP request in the SIP Request Push Bucket (Section 5.2), the proxy uses the URI comparison rules with the following additions: the 'pn-prid', 'pn-provider', and 'pn-param' SIP URI parameters MUST also match. If a 'pn-*' parameter is present in one of the compared URIs but not in the other URI, there is no match.
デフォルトでは、SIPプロキシは[RFC3261]で定義されているURI比較ルールを使用します。ただし、SIPプロキシは、REGISTERリクエストに対する2xx応答のContactヘッダーフィールドURIをSIPリクエストプッシュバケット（セクション5.2）のSIPリクエストのRequest-URIと比較する場合、URI比較ルールを次のように使用します。追加： 'pn-prid'、 'pn-provider'、および 'pn-param' SIP URIパラメーターも一致する必要があります。比較されたURIの1つに 'pn- *'パラメーターが存在するが、他のURIには存在しない場合、一致はありません。
If only the 'pn-*' SIP URI parameters listed above match, but other parts of the compared URIs do not match, a proxy MAY still consider the comparison successful based on local policy. This can occur in a race condition when the proxy compares the Contact header field URI of a 2xx response to a REGISTER request with a Request-URI of a SIP request in the SIP Request Push Bucket (Section 5.2) if the UA had modified some parts of the Contact header field URI in the REGISTER request but the Request-URI of the SIP request in the SIP Request Push Bucket still contains the old parts.
上記の「pn-*」SIP URIパラメータのみが一致し、比較されたURIの他の部分が一致しない場合でも、プロキシはローカルポリシーに基づいて比較が成功したと見なす場合があります。これは、UAが一部を変更した場合に、プロキシがREGISTERリクエストの2xx応答のContactヘッダーフィールドURIをSIPリクエストプッシュバケット（セクション5.2）のSIPリクエストのRequest-URIと比較するときに、競合状態で発生する可能性があります。 REGISTERリクエストのContactヘッダーフィールドURIの一部ですが、SIPリクエストプッシュバケットのSIPリクエストのRequest-URIには古い部分が含まれています。
A SIP proxy uses feature-capability indicators [RFC6809] to indicate support of types of PNSs and additional features (e.g., VAPID) associated with the type of PNS. A proxy MUST use a separate Feature-Cap header field for each supported type of PNS. A feature- capability indicator that indicates support of an additional feature associated with a given type of PNS MUST be inserted in the same Feature-Caps header field that is used to indicate support of the type of PNS.
SIPプロキシは、機能機能インジケータ[RFC6809]を使用して、PNSのタイプのサポートとPNSのタイプに関連付けられた追加機能（VAPIDなど）を示します。プロキシは、サポートされるPNSのタイプごとに個別のFeature-Capヘッダーフィールドを使用する必要があります。 PNSのタイプのサポートを示すために使用されるのと同じFeature-Capsヘッダーフィールドに、特定のタイプのPNSに関連付けられた追加機能のサポートを示す機能機能インジケーターを挿入する必要があります。
This specification defines the following feature-capability indicators that a proxy can use to indicate support of additional features associated with a given type of PNS: 'sip.vapid', 'sip.pnsreg', and 'sip.pnspurr'. These feature-capability indicators MUST only be inserted in a Feature-Caps header field that also contains a 'sip.pns' feature-capability indicator.
この仕様は、プロキシが特定のタイプのPNSに関連付けられた追加機能のサポートを示すために使用できる次の機能能力インジケーターを定義しています：「sip.vapid」、「sip.pnsreg」、および「sip.pnspurr」。これらの機能能力インジケーターは、「sip.pns」機能能力インジケーターも含むFeature-Capsヘッダーフィールドにのみ挿入する必要があります。
In order to request that a push notification be sent to a SIP UA, a SIP proxy needs to have information about when a binding will expire. The proxy needs to be able to retrieve the information from the registrar using some mechanism or run its own registration timers. Such mechanisms are outside the scope of this document but could be implemented, e.g., by using the SIP event package for registrations mechanism [RFC3680].
プッシュ通知をSIP UAに送信するように要求するには、SIPプロキシにバインディングの有効期限に関する情報が必要です。プロキシは、何らかのメカニズムを使用してレジストラから情報を取得するか、独自の登録タイマーを実行できる必要があります。このようなメカニズムはこのドキュメントの範囲外ですが、たとえば、登録メカニズム用のSIPイベントパッケージを使用して実装できます[RFC3680]。
When the proxy receives an indication that the UA needs to send a binding-refresh REGISTER request, the proxy will request that a push notification be sent to the UA.
UAがbinding-refresh REGISTER要求を送信する必要があるという指示をプロキシが受信すると、プロキシはプッシュ通知をUAに送信するように要求します。
Note that the push notification needs to be requested early enough for the associated binding-refresh REGISTER request to reach the registrar before the binding expires. It is RECOMMENDED that the proxy requests the push notification at least 120 seconds before the binding expires.
バインディングの有効期限が切れる前に、関連付けられたbinding-refresh REGISTERリクエストがレジストラに到達するためには、プッシュ通知を早くリクエストする必要があることに注意してください。プロキシがバインディングが期限切れになる少なくとも120秒前にプッシュ通知を要求することをお勧めします。
If the UA has indicated, using the 'sip.pnsreg' media feature tag, that it is able to wake itself using a non-push mechanism in order to send binding-refresh REGISTER requests, and if the proxy does not receive a REGISTER request prior to 120 seconds before the binding expires, the proxy MAY request that a push notification be sent to the UA to trigger the UA to send a binding-refresh REGISTER request.
UAが「sip.pnsreg」メディア機能タグを使用して、バインディングリフレッシュREGISTERリクエストを送信するために非プッシュメカニズムを使用して自身をウェイクアップできること、およびプロキシがREGISTERリクエストを受信しないことを示している場合バインディングの有効期限が切れる120秒前に、プロキシはUAにプッシュ通知を送信して、UAがbinding-refresh REGISTER要求を送信するようトリガーするよう要求する場合があります。
NOTE: As described in Section 4.1.5, a UA might send a REGISTER request without including a 'pn-prid' SIP URI parameter in order to retrieve push notification capabilities from the network before the UA expects to receive push notifications from the network. A proxy will not request that push notifications are sent to a UA that has not provided a 'pn-prid' SIP URI parameter (Section 5.6.2).
注：セクション4.1.5で説明されているように、UAがネットワークからプッシュ通知を受信する前に、UAがネットワークからプッシュ通知機能を取得するために、「pn-prid」SIP URIパラメータを含めずにREGISTER要求を送信する場合があります。プロキシは、「pn-prid」SIP URIパラメータを提供していないUAにプッシュ通知が送信されることを要求しません（セクション5.6.2）。
If the proxy receives information that a binding associated with a PRID has expired, or that a binding has been removed, the proxy MUST NOT request that further push notifications are sent to the UA using that PRID.
プロキシがPRIDに関連付けられたバインディングの有効期限が切れている、またはバインディングが削除されたという情報を受け取った場合、プロキシはそのPRIDを使用してさらにプッシュ通知がUAに送信されることを要求してはなりません（MUST NOT）。
This section describes how a SIP proxy processes SIP REGISTER requests (initial REGISTER request for a binding or a binding-refresh REGISTER request).
このセクションでは、SIPプロキシがSIP REGISTERリクエストを処理する方法について説明します（バインディングの最初のREGISTERリクエストまたはbinding-refresh REGISTERリクエスト）。
The procedures in this section apply when the REGISTER request contains a 'pn-provider' SIP URI parameter in the Contact header field URI. In other cases, the proxy MUST skip the procedures in this section and process the REGISTER request using normal SIP procedures.
このセクションの手順は、REGISTER要求のContactヘッダーフィールドURIに「pn-provider」SIP URIパラメータが含まれている場合に適用されます。他の場合では、プロキシはこのセクションの手順をスキップし、通常のSIP手順を使用してREGISTER要求を処理する必要があります。
This section describes the SIP proxy procedures when a SIP UA requests push notifications from the SIP network.
このセクションでは、SIP UAがSIPネットワークからのプッシュ通知を要求する場合のSIPプロキシ手順について説明します。
The procedures in this section apply when the SIP REGISTER request contains, in addition to the 'pn-provider' SIP URI parameter, a 'pn-prid' SIP URI parameter in the Contact header field URI of the request.
このセクションの手順は、SIP REGISTER要求の「pn-provider」SIP URIパラメーターに加えて、要求のContactヘッダーフィールドURIに「pn-prid」SIP URIパラメーターが含まれている場合に適用されます。
When a proxy receives a REGISTER request that contains a Feature-Caps header field with a 'sip.pns' feature-capability indicator, it indicates that another proxy between this proxy and the UA supports the type of PNS supported by the UA, and will request that push notifications are sent to the UA. In such case, the proxy MUST skip the rest of the procedures in this section and process the REGISTER request using normal SIP procedures.
プロキシが、「sip.pns」機能機能インジケータを持つFeature-Capsヘッダーフィールドを含むREGISTERリクエストを受信すると、このプロキシとUAの間の別のプロキシが、UAでサポートされるPNSのタイプをサポートしていることを示し、プッシュ通知がUAに送信されるように要求します。そのような場合、プロキシはこのセクションの残りの手順をスキップし、通常のSIP手順を使用してREGISTER要求を処理する必要があります。
When a proxy receives a REGISTER request that does not contain a Feature-Caps header field with a 'sip.pns' feature-capability indicator, the proxy processes the request according to the procedures below:
プロキシーが、「sip.pns」機能機能標識を持つFeature-Capsヘッダーフィールドを含まないREGISTERリクエストを受信すると、プロキシーは以下の手順に従ってリクエストを処理します。
o If the proxy does not support the type of PNS supported by the UA, or if the REGISTER request does not contain all information required for the type of PNS, the proxy SHOULD forward the request towards the registrar and skip the rest of the procedures in this section. If the proxy knows (by means of local configuration) 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 (Push Notification Service Not Supported) response instead of forwarding the request.
oプロキシがUAでサポートされているPNSのタイプをサポートしていない場合、またはREGISTERリクエストにPNSのタイプに必要なすべての情報が含まれていない場合、プロキシはリクエストをレジストラに転送し、残りの手順をスキップする必要があります（SHOULD）。このセクション。プロキシが、ローカル設定によって、自身とレジストラの間で他のプロキシがUAでサポートされているPNSのタイプをサポートしていないことを知っている場合、プロキシは、リクエストを転送する代わりにSIP 555（プッシュ通知サービスはサポートされていません）応答を送信できます（MAY）。 。
o If the proxy supports the type of PNS supported by the UA, but considers the requested binding expiration interval [RFC3261] to be too short (see below), the proxy MUST either send a 423 (Interval Too Brief) response to the REGISTER request or forward the request towards the registrar and skip the rest of the procedures in this section.
o プロキシがUAでサポートされているPNSのタイプをサポートしているが、要求されたバインディング有効期限間隔[RFC3261]が短すぎる（下記参照）と見なす場合、プロキシはREGISTER要求に423（Interval Too Brief）応答を送信するか、要求をレジストラに転送し、このセクションの残りの手順をスキップします。
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 the REGISTER request before it forwards the request towards the registrar. This will inform proxies between the proxy and the registrar that the proxy supports the type of PNS supported by the UA, and that the proxy will request that push notifications are sent to the UA.
o プロキシがUAでサポートされるPNSのタイプをサポートする場合、プロキシは、レジストラにリクエストを転送する前に、REGISTERリクエストでそのタイプのPNS（セクション5.4）のサポートを示す必要があります。これにより、プロキシとレジストラの間のプロキシに、プロキシがUAでサポートされるPNSのタイプをサポートし、プロキシがプッシュ通知をUAに送信するように要求することが通知されます。
A binding expiration interval MUST be considered too short if the 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-refresh REGISTER request. The proxy MAY consider the interval too short based on its own policy so as to reduce load on the system.
プロキシがUAにプッシュ通知を送信するよう要求する前にバインディングが期限切れになる場合、バインディングの有効期限間隔は短すぎると見なさなければなりません（MUST）。これにより、UAがbinding-refresh REGISTERリクエストを送信します。プロキシは、システムの負荷を減らすために、独自のポリシーに基づいて間隔が短すぎると見なす場合があります。
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 above), the proxy performs the following actions:
プロキシーがREGISTER要求に対する2xx応答を受信したときに、プロキシーがREGISTER要求でPNSのタイプのサポートを示した場合（上記を参照）、プロキシーは以下のアクションを実行します。
o If the proxy considers the binding expiration interval indicated by the registrar too short (see above), the proxy forwards the response towards the UA and MUST skip the rest of the procedures in this section.
o プロキシがレジストラによって示されたバインディング有効期限間隔が短すぎる（上記を参照）と見なす場合、プロキシはUAに応答を転送し、このセクションの残りの手順をスキップする必要があります。
o The proxy MUST indicate support of the same type of PNS in the REGISTER response. In addition:
o プロキシは、REGISTER応答で同じタイプのPNSのサポートを示す必要があります。加えて：
* If the proxy supports the VAPID mechanism [RFC8292], the proxy MUST indicate support of the mechanism, using the 'sip.vapid' feature-capability indicator, in the REGISTER response. The indicator value contains the public key identifying the proxy. The proxy MUST determine whether the PNS provider supports the VAPID mechanism before it indicates support of it.
* プロキシがVAPIDメカニズム[RFC8292]をサポートする場合、プロキシは、REGISTER応答で「sip.vapid」機能機能インジケータを使用して、メカニズムのサポートを示す必要があります。インジケータ値には、プロキシを識別する公開鍵が含まれています。プロキシは、PNSプロバイダーがVAPIDメカニズムのサポートを示す前に、それがサポートされているかどうかを判断する必要があります。
* If the proxy received a 'sip.pnsreg' media feature tag in the REGISTER request, the proxy SHOULD insert a 'sip.pnsreg' feature-capability indicator with an indicator value bigger than 120 in the response, unless the proxy always wants to request that push notifications are sent to the UA in order to trigger the UA to send a binding-refresh REGISTER request.
* プロキシがREGISTERリクエストで「sip.pnsreg」メディア機能タグを受信した場合、プロキシは常にリクエストすることを望まない限り、応答に120より大きいインジケータ値を持つ「sip.pnsreg」機能機能インジケータを挿入する必要があります（SHOULD）。そのプッシュ通知はUAに送信され、UAがbinding-refresh REGISTER要求を送信するようトリガーします。
This section describes the SIP proxy procedures when a SIP UA queries about the push-notification support in the SIP network (Section 4.1.5).
このセクションでは、SIP UAがSIPネットワーク（セクション4.1.5）のプッシュ通知サポートについて問い合わせるときのSIPプロキシ手順について説明します。
The procedures in this section apply when the REGISTER request contains a 'pn-provider' SIP URI parameter, but does not contain a 'pn-prid' SIP URI parameter in the Contact header field URI of the REGISTER request.
このセクションの手順は、REGISTER要求に「pn-provider」SIP URIパラメータが含まれているが、REGISTER要求のContactヘッダーフィールドURIに「pn-prid」SIP URIパラメータが含まれていない場合に適用されます。
When a proxy receives a REGISTER request that contains a 'pn-provider' SIP URI parameter indicating the type of PNS supported by the UA, the proxy MUST perform the following actions:
プロキシが、UAがサポートするPNSのタイプを示す「pn-provider」SIP URIパラメータを含むREGISTERリクエストを受信すると、プロキシは次のアクションを実行する必要があります。
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 the REGISTER request before it forwards the request towards the registrar. This will inform any other proxies between the proxy and the registrar that the proxy supports the type of PNS supported by the UA.
o プロキシがUAでサポートされるPNSのタイプをサポートする場合、プロキシは、レジストラにリクエストを転送する前に、REGISTERリクエストでそのタイプのPNS（セクション5.4）のサポートを示す必要があります。これにより、プロキシがレジストラとの間の他のプロキシに、UAがサポートするPNSのタイプをプロキシがサポートすることが通知されます。
o If the proxy does not support the type of PNS supported by the UA, and if the REGISTER request contains Feature-Caps header fields indicating support of one or more types of PNSs, the proxy forwards the request towards the registrar.
o プロキシがUAでサポートされているPNSのタイプをサポートしておらず、REGISTERリクエストに1つ以上のタイプのPNSのサポートを示すFeature-Capsヘッダーフィールドが含まれている場合、プロキシはリクエストをレジストラに転送します。
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 fields indicating support of one or more types of PNSs, the proxy MUST either forward the request towards the registrar or send a SIP 555 (Push Notification Service Not Supported) response towards the UA. The proxy MUST NOT send a SIP 555 (Push Notification Service Not Supported) response unless it knows (by means of local configuration) that no other proxy supports any of the types of PNSs supported by the UA.
o プロキシがUAがサポートするPNSのタイプをサポートしておらず、REGISTERリクエストに1つ以上のタイプのPNSのサポートを示すFeature-Capsヘッダーフィールドが含まれていない場合、プロキシはリクエストをレジストラに転送するか送信する必要があります。 UAへのSIP 555（プッシュ通知サービスはサポートされていません）応答。プロキシは、UAがサポートするPNSの種類をサポートするプロキシが他にないことを（ローカル構成によって）知らない限り、SIP 555（プッシュ通知サービスはサポートされていません）応答を送信してはなりません（MUST NOT）。
When a proxy receives a REGISTER request, and the 'pn-provider' SIP URI parameter does not contain a parameter value, the proxy MUST indicate support of each type of PNS supported by the proxy before it forwards the request towards the registrar.
プロキシがREGISTER要求を受信し、「pn-provider」SIP URIパラメータにパラメータ値が含まれていない場合、プロキシは、要求をレジストラに転送する前に、プロキシでサポートされている各タイプのPNSのサポートを示す必要があります。
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 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 supports the VAPID mechanism for one or more types of PNSs, the proxy MUST indicate support of the mechanism for those PNSs in the response.
プロキシがREGISTER要求に対する2xx応答を受信したときに、プロキシがREGISTER要求で1つ以上のタイプのPNSのサポートを示している場合（上記を参照）、プロキシは応答で同じタイプのPNSのセットのサポートを示さなければなりません（MUST）。 。さらに、プロキシが1つ以上のタイプのPNSのVAPIDメカニズムをサポートする場合、プロキシは応答でそれらのPNSのメカニズムのサポートを示す必要があります。
The procedures in this section apply when a SIP proxy has indicated that it will request that push notifications are sent to the SIP UA.
このセクションの手順は、SIPプロキシがプッシュ通知をSIP UAに送信するよう要求することを示している場合に適用されます。
When the proxy receives a SIP request for a new dialog (e.g., a SIP INVITE request) or a standalone SIP request (e.g., a SIP MESSAGE request) addressed towards a SIP UA, if the Request-URI of the request contains a 'pn-provider', a 'pn-prid', and a 'pn-param' (if required for the specific PNS provider) SIP URI parameter, the proxy requests that a push notification be sent to the UA using the information in the 'pn-*' SIP URI parameters. The proxy then places the SIP request in the SIP Request Push Bucket. The push notification will trigger the UA to send a binding-refresh REGISTER request that the proxy will process as described in Section 5.6.1. In addition, the proxy MUST store the Contact URI of the REGISTER request during the lifetime of the REGISTER transaction.
プロキシが新しいダイアログのSIPリクエスト（SIP INVITEリクエストなど）またはスタンドアロンのSIPリクエスト（SIP MESSAGEリクエストなど）をSIP UA宛てに受信した場合、リクエストのRequest-URIに「pn -provider」、「pn-prid」、および「pn-param」（特定のPNSプロバイダーに必要な場合）SIP URIパラメータ。プロキシは、「pn」の情報を使用してプッシュ通知をUAに送信するように要求します。 -* 'SIP URIパラメータ。次に、プロキシはSIP要求をSIP要求プッシュバケットに配置します。プッシュ通知は、UAをトリガーして、セクション5.6.1で説明されているようにプロキシーが処理するbinding-refresh REGISTER要求を送信します。さらに、プロキシは、REGISTERトランザクションの存続期間中、REGISTERリクエストのContact URIを格納する必要があります。
NOTE: If the proxy receives a SIP request that does not contain the 'pn-*' SIP URI parameters listed above, the proxy processing of the request is based on local policy. If the proxy also serves requests for UAs that do not use the SIP push mechanism, the proxy can forward the request towards the UA. Otherwise, the proxy can reject the request.
注：上記の「pn-*」SIP URIパラメータを含まないSIPリクエストをプロキシが受信した場合、リクエストのプロキシ処理はローカルポリシーに基づいています。プロキシがSIPプッシュメカニズムを使用しないUAのリクエストも処理する場合、プロキシはリクエストをUAに転送できます。それ以外の場合、プロキシは要求を拒否できます。
When the proxy receives a 2xx response to the REGISTER request, the proxy performs the following actions:
プロキシーがREGISTER要求に対する2xx応答を受信すると、プロキシーは以下のアクションを実行します。
o The proxy processes the REGISTER response as described in Section 5.6.1.
o セクション5.6.1で説明されているように、プロキシはREGISTER応答を処理します。
o The proxy checks whether the SIP Request Push Bucket contains a SIP request associated with the REGISTER transaction by comparing (Section 5.3) the Contact header field URI in the REGISTER response with the Request-URIs of the SIP requests in the bucket. If there is a match, the proxy MUST remove the SIP request from the bucket and forward it towards the UA.
o プロキシは、REGISTER応答のContactヘッダーフィールドURIをバケット内のSIPリクエストのRequest-URIと比較することにより（Section 5.3）、SIPリクエストプッシュバケットにREGISTERトランザクションに関連付けられたSIPリクエストが含まれているかどうかをチェックします。一致がある場合、プロキシはバケットからSIPリクエストを削除し、UAに転送する必要があります。
The reason the proxy needs to wait for the REGISTER response before forwarding a SIP request towards a UA is to make sure that the REGISTER request has been accepted by the registrar, and that the UA that initiated the REGISTER request is authorized to receive messages for the Request-URI.
プロキシがREGISTER応答を待ってからUAにSIP要求を転送する必要がある理由は、REGISTER要求がレジストラによって受け入れられたこと、およびREGISTER要求を開始したUAがのメッセージの受信を許可されていることを確認するためです。リクエストURI。
If the proxy receives a non-2xx response to the REGISTER request, the proxy compares the Contact URI stored from the REGISTER request (see above) with the Request-URIs of the SIP requests in the SIP Request Push Bucket. If there is a match, the proxy SHOULD remove the associated request from the bucket and send an error response to the request. It is RECOMMENDED that the proxy sends either a 404 (Not Found) response or a 480 (Temporarily Unavailable) response to the SIP request, but other response codes can be used as well. However, if the REGISTER response is expected to trigger a new REGISTER request from the UA (e.g., if the registrar is requesting the UA to perform authentication), the proxy MAY keep the SIP request in the bucket.
プロキシがREGISTERリクエストに対して2xx以外の応答を受信した場合、プロキシは、REGISTERリクエストから格納されたContact URI（上記を参照）をSIPリクエストプッシュバケット内のSIPリクエストのRequest-URIと比較します。一致がある場合、プロキシは関連付けられたリクエストをバケットから削除し、リクエストにエラー応答を送信する必要があります（SHOULD）。プロキシが404（Not Found）応答または480（Temporarily Unavailable）応答をSIPリクエストに送信することをお勧めしますが、他の応答コードも使用できます。ただし、REGISTER応答がUAからの新しいREGISTERリクエストをトリガーすると予想される場合（たとえば、レジストラがUAに認証の実行を要求している場合）、プロキシはSIPリクエストをバケット内に保持してもよい（MAY）。
If the push notification request fails (see PNS-specific documentation for details), the proxy MUST remove the SIP request from the bucket and send an error response to the SIP request. It is RECOMMENDED that the proxy sends either a 404 (Not Found) response or a 480 (Temporarily Unavailable) response, but other response codes can be used as well.
プッシュ通知要求が失敗した場合（詳細はPNS固有のドキュメントを参照）、プロキシはバケットからSIP要求を削除し、SIP要求にエラー応答を送信する必要があります。プロキシが404（Not Found）応答または480（Temporarily Unavailable）応答を送信することをお勧めしますが、他の応答コードも使用できます。
After the proxy has requested that a push notification be sent to a UA, if the proxy does not receive a REGISTER response with a Contact URI that matches the Request-URI of the SIP request before the Bucket Timer (Section 5.2) associated with the SIP request times out, the proxy MUST remove the SIP request from the SIP Request Push Bucket (Section 5.2) and send a 480 (Temporarily Unavailable) response. The Bucket Timer time-out value is set based on local policy, taking the guidelines below into consideration.
プロキシがプッシュ通知のUAへの送信を要求した後、プロキシがSIPに関連付けられたバケットタイマー（セクション5.2）の前にSIPリクエストのリクエストURIと一致するコンタクトURIを持つREGISTER応答を受信しない場合リクエストがタイムアウトした場合、プロキシはSIPリクエストプッシュバケット（セクション5.2）からSIPリクエストを削除し、480（一時的に利用不可）レスポンスを送信する必要があります。バケットタイマーのタイムアウト値は、以下のガイドラインを考慮して、ローカルポリシーに基づいて設定されます。
As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must complete immediately or risk losing a race, which results in stress on intermediaries and state misalignment at the endpoints. The mechanism defined in this document inherently delays the final response to any non-INVITE request that requires a push notification. In particular, if the proxy forwards the SIP request towards the SIP UA, the SIP UA accepts the request, but the transaction times out at the sender before it receives the successful response, this will cause state misalignment between the endpoints (the sender considers the transaction a failure, while the receiver considers the transaction a success). The SIP proxy needs to take this into account when it sets the value of the Bucket Timer associated with the transaction, to make sure that the error response (triggered by a Bucket Timer time out) reaches the sender before the transaction times out. If the accumulated delay of this mechanism combined with any other mechanisms in the path of processing the non-INVITE transaction cannot be kept short, this mechanism should not be used. For networks encountering such conditions, an alternative (left for possible future work) would be for the proxy to immediately return a new error code meaning "wait at least the number of seconds specified in this response and retry your request" before initiating the push notification.
[RFC4320]と[RFC4321]で説明されているように、INVITE以外のトランザクションはすぐに完了する必要があるか、競合を失うリスクがあるため、仲介者にストレスがかかり、エンドポイントでの状態の不整合が生じます。このドキュメントで定義されているメカニズムは、本質的に、プッシュ通知を必要とするINVITE以外の要求への最終応答を遅らせます。特に、プロキシがSIPリクエストをSIP UAに転送する場合、SIP UAはリクエストを受け入れますが、トランザクションが正常な応答を受信する前に送信者でタイムアウトすると、エンドポイント間で状態の不整合が発生します（送信者はトランザクションは失敗しますが、受信側はトランザクションを成功と見なします）。 SIPプロキシは、トランザクションに関連付けられたバケットタイマーの値を設定するときにこれを考慮に入れて、トランザクションがタイムアウトする前にエラー応答（バケットタイマーのタイムアウトによってトリガーされる）が送信者に届くようにします。このメカニズムの累積遅延が、非INVITEトランザクションの処理パス内の他のメカニズムと組み合わされて短く保てない場合は、このメカニズムを使用しないでください。このような状況に遭遇したネットワークの場合、代替案（可能な将来の作業のために残されています）は、プッシュ通知を開始する前に、プロキシが「少なくともこの応答で指定された秒数待機してリクエストを再試行する」ことを意味する新しいエラーコードをすぐに返すことです。
NOTE: While the work on this document was ongoing, implementation test results showed that the time it takes for a proxy to receive the REGISTER request, from when the proxy has requested a push notification, is typically around 2 seconds. However, the time might vary depending on the characteristics and load of the SIP network and the PNS.
注：このドキュメントの作業は進行中ですが、実装テストの結果、プロキシがREGISTERリクエストを受信するまでの時間は、プロキシがプッシュ通知をリクエストしてから通常2秒程度であることがわかりました。ただし、時間はSIPネットワークとPNSの特性と負荷によって異なる場合があります。
In addition to the procedures described above, there are two cases where a proxy, as an optimization, can forward a SIP request towards a UA without either waiting for a 2xx response to a REGISTER request or requesting that a push notification be sent to the UA:
上記の手順に加えて、プロキシは、最適化として、REGISTER要求への2xx応答を待つことなく、またはUAにプッシュ通知を送信するように要求することなく、UAにSIP要求を転送できる2つのケースがあります。 ：
o If the proxy is able to authenticate the sender of the REGISTER request and verify that it is allowed by authorization policy, the proxy does not need to wait for the 2xx response before it forwards the SIP request towards the UA. In such cases, the proxy will use the Contact URI of the REGISTER request when comparing it against the Request-URIs of the SIP requests in the SIP Request Push Bucket.
o プロキシーがREGISTER要求の送信者を認証し、それが許可ポリシーによって許可されていることを確認できる場合、プロキシーはSIP要求をUAに転送する前に2xx応答を待つ必要はありません。そのような場合、プロキシは、SIPリクエストプッシュバケット内のSIPリクエストのリクエストURIと比較するときに、REGISTERリクエストの連絡先URIを使用します。
o If the proxy has knowledge that the UA is awake, and that the UA is able to receive the SIP request without first sending a binding-refresh REGISTER request, the proxy does not need to request that a push notification be sent to the UA (the UA will not send a binding-refresh REGISTER request) before it forwards the SIP request towards the UA. The mechanisms for getting such knowledge might be dependent on implementation or deployment architecture, and are outside the scope of this document.
o プロキシが、UAが起動していて、UAが最初にbinding-refresh REGISTER要求を送信せずにSIP要求を受信できることを知っている場合、プロキシはプッシュ通知をUAに送信するように要求する必要はありません（ UAは、SIP要求をUAに転送する前に、バインディングリフレッシュREGISTER要求を送信しません。そのような知識を得るためのメカニズムは、実装または展開アーキテクチャに依存する可能性があり、このドキュメントの範囲外です。
Some PNS providers allow payload in the push notifications. This specification does not define usage of such payload (in addition to any payload that might be required by the PNS itself).
一部のPNSプロバイダーは、プッシュ通知でペイロードを許可します。この仕様では、このようなペイロードの使用法を定義していません（PNS自体が必要とする可能性があるペイロードに加えて）。
Some SIP dialogs might have a long lifetime with little activity. For example, when the SIP event notification mechanism [RFC6665] is used, there might be a long period between the sending of mid-dialog requests. Because of this, a SIP UA may be suspended and may need to be awakened in order to be able to receive mid-dialog requests.
一部のSIPダイアログは、アクティビティがほとんどなく、寿命が長い場合があります。たとえば、SIPイベント通知メカニズム[RFC6665]が使用されている場合、ダイアログの途中の要求の送信の間隔が長い可能性があります。このため、SIP UAが一時停止されている可能性があり、ダイアログの途中の要求を受信できるようにするために、ウェイクアップする必要があります。
SIP requests for a new dialog and standalone SIP requests addressed towards a UA with 'pn-*' SIP URI parameters allow the proxy to request that a push notification be sent to the UA (Section 5.6.2). However, 'pn-*' SIP URI parameters will not be present in mid-dialog requests addressed towards the UA. Instead, the proxy needs to support a mechanism to store the information needed to request that a push notification be sent to the UA, and to be able to retrieve that information when it receives a mid-dialog request addressed towards the UA. This section defines such a mechanism. The SIP UA and SIP proxy procedures in this section are applied in addition to the generic procedures defined in this specification.
新しいダイアログのSIPリクエストと「pn-*」SIP URIパラメータを使用してUAに向けられたスタンドアロンのSIPリクエストにより、プロキシはプッシュ通知のUAへの送信をリクエストできます（5.6.2項）。ただし、「pn-*」SIP URIパラメータは、UAに向けられたダイアログ中のリクエストには存在しません。代わりに、プロキシは、プッシュ通知をUAに送信することを要求するために必要な情報を格納するメカニズムをサポートし、UAに向けられたダイアログ中の要求を受信したときにその情報を取得できる必要があります。このセクションでは、そのようなメカニズムを定義します。このセクションのSIP UAおよびSIPプロキシ手順は、この仕様で定義されている一般的な手順に加えて適用されます。
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| PNS Register | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | +-----------------------+ |
| | | Store PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK (PURR) | |
|<===================================| |
| | | |
| | | |
| SIP INVITE (PURR) | |
|===================================>| |
| | |SIP INVITE (PURR) |
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | |
| | | |
| | |SIP UPDATE (PURR) |
| | |<==================|
| | | |
| | +-----------------------+ |
| | | Fetch PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK (PURR) | |
|<===================================| |
| | | |
| SIP UPDATE | | |
|<===================================| |
| | | |
------- Push Notification API
======= SIP
Figure 4: SIP Push Long-Lived Dialog Flow
図4：SIPプッシュの長期ダイアログフロー
If the UA is willing to receive push notifications when a proxy receives a mid-dialog request addressed towards the UA, the UA MUST insert a 'pn-purr' SIP URI parameter (Section 6.2.1) in the Contact header field URI of the initial request for a dialog or the 2xx response to such requests. The UA MUST insert a parameter value identical to the last 'sip.pnspurr' feature-capability indicator (Section 6.2.1) that it received in a REGISTER response. If the UA has not received a 'sip.pnspurr' feature-capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI parameter in a request or response.
プロキシがUAに向けられたダイアログ中のリクエストを受信したときにUAがプッシュ通知を受信する場合、UAは 'pn-purr' SIP URIパラメータ（セクション6.2.1）をダイアログの最初の要求、またはそのような要求に対する2xx応答。 UAは、REGISTER応答で受信した最後の「sip.pnspurr」機能機能インジケーター（セクション6.2.1）と同一のパラメーター値を挿入する必要があります。 UAが「sip.pnspurr」機能機能インジケータを受信していない場合、UAは要求または応答に「pn-purr」SIP URIパラメータを挿入してはなりません（MUST NOT）。
The UA makes the decision to receive push notifications triggered by incoming mid-dialog requests based on local policy. Such policy might be based on the type of SIP dialog, the type of media (if any) negotiated for the dialog [RFC3264], etc.
UAは、ローカルポリシーに基づいて、着信するダイアログ中の要求によってトリガーされるプッシュ通知を受信することを決定します。そのようなポリシーは、SIPダイアログのタイプ、ダイアログ[RFC3264]についてネゴシエートされたメディア（存在する場合）のタイプなどに基づく可能性があります。
NOTE: As the 'pn-purr' SIP URI parameter only applies to a given dialog, the UA needs to insert a 'pn-purr' parameter in the Contact header field URI of the request or response for each dialog in which the UA is willing to receive push notifications triggered by incoming mid-dialog requests.
注：「pn-purr」SIP URIパラメータは特定のダイアログにのみ適用されるため、UAは、UAが存在する各ダイアログの要求または応答のContactヘッダーフィールドURIに「pn-purr」パラメータを挿入する必要があります。着信ダイアログ中のリクエストによってトリガーされたプッシュ通知を喜んで受信します。
If the proxy supports requesting push notifications triggered by mid-dialog requests being sent to the registered UA, the proxy MUST store the information (the 'pn-*' SIP URI parameters) needed to request that push notifications are sent to the UA when a proxy receives an initial REGISTER request for a binding from the UA. In addition, the proxy MUST generate a unique (within the context of the proxy) value, referred to as the PURR (Proxy Unique Registration Reference), that can be used as a key to retrieve the information.
プロキシが、登録済みのUAに送信されるダイアログ中の要求によってトリガーされるプッシュ通知の要求をサポートしている場合、プロキシは、プッシュ通知がUAに送信されることを要求するために必要な情報（ 'pn- *' SIP URIパラメーター）を格納する必要があります。プロキシは、UAからバインディングの最初のREGISTER要求を受け取ります。さらに、プロキシは、情報を取得するためのキーとして使用できる、PURR（プロキシユニーク登録参照）と呼ばれる（プロキシのコンテキスト内で）一意の値を生成する必要があります。
In order to prevent client fingerprinting, the proxy MUST periodically generate a new PURR value (even if 'pn-*'parameters did not change). However, as long as there are ongoing dialogs associated with the old value, the proxy MUST store it so that it can request that push notifications are sent to the UA when it receives a mid-dialog request addressed towards the UA. In addition, the PURR value MUST be generated in such a way so that it is unforgeable, anonymous, and unlinkable to entities other than the proxy. It must not be possible for an attacker to generate a valid PURR, to associate a PURR with a specific user, or to determine when two PURRs correspond to the same user. It can be generated, e.g., by utilizing a cryptographically secure random function with an appropriately large output size.
クライアントのフィンガープリントを防ぐために、プロキシは定期的に新しいPURR値を生成する必要があります（ 'pn- *'パラメータが変更されていない場合でも）。ただし、古い値に関連付けられている進行中のダイアログがある限り、プロキシは、UAに向けられたダイアログ中の要求を受け取ったときにプッシュ通知がUAに送信されるように要求できるように、それを保存する必要があります。さらに、PURR値は、偽造不可、匿名、プロキシ以外のエンティティにリンクできないように生成する必要があります。攻撃者が有効なPURRを生成したり、PURRを特定のユーザーに関連付けたり、2つのPURRが同じユーザーにいつ対応するかを判断したりすることはできません。これは、例えば、適切に大きな出力サイズで暗号的に安全なランダム関数を利用することによって生成できます。
Whenever the proxy receives a 2xx response to a REGISTER request, the proxy MUST insert a 'sip.pnspurr' feature-capability indicator with the latest PURR value (see above) in the response.
プロキシーがREGISTER要求への2xx応答を受信するときはいつでも、プロキシーは最新のPURR値（上記を参照）を持つ「sip.pnspurr」機能機能標識を応答に挿入しなければなりません（MUST）。
When a proxy receives an initial request for a dialog from a UA that contains a 'pn-purr' SIP URI parameter in the Contact header field URI with a PURR value that the proxy has generated (Section 6.2.1), the proxy MUST add a Record-Route header to the request to insert itself in the dialog route [RFC3261] before forwarding the request.
プロキシが生成したPURR値を持つコンタクトヘッダーフィールドURIに「pn-purr」SIP URIパラメータを含むUAからダイアログの初期リクエストを受信すると（セクション6.2.1）、プロキシは追加する必要があります。リクエストへのRecord-Routeヘッダー。リクエストを転送する前に、ダイアログルート[RFC3261]にそれ自体を挿入します。
When the proxy receives an initial request for a dialog addressed towards the UA, and the proxy has generated a PURR value associated with the 'pn-*' parameters inserted in the SIP URI of the request (Section 6.2.2), the proxy MUST add a Record-Route header to the request to insert itself in the dialog route [RFC3261] before forwarding the request.
プロキシがUAに向けられたダイアログの最初のリクエストを受信し、プロキシがリクエストのSIP URIに挿入された「pn- *」パラメータに関連付けられたPURR値を生成した場合（セクション6.2.2）、プロキシはRecord-Routeヘッダーをリクエストに追加して、リクエストを転送する前にダイアログルート[RFC3261]に自分自身を挿入します。
When the proxy receives a mid-dialog SIP request addressed towards the UA that contains a 'pn-purr' SIP URI parameter, and the proxy is able to retrieve the stored information needed to request that a push notification be sent to the UA (Section 6.2.1), the proxy MUST place the SIP request in the SIP Request Push Bucket and request that a push notification be sent to the UA.
プロキシが「pn-purr」SIP URIパラメータを含むUA宛てのダイアログ中SIPリクエストを受信すると、プロキシは、プッシュ通知をUAに送信するようリクエストするために必要な保存情報を取得できます（セクション6.2.1）、プロキシはSIPリクエストをSIPリクエストプッシュバケットに配置し、プッシュ通知がUAに送信されるようにリクエストする必要があります。
NOTE: The 'pn-purr' SIP URI parameter will either be carried in the Request-URI or in a Route header field [RFC3261] of the SIP request depending on how the route set [RFC3261] of the mid-dialog SIP request has been constructed.
注：「pn-purr」SIP URIパラメータは、ダイアログの途中のSIPリクエストのルートセット[RFC3261]の設定に応じて、SIPリクエストのリクエストURIまたはルートヘッダーフィールド[RFC3261]に含まれます。建設されました。
When the proxy receives a 2xx response to a REGISTER request, the proxy checks whether the SIP Request Push Bucket contains a mid-dialog SIP request associated with the REGISTER transaction. If the bucket contains such a request, the proxy MUST remove the SIP request from the SIP Request Push Bucket and forward it towards the UA.
プロキシは、REGISTER要求に対する2xx応答を受信すると、SIP要求プッシュバケットに、REGISTERトランザクションに関連付けられたダイアログ中のSIP要求が含まれているかどうかを確認します。バケットにそのような要求が含まれている場合、プロキシはSIP要求をSIP要求プッシュバケットから削除し、それをUAに転送する必要があります。
Note that the proxy does not perform a URI comparison (Section 5.3) when processing mid-dialog requests, as a mid-dialog request will not contain the 'pn-prid', 'pn-provider', and 'pn-param' SIP URI parameters. The proxy only checks for a mid-dialog request that contains the PURR value associated with the REGISTER 2xx response.
中間ダイアログ要求には「pn-prid」、「pn-provider」、および「pn-param」SIPが含まれないため、プロキシは中間ダイアログ要求を処理するときにURI比較（5.3節）を実行しないことに注意してください。 URIパラメータ。プロキシは、REGISTER 2xx応答に関連付けられたPURR値を含むダイアログ中のリクエストのみをチェックします。
As described in Section 5.6.2, while waiting for the push notification request to succeed, and then for the associated REGISTER request and 2xx response, the proxy needs to take into consideration that the transaction associated with the mid-dialog request will eventually time out at the sender of the request (User Agent Client), and the sender will consider the transaction a failure.
セクション5.6.2で説明されているように、プッシュ通知要求が成功するのを待っている間に、関連するREGISTER要求と2xx応答を待つ間、プロキシはダイアログ中の要求に関連するトランザクションが最終的にタイムアウトすることを考慮する必要がありますリクエストの送信者（ユーザーエージェントクライアント）では、送信者はトランザクションを失敗と見なします。
When a proxy sends an error response to a mid-dialog request (e.g., due to a transaction time out), the proxy SHOULD select a response code that only impacts the transaction associated with the request [RFC5079].
プロキシがダイアログの途中の要求にエラー応答を送信する場合（トランザクションのタイムアウトなどが原因）、プロキシは、要求に関連付けられたトランザクションにのみ影響を与える応答コードを選択する必要があります[RFC5079]。
[RFC3891] defines a mechanism that allows a SIP UA to replace a dialog with another dialog. A UA that wants to replace a dialog with another one will send an initial request for the new dialog. The Request-URI of the request will contain the Contact header field URI of the peer.
[RFC3891]は、SIP UAがダイアログを別のダイアログに置き換えることを可能にするメカニズムを定義します。ダイアログを別のダイアログに置き換えたいUAは、新しいダイアログの初期リクエストを送信します。リクエストのRequest-URIには、ピアのContactヘッダーフィールドURIが含まれます。
If a SIP proxy wants to be able to request that a push notification be sent to a UA when it receives an initial request for a dialog that replaces an existing dialog, using the mechanism in [RFC3891], the proxy and the UA MUST perform the following actions:
[RFC3891]のメカニズムを使用して、SIPプロキシが既存のダイアログを置き換えるダイアログの最初のリクエストを受信したときにプッシュ通知をUAに送信するようリクエストできるようにしたい場合、プロキシとUAは次のアクション：
o The proxy MUST provide a PURR to the UA during registration (Section 6.2.1).
o プロキシは、登録中にPURRをUAに提供する必要があります（セクション6.2.1）。
o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact header field URI of either the initial request for a dialog or a 2xx response to such requests (Section 6.1.1). This includes dialogs replacing other dialogs, as those dialogs might also get replaced.
o UAは、「pn-purr」SIP URIパラメータを、ダイアログの最初の要求またはそのような要求への2xx応答（セクション6.1.1）の連絡先ヘッダーフィールドURIに挿入する必要があります（MUST）。これには、他のダイアログを置き換えるダイアログも含まれます。これらのダイアログも置き換えられる可能性があるためです。
o The proxy MUST apply the mechanism defined in Section 6.2.3 to place and retrieve the request from the SIP Request Push Bucket.
o プロキシは、セクション6.2.3で定義されたメカニズムを適用して、SIPリクエストプッシュバケットからリクエストを配置および取得する必要があります。
In addition, the operator needs to make sure that the initial request for dialogs, addressed towards the UA using the contact of the replaced dialog, will be routed to the SIP proxy (in order to request that a push notification be sent to the UA). The procedures for doing that are operator-specific and are outside the scope of this specification.
さらに、オペレーターは、置き換えられたダイアログの連絡先を使用してUAに向けられたダイアログの最初の要求がSIPプロキシにルーティングされることを確認する必要があります（プッシュ通知がUAに送信されるように要求するため） 。そのための手順はオペレーター固有であり、この仕様の範囲外です。
The 555 response code is added to the "Server-Error" Status-Code definition. 555 (Push Notification Service Not Supported) is used to indicate that the server does not support the push notification service identified in a 'pn-provider' SIP URI parameter.
555応答コードが "Server-Error"ステータスコード定義に追加されます。 555（プッシュ通知サービスはサポートされていません）は、サーバーが 'pn-provider' SIP URIパラメーターで識別されたプッシュ通知サービスをサポートしていないことを示すために使用されます。
The use of the SIP 555 response code is only defined for SIP REGISTER responses.
SIP 555応答コードの使用は、SIP REGISTER応答に対してのみ定義されています。
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 a REGISTER request, indicates that the entity associated with the indicator supports the SIP push mechanism and the type of push notification service indicated by the indicator value. The values defined for the 'pn-provider' SIP URI parameter are used as indicator values.
sip.pns機能能力インジケーターは、SIP REGISTER要求のFeature-CapsヘッダーフィールドまたはREGISTER要求に対するSIP 2xx応答に挿入されると、インジケーターに関連付けられたエンティティがSIPプッシュメカニズムと指標値で示されるプッシュ通知サービス。 「pn-provider」SIP URIパラメータに定義された値は、インジケータ値として使用されます。
pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT pns = tag-value
pns-fc = "+ sip.pns" EQUAL LDQUOT pns RDQUOT pns = tag-value
tag-value = <tag-value defined in [RFC3840]>
The sip.vapid feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator supports the Voluntary Application Server Identification (VAPID) [RFC8292] mechanism when the entity requests that a push notification be sent to a SIP UA. The indicator value is a public key identifying the entity that can be used by a SIP UA to restrict subscriptions to that entity.
sip.vapid機能機能インジケーターは、SIP REGISTER要求へのSIP 2xx応答に挿入されると、エンティティーがプッシュを要求したときに、インジケーターに関連付けられたエンティティが自発的アプリケーションサーバー識別（VAPID）[RFC8292]メカニズムをサポートすることを示します。通知はSIP UAに送信されます。インジケータ値は、エンティティへのサブスクリプションを制限するためにSIP UAで使用できるエンティティを識別する公開キーです。
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid = tag-value
vapid-fc = "+ sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid = tag-value
tag-value = <tag-value defined in [RFC3840]>
The sip.pnsreg feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator expects to receive binding-refresh REGISTER requests from the SIP UA associated with the binding before the binding expires, even if the entity does not request that a push notification be sent to the SIP UA in order to trigger the binding-refresh REGISTER requests. The indicator value conveys the minimum time (given in seconds) prior to the binding expiration when the UA MUST send the REGISTER request.
sip.pnsreg機能機能インジケーターは、SIP REGISTER要求へのSIP 2xx応答に挿入されると、インジケーターに関連付けられたエンティティが、バインディングの有効期限が切れる前にバインディングに関連付けられたSIP UAからbinding-refresh REGISTER要求を受信することを期待していることを示します。エンティティが、バインディング更新REGISTER要求をトリガーするためにプッシュ通知をSIP UAに送信するように要求していない場合でも。インジケータ値は、UAがREGISTERリクエストを送信しなければならないときに、バインディングの有効期限が切れるまでの最小時間（秒単位）を伝えます。
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT
DIGIT = <DIGIT defined in [RFC3261]>
The sip.pnsreg media feature tag, when inserted in the Contact header field of a SIP REGISTER request, indicates that the SIP UA associated with the tag is able to send binding-refresh REGISTER requests for the associated binding without being awakened by push notifications. The media feature tag has no values.
sip.pnsregメディア機能タグは、SIP REGISTERリクエストのContactヘッダーフィールドに挿入されると、タグに関連付けられたSIP UAが、プッシュ通知によって起こされることなく、関連付けられたバインディングのbinding-refresh REGISTERリクエストを送信できることを示します。メディア機能タグには値がありません。
pnsreg-mt = "+sip.pnsreg"
pnsreg-mt = "+ sip.pnsreg"
The sip.pnspurr feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator will store information that can be used to associate a mid-dialog SIP request with the binding information in the REGISTER request.
sip.pnspurr機能機能インジケーターは、SIP REGISTER要求へのSIP 2xx応答に挿入されると、インジケーターに関連付けられたエンティティが、中間ダイアログSIP要求をバインディング情報に関連付けるために使用できる情報を格納することを示します。 REGISTERリクエスト。
pnspurr-fc = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT pnspurr = tag-value
pnspurr-fc = "+ sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT pnspurr = tag-value
tag-value = <tag-value defined in [RFC3840]>
This section defines new SIP URI parameters by extending the grammar for "uri-parameter" as defined in [RFC3261]. The ABNF [RFC5234] is as follows:
このセクションは、[RFC3261]で定義されている「uri-parameter」の文法を拡張することにより、新しいSIP URIパラメータを定義します。 ABNF [RFC5234]は次のとおりです。
uri-parameter =/ pn-provider / pn-param / pn-prid / pn-purr
pn-provider = "pn-provider" [EQUAL pvalue]
pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue
pn-purr = "pn-purr" EQUAL pvalue
pvalue = <pvalue defined in [RFC3261]>
EQUAL = <EQUAL defined in [RFC3261]>
The format and semantics of pn-prid and pn-param are specific to the pn-provider value.
pn-pridとpn-paramの形式とセマンティクスは、pn-providerの値に固有です。
Parameter value characters that are not part of pvalue need to be escaped, as defined in RFC 3261.
RFC 3261で定義されているように、pvalueの一部ではないパラメーター値文字はエスケープする必要があります。
When a new value is registered to the PNS subregistry, a reference to a specification that describes the usage of the PNS associated with the value is provided. That specification MUST contain the following information:
新しい値がPNSサブレジストリに登録されると、その値に関連付けられたPNSの使用法を説明する仕様への参照が提供されます。その仕様には、次の情報が含まれている必要があります。
o The value of the 'pn-provider' SIP URI parameter.
o 「pn-provider」SIP URIパラメータの値。
o How the 'pn-prid' SIP URI parameter value is retrieved and set by the SIP UA.
o 「pn-prid」SIP URIパラメータ値がSIP UAによって取得および設定される方法。
o How the 'pn-param' SIP URI parameter (if required for the specific PNS provider) value is retrieved and set by the SIP UA.
o 'pn-param' SIP URIパラメーター（特定のPNSプロバイダーに必要な場合）の値がSIP UAによって取得および設定される方法。
10. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Apple Push Notification service
10. Appleプッシュ通知サービスの「pn-provider」、「pn-param」、および「pn-prid」URIパラメータ
When the Apple Push Notification service (APNs) is used, the PNS-related SIP URI parameters are set as described below.
Appleプッシュ通知サービス（APN）を使用する場合、PNS関連のSIP URIパラメータは次のように設定されます。
For detailed information about the parameter values, see <https://developer.apple.com/library/archive/documentation/ NetworkingInternet/Conceptual/RemoteNotificationsPG/ CommunicatingwithAPNs.html> [pns-apns].
パラメータ値の詳細については、<https://developer.apple.com/library/archive/documentation/ NetworkingInternet / Conceptual / RemoteNotificationsPG / CommunicatingwithAPNs.html> [pns-apns]を参照してください。
The value of the 'pn-provider' URI parameter is "apns".
「pn-provider」URIパラメータの値は「apns」です。
Example: pn-provider=apns
例：pn-provider = apns
The value of the 'pn-param' URI parameter is a string that is composed of two values separated by a period (.): Team ID and Topic. The Team ID is provided by Apple and is unique to a development team. The Topic consists of the Bundle ID, which uniquely identifies an application, and a service value that identifies a service associated with the application, separated by a period (.). For Voice over IP (VoIP) applications, the service value is "voip".
'pn-param' URIパラメーターの値は、ピリオド（。）で区切られた2つの値（チームIDとトピック）で構成される文字列です。チームIDはAppleによって提供され、開発チームに固有のものです。トピックは、アプリケーションを一意に識別するバンドルIDと、アプリケーションに関連付けられたサービスを識別するサービス値で構成され、ピリオド（。）で区切られます。 Voice over IP（VoIP）アプリケーションの場合、サービス値は「voip」です。
Example: pn-param=DEF123GHIJ.com.example.yourexampleapp.voip NOTE: The Bundle ID might contain one or more periods (.). Hence, within the 'pn-param' value, the first period will be separating the Team ID from the Topic, and within the Topic, the last period will be separating the Bundle ID from the service.
例：pn-param = DEF123GHIJ.com.example.yourexampleapp.voip注：バンドルIDには、1つ以上のピリオド（。）が含まれる場合があります。したがって、「pn-param」値内では、最初の期間はチームIDをトピックから分離し、トピック内の最後の期間はバンドルIDをサービスから分離します。
The value of the 'pn-prid' URI parameter is the device token, which is a unique identifier assigned by Apple to a specific app on a specific device.
「pn-prid」URIパラメーターの値は、デバイストークンです。これは、アップルが特定のデバイス上の特定のアプリに割り当てた一意の識別子です。
Example: pn-prid=00fc13adff78512
例：pn-prid = 00fc13adff78512
11. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Google Firebase Cloud Messaging (FCM) Push Notification Service
11. Google Firebase Cloud Messaging（FCM）プッシュ通知サービスの「pn-provider」、「pn-param」、および「pn-prid」URIパラメータ
When Firebase Cloud Messaging (FCM) is used, the PNS-related URI parameters are set as described below.
Firebase Cloud Messaging（FCM）を使用する場合、PNS関連のURIパラメータは以下のように設定されます。
For detailed information about the parameter values, see <https://firebase.google.com/docs/cloud-messaging/concept-options> [pns-fcm].
パラメータ値の詳細については、<https://firebase.google.com/docs/cloud-messaging/concept-options> [pns-fcm]をご覧ください。
The value of the 'pn-provider' URI parameter is "fcm".
「pn-provider」URIパラメータの値は「fcm」です。
The value of the 'pn-param' URI parameter is the Project ID.
「pn-param」URIパラメータの値はプロジェクトIDです。
The value of the 'pn-prid' URI parameter is the Registration token, which is generated by the FCM SDK for each client app instance.
「pn-prid」URIパラメーターの値は、各クライアントアプリインスタンスのFCM SDKによって生成される登録トークンです。
12. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for RFC 8030 (Generic Event Delivery Using HTTP Push)
12. RFC 8030（HTTPプッシュを使用した一般的なイベント配信）の「pn-provider」、「pn-param」、および「pn-prid」URIパラメータ
When Generic Event Delivery Using HTTP Push is used, the PNS-related URI parameters are set as described below.
HTTPプッシュを使用した汎用イベント配信を使用する場合、PNS関連のURIパラメーターは以下のように設定されます。
The value of the 'pn-provider' URI parameter is "webpush".
「pn-provider」URIパラメータの値は「webpush」です。
The value of the 'pn-param' URI parameter MUST NOT be used.
'pn-param' URIパラメータの値は使用してはなりません（MUST NOT）。
The value of the 'pn-prid' URI parameter is the push subscription URI.
「pn-prid」URIパラメーターの値は、プッシュサブスクリプションURIです。
See RFC 8030 [RFC8030] for more details.
詳細については、RFC 8030 [RFC8030]を参照してください。
Note that encryption for web push [RFC8291] is not used; therefore, parameters for message encryption are not defined in this specification. Web push permits the sending of a push message without a payload without encryption.
Webプッシュの暗号化[RFC8291]は使用されないことに注意してください。したがって、メッセージ暗号化のパラメータは、この仕様では定義されていません。 Webプッシュでは、暗号化なしのペイロードなしでプッシュメッセージを送信できます。
The security considerations for the use and operation of any particular PNS (e.g., how users and devices are authenticated and authorized) are out of scope for this document. [RFC8030] documents the security considerations for the PNS defined in that specification. Security considerations for other PNSs are left to their respective specifications.
特定のPNSの使用と操作に関するセキュリティの考慮事項（たとえば、ユーザーとデバイスの認証と承認の方法）は、このドキュメントの範囲外です。 [RFC8030]は、その仕様で定義されているPNSのセキュリティに関する考慮事項を文書化しています。他のPNSのセキュリティに関する考慮事項は、それぞれの仕様に任されています。
Typically, the PNS requires the SIP proxy requesting push notifications to be authenticated and authorized by the PNS. In some cases, the PNS also requires the SIP application (or the SIP application developer) to be identified in order for the application to request push notifications. Unless the PNS authenticates and authorizes the PNS, a malicious endpoint or network entity that managed to get access to the parameters transported in the SIP signaling might be able to request that push notifications are sent to a UA. Such push notifications will impact the battery life of the UA and trigger unnecessary SIP traffic.
通常、PNSでは、プッシュ通知を要求するSIPプロキシがPNSによって認証および承認される必要があります。場合によっては、アプリケーションがプッシュ通知を要求するために、PNSでSIPアプリケーション（またはSIPアプリケーション開発者）を識別する必要もあります。 PNSがPNSを認証および承認しない限り、SIPシグナリングで転送されたパラメーターにアクセスできた悪意のあるエンドポイントまたはネットワークエンティティは、プッシュ通知がUAに送信されることを要求できる可能性があります。このようなプッシュ通知は、UAのバッテリー寿命に影響を与え、不要なSIPトラフィックをトリガーします。
[RFC8292] defines a mechanism that allows a proxy to identify itself to a PNS by signing a JSON Web Token (JWT) sent to the PNS using a key pair. The public key serves as an identifier of the proxy and can be used by devices to restrict push notifications to the proxy associated with the key.
[RFC8292]は、キーペアを使用してPNSに送信されたJSON Web Token（JWT）に署名することで、プロキシがPNSに対してそれ自体を識別できるようにするメカニズムを定義します。公開キーはプロキシの識別子として機能し、デバイスがキーに関連付けられたプロキシへのプッシュ通知を制限するために使用できます。
Operators MUST ensure that the SIP signaling is properly secured, e.g., using encryption, from malicious network entities. TLS MUST be used unless the operators know that the signaling is secured using some other mechanism that provides strong crypto properties.
通信事業者は、悪意のあるネットワークエンティティからのSIPシグナリングが、たとえば暗号化を使用して適切に保護されていることを確認する必要があります。オペレーターは、強力な暗号化プロパティを提供する他の何らかのメカニズムを使用してシグナリングが保護されていることをオペレーターが認識していない限り、TLSを使用する必要があります。
In addition to the information that needs to be exchanged between a device and the PNS in order to establish a push notification subscription, the mechanism defined in this document does not require any additional information to be exchanged between the device and the PNS.
プッシュ通知サブスクリプションを確立するためにデバイスとPNSの間で交換する必要がある情報に加えて、このドキュメントで定義されているメカニズムは、デバイスとPNSの間で交換される追加の情報を必要としません。
The mechanism defined in this document does not require a proxy to insert any payload (in addition to possible payload used for the PNS itself) when requesting push notifications.
このドキュメントで定義されているメカニズムでは、プッシュ通知を要求するときに、プロキシが（PNS自体に使用される可能性のあるペイロードに加えて）ペイロードを挿入する必要はありません。
Operators MUST ensure that the PNS-related SIP URI parameters conveyed by a user in the Contact URI of a REGISTER request are not sent to other users or to non-trusted network entities. One way to convey contact information is by using the SIP event package for registrations mechanism [RFC3680]. [RFC3680] defines generic security considerations for the SIP event package for registrations. As the PNS-related SIP URI parameters conveyed in the REGISTER request contain sensitive information, operators that support the event package MUST ensure that event package subscriptions are properly authenticated and authorized, and that the SIP URI parameters are not inserted in event notifications sent to other users or to non-trusted network entities.
オペレーターは、REGISTERリクエストの連絡先URIでユーザーによって伝えられたPNS関連のSIP URIパラメーターが他のユーザーや信頼されていないネットワークエンティティに送信されないようにする必要があります。連絡先情報を伝える1つの方法は、登録メカニズム[RFC3680]のSIPイベントパッケージを使用することです。 [RFC3680]は、登録用のSIPイベントパッケージの一般的なセキュリティの考慮事項を定義しています。 REGISTERリクエストで伝えられるPNS関連のSIP URIパラメータには機密情報が含まれているため、イベントパッケージをサポートするオペレータは、イベントパッケージのサブスクリプションが適切に認証および承認され、SIP URIパラメータが他に送信されるイベント通知に挿入されないようにする必要があります。ユーザーまたは信頼されていないネットワークエンティティ。
This section defines new SIP URI Parameters that extend the "SIP/SIPS URI Parameters" subregistry [RFC3969] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
このセクションでは、SIPパラメータレジストリ（https://www.iana.org/assignments/sip-parameters）の「SIP / SIPS URIパラメータ」サブレジストリ[RFC3969]を拡張する新しいSIP URIパラメータを定義します。
Parameter Name: pn-provider
パラメータ名：pn-provider
Predefined Values: No
定義済みの値：いいえ
Reference: RFC 8599
リファレンス：RFC 8599
Parameter Name: pn-param
パラメータ名：pn-param
Predefined Values: No
定義済みの値：いいえ
Reference: RFC 8599
リファレンス：RFC 8599
Parameter Name: pn-prid
パラメータ名：on-pride
Predefined Values: No
定義済みの値：いいえ
Reference: RFC 8599
リファレンス：RFC 8599
Parameter Name: pn-purr
パラメータ名：pn-purr
Predefined Values: No
定義済みの値：いいえ
Reference: RFC 8599
リファレンス：RFC 8599
This section defines a new SIP response code that extends the "Response Codes" subregistry [RFC3261] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
このセクションでは、SIPパラメータレジストリ（https://www.iana.org/assignments/sip-parameters）の下の「応答コード」サブレジストリ[RFC3261]を拡張する新しいSIP応答コードを定義します。
Response Code Number: 555
応答コード番号：555
Default Reason Phrase: Push Notification Service Not Supported
デフォルトの理由フレーズ：プッシュ通知サービスはサポートされていません
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
このセクションでは、SIPパラメータレジストリ（https://www.iana.org/assignments/sip-parameters）の下の「SIP機能能力インジケータ登録ツリー」サブレジストリ[RFC6809]を拡張する新しい機能能力インジケータを定義します。
Name: sip.pns
名前：sip.pns
Description: This feature-capability indicator, when inserted in a Feature-Caps header field of a SIP REGISTER request or a SIP 2xx response to a REGISTER request, 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.
説明：この機能機能インジケーターは、SIP REGISTER要求のFeature-CapsヘッダーフィールドまたはREGISTER要求に対するSIP 2xx応答に挿入されると、インジケーターに関連付けられたエンティティがSIPプッシュメカニズムとプッシュのタイプをサポートすることを示します指標値によって伝えられる通知サービス。
Reference: RFC 8599
リファレンス：RFC 8599
Contact: IESG (iesg@ietf.org)
連絡先：IESG（iesg@ietf.org）
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
このセクションでは、SIPパラメータレジストリ（https://www.iana.org/assignments/sip-parameters）の下の「SIP機能能力インジケータ登録ツリー」サブレジストリ[RFC6809]を拡張する新しい機能能力インジケータを定義します。
Name: sip.vapid
名前：sip.vapid
Description: This feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator supports the Voluntary Application Server Identification (VAPID) mechanism when the entity requests that a push notification be sent to a SIP UA.
説明：この機能機能インジケーターは、SIP REGISTER要求へのSIP 2xx応答に挿入されると、エンティティーがプッシュ通知の送信を要求したときに、インジケーターに関連付けられたエンティティが自発的アプリケーションサーバー識別（VAPID）メカニズムをサポートすることを示しますSIP UA。
The indicator value is a public key identifying the entity, which can be used by a SIP UA to restrict subscriptions to that entity.
インジケーター値は、エンティティを識別する公開キーであり、SIP UAがエンティティへのサブスクリプションを制限するために使用できます。
Reference: RFC 8599
リファレンス：RFC 8599
Contact: IESG (iesg@ietf.org)
連絡先：IESG（iesg@ietf.org）
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
このセクションでは、SIPパラメータレジストリ（https://www.iana.org/assignments/sip-parameters）の下の「SIP機能能力インジケータ登録ツリー」サブレジストリ[RFC6809]を拡張する新しい機能能力インジケータを定義します。
Name: sip.pnsreg
名前：sip.pnsreg
Description: This feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator expects to receive binding-refresh REGISTER requests for the binding from the SIP UA associated with the binding before the binding expires, even if the entity does not request that a push notification be sent to the SIP UA in order to trigger the binding-refresh REGISTER requests. The indicator value conveys the minimum time (given in seconds) prior to the binding expiration when the UA MUST send the REGISTER request.
説明：この機能機能インジケーターは、SIP REGISTER要求に対するSIP 2xx応答に挿入されると、インジケーターに関連付けられたエンティティが、バインディングの前にバインディングに関連付けられたSIP UAからバインディングのbinding-refresh REGISTERリクエストを受信することを期待していることを示します。エンティティが、バインディング更新REGISTER要求をトリガーするためにプッシュ通知をSIP UAに送信するように要求していない場合でも、バインディングは期限切れになります。インジケータ値は、UAがREGISTERリクエストを送信しなければならないときに、バインディングの有効期限が切れるまでの最小時間（秒単位）を伝えます。
Reference: RFC 8599
リファレンス：RFC 8599
Contact: IESG (iesg@ietf.org)
連絡先：IESG（iesg@ietf.org）
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
このセクションでは、SIPパラメータレジストリ（https://www.iana.org/assignments/sip-parameters）の下の「SIP機能能力インジケータ登録ツリー」サブレジストリ[RFC6809]を拡張する新しい機能能力インジケータを定義します。
Name: sip.pnspurr
名前：sip.pnspurr
Description: This feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, conveys that the entity associated with the indicator will store information that can be used to associate a mid-dialog SIP request with the binding information in the REGISTER request. The indicator value is an identifier that can be used as a key to retrieve the binding information.
説明：この機能機能インジケーターは、SIP REGISTER要求へのSIP 2xx応答に挿入されると、インジケーターに関連付けられたエンティティが、中間ダイアログSIP要求をバインディング情報に関連付けるために使用できる情報を格納することを伝えます。登録リクエスト。インジケータ値は、バインディング情報を取得するためのキーとして使用できる識別子です。
Reference: RFC 8599
リファレンス：RFC 8599
Contact: IESG (iesg@ietf.org)
連絡先：IESG（iesg@ietf.org）
This section defines a new media feature tag that extends the "SIP Media Feature Tag Registration Tree" subregistry [RFC3840] under the "Media Feature Tags" registry (https://www.iana.org/assignments/ media-feature-tags).
このセクションでは、「メディア機能タグ」レジストリ（https://www.iana.org/assignments/ media-feature-tags）の下の「SIPメディア機能タグ登録ツリー」サブレジストリ[RFC3840]を拡張する新しいメディア機能タグを定義します。 。
Media feature tag name: sip.pnsreg
メディア機能タグ名：sip.pnsreg
Summary of the media feature indicated by this feature tag: This media feature tag, when inserted in the Contact header field of a SIP REGISTER request, conveys that the SIP UA associated with the tag is able to send binding-refresh REGISTER requests associated with the registration without being awakened by push notifications.
この機能タグで示されるメディア機能の概要：このメディア機能タグは、SIP REGISTERリクエストのContactヘッダーフィールドに挿入されると、タグに関連付けられたSIP UAが、関連付けられたバインディングリフレッシュREGISTERリクエストを送信できることを伝えますプッシュ通知によって起こされることなく登録。
Values appropriate for use with this feature tag: none
この機能タグでの使用に適した値：なし
Related standards or documents: RFC 8599
関連する規格または文書：RFC 8599
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 will not be requested to be sent to the client.
セキュリティの考慮事項：このメディア機能タグは、基本的なSIP機能のサポートを示すだけなので、新しいセキュリティの考慮事項を導入しません。攻撃者がなんとかしてメディア機能タグを削除した場合、プッシュ通知はクライアントへの送信を要求されません。
Contact: IESG (iesg@ietf.org)
連絡先：IESG（iesg@ietf.org）
This section creates a new subregistry, "PNS", under the SIP Parameters registry (https://www.iana.org/assignments/ sip-parameters).
このセクションでは、SIPパラメータレジストリ（https://www.iana.org/assignments/ sip-parameters）の下に新しいサブレジストリ「PNS」を作成します。
The purpose of the subregistry is to register SIP URI 'pn-provider' values.
サブレジストリの目的は、SIP URI「pn-provider」の値を登録することです。
When a SIP URI 'pn-provider' value is registered in the subregistry, it needs to meet the "Specification Required" policies defined in [RFC8126].
SIP URI 'pn-provider'の値がサブレジストリに登録されている場合、[RFC8126]で定義されている "Specification Required"ポリシーを満たす必要があります。
This subregistry is defined as a table that contains the following three columns:
このサブレジストリは、次の3つの列を含むテーブルとして定義されています。
Value: The token under registration
値：登録中のトークン
Description: The name of the Push Notification Service (PNS)
説明：プッシュ通知サービス（PNS）の名前
Document: A reference to the document defining the registration
ドキュメント：登録を定義するドキュメントへの参照
This specification registers the following values:
この仕様は、次の値を登録します。
Value Description Document
------- -------------------------------------- ----------
apns Apple Push Notification service RFC 8599 fcm Firebase Cloud Messaging RFC 8599 webpush Generic Event Delivery Using HTTP Push RFC 8599
apns Apple Push Notification service RFC 8599 fcm Firebase Cloud Messaging RFC 8599 webpush Generic Event Delivery Using HTTP Push RFC 8599
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://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, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-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>.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）でのユーザーエージェント機能の表示」、RFC 3840、DOI 10.17487 / RFC3840、2004年8月、<https：// www .rfc-editor.org / info / rfc3840>。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <https://www.rfc-editor.org/info/rfc3891>.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「Session Initiation Protocol（SIP） "Replaces" Header」、RFC 3891、DOI 10.17487 / RFC3891、2004年9月、<https：// www。 rfc-editor.org/info/rfc3891>。
[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, <https://www.rfc-editor.org/info/rfc3969>.
[RFC3969] Camarillo、G。、「インターネット開始番号認証局（IANA）セッション開始プロトコル（SIP）のURI（Uniform Resource Identifier）パラメータレジストリ」、BCP 99、RFC 3969、DOI 10.17487 / RFC3969、2004年12月、< https://www.rfc-editor.org/info/rfc3969>。
[RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", RFC 5079, DOI 10.17487/RFC5079, December 2007, <https://www.rfc-editor.org/info/rfc5079>.
[RFC5079] Rosenberg、J。、「セッション開始プロトコル（SIP）での匿名リクエストの拒否」、RFC 5079、DOI 10.17487 / RFC5079、2007年12月、<https://www.rfc-editor.org/info/rfc5079> 。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, November 2012, <https://www.rfc-editor.org/info/rfc6809>.
[RFC6809] Holmberg、C.、Sedlacek、I。、およびH. Kaplan、「Session Initiation Protocol（SIP）の機能と機能のサポートを示すメカニズム」、RFC 6809、DOI 10.17487 / RFC6809、2012年11月、<https ：//www.rfc-editor.org/info/rfc6809>。
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8030] Thomson、M.、Damaggio、E。、およびB. Raymor、編、「HTTPプッシュを使用した一般的なイベント配信」、RFC 8030、DOI 10.17487 / RFC8030、2016年12月、<https：//www.rfc- editor.org/info/rfc8030>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server Identification (VAPID) for Web Push", RFC 8292, DOI 10.17487/RFC8292, November 2017, <https://www.rfc-editor.org/info/rfc8292>.
[RFC8292] Thomson、M。、およびP. Beverloo、「Webプッシュ用の自発的アプリケーションサーバー識別（VAPID）」、RFC 8292、DOI 10.17487 / RFC8292、2017年11月、<https://www.rfc-editor.org/info / rfc8292>。
[pns-apns] Apple Inc., "Local and Remote Notification Programming Guide: Communicating with APNs", <https://developer.apple. com/library/archive/documentation/NetworkingInternet/Conce ptual/RemoteNotificationsPG/CommunicatingwithAPNs.html>.
[pns-apns] Apple Inc。、「Local and Remote Notification Programming Guide：Communicating with APNs」、<https://developer.apple。 com / library / archive / documentation / NetworkingInternet / Conce ptual / RemoteNotificationsPG / CommunicatingwithAPNs.html>。
[pns-fcm] Google Inc., "Firebase Cloud Messaging", <https://firebase.google.com/docs/cloud-messaging/ concept-options>.
[pns-fcm] Google Inc。、「Firebase Cloud Messaging」、<https://firebase.google.com/docs/cloud-messaging/ concept-options>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org / info / rfc3264>。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, DOI 10.17487/RFC3680, March 2004, <https://www.rfc-editor.org/info/rfc3680>.
[RFC3680] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、DOI 10.17487 / RFC3680、2004年3月、<https://www.rfc-editor.org/info/rfc3680> 。
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, DOI 10.17487/RFC4320, January 2006, <https://www.rfc-editor.org/info/rfc4320>.
[RFC4320] Sparks、R。、「Session Initiation Protocol（SIP）Non-INVITE Transactionで識別された問題に対処するアクション」、RFC 4320、DOI 10.17487 / RFC4320、2006年1月、<https://www.rfc-editor.org / info / rfc4320>。
[RFC4321] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, DOI 10.17487/RFC4321, January 2006, <https://www.rfc-editor.org/info/rfc4321>.
[RFC4321] Sparks、R。、「Session Initiation Protocol（SIP）Non-INVITE Transactionに関連して識別された問題」、RFC 4321、DOI 10.17487 / RFC4321、2006年1月、<https://www.rfc-editor.org/ info / rfc4321>。
[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, <https://www.rfc-editor.org/info/rfc5626>.
[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 、2009年10月、<https://www.rfc-editor.org/info/rfc5626>。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <https://www.rfc-editor.org/info/rfc6665>.
[RFC6665] Roach、A。、「SIP固有のイベント通知」、RFC 6665、DOI 10.17487 / RFC6665、2012年7月、<https://www.rfc-editor.org/info/rfc6665>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, <https://www.rfc-editor.org/info/rfc8291>.
[RFC8291] Thomson、M。、「Message Push for Web Push」、RFC 8291、DOI 10.17487 / RFC8291、2017年11月、<https://www.rfc-editor.org/info/rfc8291>。
Acknowledgements
謝辞
Thanks to Paul Kyzivat, Dale Worley, Ranjit Avasarala, Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula, Liviu Chircu, Roman Shpount, Yehoshua Gev, and Jean Mahoney for reading the text and providing useful feedback.
テキストを読んで有益なフィードバックを提供してくれたPaul Kyzivat、Dale Worley、Ranjit Avasarala、Martin Thomson、Mikael Klein、Susanna Sjoholm、Kari-Pekka Perttula、Livius Chircu、Roman Shpount、Yehoshua Gev、Jean Mahoneyに感謝します。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: christer.holmberg@ericsson.com
Michael Arnold Metaswitch Networks 100 Church Street Enfield EN2 6BQ United Kingdom
Michael Arnold Metaswitch Networks 100 Church Street Enfield EN2 6BQイギリス
Email: Michael.Arnold@metaswitch.com