RFC3608 日本語訳
3608 Session Initiation Protocol (SIP) Extension Header Field forService Route Discovery During Registration. D. Willis, B. Hoeneisen. October 2003. (Format: TXT=35628 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Willis
Request for Comments: 3608 dynamicsoft Inc.
Category: Standards Track B. Hoeneisen
Switch
October 2003
コメントを求めるワーキンググループD.ウィリス要求をネットワークでつないでください: 3608dynamicsoft株式会社Category: 標準化過程B.Hoeneisenスイッチ2003年10月
Session Initiation Protocol (SIP) Extension Header Field
for Service Route Discovery During Registration
登録の間のサービスルート発見のためのセッション開始プロトコル(一口)拡大ヘッダーフィールド
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.
このドキュメントは記録係がUAが記録係のドメインから出国サービスを要求するのに使用するかもしれないサービスルートについて登録しているユーザエージェント(UA)に知らせるかもしれないメカニズムを提供するというREGISTER要求への応答に関連して使用されるSession Initiationプロトコル(SIP)拡大ヘッダーフィールドを定義します。
Table of Contents
目次
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Discussion of Mechanism . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . 5
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Procedures at the UA . . . . . . . . . . . . . . . . . 6
6.2. Procedures at the Proxy . . . . . . . . . . . . . . . 7
6.3. Procedures at the Registrar . . . . . . . . . . . . . 8
6.4. Examples of Usage . . . . . . . . . . . . . . . . . . 9
6.4.1. Example of Mechanism in REGISTER Transaction . 9
6.4.2. Example of Mechanism in INVITE Transaction . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 15
1. 用語. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 メカニズム. . . . . . . . . . . . . . . . . . 4 4の議論。 適用性証明. . . . . . . . . . . . . . . . . . 5 5。 構文. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6。 用法. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1。 UA. . . . . . . . . . . . . . . . . 6 6.2の手順。 プロキシ. . . . . . . . . . . . . . . 7 6.3における手順。 記録係. . . . . . . . . . . . . 8 6.4における手順。 用法. . . . . . . . . . . . . . . . . . 9 6.4.1に関する例。 レジスタ取引. 9 6.4.2におけるメカニズムに関する例。 招待取引. . 12 7におけるメカニズムに関する例。 セキュリティ問題. . . . . . . . . . . . . . . . . . 14 8。 IANA問題. . . . . . . . . . . . . . . . . . . . 15 9。 引用規格. . . . . . . . . . . . . . . . . . . . 15 10。 有益な参照. . . . . . . . . . . . . . . . . . . 15
Willis & Hoeneisen Standards Track [Page 1] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[1ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
11. Intellectual Property Statement. . . . . . . . . . . . . . . 16 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
11. 知的所有権声明。 . . . . . . . . . . . . . . 16 12. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 16 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 17
1. Terminology
1. 用語
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
2. Background
2. バックグラウンド
The Third Generation Partnership Project (3GPP) established a requirement for discovering home proxies during SIP registration and published this requirement in [6]. The 3GPP network dynamically assigns a home service proxy to each address-of-record (AOR). This assignment may occur in conjunction with a REGISTER operation, or out-of-band as needed to support call services when the address-of- record has no registrations. This home service proxy may provide both inbound (UA terminated) and outbound (UA originated) services.
Third Generation Partnership Project(3GPP)はSIP登録の間、家のプロキシを発見するために要件を確立して、[6]でこの要件を発表しました。 3GPPネットワークはダイナミックに各記録されている住所(AOR)に在宅サービスプロキシを選任します。 この課題がREGISTER操作に関連して起こるか、またはアドレスであるときに、呼び出しサービスを支持するのが必要であるのでバンドの外に起こるかもしれない、-、-記録には、登録証明書が全くありません。 この在宅サービスプロキシは(UAは由来しました)本国行き(終えられたUA)の、そして、外国行きの両方のサービスを提供するかもしれません。
In the inbound case, the Request-Uniform Resource Identifier (URI) of incoming SIP requests matches the address-of-record of a user associated with the home service proxy. The home service proxy then (in most cases) forwards the request to the registered contact address for that AOR. A mechanism for traversing required proxies between the home service proxy and the registered UA is presented in [4].
本国行きの場合では、入って来るSIP要求のRequest-Uniform Resource Identifier(URI)は在宅サービスプロキシに関連しているユーザの記録されている住所に合っています。 (多くの場合、)そして、在宅サービスプロキシはそのAORのための登録された連絡先に要求を転送します。 在宅サービスプロキシと登録されたUAの間の必要なプロキシを横断するためのメカニズムは[4]に提示されます。
Outbound (UA originated) session cases raise another issue. Specifically, "How does the UA know which service proxy to use and how to get there?"
(UAは由来しました)外国行きのセッションケースは別の問題を提起します。 明確に、「UAはどのサービスプロキシを使用するか、そして、どのようにそこに到着するかをどのように知っていますか?」
Several mechanisms were proposed in list discussions, including:
数個のメカニズムがリスト議論、包含で提案されました:
1. Configuration data in the UA. This raises questions of UA
configuration management and updating, especially if proxy
assignment is very dynamic, such as in load-balancing scenarios.
1. UAのコンフィギュレーション・データ。 これはUA構成管理とアップデートの疑問を引き起こします、特にプロキシ課題が非常にダイナミックであるなら、負荷分散シナリオなどのように。
2. Use of some other protocol, such as HTTP, to get configuration
data from a configuration server in the home network. While
functional, this solution requires additional protocol engines,
firewall complexity, operations overhead, and significant
additional "over the air" traffic.
2. ホームネットワークにおける構成サーバからコンフィギュレーション・データを得るある他のHTTPとしてそのようなプロトコルの使用。 機能的ですが、この解決策は追加議定書エンジン、ファイアウォールの複雑さ、操作オーバーヘッド、および「空気」重要な追加交通を必要とします。
3. Use of lookup tables in the home network, as may be done for
inbound requests in some 3G networks. This has a relatively high
overhead in terms of database operations.
3. いくつかの3Gネットワークにおける本国行きの要求のためにするかもしれないようなホームネットワークにおけるルックアップ表の使用。 これには、比較的高いオーバーヘッドがデータベース操作であります。
Willis & Hoeneisen Standards Track [Page 2] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[2ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
4. Returning a 302 response indicating the service proxy as a new
contact, causing the upstream node processing the 302 (ostensibly
the UA) to retransmit the request toward the service proxy. While
this shares the database operation of the previous alternative, it
does explicitly allow for caching the 302 response thereby
potentially reducing the frequency and number of database
operations.
4. 上流のノード処理に302を引き起こして、新しい接触としてサービスプロキシを示す302応答を返す、(表面上、UA) サービスプロキシに向かって要求を再送するために。 これが前の代替手段のデータベース操作を共有している間、それは、データベース操作の頻度と数を潜在的に減少させながら、その結果302応答をキャッシュすると明らかに考慮します。
5. Performing an operation equivalent to record-routing in a REGISTER
transaction between the UA and the associated registrar, then
storing that route in the UA and reusing it as a service route on
future requests originating from the UA. While efficient, this
constrains the service route for proxy operations to be congruent
with the route taken by the REGISTER message.
5. UAから発する今後の要求のときに、UAと関連記録係の間のREGISTER取引における記録的なルーティングに同等な操作を実行して、次に、UAにそのルートを格納して、サービスルートとしてそれを再利用します。 効率的ですが、これはREGISTERメッセージでルートを取っていて一致しているプロキシ操作のためのサービスルートを抑制します。
6. Returning service route information as the value of a header field
in the REGISTER response. While similar to the previous
alternative, this approach grants the ability for the registrar to
selectively apply knowledge about the topology of the home network
in constructing the service route.
6. REGISTER応答における、ヘッダーフィールドの値としてサービス経由地案内を返します。 前の代替手段と同様ですが、このアプローチは記録係がホームネットワークのトポロジーに関してサービスルートを構成する際に選択的に知識を応用する能力を与えます。
This document defines this final alternative: returning the service route information as a header field in the REGISTER response. This new header field indicates a "preloaded route" that the UA may wish to use if requesting services from the proxy network associated with the registrar generating the response.
このドキュメントはこの最終的な代替手段を定義します: REGISTER応答におけるヘッダーフィールドとしてサービス経由地案内を返します。 応答を発生させる記録係に関連しているプロキシネットワークからサービスを要求するなら、この新しいヘッダーフィールドはUAが使用したがっているかもしれない「プレロードされたルート」を示します。
Scenario
シナリオ
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HSP-----|
UA1----P1-----| |--R-------| | | | P2---| DBMS| | | UA2-----------| |--HSP-----|
In this scenario, we have a "home network" containing routing proxy P2, registrar R, home service proxy HSP, and database DBMS used by both R and HSP. P2 represents the "edge" of the home network from a SIP perspective, and might be called an "edge proxy". UA1 is an external UA behind proxy P1. UA1 discovers P1 via Dynamic Host Configuration Protocol (DHCP) (this is just an example, and other mechanisms besides DHCP are possible). UA2 is another UA on the Internet, and does not use a default outbound proxy. We do not show Domain Name System (DNS) elements in this diagram, but will assume their reasonable availability in the discussion. The mission is for UA1 to discover HSP so that outbound requests from UA1 may be routed (at the discretion of UA1) through HSP, thereby receiving outbound services from HSP.
このシナリオでは、私たちはプロキシP2、記録係R(在宅サービスプロキシHSP)、およびデータベースDBMSがRとHSPの両方で使用したルーティングを含む「ホームネットワーク」を持っています。 P2はSIP見解からホームネットワークの「縁」を表して、「縁のプロキシ」と呼ばれるかもしれません。 UA1はプロキシP1の後ろの外部のUAです。 UA1はDynamic Host Configuration Protocol(DHCP)でP1を発見します(これがただ例です、そして、DHCP以外に他のメカニズムは可能です)。 UA2はインターネットの別のUAであり、デフォルトの外国行きのプロキシを使用しません。 私たちは、このダイヤグラムでドメインネームシステム(DNS)要素を見せませんが、議論でそれらの妥当な有用性を仮定するつもりです。 任務はHSPを通してUA1からの外国行きの要求を発送できる(UA1の裁量で)ようにHSPを発見するUA1のためのものです、その結果、HSPから出国サービスを受けます。
Willis & Hoeneisen Standards Track [Page 3] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[3ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
3. Discussion of Mechanism
3. メカニズムの議論
UAs may include a Route header field in an initial request to force that request to visit and potentially be serviced by one or more proxies. Using such a route (called a "service route" or "preloaded route") allows a UA to request services from a specific home proxy or network of proxies. The open question is, "How may a UA discover what service route to use?"
UAsは訪問するというその要求を強制して、1つ以上のプロキシによって潜在的に修理されるという初期の要求にRouteヘッダーフィールドを含むかもしれません。 そのようなルート(「サービスルートかプレロードされたルート」と呼ばれる)を使用するのに、UAはプロキシの特定の家のプロキシかネットワークからサービスを要求できます。 未決問題は「UAは、どんなサービスルートを使用したらよいかをどのように発見するかもしれませんか?」ということです。
This document defines a header field called "Service-Route" which can contain a route vector that, if used as discussed above, will direct requests through a specific sequence of proxies. A registrar may use a Service-Route header field to inform a UA of a service route that, if used by the UA, will provide services from a proxy or set of proxies associated with that registrar. The Service-Route header field may be included by a registrar in the response to a REGISTER request. Consequently, a registering UA learns of a service route that may be used to request services from the system it just registered with.
このドキュメントは上で議論するように使用されるならプロキシの特定の系列を通して要求を指示するルートベクトルを含むことができる「サービスルート」と呼ばれるヘッダーフィールドを定義します。 記録係は、UAによって使用されるなら、プロキシからサービスを提供するか、またはセットするその記録係に関連しているプロキシのサービスルートについてUAに知らせるのにService-ルートヘッダーフィールドを使用するかもしれません。 Service-ルートヘッダーフィールドはREGISTER要求への応答で記録係によって入れられるかもしれません。 その結果、登録UAはそれがただともに記名したシステムからサービスを要求するのに使用されるかもしれないサービスルートを知っています。
The routing established by the Service-Route mechanism applies only to requests originating in the user agent. That is, it applies only to UA originated requests, and not to requests terminated by that UA.
Service-ルートメカニズムによって確立されたルーティングはユーザエージェントで起こる要求だけに適用されます。 すなわち、それは溯源された要求であって、要求に終えられなかったUAだけごとに適用されます。
Simply put, the registrar generates a service route for the registering UA and returns it in the response to each successful REGISTER request. This service route has the form of a Route header field that the registering UA may use to send requests through the service proxy selected by the registrar. The UA would use this route by inserting it as a preloaded Route header field in requests originated by the UA intended for routing through the service proxy.
単に、置かれます、記録係は登録しているUAのためにサービスルートを発生させて、それぞれのうまくいっているREGISTER要求への応答でそれを返します。 このサービスルートには、登録しているUAが記録係によって選ばれたサービスプロキシを通して要求を送るのに使用するかもしれないRouteヘッダーフィールドのフォームがあります。 UAは、要求におけるプレロードされたRouteヘッダーフィールドがルーティングのためにサービスプロキシを通して意図するUAで由来したときそれを挿入することによって、このルートを使用するでしょう。
The mechanism by which the registrar constructs the header field value is specific to the local implementation and outside the scope of this document.
記録係がヘッダーフィールド値を構成するメカニズムは地方の実現とこのドキュメントの範囲の外で特定です。
4. Applicability Statement
4. 適用性証明
The Service-Route mechanism is applicable when:
Service-ルートメカニズムが適切である、いつ:
1. The UA registers with a registrar.
1. UAは記録係とともに記名します。
2. The registrar has knowledge of a service proxy that should be used
by the UA when requesting services from the domain of the
registrar. This knowledge may be a result of dynamic assignment
or some other mechanism outside the scope of this document.
2. 記録係には、記録係のドメインからサービスを要求するときUAによって使用されるはずであるサービスプロキシに関する知識があります。 この知識は、ダイナミックな課題の結果かこのドキュメントの範囲の外のある他のメカニズムであるかもしれません。
Willis & Hoeneisen Standards Track [Page 4] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[4ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
3. The registrar(s) has/have sufficient knowledge of the network
topology, policy, and situation such that a reasonable service
route can be constructed.
3. 記録係は、/に合理的なサービスルートを構成できるようにネットワーク形態、方針、および状況に関する十分な知識を持たせます。
4. The service route constructed by the registrar is the same for all
contacts associated with a single address-of-record. This
mechanism does not provide for contact-specific service routes.
4. ただ一つの記録されている住所に関連しているすべての接触に、記録係によって構成されたサービスルートは同じです。 このメカニズムは接触特有のサービスルートに備えません。
5. Other mechanisms for proposing a service route to the UA are not
available or are inappropriate for use within the specific
environment.
5. サービスルートをUAに提案するための他のメカニズムは、利用可能でないか、または使用に、特定の環境の中で不適当です。
Other methods may also be available by which a UA may be informed of a service route. Such alternative methods are outside the scope of this document. Discussion of why one might wish to assign a service route during registration or when it might be appropriate to do so is outside the scope of this document.
また、他の方法もUAがどれであるかもしれないかでサービスルートにおいて知識があった状態で利用可能であるかもしれません。 このドキュメントの範囲の外にそのような別法があります。 このドキュメントの範囲の外に人がなぜ登録の間、サービスルートを割り当てたがっているかもしれないか、そして、またはそうするのがいつ適切であるかもしれないかに関する議論があります。
5. Syntax
5. 構文
The syntax for the Service-Route header field is:
Service-ルートヘッダーフィールドのための構文は以下の通りです。
Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)
サービスルート=「サービスルート」HCOLON sr-値の*(COMMA sr-値)
sr-value = name-addr *( SEMI rr-param )
sr-値は名前-addr*と等しいです。(SEMI rr-param)
Note that the Service-Route header field values MUST conform to the syntax of a Route element as defined in [3]. As suggested therein, such values MUST include the loose-routing indicator parameter ";lr" for full compliance with [3].
Service-ルートヘッダーフィールド値が[3]で定義されるようにRoute要素の構文に従わなければならないことに注意してください。 「そこに示されるように、そのような値はゆるいルーティングインディケータパラメタを含まなければならない」; lrする、」 [3]への完全な承諾ために。
The allowable usage of header fields is described in Tables 2 and 3 of [3]. The following additions to this table are needed for Service-Route.
ヘッダーフィールドの許容できる用法は[3]のTables2と3で説明されます。 このテーブルへの以下の追加がService-ルートに必要です。
Addition of Service-Route to SIP Table 3:
テーブル3をちびちび飲むサービスルートの添加:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Service-Route 2xx ar - - - - - o -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG PRA_______________________________________________________________ サービスルート2xx ar--、--、--、--、--、o、-
Willis & Hoeneisen Standards Track [Page 5] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[5ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
6. Usage
6. 用法
6.1. Procedures at the UA
6.1. UAの手順
The UA performs a registration as usual. The REGISTER response may contain a Service-Route header field. If so, the UA MAY store the value of the Service-Route header field in an association with the address-of-record for which the REGISTER transaction had registered a contact. If the UA supports multiple addresses-of-record, it may be able to store multiple service routes, one per address-of-record. If the UA refreshes the registration, the stored value of the Service- Route is updated according to the Service-Route header field of the latest 200 class response. If there is no Service-Route header field in the response, the UA clears any service route for that address- of-record previously stored by the UA. If the re-registration request is refused or if an existing registration expires and the UA chooses not to re-register, the UA SHOULD discard any stored service route for that address-of-record.
UAは通常通りの登録を実行します。 REGISTER応答はService-ルートヘッダーフィールドを含むかもしれません。 そうだとすれば、UA MAYはREGISTER取引が接触を登録した記録されている住所との協会でのService-ルートヘッダーフィールドの値を格納します。 UAが記録の複数のアドレスをサポートするなら、複数のサービスルート、1記録されている住所あたり1つを格納できるかもしれません。 UAが登録をリフレッシュするなら、最新の200クラス応答のService-ルートヘッダーフィールドに従って、Serviceルートの格納された値をアップデートします。 応答にService-ルートヘッダーフィールドが全くなければ、UAは以前にUAによって格納された記録のそのアドレスのためにどんなサービスルートもきれいにします。 再登録要求が拒否されるか、既存の登録が期限が切れて、またはUAが、再登録しないのを選ぶなら、UA SHOULDはその記録されている住所のためにどんな格納されたサービスルートも捨てます。
The UA MAY choose to exercise a service route for future requests associated with a given address-of-record for which a service route is known. If so, it uses the content of the Service-Route header field as a preloaded Route header field in outgoing initial requests [3]. The UA MUST preserve the order, in case there is more than one Service-Route header field or header field value.
UA MAYは、サービスルートが知られている与えられた記録されている住所に関連している今後の要求のためのサービスルートを運動させるのを選びます。 そうだとすれば、それはプレロードされたRouteヘッダーフィールドとして送信する初期の要求[3]でService-ルートヘッダーフィールドの内容を使用します。 1つ以上のService-ルートヘッダーフィールドかヘッダーフィールド値があるといけないので、Uaはオーダーを保存しなければなりません。
Loose routes may interact with routing policy in interesting ways. The specifics of how the service route set 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 service route set is appended to any locally configured route needed to egress the access proxy chain. Systems designers must match the service routing policy of their nodes with the basic SIP routing policy in order to get a workable system.
ゆるいルートはおもしろい方法でルーティング方針と対話するかもしれません。 サービスルートセットがどうどんな局所的に必要なデフォルトルートとローカルの方針とも統合されるかに関する詳細は実現に依存しています。 例えば、いくつかの装置が次のホッププロキシに届くのに局所的に構成された明白なゆるいルーティングを使用するでしょう、そして、他のものはデフォルト外国行きのプロキシルーティング規則を使用するでしょう。 しかしながら、結果が機能するように、組み合わせは有効なルーティングを地方の環境に提供しなければなりません。 一般に、アクセスプロキシがチェーニングする出口に必要であるどんな局所的に構成されたルートにもサービスルートセットを追加します。 システム設計者は、実行可能なシステムを手に入れるために彼らのノードのサービスルーティング方針を基本的なSIPルーティング方針に合わせなければなりません。
6.2. Procedures at the Proxy
6.2. プロキシにおける手順
The Service-Route header field is generally treated like any other unknown header field by intermediate proxies. They simply forward it on towards the destination. Note that, as usual, intermediate proxies that need to be traversed by future requests within a dialog may record-route. Proxies should not assume that they will be traversed by future requests in a dialog simply because they appear in the Service-Route header field.
一般に、Service-ルートヘッダーフィールドは中間的プロキシによるいかなる他の未知のヘッダーフィールドのようにも扱われます。 彼らは単にそれを送ります。目的地に向かってオンです。 必要があるいつものように中間的なプロキシが対話の中の要求が記録して発送するかもしれない未来で横断されることに注意してください。 プロキシは、彼らが単にService-ルートヘッダーフィールドに現れるので対話における今後の要求で横断されると仮定するべきではありません。
Willis & Hoeneisen Standards Track [Page 6] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[6ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
There is a question of whether proxies processing a REGISTER response may add themselves to the route set in the Service-Route header field. While this would enable dynamic construction of service routes, it has two significant problems. The first is one of transparency, as seen by the registrar: Intermediate proxies could add themselves without the knowledge or consent of the registrar. The second problem is interaction with end-to-end security. If the registrar uses S/MIME techniques to protect the REGISTER response, such additions would be visible to the UA as "man in the middle" alterations in the response. Consequently, intermediate proxies SHOULD NOT alter the value of Service-Route in REGISTER responses, and if they do, the UA MUST NOT be required to accept the alteration.
REGISTER応答を処理するプロキシがService-ルートヘッダーフィールドで設定されたルートに自分たちを追加するかもしれないかどうかに関する質問があります。 これはサービスルートのダイナミックな構造を可能にするでしょうが、それには. 1番目が1であることのうちの、透明の2つの重大な問題があります、記録係によって見られるように: 中間的プロキシは記録係の知識も同意なしで自分たちを加えることができました。 2番目の問題は終わりから終わりへのセキュリティとの相互作用です。 記録係がREGISTER応答を保護するのにS/MIMEのテクニックを使用するなら、そのような追加は応答における「中央の男性」変更としてUAに目に見えるでしょう。 その結果、中間的プロキシSHOULD NOTはREGISTER応答における、Service-ルートの値を変更します、そして、そうするなら、Uaは変更を受け入れてはいけません。
Additional considerations apply if a proxy is "dual homed", meaning connected to two (or more) different networks such that requests are received on one interface and proxied out through another network interface. Proxies implementing multi-homing precisely as documented in [3] record-route a request with the sending interface. When processing the reply, they replace the Record-Route header field value that represents the interface onto which they proxied the request with a new value that represents the interface onto which they will proxy the response. Consequently, the route vector seen at the User Agent Server (UAS) is not the exact inverse of the route vector seen at the User Agent Client (UAC). While in itself harmless, this complicates matters for nodes that use the recorded route vector (or recorded Path vector as per [4]) in the determination of a service route for future use.
プロキシが適用するなら追加問題が適用される、「二元的である、家へ帰り、」、意味は、要求が1つのインタフェースに受け取られて、別のネットワーク・インターフェースを通した外でproxiedされるように、2つ(さらに)の異なったネットワークに接続しました。 まさに[3]に記録されるようにマルチホーミングを実行するプロキシが送付インタフェースがある要求を記録して発送します。 回答を処理するとき、彼らはそれらがそれらがそうするインタフェースを表す新しい値で要求をproxiedしたインタフェースを表すヘッダーフィールドが評価するRecord-ルートプロキシのために応答を取り替えます。 その結果、UserエージェントServer(UAS)で見られたルートベクトルはUserエージェントClient(UAC)で見られたルートベクトルの正確な逆ではありません。 本来無害ですが、これは記録されたルートベクトルを使用するノードのために件を複雑にします。(または、未来の使用のためのサービスルートの決断における[4])に従って記録されたPathベクトル。
Instead of following the procedure in [3], proxies used with Service-Route that are inserting Record-Route or Path header field values SHOULD record not one but two route values when processing the request. The first value recorded indicates the receiving interface, and the second indicates the sending interface. When processing the response, no modification of the recorded route is required. This optimization provides for fully invertible routes that can be effectively used in construction of service routes.
要求を処理するとき、[3]、Record-ルートを挿入しているService-ルートで使用されるプロキシまたはPathヘッダーフィールド値における手順に従うことの代わりに、SHOULDは1ではなく、2つのルート値を記録します。 記録された最初の値は受信インタフェースを示します、そして、2番目は送付インタフェースを示します。 応答を処理するとき、記録されたルートの変更は全く必要ではありません。 この最適化は事実上、サービスルートの構造に使用できるinvertibleルートに完全に備えます。
6.3. Procedures at the Registrar
6.3. 記録係における手順
When a registrar receives a successful REGISTER request, it MAY choose to return one or more Service-Route header field(s) in the 200 class response. The determination(s) of whether to include these header fields(s) into the 200 class response and what value(s) to insert are a matter of local policy and outside the scope of this document.
記録係がうまくいっているREGISTER要求を受け取るとき、それは、200クラス応答における1つ以上のService-ルートヘッダーフィールドを返すのを選ぶかもしれません。 200クラス応答にこれらのヘッダーフィールドを含めるかどうかと、どんな値を挿入したらよいかに関する決断はローカルの方針の問題であり、外部はこのドキュメントの範囲です。
Willis & Hoeneisen Standards Track [Page 7] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[7ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
Having inserted a Service-Route header field or fields, the registrar returns the 200 class response to the UA in accordance with standard procedures.
Service-ルートヘッダーフィールドか野原を挿入したので、標準手続きに応じて、記録係はUAへの200クラス応答を返します。
A REGISTER operation performing a Fetching Bindings (i.e., no Contact header field is present in the request) SHOULD return the same value of Service-Route as returned in the corresponding previous REGISTER response for the address-of-record in question. In some cases, the Service-Route may be dynamically calculated by the registrar rather than stored, and the decision as to whether this route should be recalculated in the event of a Fetching Bindings operation is left to the implementation.
SHOULDが問題の記録されている住所のための前の対応するREGISTER応答で返すようにService-ルートの同じ値を返すFetching Bindings(すなわち、どんなContactヘッダーフィールドも要求に存在していない)を実行するREGISTER操作。 いくつかの場合、Service-ルートは格納されるより記録係によってダイナミックにむしろ計算されるかもしれません、そして、このルートがFetching Bindings操作の場合、再計算されるべきであるかどうかに関する決定は実現に残されます。
Note: A Fetching Bindings operation could be used by the UA to
recover a lost value of Service-Route. Alternatively, a UA in
this situation could just re-REGISTER.
以下に注意してください。 UAは、Service-ルートの無くなっている値を回復するのにFetching Bindings操作を使用できました。 あるいはまた、この状況におけるUAはまさしく再REGISTERをそうすることができました。
Certain network topologies MAY require a specific proxy (e.g., firewall proxy) to be traversed before the home service proxy. Thus, a registrar with specific knowledge of the network topology MAY return more than one Service-Route header field or element in the 200 class response; the order is specified as top-down, meaning the topmost Service-Route entry will be visited first. Such constructions are implementation specific and outside the scope of this document.
あるネットワークtopologiesは、特定のプロキシ(例えば、ファイアウォールプロキシ)が在宅サービスプロキシの前で横断されるのを必要とするかもしれません。 したがって、ネットワーク形態に関する特定の知識をもっている記録係は200クラス応答で1つ以上のService-ルートヘッダーフィールドか要素を返すかもしれません。 最上のService-ルートエントリーが最初に訪問されることを意味して、オーダーはトップダウンとして指定されます。 実現特有であり、このドキュメントの範囲の外でそのような構造。
In general, the Service-Route header field contains references to elements strictly within the administrative domain of the registrar and home service proxy. For example, consider a case where a user leaves the "home" network and roams into a "visited" network. The registrar cannot be assumed to have knowledge of the topology of the visited network, so the Service-Route it returns contains elements only within the home network.
一般に、Service-ルートヘッダーフィールドは記録係と在宅サービスプロキシの管理ドメインの中に厳密に要素の参照を保管しています。 例えば、ユーザが「家」ネットワークを出て、「訪問された」ネットワークに歩き回るケースを考えてください。 記録係には訪問されたネットワークのトポロジーに関する知識があると思うことができないで、それが返すService-ルートはホームネットワークだけの中に要素を含んでいます。
Note that the inserted Service-Route element(s) MUST conform to the syntax of a Route element as defined in [3]. As suggested therein, such route elements MUST include the loose-routing indicator parameter ";lr" for full compliance with [3].
挿入されたService-ルート要素が[3]で定義されるようにRoute要素の構文に一致しなければならないことに注意してください。 「そこに示されるように、そのようなルート要素はゆるいルーティングインディケータパラメタを含まなければならない」; lrする、」 [3]への完全な承諾ために。
Willis & Hoeneisen Standards Track [Page 8] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[8ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
6.4. Examples of Usage
6.4. 用法に関する例
We present an example in the context of the scenario presented in the Background section earlier in this document. The network diagram is replicated below:
私たちは、より早くBackground部に本書では提示されたシナリオの文脈の例を提示します。 ネットワーク図は以下に模写されます:
Scenario
シナリオ
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HSP-----|
UA1----P1-----| |--R-------| | | | P2---| DBMS| | | UA2-----------| |--HSP-----|
6.4.1. Example of Mechanism in REGISTER Transaction
6.4.1. レジスタ取引におけるメカニズムに関する例
This example shows the message sequence for user agent UA1 registering to HOME.EXAMPLE.COM using registrar R. R returns a Service-Route indicating that UA1 may use home service proxy HSP.HOME.EXAMPLE.COM to receive outbound services from HOME.EXAMPLE.COM.
この例は、UA1がHOME.EXAMPLE.COMから出国サービスを受けるのに在宅サービスプロキシHSP.HOME.EXAMPLE.COMを使用するかもしれないのを示しながら記録係R.Rを使用することでHOME.EXAMPLE.COMに登録するのがService-ルートを返すのをユーザエージェントUA1のためのメッセージ系列に示します。
Please note that some header fields (e.g., Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation.
いくつかのヘッダーフィールド(例えば、Content-長さ)とセッション記述が、より短くて願わくはより読み込み可能なプレゼンテーションを提供するために省略されます。
Message sequence for REGISTER returning Service-Route:
REGISTERの戻っているService-ルートへのメッセージ系列:
F1 Register UA1 -> P1
F1レジスタUA1->P1
REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
一口を示してください: 以下を通ってHOME.EXAMPLE.COM一口/2.0 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKcR1ntRAp To: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、From: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは981211呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、…
Willis & Hoeneisen Standards Track [Page 9] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[9ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
F2 Register P1 -> P2
F2はP1->P2を登録します。
REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
一口を示してください: 以下を通ってHOME.EXAMPLE.COM一口/2.0 一口/2.0/UDP P1.VISITED.EXAMPLE.ORG: 5060; ブランチは以下を通ってz9hG4bKlJuB1mcrと等しいです。 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKcR1ntRAp To: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、From: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは981211呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、…
F3 Register P2 -> R
F3はP2->Rを登録します。
REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
一口を示してください: 以下を通ってHOME.EXAMPLE.COM一口/2.0 一口/2.0/UDP P2.HOME.EXAMPLE.COM: 5060; ブランチは以下を通ってz9hG4bKvE0R2l07o2b6Tと等しいです。 一口/2.0/UDP P1.VISITED.EXAMPLE.ORG: 5060; ブランチは以下を通ってz9hG4bKlJuB1mcrと等しいです。 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKcR1ntRAp To: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、From: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは981211呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、…
F4 R executes Register
F4RはRegisterを実行します。
R Stores: For <sip:UA1@HOME.EXAMPLE.COM> Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Rストア: <一口: UA1@HOME.EXAMPLE.COM 、gt;、接触: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt。
F5 R calculates Service Route
F5RはService Routeについて計算します。
In this example, R is statically configured to reference HSP as a service route, and R also knows that P2 is used as the provider edge proxy, so:
この例では、Rはサービスルートとして静的に参照HSPに構成されます、そして、また、RはP2がそのようにプロバイダー縁のプロキシとして使用されるのを知っています:
Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
サービスルート: <一口: P2.HOME.EXAMPLE.COM; <一口: lr>、HSP.HOME.EXAMPLE.COM; lr>。
Willis & Hoeneisen Standards Track [Page 10] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[10ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
F6 Register Response r -> P2
F6は応答r->P2を登録します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T
Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp
To: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=87654
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
. . .
以下を通って一口/2.0 200OK 一口/2.0/UDP P2.HOME.EXAMPLE.COM: 5060; ブランチは以下を通ってz9hG4bKvE0R2l07o2b6Tと等しいです。 一口/2.0/UDP P1.VISITED.EXAMPLE.ORG: 5060; ブランチは以下を通ってz9hG4bKlJuB1mcrと等しいです。 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKcR1ntRAp To: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、;=87654From:にタグ付けをしてください 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは981211呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、サービスルート: <一口: P2.HOME.EXAMPLE.COM; lr>、<一口: HSP.HOME.EXAMPLE.COM; lr>…
F7 Register Response P2 -> P1
F7は応答P2->P1を登録します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp
To: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=87654
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
. . .
以下を通って一口/2.0 200OK 一口/2.0/UDP P1.VISITED.EXAMPLE.ORG: 5060; ブランチは以下を通ってz9hG4bKlJuB1mcrと等しいです。 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKcR1ntRAp To: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、;=87654From:にタグ付けをしてください 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは981211呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、サービスルート: <一口: P2.HOME.EXAMPLE.COM; lr>、<一口: HSP.HOME.EXAMPLE.COM; lr>…
F8 Register Response P1 -> UA1
F8は応答P1->UA1を登録します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp
To: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=87654
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
. . .
以下を通って一口/2.0 200OK 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKcR1ntRAp To: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、;=87654From:にタグ付けをしてください 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは981211呼び出しIDと等しいです: 843817637684230@998sdasdh09 CSeq: 1826は接触を登録します: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、サービスルート: <一口: P2.HOME.EXAMPLE.COM; lr>、<一口: HSP.HOME.EXAMPLE.COM; lr>…
F9 UA1 stores service route for UA1@HOME.EXAMPLE.COM
F9 UA1は UA1@HOME.EXAMPLE.COM のためにサービスルートを格納します。
Willis & Hoeneisen Standards Track [Page 11] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[11ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
6.4.2. Example of Mechanism in INVITE Transaction
6.4.2. 招待取引におけるメカニズムに関する例
This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2 using outbound services from HOME.EXAMPLE.COM. UA1 has previously registered with HOME.EXAMPLE.COM and been informed of a service route through HSP.HOME.EXAMPLE.COM. The service being provided by HOME.EXAMPLE.COM is a "logging" service, which provides a record of the call for UA1's use (perhaps the user of UA1 is an attorney who bills for calls to customers).
この例は結局HOME.EXAMPLE.COMから出国サービスを使用することでUA2に到着するUA1から発するINVITE取引のためにメッセージ系列を示しています。 UA1は以前に、HOME.EXAMPLE.COMとともに記名して、HSP.HOME.EXAMPLE.COMを通したサービスルートにおいて知識があります。 HOME.EXAMPLE.COMによって提供されるサービスが「伐採」サービスである、(恐らく、UA1のユーザが弁護士である、だれ、顧客への呼び出しのための請求書)。サービスは呼び出しに関する記録をUA1の使用に提供します。
Note that in this example UA1 and UA2 are assumed to be registered with the same network (HOME.EXAMPLE.COM). This does not generally need to be the case to use the herein described service route mechanism.
この例では、UA1とUA2によって同じネットワーク(HOME.EXAMPLE.COM)に登録されると思われることに注意してください。 一般に、これは、ここに説明されたサービスルートメカニズムを使用するのにケースである必要がありません。
Message sequence for INVITE using Service-Route:
Service-ルートを使用するINVITEのためのメッセージ系列:
F1 Invite UA1 -> P1
F1はUA1->P1を招待します。
INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7
To: Customer <sip:UA2@HOME.EXAMPLE.COM>
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248
Call-ID: 38615183343@s1i1l2j6u
CSeq: 18 INVITE
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
. . .
INVITE一口: UA2@HOME.EXAMPLE.COM SIP/2.0Via: 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKnashds7To: 顧客<一口: UA2@HOME.EXAMPLE.COM 、gt;、From: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは456248呼び出しIDと等しいです: 38615183343@s1i1l2j6u CSeq: 18 接触を招いてください: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、ルート: <一口: P2.HOME.EXAMPLE.COM; lr>、<一口: HSP.HOME.EXAMPLE.COM; lr>…
Note: P1 is selected using the "outbound proxy" rule in UA1.
以下に注意してください。 P1は、UA1の「外国行きのプロキシ」規則を使用することで選択されます。
F2 Invite P1 -> P2
F2はP1->P2を招待します。
INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0
Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7
To: Customer <sip:UA2@HOME.EXAMPLE.COM>
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248
Call-ID: 38615183343@s1i1l2j6u
CSeq: 18 INVITE
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr>
Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
. . .
INVITE一口: UA2@HOME.EXAMPLE.COM SIP/2.0Via: 一口/2.0/UDP P1.VISITED.EXAMPLE.ORG: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKnashds7To: 顧客<一口: UA2@HOME.EXAMPLE.COM 、gt;、From: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは456248呼び出しIDと等しいです: 38615183343@s1i1l2j6u CSeq: 18 接触を招いてください: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、記録的なルート: <一口: P1.VISITED.EXAMPLE.ORG; lr>ルート: <一口: P2.HOME.EXAMPLE.COM; lr>、<一口: HSP.HOME.EXAMPLE.COM; lr>…
Willis & Hoeneisen Standards Track [Page 12] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[12ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
Note: P1 has added itself to the Record Route.
以下に注意してください。 P1はRecord Routeにそれ自体を加えました。
F3 Invite P2 -> HSP
F3はP2->HSPを招待します。
INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer <sip:UA2@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Record-Route: <sip:P2.HOME.EXAMPLE.COM;lr> Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr> Route: <sip:HSP.HOME.EXAMPLE.COM;lr> . . .
INVITE一口: UA2@HOME.EXAMPLE.COM SIP/2.0Via: 一口/2.0/UDP P2.HOME.EXAMPLE.COM: 5060; ブランチは以下を通ってz9hG4bKiokioukju908と等しいです。 一口/2.0/UDP P1.VISITED.EXAMPLE.ORG: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKnashds7To: 顧客<一口: UA2@HOME.EXAMPLE.COM 、gt;、From: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは456248呼び出しIDと等しいです: 38615183343@s1i1l2j6u CSeq: 18 接触を招いてください: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、記録的なルート: <一口: P2.HOME.EXAMPLE.COM; lrの>の記録的なルート: <一口: P1.VISITED.EXAMPLE.ORG; lr>ルート: <一口: HSP.HOME.EXAMPLE.COM; lr>…
Note: HSP is selected using a DNS lookup for HSP within HOME.EXAMPLE.COM. P2 has added itself to the Record-Route. P2 has removed itself from the Route.
以下に注意してください。 HSPは、HSPにHOME.EXAMPLE.COMの中でDNSルックアップを使用することで選択されます。 P2はRecord-ルートにそれ自体を追加しました。 P2はRouteから立ち退きました。
F4 HSP executes service
F4 HSPはサービスを実行します。
HSP identifies the service to be executed from UA1's stored profile. The specifics of this are outside the scope of this document. For this example HSP writes a record to "Lawyer's log book", then looks up the AOR "sip:UA2@HOME.EXAMPLE.COM" and discovers that the current contact for UA2 is at host UAADDR2.HOME.EXAMPLE.COM. This will be the Request-URI of the next-hop INVITE.
HSPは、UA1の格納されたプロフィールから実行されるためにサービスを特定します。 このドキュメントの範囲の外にこの詳細があります。 この例に関しては、HSPは、「弁護士の航海日誌」、AORへの当時の一見への「一口: UA2@HOME.EXAMPLE.COM 」という記録を書いて、UA2に関する現在の接触がホストUAADDR2.HOME.EXAMPLE.COMにあると発見します。 これは次のホップINVITEのURIにRequest-なるでしょう。
F5 Invite HSP -> P2
F5はHSP->P2を招待します。
INVITE sip:UA2@UAADDR2.HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/USP HSP.HOME.EXAMPLE.COM:5060;branch=z9hG4bKHSP10120323 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer <sip:UA2@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Record-Route: <sip:HSP.HOME.EXAMPLE.COM;lr> Record-Route: <sip:P2.HOME.EXAMPLE.COM;lr> Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr>
INVITE一口: UA2@UAADDR2.HOME.EXAMPLE.COM SIP/2.0Via: 一口/2.0/USP HSP.HOME.EXAMPLE.COM: 5060; ブランチは以下を通ってz9hG4bKHSP10120323と等しいです。 一口/2.0/UDP P2.HOME.EXAMPLE.COM: 5060; ブランチは以下を通ってz9hG4bKiokioukju908と等しいです。 一口/2.0/UDP P1.VISITED.EXAMPLE.ORG: 5060; ブランチは以下を通ってz9hG4bK34ghi7ab04と等しいです。 一口/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; ブランチ=z9hG4bKnashds7To: 顧客<一口: UA2@HOME.EXAMPLE.COM 、gt;、From: 弁護士<一口: UA1@HOME.EXAMPLE.COM 、gt;、; タグは456248呼び出しIDと等しいです: 38615183343@s1i1l2j6u CSeq: 18 接触を招いてください: <一口: UA1@UADDR1.VISITED.EXAMPLE.ORG 、gt;、記録的なルート: <一口: HSP.HOME.EXAMPLE.COM; lrの>の記録的なルート: <一口: P2.HOME.EXAMPLE.COM; lrの>の記録的なルート: <一口: P1.VISITED.EXAMPLE.ORG; lr>。
Willis & Hoeneisen Standards Track [Page 13] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[13ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
. . .
. . .
Note: P2 selected by outbound proxy rule on HSP. HSP has removed itself from the Route.
以下に注意してください。 外国行きのプロキシによって選択されたP2はHSPの判決を下します。 HSPはRouteから立ち退きました。
INVITE propagates toward UA2 as usual.
INVITEは通常通りのUA2に向かって伝播します。
7. Security Considerations
7. セキュリティ問題
It is possible for proxies between the UA and the registrar during the REGISTER transaction to modify the value of Service-Route returned by the registrar, or to insert a Service-Route even when one was not returned by the registrar. The consequence of such an attack is that future requests made by the UA using the service route might be diverted to or through a node other than would normally be visited. It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore desirable to apply transitive mutual authentication using sips: or other available mechanisms in order to prevent such attacks.
1つが記録係によって返されなかったときさえ、REGISTER取引の間のUAと記録係の間のプロキシが記録係によって返されたService-ルートの値を変更するか、またはService-ルートを挿入するのが可能です。 そのような攻撃の結果がサービスルートを使用することでUAによってされた今後の要求がノードかノードを通して紛らされるかもしれないということである、通常、訪問されるでしょう。 また、INVITE経路のプロキシが多くの異なった攻撃を実行するのも、可能です。 したがって、一口を使用する他動な互いの認証を適用するのは望ましいです: 他の利用可能なメカニズム、そのような攻撃を防いでください。
The "sips:" URI as defined in [3] defines a mechanism by which a UA may request transport-level message integrity and mutual authentication. Since there is no requirement for proxies to modify messages, S/MIME signed bodies may be used to provide end-to-end protection for the returned value.
「一口:」 [3]で定義されるURIはUAが輸送レベルメッセージの保全と互いの認証を要求するかもしれないメカニズムを定義します。 プロキシがメッセージを変更するという要件が全くないので、S/MIMEのサインされた本体は戻り値のための終わりから終わりへの保護を提供するのに使用されるかもしれません。
Systems using Service-Route SHOULD provide hop-by-hop message integrity and mutual authentication. UAs SHOULD request this support by using a "sips:" URI. Registrars returning a Service-Route MUST implement end-to-end protection using S/MIME and SHOULD use S/MIME to protect all such responses. UAs receiving Service-Route SHOULD authenticate attached S/MIME bodies if present.
Service-ルートSHOULDを使用するシステムがホップごとのメッセージの保全と互いの認証を提供します。 UAs SHOULDは、aを使用するこのサポートが「以下をちびちび飲む」よう要求します。 ユリ。 S/MIMEを使用して、Service-ルートを返す記録係は終わりから終わりへの保護を実行しなければなりません、そして、SHOULDはそのようなすべての応答を保護するのにS/MIMEを使用します。 存在しているなら、Service-ルートSHOULDを受けるUAsが付属S/MIME本体を認証します。
Willis & Hoeneisen Standards Track [Page 14] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[14ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
8. IANA Considerations
8. IANA問題
This document defines the SIP extension header field "Service-Route" which has been included in the registry of SIP header fields defined in [3]. The change process for SIP, [5] mandates that general SIP extension header fields be defined by a standards-track RFC. This document provides the required definition.
このドキュメントは[3]で定義されたSIPヘッダーフィールドの登録に含まれているSIP拡張ヘッダー分野「サービスルート」を定義します。 SIPのための変化の過程、[5]は、一般的なSIP拡大ヘッダーフィールドが標準化過程RFCによって定義されるのを強制します。 このドキュメントは必要な定義を提供します。
The following is the registration for the Service-Route header field:
↓これはService-ルートヘッダーフィールドのための登録です:
RFC Number: RFC 3608
RFC番号: RFC3608
Header Field Name: Service-Route
ヘッダーフィールド名: サービスルート
Compact Form: none
コンパクト形: なし
9. Normative References
9. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[2] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[3] 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.
[3] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[4] ウィリス、D.とB.Hoeneisen、「非隣接している接触を登録するためのセッション開始プロトコル(一口)拡大ヘッダーフィールド」RFC3327(2002年12月)。
[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月。
10. Informative References
10. 有益な参照
[6] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol
(SIP)", Work in Progress, October 2002.
[6] ガルシア-マーチン、M.、「第3世代Partnership Project(3GPP)はSession Initiationプロトコル(SIP)に関する5つの要件をリリースします」、ProgressのWork、2002年10月。
Willis & Hoeneisen Standards Track [Page 15] RFC 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[15ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
11. Intellectual Property Statement
11. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
12. Authors' Addresses
12. 作者のアドレス
Dean Willis dynamicsoft Inc. 3100 Independence Parkway #311-164 Plano, TX 75075 US
ディーンウィリスdynamicsoft Inc.3100Independenceパークウェイテキサス75075#311-164プラノ(米国)
Phone: +1 972 473 5455 EMail: dean.willis@softarmor.com
以下に電話をしてください。 +1 5455年の972 473メール: dean.willis@softarmor.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 3608 SIP Extension for Service Route Discovery October 2003
ウィリスとHoeneisen標準化過程[16ページ]RFC3608はルート発見2003年10月にサービスのための拡大をちびちび飲みます。
13. Full Copyright Statement
13. 完全な著作権宣言文
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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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ページ]
一覧
スポンサーリンク
