[要約] 要約：RFC 7315は、3GPPによるSession Initiation Protocol（SIP）のためのプライベートヘッダ（P-Header）拡張に関する仕様です。 目的：このRFCの目的は、3GPPネットワークでのSIP通信において、プライベートヘッダの使用と拡張を定義することです。
Internet Engineering Task Force (IETF) R. Jesske
Request for Comments: 7315 Deutsche Telekom
Obsoletes: 3455 K. Drage
Category: Informational Alcatel-Lucent
ISSN: 2070-1721 C. Holmberg
Ericsson
July 2014
Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP
3GPPのセッション開始プロトコル（SIP）のプライベートヘッダー（Pヘッダー）拡張
Abstract
概要
This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.
このドキュメントでは、3GPPで使用されるプライベートヘッダー（Pヘッダー）セッション開始プロトコル（SIP）フィールドのセットと、特定の環境に限定される適用性について説明します。 Pヘッダーフィールドは、課金や通話が通過するネットワークに関する情報など、パートナーが実装するネットワーク内のさまざまな目的で使用されます。このドキュメントはRFC 3455を廃止します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc7315.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7315で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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. Overall Applicability ...........................................3
2. Conventions .....................................................3
3. Overview ........................................................3
4. SIP Private Header Fields .......................................4
4.1. The P-Associated-URI Header Field ..........................4
4.1.1. Applicability Statement for the
P-Associated-URI Header Field .......................5
4.1.2. Usage of the P-Associated-URI Header Field ..........5
4.2. The P-Called-Party-ID Header Field .........................6
4.2.1. Applicability Statement for the
P-Called-Party-ID Header Field .....................10
4.2.2. Usage of the P-Called-Party-ID Header Field ........11
4.3. The P-Visited-Network-ID Header Field .....................12
4.3.1. Applicability Statement for the
P-Visited-Network-ID Header Field ..................12
4.3.2. Usage of the P-Visited-Network-ID Header Field .....13
4.4. The P-Access-Network-Info Header Field ....................17
4.4.1. Applicability Statement for the
P-Access-Network-Info Header Field .................18
4.4.2. Usage of the P-Access-Network-Info Header ..........18
4.5. The P-Charging-Function-Addresses Header Field ............19
4.5.1. Applicability Statement for the
P-Charging-Function-Addresses Header Field .........20
4.5.2. Usage of the P-Charging-Function-Addresses
Header Field .......................................21
4.6. The P-Charging-Vector Header Field ........................23
4.6.1. Applicability Statement for the
P-Charging-Vector Header Field .....................25
4.6.2. Usage of the P-Charging-Vector Header Field ........25
4.6.3. Usage of the transit-ioi ...........................27
4.6.4. Usage of the related-icid ..........................28
5. Formal Syntax ..................................................28
5.1. P-Associated-URI Header Syntax ............................29
5.2. P-Called-Party-ID Header Syntax ...........................29
5.3. P-Visited-Network-ID Header Syntax ........................29
5.4. P-Access-Network-Info Header Syntax .......................29
5.5. P-Charging-Function-Addresses Header Syntax ...............31
5.6. P-Charging-Vector Header Syntax ...........................32
5.7. New Headers ...............................................33
6. Security Considerations ........................................33
6.1. P-Associated-URI Header Field .............................33
6.2. P-Called-Party-ID Header Field ............................34
6.3. P-Visited-Network-ID Header Field .........................34
6.4. P-Access-Network-Info Header Field ........................35
6.5. P-Charging-Function-Addresses Header Field ................36
6.6. P-Charging-Vector Header Field ............................36
7. IANA Considerations ............................................37
8. Contributors and Acknowledgements ..............................38
9. References .....................................................39
9.1. Normative References ......................................39
9.2. Informative References ....................................39
Appendix A. Changes from RFC 3455 .................................41
The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions apply only to private networks and are not appropriate for use in an Internet environment. The mechanisms specified here were designed to satisfy the requirements specified in the 3GPP Release 5 requirements on SIP [RFC4083] for which either no general-purpose solution was planned (where insufficient operational experience was available to understand if a general solution would be needed) or for which a more general solution is not yet mature. For more details about the assumptions made about these extensions, consult the Applicability subsection for each extension.
このドキュメントで指定されているSIP拡張は、ネットワークトポロジ、SIPと下位層の間のリンケージ、および推移的な信頼の可用性に関して特定の前提を設けています。これらの仮定はプライベートネットワークにのみ適用され、インターネット環境での使用には適していません。ここで指定されたメカニズムは、SIP [RFC4083]の3GPPリリース5要件で指定された要件を満たすように設計されており、汎用ソリューションが計画されていなかった（汎用ソリューションが必要かどうかを理解するのに十分な運用経験がなかった）またはより一般的なソリューションはまだ成熟していない。これらの拡張について行われた仮定の詳細については、各拡張の「適用性」サブセクションを参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The 3GPP uses SIP as the protocol to establish and tear down multimedia sessions in the context of its IP Multimedia Subsystem (IMS), as described in the 3GPP TS 23.228 [TS23.228] and 3GPP TS
3GPP TS 23.228 [TS23.228]および3GPP TSで説明されているように、3GPPはプロトコルとしてSIPを使用して、IPマルチメディアサブシステム（IMS）のコンテキストでマルチメディアセッションを確立および破棄します。
24.229 [TS24.229]. RFC 3455 [RFC3455] defines SIP private header extensions (referred to as P-headers) that are required by the 3GPP specification. Note that the requirements for these extensions are documented in RFC 4083 [RFC4083]. This document obsoletes RFC 3455 [RFC3455]. This document updates existing P-header descriptions to address additional requirements that are needed for 3GPP Release 11. Each of the P-headers is described in the sections below.
24.229 [TS24.229]。 RFC 3455 [RFC3455]は、3GPP仕様で必要とされるSIPプライベートヘッダー拡張（Pヘッダーと呼ばれる）を定義しています。これらの拡張機能の要件はRFC 4083 [RFC4083]に記載されていることに注意してください。このドキュメントはRFC 3455 [RFC3455]を廃止します。このドキュメントでは、既存のPヘッダーの説明を更新して、3GPPリリース11に必要な追加の要件に対処します。各Pヘッダーについては、以下のセクションで説明します。
This extension allows a registrar to return a set of associated URIs for a registered SIP address-of-record. We define the P-Associated-URI header field, used in the 200 (OK) response to a REGISTER request. The P-Associated-URI header field contains the set of associated URIs that are associated with the registered address-of-record.
この拡張機能により、レジストラは、登録されたSIPレコードのアドレスに関連付けられた一連のURIを返すことができます。 P-Associated-URIヘッダーフィールドを定義します。これは、REGISTERリクエストに対する200（OK）応答で使用されます。 P-Associated-URIヘッダーフィールドには、登録されたレコードのアドレスに関連付けられている一連の関連付けられたURIが含まれています。
In addition to the address-of-record, an associated URI is a URI that the service provider has allocated to a user. A registrar contains information that allows zero or more URIs to be associated with an address-of-record. Usually, all these URIs (the address-of-record and the associated URIs) are allocated for the usage of a particular user. This extension to SIP allows the User Agent Client (UAC) to know, upon a successful authenticated registration, which other URIs, if any, the service provider has associated with an address-of-record URI.
レコードのアドレスに加えて、関連付けられたURIは、サービスプロバイダーがユーザーに割り当てたURIです。レジストラには、0個以上のURIをレコードのアドレスに関連付けることができる情報が含まれています。通常、これらのすべてのURI（レコードのアドレスと関連するURI）は、特定のユーザーの使用に割り当てられます。このSIPの拡張により、ユーザーエージェントクライアント（UAC）は、認証された登録が成功したときに、サービスプロバイダーがレコードのアドレスURIに関連付けた他のURIがあればそれを知ることができます。
Note that, in standard SIP usage [RFC3261], the registrar does not register the associated URIs on behalf of the user. Only the address-of-record that is present in the To header field of the REGISTER is registered and bound to the contact address. The only information conveyed is that the registrar is aware of other URIs that can be used by the same user.
標準のSIPの使用法[RFC3261]では、レジストラはユーザーに代わって関連するURIを登録しないことに注意してください。 REGISTERのToヘッダーフィールドにあるレコードのアドレスのみが登録され、連絡先アドレスにバインドされます。伝えられる唯一の情報は、レジストラが同じユーザーが使用できる他のURIを認識していることです。
A situation may be possible, however, in which an application server (or even the registrar itself) registers any of the associated URIs on behalf of the user by means of a third-party registration. However, this third-party registration is out of the scope of this document. A UAC MUST NOT assume that the associated URIs are registered.
ただし、アプリケーションサーバー（またはレジストラ自体）が、サードパーティの登録によってユーザーに代わって関連するURIのいずれかを登録する状況も考えられます。ただし、このサードパーティの登録はこのドキュメントの範囲外です。 UACは、関連付けられたURIが登録されていると想定してはなりません。
If a UAC wants to check whether any of the associated URIs is registered, it can do so by mechanisms specified outside this document, e.g., the UA MAY send a REGISTER request with the To header field value set to any of the associated URIs and without a Contact header field. The 200 (OK) response will include a Contact header field with the list of addresses-of-record that have been registered with contact addresses. If the associated URI is not registered, the UA MAY register it prior to its utilization.
UACが関連するURIのいずれかが登録されているかどうかを確認する場合、このドキュメントの外部で指定されているメカニズムによって確認できます。たとえば、UAは、関連するURIのいずれかに設定されているToヘッダーフィールド値を使用してREGISTERリクエストを送信できます。 Contactヘッダーフィールド。 200（OK）応答には、連絡先アドレスに登録されているレコードのアドレスのリストを含むContactヘッダーフィールドが含まれます。関連付けられたURIが登録されていない場合、UAはそれを利用する前に登録してもよい（MAY）。
The P-Associated-URI header field is applicable in SIP networks where the SIP provider allows a set of identities that a user can claim (in header fields like the From header field) in requests that the UA generates. Furthermore, it assumes that the provider knows the entire set of identities that a user can legitimately claim and that the user is willing to restrict its claimed identities to that set. This is in contrast to normal SIP usage, where the From header field is explicitly an end-user-specified field.
P-Associated-URIヘッダーフィールドは、SIPプロバイダーが、UAが生成するリクエストでユーザーが（Fromヘッダーフィールドのようなヘッダーフィールドで）要求できるIDのセットを許可するSIPネットワークに適用できます。さらに、プロバイダーは、ユーザーが合法的に主張できるIDのセット全体を知っており、ユーザーは要求されたIDをそのセットに制限しても構わないと想定しています。これは、Fromヘッダーフィールドが明示的にエンドユーザー指定のフィールドである通常のSIPの使用とは対照的です。
The registrar inserts the P-Associated-URI header field into the 200 (OK) response to a REGISTER request. The header field value is populated with a list of URIs that are associated to the address-of-record.
レジストラは、REGISTER要求に対する200（OK）応答にP-Associated-URIヘッダーフィールドを挿入します。ヘッダーフィールドの値には、レコードのアドレスに関連付けられているURIのリストが読み込まれます。
If the registrar supports the P-Associated-URI header field extension and there is at least one associated URI, then the registrar MUST insert the P-Associated-URI header field in all the 200 (OK) responses to a REGISTER request. The absence of a P-Associated-URI header field indicates that there are no associated URIs for the registered address-of-record.
レジストラがP-Associated-URIヘッダーフィールド拡張をサポートし、関連付けられたURIが少なくとも1つある場合、レジストラは、REGISTERリクエストに対するすべての200（OK）応答にP-Associated-URIヘッダーフィールドを挿入する必要があります。 P-Associated-URIヘッダーフィールドがない場合は、登録されたレコードのアドレスに関連付けられたURIがないことを示します。
A UAC may receive a P-Associated-URI header field in the 200 (OK) response for a REGISTER request. The presence of a header field in the 200 (OK) response for a REGISTER request implies that the extension is supported at the registrar.
UACは、REGISTER要求の200（OK）応答でP-Associated-URIヘッダーフィールドを受信する場合があります。 REGISTER要求の200（OK）応答にヘッダーフィールドが存在することは、拡張機能がレジストラでサポートされていることを意味します。
The header field value contains a list of one or more associated URIs to the address-of-record. The UAC MAY use any of the associated URIs to populate the From header field value, or any other SIP header field value that provides information of the identity of the calling party, in a subsequent request.
ヘッダーフィールド値には、レコードのアドレスに関連付けられた1つ以上のURIのリストが含まれます。 UACは、関連付けられたURIのいずれかを使用して、Fromヘッダーフィールド値、または後続のリクエストで発信者のIDの情報を提供するその他のSIPヘッダーフィールド値を設定できます。
The UAC MAY check whether or not the associated URI is registered. This check can be done, e.g., by populating the To header field value in a REGISTER request sent to the registrar and without a Contact header field. The 200 (OK) response will include a Contact header field with the list of address-of-record that have been registered with contact addresses. As described in SIP [RFC3261], the 200 (OK) response may contain a Contact header field with zero or more values (zero meaning the address-of-record is not registered).
UACは、関連付けられたURIが登録されているかどうかを確認できます（MAY）。このチェックは、たとえば、レジストラに送信されたREGISTERリクエストのToヘッダーフィールドの値を、Contactヘッダーフィールドなしで入力することで実行できます。 200（OK）応答には、連絡先アドレスに登録されているレコードのアドレスのリストを含むContactヘッダーフィールドが含まれます。 SIP [RFC3261]で説明されているように、200（OK）応答には、ゼロ以上の値（レコードのアドレスが登録されていないことを意味するゼロ）のContactヘッダーフィールドが含まれる場合があります。
A registrar that receives and authorizes a REGISTER request MAY associate zero or more URIs with the registered address-of-record.
REGISTERリクエストを受信して承認するレジストラは、0個以上のURIを登録されたレコードのアドレスに関連付けることができます（MAY）。
If the address-of-record under registration does not have any associated URIs, the P-Associated-URI header field SHALL NOT be included.
登録中のレコードのアドレスに関連付けられたURIがない場合、P-Associated-URIヘッダーフィールドは含まれません。
Otherwise, a registrar that supports this specification MUST include a P-Associated-URI header field in the 200 (OK) response to a REGISTER request that contains a contact header. The header field MUST be populated with a comma-separated list of URIs that are associated to the address-of-record under registration.
それ以外の場合、この仕様をサポートするレジストラは、連絡先ヘッダーを含むREGISTER要求への200（OK）応答にP-Associated-URIヘッダーフィールドを含める必要があります。ヘッダーフィールドには、登録時にレコードのアドレスに関連付けられているURIのコンマ区切りのリストを入力する必要があります。
This header is not intended to be used by proxies -- a proxy does not add, read, modify, or delete the header field; therefore, any proxy MUST relay this header field unchanged.
このヘッダーは、プロキシによる使用を意図したものではありません。プロキシはヘッダーフィールドを追加、読み取り、変更、または削除しません。したがって、プロキシはこのヘッダーフィールドを変更せずにリレーする必要があります。
A proxy server inserts a P-Called-Party-ID header field, typically in an INVITE request, en route to its destination. The header is populated with the Request-URI received by the proxy in the request. The User Agent Server (UAS) identifies to which address-of-record, out of several registered addresses-of-record, the invitation was sent (for example, the user may be simultaneously using one personal SIP URI and one business SIP URI to receive invitation to sessions). The UAS can use the information to render different distinctive audiovisual alerting tones, depending on the URI used to receive the invitation to the session.
プロキシサーバーは、宛先への途中で、通常はINVITEリクエストにP-Called-Party-IDヘッダーフィールドを挿入します。ヘッダーには、リクエストでプロキシが受信したRequest-URIが入力されます。ユーザーエージェントサーバー（UAS）は、登録されたいくつかの記録されたアドレスのうち、招待が送信された記録のアドレスを識別します（たとえば、ユーザーは、1つの個人用SIP URIと1つのビジネスSIP URIを同時に使用して、セッションへの招待状を受け取る）。 UASはこの情報を使用して、セッションへの招待を受信するために使用されるURIに応じて、異なる独特の視聴覚警告トーンをレンダリングできます。
Users in the 3GPP IP Multimedia Subsystem (IMS) may get one or several SIP URIs (address-of-record) to identify the user. For example, a user may get one business SIP URI and one personal SIP URI. As an example of utilization, the user may make available the business SIP URI to coworkers and may make available the personal SIP URI to members of the family.
3GPP IPマルチメディアサブシステム（IMS）のユーザーは、ユーザーを識別するために1つまたは複数のSIP URI（レコードのアドレス）を取得できます。たとえば、ユーザーは1つのビジネスSIP URIと1つの個人SIP URIを取得できます。利用の例として、ユーザーは、ビジネスSIP URIを同僚に提供し、個人のSIP URIを家族のメンバーに提供します。
At a certain point in time, both the business SIP URI and the personal SIP URI are registered in the SIP registrar, so both URIs can receive invitations to new sessions. When the user receives an invitation to join a session, he/she should be aware of which of the registered SIP URIs this session was sent to.
ある時点で、ビジネスSIP URIとパーソナルSIP URIの両方がSIPレジストラーに登録されるため、両方のURIが新しいセッションへの招待を受信できます。ユーザーは、セッションに参加するための招待状を受け取ったときに、このセッションが送信された登録済みのSIP URIを認識する必要があります。
This requirement is stated in the 3GPP Release 5 requirements on SIP [RFC4083].
この要件は、SIPに関する3GPPリリース5の要件[RFC4083]に記載されています。
The problem arises during the terminating side of a session establishment. At that time, the SIP proxy that is serving a UA gets an INVITE request, and the SIP server retargets the SIP URI that is present in the Request-URI, and replaces that SIP URI with the SIP URI published by the user in the Contact header field of the REGISTER request at registration time.
この問題は、セッション確立の終了側で発生します。そのとき、UAにサービスを提供しているSIPプロキシはINVITE要求を取得し、SIPサーバーはRequest-URIに存在するSIP URIを再ターゲットし、そのSIP URIをユーザーが連絡先で公開したSIP URIに置き換えます登録時のREGISTERリクエストのヘッダーフィールド。
One can argue that the To header field conveys the semantics of the called user, and therefore, this extension to SIP is not needed. Although the To header field in SIP may convey the called party ID in most situations, there are two particular cases when the above assumption is not correct:
Toヘッダーフィールドは、呼び出されたユーザーのセマンティクスを伝えるため、SIPへのこの拡張は不要であると主張できます。 SIPのToヘッダーフィールドは、ほとんどの状況で着信者IDを伝える可能性がありますが、上記の仮定が正しくない2つの特定のケースがあります。
1. The session has been forwarded, redirected, etc., by previous SIP proxies, before arriving to the proxy that is serving the called user.
1. セッションは、呼び出されたユーザーにサービスを提供しているプロキシに到達する前に、以前のSIPプロキシによって転送、リダイレクトなどされています。
2. The UAC builds an INVITE request and the To header field is not the same as the Request-URI.
2. UACはINVITE要求を作成し、ToヘッダーフィールドはRequest-URIと同じではありません。
The problem of using the To header field is that this field is populated by the UAC and not modified by proxies in the path. If the UAC, for any reason, did not populate the To header field with the address-of-record of the destination user, then the destination user is not able to distinguish to which address-of-record the session was destined.
Toヘッダーフィールドを使用する際の問題は、このフィールドがUACによって入力され、パス内のプロキシによって変更されないことです。何らかの理由でUACが宛先ヘッダーフィールドに宛先ユーザーのレコードのアドレスを入力しなかった場合、宛先ユーザーは、セッションの宛先となったレコードのアドレスを区別できません。
Another possible solution to the problem is built upon the differentiation of the Contact header field value between different address-of-record at registration time. The UA can differentiate each address-of-record it registers by assigning a different Contact header field value. For example, when the UA registers the address-of-record sip:id1, the Contact header field value can be sip:id1@ua, while the registration of the address-of-record sip:id2 can be bound to the Contact header field value sip:id2@ua.
この問題の別の可能な解決策は、登録時に異なるレコードのアドレス間でContactヘッダーフィールド値を区別することです。 UAは、異なるContactヘッダーフィールド値を割り当てることにより、登録する各レコードアドレスを区別できます。たとえば、UAがレコードのアドレスsip：id1を登録する場合、Contactヘッダーフィールドの値はsip：id1 @ uaにすることができますが、レコードのアドレスsip：id2の登録はContactヘッダーにバインドできますフィールド値sip：id2 @ ua。
The solution described above assumes that the UA explicitly registers each of its addresses-of-record, and therefore, it has full control over the contact address values assigned to each registration.
上記のソリューションは、UAがレコードの各アドレスを明示的に登録することを前提としているため、各登録に割り当てられた連絡先アドレスの値を完全に制御できます。
However, if the UA does not have full control of its registered addresses-of-record, because of, e.g., a third-party registration, the solution does not work. This may be the case of the 3GPP registration, where the UA may have previously indicated to the network, by means outside of SIP, that some other addresses-of-record may be automatically registered when the UA registers a particular address-of-record. The requirement is covered in the 3GPP Release 5 requirements on SIP [RFC4083].
ただし、サードパーティの登録などにより、UAが登録されたレコードのアドレスを完全に制御できない場合、ソリューションは機能しません。これは、UAがSIPの外部で以前にネットワークに示した3GPP登録の場合である可能性があります。UAが特定のレコードのアドレスを登録すると、他のいくつかのレコードのアドレスが自動的に登録される場合があります。 。この要件は、SIPの3GPPリリース5要件[RFC4083]でカバーされています。
In the next paragraphs, we show an example of the problem, in the case in which there has been some sort of call forwarding in the session, so that the UAC is not aware of the intended destination URI in the current INVITE request.
次の段落では、セッションになんらかのコール転送があり、UACが現在のINVITEリクエストの目的の宛先URIを認識しない場合の問題の例を示します。
We assume that a UA is registering to its proxy (P1).
UAがプロキシ（P1）に登録していると仮定します。
Scenario UA --- P1
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
The user also registers his personal URI to his/her registrar.
また、ユーザーは自分の個人URIをレジストラに登録します。
F2 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1827 REGISTER
Contact: <sip:user1@192.0.2.4>
Later, the proxy/registrar (P1) receives an INVITE request from another proxy (P2) destined to the user's business SIP address-of-record. We assume that this INVITE request has undergone some sort of forwarding in the past, and as such, the To header field is not populated with the SIP URI of the user. In this case, we assume that the session was initially addressed to sip:other-user@othernetwork.com. The SIP server at othernetwork.com has forwarded this session to sip:user1-business@example.com.
その後、プロキシ/レジストラ（P1）は、ユーザーのビジネスSIPのレコードのアドレス宛ての別のプロキシ（P2）からのINVITE要求を受信します。このINVITEリクエストは過去になんらかの転送を受けたため、ToヘッダーフィールドにはユーザーのSIP URIが入力されていないと想定しています。この場合、セッションの最初の宛先はsip：other-user@othernetwork.comであると想定しています。 othernetwork.comのSIPサーバーは、このセッションをsip：user1-business@example.comに転送しました。
Scenario UA --- P1 --- P2
F3 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
The proxy P1 retargets the user and replaces the Request-URI with the SIP URI published during registration time in the Contact header field value.
プロキシP1はユーザーを再ターゲットし、Request-URIをContactヘッダーフィールド値の登録時に公開されたSIP URIに置き換えます。
F4 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
When the UAS receives the INVITE request, it cannot determine whether it got the session invitation due to his registration of the business or the personal address-of-record. Neither the UAS nor proxies / application servers can provide this user a service based on the destination address-of-record of the session.
UASがINVITE要求を受信すると、ビジネスの登録または個人の記録用アドレスが原因で、セッション招待を受け取ったかどうかを判断できません。 UASもプロキシ/アプリケーションサーバーも、セッションの宛先レコードのアドレスに基づいて、このユーザーにサービスを提供できません。
We solve this problem by allowing the proxy that is responsible for the home domain (as defined in SIP) of the user to insert a P-Called-Party-ID header field that identifies the address-of-record to which this session is destined.
この問題は、ユーザーのホームドメイン（SIPで定義）を担当するプロキシが、このセッションの宛先であるレコードのアドレスを識別するP-Called-Party-IDヘッダーフィールドを挿入できるようにすることで解決します。
If this SIP extension is used, the proxy serving the called user will get the message flow F5, it will populate the P-Called-Party-ID header field in message flow F6 with the contents of the Request-URI in F4. This is show in flows F5 and F6 below:
このSIP拡張が使用される場合、呼び出されたユーザーにサービスを提供するプロキシはメッセージフローF5を取得し、メッセージフローF6のP-Called-Party-IDヘッダーフィールドにF4のRequest-URIの内容を入力します。これは、以下のフローF5およびF6で表示されます。
F5 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F6 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
P-Called-Party-ID: <sip:user1-business@example.com>
CSeq: 101 INVITE
When the UA receives the INVITE request F6, it can determine the intended address-of-record of the session and apply whatever service is needed for that address-of-record.
UAがINVITE要求F6を受信すると、セッションの目的のレコードのアドレスを決定し、そのレコードのアドレスに必要なサービスを適用できます。
The P-Called-Party-ID header field is applicable when the UAS needs to be aware of the intended address-of-record that was present in the Request-URI of the request, before the proxy retargets to the contact address. The UAS may be interested in applying different audiovisual alerting effects or other filtering services, depending on the intended destination of the request. It is especially valuable when the UAS has registered several addresses-of-record to his registrar, and therefore, the UAS is not aware of the address-of-record that was present in the INVITE request when it hit his proxy/registrar, unless this extension is used.
P-Called-Party-IDヘッダーフィールドは、プロキシが連絡先アドレスに再ターゲットする前に、UASが要求のRequest-URIに存在する意図されたレコードのアドレスを認識する必要がある場合に適用されます。 UASは、リクエストの目的の宛先に応じて、さまざまな視聴覚警告効果やその他のフィルタリングサービスを適用することに関心を持つ場合があります。 UASがいくつかのレコードアドレスをレジストラに登録している場合に特に価値があり、UASは、プロキシ/レジストラにヒットしたときにINVITEリクエストに存在していたレコードアドレスを認識しません。この拡張子が使用されます。
P-Called-Party-ID header field and the History-Info header field: At the time RFC 3455 [RFC3455] was written, the History-Info header field was a long way from specification. This header has now been specified and approved in RFC 7044 [RFC7044]. It is acknowledged that the History-Info header field will provide equivalent coverage to that of the P-Called-Party-ID header field. However, the P-Called-Party-ID header field is used entirely within the 3GPP system and does not appear to SIP entities outside that of a single 3GPP operator.
P-Called-Party-IDヘッダーフィールドとHistory-Infoヘッダーフィールド：RFC 3455 [RFC3455]が作成された時点では、History-Infoヘッダーフィールドは仕様から遠く離れていました。このヘッダーは現在、RFC 7044 [RFC7044]で指定および承認されています。 History-Infoヘッダーフィールドは、P-Called-Party-IDヘッダーフィールドと同等のカバレッジを提供することが認められています。ただし、P-Called-Party-IDヘッダーフィールドは完全に3GPPシステム内で使用され、単一の3GPPオペレーターの外部のSIPエンティティには表示されません。
The P-Called-Party-ID header field provides proxies and the UAS with the address-of-record that was present in the Request-URI of the request, before a proxy retargets the request. This information is intended to be used by subsequent proxies in the path or by the UAS.
P-Called-Party-IDヘッダーフィールドは、プロキシがリクエストを再ターゲットする前に、リクエストのRequest-URIに存在していたレコードのアドレスをプロキシとUASに提供します。この情報は、パス内の後続のプロキシまたはUASが使用することを目的としています。
Typically, a SIP proxy inserts the P-Called-Party-ID header field prior to retargetting the Request-URI in the SIP request. The header field value is populated with the contents of the Request-URI, prior to replacing it with the contact address.
通常、SIPプロキシは、SIPリクエストのRequest-URIをリターゲットする前に、P-Called-Party-IDヘッダーフィールドを挿入します。ヘッダーフィールドの値には、連絡先アドレスに置き換える前に、Request-URIの内容が入力されます。
A UAC MUST NOT insert a P-Called-Party-ID header field in any SIP request or response.
UACは、SIP要求または応答にP-Called-Party-IDヘッダーフィールドを挿入してはなりません（MUST NOT）。
A UAS may receive a SIP request that contains a P-Called-Party-ID header field. The header field will be populated with the address-of-record received by the proxy in the Request-URI of the request, prior to its forwarding to the UAS.
UASは、P-Called-Party-IDヘッダーフィールドを含むSIP要求を受信する場合があります。ヘッダーフィールドには、UASへの転送前に、リクエストのRequest-URIでプロキシが受信したレコードのアドレスが入力されます。
The UAS MAY use the value in the P-Called-Party-ID header field to provide services based on the called party URI, such as, e.g., filtering of calls depending on the date and time, distinctive presentation services, distinctive alerting tones, etc.
UASは、P-Called-Party-IDヘッダーフィールドの値を使用して、たとえば、日付と時刻に応じたコールのフィルタリング、特有のプレゼンテーションサービス、特有のアラートトーンなど、着信側URIに基づいたサービスを提供できます。等
A proxy that has access to the contact information of the user can insert a P-Called-Party-ID header field in any of the requests indicated in Section 5.7. When included, the proxy MUST populate the header field value with the contents of the Request-URI present in the SIP request that the proxy received.
ユーザーの連絡先情報にアクセスできるプロキシは、セクション5.7に示されているすべてのリクエストにP-Called-Party-IDヘッダーフィールドを挿入できます。含まれる場合、プロキシは、プロキシが受信したSIPリクエストに存在するRequest-URIのコンテンツをヘッダーフィールド値に入力する必要があります。
It is necessary that the proxy that inserts the P-Called-Party-ID header field has information about the user, in order to prevent a wrong delivery of the called party ID. This information may, for example, have been learned through a registration process.
P-Called-Party-IDヘッダーフィールドを挿入するプロキシは、着信者IDの誤った配信を防ぐために、ユーザーに関する情報を持っている必要があります。この情報は、たとえば、登録プロセスを通じて学習された可能性があります。
A proxy or application server that receives a request containing a P-Called-Party-ID header field MAY use the contents of the header field to provide a service to the user based on the URI of that header field value.
P-Called-Party-IDヘッダーフィールドを含むリクエストを受信するプロキシサーバーまたはアプリケーションサーバーは、ヘッダーフィールドの内容を使用して、そのヘッダーフィールド値のURIに基づいてユーザーにサービスを提供できます。
A SIP proxy MUST NOT insert a P-Called-Party-ID header field in REGISTER requests.
SIPプロキシは、REGISTERリクエストにP-Called-Party-IDヘッダーフィールドを挿入してはなりません（MUST NOT）。
3GPP networks are composed of a collection of so-called home networks, visited networks, and subscribers. A particular home network may have roaming agreements with one or more visited networks. The effect of this is that when a mobile terminal is roaming, it can use resources provided by the visited network in a transparent fashion.
3GPPネットワークは、いわゆるホームネットワーク、訪問先ネットワーク、および加入者の集まりで構成されています。特定のホームネットワークには、1つ以上の訪問先ネットワークとのローミング契約がある場合があります。この効果は、モバイル端末がローミングしているときに、訪問先ネットワークによって提供されるリソースを透過的に使用できることです。
One of the conditions for a home network to accept the registration of a UA roaming to a particular visited network, is the existence of a roaming agreement between the home and the visited network. There is a need to indicate to the home network which network is the visited network that is providing services to the roaming UA.
ホームネットワークが特定の訪問先ネットワークへのUAローミングの登録を受け入れる条件の1つは、ホームと訪問先ネットワークの間にローミング契約が存在することです。ローミングUAにサービスを提供している訪問先ネットワークがどのネットワークであるかをホームネットワークに示す必要があります。
3GPP user agents always register to the home network. The REGISTER request is proxied by one or more proxies located in the visited network towards the home network. For the sake of a simple approach, it seems sensible that the visited network includes an identification that is known to the home network. This identification should be globally unique, and it takes the form of a quoted-text string or a token. The home network may use this identification to verify the existence of a roaming agreement with the visited network, and to authorize the registration through that visited network.
3GPPユーザーエージェントは常にホームネットワークに登録します。 REGISTER要求は、訪問先ネットワークにある1つ以上のプロキシによってホームネットワークに向けてプロキシされます。単純なアプローチのために、訪問先ネットワークにホームネットワークに既知のIDが含まれているのは賢明なようです。このIDはグローバルに一意である必要があり、引用テキスト文字列またはトークンの形式を取ります。ホームネットワークは、この識別情報を使用して、訪問先ネットワークとのローミング契約の存在を確認し、その訪問先ネットワークを介した登録を承認します。
Note that P-Visited-Network-ID information reveals the location of the user, to the level of the coverage area of the visited network. For a national network, for example, P-Visited-Network-ID would reveal that the user is in the country in question.
P-Visited-Network-ID情報は、ユーザーの位置を、訪問先ネットワークのカバレッジエリアのレベルまで明らかにすることに注意してください。たとえば国内ネットワークの場合、P-Visited-Network-IDは、ユーザーが問題の国にいることを明らかにします。
4.3.1. Applicability Statement for the P-Visited-Network-ID Header Field
4.3.1. P-Visited-Network-IDヘッダーフィールドの適用性ステートメント
The P-Visited-Network-ID header field is applicable whenever the following circumstances are met:
P-Visited-Network-IDヘッダーフィールドは、次の状況が当てはまる場合はいつでも適用できます。
1. There is transitive trust in intermediate proxies between the UA and the home network proxy via established relationships between the home network and the visited network, supported by the use of standard security mechanisms, e.g., IPsec, Authentication and Key Agreement (AKA), or Transport Layer Security (TLS).
1. IPsec、認証と鍵合意（AKA）、トランスポートなどの標準セキュリティメカニズムの使用によりサポートされる、ホームネットワークと訪問先ネットワーク間の確立された関係を介して、UAとホームネットワークプロキシ間の中間プロキシに推移的な信頼があります。レイヤーセキュリティ（TLS）。
2. An endpoint is using resources provided by one or more visited networks (a network to which the user does not have a direct business relationship).
2. エンドポイントは、1つ以上の訪問済みネットワーク（ユーザーが直接的なビジネス関係を持たないネットワーク）によって提供されるリソースを使用しています。
3. A proxy that is located in one of the visited networks wants to be identified at the user's home network.
3. 訪問先ネットワークの1つにあるプロキシが、ユーザーのホームネットワークで識別されることを望んでいます。
4. There is no requirement that every visited network need be identified at the home network. Those networks that want to be identified make use of this extension. Those networks that do not want to be identified do nothing.
4. 訪問したすべてのネットワークをホームネットワークで識別する必要はありません。識別したいネットワークは、この拡張機能を利用します。識別されたくないネットワークは何もしません。
5. A commonly pre-agreed text string or token identifies the visited network at the home network.
5. 一般に事前に合意されたテキスト文字列またはトークンは、訪問先ネットワークをホームネットワークで識別します。
6. The UAC sends a REGISTER request or dialog-initiating request (e.g., INVITE request) or a standalone request outside a dialog (e.g., OPTIONS request) to a proxy in a visited network.
6. UACは、REGISTERリクエストまたはダイアログ開始リクエスト（例：INVITEリクエスト）、またはダイアログ外のスタンドアロンリクエスト（例：OPTIONSリクエスト）を、訪問先ネットワークのプロキシに送信します。
7. The request traverses, en route to its destination, a first proxy located in the visited network and a second proxy located in the home network or its destination is the registrar in the home network.
7. 要求は、その宛先に向かう途中で通過します。訪問先ネットワークにある最初のプロキシと、ホームネットワークにある2番目のプロキシまたはその宛先は、ホームネットワークのレジストラです。
8. The registrar or home proxy verifies and authorizes the usage of resources (e.g., proxies) in the visited network.
8. レジストラまたはホームプロキシは、訪問先ネットワークでのリソース（プロキシなど）の使用を確認および承認します。
The P-Visited-Network-ID header field assumes that there is trust relationship between a home network and one or more transited visited networks. It is possible for other proxies between the proxy in the visited network that inserts the header, and the registrar or the home proxy, to modify the value of P-Visited-Network-ID header field. Therefore, intermediaries participating in this mechanism MUST apply a hop-by-hop integrity-protection mechanism such as IPsec or other available mechanisms in order to prevent such attacks.
P-Visited-Network-IDヘッダーフィールドは、ホームネットワークと1つ以上の通過した訪問済みネットワークとの間に信頼関係があることを前提としています。ヘッダーを挿入する訪問先ネットワークのプロキシと、レジストラまたはホームプロキシの間の他のプロキシが、P-Visited-Network-IDヘッダーフィールドの値を変更する可能性があります。したがって、このメカニズムに参加する仲介者は、そのような攻撃を防ぐために、IPsecやその他の利用可能なメカニズムなどのホップバイホップの完全性保護メカニズムを適用する必要があります。
The P-Visited-Network-ID header field is used to convey to the registrar or home proxy in the home network the identifier of a visited network. The identifier is a text string or token that is known by both the registrar or the home proxy at the home network and the proxies in the visited network.
P-Visited-Network-IDヘッダーフィールドは、訪問先ネットワークの識別子をホームネットワークのレジストラまたはホームプロキシに伝えるために使用されます。識別子はテキスト文字列またはトークンであり、ホームネットワークのレジストラまたはホームプロキシと訪問先ネットワークのプロキシの両方で認識されています。
Typically, the home network authorizes the UA to roam to a particular visited network. This action requires an existing roaming agreement between the home and the visited network.
通常、ホームネットワークは、UAが特定の訪問済みネットワークにローミングすることを許可します。このアクションには、ホームと訪問したネットワーク間の既存のローミング合意が必要です。
While it is possible for a home network to identify one or more visited networks by inspecting the domain name in the Via header fields, this approach has a heavy dependency on DNS. It is an option for a proxy to populate the Via header field with an IP address, for example, and in the absence of a reverse DNS entry, the IP address will not convey the desired information.
ホームネットワークは、Viaヘッダーフィールドのドメイン名を調べることにより、1つ以上の訪問先ネットワークを識別することができますが、このアプローチはDNSに大きく依存します。たとえば、プロキシがViaヘッダーフィールドにIPアドレスを入力するオプションです。リバースDNSエントリがない場合、IPアドレスは必要な情報を伝えません。
Any SIP proxy in the visited network that receives any of the requests indicated in Section 5.7 MAY insert a P-Visited-Network-ID header field when it forwards the request. In case a REGISTER request or other request is traversing different administrative domains (e.g., different visited networks), a SIP proxy MAY insert a new P-Visited-Network-ID header field if the request does not contain a P-Visited-Network-ID header field with the same network identifier as its own network identifier (e.g., if the request has traversed other different administrative domains).
セクション5.7に示されている要求のいずれかを受信する、訪問先ネットワークのSIPプロキシは、要求を転送するときにP-Visited-Network-IDヘッダーフィールドを挿入できます（MAY）。 REGISTER要求または他の要求が異なる管理ドメイン（たとえば、異なる訪問先ネットワーク）を通過する場合、要求にP-Visited-Network-が含まれていない場合、SIPプロキシは新しいP-Visited-Network-IDヘッダーフィールドを挿入できます（MAY）。独自のネットワーク識別子と同じネットワーク識別子を持つIDヘッダーフィールド（たとえば、要求が他の異なる管理ドメインを通過した場合）。
Note also that, there is no requirement for this header field value to be readable in the proxies. Therefore, a first proxy MAY insert an encrypted header field that only the registrar can decrypt. If the request traverses a second proxy located in the same administrative domain as the first proxy, the second proxy may not be able to read the contents of the P-Visited-Network-ID header field. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header field, and therefore, it will insert a new P-Visited-Network-ID header field value (hopefully with the same identifier that the first proxy inserted, although perhaps, not encrypted). When the request arrives at the registrar or proxy in the home network, it will notice that the header field value is repeated (both the first and the second proxy inserted it). The decrypted values should be the same, because both proxies where part of the same administrative domain. While this situation is not desirable, it does not create any harm at the registrar or proxy in the home network.
また、このヘッダーフィールドの値がプロキシで読み取り可能である必要はないことにも注意してください。したがって、最初のプロキシは、レジストラのみが復号化できる暗号化されたヘッダーフィールドを挿入してもよい（MAY）。要求が最初のプロキシと同じ管理ドメインにある2番目のプロキシを通過する場合、2番目のプロキシはP-Visited-Network-IDヘッダーフィールドの内容を読み取ることができない場合があります。この状況では、2番目のプロキシは、訪問したネットワーク識別子がヘッダーフィールドの値にまだ存在していないと見なすため、新しいP-Visited-Network-IDヘッダーフィールド値を挿入します（できれば同じ識別子を使用）最初のプロキシが挿入されたが、おそらく暗号化されていなかった）リクエストがホームネットワークのレジストラまたはプロキシに到着すると、ヘッダーフィールドの値が繰り返されていることに気づきます（最初のプロキシと2番目のプロキシの両方で挿入されます）。両方のプロキシが同じ管理ドメインの一部であるので、復号化された値は同じである必要があります。この状況は望ましくありませんが、ホームネットワークのレジストラまたはプロキシに害を及ぼすことはありません。
The P-Visited-Network-ID header field is normally used at registration. However, this extension does not preclude other usages. For example, a proxy located in a visited network that does not maintain registration state MAY insert a P-Visited-Network-ID header field into any standalone request outside a dialog or a request that creates a dialog. At the time of writing this document, the only requests that create dialogs are INVITE requests [RFC3261], SUBSCRIBE requests [RFC6665], and REFER requests [RFC3515].
P-Visited-Network-IDヘッダーフィールドは通常、登録時に使用されます。ただし、この拡張機能は他の使用法を妨げるものではありません。たとえば、登録状態を維持しない訪問先ネットワークにあるプロキシは、P-Visited-Network-IDヘッダーフィールドを、ダイアログ外のスタンドアロンリクエストまたはダイアログを作成するリクエストに挿入してもよい（MAY）。このドキュメントの執筆時点では、ダイアログを作成する要求は、INVITE要求[RFC3261]、SUBSCRIBE要求[RFC6665]、およびREFER要求[RFC3515]のみです。
In order to avoid conflicts with identifiers, especially when the number of roaming agreements between networks increase, care must be taken when selecting the value of the P-Visited-Network-ID header field. The identifier MUST be globally unique to avoid duplications. Although there are many mechanisms to create globally unique identifiers across networks, one such mechanism is already in operation, and that is DNS. The P-Visited-Network-ID header field does not have any connection to DNS, but the values in the header field can be chosen from the DNS entry representing the domain name of the network. This guarantees the uniqueness of the value.
識別子との競合を回避するために、特にネットワーク間のローミング契約の数が増える場合は、P-Visited-Network-IDヘッダーフィールドの値を選択するときに注意が必要です。重複を避けるため、識別子はグローバルに一意である必要があります。ネットワーク全体でグローバルに一意の識別子を作成するメカニズムは多数ありますが、そのようなメカニズムの1つは既に動作しており、それがDNSです。 P-Visited-Network-IDヘッダーフィールドはDNSに接続していませんが、ヘッダーフィールドの値は、ネットワークのドメイン名を表すDNSエントリから選択できます。これにより、値の一意性が保証されます。
In the context of the network to which the header fields defined in this document apply, a User Agent has no knowledge of the P-Visited-Network-ID when sending the REGISTER request. Therefore, UACs MUST NOT insert a P-Visited-Network-ID header field in any SIP message.
このドキュメントで定義されているヘッダーフィールドが適用されるネットワークのコンテキストでは、ユーザーエージェントは、REGISTERリクエストを送信するときにP-Visited-Network-IDを認識していません。したがって、UACはSIPメッセージにP-Visited-Network-IDヘッダーフィールドを挿入してはなりません（MUST NOT）。
A SIP proxy that is located in a visited network MAY insert a P-Visited-Network-ID header field in any of the requests indicated in Section 5.7. The header field MUST be populated with the contents of a text string or a token that identifies the administrative domain of the network where the proxy is operating towards the user's home network.
訪問先ネットワークにあるSIPプロキシは、セクション5.7に示されているリクエストのいずれかにP-Visited-Network-IDヘッダーフィールドを挿入する場合があります。ヘッダーフィールドには、ユーザーのホームネットワークに向けてプロキシが動作しているネットワークの管理ドメインを識別するテキスト文字列またはトークンの内容を入力する必要があります。
A SIP proxy or registrar which is located in the home network can use the contents of the P-Visited-Network-ID header field as an identifier of one or more visited networks that the request traversed. The proxy or registrar in the home network may take local-policy-driven actions based on the existence (or nonexistence) of a roaming agreement between the home and the visited networks. This means, for instance, the authorization of the actions of the request is based on the contents of the P-Visited-Network-ID header field.
ホームネットワークにあるSIPプロキシまたはレジストラは、P-Visited-Network-IDヘッダーフィールドの内容を、要求が通過した1つ以上の訪問先ネットワークの識別子として使用できます。ホームネットワーク内のプロキシまたはレジストラは、ホームネットワークと訪問先ネットワーク間のローミング契約の存在（または非存在）に基づいて、ローカルポリシー主導のアクションを実行できます。これは、たとえば、要求のアクションの承認がP-Visited-Network-IDヘッダーフィールドの内容に基づいていることを意味します。
A SIP proxy that is located in the home network MUST delete this header field when forwarding the message outside the home network administrative domain, in order to retain the user's privacy.
ユーザーのプライバシーを保持するために、ホームネットワークにあるSIPプロキシは、ホームネットワークの管理ドメイン外にメッセージを転送するときに、このヘッダーフィールドを削除する必要があります。
A SIP proxy that is located in the home network SHOULD delete this header field when the home proxy has used the contents of the header field or the request is routed based on the called party's identification, even when the request is not forwarded outside the home network administrative domain.
ホームネットワークにあるSIPプロキシは、ホームプロキシがヘッダーフィールドの内容を使用した場合、または要求がホームネットワークの外部に転送されない場合でも、要求が着信者のIDに基づいてルーティングされた場合に、このヘッダーフィールドを削除する必要があります（SHOULD）。管理ドメイン。
Note that a received P-Visited-Network-ID from a UA is not allowed and MUST be deleted when the request is forwarded.
UAから受信したP-Visited-Network-IDは許可されておらず、要求が転送されるときに削除する必要があることに注意してください。
We present an example in the context of the scenario shown in the following network diagram:
次のネットワーク図に示すシナリオのコンテキストで例を示します。
Scenario UA --- P1 --- P2 --- REGISTRAR
This example shows the message sequence for a REGISTER transaction originating from UA eventually arriving at the REGISTRAR. P1 is an outbound proxy in the visited network for UA. In this case, P1 inserts the P-Visited-Network-ID header field. Then, P1 routes the REGISTER request to REGISTRAR via P2.
この例は、最終的にREGISTRARに到達する、UAから発信されたREGISTERトランザクションのメッセージシーケンスを示しています。 P1は、UAの訪問先ネットワークの発信プロキシです。この場合、P1はP-Visited-Network-IDヘッダーフィールドを挿入します。次に、P1はP2を介してREGISTER要求をREGISTRARにルーティングします。
Message sequence for REGISTER using P-Visited-Network-ID header field:
P-Visited-Network-IDヘッダーフィールドを使用したREGISTERのメッセージシーケンス：
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
In flow F2, proxy P1 adds its own identifier in a quoted string to the P-Visited-Network-ID header field.
フローF2で、プロキシP1は、引用符で囲まれた文字列の独自の識別子をP-Visited-Network-IDヘッダーフィールドに追加します。
F2 Register P1 -> P2
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP p1@visited.net;branch=z9hG4bK203igld
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashd8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
P-Visited-Network-ID: "Visited network number 1"
Finally, in flow F3, proxy P2 decides to insert its own identifier, derived from its own domain name to the P-Visited-Network-ID header field.
最後に、フローF3で、プロキシP2は独自のドメイン名から派生した独自の識別子をP-Visited-Network-IDヘッダーフィールドに挿入することを決定します。
F3 Register P2 -> REGISTRAR
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP p2@other.net;branch=z9hG4bK2bndnvk
Via: SIP/2.0/UDP p1@visited.net;branch=z9hG4bK203igld
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashd8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
P-Visited-Network-ID: other.net,"Visited network number 1"
This section describes the P-Access-Network-Info header field. This header field is useful in SIP-based networks that also provide Layer 2 (L2) / Layer 3 (L3) connectivity through different access technologies. SIP UAs may use this header field to relay information about the access technology to proxies that are providing services. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP UA may use this header field to pass information about the access network such as radio access technology and radio cell identity to its home service provider.
このセクションでは、P-Access-Network-Infoヘッダーフィールドについて説明します。このヘッダーフィールドは、さまざまなアクセステクノロジーを通じてレイヤー2（L2）/レイヤー3（L3）接続も提供するSIPベースのネットワークで役立ちます。 SIP UAは、このヘッダーフィールドを使用して、サービスを提供しているプロキシにアクセステクノロジーに関する情報を中継できます。次に、サービングプロキシはこの情報を使用して、UAのサービスを最適化します。たとえば、3GPP UAはこのヘッダーフィールドを使用して、無線アクセス技術や無線セルIDなどのアクセスネットワークに関する情報をそのホームサービスプロバイダーに渡すことができます。
For the purpose of this extension, we define an access network as the network providing the L2/L3 IP connectivity, which, in turn, provides a user with access to the SIP capabilities and services provided.
この拡張の目的で、アクセスネットワークをL2 / L3 IP接続を提供するネットワークとして定義します。これにより、ユーザーに提供されるSIP機能およびサービスへのアクセスが提供されます。
In some cases, the SIP server that provides the user with services may wish to know information about the type of access network that the UA is currently using. Some services are more suitable or less suitable depending on the access type, and some services are of more value to subscribers if the access network details are known by the SIP proxy that provides the user with services.
場合によっては、ユーザーにサービスを提供するSIPサーバーは、UAが現在使用しているアクセスネットワークの種類に関する情報を知りたい場合があります。一部のサービスは、アクセスタイプに応じてより適切またはより適切ではありません。また、アクセスネットワークの詳細がユーザーにサービスを提供するSIPプロキシによって認識されている場合、一部のサービスは加入者にとってより価値があります。
In other cases, the SIP server that provides the user with services may simply wish to know crude location information in order to provide certain services to the user. For example, many of the location-based services available in wireless networks today require the home network to know the identity of the cell the user is being served by.
他の場合では、ユーザーにサービスを提供するSIPサーバーは、特定のサービスをユーザーに提供するために、大まかな位置情報を知りたいだけかもしれません。たとえば、今日のワイヤレスネットワークで利用できる場所ベースのサービスの多くは、ユーザーがサービスを提供しているセルのIDをホームネットワークが知っている必要があります。
Some regulatory requirements exist mandating that for cellular radio systems, the identity of the cell where an emergency call is established is made available to the emergency authorities.
セルラー無線システムの場合、緊急通報が確立されたセルのIDが緊急当局に提供されることを義務付けるいくつかの規制要件が存在します。
The SIP server that provides services to the user may desire to have knowledge about the access network. This is achieved by defining a new private SIP extension header field, P-Access-Network-Info header field. This header field carries information relating to the access network between the UAC and its serving proxy in the home network.
ユーザーにサービスを提供するSIPサーバーは、アクセスネットワークに関する知識が必要な場合があります。これは、新しいプライベートSIP拡張ヘッダーフィールドであるP-Access-Network-Infoヘッダーフィールドを定義することによって実現されます。このヘッダーフィールドには、ホームネットワーク内のUACとそのサービスプロキシの間のアクセスネットワークに関する情報が含まれています。
A proxy providing services based on the P-Access-Network-Info header field must consider the trust relationship to the UA or outbound proxy including the P-Access-Network-Info header field.
P-Access-Network-Infoヘッダーフィールドに基づいてサービスを提供するプロキシは、UAまたはP-Access-Network-Infoヘッダーフィールドを含む送信プロキシへの信頼関係を考慮する必要があります。
4.4.1. Applicability Statement for the P-Access-Network-Info Header Field
4.4.1. P-Access-Network-Infoヘッダーフィールドの適用ステートメント
This mechanism is appropriate in environments where SIP services are dependent on SIP elements knowing details about the IP and lower-layer technologies used by a UA to connect to the SIP network. Specifically, the extension requires that the UA know the access technology it is using, and that a proxy desires such information to provide services. Generally, SIP is built on the everything over IP and IP over everything principle, where the access technology is not relevant for the operation of SIP. Since SIP systems generally should not care or even know about the access technology, this SIP extension is not for general SIP usage.
このメカニズムは、SIPサービスが、UAがSIPネットワークに接続するために使用するIPおよび下位レイヤーテクノロジーに関する詳細を知っているSIP要素に依存している環境に適しています。具体的には、拡張機能では、UAが使用しているアクセステクノロジーを知っていること、およびプロキシがサービスを提供するためにそのような情報を望んでいることが必要です。一般的に、SIPは、Everything over IPおよびIP over Everyの原則に基づいて構築されており、アクセステクノロジーはSIPの運用には関係ありません。 SIPシステムは一般にアクセステクノロジーを気にしない、または知らないはずなので、このSIP拡張は一般的なSIPの使用には適していません。
The information revealed in the P-Access-Network-Info header field is potentially very sensitive. Proper protection of this information depends on the existence of specific business and security relationships amongst the proxies that will see SIP messages containing this header field. It also depends on explicit knowledge of the UA of the existence of those relationships. Therefore, this mechanism is only suitable in environments where the appropriate relationships are in place, and the UA has explicit knowledge that they exist.
P-Access-Network-Infoヘッダーフィールドで明らかにされた情報は、非常に機密性が高い可能性があります。この情報の適切な保護は、このヘッダーフィールドを含むSIPメッセージを見るプロキシ間の特定のビジネスおよびセキュリティ関係の存在に依存します。また、それらの関係の存在に関するUAの明確な知識にも依存します。したがって、このメカニズムは、適切な関係があり、UAがそれらが存在することを明確に認識している環境でのみ適しています。
When a UA generates a SIP request or response that it knows is going to be securely sent to its SIP proxy that is providing services, the UA inserts a P-Access-Network-Info header field into field the SIP message. This header contains information on the access network that the UA is using to get IP connectivity. The header is typically ignored by intermediate proxies between the UA and the SIP proxy that is providing services. The proxy providing services can inspect the header and make use of the information contained there to provide appropriate services, depending on the value of the header. Before proxying the request onwards to an untrusted administrative network domain, this proxy strips the header from the message.
UAが、サービスを提供しているSIPプロキシに安全に送信されることがわかっているSIP要求または応答を生成すると、UAは、P-Access-Network-InfoヘッダーフィールドをSIPメッセージのフィールドに挿入します。このヘッダーには、UAがIP接続を取得するために使用しているアクセスネットワークに関する情報が含まれています。ヘッダーは通常、UAとサービスを提供しているSIPプロキシの間の中間プロキシによって無視されます。プロキシ提供サービスは、ヘッダーを検査し、そこに含まれる情報を利用して、ヘッダーの値に応じて適切なサービスを提供できます。信頼できない管理ネットワークドメインに要求をプロキシする前に、このプロキシはメッセージからヘッダーを取り除きます。
Additionally, the first outbound proxy, if in possession of appropriate information, can also add a P-Access-Network-Info header field with its own information.
さらに、適切な情報を所有している場合、最初の送信プロキシは、独自の情報を含むP-Access-Network-Infoヘッダーフィールドを追加することもできます。
A UA that supports this extension and is willing to disclose the related parameters MAY insert the P-Access-Network-Info header field in any SIP request or response.
この拡張機能をサポートし、関連するパラメーターを開示してもよいUAは、SIP要求または応答にP-Access-Network-Infoヘッダーフィールドを挿入できます（MAY）。
The UA inserting this information MUST have a trust relationship with the proxy that is providing services to protect its privacy by deleting the header before forwarding the message outside of the proxy's domain. This proxy is typically located in the home network.
この情報を挿入するUAは、プロキシのドメイン外にメッセージを転送する前にヘッダーを削除してプライバシーを保護するサービスを提供しているプロキシと信頼関係を持っている必要があります。このプロキシは通常、ホームネットワークにあります。
In order to avoid the deletion of the header, there MUST also be a transitive trust in intermediate proxies between the UA and the proxy that provides the services. This trust is established by business agreements between the home network and the access network, and generally supported by the use of standard security mechanisms, e.g., IPsec, AKA, and TLS.
ヘッダーの削除を回避するために、UAとサービスを提供するプロキシの間の中間プロキシに推移的な信頼も存在する必要があります。この信頼は、ホームネットワークとアクセスネットワークの間のビジネス契約によって確立され、通常、IPsec、AKA、TLSなどの標準的なセキュリティメカニズムの使用によってサポートされます。
A proxy MUST NOT modify the value of the P-Access-Network-Info header field.
プロキシは、P-Access-Network-Infoヘッダーフィールドの値を変更してはなりません（MUST NOT）。
A proxy in possession of appropriate information about the access technology MAY insert a P-Access-Network-Info header field with its own values. A proxy sending towards an untrusted entity MUST remove any P-Access-Network-Info header field containing a "network-provided" value.
アクセステクノロジーに関する適切な情報を保持しているプロキシは、独自の値を持つP-Access-Network-Infoヘッダーフィールドを挿入してもよい（MAY）。信頼できないエンティティに向けて送信するプロキシは、「ネットワーク提供」値を含むP-Access-Network-Infoヘッダーフィールドを削除する必要があります。
A proxy that is providing services to the UA, can act upon any information present in the P-Access-Network-Info header field value, if is present, to provide a different service depending on the network or the location through which the UA is accessing the server. For example, for cellular radio access networks, the SIP proxy located in the home network MAY use the cell ID to provide basic localized services.
UAにサービスを提供しているプロキシは、存在する場合、P-Access-Network-Infoヘッダーフィールド値に存在する情報に基づいて動作し、UAが経由するネットワークまたは場所に応じて異なるサービスを提供できます。サーバーへのアクセス。たとえば、セルラー無線アクセスネットワークの場合、ホームネットワークにあるSIPプロキシは、セルIDを使用して、基本的なローカライズされたサービスを提供できます（MAY）。
A proxy that provides services to the user is typically located in the home network and is therefore trusted. It MUST delete the header when the SIP signaling is forwarded to a SIP server located in an untrusted administrative network domain. The SIP server providing services to the UA uses the access network information that is of no interest to other proxies located in different administrative domains.
ユーザーにサービスを提供するプロキシは、通常、ホームネットワークにあり、したがって信頼されています。 SIPシグナリングが信頼されていない管理ネットワークドメインにあるSIPサーバーに転送される場合、ヘッダーを削除する必要があります。 UAにサービスを提供するSIPサーバーは、異なる管理ドメインにある他のプロキシには関係のないアクセスネットワーク情報を使用します。
3GPP has defined a distributed architecture that results in multiple network entities becoming involved in providing access and services. There is a need to inform each SIP proxy involved in a transaction about the common charging functional entities to receive the generated charging records or charging events.
3GPPは、複数のネットワークエンティティがアクセスとサービスの提供に関与するようになる分散アーキテクチャを定義しています。トランザクションに含まれる各SIPプロキシに、生成された課金レコードまたは課金イベントを受信するための共通の課金機能エンティティについて通知する必要があります。
The solution provided by 3GPP is to define two types of charging functional entities: Charging Collection Function (CCF) and Event Charging Function (ECF). CCF is used for offline charging (e.g., for postpaid account charging). ECF is used for online charging (e.g., for pre-paid account charging). There may be more than a single instance of CCF and ECF in a network, in order to provide redundancy in the network. In case there are more than a single instance of either the CCF or the ECF addresses, implementations SHOULD attempt sending the charging data to the ECF or CCF address, starting with the first address of the sequence (if any) in the P-Charging-Function-Addresses header field. If the first address of the sequence is not available, then the next address (ccf-2 or ecf-2) MUST be used if available. The CCF and ECF addresses MAY be passed during the establishment of a dialog or in a standalone transaction. More detailed information about charging can be found in 3GPP TS 32.240 [TS32.240] and 3GPP TS 32.260 [TS32.260].
3GPPが提供するソリューションは、2つのタイプの課金機能エンティティを定義することです。課金収集機能（CCF）とイベント課金機能（ECF）です。 CCFはオフライン課金に使用されます（例：後払いのアカウント課金）。 ECFは、オンライン課金に使用されます（プリペイドアカウント課金など）。ネットワークに冗長性を提供するために、ネットワーク内に複数のCCFおよびECFのインスタンスが存在する場合があります。 CCFまたはECFアドレスのいずれかのインスタンスが複数ある場合、実装は、P-Charging-のシーケンス（存在する場合）の最初のアドレスから開始して、課金データをECFまたはCCFアドレスに送信する必要があります（SHOULD）。 Function-Addressesヘッダーフィールド。シーケンスの最初のアドレスが利用できない場合、利用可能な場合は次のアドレス（ccf-2またはecf-2）を使用する必要があります。 CCFおよびECFアドレスは、ダイアログの確立中またはスタンドアロントランザクションで渡される場合があります。充電の詳細については、3GPP TS 32.240 [TS32.240]および3GPP TS 32.260 [TS32.260]を参照してください。
We define the SIP private header field P-Charging-Function-Addresses header field. A proxy MAY include this header field, if not already present, in either the initial request or response for a dialog or in the request and response of a standalone transaction outside a dialog. When present, only one instance of the header MUST be present in a particular request or response.
SIPプライベートヘッダーフィールドP-Charging-Function-Addressesヘッダーフィールドを定義します。プロキシは、まだ存在していない場合、ダイアログの最初の要求または応答、またはダイアログ外のスタンドアロントランザクションの要求と応答にこのヘッダーフィールドを含めることができます（MAY）。存在する場合、特定の要求または応答には、ヘッダーのインスタンスが1つだけ存在する必要があります。
The mechanisms by which a SIP proxy collects the values to populate the P-Charging-Function-Addresses header field values are outside the scope of this document. However, as an example, a SIP proxy may have preconfigured these addresses or may obtain them from a subscriber database.
SIPプロキシが値を収集してP-Charging-Function-Addressesヘッダーフィールドの値を設定するメカニズムは、このドキュメントの範囲外です。ただし、例として、SIPプロキシはこれらのアドレスを事前に設定している場合や、サブスクライバーデータベースから取得している場合があります。
4.5.1. Applicability Statement for the P-Charging-Function-Addresses Header Field
4.5.1. P-Charging-Function-Addressesヘッダーフィールドの適用ステートメント
The P-Charging-Function-Addresses header field is applicable within a single private administrative domain where coordination of charging is required, for example, according to the architecture specified in 3GPP TS 32.240 [TS32.240].
P-Charging-Function-Addressesヘッダーフィールドは、たとえば3GPP TS 32.240 [TS32.240]で指定されているアーキテクチャに従って、課金の調整が必要な単一のプライベート管理ドメイン内で適用できます。
The P-Charging-Function-Addresses header field is not included in a SIP message sent outside of the own administrative domain. The header is not applicable if the administrative domain does not provide a charging function.
P-Charging-Function-Addressesヘッダーフィールドは、独自の管理ドメインの外部に送信されるSIPメッセージには含まれません。管理ドメインが課金機能を提供していない場合、ヘッダーは適用されません。
The P-Charging-Function-Addresses header field is applicable whenever the following circumstances are met:
P-Charging-Function-Addressesヘッダーフィールドは、次の状況が当てはまる場合はいつでも適用できます。
1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE request) or a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UAは、REGISTERまたはダイアログ開始要求（例：INVITE要求）またはスタンドアロントランザクション要求を、ダイアログの外部でプライベートネットワークの管理ドメインにあるプロキシに送信します。
2. A registrar, proxy, or UA that is located in the administrative domain of the private network wants to generate charging records.
2. プライベートネットワークの管理ドメインにあるレジストラ、プロキシ、またはUAが課金レコードを生成しようとしています。
3. A registrar, proxy, or UA that is located in the private network has access to the addresses of the charging function entities for that network.
3. プライベートネットワークにあるレジストラ、プロキシ、またはUAは、そのネットワークの課金機能エンティティのアドレスにアクセスできます。
4. There are other proxies that are located in the same administrative domain of the private network and that generate charging records or charging events. The proxies want to send, by means outside SIP, the charging information to the same charging collecting entities than the first proxy.
4. プライベートネットワークの同じ管理ドメインにあり、課金レコードまたは課金イベントを生成する他のプロキシがあります。プロキシは、SIP外の手段で、最初のプロキシと同じ課金収集エンティティに課金情報を送信したいと考えています。
A SIP proxy that receives a SIP request MAY insert a P-Charging-Function-Addresses header field prior to forwarding the request, if the header was not already present in the SIP request. The header filed contains one or more parameters that contain the hostnames or IP addresses of the nodes that are willing to receive charging information.
SIPリクエストを受信するSIPプロキシは、ヘッダーがまだSIPリクエストに存在しない場合、リクエストを転送する前にP-Charging-Function-Addressesヘッダーフィールドを挿入する場合があります。ヘッダーフィールドには、課金情報を受信するノードのホスト名またはIPアドレスを含む1つ以上のパラメーターが含まれています。
A SIP proxy that receives a SIP request that includes a P-Charging-Function-Addresses header field can use the hostnames or IP addresses included in the value, as the destination of charging information or charging events. The means to send those charging information or events are outside the scope of this document, and usually, do not use SIP for that purpose.
P-Charging-Function-Addressesヘッダーフィールドを含むSIPリクエストを受信するSIPプロキシは、値に含まれるホスト名またはIPアドレスを、課金情報または課金イベントの宛先として使用できます。それらの課金情報またはイベントを送信する手段はこのドキュメントの範囲外であり、通常、その目的でSIPを使用しません。
This document does not specify any procedure at the UA located outside the administrative domain of a private network, with regard to the P-Charging-Function-Addresses header field. Such UAs need not understand this header.
このドキュメントでは、P-Charging-Function-Addressesヘッダーフィールドに関して、プライベートネットワークの管理ドメインの外部にあるUAでの手順を指定していません。そのようなUAはこのヘッダーを理解する必要はありません。
However, it might be possible that a UA is located within the administrative domain of a private network (e.g., a Public Switched Telephone Network (PSTN) gateway, or conference mixer), and it may have access to the addresses of the charging entities. In this case, a UA MAY insert the P-Charging-Function-Addresses header field in a SIP request or response when the next hop for the message is a proxy or UA located in the same administrative domain. Similarly, such a UA MAY use the contents of the P-Charging-Function-Addresses header field in communicating with the charging entities.
ただし、UAがプライベートネットワーク（公衆交換電話網（PSTN）ゲートウェイ、または会議ミキサーなど）の管理ドメイン内にあり、課金エンティティのアドレスにアクセスできる可能性があります。この場合、メッセージの次のホップが同じ管理ドメインにあるプロキシまたはUAである場合、UAはSIP要求または応答にP-Charging-Function-Addressesヘッダーフィールドを挿入できます（MAY）。同様に、そのようなUAは、課金エンティティとの通信でP-Charging-Function-Addressesヘッダーフィールドの内容を使用できます。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Function-Addresses header field MAY insert a P-Charging-Function-Addresses header field prior to forwarding the message. The header is populated with a list of the addresses of one or more charging entities where the proxy should send charging-related information.
この拡張をサポートし、P-Charging-Function-Addressesヘッダーフィールドなしで要求または応答を受信するSIPプロキシは、メッセージを転送する前にP-Charging-Function-Addressesヘッダーフィールドを挿入する場合があります。ヘッダーには、プロキシが課金関連情報を送信する1つ以上の課金エンティティのアドレスのリストが入力されます。
If a proxy that supports this extension receives a request or response with the P-Charging-Function-Addresses header field, it MAY retrieve the information from the header field to use with application-specific logic, i.e., charging. If the next hop for the message is within the administrative domain of the proxy, then the proxy SHOULD include the P-Charging-Function-Addresses header field in the outbound message. However, if the next hop for the message is outside the administrative domain of the proxy, then the proxy MUST remove the P-Charging-Function-Addresses header field.
この拡張機能をサポートするプロキシがP-Charging-Function-Addressesヘッダーフィールドでリクエストまたはレスポンスを受信した場合、アプリケーション固有のロジック、つまり課金で使用するためにヘッダーフィールドから情報を取得する場合があります。メッセージのネクストホップがプロキシの管理ドメイン内にある場合、プロキシは発信メッセージにP-Charging-Function-Addressesヘッダーフィールドを含める必要があります（SHOULD）。ただし、メッセージの次のホップがプロキシの管理ドメインの外にある場合、プロキシはP-Charging-Function-Addressesヘッダーフィールドを削除する必要があります。
We present an example in the context of the scenario shown in the following network diagram:
次のネットワーク図に示すシナリオのコンテキストで例を示します。
Scenario UA1 --- P1 --- P2 --- UA2
In this scenario, we assume that P1 and P2 belong to the same administrative domain.
このシナリオでは、P1とP2が同じ管理ドメインに属していると想定しています。
The example below shows the message sequence for an INVITE transaction originating from UA1 and eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case, P1 inserts charging information. Then, P1 routes the request via P2 to UA2.
次の例は、UA1から発信され、最終的にUA2に到達するINVITEトランザクションのメッセージシーケンスを示しています。 P1はUA1の発信プロキシです。この場合、P1は課金情報を挿入します。次に、P1はリクエストをP2経由でUA2にルーティングします。
Message sequence for INVITE using P-Charging-Function-Addresses header field:
P-Charging-Function-Addressesヘッダーフィールドを使用したINVITEのメッセージシーケンス：
F1 Invite UA1 -> P1
INVITE sip:ua2@home1.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:ua2@home1.net
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
F2 Invite P1 -> P2
INVITE sip:ua2@home1.net SIP/2.0
Via: SIP/2.0/UDP p1@home1.net:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:ua2@home1.net
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Function-Addresses:
ccf=192.0.8.1; ecf=192.0.8.3,
ccf-2=192.0.8.2; ecf-2=192.0.8.4
Now both P1 and P2 are aware of the IP addresses of the entities that collect charging record or charging events. Both proxies can send the charging information to the same entities.
これで、P1とP2の両方が、課金レコードまたは課金イベントを収集するエンティティのIPアドレスを認識しました。両方のプロキシが課金情報を同じエンティティに送信できます。
3GPP has defined a distributed architecture that results in multiple network entities becoming involved in providing access and services. Operators need the ability and flexibility to charge for the access and services as they see fit. This requires coordination among the network entities (e.g., SIP proxies), which includes correlating charging records generated from different entities that are related to the same session.
3GPPは、複数のネットワークエンティティがアクセスとサービスの提供に関与するようになる分散アーキテクチャを定義しています。オペレーターは、必要に応じてアクセスとサービスに課金する能力と柔軟性を必要としています。これには、ネットワークエンティティ（SIPプロキシなど）間の調整が必要です。これには、同じセッションに関連するさまざまなエンティティから生成された課金レコードの関連付けが含まれます。
The correlation information includes, but is not limited to, a globally unique charging identifier that makes the billing effort easy.
相関情報には、請求作業を容易にするグローバルに一意の課金識別子が含まれますが、これに限定されません。
A charging vector is defined as a collection of charging information. The charging vector MAY be filled in during the establishment of a dialog or standalone transaction outside a dialog. The information inside the charging vector MAY be filled in by multiple network entities (including SIP proxies) and retrieved by multiple network entities. There are three types of correlation information to be transferred: the IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value, and the Inter Operator Identifier (IOI).
課金ベクトルは、課金情報の集合として定義されます。課金ベクトルは、ダイアログまたはダイアログ外のスタンドアロントランザクションの確立中に入力できます。課金ベクトル内の情報は、複数のネットワークエンティティ（SIPプロキシを含む）によって入力され、複数のネットワークエンティティによって取得される場合があります。転送される相関情報には、IMS課金ID（ICID）値、ICID値を作成するSIPプロキシのアドレス、およびInter Operator Identifier（IOI）の3つのタイプがあります。
ICID is a charging value that identifies a dialog or a transaction outside a dialog. It is used to correlate charging records. ICID MUST be a globally unique value. One way to achieve globally uniqueness is to generate the ICID using two components: a locally unique value and the hostname or IP address of the SIP proxy that generated the locally unique value.
ICIDは、ダイアログまたはダイアログ外のトランザクションを識別する課金値です。課金レコードを相互に関連付けるために使用されます。 ICIDはグローバルに一意の値である必要があります。グローバルに一意にする1つの方法は、2つのコンポーネントを使用してICIDを生成することです。ローカルに一意の値と、ローカルに一意の値を生成したSIPプロキシのホスト名またはIPアドレス。
The IOI identifies both the originating and terminating networks involved in a SIP dialog or transaction outside a dialog. There MAY be an IOI generated from each side of the dialog to identify the network associated with each side.
IOIは、SIPダイアログまたはダイアログ外のトランザクションに関与する発信ネットワークと着信ネットワークの両方を識別します。ダイアログの各サイドから生成されたIOIがあり、各サイドに関連付けられたネットワークを識別できます。
Additionally, in a multi-network environment, one or more transit IOI identifiers MAY be included along the path of the SIP dialog or transaction outside a dialog. Due to network policy, a void value MAY be included instead of the transit network name. The void value is used to indicate that a transit network appeared but due to operator policy the network name is not shown.
さらに、マルチネットワーク環境では、SIPダイアログまたはダイアログ外のトランザクションのパスに沿って、1つ以上のトランジットIOI識別子を含めることができます（MAY）。ネットワークポリシーにより、トランジットネットワーク名の代わりにvoid値が含まれる場合があります。 void値は、トランジットネットワークが出現したが、オペレーターのポリシーによりネットワーク名が表示されていないことを示すために使用されます。
Furthermore, in a multi-service provider environment, one or more transit IOIs MAY be included along the path of the SIP dialog or transaction outside a dialog. Due to service provider policy, a void value MAY be included instead of the transit service provider. The void value is used to indicate that a transit appeared but due to service provider policy the service provider name is not shown.
さらに、マルチサービスプロバイダー環境では、SIPダイアログまたはダイアログ外のトランザクションのパスに沿って1つ以上のトランジットIOIが含まれる場合があります。サービスプロバイダーのポリシーにより、トランジットサービスプロバイダーの代わりにvoid値が含まれる場合があります。 void値は、トランジットが出現したことを示すために使用されますが、サービスプロバイダーのポリシーにより、サービスプロバイダー名は表示されません。
There is also expected to be access network charging information, which consists of network-specific identifiers for the access level (e.g., Universal Mobile Telecommunications System (UMTS) radio access network or IEEE 802.11b). The details of the information for each type of network are not described in this memo.
アクセスレベルのネットワーク固有の識別子（たとえば、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）無線アクセスネットワークまたはIEEE 802.11b）で構成されるアクセスネットワーク課金情報も期待されています。このメモには、ネットワークのタイプごとの情報の詳細は記載されていません。
We define the SIP private header P-Charging-Vector header field. A proxy MAY include this header, if not already present, in either the initial request or response for a dialog, or in the request and response of a standalone transaction outside a dialog. When present, only one instance of the header MUST be present in a particular request or response.
SIPプライベートヘッダーP-Charging-Vectorヘッダーフィールドを定義します。プロキシは、このヘッダーがまだ存在しない場合は、ダイアログの最初の要求または応答、またはダイアログ外のスタンドアロントランザクションの要求と応答に含めることができます（MAY）。存在する場合、特定の要求または応答には、ヘッダーのインスタンスが1つだけ存在する必要があります。
The mechanisms by which a SIP proxy collects the values to populate the P-Charging-Vector header field are outside the scope of this document.
SIPプロキシが値を収集してP-Charging-Vectorヘッダーフィールドに入力するメカニズムは、このドキュメントの範囲外です。
The P-Charging-Vector header field is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.
P-Charging-Vectorヘッダーフィールドは、単一のプライベート管理ドメイン内、またはドメイン間に信頼関係がある異なる管理ドメイン間に適用できます。
The P-Charging-Vector header field is not included in a SIP message sent to another network if there is no trust relationship. The header is not applicable if the administrative domain manages charging in a way that does not require correlation of records from multiple network entities (e.g., SIP proxies).
信頼関係がない場合、P-Charging-Vectorヘッダーフィールドは別のネットワークに送信されるSIPメッセージに含まれません。複数のネットワークエンティティ（SIPプロキシなど）からのレコードの相関を必要としない方法で管理ドメインが課金を管理する場合、ヘッダーは適用されません。
The P-Charging-Vector header field is applicable whenever the following circumstances are met:
P-Charging-Vectorヘッダーフィールドは、次の状況が当てはまる場合はいつでも適用できます。
1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE) or mid-dialog request (e.g., UPDATE) or a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UAは、REGISTERまたはダイアログ開始要求（例：INVITE）またはダイアログ中要求（例：UPDATE）またはスタンドアロントランザクション要求を、ダイアログの外でプライベートネットワークの管理ドメインにあるプロキシに送信します。
2. A registrar, proxy, or UA that is located in the administrative domain of the private network wants to generate charging records.
2. プライベートネットワークの管理ドメインにあるレジストラ、プロキシ、またはUAが課金レコードを生成しようとしています。
3. A proxy or UA that is located in the administrative domain of the private network has access to the charging correlation information for that network.
3. プライベートネットワークの管理ドメインにあるプロキシまたはUAは、そのネットワークの課金相関情報にアクセスできます。
4. Optionally, a registrar, proxy, or UA that is part of a second administrative domain in another private network, whose SIP requests and responses are traversed through, en route to/from the first private network, wants to generate charging records and correlate those records with those of the first private network. This assumes that there is a trust relationship between both private networks.
4. 必要に応じて、別のプライベートネットワークの2番目の管理ドメインの一部であるレジストラー、プロキシ、またはUAは、そのSIP要求と応答が最初のプライベートネットワークとの間でやり取りされ、課金レコードを生成してそれらのレコードを関連付けます。最初のプライベートネットワークのものと。これは、両方のプライベートネットワーク間に信頼関係があることを前提としています。
The P-Charging-Vector header field is used to convey charging-related information, such as the globally unique IMS Charging Identity (ICID) value.
P-Charging-Vectorヘッダーフィールドは、グローバルに一意のIMS課金ID（ICID）値などの課金関連情報を伝えるために使用されます。
Typically, a SIP proxy that receives a SIP request that does not contain a P-Charging-Vector header field MAY insert it, with those parameters that are available at the SIP proxy.
通常、P-Charging-Vectorヘッダーフィールドを含まないSIPリクエストを受信するSIPプロキシは、SIPプロキシで使用可能なパラメーターを使用して、それを挿入する場合があります。
A SIP proxy that receives a SIP request that contains a P-Charging-Vector header field can use the values, such as the globally unique ICID, to produce charging records.
P-Charging-Vectorヘッダーフィールドを含むSIPリクエストを受信するSIPプロキシは、グローバルに一意のICIDなどの値を使用して、課金レコードを生成できます。
This document does not specify any procedure at a UA located outside the administrative domain of a private network (e.g., PSTN gateway or conference mixer), with regard to the P-Charging-Vector header field. UAs need not understand this header.
このドキュメントでは、P-Charging-Vectorヘッダーフィールドに関して、プライベートネットワーク（PSTNゲートウェイや会議ミキサーなど）の管理ドメインの外部にあるUAでの手順を指定していません。 UAはこのヘッダーを理解する必要はありません。
However, it might be possible that a UA be located within the administrative domain of a private network (e.g., a PSTN gateway, or conference mixer), and it may interact with the charging entities. In this case, a UA MAY insert the P-Charging-Vector header field in a SIP request or response when the next hop for the message is a proxy or UA located in the same administrative domain. Similarly, such a UA MAY use the contents of the P-Charging-Vector header field in communicating with the charging entities.
ただし、UAがプライベートネットワーク（PSTNゲートウェイや会議ミキサーなど）の管理ドメイン内にある可能性があり、課金エンティティとやり取りする可能性があります。この場合、メッセージの次のホップが同じ管理ドメインにあるプロキシまたはUAである場合、UAはSIP要求または応答にP-Charging-Vectorヘッダーフィールドを挿入できます（MAY）。同様に、そのようなUAは、課金エンティティとの通信でP-Charging-Vectorヘッダーフィールドのコンテンツを使用できます。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Vector header field MAY insert a P-Charging-Vector header field prior to forwarding the message. The header is populated with one or more parameters, as described in the syntax, including but not limited to, a globally unique charging identifier.
この拡張をサポートし、P-Charging-Vectorヘッダーフィールドなしで要求または応答を受信するSIPプロキシは、メッセージを転送する前にP-Charging-Vectorヘッダーフィールドを挿入する場合があります。ヘッダーには、構文で説明されているように、1つ以上のパラメーターが設定されています。これには、グローバルに一意の課金識別子が含まれますが、これに限定されません。
If a proxy that supports this extension receives a request or response with the P-Charging-Vector header field, it MAY retrieve the information from the header value to use with application-specific logic, i.e., charging. If the next hop for the message is within the trusted domain, then the proxy SHOULD include the P-Charging-Vector header field in the outbound message. If the next hop for the message is outside the trusted domain, then the proxy MAY remove the P-Charging-Function-Addresses header field.
この拡張をサポートするプロキシがP-Charging-Vectorヘッダーフィールドでリクエストまたはレスポンスを受信した場合、アプリケーション固有のロジック、つまり課金で使用するために、ヘッダー値から情報を取得する場合があります。メッセージの次のホップが信頼されるドメイン内にある場合、プロキシは発信メッセージにP-Charging-Vectorヘッダーフィールドを含める必要があります（SHOULD）。メッセージのネクストホップが信頼できるドメインの外にある場合、プロキシはP-Charging-Function-Addressesヘッダーフィールドを削除できます（MAY）。
Per local application-specific logic, the proxy MAY modify the contents of the P-Charging-Vector header field prior to sending the message.
ローカルアプリケーション固有のロジックごとに、プロキシはメッセージを送信する前にP-Charging-Vectorヘッダーフィールドの内容を変更できます（MAY）。
We present an example in the context of the scenario shown in the following network diagram:
次のネットワーク図に示すシナリオのコンテキストで例を示します。
Scenario UA1 --- P1 --- P2 --- UA2
This example shows the message sequence for an INVITE transaction originating from UA1 and eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case, P1 inserts charging information. Then, P1 routes the call via P2 to UA2.
この例は、UA1から発信され、最終的にUA2に到着するINVITEトランザクションのメッセージシーケンスを示しています。 P1はUA1の発信プロキシです。この場合、P1は課金情報を挿入します。次に、P1はP2経由でコールをUA2にルーティングします。
Message sequence for INVITE using P-Charging-Vector header field:
P-Charging-Vectorヘッダーフィールドを使用したINVITEのメッセージシーケンス：
F1 Invite UA1 -> P1
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
F2 Invite P1 -> P2
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP P1@home1.net:5060;branch=z9hG4bK34ghi7a
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Vector: icid-value=1234bc9876e;
icid-generated-at=192.0.6.8;
orig-ioi=home1.net
The transit-ioi is added to the P-Charging-Vector header field when traversing transit networks. It is allowed to have multiple transit-ioi values within one SIP message or response. The values within the response are independent from the values set up within the request.
トランジットネットワークを通過するときに、transit-ioiがP-Charging-Vectorヘッダーフィールドに追加されます。 1つのSIPメッセージまたは応答内に複数の通過ioi値を含めることができます。応答内の値は、要求内で設定された値から独立しています。
The element could be added either by a transit network itself or by the succeeding network at the entry point where the preceding network is known. Based on network policy, a void value can be used.
要素は、トランジットネットワーク自体によって、または先行するネットワークが既知のエントリポイントにある後続のネットワークによって追加できます。ネットワークポリシーに基づいて、void値を使用できます。
Depending on the call scenario, each transit network can add either a transit network name or a void value. However, it cannot be guaranteed that all the values that are added will appear within the P-Charging-Vector header field.
通話シナリオに応じて、各トランジットネットワークはトランジットネットワーク名またはvoid値を追加できます。ただし、追加されるすべての値がP-Charging-Vectorヘッダーフィールド内に表示されることは保証されません。
Some networks can screen the P-Charging-Vector header field and delete transit-ioi values, e.g., networks not supporting this value. There are scenarios where the appearance of the transit-ioi values of all networks is needed to have a correct end-to-end view.
一部のネットワークでは、P-Charging-Vectorヘッダーフィールドをスクリーニングし、transit-ioi値を削除できます。たとえば、この値をサポートしていないネットワークなどです。すべてのネットワークの通過ioi値の外観が正しいエンドツーエンドのビューを持つ必要があるシナリオがあります。
The policies of adding, modifying, and deleting transit-ioi values are out of the scope of this document.
トランジットioi値の追加、変更、および削除のポリシーは、このドキュメントの範囲外です。
The transit-ioi contains an indexed value that MUST be incremented with each value added to the P-Charging-Vector header field.
transition-ioiには、P-Charging-Vectorヘッダーフィールドに各値が追加されるたびにインクリメントされるインデックス付きの値が含まれています。
A void value has no index. By adding the next value, the index has to be incremented by the number of void entries +1.
void値にはインデックスがありません。次の値を追加することにより、インデックスはvoidエントリの数+1する必要があります。
Procedures described within Section 4.5.2.2 apply. A transit-ioi MAY be added or modified by a proxy. A deletion of the transit-ioi or a entry within the tranist-ioi could appear depending on the network policy and trust rules. This is also valid by replacing the transit-ioi with a void value.
セクション4.5.2.2で説明されている手順が適用されます。 Transit-ioiは、プロキシによって追加または変更される場合があります。ネットワークポリシーと信頼ルールによっては、transit-ioiの削除またはtranist-ioi内のエントリが表示されることがあります。これは、transit-ioiをvoid値に置き換えることでも有効です。
The UAS acting as a B2BUA MAY add the related-icid into the P-Charging-Vector header field into SIP request or SIP responses. For example, the UAS can include the related-icid in a response to an INVITE request when the received INVITE request creates a new call leg towards the same remote end. The value of the related-icid is the icid value of the original dialog towards the remote end.
B2BUAとして機能するUASは、SIP要求またはSIP応答のP-Charging-Vectorヘッダーフィールドにrelated-icidを追加する場合があります。たとえば、受信したINVITE要求が同じリモートエンドに向けて新しいコールレッグを作成する場合、UASはINVITE要求への応答にrelated-icidを含めることができます。 related-icidの値は、リモートエンドに向かう元のダイアログのicid値です。
Procedures described within Section 4.5.2.2 apply. A related-icid and "related-icid-generated-at" MAY be added or modified by a proxy. A deletion of the elements could appear depending on the network policy and trust rules.
セクション4.5.2.2で説明されている手順が適用されます。 related-icidおよび "related-icid-generated-at"は、プロキシによって追加または変更される場合があります。要素の削除は、ネットワークポリシーと信頼ルールによっては表示される場合があります。
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 5234 [RFC5234]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementors need to be familiar with the notation and contents of SIP [RFC3261] and [RFC5234] to understand this document.
このドキュメントで指定されているすべてのメカニズムは、RFC 5234 [RFC5234]で定義されている散文と拡張バッカスナウアフォーム（BNF）の両方で説明されています。さらに、いくつかのBNF定義はSIPから継承され、ここでは繰り返されません。このドキュメントを理解するには、実装者はSIP [RFC3261]と[RFC5234]の表記法と内容に精通している必要があります。
The syntax of the P-Associated-URI header field is described as follows:
P-Associated-URIヘッダーフィールドの構文は次のとおりです。
P-Associated-URI = "P-Associated-URI" HCOLON [p-aso-uri-spec] *(COMMA p-aso-uri-spec) p-aso-uri-spec = name-addr *(SEMI ai-param) ai-param = generic-param
P-Associated-URI = "P-Associated-URI" HCOLON [p-aso-uri-spec] *（COMMA p-aso-uri-spec）p-aso-uri-spec = name-addr *（SEMI ai- param）ai-param = generic-param
The syntax of the P-Called-Party-ID header field is described as follows:
P-Called-Party-IDヘッダーフィールドの構文は次のとおりです。
P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec called-pty-id-spec = name-addr *(SEMI cpid-param) cpid-param = generic-param
P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec called-pty-id-spec = name-addr *（SEMI cpid-param）cpid-param = generic-param
The syntax of the P-Visited-Network-ID header field is described as follows:
P-Visited-Network-IDヘッダーフィールドの構文は次のとおりです。
P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON
vnetwork-spec
*(COMMA vnetwork-spec)
vnetwork-spec = (token / quoted-string)
*(SEMI vnetwork-param)
vnetwork-param = generic-param
The syntax of the P-Access-Network-Info header field is described as follows:
P-Access-Network-Infoヘッダーフィールドの構文は次のとおりです。
P-Access-Network-Info = "P-Access-Network-Info" HCOLON
access-net-spec *(COMMA access-net-spec)
access-net-spec = (access-type / access-class)
*(SEMI access-info)
access-type = "IEEE-802.11" / "IEEE-802.11a" /
"IEEE-802.11b" / "IEEE-802.11g" /
"IEEE-802.11n" /
"IEEE-802.3" / "IEEE-802.3a" /
"IEEE-802.3ab" / "IEEE-802.3ae" /
"IEEE-802.3ak" / "IEEE-802.3ah" /
"IEEE-802.3aq" / "IEEE-802.3an" /
"IEEE-802.3e" / "IEEE-802.3i" /
"IEEE-802.3j" / "IEEE-802.3u" /
"IEEE-802.3y" / "IEEE-802.3z" /
"3GPP-GERAN" /
"3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" /
"3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" /
"3GPP2-1X-Femto" / "3GPP2-UMB" /
"3GPP2-1X-HRPD" / "3GPP2-1X" /
"ADSL" / "ADSL2" / "ADSL2+" / "RADSL" /
"SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" /
"VDSL" / "IDSL" /
"DOCSIS" / "GSTN" / "GPON" / " XGPON1" /
"DVB-RCS2" / token
access-class = "3GPP-GERAN" / "3GPP-UTRAN" /
"3GPP-E-UTRAN" / "3GPP-WLAN" /
"3GPP-GAN" / "3GPP-HSPA" /
"3GPP2" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
dsl-location / i-wlan-node-id /
ci-3gpp2 / eth-location /
ci-3gpp2-femto / fiber-location /
np / gstn-location /local-time-zone /
dvb-rcs2-node-id / extension-access-info
np = "network-provided"
extension-access-info = gen-value
cgi-3gpp = "cgi-3gpp" EQUAL
(token / quoted-string)
utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL
(token / quoted-string)
i-wlan-node-id = "i-wlan-node-id" EQUAL
(token / quoted-string)
dsl-location = "dsl-location" EQUAL
(token / quoted-string)
eth-location = "eth-location" EQUAL
(token / quoted-string)
fiber-location = "fiber-location" EQUAL
(token / quoted-string)
ci-3gpp2 = "ci-3gpp2" EQUAL
(token / quoted-string)
ci-3gpp2-femto = "ci-3gpp2-femto" EQUAL
(token / quoted-string)
gstn-location = "gstn-location" EQUAL
(token / quoted-string)
dvb-rcs2-node-id = "dvb-rcs2-node-id" EQUAL
quoted-string
local-time-zone = "local-time-zone" EQUAL
quoted-string
operator-specific-GI = "operator-specific-GI" EQUAL (token / quoted-string) utran-sai-3gpp = "utran-sai-3gpp" EQUAL (token / quoted-string)
operator-specific-GI = "operator-specific-GI" EQUAL（トークン/引用文字列）utran-sai-3gpp = "utran-sai-3gpp" EQUAL（トークン/引用文字列）
The access-info MAY contain additional information relating to the access network. The values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto", and "gstn-location" are defined in 3GPP TS 24.229 [TS24.229].
access-infoには、アクセスネットワークに関連する追加情報が含まれる場合があります。 「cgi-3gpp」、「utran-cell-id-3gpp」、「i-wlan-node-id」、「dsl-location」、「ci-3gpp2」、「ci-3gpp2-femto」、および「gstn-location」は、3GPP TS 24.229 [TS24.229]で定義されています。
The syntax for the P-Charging-Function-Addresses header field is described as follows:
P-Charging-Function-Addressesヘッダーフィールドの構文は次のとおりです。
P-Charging-Addresses = "P-Charging-Function-Addresses" HCOLON
charge-addr-params *(COMMA charge-addr-params)
charge-addr-params = charge-addr-param *(SEMI charge-addr-param)
charge-addr-param = ccf / ecf / ccf-2 /ecf-2 / generic-param
ccf = "ccf" EQUAL gen-value
ecf = "ecf" EQUAL gen-value
ccf-2 = "ccf-2" EQUAL gen-value
ecf-2 = "ecf-2" EQUAL gen-value
The P-Charging-Function-Addresses header field contains one or two addresses of the ECF (ecf and ecf-2) or CCF (ccf and ccf-2). The first address of the sequence is ccf or ecf. If the first address of the sequence is not available, then the next address (ccf-2 or ecf-2) MUST be used if available.
P-Charging-Function-Addressesヘッダーフィールドには、ECF（ecfおよびecf-2）またはCCF（ccfおよびccf-2）の1つまたは2つのアドレスが含まれます。シーケンスの最初のアドレスはccfまたはecfです。シーケンスの最初のアドレスが利用できない場合、利用可能な場合は次のアドレス（ccf-2またはecf-2）を使用する必要があります。
The syntax for the P-Charging-Vector header field is described as follows:
P-Charging-Vectorヘッダーフィールドの構文は次のとおりです。
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value
*(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi / term-ioi /
transit-ioi / related-icid /
related-icid-gen-addr / generic-param
icid-value = "icid-value" EQUAL gen-value
icid-gen-addr = "icid-generated-at" EQUAL host
orig-ioi = "orig-ioi" EQUAL gen-value
term-ioi = "term-ioi" EQUAL gen-value
transit-ioi = "transit-ioi" EQUAL transit-ioi-list
transit-ioi-list = DQUOTE transit-ioi-param
*(COMMA transit-ioi-param) DQUOTE
transit-ioi-param = transit-ioi-indexed-value /
transit-ioi-void-value
transit-ioi-indexed-value = transit-ioi-name "."
transit-ioi-index
transit-ioi-name = ALPHA *(ALPHA / DIGIT)
transit-ioi-index = 1*DIGIT
transit-ioi-void-value = "void"
related-icid = "related-icid" EQUAL gen-value
related-icid-gen-addr = "related-icid-generated-at" EQUAL host
The P-Charging-Vector header field contains icid-value as a mandatory parameter. The icid-value represents the IMS charging ID, and contains an identifier used for correlating charging records and events. The first proxy that receives the request generates this value.
P-Charging-Vectorヘッダーフィールドには、必須パラメーターとしてicid-valueが含まれています。 icid-valueは、IMS課金IDを表し、課金レコードとイベントを関連付けるために使用される識別子を含みます。リクエストを受信した最初のプロキシがこの値を生成します。
The icid-gen-addr parameter contains the hostname or IP address of the proxy that generated the icid-value.
icid-gen-addrパラメータには、icid-valueを生成したプロキシのホスト名またはIPアドレスが含まれています。
The orig-ioi and term-ioi parameters contain originating and terminating interoperator identifiers. They are used to correlate charging records between different operators. The originating IOI represents the network responsible for the charging records in the originating part of the session or standalone request. Similarly, the terminating IOI represents the network responsible for the charging records in the terminating part of the session or standalone request.
orig-ioiおよびterm-ioiパラメータには、発信元と終了の相互運用者識別子が含まれています。それらは、異なるオペレーター間で課金レコードを相関させるために使用されます。元のIOIは、セッションまたはスタンドアロンリクエストの元の部分の課金レコードを担当するネットワークを表します。同様に、終了IOIは、セッションまたはスタンドアロン要求の終了部分の課金レコードを担当するネットワークを表します。
The transit-ioi parameter contains values with each of them, respectively, representing a transit interoperator identifier. It is used to correlate charging records between different networks. The transit-ioi represents the network responsible for the records in the transit part of the session or standalone request.
トランジットioiパラメータには、トランジット相互運用者識別子を表すそれぞれの値が含まれます。異なるネットワーク間で課金レコードを相関させるために使用されます。 Transit-ioiは、セッションのトランジット部分またはスタンドアロンのリクエストのレコードを担当するネットワークを表します。
The related-icid parameter contains the icid-value of a related charging record when more than one call leg is associated with one session. This optional parameter is used for correlation of charging information between two or more call legs related to the same remote-end dialog.
related-icidパラメータには、複数のコールレッグが1つのセッションに関連付けられている場合の関連する課金レコードのicid値が含まれます。このオプションパラメータは、同じリモートエンドダイアログに関連する2つ以上のコールレッグ間の課金情報の相関に使用されます。
The related-icid-gen-addr parameter contains the hostname or IP address of the proxy that generated the related-icid.
related-icid-gen-addrパラメーターには、related-icidを生成したプロキシのホスト名またはIPアドレスが含まれます。
Applications using the P-Charging-Vector header field within their own applicability are allowed to define generic-param extensions without further reference to the IETF specification process.
独自の適用範囲内でP-Charging-Vectorヘッダーフィールドを使用するアプリケーションは、IETF仕様プロセスを参照しなくても、generic-param拡張を定義できます。
The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses. 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共振で表示される可能性があります。 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メソッドで使用できます。
The information returned in the P-Associated-URI header field is not viewed as particularly sensitive. Rather, it is simply informational in nature, providing openness to the UAC with regard to the automatic association performed by the registrar. If end-to-end protection is not used at the SIP layer, it is possible for proxies between the registrar and the UA to modify the contents of the header value.
P-Associated-URIヘッダーフィールドに返される情報は、特に機密性が高いとは見なされません。むしろ、それは本質的に単なる情報提供であり、レジストラによって実行される自動関連付けに関してUACに開放性を提供します。 SIP層でエンドツーエンド保護が使用されていない場合、レジストラとUA間のプロキシがヘッダー値の内容を変更する可能性があります。
The lack of encryption, either end-to-end or hop-by-hop, may lead to leak some privacy regarding the list of authorized identities. For instance, a user who registers an address-of-record of sip:user1@example.com may get another SIP URI associated as sip:first.last@example.com returned in the P-Associated-URI header field value.
エンドツーエンドまたはホップバイホップのいずれかの暗号化の欠如により、許可されたIDのリストに関するプライバシーが漏洩する可能性があります。たとえば、sip：user1@example.comのレコードのアドレスを登録するユーザーは、P-Associated-URIヘッダーフィールド値で返されるsip：first.last@example.comとして関連付けられた別のSIP URIを取得する場合があります。
An eavesdropper could possibly collect the list of identities a user is registered. This can have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop and where a trust relationship equivalent with that defined in RFC 3325 [RFC3325] between entities exists. That is, the privacy of the user relies on the other entities in the session not disclosing information that they have learned about the user.
盗聴者は、ユーザーが登録されているIDのリストを収集する可能性があります。これはプライバシーに影響を与える可能性があります。この問題を軽減するために、この拡張機能は、SIPメッセージの暗号化がエンドツーエンドまたはホップバイホップで提供され、RFC 3325 [RFC3325]で定義されているものと同等の信頼関係がある安全な環境でのみ使用する必要があります（SHOULD）。エンティティ間に存在します。つまり、ユーザーのプライバシーは、セッション内の他のエンティティに依存し、ユーザーについて学習した情報を開示しません。
While the P-Associated-URI header field value allows the implicit registration of a bundle of URIs with one REGISTER Message, the impact of security using the P-Associated-URI header field is no higher than using separate REGISTER messages for each of the URIs.
P-Associated-URIヘッダーフィールドの値では、URIのバンドルを1つのREGISTERメッセージで暗黙的に登録できますが、P-Associated-URIヘッダーフィールドを使用したセキュリティの影響は、URIごとに個別のREGISTERメッセージを使用する場合よりも高くありません。 。
Due to the nature of the P-Called-Party-ID header field, this header does not introduce any significant security concern. It is possible for an attacker to modify the contents of the header. However, this modification will not cause any harm to the session establishment.
P-Called-Party-IDヘッダーフィールドの性質上、このヘッダーは重大なセキュリティ上の懸念をもたらしません。攻撃者がヘッダーの内容を変更する可能性があります。ただし、この変更によってセッションの確立に害が生じることはありません。
An eavesdropper could possibly collect the list of identities a user has registered. This can have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop.
盗聴者は、ユーザーが登録したIDのリストを収集する可能性があります。これはプライバシーに影響を与える可能性があります。この問題を軽減するために、この拡張機能は、SIPメッセージの暗号化がエンドツーエンドまたはホップバイホップで提供される安全な環境でのみ使用する必要があります（SHOULD）。
Normally, within a 3GPP environment, the P-Called-Party-ID is not sent towards end users but may be exchanged between carriers where other security mechanisms than SIP encryption are used.
通常、3GPP環境では、P-Called-Party-IDはエンドユーザーに向けて送信されませんが、SIP暗号化以外のセキュリティメカニズムが使用されているキャリア間で交換される場合があります。
The P-Visited-Network-ID header field assumes that there is trust relationship between a home network and one or more transited visited networks. It is possible for other proxies between the proxy in the visited network that inserts the header, and the registrar or the home proxy, to modify the value of P-Visited-Network-ID header field. Therefore, intermediaries participating in this mechanism MUST apply a hop-by-hop integrity-protection mechanism such as IPsec or other available mechanisms in order to prevent such attacks.
P-Visited-Network-IDヘッダーフィールドは、ホームネットワークと1つ以上の通過した訪問済みネットワークとの間に信頼関係があることを前提としています。ヘッダーを挿入する訪問先ネットワークのプロキシと、レジストラまたはホームプロキシの間の他のプロキシが、P-Visited-Network-IDヘッダーフィールドの値を変更する可能性があります。したがって、このメカニズムに参加する仲介者は、そのような攻撃を防ぐために、IPsecやその他の利用可能なメカニズムなどのホップバイホップの完全性保護メカニズムを適用する必要があります。
A Trust Domain is formally defined in RFC 3324 [RFC3324]. For the purposes of this document, we refer to the 3GPP trust domain as the collection of SIP proxies and application servers that are operated by a 3GPP network operator and are compliant with the requirements expressed in 3GPP TS 24.229 [TS24.229].
信頼ドメインは、RFC 3324 [RFC3324]で正式に定義されています。このドキュメントでは、3GPP信頼ドメインを、3GPPネットワークオペレーターによって運用され、3GPP TS 24.229 [TS24.229]で表現された要件に準拠しているSIPプロキシとアプリケーションサーバーの集まりと呼びます。
This extension assumes that the access network is trusted by the UA (because the UA's home network has a trust relationship with the access network), as described earlier in this document.
この拡張機能では、このドキュメントで前述したように、アクセスネットワークがUAによって信頼されていることを前提としています（UAのホームネットワークはアクセスネットワークと信頼関係があるため）。
This extension assumes that the information added to the header by the UAC should be sent only to trusted entities and MUST NOT be used outside of the trusted administrative network domain.
この拡張機能は、UACによってヘッダーに追加された情報は信頼できるエンティティにのみ送信され、信頼できる管理ネットワークドメインの外部で使用してはならないことを前提としています。
The SIP proxy that provides services to the user, utilizes the information contained in this header to provide additional services and UAs are expected to provide correct information. However, there are no security problems resulting from a UA inserting incorrect information. Networks providing services based on the information carried in the P-Access-Network-Info header field will therefore need to trust the UA sending the information. A rogue UA sending false access network information will do no more harm than to restrict the user from using certain services.
ユーザーにサービスを提供するSIPプロキシは、このヘッダーに含まれる情報を利用して追加のサービスを提供し、UAは正しい情報を提供することが期待されます。ただし、UAが誤った情報を挿入することによるセキュリティ上の問題はありません。したがって、P-Access-Network-Infoヘッダーフィールドに含まれる情報に基づいてサービスを提供するネットワークは、情報を送信するUAを信頼する必要があります。不正なアクセスネットワーク情報を送信する不正なUAは、ユーザーが特定のサービスを使用することを制限する以上の害はありません。
The mechanism provided in this document is designed primarily for private systems like 3GPP. Most security requirements are met by way of private standardized solutions.
このドキュメントで提供されるメカニズムは、主に3GPPのようなプライベートシステム用に設計されています。ほとんどのセキュリティ要件は、プライベートな標準化されたソリューションによって満たされます。
For instance, 3GPP will use the P-Access-Network-Info header field to carry relatively sensitive information like the cell ID. Therefore, the information MUST NOT be sent outside of the 3GPP domain.
たとえば、3GPPはP-Access-Network-Infoヘッダーフィールドを使用して、セルIDなどの比較的機密性の高い情報を伝送します。したがって、情報を3GPPドメインの外部に送信してはなりません（MUST NOT）。
The UA is aware -- if it is a 3GPP UA -- that it is operating within a trusted domain.
UAは、それが3GPP UAの場合、信頼できるドメイン内で動作していることを認識しています。
The 3GPP UA is aware of whether or not a secure association to the home network domain for transporting SIP signaling is currently available, and, as such, the sensitive information carried in the P-Access-Network-Info header field MUST NOT be sent in any initial unauthenticated and unprotected requests (e.g., REGISTER).
3GPP UAは、SIPシグナリングを転送するためのホームネットワークドメインへの安全な関連付けが現在利用可能であるかどうかを認識しているため、P-Access-Network-Infoヘッダーフィールドに含まれる機密情報を送信してはならない（MUST NOT）認証されておらず、保護されていない最初のリクエスト（例：REGISTER）。
Any UA that is using this extension and is not part of a private trusted domain should not consider the mechanism as secure, and, as such, MUST NOT send sensitive information in the P-Access-Network-Info header field.
この拡張機能を使用しており、プライベートの信頼されたドメインの一部ではないUAは、メカニズムを安全であると見なすべきではないため、P-Access-Network-Infoヘッダーフィールドで機密情報を送信してはなりません。
Any proxy that is operating in a private trust domain where the P-Access-Network-Info header field is supported is REQUIRED to delete the header, if it is present, from any message prior to forwarding it outside of the trusted domain.
P-Access-Network-Infoヘッダーフィールドがサポートされているプライベート信頼ドメインで動作しているプロキシは、ヘッダーが存在する場合は、信頼できるドメインの外に転送する前にメッセージからヘッダーを削除する必要があります。
A proxy receiving a message containing the P-Access-Network-Info header field from an untrusted entity is not able to guarantee the validity of the contents. Thus, this content SHOULD be deleted based on local policy.
信頼できないエンティティからP-Access-Network-Infoヘッダーフィールドを含むメッセージを受信するプロキシは、コンテンツの有効性を保証できません。したがって、このコンテンツはローカルポリシーに基づいて削除する必要があります。
It is expected as normal behavior that proxies within a closed network will modify the values of the P-Charging-Function-Addresses header field and insert it into a SIP request or response. However, the proxies that share this information MUST have a trust relationship.
通常の動作として、閉じたネットワーク内のプロキシがP-Charging-Function-Addressesヘッダーフィールドの値を変更し、それをSIPリクエストまたは応答に挿入することが期待されています。ただし、この情報を共有するプロキシには信頼関係が必要です。
If an untrusted entity were inserted between trusted entities, it could potentially substitute a different charging function address. Therefore, an integrity-protection mechanism such as IPsec or other available mechanisms MUST be applied in order to prevent such attacks. Since each trusted proxy MAY need to view or modify the values in the P-Charging-Function-Addresses header field, the protection should be applied on a hop-by-hop basis.
信頼できないエンティティが信頼できるエンティティの間に挿入された場合、別の課金機能アドレスに置き換えられる可能性があります。したがって、そのような攻撃を防ぐために、IPsecやその他の利用可能なメカニズムなどの整合性保護メカニズムを適用する必要があります。各信頼できるプロキシはP-Charging-Function-Addressesヘッダーフィールドの値を表示または変更する必要がある場合があるため、保護はホップごとに適用する必要があります。
It is expected as normal behavior that proxies within a closed network will modify the values of the P-Charging-Vector header field and insert it into a SIP request or response. However, these proxies that share this information MUST have a trust relationship.
通常の動作として、クローズドネットワーク内のプロキシがP-Charging-Vectorヘッダーフィールドの値を変更し、それをSIPリクエストまたは応答に挿入することが期待されています。ただし、この情報を共有するこれらのプロキシには信頼関係が必要です。
If an untrusted entity were inserted between trusted entities, it could potentially interfere with the charging correlation mechanism. Therefore, an integrity-protection mechanism such as IPsec or other available mechanisms MUST be applied in order to prevent such attacks. Since each trusted proxy MAY need to view or modify the values in the P-Charging-Vector header field, the protection should be applied on a hop-by-hop basis.
信頼できないエンティティが信頼できるエンティティの間に挿入された場合、課金相関メカニズムに干渉する可能性があります。したがって、そのような攻撃を防ぐために、IPsecやその他の利用可能なメカニズムなどの整合性保護メカニズムを適用する必要があります。各信頼できるプロキシはP-Charging-Vectorヘッダーフィールドの値を表示または変更する必要がある場合があるため、保護はホップバイホップベースで適用する必要があります。
This document defines several private SIP extension header fields (beginning with the prefix "P-" ).
このドキュメントでは、いくつかのプライベートSIP拡張ヘッダーフィールドを定義します（先頭が "P-"で始まります）。
This document obsoletes [RFC3455] but uses the same SIP header field names. The references in the "Header Fields" registry and "Header Field Parameters and Parameter Values" registry have been updated to [RFC3455] to this document.
このドキュメントは[RFC3455]を廃止しますが、同じSIPヘッダーフィールド名を使用します。 「Header Fields」レジストリと「Header Field Parameters and Parameter Values」レジストリの参照は、このドキュメントの[RFC3455]に更新されました。
The following extensions are registered as private extension header fields:
次の拡張は、プライベート拡張ヘッダーフィールドとして登録されています。
Header Field Name: P-Associated-URI Compact Form: none Reference: RFC 7315
ヘッダーフィールド名：P-Associated-URIコンパクトフォーム：なし参照：RFC 7315
Header Field Name: P-Called-Party-ID Compact Form: none Reference: RFC 7315
ヘッダーフィールド名：P-Called-Party-IDコンパクトフォーム：なし参照：RFC 7315
Header Field Name: P-Visited-Network-ID Compact Form: none Reference: RFC 7315
ヘッダーフィールド名：P-Visited-Network-IDコンパクトフォーム：なし参照：RFC 7315
Header Field Name: P-Access-Network-Info Parameter Name: ci-3gpp Parameter Name: ci-3gpp2 Parameter Name: ci-3gpp2-femto Parameter Name: dsl-location Parameter Name: dvb-rcs2-node-id Parameter Name: eth-location Parameter Name: fiber-location Parameter Name: gstn-location Parameter Name: i-wlan-node-id Parameter Name: local-time-zone Parameter Name: operator-specific-GI Parameter Name: utran-cell-id-3gpp Parameter Name: utran-sai-3gpp Compact Form: none Reference: RFC 7315 Header Field Name: P-Charging-Function-Addresses Parameter Name: ccf Parameter Name: ccf-2 Parameter Name: ecf Parameter Name: ecf-2 Compact Form: none Reference: RFC 7315
ヘッダーフィールド名：P-Access-Network-Infoパラメーター名：ci-3gppパラメーター名：ci-3gpp2パラメーター名：ci-3gpp2-femtoパラメーター名：dsl-locationパラメーター名：dvb-rcs2-node-idパラメーター名： eth-locationパラメータ名：fibre-locationパラメータ名：gstn-locationパラメータ名：i-wlan-node-idパラメータ名：local-time-zoneパラメータ名：operator-specific-GIパラメータ名：utran-cell-id- 3gppパラメーター名：utran-sai-3gppコンパクトフォーム：なし参照：RFC 7315ヘッダーフィールド名：P-Charging-Function-Addressesパラメーター名：ccfパラメーター名：ccf-2パラメーター名：ecfパラメーター名：ecf-2コンパクトフォーム：なし参照：RFC 7315
Header Field Name: P-Charging-Vector Parameter Name: icid-value Parameter Name: icid-generated-at Parameter Name: orig-ioi Parameter Name: related-icid Parameter Name: related-icid-generated-at Parameter Name: term-ioi Parameter Name: transit-ioi Compact Form: none Reference: RFC 7315
ヘッダーフィールド名：P-Charging-Vectorパラメーター名：icid-valueパラメーター名：icid-generated-atパラメーター名：orig-ioiパラメーター名：related-icidパラメーター名：related-icid-generated-atパラメーター名：term- ioiパラメータ名：transit-ioiコンパクトフォーム：なし参照：RFC 7315
The authors would like to thank James Yu and Atle Monrad for their extensive review, Dean Willis for his expert review, and Mary Barnes for the proto review. The authors would like to acknowledge the constructive feedback and contributions provided by Peter Leis, Joergen Axell, and Jan Holm.
著者は、広範囲にわたるレビューを行ったJames YuとAtle Monrad、専門家のレビューを行ったDean Willis、プロトレビューを行ったMary Barnesに感謝します。著者は、Peter Leis、Joergen Axell、およびJan Holmによって提供された建設的なフィードバックと貢献に感謝します。
The extensions described in [RFC3455] were originally specified in several documents. Miguel Garcia-Martin authored the P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID header fields. Duncan Mills authored the P-Access-Network-Info header. Eric Henrikson authored the P-Charging-Function-Addresses and P-Charging-Vector headers. Rohan Mahy assisted in the incorporation of these extensions into a single document.
[RFC3455]で説明されている拡張機能は、もともといくつかのドキュメントで指定されていました。 Miguel Garcia-Martinは、P-Associated-URI、P-Called-Party-ID、およびP-Visited-Network-IDヘッダーフィールドを作成しました。 Duncan MillsがP-Access-Network-Infoヘッダーを作成しました。エリックヘンリクソンは、P-Charging-Function-AddressesおよびP-Charging-Vectorヘッダーを作成しました。 Rohan Mahyは、これらの拡張機能を1つのドキュメントに組み込むのを支援しました。
The listed authors of [RFC3455] were Miguel Garcia-Martin, Eric Henrikson and Duncan Mills.
[RFC3455]のリストに載っている著者は、ミゲルガルシアマーティン、エリックヘンリクソン、ダンカンミルズでした。
The [RFC3455] authors thanked Andrew Allen, Gabor Bajko, Gonzalo Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Jonathan Rosenberg, Ya-Ching Tan, and the 3GPP CN1 WG members for their comments on [RFC3455].
[RFC3455]の著者は、[RFC3455]についてのコメントについて、Andrew Allen、Gabor Bajko、Gonzalo Camarillo、Keith Drage、Georg Mayer、Dean Willis、Rohan Mahy、Jonathan Rosenberg、Ya-Ching Tan、および3GPP CN1 WGメンバーに感謝しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[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 12.4.0, March 2014.
[TS24.229] 3GPP、「セッション開始プロトコル（SIP）とセッション記述プロトコル（SDP）に基づくIPマルチメディアコール制御プロトコル、ステージ3」、3GPP TS 24.229 12.4.0、2014年3月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324] Watson、M.、「ネットワークアサートされたIDの短期要件」、RFC 3324、2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「Trusted Networks内のAsserted IdentityのためのSession Initiation Protocol（SIP）のプライベート拡張」、RFC 3325、2002年11月。
[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, January 2003.
[RFC3455] Garcia-Martin、M.、Henrikson、E。、およびD. Mills、「第3世代パートナーシッププロジェクト（3GPP）のセッション開始プロトコル（SIP）のプライベートヘッダー（Pヘッダー）拡張」、RFC 3455、2003年1月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、2003年4月。
[RFC4083] Garcia-Martin, M., "Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)", RFC 4083, May 2005.
[RFC4083] Garcia-Martin、M。、「Session Initiation Protocol（SIP）に関するInput 3rd-Generation Partnership Project（3GPP）Release 5要件」、RFC 4083、2005年5月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665] Roach、A。、「SIP固有のイベント通知」、RFC 6665、2012年7月。
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, February 2014.
[RFC7044] Barnes、M.、Audet、F.、Schubert、S.、van Elburg、J。、およびC. Holmberg、「An an Extension to the Session Initiation Protocol（SIP）for Request History Information」、RFC 7044、2月2014。
[TS23.228] 3GPP, "P Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 12.4.0, March 2014.
[TS23.228] 3GPP、「Pマルチメディアサブシステム（IMS）;ステージ2」、3GPP TS 23.228 12.4.0、2014年3月。
[TS32.240] 3GPP, "Telecommunication management; Charging management; Charging architecture and principles", 3GPP TS 32.240 12.3.0, March 2013.
[TS32.240] 3GPP、「通信管理、課金管理、課金アーキテクチャと原則」、3GPP TS 32.240 12.3.0、2013年3月。
[TS32.260] 3GPP, "Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging", 3GPP TS 32.260 10.3.0, April 2011.
[TS32.260] 3GPP、「通信管理、課金管理、IPマルチメディアサブシステム（IMS）課金」、3GPP TS 32.260 10.3.0、2011年4月。
1. Procedures for the P-Associated-URI header field at a proxy. RFC 3455 indicates that it defines no procedures for the P-Associated-URI header field at a proxy. What is implicitly meant here is that the proxy does not add, read, modify, or delete the header; therefore, RFC 3261 proxy procedures only apply to the header.
1. プロキシでのP-Associated-URIヘッダーフィールドの手順。 RFC 3455は、プロキシでP-Associated-URIヘッダーフィールドの手順を定義しないことを示しています。ここで暗黙的に意味されているのは、プロキシがヘッダーを追加、読み取り、変更、または削除しないことです。したがって、RFC 3261プロキシ手順はヘッダーにのみ適用されます。
2. P-Called-Party-ID header field and the History-Info header field: At the time RFC 3455 was written, the History-Info header field was a long way from specification. This header has now been specified and approved in RFC 7044. It is acknowledged that the History-Info header field will provide equivalent coverage to that of the P-Called-Party-ID header field. However, the P-Called-Party-ID header field is used entirely within the 3GPP system and does not appear to SIP entities outside that of a single 3GPP operator.
2. P-Called-Party-IDヘッダーフィールドとHistory-Infoヘッダーフィールド：RFC 3455が作成された時点では、History-Infoヘッダーフィールドは仕様から遠く離れていました。このヘッダーは現在、RFC 7044で指定および承認されています。History-Infoヘッダーフィールドは、P-Called-Party-IDヘッダーフィールドと同等のカバレッジを提供することが認められています。ただし、P-Called-Party-IDヘッダーフィールドは完全に3GPPシステム内で使用され、単一の3GPPオペレーターの外部のSIPエンティティには表示されません。
3. Procedures at the UA for the P-Charging-Function Addresses header field: The text in Section 4.5.2.1 of RFC 3455 does not adequately take into account procedures for UAs located inside the private network, e.g., as gateways and such that may play a full part in network charging procedures. Section 4.5.2.1 is replaced with new text.
3. P-Charging-Function AddressesヘッダーフィールドのUAでの手順：RFC 3455のセクション4.5.2.1のテキストでは、ゲートウェイなど、プライベートネットワーク内にあるUAの手順が適切に考慮されていません。ネットワーク充電手順の完全な部分。セクション4.5.2.1は新しいテキストに置き換えられました。
4. The text in Section 4.6.2.1 of RFC 3455 does not adequately take into account procedures for UAs located inside the private network, e.g., as gateways and such that may play a full part in network charging procedures. Section 4.6.2.1 is now replaced with new text.
4. RFC 3455のセクション4.6.2.1のテキストでは、ゲートウェイなど、プライベートネットワーク内にあるUAの手順を適切に考慮していないため、ネットワークの課金手順で完全な役割を果たす可能性があります。セクション4.6.2.1は新しいテキストに置き換えられました。
5. Recognition of additional values of access technology in the P-Access-Network-Info header field (Section 4.4): A number of new access technologies are contemplated in 3GPP, and the reuse of IMS to support Next Generation Networks (NGN) is also resulting in new access technologies. Values for access technologies are defined explicitly in RFC 3455, and no IANA procedures are defined to maintain a separate registry. In particular, the new values: "IEEE 802.11", "IEEE-802.11g", "IEEE-802.11n", "ADSL" / "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", "IEEE-802.3ak", "IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y", "IEEE-802.3z", and "IEEE-802.3y" are defined.
5. P-Access-Network-Infoヘッダーフィールドでのアクセステクノロジーの追加値の認識（4.4節）：3GPPでは多くの新しいアクセステクノロジーが検討されており、次世代ネットワーク（NGN）をサポートするためのIMSの再利用も行われています。新しいアクセス技術。アクセステクノロジの値はRFC 3455で明示的に定義されており、個別のレジストリを維持するためのIANA手順は定義されていません。特に、新しい値：「IEEE 802.11」、「IEEE-802.11g」、「IEEE-802.11n」、「ADSL」/「ADSL2」、「ADSL2 +」、「RADSL」、「SDSL」、「HDSL」、 「HDSL2」、「G.SHDSL」、「VDSL」、「IDSL」、「IEEE-802.3」、「IEEE-802.3a」、「IEEE-802.3e」、「IEEE-802.3i」、「IEEE-802.3j "、" IEEE-802.3u "、" IEEE-802.3ab "、" IEEE-802.3ae "、" IEEE-802.3ak "、" IEEE-802.3aq "、" IEEE-802.3an "、" IEEE-802.3y " 、「IEEE-802.3z」、「IEEE-802.3y」が定義されています。
6. Replacement of existing value of access technology in the P-Access-Network-Info header field (Section 4.4): The value of "3GPP-CDMA2000" was replaced long ago in 3GPP2 by three new values: "3GPP2-1X", "3GPP2-1X-HRPD", and "3GPP2-UMB". It is not believed that there was any deployment of the "3GPP-CDMA2000" value.
6. P-Access-Network-Infoヘッダーフィールドの既存のアクセステクノロジーの値の置き換え（セクション4.4）：「3GPP-CDMA2000」の値は、3GPP2で3つの新しい値「3GPP2-1X」、「3GPP2」にずっと以前に置き換えられました-1X-HRPD」、「3GPP2-UMB」。 「3GPP-CDMA2000」の値の展開があったとは考えられていません。
7. Network-provided P-Access-Network-Info header field: The P-Access-Network-Info header field may additionally be provided by proxies within the network. This does not impact the values provided by a UA; rather, the header is repeated. Such values are identified by the string "network-provided". A special class of values are defined for use here, as the same granularity of values may not be possible as for those available from the UA: "3GPP-GERAN", "3GPP-UTRAN", "3GPP-WLAN", "3GPP-GAN", and "3GPP-HSPA". Outbound proxies remove P-Access-Network-Info header fields containing the "network-provided" value.
7. ネットワーク提供のP-Access-Network-Infoヘッダーフィールド：P-Access-Network-Infoヘッダーフィールドは、ネットワーク内のプロキシによってさらに提供される場合があります。これは、UAによって提供される値には影響しません。むしろ、ヘッダーは繰り返されます。このような値は、「ネットワーク提供」という文字列で識別されます。 UAから利用可能なものと同じ細かさの値は不可能である可能性があるため、ここで使用するために特別なクラスの値が定義されています。 GAN」、「3GPP-HSPA」。送信プロキシは、「ネットワーク提供」の値を含むP-Access-Network-Infoヘッダーフィールドを削除します。
8. Definition of additional parameters to the P-Charging-Vector header field: Section 5.6 of RFC 3455 defines the syntax of the P-Charging-Vector header field. Additional parameters were considered too application specific for specification in RFC 3455, but it was acknowledged that they would exist, and indeed additional specification of such parameters, relating to specific access technologies, has occurred in 3GPP. Therefore, this update states that applications using the P-Charging-Vector header field within their own applicability are allowed to define generic-param extensions without further reference to the IETF specification process.
8. P-Charging-Vectorヘッダーフィールドへの追加パラメーターの定義：RFC 3455のセクション5.6は、P-Charging-Vectorヘッダーフィールドの構文を定義しています。追加のパラメーターは、RFC 3455の仕様ではアプリケーションに固有すぎると考えられていましたが、それらが存在することが認められ、実際に、特定のアクセステクノロジーに関連するそのようなパラメーターの追加の仕様が3GPPで発生しました。したがって、このアップデートでは、独自の適用範囲内でP-Charging-Vectorヘッダーフィールドを使用するアプリケーションが、IETF仕様プロセスを参照せずにgeneric-param拡張を定義できるようになっていると述べています。
9. In Section 5.7, it was added that the P-Called-Party-ID can appear in the PUBLISH method.
9. セクション5.7では、P-Called-Party-IDをPUBLISHメソッドに表示できることが追加されました。
10. Referencing: RFC 3427 was deleted from the References section as it was not used within the document. Various informative references have now been published as RFCs and have been updated to include the appropriate RFC number. References to 3GPP TS 32.200 were replaced by references to 3GPP TS 32.240 [TS32.240], which is the successor specification. References to 3GPP TS 32.225 were replaced by references to 3GPP TS 32.260 [TS32.260], which is the successor specification. The referencing style was changed to symbolic references. Dates have been removed from all 3GPP references (i.e., latest version applies).
10. 参照：RFC 3427はドキュメント内で使用されていなかったため、参照セクションから削除されました。さまざまな有益な参照がRFCとして公開され、適切なRFC番号を含むように更新されました。 3GPP TS 32.200への参照は、後継仕様である3GPP TS 32.240 [TS32.240]への参照に置き換えられました。 3GPP TS 32.225への参照は、後継仕様である3GPP TS 32.260 [TS32.260]への参照に置き換えられました。参照スタイルがシンボリック参照に変更されました。すべての3GPP参照から日付が削除されました（つまり、最新バージョンが適用されます）。
11. Various editorial changes in alignment with style used in RFC 3261 such as placing response code text in parentheses and using words "request" and "response" in association with method names have been applied.
11. RFC 3261で使用されているスタイルに合わせて、編集コードのさまざまな編集上の変更（括弧内に応答コードテキストを配置したり、メソッド名に関連付けられた "request"および "response"という単語を使用するなど）が適用されました。
Authors' Addresses
著者のアドレス
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7ダルムシュタットドイツ
Phone: +4961515812766
EMail: r.jesske@telekom.de
Keith Drage Alcatel-Lucent Quadrant, StoneHill Green, Westlea Swindon, Wilts UK
キースドラゲアルカテルルーセントクアドラント、ストーンヒルグリーン、ウェストリースウィンドン、ウィルトズイギリス
EMail: drage@alcatel-lucent.com
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com