RFC 7976 - Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7976
タイトル : RFC 7976 - セッション開始プロトコル（SIP）の要求と応答でのプライベートヘッダー（Pヘッダー）拡張の使用法の更新
翻訳編集 : 自動生成

[要約] RFC 7976は、SIPリクエストとレスポンスでのプライベートヘッダ（P-Header）拡張の使用に関する更新を提供しています。目的は、SIPメッセージにカスタムヘッダを追加するための一貫した方法を提供することです。

Internet Engineering Task Force (IETF)                       C. Holmberg
Request for Comments: 7976                                    N. Biondic
Updates: 7315                                                   Ericsson
Category: Informational                                     G. Salgueiro
ISSN: 2070-1721                                                    Cisco
                                                          September 2016

Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses

セッション開始プロトコル（SIP）の要求と応答でのプライベートヘッダー（Pヘッダー）拡張の使用法の更新

Abstract

概要

The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.

第3世代パートナーシッププロジェクト（3GPP）では、「P-」ヘッダーフィールドと呼ばれ、RFC 7315で定義されているさまざまなSIPプライベートヘッダー拡張を、RFC 7315で現在許可されていないSIP要求および応答に含める必要があるケースが特定されています。このドキュメントでは、影響を受ける「P-」ヘッダーフィールドをそのような要求と応答に含めることができるように、RFC 7315を更新しています。

This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.

このドキュメントは、RFC 3455が更新され、RFC 7315によって廃止されたときに発生した不整合を修正するために、RFC 7315の更新も行います。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc7976.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7976で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Misalignments and 3GPP Use Cases  . . . . . . . . . . . . . .   3
     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Misalignments . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . .   4
       2.3.1.  General . . . . . . . . . . . . . . . . . . . . . . .   4
       2.3.2.  P-Access-Network-Info . . . . . . . . . . . . . . . .   4
       2.3.3.  P-Charging-Vector . . . . . . . . . . . . . . . . . .   5
   3.  Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

1. はじめに

The Third Generation Partnership Project (3GPP) has identified cases where different Session Initiation Protocol (SIP) [RFC3261] private header extensions referred to as "P-" header fields, and defined in [RFC7315], need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.

第3世代パートナーシッププロジェクト（3GPP）は、「P-」ヘッダーフィールドと呼ばれ、[RFC7315]で定義されているさまざまなセッション開始プロトコル（SIP）[RFC3261]プライベートヘッダー拡張をSIPリクエストに含める必要がある場合を識別し、このドキュメントでは、RFC 7315を更新して、影響を受ける "P-"ヘッダーフィールドをこのような要求と応答に含めることができるようにしています。

This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 [RFC3455] was updated and obsoleted by RFC 7315.

このドキュメントは、RFC 3455 [RFC3455]が更新され、RFC 7315によって廃止されたときに発生した不整合を修正するために、RFC 7315の更新も行います。

As the "P-" header fields are mainly used in (and in most cases, only defined for) networks defined by the 3GPP, where the updates defined in this document are already defined [TS.3GPP.24.229], the updates are not seen to cause backward-compatibility concerns.

「P-」ヘッダーフィールドは、3GPPによって定義されたネットワークで主に使用され（ほとんどの場合、定義されているだけ）、このドキュメントで定義された更新はすでに定義されています[TS.3GPP.24.229]、更新は後方互換性の問題を引き起こすことがわかっています。

2. Misalignments and 3GPP Use Cases

2. ミスアライメントと3GPPの使用例

2.1. General

2.1. 一般的な

RFC 7315 contains contradicting statements regarding the usage of SIP "P-" header fields in SIP requests and responses, which leave the presence of the SIP "P-" header fields in the SIP requests and responses open to interpretation and different implementations. Statements in Section 5.7 of that RFC are not aligned with the definitions and usage of the SIP "P-" header fields specified in Section 4. This section describes the misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315, and how they are fixed.

RFC 7315には、SIP要求および応答におけるSIP "P-"ヘッダーフィールドの使用に関する矛盾する記述が含まれています。これにより、SIP要求および応答におけるSIP "P-"ヘッダーフィールドの存在が解釈およびさまざまな実装に対して開かれます。そのRFCのセクション5.7のステートメントは、セクション4で指定されたSIP "P-"ヘッダーフィールドの定義と使用法と整合していません。このセクションでは、RFC 3455が更新され、RFC 7315によって廃止されたときに発生したミスアライメントと、その方法について説明します固定されています。

NOTE: In the case of the P-Called-Party-ID header field, allowing it in PUBLISH requests was deliberately done in RFC 7315. Therefore, it is not considered a misalignment.

