[要約] RFC 3455は、3GPPのためのSIPのプライベートヘッダ（P-Header）拡張に関する規格です。このRFCの目的は、3GPPネットワークでのSIPメッセージの拡張性と相互運用性を向上させることです。
Network Working Group M. Garcia-Martin
Request for Comments: 3455 Ericsson
Category: Informational E. Henrikson
Lucent
D. Mills
Vodafone
January 2003
Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
第3世代パートナーシッププロジェクト（3GPP）のセッション開始プロトコル（SIP）へのプライベートヘッダー（P-Header）拡張
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.
このドキュメントでは、第3世代パートナーシッププロジェクト（3GPP）で使用されるプライベートセッション開始プロトコル（SIP）ヘッダー（Pヘッダー）のセットと、特定の環境に限定される適用性について説明します。Pヘッダーは、パートナーが使用するネットワーク内のさまざまな目的のために、充電やネットワークAコールトラバースに関する情報などです。
Table of Contents
目次
1. Overall Applicability . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SIP Private Headers . . . . . . . . . . . . . . . . . . . . . 3
4.1 The P-Associated-URI header. . . . . . . . . . . . . . . . 3
4.1.1 Applicability statement for the
P-Associated-URI header. . . . . . . . . . . . . . . 4
4.1.2 Usage of the P-Associated-URI header . . . . . . . . 4
4.2 The P-Called-Party-ID header . . . . . . . . . . . . . . . 6
4.2.1 Applicability statement for the
P-Called-Party-ID header. . . . . . . . . . . . . . . 9
4.2.2 Usage of the P-Called-Party-ID header. . . . . . . . 10
4.3 The P-Visited-Network-ID header. . . . . . . . . . . . . . 11
4.3.1 Applicability statement for the
P-Visited-Network-ID header. . . . . . . . . . . . . 11
4.3.2 Usage of the P-Visited-Network-ID header . . . . . . 12
4.4 The P-Access-Network-Info header . . . . . . . . . . . . . 15
4.4.1 Applicability Statement for the
P-Access-Network-Info header . . . . . . . . . . . . 16
4.4.2 Usage of the P-Access-Network-Info header . . . . . 17
4.5 The P-Charging-Function-Addresses header . . . . . . . . . 18
4.5.1 Applicability Statement for the
P-Charging-Function-Addresses header . . . . . . . . 18
4.5.2 Usage of the P-Charging-Function-Addresses
headerd. . . . . . . . . . . . . . . . . . . . . . . 19
4.6 The P-Charging-Vector header . . . . . . . . . . . . . . . 21
4.6.1 Applicability Statement for the
P-Charging-Vector header . . . . . . . . . . . . . . 22
4.6.2 Usage of the P-Charging-Vector header . . . . . . . 23
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 P-Associated-URI header syntax . . . . . . . . . . . . . . 25
5.2 P-Called-Party-ID header syntax. . . . . . . . . . . . . . 25
5.3 P-Visited-Network-ID header syntax . . . . . . . . . . . . 25
5.4 P-Access-Network-Info header syntax. . . . . . . . . . . . 25
5.5 P-Charging-Function-Addresses header syntax. . . . . . . . 26
5.6 P-Charging-Vector header syntax. . . . . . . . . . . . . . 26
5.7 Table of new headers . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 28
6.2 P-Called-Party-ID. . . . . . . . . . . . . . . . . . . . . 28
6.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 28
6.4 P-Access-Network-Info. . . . . . . . . . . . . . . . . . . 29
6.5 P-Charging-Function-Addresses. . . . . . . . . . . . . . . 30
6.6 P-Charging-Vector. . . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 30
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34
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 are generally NOT APPLICABLE in the Internet as a whole. The mechanisms specified here were designed to satisfy the requirements specified in the 3GPP Release 5 requirements on SIP [4] for which either no general-purpose solution was planned, where insufficient operational experience was available to understand if a general solution is needed, or where 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の3GPPリリース5要件で指定された要件を満たすように設計されました[4]。一般的なソリューションが計画されていない場合、一般的なソリューションが必要かどうか、またはどこで運用エクスペリエンスが不十分な場合は、より一般的な解決策はまだ成熟していません。これらの拡張機能について行われた仮定の詳細については、各拡張機能のアプリケーションサブセクションを参照してください。
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 BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
The Third Generation Partnership Project (3GPP) has selected SIP as the protocol used to establish and tear down multimedia sessions in the context of its IP Multimedia Subsystem (IMS). (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [14] and 3GPP TS 24.229 [15]). 3GPP notified the IETF SIP and SIPPING working groups that existing SIP documents provided almost all the functionality needed to satisfy the requirements of the IMS, but that they required some additional functionality in order to use SIP for this purpose. These requirements [4] are documented in an Internet Draft which was submitted to the SIPPING Working Group. Some of these requirements are satisfied by chartered extensions, while other requirements were applicable to SIP, but not sufficiently general for the SIP Working Group to adopt. This document describes private extensions to address those requirements. Each extension, or set of related extensions is described in its own section below.
第3世代のパートナーシッププロジェクト（3GPP）は、IPマルチメディアサブシステム（IMS）のコンテキストでマルチメディアセッションを確立および取り壊すために使用されるプロトコルとしてSIPを選択しました。（IMSの詳細については、3GPP TS 23.228 [14]および3GPP TS 24.229 [15]に詳細な説明をご覧ください）。3GPPは、IETF SIPに通知し、ワーキンググループに、既存のSIPドキュメントがIMSの要件を満たすために必要なほぼすべての機能を提供するが、この目的にSIPを使用するために追加の機能が必要であることを通知しました。これらの要件[4]は、すすり回すワーキンググループに提出されたインターネットドラフトに文書化されています。これらの要件の一部はチャーターされた拡張機能によって満たされていますが、他の要件はSIPに適用できましたが、SIPワーキンググループが採用するのに十分な一般ではありません。このドキュメントは、これらの要件に対処するためのプライベートエクステンションについて説明しています。各拡張機能、または関連する拡張機能のセットについては、以下の独自のセクションで説明します。
This extension allows a registrar to return a set of associated URIs for a registered 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 transports the set of Associated URIs to the registered address-of-record.
この拡張機能により、レジストラは、登録された住所のために関連するURIのセットを返すことができます。レジスタリクエストに対する200 OK応答で使用されるp関連型-URIヘッダーフィールドを定義します。P関連-RIヘッダーフィールドは、関連するURIのセットを登録済み住所に輸送します。
An associated URI is a URI that the service provider has allocated to a user for his own usage. A registrar contains information that allows an address-of-record URI to be associated with zero or more URIs. Usually, all these URIs (the address-of-record URI and the associated URIs) are allocated for the usage of a particular user. This extension to SIP allows the UAC to know, upon a successful authenticated registration, which other URIs, if any, the service provider has associated to an address-of-record URI.
関連するURIは、サービスプロバイダーが自分の使用のためにユーザーに割り当てたURIです。レジストラには、録音住所のURIがゼロ以上のURIに関連付けられるようにする情報が含まれています。通常、これらのすべてのURI（録音アドレスURIと関連するURI）は、特定のユーザーの使用に割り当てられます。SIPへのこの拡張機能により、UACは認証された登録を成功させると、他のURIが録音住所URIに関連付けられていることを知ることができます。
Note that, generally speaking, the registrar does not register the associated URIs on behalf of the user. Only the address-of-record which 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 to be used by the same user.
一般的に言えば、レジストラはユーザーに代わって関連するURIを登録しないことに注意してください。レジスタのヘッダーフィールドに存在する録音アドレスのみが登録され、連絡先アドレスに拘束されます。伝えられる唯一の情報は、レジストラが同じユーザーが使用する他のURIを認識していることです。
It may be possible, however, that 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. The 200 OK response will include a Contact header with the list of registered contact addresses. If the associated URI is not registered, the UA MAY register it prior to its utilization.
UACが関連するURIのいずれかが登録されているかどうかを確認したい場合、このドキュメントの外部で指定されたメカニズムによってそうすることができます。連絡先ヘッダー。200 OK応答には、登録された連絡先アドレスのリストに連絡先ヘッダーが含まれます。関連するURIが登録されていない場合、UAはその利用前に登録することができます。
The P-Associated-URI header is applicable in SIP networks where the SIP provider is allocating the set of identities that a user can claim (in headers like the From field) in requests that the UA generates. It furthermore 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 field is explicitly an end-user specified field.
Pに関連する-RIヘッダーは、SIPプロバイダーがUAが生成するリクエストで（From Fromフィールドのようなヘッダーで）請求できる一連のアイデンティティを割り当てているSIPネットワークに適用されます。さらに、プロバイダーは、ユーザーが合法的に請求できるアイデンティティのセット全体を知っており、ユーザーはそのセットに対して請求されたアイデンティティを制限する意思があると想定しています。これは、通常のSIP使用量とは対照的であり、From Fieldは明示的にエンドユーザー指定フィールドです。
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 containing zero or more URIs that are associated to the address-of-record.
レジストラは、Pに関連する-RI-URIヘッダーフィールドをレジスタリクエストへの200 OK応答に挿入します。ヘッダーフィールド値には、録音アドレスに関連付けられているゼロ以上のURIを含むリストが入力されています。
If the registrar supports the P-Associated-URI header extension, then the registrar MUST always insert the P-Associated-URI header field in all the 200 OK responses to a REGISTER request, regardless of whether the REGISTER was an initial registration, re-registration, or de-registration and regardless of whether there are zero or more associated URIs.
レジストラがp関連型-URIヘッダー拡張機能をサポートする場合、レジスタラは、レジスタが初期登録であるかどうかに関係なく、レジスタリクエストに対する200のOK応答すべてに常にP関連のURIヘッダーフィールドを挿入する必要があります。登録、または登録解除およびゼロまたはそれ以上の関連するURIがあるかどうかに関係なく。
A UAC may receive a P-Associated-URI header field in the 200 OK response for a REGISTER. The presence of the header field in the 200 OK response for a REGISTER request implies that the extension is supported at the registrar.
UACは、レジスタの200 OK応答でp関連型-URIヘッダーフィールドを受け取る場合があります。レジスタリクエストの200 OK応答にヘッダーフィールドが存在することは、拡張機能がレジストラでサポートされていることを意味します。
The header value contains a list of zero or more associated URIs to the address-of-record URI. The UAC MAY use any of the associated URIs to populate the From header value, or any other SIP header value that provides information of the identity of the calling party, in a subsequent request.
ヘッダー値には、録音アドレスURIに関連するゼロ以上のURIのリストが含まれています。UACは、関連するURIのいずれかを使用して、From Header値、または後続の要求で、Calling PartyのIDの情報を提供するその他のSIPヘッダー値を入力できます。
The UAC MAY check whether the associated URI is registered or not. This check can be done, e.g., by populating the To header value in a REGISTER sent to the registrar and without a Contact header. The 200 OK response will include a Contact header with the list of registered contact addresses. As described in SIP [1], 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が登録されているかどうかを確認できます。このチェックは、たとえば、レジストラに送信されたレジスタのヘッダー値をコンタクトヘッダーなしで入力することによって行うことができます。200 OK応答には、登録された連絡先アドレスのリストに連絡先ヘッダーが含まれます。SIP [1]で説明されているように、200 OK応答には、ゼロ以上の値を持つコンタクトヘッダーフィールドが含まれている場合があります（ゼロという意味で、録音アドレスが登録されていません）。
A registrar that receives and authorizes a REGISTER request, may associate zero or more URIs with the address-of-record.
レジスタリクエストを受信および承認するレジストラは、ゼロ以上のURIを記録アドレスに関連付けることができます。
A registrar that supports this specification MUST include a P-Associated-URI header field in the 200 OK response to a REGISTER request. The header MUST be populated with a comma-separated list of SIP or SIPS URIs which are associated to the address-of-record under registration.
この仕様をサポートするレジストラには、レジスタリクエストに対する200 OK応答にP関連型-URIヘッダーフィールドを含める必要があります。ヘッダーには、登録の下での記録アドレスに関連付けられているSIPまたはSIP URIのコンマ区切りリストを入力する必要があります。
In case the address-of-record under registration does not have any other SIP or SIPS URIs associated, the registrar MUST include an empty P-Associated-URI header value.
登録中の録音アドレスに他のSIPまたはSIPが関連付けられていない場合、レジストラには空のP関連-RIヘッダー値を含める必要があります。
This memo does not define any procedure at the proxy.
このメモは、プロキシでの手順を定義しません。
A proxy server inserts a P-Called-Party-ID header, 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 UAS identifies which address-of-record, out of several registered address-of-records, the invitation was sent to (for example, the user may be simultaneously using a personal and a business SIP URIs to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the URI used to receive the invitation to the session.
プロキシサーバーは、通常、招待状リクエストで、宛先に招待されたリクエストで、P-Called-Party-IDヘッダーを挿入します。ヘッダーには、リクエストでプロキシが受け取ったリクエスト-URIが入力されています。UASは、登録されているいくつかの録音住所のうち、どの録音住所を識別し、招待状が送信されました（たとえば、ユーザーは個人とビジネスの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 instance, a user may get a business SIP URI and a personal one. As an example of utilization, the user may make available the business SIP URI to co-workers and may make available the personal SIP URI to members of the family.
3GPP IPマルチメディアサブシステム（IMS）のユーザーは、ユーザーを識別するために1つまたは複数のSIP URI（recordのアドレス）を取得できます。たとえば、ユーザーはビジネスシップ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 several registered SIP URIs this session was sent to.
ある時点で、ビジネスSIP URIと個人SIP URIの両方がSIPレジストラに登録されているため、両方のURIは新しいセッションへの招待状を受け取ることができます。ユーザーがセッションに参加する招待状を受け取ったとき、このセッションが送信されたいくつかの登録されたSIPウリのどれに注意する必要があります。
This requirement is stated in the 3GPP Release 5 requirements on SIP [4].
この要件は、SIPの3GPPリリース5要件に記載されています[4]。
The problem arises during the terminating side of a session establishment, when the SIP proxy that is serving a UA gets an INVITE, and the SIP server retargets the SIP URI which is present in the Request-URI field, and replaces it by the SIP URI published by the user in the Contact header field of the REGISTER request at registration time. When the UAS receives the SIP INVITE, it cannot determine which address-of-record the request was sent to.
セッション施設の終了面で問題が発生します。UAにサービスを提供しているSIPプロキシが招待され、SIPサーバーはリクエスト-URIフィールドに存在するSIP URIをリテルゲットし、SIP URIに置き換えます。登録時にレジスタリクエストの連絡先ヘッダーフィールドにユーザーが公開します。UASがSIPの招待状を受信した場合、リクエストが送信された録音アドレスを決定することはできません。
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 Headerフィールドは呼び出されたユーザーのセマンティクスを伝えるため、SIPのこの拡張機能は必要ないと主張することができます。SIPのヘッダーへのフィールドは、ほとんどの状況で呼び出されたパーティーIDを伝える可能性がありますが、上記の仮定が正しくない場合、2つの特定のケースがあります。
1. The session has been forwarded, redirected, etc., by previous SIP proxies, before arriving to the proxy which 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は招待リクエストを構築し、ヘッダーからヘッダーのフィールドはリクエスト-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 which address-of-record the session was destined.
Headerフィールドを使用する問題は、このフィールドがUACによって入力され、パス内のプロキシによって変更されていないことです。何らかの理由で、UACが宛先ユーザーの録音アドレスにヘッダーフィールドに入力しなかった場合、宛先ユーザーは、セッションが運命づけられた記録アドレスを区別することができません。
Another possible solution to the problem is built upon the differentiation of the Contact header 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 value. For instance, when the UA registers the address-of-record sip:id1, the Contact header value can be sip:id1@ua; the registration of sip:id2 can be bound to the Contact value sip:id2@ua.
問題に対する別の可能な解決策は、登録時に異なる録音住所間のコンタクトヘッダー値の区別に基づいて構築されます。UAは、異なる連絡先ヘッダー値を割り当てることにより、各録音アドレスITレジスタを区別できます。たとえば、UAが録音アドレスSIPを登録する場合、ID1、連絡先ヘッダー値はsip：id1@ua;SIPの登録：ID2は、連絡先値SIP：id2@uaにバインドできます。
The solution described above assumes that the UA explicitly registers each of its address-of-record URIs, and therefore, it has full control over the contact address values assigned to each registration. However, in the case the UA does not have full control of its registered address-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 the network, by means outside of SIP, that some other address-of-record URIs 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 [4].
上記のソリューションは、UAが各録音のurisのそれぞれを明示的に登録することを前提としているため、各登録に割り当てられた連絡先アドレス値を完全に制御できます。ただし、UAは、サードパーティの登録など、登録された住所を完全に制御できない場合、ソリューションは機能しません。これは3GPP登録の場合である可能性があります。これは、UAがSIP以外の場合、UAが特定の記録アドレスを登録するときに他のいくつかの録音住所URIが自動的に登録される可能性があることを以前にSIP以外のネットワークを示していた可能性があります。。要件は、SIPの3GPPリリース5要件でカバーされています[4]。
In the next paragraphs we show an example of the problem, in the case 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.
次の段落では、問題の例を示しています。この場合、セッションで何らかのコール転送が行われているため、UACは現在の招待で意図した宛先URIを認識していません。
We assume that a User Agent (UA) is registering to his proxy (P1).
ユーザーエージェント（UA）がプロキシ（P1）に登録していると仮定します。
Scenario UA --- P1
シナリオ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 from another proxy (P2) destined to the user's business SIP address-of-record. We assume that this SIP INVITE 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）は、ユーザーのBusiness SIP住所に向けられた別のプロキシ（P2）から招待状を受け取ります。このSIPの招待状は、過去に何らかの転送を受けているため、ヘッダーフィールドにはユーザーのSIP URIが入力されていないと仮定します。この場合、セッションは最初にsip other-user@othernetwork.comに宛てられたと想定しています。othernetwork.comのSIPサーバーは、このセッションをsip：user1-business@example.comに転送しました
Scenario UA --- P1 --- P2
シナリオ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 value.
プロキシP1はユーザーにリターゲットし、リクエスト-URIを連絡先ヘッダー値の登録時に公開された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, 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 or application servers can provide this user a service based on the destination address-of-record of the session.
UASが招待状を受け取ったとき、事業の登録または個人的な住所のためにセッションの招待状を取得したかどうかを判断することはできません。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 that identifies the address-of-record to which this session is destined.
ユーザーのホームドメイン（SIPで定義されている）に責任のあるプロキシを許可することにより、この問題を解決します。
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 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のリクエスト-URIの内容を備えています。これは、以下のFlows 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 Request F6を受信すると、セッションの意図された住所を決定し、その録音アドレスに必要なサービスを適用できます。
The P-Called-Party-ID 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 specially valuable when the UAS has registered several address-of-record URIs 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が、プロキシが連絡先アドレスにリタールする前に、リクエストのリクエスト-URIに存在する意図された記録アドレスを認識する必要がある場合に適用されます。UASは、リクエストの意図した宛先に応じて、さまざまな視聴覚アラート効果またはその他のフィルタリングサービスを適用することに関心がある場合があります。UASがレジストラにいくつかの録音住所を登録した場合、それは特に価値があります。したがって、UASは、彼のプロキシ/レジストラにヒットしたときに招待リクエストに存在する記録アドレスを認識していません。この拡張機能が使用されない限り。
Requirements for a more general solution are proposed in [12], but have not been adopted by SIP, nor a solution has been developed.
より一般的なソリューションの要件は[12]で提案されていますが、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ヘッダーフィールドは、プロキシがリクエストをリクターゲットする前に、リクエストのリクエスト-URIに存在する記録アドレスをプロキシとUASに提供します。この情報は、パスでの後続のプロキシまたはUASによって使用されることを目的としています。
Typically, a SIP proxy inserts the P-Called-Party-ID header prior to retargetting the Request-URI in the SIP request. The header value is populated with the contents of Request-URI, prior to replacing it with the Contact address.
通常、SIPプロキシは、SIPリクエストでリクエスト-URIをリターゲティングする前に、P-Called-Party-IDヘッダーを挿入します。ヘッダー値には、連絡先アドレスに置き換える前に、リクエスト-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ヘッダーフィールドを挿入してはなりません。
A UAS may receive a SIP request that contains a P-Called-Party-ID header field. The header 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への転送の前に、リクエストのリクエスト-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, MAY insert a P-Called-Party-ID header field in any of the requests indicated in the Table 1 (Section 5.7). The proxy MUST populate the header value with the contents of the Request-URI present in the SIP request that the proxy received.
ユーザーの連絡先情報にアクセスできるプロキシは、表1（セクション5.7）に示されているリクエストのいずれかにP-Called-Party-IDヘッダーフィールドを挿入する場合があります。プロキシは、プロキシが受け取ったSIPリクエストに存在するリクエスト-URIの内容にヘッダー値を入力する必要があります。
It is necessary that the proxy which inserts the P-Called-Party-ID header has information about the user, in order to prevent a wrong delivery of the called party ID. This information may have been learned through a registration process, for instance.
P-Called-Party-IDヘッダーを挿入するプロキシには、呼び出されたパーティーIDの誤った配信を防ぐために、ユーザーに関する情報が必要です。この情報は、たとえば登録プロセスを通じて学習された可能性があります。
A proxy or application server that receives a request containing a P-Called-Party-ID header may use the contents of the header to provide a service to the user based on the URI of that header value.
P-Called-Party-IDヘッダーを含むリクエストを受信するプロキシまたはアプリケーションサーバーは、ヘッダーの内容を使用して、そのヘッダー値のURIに基づいてユーザーにサービスを提供する場合があります。
A SIP proxy MUST NOT insert a P-Called-Party-ID header in REGISTER requests.
SIPプロキシは、レジスタリクエストにP-Called-Party-IDヘッダーを挿入してはなりません。
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. This has the effect 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 one 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 at the home network. This identification should be globally unique, and 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ユーザーエージェントは常にホームネットワークに登録します。レジスタリクエストは、訪問されたネットワークにホームネットワークに向かっている1つ以上のプロキシによってプロキシ化されています。簡単なアプローチのために、訪問されたネットワークにホームネットワークで知られている識別が含まれていることは賢明なようです。この識別はグローバルに一意であり、引用されたテキスト文字列またはトークンの形をとる必要があります。ホームネットワークは、この識別を使用して、訪問されたネットワークとのローミング契約の存在を検証し、訪問したネットワークを通じて登録を承認することができます。
The P-Visited-Network-ID 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, and generally supported by the use of standard security mechanisms, e.g., IPsec, AKA, or TLS.
1. ホームネットワークと訪問されたネットワークの間の確立された関係を介して、UAとホームネットワークプロキシの間の中間プロキシには推移的な信頼があり、一般的に標準セキュリティメカニズム、例えばIPSEC、別名、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 needs to be identified at the home network. Those networks that want to be identified make use of the extension defined in this document. 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 or dialog-initiating request (e.g., INVITE) or a standalone request outside a dialog (e.g., OPTIONS) to a proxy in a visited network.
6. UACは、登録またはダイアログ開始リクエスト（招待など）またはダイアログ外のスタンドアロンリクエスト（例：オプション）を訪問したネットワークのプロキシに送信します。
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 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 with an IP address, for example, and in the absence of a reverse DNS entry, the IP address will not convey the desired information.
Home Networkは、Via Headerフィールドのドメイン名を検査することにより、1つ以上の訪問ネットワークを特定することができますが、このアプローチはDNSに大きく依存しています。これは、プロキシがIPアドレスをIPアドレスに入力するオプションであり、逆DNSエントリがない場合、IPアドレスは目的の情報を伝えません。
Any SIP proxy that receives any of the requests indicated in Table 1 (Section 5.7) MAY insert a P-Visited-Network-ID header when it forwards the request. In case a REGISTER 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 if the request does not contain a P-Visited-Network-ID header with the same network identifier as its own network identifier (e.g., if the request has traversed other different administrative domains).
表1（セクション5.7）に示されているリクエストのいずれかを受信するSIPプロキシは、リクエストを転送するときにP-Visited-Network-IDヘッダーを挿入する場合があります。レジスタまたはその他のリクエストが異なる管理ドメインを通過している場合（例：異なる訪問ネットワーク）、SIPプロキシは、リクエストにP-Visited-Network-IDヘッダーが含まれていない場合、新しいP-Visited-Network-IDヘッダーを挿入する場合があります独自のネットワーク識別子と同じネットワーク識別子を使用します（たとえば、要求が他の異なる管理ドメインを通過した場合）。
Note also that, there is not requirement for the header value to be readable in the proxies. Therefore, a first proxy may insert an encrypted header 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. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header, and therefore, it will insert a new P-Visited-Network-ID header 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 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.
また、プロキシでヘッダー値を読み取る必要がないことにも注意してください。したがって、最初のプロキシは、レジストラのみが復号化できる暗号化されたヘッダーを挿入する場合があります。リクエストが最初のプロキシと同じ管理ドメインにある2番目のプロキシを横断する場合、2番目のプロキシはP-Visited-Network-IDヘッダーの内容を読み取れない場合があります。この状況では、2番目のプロキシは、訪問されたネットワーク識別子がヘッダーの値にまだ存在していないことを考慮します。したがって、新しいp-visited-network-idヘッダー値を挿入します（うまくいけば、同じ識別子を使用して最初に挿入されましたが、おそらく暗号化されていません）。リクエストがホームネットワークのレジストラまたはプロキシに到着すると、ヘッダー値が繰り返されていることがわかります（最初と2番目のプロキシの両方が挿入されました）。復号化された値は同じでなければなりません。なぜなら、同じ管理ドメインの一部がプロキシであるためです。この状況は望ましくありませんが、ホームネットワークのレジストラやプロキシに害はありません。
The P-Visited-Network-ID is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy
P-Visited-Network-IDは通常、登録時に使用されます。ただし、この拡張機能は他の使用法を排除しません。たとえば、プロキシ
located in a visited network that does not maintain registration state may insert a P-Visited-Network-ID header 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 [1], SUBSCRIBE [6] and REFER [11].
登録状態を維持していない訪問されたネットワークに位置する場合、ダイアログ外のスタンドアロンリクエストまたはダイアログを作成する要求の外側のスタンドアロンリクエストにP-Visited-Network-IDヘッダーを挿入する場合があります。このドキュメントの作成時点では、ダイアログを作成する唯一のリクエストは、[1]、購読[6]、[11]を参照します。
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. The identifier should be a globally unique to avoid duplications. Although there are many mechanism to create globally unique identifiers across networks, one of such as mechanisms is already in operation, and that is DNS. The P-Visited-Network-ID does not have any connection to DNS, but the values in the header can be chosen from the own 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エントリから選択できます。これにより、価値の独自性が保証されます。
User agent clients SHOULD NOT insert a P-Visited-Network-ID header in any SIP message.
ユーザーエージェントクライアントは、SIPメッセージにP-Visited-Network-IDヘッダーを挿入しないでください。
A SIP proxy which is located in a visited network MAY insert a P-Visited-Network-ID header field in any of the requests indicated in the Table 1 (Section 5.7). The header 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 at the user's home network.
訪問されたネットワークにあるSIPプロキシは、表1（セクション5.7）に示されているリクエストのいずれかにP-Visited-Network-IDヘッダーフィールドを挿入する場合があります。ヘッダーには、プロキシがユーザーのホームネットワークで動作しているネットワークの管理ドメインを識別するテキスト文字列またはトークンの内容を入力する必要があります。
A SIP proxy or registrar which is located in the home network may use the contents of the P-Visited-Network-ID 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 not of a roaming agreement between the home and the visited networks. This means, for instance, authorize the actions of the request based on the contents of the P-Visited-Network-ID header.
ホームネットワークにあるSIPプロキシまたはレジストラは、リクエストが通過した1つ以上の訪問ネットワークの識別子として、P-Visited-Network-IDのコンテンツを使用する場合があります。ホームネットワーク内のプロキシまたはレジストラは、ホームと訪問ネットワークの間のローミング契約の存在に基づいて、ローカルポリシー駆動型のアクションを実行する場合があります。これは、たとえば、P-Visited-Network-IDヘッダーの内容に基づいて、要求のアクションを承認することを意味します。
A SIP proxy which is located in the home network MUST delete this header when forwarding the message outside the home network administrative domain, in order to retain the user's privacy.
ホームネットワークにあるSIPプロキシは、ユーザーのプライバシーを保持するために、ホームネットワーク管理ドメインの外側にメッセージを転送するときにこのヘッダーを削除する必要があります。
A SIP proxy which is located in the home network SHOULD delete this header when the home proxy has used the contents of the header or the request is routed based on the called party, even when the request is not forwarded outside the home network administrative domain.
ホームネットワークにあるSIPプロキシは、ホームプロキシがヘッダーのコンテンツを使用した場合、またはリクエストがホームネットワーク管理ドメインの外側に転送されない場合でも、コールパーティーに基づいてリクエストがルーティングされる場合、このヘッダーを削除する必要があります。
We present example in the context of the scenario presented in the following network diagram:
次のネットワーク図に記載されているシナリオのコンテキストで例を示します。
Scenario UA --- P1 --- P2 --- REGISTRAR
This example shows the message sequence for an REGISTER transaction originating from UA1 eventually arriving at REGISTRAR. P1 is an outbound proxy for UA1. In this case P1 also inserts the P-Visited-Network-ID header. P1 then routes the REGISTER request to the Registrar via P2.
この例は、最終的にレジストラに到着するUA1から発信されるレジスタトランザクションのメッセージシーケンスを示しています。P1は、UA1のアウトバウンドプロキシです。この場合、P1はP-Visited-Network-IDヘッダーも挿入します。P1は、P2を介してレジスタリクエストをレジストラにルーティングします。
Message sequence for REGISTER using P-Visited-Network-ID header:
p-visited-network-idヘッダーを使用したレジスタのメッセージシーケンス：
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 P2 adds its own identifier to the P-Visited-Network-ID header.
Flow F2では、Proxy P2は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=z9hG4bKnashdt8
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 his own identifier, derived from its own domain name.
最後に、Flow F3では、プロキシP2は、独自のドメイン名から派生した独自の識別子を挿入することを決定します。
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=z9hG4bKnashdt8
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. This header is useful in SIP-based networks that also provide layer 2/layer 3 connectivity through different access technologies. SIP User Agents may use this header 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 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/レイヤー3接続を提供するSIPベースのネットワークで役立ちます。SIPユーザーエージェントは、このヘッダーを使用して、アクセステクノロジーに関する情報を、サービスを提供しているプロキシに中継することができます。サービングプロキシは、この情報を使用してUAのサービスを最適化する場合があります。たとえば、3GPP UAはこのヘッダーを使用して、ラジオアクセステクノロジーやラジオセルのアイデンティティなどのアクセスネットワークに関する情報をホームサービスプロバイダーに渡すことができます。
For the purpose of this extension, we define an access network as the network providing the layer 2/layer 3 IP connectivity which in turn provides a user with access to the SIP capabilities and services provided.
この拡張機能の目的のために、アクセスネットワークをネットワークとして定義し、レイヤー2/レイヤー3 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 which 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サーバーは、特定のサービスをユーザーに提供するために、粗い位置情報を知りたいだけです。たとえば、今日のワイヤレスネットワークで利用可能なロケーションベースのサービスの多くは、ユーザーが提供されているセルの身元を知るためにホームネットワークを必要とします。
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.
いくつかの規制要件が存在し、携帯電話の無線システムでは、緊急電話が確立されたセルの身元が緊急当局が利用できるようにします。
The SIP server that provides services to the user may desire knowledge about the access network. This is achieved by defining a new private SIP extension header, P-Access-Network-Info. This header 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とホームネットワークでのそのサービスプロキシとの間のアクセスネットワークに関連する情報を搭載しています。
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サービスがSIP要素に依存している環境で適切であり、SIPネットワークに接続するためにUAが使用するIPおよび低層テクノロジーの詳細を知っています。具体的には、拡張機能では、UAが使用しているアクセステクノロジーを知っている必要があり、プロキシがサービスを提供するためにそのような情報を望んでいることが必要です。一般的に、SIPは「すべてのIP上のすべてのIPを超えるすべて」の原則に基づいて構築されています。この原則では、アクセステクノロジーがSIPの操作に関連していません。SIPシステムは一般にアクセステクノロジーを気にしたり、知ったりするべきではないため、このSIP拡張機能は一般的なSIP使用のためではありません。
The information revealed in the P-Access-Network-Info header 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. 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 which 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 into 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, this proxy strips the header from the message.
UAがサービスを提供しているSIPプロキシに安全に送信されることがわかっているSIPリクエストまたは応答を生成すると、UAはP-Access-Network-infoヘッダーをSIPメッセージに挿入します。このヘッダーには、UAがIP接続を取得するために使用しているアクセスネットワーク上の情報が含まれています。ヘッダーは通常、UAとサービスを提供しているSIPプロキシとの間の中間プロキシによって無視されます。プロキシ提供サービスは、ヘッダーを検査し、そこに含まれる情報を利用して、ヘッダーの価値に応じて適切なサービスを提供することができます。リクエストを先にプロキシする前に、このプロキシはメッセージからヘッダーをストリップします。
A UA that supports this extension and is willing to disclose the related parameters MAY insert the P-Access-Network-Info header in any SIP request or response.
この拡張機能をサポートし、関連するパラメーターを開示する意思のあるUAは、SIPリクエストまたは応答にP-Access-Network-INFOヘッダーを挿入する場合があります。
The UA inserting this information MUST trust 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 do 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、別名、TLSの使用によってサポートされています。
A proxy MUST NOT insert or modify the value of the P-Access-Network-Info header.
プロキシは、p-access-network-infoヘッダーの値を挿入または変更してはなりません。
A proxy which is providing services to the UA, may act upon any information present in the P-Access-Network-Info header 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ヘッダー値に存在する情報に基づいて行動します。サーバー。たとえば、セルラー無線アクセスネットワークの場合、ホームネットワークにあるSIPプロキシは、セルIDを使用して基本的なローカライズされたサービスを提供する場合があります。
A proxy that provides services to the user, the proxy typically located in the home network, and therefore trusted, MUST delete the header when the SIP signaling is forwarded to a SIP server located in a non-trusted administrative network domain. The SIP server providing services to the UA uses the access network information and 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 off-line charging (e.g., for postpaid account charging). ECF is used for on-line 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. 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.200 [16] and 3GPP TS 32.225 [17].
3GPPが提供するソリューションは、充電コレクション機能（CCF）とイベント充電機能（ECF）の2種類の充電機能エンティティを定義することです。CCFは、オフライン充電に使用されます（例：ポストペイドアカウントの充電など）。ECFは、オンライン充電に使用されます（プリペイドアカウントの充電など）。ネットワークに冗長性を提供するために、ネットワークにCCFとECFの単一のインスタンスがある場合があります。CCFまたはECFアドレスのいずれかに単一のインスタンスがある場合、実装は充電データをECFまたはCCFアドレスに送信しようとする必要があります。関数アドレスヘッダー。CCFおよびECFアドレスは、ダイアログの確立中またはスタンドアロントランザクションで渡される場合があります。充電に関する詳細情報は、3GPP TS 32.200 [16]および3GPP TS 32.225 [17]に記載されています。
We define the SIP private header P-Charging-Function-Addresses. 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. Only one instance of the header MUST be present in a particular request or response.
SIPプライベートヘッダーP充電機能アドレスを定義します。プロキシには、まだ存在していないとしても、ダイアログの初期リクエストまたは応答のいずれか、またはダイアログ外のスタンドアロントランザクションのリクエストと応答を含めることができます。特定のリクエストまたは応答には、ヘッダーの1つのインスタンスのみが存在する必要があります。
The mechanisms by which a SIP proxy collects the values to populate the P-Charging-Function-Addresses header 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充電機能アドレスのヘッダー値を収集するメカニズムは、このドキュメントの範囲外です。ただし、例として、SIPプロキシがこれらのアドレスを事前に構成した場合、またはサブスクライバーデータベースからそれらを取得する場合があります。
The P-Charging-Function-Addresses header 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.200 [16].
P充電機能アドレスヘッダーは、3GPP TS 32.200で指定されたアーキテクチャに従って、充電の調整が必要な単一のプライベート管理ドメイン内で適用できます[16]。
The P-Charging-Function-Addresses header 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充電機能アドレスヘッダーは、独自の管理ドメインの外部で送信されるSIPメッセージに含まれていません。管理ドメインが充電機能を提供しない場合、ヘッダーは適用されません。
The P-Charging-Function-Addresses header is applicable whenever the following circumstances are met:
次の状況が満たされるたびに、P充電融合 - アドレスドレスヘッダーが適用できます。
1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE) or a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UAは、プライベートネットワークの管理ドメインにあるプロキシへのダイアログ外で、登録またはダイアログ開始リクエスト（招待など）またはスタンドアロントランザクションリクエストを送信します。
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 located in the same administrative domain of the private network, that are generated 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 prior to forwarding the request, if the header was not already present in the SIP request. The header value 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充電機能アドレスヘッダーを挿入する場合があります。ヘッダー値には、充電情報を受け取る意思のあるノードのホスト名またはIPアドレスを含む1つ以上のパラメーターが含まれています。
A SIP proxy that receives a SIP request that includes a P-Charging-Function-Addresses may 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充電機能アドレスを含むSIPリクエストを受信するSIPプロキシは、情報または充電イベントの宛先として、値に含まれるホスト名またはIPアドレスを使用する場合があります。これらの充電情報またはイベントを送信する手段は、このドキュメントの範囲外であり、通常、その目的のためにSIPを使用しないでください。
This document does not specify any procedure at the UA, with regard to the P-Charging-Function-Addresses header. UAs need not understand this header.
このドキュメントでは、P充電機能アドレスヘッダーに関して、UAでの手順は指定されていません。UASはこのヘッダーを理解する必要はありません。
However, it might be possible that a UA is located within the administrative domain of a private network (e.g., a PSTN gateway, or conference mixer), and it may have access to the addresses of the charging entities. In this cases, a UA MAY insert the P-Charging-Function-Addresses header in a SIP request or response when the next hop for the message is a proxy located in the same administrative domain.
ただし、UAがプライベートネットワークの管理ドメイン（PSTNゲートウェイや会議ミキサーなど）内に位置する可能性があり、充電エンティティのアドレスにアクセスできる可能性があります。この場合、UAは、メッセージの次のホップが同じ管理ドメインにあるプロキシである場合、SIPリクエストまたは応答にP充電機能アドレスヘッダーを挿入する場合があります。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Function-Addresses MAY insert a P-Charging-Function-Addresses header 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充電融合アドレスを使用せずにリクエストまたは応答を受信するSIPプロキシは、メッセージを転送する前にP充電融合アドレスのヘッダーを挿入する場合があります。ヘッダーには、プロキシが充電関連情報を送信する必要がある1つ以上の充電エンティティのアドレスのリストが入力されています。
If a proxy that supports this extension receives a request or response with the P-Charging-Function-Addresses, 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 administrative domain of the proxy, then the proxy SHOULD include the P-Charging-Function-Addresses header 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.
この拡張機能をサポートするプロキシが、P充電機能アドレスを使用して要求または応答を受信した場合、アプリケーション固有のロジック、つまり充電で使用するヘッダー値から情報を取得する場合があります。メッセージの次のホップがプロキシの管理ドメイン内にある場合、プロキシには、アウトバウンドメッセージにp充電フyction-addressesヘッダーを含める必要があります。ただし、メッセージの次のホップがプロキシの管理ドメインの外側にある場合、プロキシはP充電機能アドレスヘッダーを削除する必要があります。
We present example in the context of the scenario presented in the following network diagram:
次のネットワーク図に記載されているシナリオのコンテキストで例を示します。
Scenario UA1 --- P1 --- P2 --- UA2
In the 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 eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case P1 also inserts charging information. P1 then routes the call via P2 to UA2.
以下の例は、最終的にUA2に到着したUA1から発生する招待トランザクションのメッセージシーケンスを示しています。P1は、UA1のアウトバウンドプロキシです。この場合、P1は充電情報も挿入します。P1は、P2を介してCallをUA2にルーティングします。
Message sequence for INVITE using P-Charging-Function-Addresses:
P充電融合 - アドレスを使用した招待のためのメッセージシーケンス：
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:ua1home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Function-Addresses: ccf=192.1.1.1; ccf=192.1.1.2;
ecf=192.1.1.3; ecf=192.1.1.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 it is not limited to, a globally unique charging identifier that makes easy the billing effort.
相関情報には含まれますが、請求の努力を容易にするグローバルに一意の充電識別子に限定されません。
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 Identifiers (IOI).
充電ベクトルは、充電情報のコレクションとして定義されます。充電ベクトルは、ダイアログまたはダイアログ外のスタンドアロントランザクションの確立中に記入される場合があります。充電ベクトル内の情報は、複数のネットワークエンティティ（SIPプロキシを含む）によって記入され、複数のネットワークエンティティによって取得される場合があります。転送される相関情報には、IMS充電ID（ICID）値、ICID値を作成するSIPプロキシのアドレス、およびインターオペレーター識別子（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 host name 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 an IOI generated from each side of the dialog to identify the network associated with each side.
IOIは、SIPダイアログまたはダイアログ外のトランザクションに含まれる発信および終了ネットワークの両方を識別します。ダイアログの両側から生成されたIOIがあり、各側に関連付けられたネットワークを識別できます。
There is also expected to be access network charging information, which consists of network specific identifiers for the access level (e.g., 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 Radio Access NetworkまたはIEEE 802.11bなど）で構成されるアクセスネットワーク充電情報も期待されています。ネットワークの各タイプの情報の詳細は、このメモに記載されていません。
We define the SIP private header P-Charging-Vector. 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. Only one instance of the header MUST be present in a particular request or response.
SIPプライベートヘッダーP充電ベクトルを定義します。プロキシには、まだ存在していないとしても、ダイアログの初期リクエストまたは応答のいずれか、またはダイアログ外のスタンドアロントランザクションのリクエストと応答を含めることができます。特定のリクエストまたは応答には、ヘッダーの1つのインスタンスのみが存在する必要があります。
The mechanisms by which a SIP proxy collects the values to populate in the P-Charging-Vector are outside the scope of this document.
SIPプロキシがP充電ベクトルに入力する値を収集するメカニズムは、このドキュメントの範囲外です。
The P-Charging-Vector header is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.
P充電ベクトルヘッダーは、単一のプライベート管理ドメイン内またはドメイン間に信頼関係がある異なる管理ドメイン間で適用できます。
The P-Charging-Vector header 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充電 - ベクトルヘッダーは、信頼関係がない場合、別のネットワークに送信されたSIPメッセージに含まれていません。管理ドメインが複数のネットワークエンティティ（SIPプロキシなど）からのレコードの相関を必要としない方法で充電を管理する場合、ヘッダーは適用できません。
The P-Charging-Vector header 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 a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UAは、プライベートネットワークの管理ドメインにあるプロキシへのダイアログ外で、登録またはダイアログ開始リクエスト（招待など）またはスタンドアロントランザクションリクエストを送信します。
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 request and responses are traversed through, en-route to 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。最初のプライベートネットワークの。これは、両方のプライベートネットワーク間に信頼関係があることを前提としています。
The P-Charging-Vector header is used to convey charging related information, such as the globally unique IMS charging identifier (ICID) value.
P充電ベクトルヘッダーは、グローバルに一意のIMS充電識別子（ICID）値などの充電関連情報を伝えるために使用されます。
Typically, a SIP proxy that receives a SIP request that does not contain a P-Charging-Vector header may insert it, with those parameters that are available at the SIP proxy.
通常、P充電ベクトルヘッダーを含まないSIP要求を受信するSIPプロキシは、SIPプロキシで利用可能なパラメーターを使用して挿入する場合があります。
A SIP proxy that receives a SIP request that contains a P-Charging-Vector header may use the values, such as the globally unique ICID, to produce charging records.
P充電ベクトルヘッダーを含むSIPリクエストを受信するSIPプロキシは、グローバルに一意のICIDなどの値を使用して充電レコードを作成する場合があります。
This document does not specify any procedure at the UA, with regard to the P-Charging-Vector header. UAs need not understand this header.
このドキュメントでは、P充電ベクトルヘッダーに関して、UAでの手順は指定されていません。UASはこのヘッダーを理解する必要はありません。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Vector header MAY insert a P-Charging-Vector header prior to forwarding the message. The header is populated with one ore more parameters, as described in the syntax, including but not limited to, a globally unique charging identifier.
この拡張機能をサポートし、p充電ベクトルヘッダーなしでリクエストまたは応答を受信するSIPプロキシは、メッセージを転送する前にp充電ベクトルヘッダーを挿入する場合があります。ヘッダーには、グローバルに一意の充電識別子を含むがこれらに限定されない構文に記載されているように、1つの鉱石のより多くのパラメーターが入力されています。
If a proxy that supports this extension receives a request or response with the P-Charging-Vector header, 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 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.
この拡張機能をサポートするプロキシが、p充電ベクトルヘッダーでリクエストまたは応答を受信する場合、アプリケーション固有のロジック、つまり充電で使用するヘッダー値から情報を取得する場合があります。メッセージの次のホップが信頼できるドメイン内にある場合、プロキシにはアウトバウンドメッセージにp充電ベクトルヘッダーを含める必要があります。メッセージの次のホップが信頼できるドメインの外側にある場合、プロキシはP充電融合 - アドレスヘッダーを削除する場合があります。
Per local application specific logic, the proxy MAY modify the contents of the P-Charging-Vector header prior to sending the message.
ローカルアプリケーション固有のロジックごとに、プロキシは、メッセージを送信する前にp充電ベクトルヘッダーの内容を変更する場合があります。
We present example in the context of the scenario presented in the following network diagram:
次のネットワーク図に記載されているシナリオのコンテキストで例を示します。
Scenario UA1 --- P1 --- P2 --- UA2
This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case P1 also inserts charging information. P1 then routes the call via P2 to UA2.
この例は、最終的にUA2に到着したUA1から発生する招待トランザクションのメッセージシーケンスを示しています。P1は、UA1のアウトバウンドプロキシです。この場合、P1は充電情報も挿入します。P1は、P2を介してCallをUA2にルーティングします。
Message sequence for INVITE using P-Charging-Vector:
p-charing-vectorを使用した招待のためのメッセージシーケンス：
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
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
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [3]. 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 [1] and RFC 2234 [3] to understand this document.
このドキュメントで指定されたすべてのメカニズムは、RFC 2234で定義されている散文と拡張されたバックナウル形式（BNF）の両方で説明されています[3]。さらに、いくつかのBNF定義はSIPから継承され、ここでは繰り返されません。実装者は、このドキュメントを理解するには、SIP [1]およびRFC 2234 [3]の表記と内容に精通している必要があります。
The syntax of the P-Associated-URI header is described as follows:
p関連型尿素ヘッダーの構文は、次のように説明されています。
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 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 calk-pty-id-spec calld-pty-id-spec = name-addr *（semi cpid-param）cpid-param = generic-param
The syntax of the P-Visited-Network-ID header 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 is described as follows:
p-access-network-infoヘッダーの構文は次のように説明されています。
P-Access-Network-Info = "P-Access-Network-Info" HCOLON
access-net-spec
access-net-spec = access-type *(SEMI access-info)
access-type = "IEEE-802.11a" / "IEEE-802.11b" /
"3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN-TDD" /
"3GPP-CDMA2000" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
extension-access-info
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)
The access-info may contain additional information relating to the access network. The values for "cgi-3gpp" and "utran-cell-id-3gpp" are defined in 3GPP TS 24.229 [15].
Access-INFOには、アクセスネットワークに関連する追加情報が含まれる場合があります。「CGI-3GPP」および「utran-cell-id-3gpp」の値は、3GPP TS 24.229 [15]で定義されています。
The syntax for the P-Charging-Function-Addresses header is described as follows:
P充電融合とアドレスのヘッダーの構文は、次のように説明されています。
P-Charging-Addr = "P-Charging-Function-Addresses" HCOLON charge-addr-params *(SEMI charge-addr-params) charge-addr-params = ccf / ecf / generic-param ccf = "ccf" EQUAL gen-value ecf = "ecf" EQUAL gen-value
p-charging-addr = "p-charing-function-addresses" hcolon charge-addr-params *（semi charge-addr-params）charge-addr-params = ccf / ecf / generic-param ccf = "ccf"-value ecf = "ecf"等しいgen-value
The syntax for the P-Charging-Vector header is described as follows:
P充電ベクトルヘッダーの構文は次のように説明されています。
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value
*(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi /
term-ioi / 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
The P-Charging-Vector contains icid-value 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充電ベクトルには、ICID値の必須パラメーターが含まれています。ICID-ValueはIMS充電IDを表し、充電レコードとイベントの相関に使用される識別子が含まれています。リクエストを受信する最初のプロキシは、この値を生成します。
The icid-gen-addr parameter contains the host name or IP address of the proxy that generated the icid-value.
ICID-GEN-ADDRパラメーターには、ICID値を生成したプロキシのホスト名またはIPアドレスが含まれています。
The orig-ioi and term-ioi parameters represent, respectively, the 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は、セッションの終了部分またはスタンドアロン要求の充電記録の責任者ネットワークを表します。
Table 1 extends the headers defined in this document to Table 2 in SIP [1], section 7.1 of the SIP-specific event notification [6], tables 1 and 2 in the SIP INFO method [8], tables 1 and 2 in Reliability of provisional responses in SIP [7], tables 1 and 2 in the SIP UPDATE method [9], tables 1 and 2 in the SIP extension for Instant Messaging [10], and table 1 in the SIP REFER method [11]:
表1は、このドキュメントで定義されているヘッダーを、SIP [1]の表2、SIP固有のイベント通知[6]のセクション7.1、SIP情報方法[8]の表1および2、信頼性の表1および2に拡張します。SIP [7]の暫定的な応答、SIP更新方法[9]の表1および2、SIP拡張の表1および2の瞬間メッセージの表1と2、およびSIP参照法[11]の表1の表1および2
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Associated-URI 2xx - - - - - o
P-Called-Party-ID R amr - - - o o -
P-Visited-Network-ID R ad - - - o o o
P-Access-Network-Info dr - o - o o o
P-Charging-Vector admr - o - o o o
P-Charging-Function- adr - o - o o o
Addresses
Header field SUB NOT PRA INF UPD MSG REF
___________________________________________________________
P-Associated-URI - - - - - - -
P-Called-Party-ID o - - - - o o
P-Visited-Network-ID o - - - - o o
P-Access-Network-Info o o o o o o o
P-Charging-Vector o o o o o o o
P-Charging-Function- o o o o o o o
Addresses
Table 1: Header field support
表1：ヘッダーフィールドサポート
The information returned in the P-Associated-URI header 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. This attack, while potentially annoying, should not have significant impacts.
p関連型-RIヘッダーで返される情報は、特に敏感であるとは見なされません。むしろ、それは本質的に単に情報に基づいており、レジストラが実行した自動関連に関して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 value. An eavesdropper could collect this information. If the user does not want to disclose the associated URIs, the eavesdropper could have gain access to private URIs. Therefore it is RECOMMENDED that this extension is used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop.
エンドツーエンドまたはホップバイホップの暗号化の欠如は、承認されたアイデンティティのリストに関するプライバシーをリークする可能性があります。たとえば、sip：user1@example.comの録音アドレスを登録するユーザーは、sip：first.last@example.comとして別のSIP URIをP-Associated-URIヘッダー値で返します。盗聴者はこの情報を収集できます。ユーザーが関連するURIを開示したくない場合、盗聴者はプライベートURIにアクセスできる可能性があります。したがって、この拡張機能は、SIPメッセージの暗号化がエンドツーエンドまたはホップバイホップのいずれかで提供される安全な環境で使用されることをお勧めします。
Due to the nature of the P-Called-Party-ID header, 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 may collect the list of identities a user is registered. This may 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.
盗聴者は、ユーザーが登録されているアイデンティティのリストを収集する場合があります。これにはプライバシーへの影響があります。この問題を軽減するには、この拡張機能は、SIPメッセージの暗号化がエンドツーエンドまたはホップバイホップのいずれかで提供される安全な環境でのみ使用する必要があります。
The P-Visited-Network-ID header 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. Therefore intermediaries participating in this mechanism MUST apply a hop-by-hop integrity protection mechanism such us 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 the Short term requirements for Network Asserted Identity [13] document. For the purpose 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 [15].
信頼ドメインは、ネットワーク主張されたID [13]ドキュメントの短期的要件で正式に定義されています。このドキュメントの目的のために、3GPP Trustドメインを、3GPPネットワークオペレーターによって動作し、3GPP TS 24.229で表される要件に準拠したSIPプロキシおよびアプリケーションサーバーのコレクションと呼びます[15]。
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 should 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 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プロキシは、このヘッダーに含まれる情報を利用して追加のサービスを提供し、UASは正しい情報を提供することが期待されます。ただし、UAが誤った情報を挿入することに起因するセキュリティ上の問題はありません。したがって、P-Access-Network-INFOヘッダーにある情報に基づいてサービスを提供するネットワークは、情報を送信するUAを信頼する必要があります。誤ったアクセスネットワーク情報を送信するRogue 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 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ドメインの外部で送信してはなりません。
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 SHOULD NOT be sent in any initial unauthenticated and unprotected requests (e.g., REGISTER).
3GPP UAは、SIPシグナル伝達を輸送するためのホームネットワークドメインとの安全な関連性が現在利用可能かどうかを認識しているため、P-Access-Network-INFOヘッダーに掲載されている機密情報を最初に送信しないでください無慈悲で保護されていないリクエスト（登録など）。
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 SHOULD NOT send sensitive information in the P-Access-Network-Info header.
この拡張機能を使用しており、プライベート信頼できるドメインの一部ではないUAは、メカニズムを安全であると考えるべきではないため、P-Access-Network-infoヘッダーに機密情報を送信するべきではありません。
Any proxy that is operating in a private trust domain where the P-Access-Network-Info header 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ヘッダーがサポートされているプライベートトラストドメインで動作しているプロキシは、信頼できるドメインの外側に転送する前に、ヘッダーが存在する場合は存在する場合に削除するために必要です。
Therefore, a network that requires its UA to send information in the P-Access-Network-Info header must ensure that either that information is not of a sensitive nature or that the information is not sent outside of the trust domain.
したがって、UAにP-Access-Network-INFOヘッダーに情報を送信する必要があるネットワークは、その情報が機密性のある性質ではないこと、または情報が信頼ドメインの外側に送信されないことを確認する必要があります。
A proxy receiving a message containing the P-Access-Network-Info header from a non-trusted entity is not able to guarantee the validity of the contents.
非信頼性のあるエンティティから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 and insert it into a SIP request or response. However, these proxies that share this information MUST have a trust relationship.
閉じたネットワーク内のプロキシは、p充電融合アドレスの値を変更し、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, the protection should be applied on a hop-by-hop basis.
信頼されていないエンティティが信頼できるエンティティ間に挿入された場合、潜在的に異なる充電機能アドレスを置き換える可能性があります。したがって、そのような攻撃を防ぐために、IPSECやその他の利用可能なメカニズムなどの完全性保護メカニズムを適用する必要があります。信頼できる各プロキシは、P充電機能アドレスヘッダーの値を表示または変更する必要がある場合があるため、保護はホップバイホップベースで適用する必要があります。
It is expected as normal behavior that proxies within a closed network will modify the values of the P-Charging-Vector and insert it into a SIP request or response. However, these proxies that share this information MUST have a trust relationship.
閉じたネットワーク内のプロキシは、p充電ベクトルの値を変更し、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, the protection should be applied on a hop-by-hop basis.
信頼されていないエンティティが信頼できるエンティティ間に挿入された場合、充電相関メカニズムを妨害する可能性があります。したがって、そのような攻撃を防ぐために、IPSECやその他の利用可能なメカニズムなどの完全性保護メカニズムを適用する必要があります。信頼できる各プロキシは、p充電ベクトルヘッダーの値を表示または変更する必要がある場合があるため、保護はホップバイホップベースで適用する必要があります。
This document defines several private SIP extension header fields (beginning with the prefix "P-" ).
このドキュメントでは、いくつかのプライベートSIP拡張ヘッダーフィールドを定義します（プレフィックス「P-」で始まります）。
These extension headers have been included in the registry of SIP header fields defined in SIP [1]. Expert review as required for this process was provided by the SIP Working Group.
これらの拡張ヘッダーは、SIPで定義されたSIPヘッダーフィールドのレジストリに含まれています[1]。このプロセスに必要な専門家のレビューは、SIPワーキンググループによって提供されました。
The following extensions are registered as private extension header fields:
次の拡張機能は、プライベートエクステンションヘッダーフィールドとして登録されています。
RFC Number: RFC3455 Header Field Name: P-Associated-URI Compact Form: none
RFC番号：RFC3455ヘッダーフィールド名：p関連型-URIコンパクトフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Called-Party-ID Compact Form: none
RFC番号：RFC3455ヘッダーフィールド名：P-Called-Party-IDコンパクトフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Visited-Network-ID Compact Form: none
RFC番号：RFC3455ヘッダーフィールド名：P-Visited-Network-IDコンパクトフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Access-Network-Info Compact Form: none
RFC番号：RFC3455ヘッダーフィールド名：P-Access-Network-INFOコンパクトフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Charging-Function-Addresses Compact Form: none
RFC番号：RFC3455ヘッダーフィールド名：P-charing-Function-Addressesコンパクトフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Charging-Vector Compact Form: none
RFC番号：RFC3455ヘッダーフィールド名：P-charging-Vectorコンパクトフォーム：なし
The extensions described in this document were originally specified in several documents. Miguel Garcia-Martin authored the P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID headers. 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.
このドキュメントで説明されている拡張機能は、もともといくつかのドキュメントで指定されていました。Miguel Garcia-Martinは、P関連-RI、P-Called-Party-ID、およびP-Visited-Network-IDヘッダーを執筆しました。Duncan Millsは、P-Access-Network-infoヘッダーを執筆しました。エリック・ヘンリクソンは、P充電融合 - アドレスとP充電ベクトルヘッダーを執筆しました。Rohan Mahyは、これらの拡張機能を単一のドキュメントに組み込むのを支援しました。
The authors would like to thank 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 this document.
著者は、アンドリュー・アレン、ガボール・バジコ、ゴンザロ・カマリロ、キース・ドレイジ、ジョージ・メイヤー、ディーン・ウィリス、ロハン・マヒー、ジョナサン・ローゼンバーグ、ヤシング・タン、3GPP CN1 WGメンバーにこの文書にコメントしてくれたことに感謝します。
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[4] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress.
[4] Garcia-Martin、M。、「セッション開始プロトコル（SIP）の第3世代パートナーシッププロジェクト（3GPP）リリース5要件」、進行中の作業。
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[5] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J.、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC 3427、2002年12月。
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[8] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[9] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[10] Campbell, B., Editor, Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[10] Campbell、B.、編集者、Rosenberg、J.、Schulzrinne、H.、Huitema、C。and D. Gurle、「インスタントメッセージング用のセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[11] Sparks, R., "The SIP Refer Method", Work in Progress.
[11] Sparks、R。、「SIP refery Method」、進行中の作業。
[12] Barnes, M., "SIP Generic Request History Capability Requirements", Work in Progress.
[12] Barnes、M。、「一般的な要求履歴能力要件をSIP」、進行中の作業。
[13] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[13] ワトソン、M。、「ネットワーク主張されたアイデンティティの短期要件」、RFC 3324、2002年11月。
[14] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", 3GPP 23.228, September 2002, <ftp://ftp.3gpp.org/ Specs/archive/23_series/23.228/>.
[14] 3GPP、 "TS 23.228：IPマルチメディアサブシステム（IMS）;ステージ2（リリース5）"、3GPP 23.228、2002年9月、<ftp://ftp.3gpp.org/ specs/archive/23_series/23.228/>。
[15] 3GPP, "TS 24.229: IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", 3GPP 24.229, September 2002, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[15] 3GPP、 "TS 24.229：SIPおよびSDP;ステージ3（リリース5）"に基づくIPマルチメディアコールコントロールプロトコル、3GPP 24.229、2002年9月、<ftp://ftp.3gpp.org/specs/archive/24_series/24.229//>。
[16] 3GPP, "TS 32.200: Telecommunication Management; Charging management; Charging principles (Release 5)", 3GPP 32.200, June 2002, <ftp://ftp.3gpp.org/Specs/archive/32_series/32.200/>.
[16] 3GPP、「TS 32.200：通信管理;充電管理;充電原則（リリース5）」、3GPP 32.200、2002年6月、<ftp://ftp.3gpp.org/specs/archive/32_series/32.200/>。
[17] 3GPP, "TS 32.225: Telecommunication Management; Charging management; Charging Data Description for IP Multimedia Subsystem (Release 5)", 3GPP 32.225, September 2002, <ftp:// ftp.3gpp.org/Specs/archive/32_series/32.225/>.
[17] 3GPP、 "TS 32.225：電気通信管理;充電管理; IPマルチメディアサブシステムの充電データの説明（リリース5）"、3GPP 32.225、2002年9月、<ftp：// <ftp：//>。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin Ericsson Hirsalantie 11 Jorvas FIN-02420 Finland EMail: miguel.a.garcia@ericsson.com
Miguel A. Garcia-Martin Ericsson Hirsalantie 11 Jorvas Fin-02420フィンランドメール：miguel.a.garcia@ericsson.com
Eric Henrikson Lucent 11601 Willows Rd, Suite 100 Redmond, WA 98052 USA EMail: ehenrikson@lucent.com
Eric Henrikson Lucent 11601 Willows Rd、Suite 100 Redmond、WA 98052 USAメール：ehenrikson@lucent.com
Duncan Mills Vodafone The Courtyard, 2-4 London Road Newbury, Berkshire RG14 1JX UK EMail: duncan.mills@vf.vodafone.co.uk
Duncan Mills Vodafone The Courtyard、2-4 London Road Newbury、Berkshire RG14 1JX UKメール：duncan.mills@vf.vodafone.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。