Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 9878 Ericsson
Obsoletes: 7976 N. Biondic
Updates: 7315 ETSI
Category: Informational G. Salgueiro
ISSN: 2070-1721 Cisco Systems, Inc.
R. Jesske
Deutsche Telekom
November 2025
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 where they were 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. This document obsoletes RFC 7976. The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses.
Third Generation Partnership Project (3GPP) は、「P-」ヘッダー フィールドと呼ばれ、RFC 7315 で定義されているさまざまな SIP プライベート ヘッダー拡張を、RFC 7315 に従って許可されていない SIP リクエストと応答に含める必要があるケースを特定しました。この文書は、影響を受ける「P-」ヘッダー フィールドをそのようなリクエストと応答に含めることを許可するために、RFC 7315 を更新します。この文書は RFC 7976 を廃止します。RFC 7976 に関連する変更には、SIP 応答への P-Visited-Network-ID ヘッダー フィールドの組み込みが含まれます。
This document also makes updates to RFC 7315 in order to fix misalignments that occurred when RFC 3455 was obsoleted by RFC 7315.
この文書では、RFC 3455 が RFC 7315 によって廃止されたときに発生した不整合を修正するために、RFC 7315 も更新されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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 https://www.rfc-editor.org/info/rfc9878.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9878 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Misalignments and 3GPP Use Cases
2.1. General
2.2. Misalignments
2.3. 3GPP Use Cases
2.3.1. General
2.3.2. P-Access-Network-Info
2.3.3. P-Charging-Vector
3. Updates to RFC 7315
4. IANA Considerations
5. Security Considerations
6. Operational considerations
7. Changes since RFC 7976
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
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 where they were not allowed according to [RFC7315]. This document updates [RFC7315], in order to allow inclusion of the affected "P-" header fields in such requests and responses.
第 3 世代パートナーシップ プロジェクト (3GPP) は、「P-」ヘッダー フィールドと呼ばれ、[RFC7315] で定義されているさまざまなセッション開始プロトコル (SIP) [RFC3261] プライベート ヘッダー拡張を、[RFC7315] に従って許可されていない SIP 要求および応答に含める必要があるケースを特定しました。この文書は、影響を受ける「P-」ヘッダフィールドをそのようなリクエストやレスポンスに含めることを許可するために、[RFC7315]を更新します。
This document also makes updates to [RFC7315] in order to fix misalignments that occurred when [RFC3455] was updated and subsequently obsoleted by the publication of [RFC7315].
この文書は、[RFC3455] が更新され、その後 [RFC7315] の出版によって廃止されたときに発生した不整合を修正するために、[RFC7315] も更新しています。
[RFC7315] contains contradictory 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 [RFC7315] are not aligned with the definitions and usage of the SIP "P-" header fields specified in Section 4 of [RFC7315]. This section describes the misalignments that occurred when [RFC3455] was updated and subsequently obsoleted by the publication of [RFC7315], and how they are fixed.
[RFC7315] には、SIP リクエストおよび応答における SIP "P-" ヘッダー フィールドの使用法に関する矛盾した記述が含まれており、SIP リクエストおよび応答における SIP "P-" ヘッダー フィールドの存在は、解釈および異なる実装の余地が残されています。[RFC7315] のセクション 5.7 の記述は、[RFC7315] のセクション 4 で指定されている SIP "P-" ヘッダーフィールドの定義および使用法と一致していません。このセクションでは、[RFC3455] が更新され、その後 [RFC7315] の発行によって廃止されたときに発生した不整合と、それらの修正方法について説明します。
NOTE: In the case of the P-Called-Party-ID header field, allowing it in PUBLISH requests was done deliberately in [RFC7315]. Therefore, it is not considered a misalignment.
注: P-Called-Party-ID ヘッダーフィールドの場合、PUBLISH リクエストでの許可は [RFC7315] で意図的に行われています。したがって、位置ずれとはみなされません。
Since [RFC7315] 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 [RFC7315] in order to support the use cases.
[RFC7315] が公開されて以来、3GPP は RFC の更新を必要とする新しいユースケースを定義しました。このセクションでは、アップデートの背後にある 3GPP のユースケースと、そのユースケースをサポートするために [RFC7315] に必要なアップデートについて説明します。
Section 3 updates [RFC7315], based on the misalignments and 3GPP use cases.
セクション 3 では、不整合と 3GPP のユースケースに基づいて [RFC7315] を更新します。
The following updates are needed in order to fix the misalignments that occurred when [RFC3455] was obsoleted by [RFC7315]:
[RFC3455] が [RFC7315] によって廃止されたときに発生した不整合を修正するには、次の更新が必要です。
* P-Associated-URI: Remove the statement that the header field can appear in the SIP REGISTER method.
* P-Associated-URI: ヘッダー フィールドが SIP REGISTER メソッドに表示される可能性があるというステートメントを削除します。
* 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.
* P-Called-Party-ID: P-Called-Party-ID ヘッダー フィールドが SIP 応答に表示される可能性があるというステートメントを削除します。P-Called-Party-ID ヘッダー フィールドが SIP REFER メソッドに表示される可能性があるというステートメントを追加します。
* P-Access-Network-Info: Add a statement that the P-Access-Network-Info header field can appear in SIP responses.
* P-Access-Network-Info: P-Access-Network-Info ヘッダー フィールドが SIP 応答に表示される可能性があるというステートメントを追加します。
* 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.
* P-Charging-Vector: P-Charging-Vector ヘッダー フィールドが SIP 応答に表示される可能性があるというステートメントを追加します。P-Charging-Vector ヘッダー フィールドを SIP ACK メソッドに含めることはできないというステートメントを追加します。
* P-Charging-Function-Addresses: Add a statement that the P-Charging-Function-Addresses header field can appear in SIP responses.
* P-Charging-Function-Addresses: P-Charging-Function-Addresses ヘッダー フィールドが SIP 応答に表示される可能性があるというステートメントを追加します。
The following update is needed in order to clarify the usage of the header compared to [RFC7315]:
[RFC7315] と比較してヘッダーの使用法を明確にするために、次の更新が必要です。
* P-Visited-Network-ID: Add a statement that the P-Visited-Network-ID header field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE methods. Add statement that the P-Visited-Network-ID header field can appear in all non-100 (Trying) responses.
* P-Visited-Network-ID: P-Visited-Network-ID ヘッダー フィールドが SIP NOTIFY、PRACK、INFO、および UPDATE メソッドに表示できないというステートメントを追加します。P-Visited-Network-ID ヘッダー フィールドが 100 以外のすべての (Trying) 応答に表示される可能性があるというステートメントを追加します。
The following updates are needed in order to implement the 3GPP use cases:
3GPP ユースケースを実装するには、次の更新が必要です。
* 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.
* P-Access-Network-Info: SIP 2xx 応答によってトリガーされたときに、P-Access-Network-Info ヘッダー フィールドが SIP ACK メソッドに表示される可能性があるというステートメントを追加します。
* 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.
* 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 [TS24.229].
以下のセクションでは、個々の「P-」ヘッダー フィールドについて、更新の基礎となる 3GPP の使用例について説明します。使用例は、[TS24.229] で定義されている手順に基づいています。
The P-Access-Network-Info header field may contain the Network Provided Location Information (NPLI). The NPLI is described in [TS23.228].
P-Access-Network-Info ヘッダー フィールドには、ネットワーク提供位置情報 (NPLI) が含まれる場合があります。NPLI は [TS23.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 [RFC7315]. Based on operator policy, roaming agreement, or both, the local time of the visited network may be included.
アクセス テクノロジに関する適切な情報を所有するプロキシは、独自の値を持つ P-Access-Network-Info ヘッダー フィールドを挿入する場合があります。このような値は、[RFC7315] で定義されている文字列「network-provided」によって識別されます。通信事業者のポリシー、ローミング契約、またはその両方に基づいて、訪問先ネットワークの現地時間が含まれる場合があります。
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 を提供する必要があります。
* when the bearer establishment is triggered, or
* ベアラ確立がトリガーされたとき、または
* at session release when the bearer deactivation is triggered, or
* セッション解放時、ベアラーの非アクティブ化がトリガーされたとき、または
* when the bearer modification is triggered, e.g., a QoS modification for the use of a newly negotiated codec.
* ベアラ変更がトリガーされたとき（たとえば、新しくネゴシエートされたコーデックを使用するための QoS 変更）。
In some scenarios, the bearer modification may be triggered by the proxy upon reception of a Session Description Protocol (SDP) answer within the SIP 2xx response to the SIP INVITE request. In such case, the NPLI needs to be provided within the SIP ACK request. However, [RFC7315] does not allow the usage of the P-Access-Network-Info header field in a SIP ACK request.
一部のシナリオでは、SIP INVITE 要求に対する SIP 2xx 応答内でセッション記述プロトコル (SDP) 応答を受信すると、プロキシによってベアラー変更がトリガーされる場合があります。このような場合、NPLI を SIP ACK 要求内で提供する必要があります。ただし、[RFC7315] では、SIP ACK リクエストでの P-Access-Network-Info ヘッダーフィールドの使用は許可されていません。
Upon reception of the SDP answer within a 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 を取得する手順を開始し、SIP ACK リクエストに NPLI を含む P-Access-Network-Info ヘッダー フィールドを含めることができます。
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 要求には含まれません。
[RFC7315] 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.
[RFC7315] は、SIP ダイアログまたはダイアログ外のトランザクションに関与するさまざまなオペレーターが、P-Charging-Vector ヘッダーフィールド内でオペレーター識別情報を交換することによって相互に識別できるようにするためのオペレーター間識別子 (IOI) を定義しています。
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, [RFC7315] does not allow the usage of the P-Charging-Vector header field in the SIP ACK request.
トランジット オペレータは、SIP メソッドおよびリクエストの方向ごとに個別に選択できます。トランジット ネットワークは個々の SIP リクエストに関する情報のみを持ち、トランジット ネットワークの選択はリクエストごとに独立して決定され、負荷、コスト、パーセンテージ、時刻、その他の要因に基づいて行われます。このため、トランジット IOI 情報を伝送する P-Charging-Vector ヘッダー フィールドが各 SIP 要求と応答に含まれる必要があります。ただし、[RFC7315] では、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 non-2xx responses.
P-Charging-Vector ヘッダー フィールドは、非 2xx 応答によってトリガーされる SIP ACK 要求には含まれません。
This section contains the update to Section 5.7 of [RFC7315], in order to implement the misalignment fixes and the 3GPP requirements described in Section 2. In the old text, blank lines have been added for readability.
このセクションには、セクション 2 で説明されている位置ずれの修正と 3GPP 要件を実装するための、[RFC7315] のセクション 5.7 の更新が含まれています。古いテキストでは、読みやすくするために空行が追加されています。
Old text:
古いテキスト:
The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses [sic].
P-Associated-URI ヘッダー フィールドは、SIP REGISTER メソッドと 2xx 応答に表示されます [原文ママ]。
The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all responses.
P-Called-Party-ID ヘッダー フィールドは、SIP INVITE、OPTIONS、PUBLISH、SUBSCRIBE、および MESSAGE メソッドとすべての応答に表示されます。
The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses.
P-Visited-Network-ID ヘッダー フィールドは、ACK、BYE、CANCEL を除くすべての SIP メソッドとすべての応答に表示できます。
The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL.
P-Access-Network-Info ヘッダー フィールドは、ACK と CANCEL を除くすべての SIP メソッドに表示できます。
The P-Charging-Vector header field can appear in all SIP methods except CANCEL.
P-Charging-Vector ヘッダー フィールドは、CANCEL を除くすべての SIP メソッドに表示できます。
The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL.
P-Charging-Function-Addresses ヘッダー フィールドは、ACK と CANCEL を除くすべての SIP メソッドに表示できます。
New text:
新しいテキスト:
The P-Associated-URI header field can appear in SIP REGISTER 2xx responses.
P-Associated-URI ヘッダー フィールドは、SIP REGISTER 2xx 応答に表示されることがあります。
The P-Called-Party-ID header field can appear in the SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE requests.
P-Called-Party-ID ヘッダー フィールドは、SIP INVITE、OPTIONS、PUBLISH、REFER、SUBSCRIBE、および MESSAGE 要求に表示されます。
The P-Visited-Network-ID header field can appear in all SIP requests and the associated non-100 response message except in ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, UPDATE.
P-Visited-Network-ID ヘッダー フィールドは、ACK、BYE、CANCEL、NOTIFY、PRACK、INFO、UPDATE を除くすべての SIP 要求および関連する 100 以外の応答メッセージに表示できます。
The P-Access-Network-Info header field can appear in all SIP requests and the associated non-100 responses, except in CANCEL requests, CANCEL responses, and ACK methods triggered by non-2xx responses.
P-Access-Network-Info ヘッダー フィールドは、CANCEL 要求、CANCEL 応答、および 2xx 以外の応答によってトリガーされる ACK メソッドを除く、すべての SIP 要求および関連する 100 以外の応答に表示されます。
The P-Charging-Vector header field can appear in all SIP requests and the associated non-100 responses, except in CANCEL requests, CANCEL responses, and ACK requests triggered by non-2xx responses.
P-Charging-Vector ヘッダー フィールドは、CANCEL 要求、CANCEL 応答、および 2xx 以外の応答によってトリガーされる ACK 要求を除く、すべての SIP 要求および関連する 100 以外の応答に表示されます。
The P-Charging-Function-Addresses header field can appear in all SIP methods and the associated non-100 responses, except in CANCEL requests, CANCEL responses, and ACK requests.
P-Charging-Function-Addresses ヘッダー フィールドは、CANCEL 要求、CANCEL 応答、および ACK 要求を除く、すべての SIP メソッドおよび関連する 100 以外の応答に表示できます。
This document has no IANA actions.
この文書には IANA のアクションはありません。
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 Section 6.4 of [RFC7315]. The security and privacy considerations for the P-Visited-Network-ID header field are similar to those for the other SIP responses discussed in Section 6.3 of [RFC7315].
これらの「P-」ヘッダフィールドのセキュリティに関する考慮事項は、[RFC7315] で定義されています。この仕様により、以前は許可されていなかったメッセージ内に一部のヘッダーフィールドが存在することが許可され、[RFC7315] で説明されているセキュリティ上の考慮事項と前提条件 (例えば、信頼できるエンティティへの情報の送信のみに関する) もそれらのメッセージに適用されます。さらに、この仕様では、以前は許可されていた一部のヘッダー フィールドをメッセージに含めることも禁止します。これによってセキュリティ上の問題が発生することはありませんが、実装者は実装がこの文書に従って更新されていない可能性があることを認識し、メッセージ内でヘッダー フィールドが発生する場合、または発生しない場合 (または発生すべきではないメッセージで発生する場合) に適切な措置を講じる必要があります。このドキュメントでは、ACK リクエストに P-Access-Network-Info を含める機能を追加します。[RFC7315] に記載されているように、P-Access-Network-Info には、ユーザーの位置情報などのプライバシーに関わる機密情報が含まれる場合があります。ACK リクエストにおける P-Access-Network-Info のセキュリティとプライバシーの考慮事項は、[RFC7315] のセクション 6.4 で説明されている他の SIP リクエストの考慮事項と同様です。P-Visited-Network-ID ヘッダーフィールドのセキュリティとプライバシーに関する考慮事項は、[RFC7315] のセクション 6.3 で説明されている他の SIP 応答に関する考慮事項と同様です。
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 [TS24.229], the updates are not seen to cause backward-compatibility concerns.
「P-」ヘッダー フィールドは主に 3GPP によって定義されたネットワークで使用されている (そしてほとんどの場合、そのネットワークに対してのみ定義されている) ため、この文書で定義されている更新は [TS24.229] ですでに定義されているため、更新によって下位互換性の問題が生じるとは考えられません。
The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses. Specifically, any SIP response message, with the exception of a 100 (Trying) response, may include a P-Visited-Network-ID header field.
RFC 7976 に関連する変更には、SIP 応答への P-Visited-Network-ID ヘッダー フィールドの組み込みが含まれます。具体的には、100 (Trying) 応答を除くすべての SIP 応答メッセージには、P-Visited-Network-ID ヘッダー フィールドが含まれる場合があります。
[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>.
[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, <https://www.rfc-editor.org/info/rfc7315>.
[TS23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=821>.
[TS24.229] 3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", 3GPP TS 24.229,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1055>.
[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,
<https://www.rfc-editor.org/info/rfc3455>.
The author would like to acknowledge the constructive feedback provided by Michael Kreipl, Charles Eckel, and Paul Kyzivat.
著者は、Michael Kreipl、Charles Eckel、Paul Kyzivat から提供された建設的なフィードバックに感謝したいと思います。
Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach for providing comments on an earlier draft version of this document.
この文書の初期の草案バージョンにコメントを提供してくださった Paul Kyzivat、Jean Mahoney、Ben Campbell、および Adam Roach に感謝します。
Christer Holmberg
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland
Email: christer.holmberg@ericsson.com
Nevenka Biondic
ETSI
650 route des Lucioles
06921 Sophia Antipolis cedex
France
Email: Nevenka.Biondic@etsi.org
Gonzalo Salgueiro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
United States of America
Email: gsalguei@cisco.com
Roland Jesske
Deutsche Telekom
Deutsche-Telekom-Allee 9
64295 Darmstadt
Germany
Email: r.jesske@telekom.de
URI: www.telekom.com