RFC3455 日本語訳
3455 Private Header (P-Header) Extensions to the Session InitiationProtocol (SIP) for the 3rd-Generation Partnership Project (3GPP). M.Garcia-Martin, E. Henrikson, D. Mills. January 2003. (Format: TXT=79620 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Garcia-Martin
Request for Comments: 3455 Ericsson
Category: Informational E. Henrikson
Lucent
D. Mills
Vodafone
January 2003
コメントを求めるワーキンググループM.ガルシア-マーチンの要求をネットワークでつないでください: 3455年のエリクソンカテゴリ: 情報のE.Henrikson透明なD.はボーダフォン2003年1月にかけめぐります。
Private Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
第3世代パートナーシッププロジェクトのためのセッション開始プロトコル(一口)への個人的なヘッダー(P-ヘッダー)拡大(3GPP)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.
このドキュメントは第3世代Partnership Project(3GPP)によって使用された1セットの個人的なSession Initiationプロトコル(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
1. 総合的な適用性. . . . . . . . . . . . . . . . . . . . 3 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 概観. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4。 P関連URIヘッダーのSIP兵士のHeaders. . . . . . . . . . . . . . . . . . . . . 3 4.1。 . . . . . . . . . . . . . . . 3 4.1 .1 P関連URIヘッダーのための適用性証明。 . . . . . . . . . . . . . . 4 4.1 P関連URIヘッダー. . . . . . . . 4 4.2Party IDと呼ばれるPヘッダーの.2使用法、Party IDと呼ばれるPヘッダーのための.64.2.1Applicability声明。 . . . . . . . . . . . . . . 9 4.2 .2 Party IDと呼ばれるPヘッダーの使用法。 . . . . . . . 10 4.3 PがネットワークIDを訪問しているヘッダー。 . . . . . . . . . . . . . 11 4.3 .1 PがネットワークIDを訪問しているヘッダーのための適用性証明。 . . . . . . . . . . . . 11
Garcia-Martin, et. al. Informational [Page 1] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[1ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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
4.3.2 PがネットワークIDを訪問しているヘッダー. . . . . . 12 4.4の使用法、Pアクセスネットワークインフォメーションヘッダー、.154.4、.1Applicability Statement、Pアクセスネットワークインフォメーションヘッダー、.164.4、.2Usage、Pアクセスネットワークインフォメーションヘッダー. . . . . 17 4.5機能アドレスを請求するPヘッダー、.184.5、.1Applicability Statement、P充電機能アドレスヘッダー、.184.5、.2Usage、機能アドレスを請求するP headerdについて。 . . . . . . . . . . . . . . . . . . . . . . 19 4.6 P充電ベクトルヘッダー、.214.6、.1Applicability Statement、P充電ベクトルヘッダー、.224.6、.2Usage、P充電ベクトルヘッダー. . . . . . . 23 5 正式なSyntax. . . . . . . . . . . . . . . . . . . . . . . . 25 5.1P関連URIヘッダー構文. . . . . . . . . . . . . . 25 5.2Party IDと呼ばれるPヘッダー構文。 . . . . . . . . . . . . . 25 5.3 PがネットワークIDを訪問しているヘッダー構文. . . . . . . . . . . . 25 5.4Pアクセスネットワークインフォメーションヘッダー構文。 . . . . . . . . . . . 25 5.5機能アドレスを請求するPヘッダー構文。 . . . . . . . 26 5.6P充電ベクトルヘッダー構文。 . . . . . . . . . . . . . 26 新しいヘッダー. . . . . . . . . . . . . . . . . . . 27 6の5.7テーブル。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 28 6.1P関連URI.286.2に、Pは、IDにパーティに電話をしました。 . . . . . . . . . . . . . . . . . . . . 28 6.3 PがネットワークIDを訪問している.286.4Pアクセスネットワークインフォメーション。 . . . . . . . . . . . . . . . . . . 29 6.5 P充電機能アドレス。 . . . . . . . . . . . . . . 30 6.6P充電ベクトル。 . . . . . . . . . . . . . . . . . . . . 30 7. IANA問題。 . . . . . . . . . . . . . . . . . . . . 30 8. 貢献者. . . . . . . . . . . . . . . . . . . . . . . . 31 9。 承認。 . . . . . . . . . . . . . . . . . . . . . . 32 10. 引用規格. . . . . . . . . . . . . . . . . . . . 32 11。 有益な参照. . . . . . . . . . . . . . . . . . . 32作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 33の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 34
Garcia-Martin, et. al. Informational [Page 2] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[2ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
1. Overall Applicability
1. 総合的な適用性
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と下層の間のリンケージ、および他動な信用の有用性をします。 一般に、これらの仮定は全体でインターネットのNOT APPLICABLEです。 ここで指定されたメカニズムは汎用解決策が全く計画されていなかったSIP[4]に関する3GPP Release5要件で指定された要件を満たすように設計されました、不十分な運用経験が一般解が必要であるかどうか、または、より一般的な解決策がどこでまだ熟していないかを理解するために利用可能であったところで。 これらの拡大に関してされた仮定に関するその他の詳細に関しては、各拡大のためにApplicability小区分に相談してください。
2. Conventions
2. コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
3. Overview
3. 概観
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.
プロトコルがIP Multimedia Subsystem(IMS)の文脈におけるマルチメディアセッションを確立して、以前はよく取りこわしていたとき、Third Generation Partnership Project(3GPP)はSIPを選択しました。 (IMSの詳しい情報に関しては、3GPP TS23.228[14]と3GPP TS24.229[15])で詳述を見つけることができます。 3GPPは、このためにSIPを使用するためにSIPが記録する存在がIMSの要件を満たすのに必要であるほとんどすべての機能性を提供しましたが、彼らが何らかの追加機能性を必要としたことをIETF SIPとSIPPINGワーキンググループに通知しました。 これらの要件[4]はSIPPING作業部会に提出されたインターネットDraftに記録されます。 これらの要件のいくつかが貸し切りの拡大で満たされていますが、他の要件は、SIPに適切ですが、SIP作業部会が採用できるくらいには一般的ではありませんでした。 このドキュメントは、それらの要件を記述するために個人的な拡大について説明します。 それぞれの拡大、またはセットの関連する拡大は下のそれ自身のセクションで説明されます。
4. SIP Private Headers
4. 個人的なヘッダーをちびちび飲んでください。
4.1 The P-Associated-URI header
4.1 P関連URIヘッダー
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.
この拡大で、記録係は登録された記録されている住所のために1セットの関連URIを返すことができます。 私たちはREGISTER要求への200OK応答に使用されるP関連URIヘッダーフィールドを定義します。 P関連URIヘッダーフィールドはAssociated URIのセットを登録された記録されている住所に輸送します。
Garcia-Martin, et. al. Informational [Page 3] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[3ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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 MUST NOTは、関連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のどれかとContactヘッダーなしでToヘッダーフィールド選択値群によるREGISTER要求を送るかもしれません。 200OK応答は登録された連絡先のリストでContactヘッダーを含むでしょう。 関連URIが登録されていないなら、UA MAYは利用の前にそれを登録します。
4.1.1 Applicability statement for the P-Associated-URI header
4.1.1 P関連URIヘッダーのための適用性証明
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用法と対照的になっています。そこでは、From分野は明らかに、エンドユーザが分野を指定したということです。
4.1.2 Usage of the P-Associated-URI header
4.1.2 P関連URIヘッダーの使用法
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要求への200OK応答にP関連URIヘッダーフィールドを挿入します。 リストが記録されている住所に関連づけられるゼロか、より多くのURIを含んでいて、ヘッダーフィールド値は居住されます。
Garcia-Martin, et. al. Informational [Page 4] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[4ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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が新規登録、再登録、または反-登録であったことにかかわらずゼロか、より関連したURIがあるかどうかにかかわらずREGISTER要求へのすべての200のOK応答にP関連URIヘッダーフィールドを挿入しなければなりません。
4.1.2.1 Procedures at the UA
4.1.2.1 UAの手順
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はREGISTERのために200OK応答におけるP関連URIヘッダーフィールドを受けるかもしれません。 REGISTER要求のための200OK応答における、ヘッダーフィールドの存在は、拡大が記録係で支持されるのを含意します。
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 MAYはFromヘッダー価値、または起呼側のアイデンティティの情報を提供するいかなる他の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 MAYは、関連URIが登録されているかどうかチェックします。 このチェックができます、例えば、記録係とContactヘッダーなしで送られたREGISTERでToヘッダー価値に居住することによって。 200OK応答は登録された連絡先のリストでContactヘッダーを含むでしょう。 SIP[1]で説明されるように、200OK応答はゼロか、より多くの値があるContactヘッダーフィールドを含むかもしれません(記録されている住所を意味するのは登録されていません)。
4.1.2.2 Procedures at the registrar
4.1.2.2 記録係における手順
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要求への200OK応答で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ヘッダー価値を入れなければなりません。
4.1.2.3 Procedures at the proxy
4.1.2.3 プロキシにおける手順
This memo does not define any procedure at the proxy.
このメモはプロキシにおけるどんな手順も定義しません。
Garcia-Martin, et. al. Informational [Page 5] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[5ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
4.2 The P-Called-Party-ID header
4.2 Party IDと呼ばれるPヘッダー
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.
プロキシサーバは目的地への途中で、Party IDと呼ばれるPヘッダーを通常INVITE要求に挿入します。 Request-URIが要求にプロキシによって受け取られている状態で、ヘッダーは居住されます。 UASは、記録の登録されたアドレス、招待が数個からのどの記録されている住所に送られたかを特定します(例えば、ユーザは、セッションへの招待を受けるためには同時に、使用a個人的であって、ビジネス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 Multimedia Subsystem(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 Release5要件に述べられています。
The problem arises during the terminating side of a session establishment, when the SIP proxy that is serving a UA gets an INVITE, and the SIP server retargets the SIP URI which is present in the Request-URI field, and replaces it by the SIP URI published by the user in the Contact header field of the REGISTER request at registration time. When the UAS receives the SIP INVITE, it cannot determine which address-of-record the request was sent to.
問題はセッション設立の終わり側面の間、起こります、UAに勤めているSIPプロキシがRequest-URI分野でINVITE、およびSIPサーバ「再-目標」に存在しているSIP URIを手に入れて、それを登録時にREGISTER要求のContactヘッダーフィールドにおけるユーザによって発行されたSIP URIに取り替えるとき。 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:
1つは、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と同じではありません。
Garcia-Martin, et. al. Informational [Page 6] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[6ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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.
Toヘッダーフィールドを使用するという問題はこの分野が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.
問題の別の可能な解決は登録時に異なった記録されている住所の間のContactヘッダー価値の分化のときに組立しています。 UAはそれが異なったContactヘッダー価値を割り当てることによって登録する各記録されている住所を微分できます。 -例えば、UAがアドレスを登録するときには、記録では、ちびちび飲んでください: id1、Contactヘッダー価値は: id1@ua; をちびちび飲むことであるかもしれません。 一口の登録: Contact値の一口に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が登録された記録されている住所を完全に管理しない、例えば、第三者登録、解決策は働いていません。 これが3GPP登録のそうであるかもしれない、SIPの外では、手段で、UAであるときに、ある他の記録されている住所URIが自動的に登録されるかもしれないのが特定の記録されている住所を登録します。そこで、UAは以前に、ネットワークを示したかもしれません。 要件は3GPP Release5要件でSIP[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).
私たちは、Userエージェント(UA)が彼のプロキシ(P1)に登録していると思います。
Scenario UA --- P1
シナリオUA--- P1
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
F1Register Ua->P1 REGISTER一口: example.com SIP/2.0Via: 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: 一口: user1-business@example.com From: 一口: user1-business@example.com;tag =456248Call-ID: 843817637684230998sdasdh09 CSeq: 1826は接触を登録します: <一口: user1@192.0.2.4 、gt。
The user also registers his personal URI to his/her registrar.
また、ユーザは彼の個人的なURIをその人の記録係に登録します。
Garcia-Martin, et. al. Informational [Page 7] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[7ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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 REGISTER一口: example.com SIP/2.0Viaを登録します: 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashdt8To: 一口: user1-personal@example.com From: 一口: user1-personal@example.com;tag =346249Call-ID: 2Q3817637684230998sdasdh10 CSeq: 1827は接触を登録します: <一口: user1@192.0.2.4 、gt。
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サーバはこのセッションのときに一口: user1-business@example.com に転送しました。
Scenario UA --- P1 --- P2
シナリオUA--- P1--- P2
F3 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F3はP2->P1 INVITE一口: user1-business@example.com SIP/2.0Viaを招待します: 一口/2.0/UDP192.0.2.20: 5060;ブランチ=z9hG4bK03djaoe1To: 一口: other-user@othernetwork.com From: 一口: another-user@anothernetwork.com;tag は938s0 Call-IDと等しいです: 843817637684230998sdasdh09 CSeq: 101 招待
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 retargets、Request-URIを登録時間Contactヘッダー価値で発行されたSIP URIに取り替えます。
F4 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F4はP1->UA INVITE一口: user1@192.0.2.4 SIP/2.0Viaを招待します: 一口/2.0/UDP192.0.2.10: 5060; ブランチは以下を通ってz9hG4bKg48sh128と等しいです。 一口/2.0/UDP192.0.2.20: 5060;ブランチ=z9hG4bK03djaoe1To: 一口: other-user@othernetwork.com From: 一口: another-user@anothernetwork.com;tag は938s0 Call-IDと等しいです: 843817637684230998sdasdh09 CSeq: 101 招待
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かプロキシもアプリケーション・サーバーもセッションの目的地記録されている住所に基づくサービスをこのユーザに提供できません。
Garcia-Martin, et. al. Informational [Page 8] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[8ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
We solve this problem by allowing the proxy that is responsible for the home domain (as defined in SIP) of the user to insert a P-Called-Party-ID header that identifies the address-of-record to which this session is destined.
ユーザの家のドメイン(SIPで定義されるように)に責任があるプロキシがこのセッションが運命づけられている記録されている住所を特定するParty IDと呼ばれるPヘッダーを挿入するのを許容することによって、私たちはこの問題を解決します。
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を手に入れて、それはF4でメッセージ流動F6でRequest-URIのコンテンツでParty IDと呼ばれるPヘッダーに居住するでしょう。 これは流れの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 INVITE一口: user1-business@example.com SIP/2.0Viaを招待します: 一口/2.0/UDP192.0.2.20: 5060;ブランチ=z9hG4bK03djaoe1To: 一口: other-user@othernetwork.com From: 一口: another-user@anothernetwork.com;tag は938s0 Call-IDと等しいです: 843817637684230998sdasdh09 CSeq: 101 招待
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 INVITE一口: user1@192.0.2.4 SIP/2.0Viaを招待します: 一口/2.0/UDP192.0.2.10: 5060; ブランチは以下を通ってz9hG4bKg48sh128と等しいです。 一口/2.0/UDP192.0.2.20: 5060;ブランチ=z9hG4bK03djaoe1To: 一口: other-user@othernetwork.com From: 一口: another-user@anothernetwork.com;tag は938s0 Call-IDと等しいです: Party IDと呼ばれる843817637684230998sdasdh09P: 一口: user1-business@example.com CSeq: 101 招待
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を受けるとき、それは、セッションの意図している記録されている住所を決定して、その記録されている住所に必要であるどんなサービスも適用できます。
4.2.1 Applicability statement for the P-Called-Party-ID header
4.2.1 Party IDと呼ばれるPヘッダーのための適用性証明
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.
UASが、要求のRequest-URIで存在している意図している記録されている住所を意識している必要があるとき、Party IDと呼ばれるPは適切です、連絡先へのプロキシ「再-目標」の前で。 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によって採用されません、または、解決策は見いだされました。
Garcia-Martin, et. al. Informational [Page 9] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[9ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
4.2.2 Usage of the P-Called-Party-ID header
4.2.2 Party IDと呼ばれるPヘッダーの使用法
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.
Party IDと呼ばれるPヘッダーフィールドはプロキシ「再-目標」の前での要求のRequest-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.
Request-URIをretargettingする前に、通常、SIPプロキシはParty IDと呼ばれるPヘッダーをSIP要求に挿入します。 それをContactアドレスに取り替える前に、ヘッダー値はRequest-URIのコンテンツで居住されます。
4.2.2.1 Procedures at the UA
4.2.2.1 UAの手順
A UAC MUST NOT insert a P-Called-Party-ID header field in any SIP request or response.
UAC MUST NOTはParty IDと呼ばれるPヘッダーフィールドをどんなSIP要求や応答にも挿入します。
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はParty IDと呼ばれるPヘッダーフィールドを含むSIP要求を受け取るかもしれません。 ヘッダーがアドレスで居住される、-、-記録は要求のRequest-URIにおけるプロキシのそばで受信されました、UASへの推進の前に。
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に基づくサービスを提供するのにトーンなどを警告しながら、Party IDと呼ばれるPヘッダーフィールドに値を使用するかもしれません。
4.2.2.2 Procedures at the proxy
4.2.2.2 プロキシにおける手順
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.
ユーザのContact情報に近づく手段を持っているプロキシ、Table1(セクション5.7)で示された要求のいずれにもParty IDと呼ばれるPヘッダーフィールドを挿入するかもしれません。 Request-URIのコンテンツが存在していた状態で、プロキシはプロキシが受信したというSIP要求でヘッダー値に居住しなければなりません。
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.
Party IDと呼ばれるPヘッダーを挿入するプロキシがユーザの情報を持っているのが必要です、被呼者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.
Party IDと呼ばれるPヘッダーを含む要求を受け取るプロキシかアプリケーション・サーバーが、そのヘッダー価値のURIに基づくユーザに対するサービスを提供するのにヘッダーのコンテンツを使用するかもしれません。
A SIP proxy MUST NOT insert a P-Called-Party-ID header in REGISTER requests.
A SIP proxy MUST NOT insert a P-Called-Party-ID header in REGISTER requests.
Garcia-Martin, et. al. Informational [Page 10] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 10] RFC 3455 3GPP SIP P-Header Extensions January 2003
4.3 The P-Visited-Network-ID header
4.3 The P-Visited-Network-ID header
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 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.
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.
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.
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 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.
4.3.1 Applicability statement for the P-Visited-Network-ID header
4.3.1 Applicability statement for the P-Visited-Network-ID header
The P-Visited-Network-ID is applicable whenever the following circumstances are met:
The P-Visited-Network-ID is applicable whenever the following circumstances are met:
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. 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.
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. 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).
3. A proxy that is located in one of the visited networks wants to be
identified at the user's home network.
3. A proxy that is located in one of the visited networks wants to be identified at the user's home network.
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. 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.
Garcia-Martin, et. al. Informational [Page 11] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 11] RFC 3455 3GPP SIP P-Header Extensions January 2003
5. A commonly pre-agreed text string or token identifies the visited
network at the home network.
5. A commonly pre-agreed text string or token identifies the visited network at the home network.
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. 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.
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. 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.
8. The registrar or home proxy verifies and authorizes the usage of
resources (e.g., proxies) in the visited network.
8. The registrar or home proxy verifies and authorizes the usage of resources (e.g., proxies) in the visited network.
4.3.2 Usage of the P-Visited-Network-ID header
4.3.2 Usage of the P-Visited-Network-ID header
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.
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.
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.
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.
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.
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.
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).
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).
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
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
Garcia-Martin, et. al. Informational [Page 12] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 12] RFC 3455 3GPP SIP P-Header Extensions January 2003
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.
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.
The P-Visited-Network-ID is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy
The P-Visited-Network-ID is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy
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].
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].
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.
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.
4.3.2.1 Procedures at the UA
4.3.2.1 Procedures at the UA
User agent clients SHOULD NOT insert a P-Visited-Network-ID header in any SIP message.
User agent clients SHOULD NOT insert a P-Visited-Network-ID header in any SIP message.
4.3.2.2 Procedures at the registrar and proxy
4.3.2.2 Procedures at the registrar and proxy
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.
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.
Garcia-Martin, et. al. Informational [Page 13] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 13] RFC 3455 3GPP SIP P-Header Extensions January 2003
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.
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.
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.
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.
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.
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.
4.3.2.3 Examples of Usage
4.3.2.3 Examples of Usage
We present example in the context of the scenario presented in the following network diagram:
We present example in the context of the scenario presented in the following network diagram:
Scenario UA --- P1 --- P2 --- REGISTRAR
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.
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.
Message sequence for REGISTER using P-Visited-Network-ID header:
Message sequence for REGISTER using P-Visited-Network-ID header:
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 Register UA -> P1 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: sip:user1-business@example.com From: sip:user1-business@example.com;tag=456248 Call-ID: 843817637684230998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:user1@192.0.2.4>
In flow F2, proxy P2 adds its own identifier to the P-Visited-Network-ID header.
In flow F2, proxy P2 adds its own identifier to the P-Visited-Network-ID header.
Garcia-Martin, et. al. Informational [Page 14] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 14] RFC 3455 3GPP SIP P-Header Extensions January 2003
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 Register P1 -> P2 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP p1.visited.net;branch=z9hG4bK203igld Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8 To: sip:user1-personal@example.com From: sip:user1-personal@example.com;tag=346249 Call-ID: 2Q3817637684230998sdasdh10 CSeq: 1826 REGISTER Contact: <sip:user1@192.0.2.4> P-Visited-Network-ID: "Visited network number 1"
Finally, in flow F3, proxy P2 decides to insert his own identifier, derived from its own domain name.
Finally, in flow F3, proxy P2 decides to insert his own identifier, derived from its own domain name.
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 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"
4.4 The P-Access-Network-Info header
4.4 The P-Access-Network-Info header
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.
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.
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.
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.
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
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
Garcia-Martin, et. al. Informational [Page 15] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 15] RFC 3455 3GPP SIP P-Header Extensions January 2003
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.
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.
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.
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.
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.
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.
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.
4.4.1 Applicability Statement for the P-Access-Network-Info header
4.4.1 Applicability Statement for the P-Access-Network-Info header
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.
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.
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.
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.
Garcia-Martin, et. al. Informational [Page 16] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 16] RFC 3455 3GPP SIP P-Header Extensions January 2003
4.4.2 Usage of the P-Access-Network-Info header
4.4.2 Usage of the P-Access-Network-Info header
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.
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.
4.4.2.1 UA behavior
4.4.2.1 UA behavior
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.
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.
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.
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.
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.
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.
4.4.2.2 Proxy behavior
4.4.2.2 Proxy behavior
A proxy MUST NOT insert or modify the value of the P-Access-Network-Info header.
A proxy MUST NOT insert or modify the value of the P-Access-Network-Info header.
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.
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.
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 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
Garcia-Martin, et. al. Informational [Page 17] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 17] RFC 3455 3GPP SIP P-Header Extensions January 2003
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.
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.
4.5 The P-Charging-Function-Addresses header
4.5 The P-Charging-Function-Addresses header
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 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.
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].
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].
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.
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.
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.
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.
4.5.1 Applicability Statement for the P-Charging-Function-Addresses
header
4.5.1 Applicability Statement for the P-Charging-Function-Addresses header
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].
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].
Garcia-Martin, et. al. Informational [Page 18] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 18] RFC 3455 3GPP SIP P-Header Extensions January 2003
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.
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.
The P-Charging-Function-Addresses header is applicable whenever the following circumstances are met:
The P-Charging-Function-Addresses header is applicable whenever the following circumstances are met:
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 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.
2. A registrar, proxy or UA that is located in the administrative
domain of the private network wants to generate charging records.
2. A registrar, proxy or UA that is located in the administrative domain of the private network wants to generate charging records.
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. 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.
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. 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.5.2 Usage of the P-Charging-Function-Addresses header
4.5.2 Usage of the P-Charging-Function-Addresses header
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.
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.
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.
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.
4.5.2.1 Procedures at the UA
4.5.2.1 Procedures at the UA
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.
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.
Garcia-Martin, et. al. Informational [Page 19] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 19] RFC 3455 3GPP SIP P-Header Extensions January 2003
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.
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.
4.5.2.2 Procedures at the Proxy
4.5.2.2 Procedures at the Proxy
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.
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.
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.
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.
4.5.2.3 Examples of Usage
4.5.2.3 Examples of Usage
We present example in the context of the scenario presented in the following network diagram:
We present example in the context of the scenario presented in the following network diagram:
Scenario UA1 --- P1 --- P2 --- UA2
Scenario UA1 --- P1 --- P2 --- UA2
In the scenario we assume that P1 and P2 belong to the same administrative domain.
In the scenario we assume that P1 and P2 belong to the same administrative domain.
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.
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.
Message sequence for INVITE using P-Charging-Function-Addresses:
Message sequence for INVITE using P-Charging-Function-Addresses:
Garcia-Martin, et. al. Informational [Page 20] RFC 3455 3GPP SIP P-Header Extensions January 2003
Garcia-Martin, et. al. Informational [Page 20] RFC 3455 3GPP SIP P-Header Extensions January 2003
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
F1Invite UA1->P1 INVITE一口: ua2@home1.net SIP/2.0Via: 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: 一口: ua2@home1.net From: 一口: ua1@home1.net;tag =456248Call-ID: 843817637684230998sdasdh09 CSeq: 18 接触を招いてください: 一口: ua1@192.0.2.4
F2 Invite P1 -> P2
INVITE sip:ua2@home1.net SIP/2.0
Via: SIP/2.0/UDP p1.home1.net:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:ua2@home1.net
From: sip:ua1home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Function-Addresses: ccf=192.1.1.1; ccf=192.1.1.2;
ecf=192.1.1.3; ecf=192.1.1.4
F2はP1->P2 INVITE一口: ua2@home1.net SIP/2.0Viaを招待します: 一口/2.0/UDP p1.home1.net: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: 一口: ua2@home1.net From: 一口: ua1home1.net; =456248Call-IDにタグ付けをしてください: 843817637684230998sdasdh09 CSeq: 18 接触を招いてください: 一口: 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アドレスを意識しています。 両方のプロキシは充電情報を同じ実体に送ることができます。
4.6 The P-Charging-Vector header
4.6 P充電ベクトルヘッダー
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 Charging Identity(ICID)値、ICID値、およびInter Operator Identifiers(IOI)を作成するSIPプロキシのアドレス。
Garcia-Martin, et. al. Informational [Page 21] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[21ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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 MUST、グローバルにユニークな値になってください。 ユニークさをグローバルに獲得する1つの方法は2つのコンポーネントを使用することでICIDを発生させることです: 局所的にユニークな値を発生させたSIPプロキシの局所的にユニークな値とホスト名かIPアドレス。
The IOI identifies both the originating and terminating networks involved in a SIP dialog or transaction outside a dialog. There may an IOI generated from each side of the dialog to identify the network associated with each side.
IOIは由来とネットワークが対話の外でSIP対話か取引にかかわった終わりの両方を特定します。 そこでは、それぞれの側に関連しているネットワークを特定するために対話のそれぞれの側から発生するIOIがそうするかもしれません。
There is also expected to be access network charging information, which consists of network specific identifiers for the access level (e.g., UMTS radio access network or IEEE 802.11b). The details of the information for each type of network are not described in this memo.
また、アクセスネットワーク充電情報があると予想されます。(情報はアクセスのための特定の識別子が平らにするネットワーク(例えば、UMTSラジオのアクセスネットワークかIEEE 802.11b)から成ります)。 それぞれのタイプのネットワークのための情報の詳細はこのメモで説明されません。
We define the SIP private header P-Charging-Vector. A proxy MAY include this header, if not already present, in either the initial request or response for a dialog, or in the request and response of a standalone transaction outside a dialog. Only one instance of the header MUST be present in a particular request or response.
私たちはSIPの個人的なヘッダーP充電ベクトルを定義します。 プロキシは、このヘッダーを入れるか、またはどちらかに対話の外で既にスタンドアロン取引の対話か、要求と応答における初期の要求か応答を提示するかもしれません。 ヘッダーの1つの例だけが特定の要求か応答で存在していなければなりません。
The mechanisms by which a SIP proxy collects the values to populate in the P-Charging-Vector are outside the scope of this document.
このドキュメントの範囲の外にSIPプロキシがP充電ベクトルで居住する値を集めるメカニズムがあります。
4.6.1 Applicability Statement for the P-Charging-Vector header
4.6.1 P充電ベクトルヘッダーのための適用性Statement
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. UAは(例えば、INVITE)かプロキシとの対話の外におけるスタンドアロントランザクション要求が私設のネットワークの管理ドメインで場所を見つけたREGISTERか対話を開始する要求を送ります。
2. A registrar, proxy or UA that is located in the administrative
domain of the private network wants to generate charging records.
2. 記録係、プロキシまたは私設のネットワークの管理ドメインに位置しているUAが充電記録を発生させたがっています。
Garcia-Martin, et. al. Informational [Page 22] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[22ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
3. A proxy or UA that is located in the administrative domain of the
private network has access to the charging correlation information
for that network.
3. 私設のネットワークの管理ドメインに位置しているプロキシかUAがそのネットワークのための充電相関関係情報に近づく手段を持っています。
4. Optionally, a registrar, proxy or UA that is part of a second
administrative domain in another private network, whose SIP
request and responses are traversed through, en-route to the first
private network, wants to generate charging records and correlate
those records with those of the first private network. This
assumes that there is a trust relationship between both private
networks.
4. 任意に、記録係(最初の私設のネットワークへの途中で要求と応答がSIPで横断される別の私設のネットワークにおける2番目の管理ドメインの一部であるプロキシかUA)は、最初の私設のネットワークのもので充電記録を発生させて、それらの記録を関連させたがっています。 これは、両方の私設のネットワークの間には、信用関係があると仮定します。
4.6.2 Usage of the P-Charging-Vector header
4.6.2 P充電ベクトルヘッダーの使用法
The P-Charging-Vector header is used to convey charging related information, such as the globally unique IMS charging identifier (ICID) value.
P充電ベクトルヘッダーは、グローバルにユニークなIMS充電識別子(ICID)値などの充電の関連する情報を伝えるのに使用されます。
Typically, a SIP proxy that receives a SIP request that does not contain a P-Charging-Vector header may insert it, with those parameters that are available at the SIP proxy.
通常、P充電ベクトルヘッダーを含まないSIP要求を受け取るSIPプロキシはそれを挿入するかもしれません、それらのSIPプロキシで利用可能なパラメタで。
A SIP proxy that receives a SIP request that contains a P-Charging-Vector header may use the values, such as the globally unique ICID, to produce charging records.
P充電ベクトルヘッダーを含むSIP要求を受け取るSIPプロキシは、生産するのに記録を請求しながら、グローバルにユニークなICIDなどの値を使用するかもしれません。
4.6.2.1 Procedures at the UA
4.6.2.1 UAの手順
This document does not specify any procedure at the UA, with regard to the P-Charging-Vector header. UAs need not understand this header.
このドキュメントはP充電ベクトルヘッダーに関してUAのどんな手順も指定しません。 UAsはこのヘッダーを理解する必要はありません。
4.6.2.2 Procedures at the Proxy
4.6.2.2 プロキシにおける手順
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
この拡大を支持するプロキシがP充電ベクトルヘッダーと共に要求か応答を受け取るなら、それは、アプリケーションと共に特定の論理(すなわち、充電)を使用するためにヘッダー値からの情報を検索するかもしれません。 信じられたドメインの中にメッセージのための次のホップがあるなら、プロキシSHOULDはP充電ベクトルを含んでいます。
Garcia-Martin, et. al. Informational [Page 23] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[23ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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充電機能アドレスヘッダーを取り除くかもしれません。
Per local application specific logic, the proxy MAY modify the contents of the P-Charging-Vector header prior to sending the message.
局所塗布の特定の論理に従って、メッセージを送る前に、プロキシはP充電ベクトルヘッダーのコンテンツを変更するかもしれません。
4.6.2.3 Examples of Usage
4.6.2.3 用法に関する例
We present example in the context of the scenario presented in the following network diagram:
私たちは以下のネットワーク図で提示されたシナリオの文脈の例を提示します:
Scenario UA1 --- P1 --- P2 --- UA2
シナリオUA1--- P1--- P2--- UA2
This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case P1 also inserts charging information. P1 then routes the call via P2 to UA2.
この例は結局UA2に到着するUA1から発する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
F1Invite UA1->P1 INVITE一口: joe@example.com SIP/2.0Via: 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: 一口: joe@example.com From: 一口: ua1@home1.net;tag =456248Call-ID: 843817637684230998sdasdh09 CSeq: 18 接触を招いてください: 一口: ua1@192.0
F2 Invite P1 -> P2
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP P1.home1.net:5060;branch=z9hG4bK34ghi7a
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Vector: icid-value=1234bc9876e;
icid-generated-at=192.0.6.8;
orig-ioi=home1.net
F2はP1->P2 INVITE一口: joe@example.com SIP/2.0Viaを招待します: 一口/2.0/UDP P1.home1.net: 5060; ブランチは以下を通ってz9hG4bK34ghi7aと等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: 一口: joe@example.com From: 一口: ua1@home1.net;tag =456248Call-ID: 843817637684230998sdasdh09 CSeq: 18 接触を招いてください: 一口: ua1@192.0.2.4 P充電ベクトル: icid-値は1234bc9876eと等しいです。 icidが発生する、-、=192.0.6、.8。 orig-ioi=home1.net
Garcia-Martin, et. al. Informational [Page 24] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[24ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
5. Formal Syntax
5. 正式な構文
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.
本書では指定されたメカニズムのすべてが散文とRFC2234[3]で定義された増大しているバッカス記法(BNF)の両方で説明されます。 さらに、いくつかのBNF定義は、SIPから引き継がれて、ここで繰り返されません。 作成者は、このドキュメントを理解するのにSIP[1]とRFC2234[3]の記法とコンテンツによく知られる必要があります。
5.1 P-Associated-URI header syntax
5.1P関連URIヘッダー構文
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-uri-仕様)*(COMMA p-aso-uri-仕様)p-aso-uri-仕様=名前-addr*(SEMI ai-param)ai-paramはジェネリック-paramと等しいです。
5.2 P-Called-Party-ID header syntax
5.2Party IDと呼ばれるPヘッダー構文
The syntax of the P-Called-Party-ID header is described as follows:
Party IDと呼ばれるPヘッダーの構文は以下の通り説明されます:
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
「Party IDと呼ばれるP」HCOLON呼ばれたptyイド仕様呼ばれたptyイド仕様=名前-addr*(SEMI cpid-param)Party IDと呼ばれるP=cpid-paramはジェネリック-paramと等しいです。
5.3 P-Visited-Network-ID header syntax
PがネットワークIDを訪問している5.3ヘッダー構文
The syntax of the P-Visited-Network-ID header is described as follows:
Pがネットワーク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
5.4 P-Access-Network-Info header syntax
5.4Pアクセスネットワークインフォメーションヘッダー構文
The syntax of the P-Access-Network-Info header is described as follows:
Pアクセスネットワークインフォメーションヘッダーの構文は以下の通り説明されます:
P-Access-Network-Info = "P-Access-Network-Info" HCOLON
access-net-spec
access-net-spec = access-type *(SEMI access-info)
ネットの仕様にアクセスしている「Pアクセスネットワークインフォメーション」HCOLONネットの仕様にアクセスしている=Pアクセスネットワークインフォメーション=アクセス型*(SEMIアクセスインフォメーション)
Garcia-Martin, et. al. Informational [Page 25] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[25ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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)
拡大アクセス象徴アクセスアクセス型="IEEE-802.11a"/"IEEE-802.11b"/"3GPP-GERAN"/"3GPP-UTRAN-FDD"/"3GPP-UTRAN-TDD"/"3GPP-CDMA2000"/インフォメーション=管路気中送電3gpp / utranセルイド3gpp/インフォメーション拡大アクセスインフォメーション=「管路気中送電-3gpp」等しい(象徴/引用文字列)utranセルイド値に情報を得ている管路気中送電-3gpp=3gpp=「utranセルイド3gpp」同輩(象徴/引用文字列)
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].
アクセスインフォメーションはアクセスネットワークに関連する追加情報を含むかもしれません。 「管路気中送電-3gpp」と「utranセルイド3gpp」のための値は3GPP TS24.229[15]で定義されます。
5.5 P-Charging-Function-Addresses header syntax
5.5機能アドレスを請求するPヘッダー構文
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は"ecf"値に情報を得ているジェネリック-param ccf=ccf/ecf/"ccf"EQUAL「P充電機能アドレス」HCOLON料金-addr-params*(SEMI料金-addr-params)料金-addr-params=ecf=EQUALと値に情報を得て等しいです。
5.6 P-Charging-Vector header syntax
5.6P充電ベクトルヘッダー構文
The syntax for the P-Charging-Vector header is described as
follows:
P充電ベクトルヘッダーのための構文は以下の通り説明されます:
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value
*(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi /
term-ioi / generic-param
icid-value = "icid-value" EQUAL gen-value
icid-gen-addr = "icid-generated-at" EQUAL host
orig-ioi = "orig-ioi" EQUAL gen-value
term-ioi = "term-ioi" EQUAL gen-value
値に情報を得ているP充電ベクトル=「P充電ベクトル」HCOLON icid-値の*(SEMI料金-params)料金-params=icidにaddrに情報を得ている/一般的なparam icid用語orig-ioi/ioi/価値=「icid-値」EQUAL値に情報を得ているicidにaddrに情報を得ている=「icidに発生している」EQUALホストorig-ioi="orig-ioi"EQUAL用語-ioiは「用語-ioi」EQUALと値に情報を得て等しいです。
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-値は、IMS充電IDを表して、記録と出来事を請求しながら関連するのに使用される識別子を含んでいます。 第1代要求を受け取るプロキシはこの値を発生させます。
Garcia-Martin, et. al. Informational [Page 26] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[26ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
The icid-gen-addr parameter contains the host name or IP address of the proxy that generated the icid-value.
icidが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はセッションかスタンドアロン要求の終わり部分での充電記録に責任があるネットワークを代表します。
5.7 Table of new headers
5.7 新しいヘッダーのテーブル
Table 1 extends the headers defined in this document to Table 2 in SIP [1], section 7.1 of the SIP-specific event notification [6], tables 1 and 2 in the SIP INFO method [8], tables 1 and 2 in Reliability of provisional responses in SIP [7], tables 1 and 2 in the SIP UPDATE method [9], tables 1 and 2 in the SIP extension for Instant Messaging [10], and table 1 in the SIP REFER method [11]:
テーブル1はSIP[1]で本書ではTable2と定義されたヘッダー、SIP特有のイベント通知[6]のセクション7.1、SIP INFO方法[8]によるテーブル1と2、SIP[7]の暫定的な応答のReliabilityのテーブル1と2、SIP UPDATE方法[9]によるテーブル1と2、Instant Messaging[10]のためのSIP拡張子でのテーブル1と2、およびSIP REFER方法[11]によるテーブル1を広げています:
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
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG___________________________________________________________ P関連URI2xx----------o Party IDと呼ばれるP R amr------o o(PがネットワークIDを訪問しているR広告)----o o o Pアクセスネットワークインフォメーションdr--o--o o o P充電ベクトルadmr--o--o o o Pを請求する機能-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
ヘッダーフィールドSUB NOT PRA INF UPD MSG REF___________________________________________________________ P関連URI--------------Party IDと呼ばれるP o--------o o P訪問されたネットワークID o--、--、--、--、o o Pアクセスネットワークインフォメーションo o o o o o o P充電ベクトルo o o o o o o Pを請求する機能o o o o o o o Addresses
Table 1: Header field support
テーブル1: ヘッダーフィールドサポート
Garcia-Martin, et. al. Informational [Page 27] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[27ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
6. Security Considerations
6. セキュリティ問題
6.1 P-Associated-URI
6.1 P関連URI
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.
終わらせる終わりかホップのどちらかごとの暗号化の不足は、認可されたアイデンティティのリストに関して何らかのプライバシーを漏らすのを導くかもしれません。 例えば、一口の記録されている住所を登録するユーザ: user1@example.com は一口として別のSIP URIを関連づけさせるかもしれません: P関連URIヘッダー価値で返された first.last@example.com 。 立ち聞きする者はこの情報を集めることができました。 ユーザが関連URIを明らかにしたくないなら、立ち聞きする者は個人的なURIに利得アクセスを持っているかもしれません。 したがって、この拡張子が安全にされた環境かホップごとに使用されるのは、RECOMMENDEDです。そこでは、SIPメッセージの暗号化がどちらの終わりから終わりにも提供されます。
6.2 P-Called-Party-ID
6.2 Party IDと呼ばれるP
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.
Party IDと呼ばれるPヘッダーの自然のため、このヘッダーは少しの重要なセキュリティ関心も導入しません。 攻撃者がヘッダーのコンテンツを変更するのは、可能です。 しかしながら、この変更はセッション設立に少しの害も引き起こさないでしょう。
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.
立ち聞きする者は登録されたアイデンティティaユーザのリストを集めるかもしれません。 これには、プライバシー意味があるかもしれません。 この拡大SHOULDは、この問題を緩和するために、安全にされた環境で使用されるだけであるか、またはホップで跳ぶだけです。(そこでは、SIPメッセージの暗号化がどちらの終わりから終わりにも提供されます)。
6.3 P-Visited-Network-ID
6.3 PはネットワークIDを訪問しました。
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がネットワークIDを訪問しているヘッダーは、ホームネットワークと1との信用関係かさらに通過している訪問されたネットワークがあると仮定します。 他のプロキシに、それは、PがネットワークIDを訪問しているヘッダーの値を変更するためにヘッダーを挿入する訪問されたネットワークのプロキシと、記録係か家のプロキシの間で可能です。 したがって、このメカニズムに参加する仲介者がホップごとのIPsecかもう一方都合が良い保全保護メカニズムそのような私たちを適用しなければならない、メカニズム、そのような攻撃を防いでください。
Garcia-Martin, et. al. Informational [Page 28] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[28ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
6.4 P-Access-Network-Info
6.4 Pアクセスネットワークインフォメーション
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].
Trust DomainはNetwork Asserted Identity[13]のための要件が記録するShort用語で正式に定義されます。 3GPPネットワーク・オペレータによって運転された、要件で対応であるSIPプロキシとアプリケーション・サーバーの収集が3GPP TSで24.229[15]を言い表したので、このドキュメントの目的について、私たちは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.
提供する追加サービスを提供するのにユーザに対するサービスを提供して、このヘッダーに含まれた情報を利用するプロキシとUAsが予想されるSIPは情報を修正します。 しかしながら、不正確な情報を挿入するUAから生じることにおける警備上の問題が全くありません。 したがって、情報に基づくサービスがPアクセスネットワークインフォメーションヘッダーで提供されたなら、ネットワークは、情報を送るUAを信じる必要があるでしょう。 凶暴なUA送付誤ったアクセスネットワーク情報はあるサービスを利用するのでユーザを制限するより多くの害を加えないでしょう。
The mechanism provided in this document is designed primarily for private systems like 3GPP. Most security requirements are met by way of private standardized solutions.
本書では提供されたメカニズムは主として3GPPのような個人的なシステムのために設計されています。 ほとんどのセキュリティ必要条件が個人的な標準液を通して満たされます。
For instance, 3GPP will use the P-Access-Network-Info header to carry relatively sensitive information like the cell ID. Therefore the information MUST NOT be sent outside of the 3GPP domain.
例えば、3GPPは、セルIDのように比較的機密の情報を運ぶのにPアクセスネットワークインフォメーションヘッダーを使用するでしょう。 したがって、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アクセスネットワークインフォメーションヘッダーSHOULD NOTで運ばれたように、あらゆる初期の非認証されて保護のない要求(例えば、REGISTER)で送ってください。
Any UA that is using this extension and is not part of a private trusted domain should not consider the mechanism as secure and as such SHOULD NOT send sensitive information in the P-Access-Network-Info header.
この拡張子を使用していて、個人的な信じられたドメインの一部でないどんなUAも、メカニズムが安全であるとみなすはずがありません、そして、そういうものとして、SHOULD NOTはPアクセスネットワークインフォメーションヘッダーで機密情報を送ります。
Garcia-Martin, et. al. Informational [Page 29] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[29ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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アクセスネットワークインフォメーションヘッダーが支えられる個人信託ドメインで働いているプロキシがヘッダーを削除するのに必要です、それが存在しているなら、信じられたドメインの外にそれを送る前のどんなメッセージからも。
Therefore, a network that requires its UA to send information in the P-Access-Network-Info header must ensure that either that information is not of a sensitive nature or that the information is not sent outside of the trust domain.
したがって、UAがPアクセスネットワークインフォメーションヘッダーで情報を送るのを必要とするネットワークは、情報が敏感な本質のものでない情報が信用ドメインの外に送られないのを確実にそんなにのどちらかでなければなりません。
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アクセスネットワークインフォメーションヘッダーを含むメッセージを受け取るプロキシはコンテンツの正当性を保証できません。
6.5 P-Charging-Function-Addresses
6.5 P充電機能アドレス
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充電機能アドレスヘッダーで値を見るか、または変更する必要であるかもしれないと信じたので、保護はホップごとのベースで適用されるべきです。
6.6 P-Charging-Vector
6.6 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充電ベクトルヘッダーで値を見るか、または変更する必要であるかもしれないと信じたので、保護はホップごとのベースで適用されるべきです。
7. IANA Considerations
7. IANA問題
This document defines several private SIP extension header fields (beginning with the prefix "P-" ).
このドキュメントはいくつかの個人的なSIP拡大ヘッダーフィールドを定義します(接頭語「P」で始まって)。
Garcia-Martin, et. al. Informational [Page 30] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[30ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
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[1]で定義されたSIPヘッダーフィールドの登録に含まれています。 専門家は過程がSIP作業部会によって提供されたこれのために必要に応じて論評します。
The following extensions are registered as private extension header fields:
以下の拡大は個人的な拡大ヘッダーフィールドとして示されます:
RFC Number: RFC3455 Header Field Name: P-Associated-URI Compact Form: none
RFC番号: RFC3455ヘッダーフィールド名: P関連URIコンパクト形: なし
RFC Number: RFC3455 Header Field Name: P-Called-Party-ID Compact Form: none
RFC番号: RFC3455ヘッダーフィールド名: Party IDと呼ばれるPコンパクト形: なし
RFC Number: RFC3455 Header Field Name: P-Visited-Network-ID Compact Form: none
RFC番号: RFC3455ヘッダーフィールド名: PがネットワークIDを訪問しているコンパクト形: なし
RFC Number: RFC3455 Header Field Name: P-Access-Network-Info Compact Form: none
RFC番号: RFC3455ヘッダーフィールド名: Pアクセスネットワークインフォメーションコンパクト形: なし
RFC Number: RFC3455 Header Field Name: P-Charging-Function-Addresses Compact Form: none
RFC番号: RFC3455ヘッダーフィールド名: P充電機能アドレスコンパクト形: なし
RFC Number: RFC3455 Header Field Name: P-Charging-Vector Compact Form: none
RFC番号: RFC3455ヘッダーフィールド名: P充電ベクトルコンパクト形: なし
8. Contributors
8. 貢献者
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、Party IDと呼ばれるP、およびPがネットワークIDを訪問しているヘッダーを書きました。 ダンカン・ミルズはPアクセスネットワークインフォメーションヘッダーを書きました。 エリックHenriksonはP充電機能アドレスとP充電ベクトルヘッダーを書きました。 Rohanマーイはこれらの拡大の編入をただ一つのドキュメントに助けました。
Garcia-Martin, et. al. Informational [Page 31] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[31ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
9. Acknowledgments
9. 承認
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、ゴンサロ・キャマリロ、キースDrage、ゲオルク・マイヤー、ディーン・ウィリス、Rohanマーイ、ジョナサン・ローゼンバーグ、Ya-チンTan、および3GPP CN1 WGメンバーに感謝したがっています。
10. Normative References
10. 引用規格
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
11. Informative References
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世代Partnership Project(3GPP)はSession Initiationプロトコル(SIP)で5つの要件をリリースする」ProgressのWork。
[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.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、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、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[8] ドノヴァン、S.、「一口インフォメーション方法」、RFC2976、2000年10月。
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[9] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、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、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[11] Sparks, R., "The SIP Refer Method", Work in Progress.
[11] R.、「一口は方法を参照する」というスパークが進行中で働いています。
Garcia-Martin, et. al. Informational [Page 32] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[32ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
[12] Barnes, M., "SIP Generic Request History Capability
Requirements", Work in Progress.
[12] バーンズ、M.、「一口の一般的な要求歴史信用要求事項」が進行中で働いています。
[13] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
[13] ワトソン、M.、「ネットワークの断言されたアイデンティティのための短期間要件」、RFC3324、2002年11月。
[14] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2
(Release 5)", 3GPP 23.228, September 2002, <ftp://ftp.3gpp.org/
Specs/archive/23_series/23.228/>.
[14] 3GPP、「t23.228:」 IPマルチメディアサブシステム(IMS)。 「ステージ2(リリース5)」、3GPP23.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、「t24.229:」 SIPとSDPに基づくIP Multimedia Call Controlプロトコル。 「ステージ3(リリース5)」、3GPP24.229、2002年9月、<ftp://ftp.3gpp.org/仕様/アーカイブ/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、「t32.200:」 電気通信管理。 管理を請求します。 「充電原則(リリース5)」、3GPP32.200、2002年6月、<ftp://ftp.3gpp.org/仕様/アーカイブ/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、「t32.225:」 電気通信管理。 管理を請求します。 「IPマルチメディアサブシステム(リリース5)のための課金データ記述」、3GPP32.225、2002年9月、<ftp://ftp.3gpp.org/仕様/アーカイブ/32_series/32.225/>。
Authors' Addresses
作者のアドレス
Miguel A. Garcia-Martin Ericsson Hirsalantie 11 Jorvas FIN-02420 Finland EMail: miguel.a.garcia@ericsson.com
ミゲルA.ガルシア-マーチンエリクソンHirsalantie11Jorvasフィン-02420フィンランドメール: miguel.a.garcia@ericsson.com
Eric Henrikson Lucent 11601 Willows Rd, Suite 100 Redmond, WA 98052 USA EMail: ehenrikson@lucent.com
エリックHenrikson透明な11601柳、Suite100ワシントン98052レッドモンド(米国)は以下を第メールします。 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イギリスはメールされます: duncan.mills@vf.vodafone.co.uk
Garcia-Martin, et. al. Informational [Page 33] RFC 3455 3GPP SIP P-Header Extensions January 2003
etガルシア-マーチン、アル。 情報[33ページ]のRFC3455 3GPPはP-ヘッダー拡大2003年1月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Garcia-Martin, et. al. Informational [Page 34]
etガルシア-マーチン、アル。 情報[34ページ]
一覧
スポンサーリンク
