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)
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.
著作権（C）インターネット協会（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.
この文書では、特定の環境に制限されているそれらの適用と共に、第三世代パートナーシッププロジェクト（3GPP）によって使用されるプライベートセッション開始プロトコル（SIP）のヘッダ（P-ヘッダ）のセットを記述する。 P-ヘッダはパートナーが充電と呼が横断するネットワークに関する情報を含む、使用するネットワーク内の種々の目的のためです。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
第三世代パートナーシッププロジェクト（3GPP）は、そのIPマルチメディア・サブシステム（IMS）の文脈におけるマルチメディアセッションを確立し、取り壊すために使用されるプロトコルとしてSIPを選択しました。 （IMSの詳細については、詳細な説明は、3GPP TS 23.228 [14]および3GPP TS 24.229 [15]に見出すことができます）。 3GPPは、既存のSIP文書はIMSの要件を満たすために必要なほぼすべての機能を提供し、彼らは、この目的のためにSIPを使用するためにいくつかの追加機能を必要とIETF SIPとSIPPINGワーキンググループを通知しました。 [4]これらの要件は、SIPPING作業部会に提出されたインターネットドラフトに記載されています。 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のセットを返すことができます。我々は、REGISTERリクエストに対する200 OK応答に使用されるP-関連-URIヘッダフィールドを定義します。 P-関連-URIヘッダフィールドは、登録されたアドレスのレコードに関連付けられる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を登録していない、ということに注意してください。唯一のアドレス・オブ・レコードREGISTERのToヘッダーフィールドに登録されており、コンタクトアドレスにバインド存在します。搬送される唯一の情報は、レジストラが同じユーザによって使用される他の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のいずれかが登録されているかどうかを確認したい場合は、このドキュメントの外に指定されたメカニズムによってそうすることができ、例えば、UAは、関連するURIのとせずにいずれかに設定Toヘッダーフィールド値を持つREGISTERリクエストを送信することができContactヘッダー。 200 OK応答は、登録された連絡先のリストをContactヘッダーが含まれます。関連する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-関連-URIヘッダは、SIPプロバイダは、ユーザがUAが生成するリクエストで（Fromフィールドのようなヘッダーに）請求することができるアイデンティティのセットを割り当てているSIPネットワークに適用可能です。それはさらに、プロバイダは、ユーザーが合法的に主張することができますアイデンティティのセット全体を知っていること、およびユーザーがそのセットにその主張のアイデンティティを制限する意志があることを前提としています。これは、フィールドから明示的にエンドユーザ指定されたフィールドである通常のSIPの使用とは対照的です。
The registrar inserts the P-Associated-URI header field into the 200 OK response to a REGISTER request. The header field value is populated with a list containing zero or more URIs that are associated to the address-of-record.
レジストラは、REGISTERリクエストに対する200 OK応答の中にP-関連-URIヘッダフィールドを挿入します。ヘッダーフィールド値は、アドレス・オブ・レコードに関連付けられているゼロ個以上の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ヘッダ拡張をサポートしている場合は、レジストラは関係なく、常にレジスタが初期登録であったかどうかの、再、REGISTERリクエストにすべての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ヘッダフィールドを受信することができます。 REGISTER要求のための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は、ヘッダの値、または後続の要求で、発呼者のアイデンティティの情報を提供する任意の他のSIPヘッダー値から移入するために関連付けられたURIのいずれかを使用するかもしれません。
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が登録されているかどうかをチェックします。このチェックは、レジストラおよびContactヘッダなしで送信されたレジスタの値をヘッダには移入することによって、例えば、行うことができます。 200 OK応答は、登録された連絡先のリストをContactヘッダーが含まれます。 SIP [1]に記載されているように、200 OK応答は、ゼロ以上の値（アドレスのレコードが登録されていないゼロを意味する）とContactヘッダーフィールドを含んでいてもよいです。
A registrar that receives and authorizes a REGISTER request, may associate zero or more URIs with the address-of-record.
REGISTER要求を受信し、承認レジストラは、アドレス・オブ・レコードにゼロ以上の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.
この仕様をサポートしているレジストラは、REGISTERリクエストに対する200 OK応答してP-関連-URIヘッダフィールドを含まなければなりません。ヘッダは、アドレスのレコード登録下に関連付けられているSIPまたはSIPS 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またはSIPS URIに関連付けられていない、レジストラは、空のP-関連-URIヘッダの値を含まなければなりません。
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.
プロキシサーバは、専用ルートその宛先に、典型的には、INVITE要求に、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を（アドレス・オブ・レコード）を得ることができます。例えば、ユーザはビジネスSIP URIと個人的なものを得ることができます。利用の例として、ユーザは、労働者を共同して利用可能なビジネスSIP URIを行うことができ、家族のメンバーに個人的なSIP URIを利用可能にすることができます。
At a certain point in time, both the business SIP URI and the personal SIP URI are registered in the SIP registrar, so both URIs can receive invitations to new sessions. When the user receives an invitation to join a session, he/she should be aware of which of the several registered SIP URIs this session was sent to.
ある時点で、ビジネスのSIP URIと個人的なSIP URIの両方がSIPレジストラに登録されているので、両方のURIは、新規セッションへの招待状を受け取ることができます。ユーザーがセッションへの招待を受けたとき、彼/彼女は、このセッションが送られたいくつか登録されたSIP URIのどのに注意する必要があります。
This requirement is stated in the 3GPP Release 5 requirements on SIP [4].
この要件は、SIP [4]に3GPPリリース5つの要件に記載されています。
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.
問題は、INVITEますUAにサービスを提供しているSIPプロキシ、SIPサーバがRequest-URIフィールドに存在するSIP URIを再ターゲティングセッション確立の終端側、中に生じる、及びSIP URIによってそれを置き換えます登録時にREGISTER要求のContactヘッダーフィールドにユーザーによって公開。 UASは、SIP INVITEを受信すると、要求が送られたアドレスのレコードを判断することはできません。
One can argue that the To header field conveys the semantics of the called user, and therefore, this extension to SIP is not needed. Although the To header field in SIP may convey the called party ID in most situations, there are two particular cases when the above assumption is not correct:
一つは、Toヘッダフィールドは、呼び出されるユーザの意味論を伝えるので、SIPにこの拡張が必要とされないと主張することができます。 SIPでのToヘッダーフィールドは、ほとんどの状況で呼ばれるパーティのIDを伝えることができるが、上記の仮定が正しくない場合、2つの特定の例があります。
1. The session has been forwarded, redirected, etc., by previous SIP proxies, before arriving to the proxy 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は、INVITE要求を構築し、Toヘッダーフィールドは、Request-URIと同じではありません。
The problem of using the To header field is that this field is populated by the UAC and not modified by proxies in the path. If the UAC, for any reason, did not populate the To header field with the address-of-record of the destination user, then the destination user is not able to distinguish which address-of-record the session was destined.
フィールドをヘッダーに使用しての問題は、このフィールドは、UACによって移入パスにおけるプロキシによって変更されないことです。 UACは、何らかの理由で、アドレスのレコード先のユーザーのでToヘッダーフィールドに移入しなかった場合、宛先ユーザは、セッションが運命づけされたアドレスのレコードを区別することはできません。
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は、各アドレスのレコードが異なるContactヘッダー値を割り当てることによって、レジスタを区別することができます。 UAは、アドレス・オブ・レコードSIP登録する際、例えば、：ID1を、Contactヘッダー値は、SIPであることができる：ID1 @ UA。 SIPの登録：ID2が接触値一口にバインドすることができます。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が明示的にそのアドレスのレコードのURIの各々を登録することを前提とし、そのため、各登録に割り当てられた連絡先アドレス値を完全に制御しています。しかし、UAが原因で、例えば、サードパーティの登録、の、その登録アドレス・オブ・レコードの完全な制御を持っていない場合には、解決策は動作しません。これは、UAは、以前UAは、特定のアドレス・オブ・レコードを登録する際、いくつかの他のアドレス・オブ・レコードURIは自動的に登録されてもよいことは、SIPの外部手段により、ネットワークを示している可能性があり、3GPP登録の場合であってもよいです。要件は、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がINVITE現在で意図した宛先URIを認識していないように、我々は問題の一例を示し、次の段落では、場合には、セッション中に着信転送のいくつかの並べ替えがありました。
We assume that a User Agent (UA) is registering to his proxy (P1).
私たちは、ユーザーエージェント（UA）は彼のプロキシ（P1）に登録されていることを前提としています。
Scenario UA --- P1
F1 Register UA -> P1 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: sip:user1-business@example.com From: sip:user1-business@example.com;tag=456248 Call-ID: 843817637684230998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:user1@192.0.2.4>
F1の登録UA - > P1 REGISTERのSIP：example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ：SIP：user1-business@example.comから：SIP：user1のビジネス@ example.com;タグ= 456248コールID：843817637684230998sdasdh09のCSeq：1826 REGISTER連絡先：<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>
F2の登録UA - > P1レジスタSIP：example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8へ：SIP：user1-personal@example.comから：SIP：user1が、個人的な@ example.com;タグ= 346249コールID：2Q3817637684230998sdasdh10のCSeq：1827 REGISTER連絡先：<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）は、ユーザーのビジネスSIPアドレス・オブ・レコードに宛て別のプロキシ（P2）からINVITEを受信します。我々は、このSIPは、過去の転送のいくつかの並べ替えを受けたINVITEと仮定し、そのようなものとして、Toヘッダーフィールドは、ユーザーのSIP URIが移入されていません。 other-user@othernetwork.com：このケースでは、セッションが最初一口に宛てたと仮定します。 othernetwork.comのSIPサーバは、SIPするために、このセッションを転送していますuser1-business@example.com
Scenario UA --- P1 --- P2
F3 Invite P2 -> P1 INVITE sip:user1-business@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1 To: sip:other-user@othernetwork.com From: sip:another-user@anothernetwork.com;tag=938s0 Call-ID: 843817637684230998sdasdh09 CSeq: 101 INVITE
F3は、P2を招待 - > P1、SIP INVITE：user1-business@example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1へ：SIP：other-user@othernetwork.comから：SIP： another-user@anothernetwork.com;タグ= 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は、ユーザを再ターゲティングし、Contactヘッダー値の登録時に公開されたSIP URIとのRequest-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
F4 P1を招待 - > UAがSIP INVITE：user1@192.0.2.4のSIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128経由：SIP / 2.0 / UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1への：SIP：other-user@othernetwork.comから：SIP：another-user@anothernetwork.com;タグ= 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がINVITEを受信すると、それは彼のビジネスの登録または個人アドレス・オブ・レコードに起因するセッション招待を得たかどうかを判断することはできません。 UASもプロキシまたはアプリケーションサーバーはいずれも、このユーザーに送信先アドレスのレコードのセッションのに基づいてサービスを提供することができます。
We solve this problem by allowing the proxy that is responsible for the home domain (as defined in SIP) of the user to insert a P-Called-Party-ID header that identifies the address-of-record to which this session is destined.
私たちは、アドレスのレコードこのセッションの宛先であるためにを識別P-Called-Party-IDヘッダを挿入するために、ユーザの（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を取得します、それは、Request-URI F4中の内容とメッセージフローF6にP-Called-Party-IDヘッダに移入されます。これは、フロー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
F5は、P2を招待 - > P1、SIP INVITE：user1-business@example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1へ：SIP：other-user@othernetwork.comから：SIP： another-user@anothernetwork.com;タグ= 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
F6 P1を招待 - > UAがSIP INVITE：user1@192.0.2.4のSIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128経由：SIP / 2.0 / UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1への：SIP：other-user@othernetwork.comから：SIP：another-user@anothernetwork.com;タグ= 938s0のCall-ID：843817637684230998sdasdh09 P-呼び出さパーティ-ID：SIP：user1-business@example.comのCSeq：101 INVITE
When the UA receives the INVITE request F6 it can determine the intended address-of-record of the session, and apply whatever service is needed for that address-of-record.
UAがINVITE要求F6を受信すると、それは意図したアドレスのレコードセッションのを決定し、そのアドレスのレコードのために必要とされるものは何でもサービスに適用することができます。
The P-Called-Party-ID 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-と呼ばれるパーティ-ID UASが意図したアドレスのレコード連絡先へのプロキシ再ターゲティングする前に、リクエストのRequest-URIに存在したのを認識する必要がある場合に適用されます。 UASは、要求の意図された宛先に応じて、異なる視聴覚警告効果又は他のフィルタリングサービスを適用することに興味があるかもしれません。 UASは、彼のレジストラにいくつかのアドレス・オブ・レコードのURIを登録したときには、特別に貴重であり、したがって、UASはそれが彼のプロキシ/レジストラを打ったとき、INVITEリクエストに存在したアドレスのレコードを認識していません、この拡張機能が使用されていない場合。
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要求内のRequest-URIをリターゲットする前にP-Called-Party-IDヘッダを挿入します。ヘッダ値は、連絡先アドレスに置き換える前のRequest-URIの内容が取り込まれています。
A UAC MUST NOT insert a P-Called-Party-ID header field in any SIP request or response.
UACは、任意のSIP要求または応答にP-Called-Party-IDヘッダフィールドを挿入してはいけません。
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は、日付や時間に応じて呼び出し、独特のプレゼンテーションサービス、独特の警告音のフィルタリング、例えば、などと呼ばれるパーティURIに基づいてサービスを、提供するために、P-Called-Party-IDヘッダフィールドの値を使用することができます等
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要求内のRequest-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.
そのヘッダ値のURIに基づいてユーザにサービスを提供するために、ヘッダの内容を使用することができるP-Called-Party-IDヘッダを含むリクエストを受信するプロキシまたはアプリケーションサーバー。
A SIP proxy MUST NOT insert a P-Called-Party-ID header in REGISTER requests.
SIPプロキシは、REGISTERリクエストで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ユーザエージェントは常にホームネットワークに登録してください。 REGISTER要求は、ホームネットワークへの訪問先ネットワークに配置された1つのまたは複数のプロキシによってプロキシされます。単純なアプローチのために、訪問先ネットワークがホームネットワークで知られている識別を含むことを賢明なようです。この識別は、グローバルに一意である、と引用符で囲まれたテキスト文字列またはトークンの形式をとる必要があります。ホームネットワークは、訪問先ネットワークとのローミング契約の存在を確認するために、その訪問先ネットワークを通して登録を認可するために、このIDを使用することができます。
The P-Visited-Network-ID is applicable whenever the following circumstances are met:
以下の状況が満たされるたびにP-訪問ネットワーク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.標準のセキュリティメカニズム、例えば、IPsecの、AKA、またはTLSを使用することでサポートされているホームネットワークと訪問先ネットワーク、及び一般の間で確立された関係を介したUAとホームネットワークプロキシ間の中間プロキシで推移的な信頼があります。
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.エンドポイントは、一つ以上の訪問先ネットワーク（ユーザーが直接の取引関係を持っていないために、ネットワーク）が提供するリソースを使用しています。
3. A proxy that is located in one of the visited networks wants to be identified at the user's home network.
訪問先ネットワークの一つに位置しています3.プロキシは、ユーザのホーム・ネットワークで識別されることを望んでいます。
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. A一般的に事前に合意されたテキスト文字列またはトークンは、ホームネットワークでの訪問先ネットワークを識別します。
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はREGISTERまたはダイアログ開始要求（例えば、INVITE）又は訪問先ネットワーク内のプロキシへのダイアログ（例えば、OPTIONS）外部スタンドアロン要求を送信します。
7. The request traverses, en route to its destination, a first proxy located in the visited network, and a second proxy located in the home network or its destination is the registrar in the home network.
7.要求は、その宛先、訪問先ネットワークに位置する最初のプロキシへの途中、横断、ホームネットワークまたはその先に位置する第2のプロキシは、ホームネットワーク内のレジストラです。
8. The registrar or home proxy verifies and authorizes the usage of resources (e.g., proxies) in the visited network.
8.レジストラまたはホームプロキシが確認し、訪問先ネットワーク内のリソース（例えば、プロキシ）の使用を許可します。
The P-Visited-Network-ID header field 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-訪問ネットワーク-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.
ホームネットワークは、Viaヘッダーフィールドにドメイン名を検査することによって、1つ以上の訪問先ネットワークを識別することは可能であるが、このアプローチは、DNSに大きく依存しています。これは、例えば、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ヘッダを挿入することができます。ケース内のレジスタまたは他の要求が異なる管理ドメイン（例えば、異なる訪問先ネットワーク）を横断している要求はP-訪問ネットワーク-IDヘッダが含まれていない場合、SIPプロキシは、新しい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のプロキシを横断する場合、第二プロキシはP-訪問ネットワーク-IDヘッダの内容を読み取ることができないかもしれません。この状況では、第二プロキシは、その訪問先ネットワーク識別子は、ヘッダの値に既に存在せず、従って、それがうまくいけば、同じ識別子（新しいP-訪問ネットワーク-IDヘッダ値を挿入することを検討しますおそらく、暗号化されていないが挿入された第一プロキシ）。要求は、ホームネットワーク内のレジストラまたはプロキシに到達すると、それは、（第1および第2のプロキシはそれを挿入）ヘッダ値が繰り返されることに気付くであろう。同じ管理ドメインの両方のプロキシがどこの部分ので、復号化された値は、同じでなければなりません。このような状況は望ましくありませんが、それは、ホームネットワーク内のレジストラまたはプロキシに害を作成しません。
The P-Visited-Network-ID is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy
P-訪問ネットワーク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ヘッダを挿入することができる登録状態を維持しない訪問先ネットワークに位置します。このドキュメントの執筆時点で、ダイアログを作成のみリクエストがINVITEている[1]、[11] [6] SUBSCRIBEとREFER。
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-訪問ネットワークIDの値を選択する際に、特に、ネットワークの増加との間の合意をローミング番号を識別子との競合を避けるために、注意を払わなければなりません。識別子は、重複を避けるために、グローバルに一意である必要があります。ネットワークを介してグローバルに一意の識別子を作成するための多くのメカニズムがありますが、メカニズムなどの1がすでに動作している、それはDNSです。 P-訪問ネットワークIDは、DNSへの接続を持たないが、ヘッダの値は、ネットワークのドメイン名を表す独自のDNSエントリから選択することができます。これは、値の一意性を保証します。
User agent clients SHOULD NOT insert a P-Visited-Network-ID header in any SIP message.
ユーザエージェントクライアントは、どのSIPメッセージ内のP-訪問ネットワーク-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-訪問ネットワーク-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プロキシまたはレジストラは、要求が横断一つ以上の訪問先ネットワークの識別子としてP-訪問ネットワーク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は、最終的にREGISTRARに到着から発信REGISTERトランザクションのメッセージシーケンスを示しています。 P1は、UA1のためのアウトバウンドプロキシです。この場合、P1はまた、P-Visited-Network-Idヘッダを挿入します。 P1は次に、経路P2を介してレジストラにREGISTER要求を。
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>
F1の登録UA - > P1 REGISTERのSIP：example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ：SIP：user1-business@example.comから：SIP：user1のビジネス@ example.com;タグ= 456248コールID：843817637684230998sdasdh09のCSeq：1826 REGISTER連絡先：<SIP：user1@192.0.2.4>
In flow F2, proxy P2 adds its own identifier to the P-Visited-Network-ID header.
フローF2において、プロキシP2は、P-訪問ネットワーク-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"
F2登録P1 - > P2 REGISTERのSIP：example.com SIP / 2.0経由：SIP / 2.0 / UDP p1.visited.net;ブランチ= z9hG4bK203igld経由：SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8へ：SIP ：user1-personal@example.comから：SIP：user1-personal@example.com;タグ= 346249コールID：2Q3817637684230998sdasdh10のCSeq：1826 REGISTER連絡先：<SIP：user1@192.0.2.4> P-訪問-ネットワークID ：「ネットワーク番号1を訪問」
Finally, in flow F3, proxy P2 decides to insert his own identifier, derived from its own domain name.
最後に、フロー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"
F3登録P2 - > REGISTRAR REGISTERのSIP：example.com SIP / 2.0経由：SIP / 2.0 / UDP p2.other.net;ブランチ= z9hG4bK2bndnvk経由：SIP / 2.0 / UDP p1.visited.net;ブランチ= z9hG4bK203igld経由：SIP /2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8へ：SIP：user1-personal@example.comから：SIP：user1-personal@example.com;タグ= 346249コールID：2Q3817637684230998sdasdh10のCSeq：1826 REGISTERお問い合わせ： <SIP：user1@192.0.2.4> P-訪問ネットワークID：other.net、 "訪問先ネットワーク番号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は、そのホーム・サービス・プロバイダへの無線アクセス技術と無線セルIDとしてアクセスネットワークに関する情報を渡すために、このヘッダを使用することができます。
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.
この拡張の目的のために、我々は、順番に設けられたSIP機能やサービスへのアクセスをユーザに提供するレイヤ2 /レイヤ3のIP接続性を提供するネットワークなどのアクセスネットワークを定義します。
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-アクセス・ネットワーク情報を定義することによって達成されます。このヘッダは、ホームネットワーク内の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サービスはIPとSIPネットワークに接続するためにUAによって使用される下層技術の詳細を知るSIP要素に依存している環境では適切です。具体的には、拡張子がUAは、それが使用されるアクセス技術を知っていること、およびプロキシサービスを提供するために、そのような情報を希望していることが必要です。一般的に、SIPは、アクセス技術は、SIPの動作には関係ありません「すべてIPおよびIP上のすべての上に」原則、上に構築されています。 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アクセス・ネットワーク情報は、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の、AKA、および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がアクセスされ、それを通して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].
収集機能（CCF）とイベント課金機能（ECF）充電：3GPPによって提供される解決策は、機能エンティティを充電の2種類を定義することです。 CCFは、オフライン（例えば、ポストペイドアカウントの充電）の充電のために使用されます。 ECFは（例えば、アカウントの前払い充電用）の充電にラインに使用されます。ネットワークの冗長性を提供するために、ネットワーク内CCFとECFの単一インスタンスよりもあるかもしれません。場合CCFまたはECFアドレスのいずれかの単一のインスタンス以上存在し、P-Charging-における配列の最初のアドレス（もしあれば）から出発し、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プロキシは、これらのアドレスを事前に設定している場合があり、または加入者データベースからそれらを得ることができます。
4.5.1 Applicability Statement for the P-Charging-Function-Addresses header
P-充電ファンクションアドレスヘッダの4.5.1適用に関する声明
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. A UAは、REGISTERまたはダイアログ開始要求（例えば、INVITE）またはプライベートネットワークの管理ドメイン内に位置するプロキシにダイアログ外側スタンドアローントランザクション要求を送信します。
2. A registrar, proxy or UA that is located in the administrative domain of the private network wants to generate charging records.
2.プライベートネットワークの管理ドメインに位置しているレジストラ、プロキシまたはUAは、レコードを充電生成したいと考えています。
3. A registrar, proxy or UA that is located in the private network has access to the addresses of the charging function entities for that network.
3.プライベートネットワークに位置しているレジストラ、プロキシまたはUAは、そのネットワークの課金機能エンティティのアドレスへのアクセスを持っています。
4. There are other proxies 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.
含むSIP要求を受信したSIPプロキシP-充電ファンクションアドレス情報を充電またはイベントを課金先として、値に含まれるホスト名または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で任意の手順を指定していません。 UAはこのヘッダーを理解する必要がありません。
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-充電ファンクションアドレスが前のメッセージを転送するヘッダ挿入することができます。ヘッダは、プロキシが関連する課金情報を送るべき一つ以上の課金実体のアドレスのリストで埋められます。
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-充電ファンクションアドレスヘッダを含むべきです。メッセージのための次のホップは、プロキシの管理ドメイン外にある場合は、次にプロキシは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.
以下の例は、UA1は、最終的にUA2に到着由来INVITEトランザクションのメッセージシーケンスを示します。 P1は、UA1のためのアウトバウンドプロキシです。この場合、P1はまた、課金情報を挿入します。 P1は次に、ルートUA2にP2を介してコール。
Message sequence for INVITE using P-Charging-Function-Addresses:
P-充電機能・アドレスを使用してINVITEのメッセージシーケンス：
F1 Invite UA1 -> P1 INVITE sip:ua2@home1.net SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: sip:ua2@home1.net From: sip:ua1@home1.net;tag=456248 Call-ID: 843817637684230998sdasdh09 CSeq: 18 INVITE Contact: sip:ua1@192.0.2.4
F1はUA1を招待 - > P1がSIP INVITE：からua2@home1.net：：SIP：UA1 @ home1のua2@home1.net SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ：一口。ネット;タグ= 456248コールID：843817637684230998sdasdh09のCSeq：SIP：ua1@192.0.2.4 18は、連絡先を招待
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
F2 P1を招待 - > P2は、SIP INVITE：ua2@home1.net SIP / 2.0を経由：SIP / 2.0 / UDP p1.home1.net:5060;branch=z9hG4bK34ghi7ab04経由：SIP / 2.0 / UDP 192.0.2.4:5060;branch= z9hG4bKnashds7へ：SIP：ua2@home1.netから：SIP：ua1home1.net;タグは= 456248コールID：843817637684230998sdasdh09のCSeq：18連絡先をINVITE：SIP：ua1@192.0.2.4のP-充電機能-アドレス：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プロキシを含む）複数のネットワークエンティティによって充填し、複数のネットワークエンティティによって取得することができます。転送される相関情報の3つのタイプがあります：IMSは、Identity（ICID）値、ICID値を作成し、SIPプロキシのアドレス、およびインターオペレータ識別子（IOI）を充電します。
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は、グローバルに一意の値でなければなりません。ローカルにユニークな値とホスト名またはローカルにユニークな値を生成したSIPプロキシのIPアドレス：グローバル一意性を達成するための一つの方法は、2つのコンポーネントを使用してICIDを生成することです。
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.
また、アクセスレベルのネットワークの特定の識別子で構成されたアクセスネットワーク課金情報、であることが期待されている（例えば、無線アクセス・ネットワークまたはIEEE 802.11bのUMTS）。ネットワークの各タイプの情報の詳細は、このメモに記載されていません。
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充電ベクトルヘッダーが適用可能です。
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. A UAは、REGISTERまたはダイアログ開始要求（例えば、INVITE）またはプライベートネットワークの管理ドメイン内に位置するプロキシにダイアログ外側スタンドアローントランザクション要求を送信します。
2. A registrar, proxy or UA that is located in the administrative domain of the private network wants to generate charging records.
2.プライベートネットワークの管理ドメインに位置しているレジストラ、プロキシまたはUAは、レコードを充電生成したいと考えています。
3. A 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.
SIP要求および応答エンルート最初のプライベートネットワークに、スルー横断される別のプライベートネットワークにおいて、第2の管理ドメインの一部である4.オプション、レジストラ、プロキシまたはUAは、課金レコードを生成し、それらのレコードを相関させたいです最初のプライベートネットワークのものと。これは、両方のプライベートネットワーク間の信頼関係があることを前提としています。
The P-Charging-Vector header is used to convey charging related information, such as the globally unique IMS charging identifier (ICID) value.
P充電ベクトルヘッダは、識別子（ICID）値を充電そのようなグローバルに一意IMSように、関連する課金情報を伝えるために使用されます。
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.
課金レコードを生成するために、そのようなグローバル一意ICIDなどの値を使用することができるP充電ベクトルヘッダーが含まSIP要求を受信したSIPプロキシ。
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で任意の手順を指定していません。 UAはこのヘッダーを理解する必要がありません。
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.
この例では、UA1 UA2が最終的に到着から発信INVITEトランザクションのメッセージシーケンスを示しています。 P1は、UA1のためのアウトバウンドプロキシです。この場合、P1はまた、課金情報を挿入します。 P1は次に、ルートUA2にP2を介してコール。
Message sequence for INVITE using P-Charging-Vector:
P-充電-ベクターを用いて、INVITEのメッセージシーケンス：
F1 Invite UA1 -> P1 INVITE sip:joe@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: sip:joe@example.com From: sip:ua1@home1.net;tag=456248 Call-ID: 843817637684230998sdasdh09 CSeq: 18 INVITE Contact: sip:ua1@192.0
F1はUA1を招待 - > P1がSIP INVITE：からjoe@example.com：：SIP：UA1 @ home1のjoe@example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ：一口。ネット;タグ= 456248コールID：843817637684230998sdasdh09のCSeq：SIP：ua1@192.0 18は、連絡先を招待
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.
この文書で指定された機構の全ては、[3]散文及びRFC 2234で定義された拡張バッカスナウア記法（BNF）の両方に記載されています。さらに、いくつかのBNFの定義は、SIPから継承されており、ここでは繰り返しません。実装者は、表記とSIPの内容[1]およびRFC 2234 [3]この文書を理解するために精通している必要があります。
The syntax of the P-Associated-URI header is described as follows:
次のようにP-関連-URIヘッダの構文を説明します。
P-Associated-URI = "P-Associated-URI" HCOLON (p-aso-uri-spec) *(COMMA p-aso-uri-spec) p-aso-uri-spec = name-addr *(SEMI ai-param) ai-param = generic-param
P-関連-URI = "P-関連-URI" HCOLON（P-ASO-S-SPEC）*（COMMA P-ASO-S-SPEC）P-ASO-S-ADDR-スペック=名*（SEMIあいPARAM）のジェネリック-PARAM-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-と呼ばれるパーティ-ID = "P-と呼ばれるパーティ-ID" HCOLONと呼ばれる-PTY-ID-スペックと呼ばれる-PTY-ID-スペック=名前-addrには*（SEMI CPID-のparam）CPID-PARAM =ジェネリック-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
P-訪問-ネットワークID = "P-訪問-ネットワークID" HCOLONのvNetwork分散スペック*（COMMAのvNetworkスペック）のvNetworkスペック=（トークン/引用符で囲まれた文字列）*（SEMIのvNetwork-のparam）のvNetwork-PARAM =ジェネリック-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)
P-アクセス・ネットワーク情報= "P-アクセス・ネットワーク情報" HCOLONアクセスネット仕様のアクセスネットスペック=アクセス型*（SEMIアクセス情報）アクセスタイプ= "IEEE-802.11aの" / "IEEE-802.11bの" / "3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" / "3GPP-CDMA2000" /トークンアクセス情報= CGI-3GPP / UTRANセル-ID- 3GPP /拡張アクセス情報拡張アクセス-INFO = GEN-値CGI-3GPP = "CGI-3GPP" EQUAL（トークン/引用符で囲まれた文字列）UTRANセル-ID-3GPP = "UTRANセル-ID-3GPP" EQUAL（トークン/引用符で囲まれた文字列）
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].
アクセス情報は、アクセスネットワークに関連する追加情報が含まれていてもよいです。 "CGI-3GPP" 及び "UTRANセル-ID-3GPP" の値は、[15] 3GPP TS 24.229で定義されています。
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-充電-ADDR = "P-充電機能・アドレス" HCOLONチャージ-addrに-のparams *（SEMI担当-addrに-のparams）担当-addrに-のparams = CCF / ECF /ジェネリック-のparam CCF = "CCF" EQUAL GEN - 値ECF = "ECF" EQUAL GEN-値
The syntax for the P-Charging-Vector header is described as
follows:
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
P-充電-ベクトル= "P-充電-ベクトル" HCOLONのICID-値*（SEMI電荷のparams）電荷のparams = ICID-GEN-addrに/ ORIG-IOI /用語-IOI /ジェネリック-のparam ICID-値= " ICID値」EQUAL GEN-値ICID-GEN-ADDR = "ICID-生成-AT" EQUALホストORIG-IOI = "ORIG-IOI" EQUAL GEN-値という用語は、IOI = "という用語は、IOI" EQUAL GEN-値
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値は、IDを充電IMSを表し、充電レコードとイベントを関連付けるために使用される識別子を含みます。要求を受信する第1のプロキシは、この値を生成します。
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用語-IOIパラメータは、それぞれ、発信および着信interoperator識別子を表します。彼らは、異なる事業者間の課金レコードを相関させるために使用されています。元の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の表2に、この文書で定義されたヘッダを拡張する[1]、SIP固有のイベント通知のセクション7.1 [6]、SIP INFO法の表1及び2 [8]、信頼性の表1及び2 ：仮SIPインスタントメッセージングのためのSIP拡張で[7]、SIPのUPDATEメソッドの表1及び2 [9]、表1及び2 [10]に応答し、SIPの表1は、方法[11] REFERの
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-関連-URIヘッダに返される情報は特に敏感として見ていません。むしろ、それは単にレジストラによって行われる自動連想に関してUACへの開放性を提供し、自然の中で情報提供されます。エンドツーエンドの保護がSIP層で使用されていない場合、レジストラとUAとの間のプロキシはヘッダ値の内容を変更することが可能です。この攻撃は、潜在的に迷惑ながら、重大な影響を与えるべきではありません。
The lack of encryption, either end-to-end or hop-by-hop, may lead to leak some privacy regarding the list of authorized identities. For instance, a user who registers an address-of-record of sip:user1@example.com may get another SIP URI associated as sip:first.last@example.com returned in the P-Associated-URI header 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 URIは、SIPのように関連することがありますfirst.last@example.comはP-関連-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.
盗聴者は、ユーザーが登録されているIDのリストを収集することがあります。これは、プライバシーへの影響を有することができます。この問題を緩和するために、この拡張機能は、SIPメッセージの暗号化はエンドエンドにまたはホップバイホップのいずれかに提供されて保護された環境で使用されるべきである（SHOULD）。
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].
信頼ドメインは、正式にネットワークのための短期要件で定義されているアイデンティティー[13]文書をアサートされます。このドキュメントの目的のために、私たちは、3GPPネットワークオペレータによって操作され、3GPP TS 24.229 [15]で表される要件に準拠しているSIPプロキシおよびアプリケーション・サーバーの集合として、3GPPの信頼ドメインを参照してください。
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から生じたいかなるセキュリティ上の問題はありません。意志はそのための情報を送信してUAを信頼する必要があるP-Access-Network-Infoヘッダで運ばれた情報に基づいてサービスを提供するネットワーク。偽のアクセスネットワーク情報を送信する不正な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は、セルIDのような比較的敏感な情報を運ぶためにP-Access-Network-Infoヘッダを使用します。そのための情報は、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ヘッダで運ばれたそのような機密情報などの任意の初期に送るべきではありません認証されていないと、保護されていない要求（例えば、REGISTER）。
Any UA that is using this extension and is not part of a private trusted domain should not consider the mechanism as secure and as such 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.
したがって、P-Access-Network-Infoヘッダ内の情報を送信するためにそのUAを必要とするネットワークは、そのどちらか、その情報が機密性のものではないか、情報が信頼ドメインの外に送信されていないことを確認する必要があります。
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のRFC番号：RFC3455ヘッダーフィールド名：P-関連-URIコンパクトなフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Called-Party-ID Compact Form: none
RFCのRFC番号：RFC3455ヘッダーフィールド名：P-呼び出さパーティ-IDコンパクトなフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Visited-Network-ID Compact Form: none
RFCのRFC番号：RFC3455ヘッダーフィールド名：P-訪問-ネットワークIDコンパクトなフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Access-Network-Info Compact Form: none
RFCのRFC番号：RFC3455ヘッダーフィールド名：P-アクセス・ネットワーク・インフォメーションコンパクト形：なし
RFC Number: RFC3455 Header Field Name: P-Charging-Function-Addresses Compact Form: none
RFCのRFC番号：RFC3455ヘッダーフィールド名：P-充電機能-アドレスコンパクトなフォーム：なし
RFC Number: RFC3455 Header Field Name: P-Charging-Vector Compact Form: none
RFCのRFC番号：RFC3455ヘッダーフィールド名：P-充電-ベクトルコンパクトなフォーム：なし
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.
この文書で説明した拡張は、もともといくつかの文書で指定されました。ミゲル・ガルシア・マーティンはP-関連-URI、P-と呼ばれるパーティ-IDを執筆し、P-訪問-ネットワーク-IDヘッダ。ダンカンミルズは、P-Access-Network-Infoヘッダを執筆しています。エリックHenriksonはP-充電機能・アドレスおよびP-充電ベクトルヘッダーを執筆しています。ロハンマーイは、1つの文書にこれらの拡張機能の組み込みを支援します。
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.
作者はこのドキュメントの彼らのコメントのためにアンドリュー・アレン、ガボールBajko、ゴンサロ・カマリロ、キース糖剤、ゲオルク・メイヤー、ディーンウィリス、ロハンマーイ、ジョナサン・ローゼンバーグ、雅 - チンタンおよび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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3]クロッカー、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]ガルシア - マーチン、M.、進行中で働いて、「第3世代パートナーシッププロジェクト（3GPP）は、セッション開始プロトコル（SIP）の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]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427 、2002年12月。
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6]ローチ、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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[8]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[9]ローゼンバーグ、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]キャンベル、B.、エディタ、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.及びD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[11] Sparks, R., "The SIP Refer Method", Work in Progress.
[11]、進行中の作業 "SIPメソッドを参照してください"、R.スパークス。
[12] Barnes, M., "SIP Generic Request History Capability Requirements", Work in Progress.
[12]バーンズ、M.、 "SIPジェネリックリクエスト履歴機能要件"、ProgressのWork。
[13] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[13]ワトソン、M.、2002年11月、RFC 3324、 "ネットワークのための短期要件は、アイデンティティをアサート"。
[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/仕様/アーカイブ/ 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に基づくIPマルチメディア呼制御プロトコル;ステージ3（リリース5）"、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.3gpp.org/Specs/archive/32_series /32.225/>。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin Ericsson Hirsalantie 11 Jorvas FIN-02420 Finland EMail: miguel.a.garcia@ericsson.com
ミゲルA.ガルシア・マーティン・エリクソンHirsalantie 11 FIN-02420 Jorvasフィンランドメール：miguel.a.garcia@ericsson.com
Eric Henrikson Lucent 11601 Willows Rd, Suite 100 Redmond, WA 98052 USA EMail: ehenrikson@lucent.com
エリックHenriksonルーセント11601ウィローズRdを、スイート100レドモンド、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
ダンカンミルズボーダフォンザ・コートヤード、2-4ロンドンの道バークシャー州RG14 1JX英国Eメール：duncan.mills@vf.vodafone.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。