注：P-Called-Party-IDヘッダーフィールドの場合、PUBLISHリクエストで許可することは、RFC 7315で意図的に行われました。したがって、ミスアライメントとは見なされません。

Since RFC 7315 was published, 3GPP defined new use cases that require the RFC to be updated. This section describes the 3GPP use cases behind the updates, and the updates needed to RFC 7315 in order to support the use cases.

RFC 7315が公開されて以来、3GPPはRFCの更新を必要とする新しいユースケースを定義しました。このセクションでは、更新の背後にある3GPPの使用例と、使用例をサポートするためにRFC 7315に必要な更新について説明します。

Section 3 updates RFC 7315, based on the misalignments and 3GPP use cases.

セクション3では、ミスアライメントと3GPPの使用例に基づいてRFC 7315を更新します。

2.2. Misalignments

2.2. ミスアライメント

The following updates are needed in order to fix the misalignments between RFCs 7315 and 3455:

RFC 7315と3455の間の不整合を修正するには、次の更新が必要です。

o P-Associated-URI: Remove the statement that the header field can appear in the SIP REGISTER method.

o P-Associated-URI：ヘッダーフィールドをSIP REGISTERメソッドに表示できるというステートメントを削除します。

o P-Called-Party-ID: Delete the statement that the P-Called-Party-ID header field can appear in SIP responses. Add a statement that the P-Called-Party-ID header field can appear in the SIP REFER method.

o P-Called-Party-ID：P-Called-Party-IDヘッダーフィールドがSIP応答に表示される可能性があるというステートメントを削除します。 P-Called-Party-IDヘッダーフィールドをSIP REFERメソッドに表示できるというステートメントを追加します。

o P-Visited-Network-ID: Delete the statement that the P-Visited-Network-ID header field can appear in SIP responses. Add a statement that the P-Visited-Network-ID header field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE methods.

o P-Visited-Network-ID：P-Visited-Network-IDヘッダーフィールドがSIP応答に表示される可能性があるというステートメントを削除します。 P-Visited-Network-IDヘッダーフィールドをSIP NOTIFY、PRACK、INFO、およびUPDATEメソッドに表示できないというステートメントを追加します。

o P-Access-Network-Info: Add a statement that the P-Access-Network-Info header field can appear in SIP responses.

o P-Access-Network-Info：P-Access-Network-InfoヘッダーフィールドをSIP応答に表示できるというステートメントを追加します。

o P-Charging-Vector: Add a statement that the P-Charging-Vector header field can appear in SIP responses. Add a statement that the P-Charging-Vector header field cannot appear in the SIP ACK method.

o P-Charging-Vector：P-Charging-VectorヘッダーフィールドをSIP応答に表示できるというステートメントを追加します。 P-Charging-VectorヘッダーフィールドをSIP ACKメソッドに表示できないというステートメントを追加します。

o P-Charging-Function-Addresses: Add a statement that the P-Charging-Function-Addresses header field can appear in SIP responses.

o P-Charging-Function-Addresses：P-Charging-Function-AddressesヘッダーフィールドをSIP応答に表示できるステートメントを追加します。

2.3. 3GPP Use Cases

2.3. 3GPPの使用例

2.3.1. General

2.3.1. 一般的な

The following updates are needed in order to implement the 3GPP use cases:

3GPPユースケースを実装するには、次の更新が必要です。

o P-Access-Network-Info: Add statement that the P-Access-Network-Info header field can appear in the SIP ACK method when triggered by a SIP 2xx response.

o P-Access-Network-Info：SIP 2xx応答によってトリガーされたときに、P-Access-Network-InfoヘッダーフィールドをSIP ACKメソッドに表示できるというステートメントを追加します。

o P-Charging-Vector: Add statement that the P-Charging-Vector header field can appear in the SIP ACK method when triggered by a SIP 2xx response.

o P-Charging-Vector：SIP 2xx応答によってトリガーされたときに、P-Charging-VectorヘッダーフィールドをSIP ACKメソッドに表示できるというステートメントを追加します。

This following sections describe, for individual "P-" header fields, the 3GPP use cases that are the basis for the updates. The use cases are based on the procedures defined in [TS.3GPP.24.229].

以下のセクションでは、個々の「P-」ヘッダーフィールドについて、更新の基礎となる3GPPの使用例について説明します。ユースケースは、[TS.3GPP.24.229]で定義されている手順に基づいています。

2.3.2. P-Access-Network-Info

