RFC3327 日本語訳
3327 Session Initiation Protocol (SIP) Extension Header Field forRegistering Non-Adjacent Contacts. D. Willis, B. Hoeneisen. December 2002. (Format: TXT=36493 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Willis
Request for Comments: 3327 dynamicsoft Inc.
Category: Standards Track B. Hoeneisen
Switch
December 2002
コメントを求めるワーキンググループD.ウィリス要求をネットワークでつないでください: 3327dynamicsoft株式会社Category: 標準化過程B.Hoeneisenスイッチ2002年12月
Session Initiation Protocol (SIP) Extension Header Field
for Registering Non-Adjacent Contacts
非隣接している接触を登録するためのセッション開始プロトコル(一口)拡大ヘッダーフィールド
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism.
REGISTER機能は、主として一時的な連絡先を記録されている住所に関連づけるのにSession Initiationプロトコル(SIP)システムで使用されます。 この接触は一般にContactなどのUniform Resource Identifier(URI)の形にあります: そして、<一口: alice@pc33.atlanta.com 、gt;、一般に、ダイナミックであり、SIP UserエージェントのIPアドレスかホスト名に関連づけられます(UA)。 問題はUAと記録係の間には、ネットワーク形態に1つ以上のSIPプロキシがあるかもしれないということです、ユーザのホームネットワークから登録されたUAまで移動するどんな要求もこれらのプロキシを横断しなければならないように。 REGISTER方法は、今後の使用のために記録係のプロキシのこの系列を発見して、記録するためにメカニズムを私たちに与えません。 このドキュメントは拡張ヘッダー分野、そのようなメカニズムを提供する「経路」を定義します。
Willis & Hoeneisen Standards Track [Page 1] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[1ページ]。
Table of Contents
目次
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . 3
4. Path Header Field Definition and Syntax . . . . . . . . . . 3
5. Usage of Path Header Field . . . . . . . . . . . . . . . . . 5
5.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . 5
5.2 Procedures at Intermediate Proxies . . . . . . . . . . . . . 5
5.3 Procedures at the Registrar . . . . . . . . . . . . . . . . 6
5.4 Procedures at the Home Proxy . . . . . . . . . . . . . . . . 6
5.5 Examples of Usage . . . . . . . . . . . . . . . . . . . . . 7
5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . . 7
5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . 13
6.1 Considerations in REGISTER Request Processing . . . . . . . 13
6.2 Considerations in REGISTER Response Processing . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 16
Non-Normative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
1. バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 適用性証明. . . . . . . . . . . . . . . . . . 3 4。 経路ヘッダーフィールド定義と構文. . . . . . . . . . 3 5。 UAのヘッダーフィールド.55.1の経路手順の用法、中間的プロキシにおける.55.2の手順、記録係. . . . . . . . . . . . . . . . 6 5における.55.3の手順; メカニズムに関するレジスタ取引.75.5.2の例のメカニズムに関する用法.75.5.1の例に関するプロキシ.65.5のホーム例における4つの手順が中で取引. . . . . . . . . 11 6を招待します。 レジスタのセキュリティ問題. . . . . . . . . . . . . . . . . . 13 6.1問題はレジスタ応答処理. . . . . . . 14 7における処理.136.2の問題を要求します。 IANA問題. . . . . . . . . . . . . . . . . . . . 15 8。 作者の.16のものが記述する非引用規格の承認. . . . . . . . . . . . . . . . . . . . . . 15の引用規格. . . . . . . . . . . . . . . . . . . . 16の.16の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 17
1. Background
1. バックグラウンド
3GPP established a requirement for discovering intermediate proxies during SIP registration and published this requirement in [5].
3GPPはSIP登録の間、中間的プロキシを発見するために要件を確立して、[5]でこの要件を発表しました。
Scenario:
シナリオ:
UA1----P1-----P2-----P3------REGISTRAR
UA1----P1-----P2-----P3------記録係
UA1 wishes to register with REGISTRAR. However, due to network topology, UA1 must use P1 as an "outbound proxy", and all requests between UA1 and REGISTRAR must also traverse P1, P2, and P3 before reaching REGISTRAR. Likewise, all requests between REGISTRAR and UA1 must also traverse P3, P2, and P1 before reaching UA1.
UA1はREGISTRARとともに記名したがっています。 しかしながら、ネットワーク形態のため、UA1は「外国行きのプロキシ」としてP1を使用しなければなりません、そして、また、REGISTRARに達する前に、UA1とREGISTRARの間のすべての要求がP1、P2、およびP3を横断しなければなりません。 また、同様に、UA1に達する前に、REGISTRARとUA1の間のすべての要求がP3、P2、およびP1を横断しなければなりません。
UA1 has a standing relationship with REGISTRAR. How UA1 establishes this relationship is outside the scope of this document. UA1 discovers P1 as a result of configuration, DHCP assignment or other similar operation, also outside the scope of this document. REGISTRAR has a similar "default outbound proxy" relationship with P3.
UA1には、REGISTRARとの地位の関係があります。 このドキュメントの範囲の外にUA1がどうこの関係を確立するかがあります。 UA1は構成、DHCP課題または他の同様の操作の結果、P1を発見します、このドキュメントの範囲の外でも。 REGISTRARには、P3との同様の「デフォルトの外国行きのプロキシ」関係があります。
Willis & Hoeneisen Standards Track [Page 2] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[2ページ]。
Eventually, REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) closely related to it will receive a request destined for UA1. It needs to know which proxies must be transited by that request in order to get back to UA1. In some cases, this information may be deducible from SIP routing configuration tables or from DNS entries. In other cases, such as that raised by 3GPP, the information is not readily available outside of the SIP REGISTER transaction.
結局、REGISTRARか密接にそれに関連する「家のプロキシ」(記録されている住所を発送するための端末のポイントとして勤めているプロキシ)がUA1のために運命づけられた要求を受け取るでしょう。 それは、UA1に戻るためにその要求でどのプロキシを通過しなければならないかを知る必要があります。 いくつかの場合、この情報はSIPルーティング設定テーブルかDNSエントリーので推定可能であるかもしれません。 3GPPによって上げられたそれなどの他の場合では、情報は外でSIP REGISTER取引で容易に入手できません。
The Path extension header field allows accumulating and transmitting the list of proxies between UA1 and REGISTRAR. Intermediate nodes such as P1 may statefully retain Path information if needed by operational policy. This mechanism is in many ways similar to the operation of Record-Route in dialog-initiating requests. The routing established by the Path header field mechanism applies only to requests transiting or originating in the home domain.
Path拡大ヘッダーフィールドで、UA1とREGISTRARの間にプロキシのリストを蓄積して、伝えます。 運用政策が必要であるなら、P1などの中間的ノードはstatefullyにPath情報を保有するかもしれません。 このメカニズムは対話を開始する要求における、Record-ルートの操作と同様の多くの方法であります。 Pathヘッダーフィールドメカニズムによって確立されたルーティングは家のドメインで通過するか、または起こる要求だけに適用されます。
2. Terminology
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 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[3])で説明されるように本書では解釈されることであるべきです。
3. Applicability Statement
3. 適用性証明
The Path mechanism is applicable whenever there are intermediate proxies between a SIP UA and a SIP Registrar used by that UA where the following conditions are true:
以下の条件が本当であるそのUAによって使用されたSIP UAとSIP Registrarの間には、中間的プロキシがあるときはいつも、Pathメカニズムは適切です:
1. One or more of the intermediate proxies are visited by
registration requests from the UA to the Registrar.
2. The same intermediate proxies or a set of proxies known to the
intermediate proxies must be traversed, in reverse order, by
requests sent through a home proxy to the UA. In the simplest
form, the route between the home proxy and the UA is the exact
inverse of the route between the UA and the route between the UA
and the registrar.
3. The network topology is such that the intermediate proxies which
must be visited are NOT implied by SIP routing tables, DNS, or
similar mechanisms.
1. 1か中間的プロキシの以上がUAからRegistrarまでの登録要求で訪問されます。 2. 中間的プロキシにおいて知られているプロキシの同じ中間的プロキシかセットを横断しなければなりません、逆順で、家のプロキシを通してUAに送られた要求で。 最も簡単なフォームでは、家のプロキシとUAの間のルートはUAと記録係の間のUAとルートの間のルートの正確な逆です。 3. ネットワーク形態がそのようなものであるので、訪問しなければならない中間的プロキシはSIP経路指定テーブル、DNS、または同様のメカニズムによって含意されません。
4. Path Header Field Definition and Syntax
4. 経路ヘッダーフィールド定義と構文
The Path header field is a SIP extension header field with syntax very similar to the Record-Route header field. It is used in conjunction with SIP REGISTER requests and with 200 class messages in response to REGISTER (REGISTER responses).
PathヘッダーフィールドはRecord-ルートヘッダーフィールドと非常に同様の構文があるSIP拡大ヘッダーフィールドです。 それはSIP REGISTER要求に関連したREGISTER(REGISTER応答)に対応した200のクラスメッセージと共に使用されます。
Willis & Hoeneisen Standards Track [Page 3] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[3ページ]。
A Path header field MAY be inserted into a REGISTER by any SIP node traversed by that request. Like the Route header field, sequential Path header fields are evaluated in the sequence in which they are present in the request, and Path header fields MAY be combined into compound Path header in a single Path header field. The registrar reflects the accumulated Path back into the REGISTER response, and intermediate nodes propagate this back toward the originating UA. The originating UA is therefore informed of the inclusion of nodes on its registered Path, and MAY use that information in other capacities outside the scope of this document.
Pathヘッダーフィールドはその要求で横断されたどんなSIPノードによってもREGISTERに挿入されるかもしれません。 Routeヘッダーフィールドのように、連続したPathヘッダーフィールドはそれらが要求で現在である系列で評価されます、そして、Pathヘッダーフィールドはただ一つのPathヘッダーフィールドで合成Pathヘッダーに結合されるかもしれません。 記録係は蓄積されたPathをREGISTER応答に映し出します、そして、中間的ノードは由来しているUAに向かってこの後部を伝播します。 由来しているUAはしたがって、登録されたPathにおけるノードの包含において知識があって、このドキュメントの範囲の外で他の立場にその情報を使用するかもしれません。
The difference between Path and Record-Route is that Path applies to REGISTER and 200 class responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatibility. Furthermore, the vector established by Record-Route applies only to requests within the dialog that established that Record-Route, whereas the vector established by Path applies to future dialogs.
PathとRecord-ルートの違いはPathがREGISTERとREGISTERへの200のクラス応答に適用するということです。 記録的なルートは定義しません、そして、後方の互換性の理由で、REGISTERで定義できません。 その上、Record-ルートで確立されたベクトルはそのRecord-ルートを確立した対話の中で要求だけに適用されますが、Pathによって確立されたベクトルは今後の対話に適用されます。
The syntax for Path is defined as follows:
Pathのための構文は以下の通り定義されます:
Path = "Path" HCOLON path-value *( COMMA path-value )
経路=「経路」HCOLON経路価値*(COMMA経路価値)
path-value = name-addr *( SEMI rr-param )
経路値は名前-addr*と等しいです。(SEMI rr-param)
Note that the Path header field values conform to the syntax of a Route element as defined in [1]. As suggested therein, such values MUST include the loose-routing indicator parameter ";lr" for full compliance with [1].
Pathヘッダーフィールド値が[1]で定義されるようにRoute要素の構文に従うことに注意してください。 「そこに示されるように、そのような値はゆるいルーティングインディケータパラメタを含まなければならない」; lrする、」 [1]への完全な承諾ために。
The allowable usage of header fields is described in Tables 2 and 3 of SIP [1]. The following additions to this table are needed for Path.
ヘッダーフィールドの許容できる用法はSIP[1]のTables2と3で説明されます。 このテーブルへの以下の追加がPathに必要です。
Support for the Path header field MAY be indicated by a UA by including the option-tag "path" in a Supported header field.
Pathヘッダーフィールドのサポートは、Supportedヘッダーフィールドにオプションタグ「経路」を含んでいることによって、UAによって示されるかもしれません。
Addition of Path to SIP Table 3:
テーブル3をちびちび飲む経路の添加:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Path R ar - - - - - o
Path 2xx - - - - - - o
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG___________________________________________________________ 経路R ar----------o Path 2xx--、--、--、--、--、--、o
Willis & Hoeneisen Standards Track [Page 4] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[4ページ]。
5. Usage of Path Header Field
5. 経路ヘッダーフィールドの用法
5.1 Procedures at the UA
UAの5.1の手順
The UA executes its register operation as usual. The response MAY contain a Path header field. The general operation of the UA is to ignore the Path header field in the response. It MAY choose to display the contents of the Path header field to the user or take other action outside the scope of this document. The Path information in the REGISTER response lets the UA know what intermediate proxies were added during registration. Examination of this information may be important from a security perspective, as such inspection might allow the UA to detect intermediate proxies that have inappropriately added themselves.
UAは通常通りのレジスタ操作を実行します。 応答はPathヘッダーフィールドを含むかもしれません。 UAの一般的な操作は応答におけるPathヘッダーフィールドを無視することです。 それは、Pathヘッダーフィールドのコンテンツをユーザに表示するか、またはこのドキュメントの範囲の外に他の行動を取るのを選ぶかもしれません。 REGISTER応答におけるPath情報は、どんな中間的プロキシが登録の間、加えられたかをUAに知らせます。 この情報の調査はセキュリティ見解から重要であるかもしれません、UAがそのような点検で不適当に自分たちを加えた中間的プロキシを検出できるかもしれないとき。
The UA SHOULD include the option tag "path" as a header field value in all Supported header fields, and SHOULD include a Supported header field in all requests.
UA SHOULDはヘッダーフィールド値としてすべてのSupportedヘッダーフィールドにオプションタグ「経路」を含んでいます、そして、SHOULDはすべての要求にSupportedヘッダーフィールドを含んでいます。
The UA MAY include a Path header field in a request. This is not broadly applicable and caution must be taken to insure proper function, as the Path header field inserted by the UA may have additional Path header field values appended by intermediate proxies. Such proxies are not aware that the Path header field value was inserted by a UA, and will treat it as if it had been inserted by a previously traversed proxy, which could result in unexpected routing behavior wherein the UA is asked to act as a proxy.
UA MAYは要求にPathヘッダーフィールドを含んでいます。 これは広く適切ではありません、そして、適切な機能を保障するために警告を取らなければなりません、中間的プロキシがUAによって挿入されたPathヘッダーフィールドで追加Pathヘッダーフィールド値を追加するとき。 まるでそれが以前に横断されたプロキシ(UAがプロキシとして務めるように頼まれる予期していなかったルーティングの振舞いをもたらすことができた)によって挿入されたかのようにそのようなプロキシはPathヘッダーフィールド価値がUAによって挿入されて、それを扱うのを意識していません。
5.2 Procedures at Intermediate Proxies
中間的プロキシにおける5.2の手順
When a proxy processing a REGISTER request wishes to be on the path for future requests toward the UA originating that REGISTER request, the proxy inserts a URI for that proxy as the topmost value in the Path header field (or inserts a new topmost Path header) before proxying that request. It is also possible for a proxy with specific knowledge of network topology to add a Path header field value referencing another node, thereby allowing construction of a Path which is discongruent with the route taken by the REGISTER request. Such a construction is implementation specific and outside the scope of this document.
REGISTER要求を処理するプロキシが今後の要求のための経路でREGISTERが要求するUA由来に向かいたがっているとき、その要求をproxyingする前に、プロキシはそのプロキシのために最上の値としてPathヘッダーフィールド(または、新しい最上のPathヘッダーを挿入する)にURIを挿入します。 また、ネットワーク形態に関する特定の知識があるプロキシが別のノードに参照をつけるPathヘッダーフィールド価値を高めるのも、可能です、その結果、REGISTER要求でルートを取っているdiscongruentであるPathの構造を許容します。 実現特有であり、このドキュメントの範囲の外でそのような工事。
Intermediate proxies SHOULD NOT add a Path header field to a request unless the UA has indicated support for this extension with a Supported header field value. If the UA has indicated support and the proxy requires the registrar to support the Path extension, then the proxy SHOULD insert a Requires header field value for this extension. If the UA has not indicated support for the extension and the proxy requires support for it in the registrar, the proxy SHOULD
UAがSupportedヘッダーフィールド価値でこの拡大のサポートを示していない場合、中間的プロキシSHOULD NOTはPathヘッダーフィールドを要求に追加します。 UAが、サポートとプロキシが、記録係がPath拡張子をサポートするのを必要とするのを示したなら、プロキシSHOULDはこの拡大のためにRequiresヘッダーフィールド価値を挿入します。 UAが、拡大とプロキシのサポートが必要であることを示していないなら、それには、記録係、プロキシでSHOULDを支持してください。
Willis & Hoeneisen Standards Track [Page 5] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[5ページ]。
reject the request with a 421 response indicating a requirement for the extension.
421応答が拡大のための要件を示している要求を拒絶してください。
Proxies processing a REGISTER response SHOULD NOT alter any Path header field values that may be present in the response. The registrar MAY protect the Path header field in the response by including it in a protected S/MIME body, and alterations of the Path by an intermediate proxy can therefore be detected by the UA as man- in-the-middle attacks. Proxies SHOULD only consider altering the value of a Path header field in the REGISTER response if they have the credentials to correctly alter the S/MIME body to account for the change.
REGISTER応答SHOULD NOTを処理するプロキシがどんな応答で存在するかもしれないPathヘッダーフィールド値も変更します。 記録係は保護されたS/MIME本体にそれを含んでいることによって、応答におけるPathヘッダーフィールドを保護するかもしれません、そして、したがって、UAは中央での男性攻撃として中間的プロキシによるPathの変更を検出できます。 プロキシSHOULDは、変化の原因になるように正しくS/MIME本体を変更するために彼らに信任状があるならREGISTER応答における、Pathヘッダーフィールドの値を変更すると考えるだけです。
5.3 Procedures at the Registrar
記録係における5.3の手順
If a Path header field exists in a successful REGISTER request, the registrar constructs an ordered list of route elements (a path vector) from the nodes listed in the Path header field values, preserving the order as indicated in the Path header field values. The registrar then stores this path vector in association with that contact and the address-of-record indicated in the REGISTER request (the "binding" as defined in [1]). The registrar copies the Path header field values into a Path header field in the successful (200 class) REGISTER response. In the event that the home proxy and registrar are not co-located, the registrar MAY apply a locally- determined transformation to the stored path vector.
PathヘッダーフィールドがうまくいっているREGISTER要求に存在しているなら、記録係はPathヘッダーフィールド値でリストアップされたノードからルート要素(経路ベクトル)の規則正しいリストを構成します、Pathヘッダーフィールド値にみられるようにオーダーを保存して。 記録係は次に、その接触とREGISTER要求で示された記録されている住所と関連してこの経路ベクトルを格納します。(「拘束力がある」[1])で定義される。 記録係はうまくいっている(200のクラス)REGISTER応答におけるPathヘッダーフィールドにPathヘッダーフィールド値をコピーします。 家のプロキシと記録係が共同見つけられていない場合、記録係は局所的に決定している変化を格納された経路ベクトルに適用するかもしれません。
If a registrar receives a REGISTER request containing a Path header field and there is no indication of support for the extension in the UA (via a Supported header field), the registrar must rely on local policy in determining how to treat this request. The recommended policy is for the registrar to reject the request with a 420 "Bad Extension" response indicating the Path extension. This approach allows the UA to detect that an intermediate proxy has inappropriately added a Path header field. However, the Path mechanism should technically work in the absence of UA support (at some compromise to security), so some registrars MAY choose to support the extension in the absence of a Supported header field value in the request.
記録係がPathヘッダーフィールドを含むREGISTER要求を受け取って、拡大のサポートのしるしが全くUA(Supportedヘッダーフィールドを通した)になければ、記録係はこの要求を扱う方法を決定する際にローカルの方針を当てにしなければなりません。 お勧めの方針は記録係が420「悪い拡大」応答がPath拡張子を示している要求を拒絶することです。 UAはこのアプローチでそれを検出できます。中間的プロキシは不適当にPathヘッダーフィールドを言い足しました。 しかしながら、PathメカニズムがUAサポート(セキュリティとの何らかの妥協における)がないとき技術的に動作するはずであるので、何人かの記録係が、要求におけるSupportedヘッダーフィールド価値がないとき拡大を支持するのを選ぶかもしれません。
5.4 Procedures at the Home Proxy
ホームプロキシにおける5.4の手順
In the common SIP model, there is a home proxy associated with the registrar for a user. Each incoming request targeted to the public address-of-record for the user is routed to this proxy, which consults the registrar's database in order to determine the contact to which the request should be retargeted. The home proxy, in its basic mode of operation, rewrites the request-URI from the incoming
一般的なSIPモデルには、ユーザのために記録係に関連づけられた家のプロキシがあります。 ユーザのために記録の公共のアドレスに狙うそれぞれの入って来る要求はこのプロキシに発送されます。(プロキシは、要求が「再-狙」うべきである接触を決定するために記録係のデータベースに相談します)。 操作の基本のモードで、家のプロキシは入来から要求URIを書き直します。
Willis & Hoeneisen Standards Track [Page 6] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[6ページ]。
request with the value of the registered contact and retransmits the request.
登録の値がある要求は、要求に連絡して、再送します。
With the addition of Path, the home proxy also copies the stored path vector associated with the specific contact in the registrar database into the Route header field of the outgoing request as a preloaded route. This causes the outgoing request to transit the proxies that were included in the Path header field of the REGISTER request.
また、Pathの添加で、家のプロキシはプレロードされたルートとして記録係データベースにおける特定の接触に関連している格納された経路ベクトルを送信する要求のRouteヘッダーフィールドにコピーします。 これはトランジットへのREGISTER要求のPathヘッダーフィールドに含まれていたプロキシを送信する要求に引き起こします。
In normal processing, the home proxy is the "terminal point" for the user's address-of-record (AOR). Consequentially, the Route header field on the incoming request will have been exhausted in reaching the home proxy. If it isn't, then things get interesting. In the most common case, the home proxy generates the outgoing Route header field by inserting the stored path vector ahead of the Route header field values contained in the incoming request. This procedure may be altered by a local policy at the home proxy.
正常処理では、家のプロキシはユーザの記録されている住所(AOR)のための「端末のポイント」です。 結果的に、入って来る要求のRouteヘッダーフィールドは家のプロキシに届く際に消耗してしまうでしょう。 それがないなら、いろいろなことはおもしろくなります。 最も一般的な場合では、家のプロキシは、入って来る要求に含まれたRouteヘッダーフィールド値の前に格納された経路ベクトルを挿入することによって、外向的なRouteヘッダーフィールドを発生させます。 この手順は家のプロキシのローカルの方針で変更されるかもしれません。
Loose routes may interact with routing policy in interesting ways. The specifics of how the stored path vector integrates with any locally required default route and local policy are implementation dependent. For example, some devices will use locally-configured explicit loose routing to reach a next-hop proxy, and others will use a default outbound-proxy routing rule. However, for the result to function, the combination must provide valid routing in the local environment. In general, the stored path vector is appended to any locally configured route needed to egress the service cluster. The service proxy (or registrar, as noted earlier) MAY also transform the stored path vector as needed to provide correct functionality. Systems designers must match the Path recording policy of their nodes with the routing policy in order to get a workable system.
ゆるいルートはおもしろい方法でルーティング方針と対話するかもしれません。 格納された経路ベクトルがどうどんな局所的に必要なデフォルトルートとローカルの方針とも統合されるかに関する詳細は実現に依存しています。 例えば、いくつかの装置が次のホッププロキシに届くのに局所的に構成された明白なゆるいルーティングを使用するでしょう、そして、他のものはデフォルト外国行きのプロキシルーティング規則を使用するでしょう。 しかしながら、結果が機能するように、組み合わせは有効なルーティングを地方の環境に提供しなければなりません。 一般に、サービスが群生させる出口に必要であるどんな局所的に構成されたルートにも格納された経路ベクトルを追加します。 また、サービスプロキシ(または、より早く同じくらい有名な記録係)は、正しい機能性を提供するために必要に応じて格納された経路ベクトルを変えるかもしれません。 システム設計者は、実行可能なシステムを手に入れるために彼らのノードのPath録音方針をルーティング方針に合わせなければなりません。
5.5 Examples of Usage
5.5 用法に関する例
Note that some header fields (e.g. Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation. The node marked REGISTRAR is a registrar and a proxy and serves as a home proxy. Thus, in the DNS the domain EXAMPLEHOME.COM points to the same host as REGISTRAR.EXAMPLEHOME.COM.
いくつかのヘッダーフィールド(例えば、Content-長さ)とセッション記述が、より短くて願わくはより読み込み可能なプレゼンテーションを提供するために省略されることに注意してください。 REGISTRARであるとマークされたノードは、記録係とプロキシであり、家のプロキシとして勤めます。 したがって、DNSでは、ドメインEXAMPLEHOME.COMはREGISTRAR.EXAMPLEHOME.COMと同じホストを示します。
5.5.1 Example of Mechanism in REGISTER Transaction
5.5.1 レジスタ取引におけるメカニズムに関する例
As an example, we use the scenario from the Background section:
例として、私たちはBackground部からのシナリオを使用します:
UA1----P1-----P2----P3-----REGISTRAR
UA1----P1-----P2----P3-----記録係
Willis & Hoeneisen Standards Track [Page 7] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[7ページ]。
In this example, UA1 sends a REGISTER request to REGISTRAR. This request transits its default outbound proxy P1, an intermediate proxy P2, and the firewall proxy for the home domain, P3, before reaching REGISTRAR. Due to network topology and operational policy, P1 and and P3 need to be transited by requests from REGISTRAR or other nodes in the home network targeted to UA1. P2 does not. P1 and P3 have been configured to include themselves in Path header fields on REGISTER requests that they process. UA1 has a current IP address of "192.0.2.4".
この例では、UA1はREGISTER要求をREGISTRARに送ります。 この要求がデフォルト外国行きのプロキシP1を通過して、中間的プロキシがP2であり、家のドメインへのファイアウォールプロキシ、達する前のP3はREGISTRARです。 そして、ネットワーク形態と運用政策、P1、そして、REGISTRARからの要求か他のノードによってUA1に狙うホームネットワークで通過するべきP3の必要性。 P2はそうしません。 P1とP3は、処理するというREGISTER要求のPathヘッダーフィールドに自分たちを含むように構成されました。 UA1には現在のIPアドレスがある、「192.0 .2 0.4インチ」
Message sequence for REGISTER with Path:
PathとREGISTERのためのメッセージ系列:
F1 Register UA1 -> P1
F1レジスタUA1->P1
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
. . .
一口を示してください: 以下を通ってREGISTRAR.EXAMPLEHOME.COM一口/2.0 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路…
F2 Register P1 -> P2
F2はP1->P2を登録します。
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P1.EXAMPLEVISITED.COM;lr>
. . .
一口を示してください: 以下を通ってREGISTRAR.EXAMPLEHOME.COM一口/2.0 一口/2.0/UDP112.68.155.4: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P1.EXAMPLEVISITED.COM; lr>…
Note: P1 has added itself to the Path.
以下に注意してください。 P1はPathにそれ自体を加えました。
Willis & Hoeneisen Standards Track [Page 8] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[8ページ]。
F3 Register P2 -> P3
F3はP2->P3を登録します。
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P1.EXAMPLEVISITED.COM;lr>
. . .
一口を示してください: 以下を通ってREGISTRAR.EXAMPLEHOME.COM一口/2.0 一口/2.0/UDP178.73.76.230: 5060; ブランチは以下を通ってz9hG4bKiokioukju908と等しいです。 一口/2.0/UDP112.68.155.4: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P1.EXAMPLEVISITED.COM; lr>…
Note: P2 did NOT add itself to the Path.
以下に注意してください。 P2はPathにそれ自体を加えませんでした。
F4 Register P3 -> REGISTRAR
F4はP3->記録係を登録します。
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .
一口を示してください: 以下を通ってREGISTRAR.EXAMPLEHOME.COM一口/2.0 一口/2.0/UDP19.31.97.3: 5060; ブランチは以下を通ってz9hG4bKp3wer654363と等しいです。 一口/2.0/UDP178.73.76.230: 5060; ブランチは以下を通ってz9hG4bKiokioukju908と等しいです。 一口/2.0/UDP112.68.155.4: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P3.EXAMPLEHOME.COM; lr>、<一口: P1.EXAMPLEVISITED.COM; lr>…
Note: P3 added itself to the Path.
以下に注意してください。 P3はPathにそれ自体を加えました。
F5 REGISTRAR executes Register
F5 REGISTRARはRegisterを実行します。
REGISTRAR Stores:
For UA1@EXAMPLEHOME.COM
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
記録係ストア: UA1@EXAMPLEHOME.COM に関しては、以下に連絡してください。 <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P3.EXAMPLEHOME.COM; <一口: lr>、P1.EXAMPLEVISITED.COM; lr>。
Willis & Hoeneisen Standards Track [Page 9] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[9ページ]。
F6 Register Response REGISTRAR -> P3
F6は応答記録係->P3を登録します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .
以下を通って一口/2.0 200OK 一口/2.0/UDP19.31.97.3: 5060; ブランチは以下を通ってz9hG4bKp3wer654363と等しいです。 一口/2.0/UDP178.73.76.230: 5060; ブランチは以下を通ってz9hG4bKiokioukju908と等しいです。 一口/2.0/UDP112.68.155.4: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、;=251077From:にタグ付けをしてください UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P3.EXAMPLEHOME.COM; lr>、<一口: P1.EXAMPLEVISITED.COM; lr>…
Note: The Path header field in the response is identical to the
one received in the REGISTER request.
以下に注意してください。 応答におけるPathヘッダーフィールドはREGISTER要求に受け取られたものと同じです。
F7 Register Response P3 -> P2
F7は応答P3->P2を登録します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .
以下を通って一口/2.0 200OK 一口/2.0/UDP178.73.76.230: 5060; ブランチは以下を通ってz9hG4bKiokioukju908と等しいです。 一口/2.0/UDP112.68.155.4: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、;=251077From:にタグ付けをしてください UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P3.EXAMPLEHOME.COM; lr>、<一口: P1.EXAMPLEVISITED.COM; lr>…
F8 Register Response P2 -> P1
F8は応答P2->P1を登録します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .
以下を通って一口/2.0 200OK 一口/2.0/UDP112.68.155.4: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、;=251077From:にタグ付けをしてください UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P3.EXAMPLEHOME.COM; lr>、<一口: P1.EXAMPLEVISITED.COM; lr>…
Willis & Hoeneisen Standards Track [Page 10] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[10ページ]。
F9 Register Response P1 -> UA1
F9は応答P1->UA1を登録します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .
以下を通って一口/2.0 200OK 一口/2.0/UDP192.0.2.4: 5060;ブランチ=z9hG4bKnashds7To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、;=251077From:にタグ付けをしてください UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、; タグは456248呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@192.0.2.4 、gt;、支持される: 経路Path: <一口: P3.EXAMPLEHOME.COM; lr>、<一口: P1.EXAMPLEVISITED.COM; lr>…
5.5.2 Example of Mechanism in INVITE Transaction
5.5.2 招待取引におけるメカニズムに関する例
This example shows the message sequence for an INVITE transaction originating from UA2 eventually arriving at UA1. REGISTRAR inserts a preloaded Route toward UA1 and retargets the request by replacing the request URI with the registered Contact. It then sends the retargeted INVITE along the Path towards UA1. Note that this example introduces foreign user agent UA2 (address "71.91.180.10") and foreign domain FOREIGN.ELSEWHERE.ORG. We have extended the diagram from the previous example by adding UA2, and by showing P2 out-of- line indicating that it did not include itself in the path during registration.
この例は結局UA1に到着するUA2から発するINVITE取引のためにメッセージ系列を示しています。 REGISTRARはプレロードされたRouteをUA1に向かって挿入します、そして、「再-目標」は要求URIを登録されたContactに取り替えるのによる要求を挿入します。 そして、それはPathに沿ってUA1に向かってretargeted INVITEを送ります。 この例が外国人のユーザエージェントUA2を導入することに注意してください、(アドレス、「71.91 .180 0.1インチ)、外国ドメインFOREIGN.ELSEWHERE.ORG、」 UA2を言い足して、-登録の間、それを示して、線では、それが経路にそれ自体を含んでいなかったのをP2アウトに示すことによって、私たちは前の例からダイヤグラムを広げました。
Scenario
シナリオ
UA1----P1---------P3-----REGISTRAR
| |
P2 |
|
UA2--------------------------
UA1----P1---------P3-----記録係| | P2| | UA2--------------------------
Message sequence for INVITE using Path:
Pathを使用するINVITEのためのメッセージ系列:
F1 Invite UA2 -> REGISTRAR
F1はUA2->記録係を招待します。
INVITE UA1@EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
以下を通って UA1@EXAMPLEHOME.COM 一口/2.0を招待してください。 一口/2.0/UDP71.91.180.10: 5060;ブランチ=z9hG4bKe2i95c5st3R To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA2<一口: UA2@FOREIGN.ELSEWHERE.ORG 、gt;、; タグは224497呼び出しIDと等しいです: 48273181116@71.91.180.10 CSeq: 29 接触を招いてください: <一口: UA2@71.91.180.10 、gt;、…
Willis & Hoeneisen Standards Track [Page 11] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[11ページ]。
F2 REGISTRAR processing
F2 REGISTRAR処理
REGISTRAR looks up name "UA1@EXAMPLEHOME.COM" and returns:
- Contact = <sip:UA1@192.0.2.4>
- Path vector = <sip:P3.EXAMPLEHOME.COM;lr>,
<sip:P1.EXAMPLEVISITED.COM;lr>
REGISTRARは名前" UA1@EXAMPLEHOME.COM "を見上げて、戻ります: - 接触が<一口: UA1@192.0.2.4 と等しい、gt;、--経路ベクトルが<一口: P3.EXAMPLEHOME.COM; <一口: lr>、P1.EXAMPLEVISITED.COM; lr>と等しい
Note: The Contact replaces the request-URI. The path vector is
pushed onto the Route stack (preloaded Route) of the outgoing
INVITE request. The topmost Route is used for making the
routing decision (in conjunction with local policy).
以下に注意してください。 Contactは要求URIを取り替えます。 経路ベクトルは送信するINVITE要求のRouteスタック(プレロードされたRoute)に押されます。 最上のRouteは、ルーティング決定(ローカルの方針に関連した)をするのに使用されます。
F3 Invite REGISTRAR -> P3
F3は記録係->P3を招待します。
INVITE UA1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
Route: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .
以下を通って UA1@192.0.2.4 一口/2.0を招待してください。 一口/2.0/UDP143.70.6.83: 5060; ブランチは以下を通ってz9hG4bKlj25C107a7b176と等しいです。 一口/2.0/UDP71.91.180.10: 5060;ブランチ=z9hG4bKe2i95c5st3R To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA2<一口: UA2@FOREIGN.ELSEWHERE.ORG 、gt;、; タグは224497呼び出しIDと等しいです: 48273181116@71.91.180.10 CSeq: 29 接触を招いてください: <一口: UA2@71.91.180.10 、gt;、ルート: <一口: P3.EXAMPLEHOME.COM; lr>、<一口: P1.EXAMPLEVISITED.COM; lr>…
Note: In this example REGISTRAR does not want to stay on the
Route and therefore does not insert a Record-Route.
以下に注意してください。 この例には、REGISTRARはRouteに滞在したくなくて、したがって、Record-ルートを挿入しません。
F4 Invite P3 -> P1
F4はP3->P1を招待します。
INVITE UA1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e
Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>
Route: <sip:P1.EXAMPLEVISITED.COM;lr>
. . .
以下を通って UA1@192.0.2.4 一口/2.0を招待してください。 一口/2.0/UDP19.31.97.3: 5060; ブランチは以下を通ってz9hG4bKjasg7li7nc9eと等しいです。 一口/2.0/UDP143.70.6.83: 5060; ブランチは以下を通ってz9hG4bKlj25C107a7b176と等しいです。 一口/2.0/UDP71.91.180.10: 5060;ブランチ=z9hG4bKe2i95c5st3R To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA2<一口: UA2@FOREIGN.ELSEWHERE.ORG 、gt;、; タグは224497呼び出しIDと等しいです: 48273181116@71.91.180.10 CSeq: 29 接触を招いてください: <一口: UA2@71.91.180.10 、gt;、記録的なルート: <一口: P3.EXAMPLEHOME.COM; lr>ルート: <一口: P1.EXAMPLEVISITED.COM; lr>…
Note: P3 has added a Record-Route entry, indicating that it wants
to be traversed by future messages in this dialog.
以下に注意してください。 それをこの対話における将来のメッセージによって横断されたいのを示して、P3はRecord-ルートエントリーを加えました。
Willis & Hoeneisen Standards Track [Page 12] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[12ページ]。
F5 Invite P1 -> UA1
F5はP1->UA1を招待します。
INVITE UA1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e
Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
Record-Route: <sip:P1.EXAMPLEVISITED.COM;lr>
Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>
. . .
以下を通って UA1@192.0.2.4 一口/2.0を招待してください。 一口/2.0/UDP112.68.155.4: 5060; ブランチは以下を通ってz9hG4bKk5l1833o43pと等しいです。 一口/2.0/UDP19.31.97.3: 5060; ブランチは以下を通ってz9hG4bKjasg7li7nc9eと等しいです。 一口/2.0/UDP143.70.6.83: 5060; ブランチは以下を通ってz9hG4bKlj25C107a7b176と等しいです。 一口/2.0/UDP71.91.180.10: 5060;ブランチ=z9hG4bKe2i95c5st3R To: UA1<一口: UA1@EXAMPLEHOME.COM 、gt;、From: UA2<一口: UA2@FOREIGN.ELSEWHERE.ORG 、gt;、; タグは224497呼び出しIDと等しいです: 48273181116@71.91.180.10 CSeq: 29 接触を招いてください: <一口: UA2@71.91.180.10 、gt;、記録的なルート: <一口: P1.EXAMPLEVISITED.COM; lrの>の記録的なルート: <一口: P3.EXAMPLEHOME.COM; lr>…
Note: P1 has added a Record-Route entry, indicating that it wants
to be traversed by future messages in this dialog.
以下に注意してください。 それをこの対話における将来のメッセージによって横断されたいのを示して、P1はRecord-ルートエントリーを加えました。
6. Security Considerations
6. セキュリティ問題
There are few security considerations for this document beyond those in SIP [1]. From a security perspective, the Path extension and its usage are identical to the Record-Route header field of basic SIP. Note that the transparency of the user expectations are preserved by returning the final Path to the originating UA -- that is, the UA is informed which additional proxies have been inserted into the path for the registration associated with that response.
それらを超えたSIP[1]のこのドキュメントのためのセキュリティ問題がわずかしかありません。 セキュリティ見解から、Path拡張子とその用法は基本的なSIPのRecord-ルートヘッダーフィールドと同じです。 ユーザ期待の透明がある注意が由来しているUA()に最終的なPathを返すことによって保存されて、UAはその応答に関連している登録のためにどの追加プロキシを経路に挿入してあるかを知らされます。
The Path header field accumulates information in a hop-by-hop manner during REGISTER processing. The return information is essentially end-to-end, that is, it is not altered by intermediate proxies. This leads to two slightly different security approaches.
PathヘッダーフィールドはREGISTER処理の間、ホップごとの方法による情報を蓄積します。 リターン情報が本質的には終わらせる終わりである、すなわち、それは中間的プロキシによって変更されません。 これは2つのわずかに異なったセキュリティアプローチに通じます。
6.1 Considerations in REGISTER Request Processing
レジスタの6.1の問題が処理を要求します。
Information accumulated in REGISTER processing causes additional proxies to be included in future requests between the registrar's location and the UA. An attack that allowed an intruding proxy to add itself to this chain would allow the attacker to intercept future calls intended for the UA.
情報は、記録係の位置とUAの間の今後の要求に含まれるようにREGISTER処理原因で追加プロキシを蓄積しました。 侵入しているプロキシがこのチェーンにそれ自体を追加できた攻撃で、攻撃者はUAのために意図する今後の呼び出しを妨害できるでしょう。
An attacker could conceivably alter the Path either by altering data "on the wire" or by other manipulations (such as impersonation) that would cause it to be included in the SIP routing chain (a "node insertion" attack). Altering data "on the wire" may be addressed adequately by the use of transport-layer integrity protection mechanisms such as TLS or IPSEC. Proxy insertion can be addressed by
「ワイヤ」というデータを変更するか、SIPルーティングチェーン(「ノード挿入」攻撃)にそれを含んでいる他の操作(ものまねなどの)で攻撃者は多分Pathを変更できるでしょう。 「ワイヤ」というデータを変更するのはTLSかIPSECなどのトランスポート層保全保護メカニズムの使用で適切に記述されるかもしれません。 挿入を記述できるプロキシ
Willis & Hoeneisen Standards Track [Page 13] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[13ページ]。
mutual authentication at the proxy layer, which can also be provided by TLS or IPSEC. The "sips:" URI class defined in [1] provides a mechanism by which a UA may request that intermediate proxies provide integrity protection and mutual authentication.
プロキシ層での互いの認証。(また、TLSかIPSECがそれを提供できます)。 「一口:」 [1]で定義されたURIのクラスはUAが、中間的プロキシが保全保護と互いの認証を提供するよう要求するかもしれないメカニズムを提供します。
Systems using the Path mechanism SHOULD use appropriate mechanisms (TLS, IPSEC, etc.) to provide message integrity and mutual authentication. UAs SHOULD use "sips:" to request transitive protection.
PathメカニズムSHOULDを使用するシステムは、メッセージの保全と互いの認証を提供するのに、適切な手段(TLS、IPSECなど)を使用します。 UAs SHOULD使用は「以下をちびちび飲みます」。 他動な保護を要求するために。
The registering UA SHOULD use S/MIME mechanisms to provide a protected copy of the original request to the registrar. In this case, the UA SHOULD include a Supported header field with a value indicating support for the Path extension in the protected copy. Registrars receiving such as request MUST honor the Path extension only if support is indicated in the protected header field. Further, they SHOULD compare the unprotected Supported header field with the protected Supported header field and take appropriate action in the event that an intermediate has altered the message to indicate support for Path when it was not indicated by the requesting UA.
登録しているUA SHOULDは、保護された謄本要求を記録係に提供するのにS/MIMEメカニズムを使用します。 この場合、UA SHOULDは保護されたコピーにおけるPath拡張子のサポートを示す値があるSupportedヘッダーフィールドを含んでいます。 サポートが保護されたヘッダーフィールドで示される場合にだけ、要求としてそのようなものを受ける記録係はPath拡張子を光栄に思わなければなりません。 さらに、それら、SHOULDは保護されたSupportedヘッダーフィールドと保護のないSupportedヘッダーフィールドを比べて、中間介在物がそれが要求しているUAによって示されなかったときPathのサポートを示すメッセージを変更した場合、適切な行動を取ります。
6.2 Considerations in REGISTER Response Processing
6.2 レジスタ応答処理における問題
The data returned to the UA by the Path header field in the response to the REGISTER request is there to provide openness to the UA. The registrar is telling the UA, "These are the intermediate proxies that will be included on future requests to you processed through me". By inspection of this header field, the UA may be able to detect node insertion attacks that involve inserting a proxy into the SIP routing chain. S/MIME techniques may be used to prevent alteration of this header field by intermediate proxies during response processing.
風通しの良さをUAに供給するために、REGISTER要求への応答におけるPathヘッダーフィールドによるUAに返されたデータはそこにあります。 「これらは私を通してあなたに処理された今後の要求のときに含まれている中間的プロキシです。」と、記録係はUAに言っています。 このヘッダーフィールドの点検で、UAはSIPルーティングチェーンにプロキシを挿入することを伴うノード挿入攻撃を検出できるかもしれません。 S/MIMEのテクニックは、応答処理の間、中間的プロキシによるこのヘッダーフィールドの変更を防ぐのに使用されるかもしれません。
As specified, there is no requirement for arbitrary proxies between the UA and the registrar to modify the Path header field in the REGISTER response. Consequently, we may use an end-to-end protection technique. The S/MIME technique defined in [1] provides an effective mechanism. Using this technique, the registrar makes a copy of the complete response, signs it, and attaches it as a body to the response. The UA may then verify this response, assuring an unmodified Path header field is received.
指定されるように、REGISTER応答にはUAと記録係の間の任意のプロキシがPathヘッダーフィールドを変更するという要件が全くありません。 その結果、私たちは終わりから終わりへの保護テクニックを使用するかもしれません。 [1]で定義されたS/MIMEのテクニックは有効なメカニズムを提供します。 このテクニックを使用して、記録係は、ボディーとして応答に完全な応答のコピーを作って、それにサインして、それを付けます。 そして、ヘッダーフィールドが受け取られていることを変更されていないPathに保証して、UAはこの応答について確かめるかもしれません。
In addition to the hop-by-hop integrity protection and mutual authentication measures suggested for REGISTER request processing in the preceding section, systems using Path header fields SHOULD implement end-to-end protection using S/MIME. More specifically, registrars returning a Path header field SHOULD attach a signed S/MIME of the response, and UAs receiving a REGISTER response containing a Path header field SHOULD validate the message using the
先行するセクションにおけるREGISTER要求処理のために示されたホップごとの保全保護と互いの認証測定に加えて、PathヘッダーフィールドSHOULDを使用するシステムが、S/MIMEを使用することで終わりから終わりへの保護を実行します。 より明確に、PathヘッダーフィールドSHOULDを含むREGISTER応答を受けながら応答、およびUAsのサインされたS/MIMEをSHOULDが付けるPathヘッダーフィールドに返す記録係がメッセージ使用を有効にします。
Willis & Hoeneisen Standards Track [Page 14] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[14ページ]。
S/MIME technique. Furthermore, UAs receiving a Path header field in a REGISTER response SHOULD render it to the user, or (where feasible) check it programmatically.
S/MIMEのテクニック。 その上、REGISTER応答SHOULDにおけるPathヘッダーフィールドを受けるUAsがそれをユーザに提供するか、またはプログラムに基づいてそれをチェックします(可能であるところ)。
7. IANA Considerations
7. IANA問題
This document defines the SIP extension header field "Path", which the IANA has added to the registry of SIP header fields defined in SIP [1].
このドキュメントはSIP拡張ヘッダー分野「経路」を定義します。(IANAはSIP[1]で定義されたSIPヘッダーフィールドの登録にそれを加えました)。
This document also defines the SIP option tag "path" which IANA has added to the registry of SIP option tags defined in SIP [1].
また、このドキュメントはIANAがSIP[1]で定義されたSIPオプションタグの登録に加えたSIPオプションタグ「経路」を定義します。
The following is the registration for the Path header field:
↓これはPathヘッダーフィールドのための登録です:
RFC Number: RFC3327
RFC番号: RFC3327
Header Field Name: Path
ヘッダーフィールド名: 経路
Compact Form: none
コンパクト形: なし
The following is the registration for the path option tag:
↓これは経路オプションタグのための登録です:
RFC Number: RFC3327
RFC番号: RFC3327
Option Tag: path
オプションタグ: 経路
8. Acknowledgements
8. 承認
Min Huang and Stinson Mathai, who put together the original proposal in 3GPP for this mechanism, and worked out most of the 3GPP procedures in 24.229.
分のホアンとスティンソンMathai。(そのMathaiはこのメカニズムのために3GPPに起案をまとめて、24.229で3GPP手順の大部分を考え出しました)。
Keith Drage, Bill Marshall, and Miguel Angel Garcia-Martin who argued with everybody a lot about the idea as well as helped refine the requirements.
キースDrage、ビル・マーシャル、および考えに関してみんなと大いに言い争って、助けたミゲル・Angelガルシア-マーチンが要件を洗練します。
Juha Heinanen, who argued steadfastly against standardizing the function of discovering the home proxy with this technique in this document.
ユハHeinanen、だれが本書ではこのテクニックがある家のプロキシを発見する機能を標準化しながら、しっかりと論争しましたか?
Willis & Hoeneisen Standards Track [Page 15] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[15ページ]。
Normative References
引用規格
[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., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[4] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
Non-Normative References
非引用規格
[5] Garcia-Martin, MA., "3GPP Requirements On SIP", Work in Progress.
[5] ガルシア-マーチン(MA)、「一口に関する3GPP要件」は進行中で働いています。
[6] Mankin, A., "SIP Change Process", Work in Progress.
[6] マンキン、A.、「一口変化の過程」が進行中で働いています。
Authors' Addresses
作者のアドレス
Dean Willis dynamicsoft Inc. 5100 Tennyson Parkway Suite 1200 Plano, TX 75028 US
ディーンウィリスdynamicsoft Inc.5100テニソンパークウェイSuite1200テキサス75028プラノ(米国)
Phone: +1 972 473 5455 EMail: dean.willis@softarmor.com URI: http://www.dynamicsoft.com/
以下に電話をしてください。 +1 5455年の972 473メール: dean.willis@softarmor.com ユリ: http://www.dynamicsoft.com/
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland
バーニーHoeneisenスイッチLimmatquai138CH-8001 Zuerichスイス
Phone: +41 1 268 1515 EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org URI: http://www.switch.ch/
以下に電話をしてください。 +41 1 268 1515はメールされます: hoeneisen@switch.ch 、b.は@ieee.org URIをhoeneisenします: http://www.switch.ch/
Willis & Hoeneisen Standards Track [Page 16] RFC 3327 Path Extension Header Field for SIP December 2002
ウィリスとHoeneisen規格は2002年12月に一口のためにRFC3327経路拡張ヘッダー分野を追跡します[16ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。
Willis & Hoeneisen Standards Track [Page 17]
ウィリスとHoeneisen標準化過程[17ページ]
一覧
スポンサーリンク