The P-Access-Network-Info header field may contain the Network Provided Location Information (NPLI). The NPLI is described in [TS.3GPP.23.228].

P-Access-Network-Infoヘッダーフィールドには、ネットワーク提供ロケーション情報（NPLI）が含まれる場合があります。 NPLIは[TS.3GPP.23.228]で説明されています。

A proxy in possession of appropriate information about the access technology might insert a P-Access-Network-Info header field with its own values. Such values are identified by the string "network-provided" defined in RFC 7315. Based on operator policy and/or roaming agreement, the local time of the visited network may be included.

アクセステクノロジーに関する適切な情報を保持しているプロキシは、独自の値を持つP-Access-Network-Infoヘッダーフィールドを挿入する場合があります。このような値は、RFC 7315で定義されている「ネットワーク提供」という文字列によって識別されます。オペレーターのポリシーやローミングの合意に基づいて、訪問したネットワークの現地時間を含めることができます。

The Call Data Records (CDRs) generated within the IP Multimedia Subsystem (IMS) have to contain the NPLI in order to guarantee correct billing. When an IMS session is modified, the NPLI also needs to be stored as the location of the user at the time when the session is modified may generate a charging event. In case of a session modification event at IMS, the NPLI needs to be provided:

IPマルチメディアサブシステム（IMS）内で生成されたコールデータレコード（CDR）には、正しい請求を保証するためにNPLIが含まれている必要があります。 IMSセッションが変更されると、セッションが変更されるときにユーザーの場所が課金イベントを生成する可能性があるため、NPLIも保存する必要があります。 IMSでのセッション変更イベントの場合、NPLIを提供する必要があります。

o when the bearer establishment is triggered, or

o ベアラ確立がトリガーされたとき、または

o at session release when the bearer deactivation is triggered, or

o ベアラの非アクティブ化がトリガーされたセッションリリース時、または

o when the bearer modification is triggered, e.g., a QoS modification for the use of a newly negotiated codec.

o ベアラの変更がトリガーされたとき。たとえば、新たにネゴシエートされたコーデックを使用するためのQoS変更。

In some scenarios, the bearer modification may be triggered by the proxy upon reception of a Session Description Protocol (SDP) answer within SIP 2xx response to the SIP INVITE request. In such case, the NPLI needs to be provided within the SIP ACK request. However, RFC 7315 does not allow the usage of the P-Access-Network-Info header field in SIP ACK request.

一部のシナリオでは、SIP INVITE要求に対するSIP 2xx応答内でセッション記述プロトコル（SDP）応答を受信すると、ベアラの変更がプロキシによってトリガーされます。そのような場合、NPLIはSIP ACK要求内で提供される必要があります。ただし、RFC 7315では、SIP ACK要求でP-Access-Network-Infoヘッダーフィールドを使用できません。

Upon reception of the SDP answer within SIP 2xx response on the SIP INVITE request, a proxy may initiate procedures to obtain the NPLI and may include the P-Access-Network-Info header field with the NPLI in the SIP ACK request.

SIP INVITE要求のSIP 2xx応答内でSDP応答を受信すると、プロキシはNPLIを取得する手順を開始し、P-Access-Network-InfoヘッダーフィールドをNPLIとともにSIP ACK要求に含めることができます。

The P-Access-Network-Info header field shall not be included in SIP ACK requests triggered by non-2xx responses.

P-Access-Network-Infoヘッダーフィールドは、非2xx応答によってトリガーされるSIP ACK要求に含まれません。

2.3.3. P-Charging-Vector

2.3.3. P充電ベクトル

RFC 7315 defines an Inter Operator Identifier (IOI) to enable different operators involved in a SIP dialog or a transaction outside a dialog to identify each other by exchanging operator identification information within the P-Charging-Vector header field.

RFC 7315は、オペレーター間識別子（IOI）を定義して、P-Charging-Vectorヘッダーフィールド内のオペレーター識別情報を交換することにより、SIPダイアログまたはダイアログ外のトランザクションに関与するさまざまなオペレーターがお互いを識別できるようにします。

In the interconnection scenarios in multi-operator environments, where one or more transit operators are between the originating and terminating operator, the identities of the involved transit operators are represented by a transit-ioi parameter of the P-Charging-Vector header field.

1つ以上のトランジットオペレーターが開始オペレーターと終了オペレーターの間にあるマルチオペレーター環境の相互接続シナリオでは、関係するトランジットオペレーターのIDは、P-Charging-Vectorヘッダーフィールドのtransit-ioiパラメーターで表されます。

Transit operators can be selected independently for each SIP method and direction of request. A transit network will only have knowledge of an individual SIP request, and transit network selection will be an independent decision for each request and could be made based on load, cost, percentage, time of day, and other factors. For this reason, it is necessary that the P-Charging-Vector header field, which carries the transit IOI information, is included in each SIP request and response. However, RFC 7315 does not allow the usage of the P-Charging-Vector header field in the SIP ACK request.

トランジットオペレーターは、各SIPメソッドと要求の方向に対して個別に選択できます。トランジットネットワークは個々のSIPリクエストのみを認識し、トランジットネットワークの選択はリクエストごとに独立した決定となり、負荷、コスト、パーセンテージ、時刻、およびその他の要因に基づいて行われます。このため、トランジットIOI情報を運ぶP-Charging-Vectorヘッダーフィールドが各SIPリクエストおよびレスポンスに含まれている必要があります。ただし、RFC 7315では、SIP ACK要求でP-Charging-Vectorヘッダーフィールドを使用できません。

A SIP proxy that supports this extension and receives the SIP ACK request may include a P-Charging-Vector header field in the SIP ACK request.

この拡張をサポートし、SIP ACK要求を受信するSIPプロキシは、SIP ACK要求にP-Charging-Vectorヘッダーフィールドを含めることができます。

The P-Charging-Vector header field shall not be included in SIP ACK requests triggered by SIP non-2xx responses.

P-Charging-Vectorヘッダーフィールドは、SIP非2xx応答によってトリガーされるSIP ACK要求に含まれません。

3. Updates to RFC 7315

3. RFC 7315の更新

This section implements the update to Section 5.7 of RFC 7315, in order to implement the misalignment fixes and the 3GPP requirements described in Section 2.

このセクションでは、RFC 7315のセクション5.7への更新を実装して、ミスアライメントの修正とセクション2で説明されている3GPP要件を実装します。

Old text:

古いテキスト：

The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses [sic]. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all responses. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses. The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL. The P-Charging-Vector header field can appear in all SIP methods except CANCEL. The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL.

P-Associated-URIヘッダーフィールドは、SIP REGISTERメソッドおよび2xxで表示される可能性があります[sic]。 P-Called-Party-IDヘッダーフィールドは、SIP INVITE、OPTIONS、PUBLISH、SUBSCRIBE、およびMESSAGEメソッドとすべての応答に表示できます。 P-Visited-Network-IDヘッダーフィールドは、ACK、BYE、CANCELを除くすべてのSIPメソッドとすべての応答に表示できます。 P-Access-Network-Infoヘッダーフィールドは、ACKとCANCELを除くすべてのSIPメソッドで使用できます。 P-Charging-Vectorヘッダーフィールドは、CANCELを除くすべてのSIPメソッドで使用できます。 P-Charging-Function-Addressesヘッダーフィールドは、ACKとCANCELを除くすべてのSIPメソッドで使用できます。

New text:

新しいテキスト：

The P-Associated-URI header field can appear in SIP REGISTER 2xx responses. The P-Called-Party-ID header field can appear in the SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE. The P-Access-Network-Info header field can appear in all SIP methods and non-100 responses, except in CANCEL methods, CANCEL responses, and ACK methods triggered by non-2xx responses. The P-Charging-Vector header field can appear in all SIP methods and non-100 responses, except in CANCEL methods, CANCEL responses, and ACK methods triggered by non-2xx responses. The P-Charging-Function-Addresses header field can appear in all SIP methods and non-100 responses, except in CANCEL methods, CANCEL responses, and ACK methods.

P-Associated-URIヘッダーフィールドは、SIP REGISTER 2xx応答に表示されます。 P-Called-Party-IDヘッダーフィールドは、SIP INVITE、OPTIONS、PUBLISH、REFER、SUBSCRIBE、およびMESSAGEメソッドに表示できます。 P-Visited-Network-IDヘッダーフィールドは、ACK、BYE、CANCEL、NOTIFY、PRACK、INFO、およびUPDATEを除くすべてのSIPメソッドで使用できます。 P-Access-Network-Infoヘッダーフィールドは、CANCELメソッド、CANCEL応答、および2xx以外の応答によってトリガーされるACKメソッドを除き、すべてのSIPメソッドと100以外の応答に表示できます。 P-Charging-Vectorヘッダーフィールドは、CANCELメソッド、CANCEL応答、および2xx以外の応答によってトリガーされるACKメソッドを除いて、すべてのSIPメソッドと100以外の応答に表示できます。 P-Charging-Function-Addressesヘッダーフィールドは、CANCELメソッド、CANCEL応答、およびACKメソッドを除いて、すべてのSIPメソッドと100以外の応答に表示できます。

4. Security Considerations

4. セキュリティに関する考慮事項

The security considerations for these "P-" header fields are defined in [RFC7315]. This specification allows some header fields to be present in messages where they were previously not allowed, and the security considerations and assumptions described in [RFC7315] (e.g., regarding only sending information to trusted entities) also apply to those messages. In addition, this specification also disallows some header fields to be present in messages where they were previously allowed. That does not cause any security issues, but implementors need to be aware that implementations may not have been updated according to this document, and take proper actions if a header field occurs, or does not occur, in a message where it should occur (or occurs in a message where it should not occur). This document adds the ability to include P-Access-Network-Info in ACK requests. As documented in [RFC7315], P-Access-Network-Info may include privacy sensitive information, including the user's location. The security and privacy considerations for P-Access-Network-Info in ACK requests are similar to those for the other SIP requests discussed in [RFC7315].

これらの「P-」ヘッダーフィールドのセキュリティに関する考慮事項は、[RFC7315]で定義されています。この仕様では、以前は許可されていなかった一部のヘッダーフィールドをメッセージに含めることができ、[RFC7315]で説明されているセキュリティの考慮事項と前提事項（信頼できるエンティティへの情報の送信のみに関するものなど）もそれらのメッセージに適用されます。さらに、この仕様では、一部のヘッダーフィールドが以前は許可されていたメッセージに存在することも禁止されています。これはセキュリティの問題を引き起こしませんが、実装者はこのドキュメントに従って実装が更新されていない可能性があることを認識し、ヘッダーフィールドが発生するか発生しない場合、発生するはずのメッセージで適切なアクションを実行する必要があります（または発生してはならないメッセージで発生します）。このドキュメントでは、ACKリクエストにP-Access-Network-Infoを含める機能を追加しています。 [RFC7315]で文書化されているように、P-Access-Network-Infoには、ユーザーの位置を含むプライバシーに関わる情報が含まれている可能性があります。 ACK要求におけるP-Access-Network-Infoのセキュリティとプライバシーの考慮事項は、[RFC7315]で説明されている他のSIP要求の場合と同様です。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[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月、<http://www.rfc-editor.org/info/rfc3261>。

[RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July 2014, <http://www.rfc-editor.org/info/rfc7315>.

[RFC7315] Jesske、R.、Drage、K。、およびC. Holmberg、「3GPPのセッション開始プロトコル（SIP）に対するプライベートヘッダー（Pヘッダー）拡張」、RFC 7315、DOI 10.17487 / RFC7315、2014年7月、<http://www.rfc-editor.org/info/rfc7315>。

[TS.3GPP.23.228] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 23.228 13.6.0, June 2016, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.

[TS.3GPP.23.228] 3GPP、「セッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）に基づくIPマルチメディアコール制御プロトコル、ステージ3」、3GPP TS 23.228 13.6.0、2016年6月、<http：// www.3gpp.org/ftp/Specs/html-info/23228.htm>。

[TS.3GPP.24.229] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 24.229 13.6.0, June 2016, <http://www.3gpp.org/ftp/Specs/html-info/24229.htm>.

[TS.3GPP.24.229] 3GPP、「IP Multimedia Subsystem（IMS）; Stage 2」、3GPP TS 24.229 13.6.0、June 2016、<http://www.3gpp.org/ftp/Specs/html-info/ 24229.htm>。

5.2. Informative References

5.2. 参考引用

[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003, <http://www.rfc-editor.org/info/rfc3455>.

[RFC3455] Garcia-Martin、M.、Henrikson、E。、およびD. Mills、「第3世代パートナーシッププロジェクト（3GPP）のセッション開始プロトコル（SIP）のプライベートヘッダー（Pヘッダー）拡張」、RFC 3455、DOI 10.17487 / RFC3455、2003年1月、<http://www.rfc-editor.org/info/rfc3455>。

Acknowledgments

謝辞

Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach for providing comments on the document.

ドキュメントにコメントを提供してくれたPaul Kyzivat、Jean Mahoney、Ben Campbell、およびAdam Roachに感謝します。

Authors' Addresses

著者のアドレス

Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland

Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド

   Email: christer.holmberg@ericsson.com

Nevenka Biondic Ericsson Krapinska 45 Zagreb 10002 Croatia

Nevenka Biondic Ericsson Krapinska 45ザグレブ10002クロアチア

   Email: nevenka.biondic@ericsson.com

Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America

Gonzalo Salgueiro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国

   Email: gsalguei@cisco.com