Network Working Group D. Willis
Request for Comments: 3608 dynamicsoft Inc.
Category: Standards Track B. Hoeneisen
Switch
October 2003
Session Initiation Protocol (SIP) Extension Header Field
for Service Route Discovery During Registration
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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）を通知することができるメカニズムを提供する要求を登録する応答と関連して使用されるセッション開始プロトコル（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
11. Intellectual Property Statement. . . . . . . . . . . . . . . 16
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
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.
第三世代パートナーシッププロジェクト（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要求の要求-URI（Uniform Resource Identifier）は、アドレスのレコードホームサービスプロキシに関連付けられたユーザーの一致します。 （ほとんどの場合）、ホームサービスプロキシは、その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.
UA 1.コンフィギュレーション・データ。これは、プロキシ割り当ては、ロードバランシングのシナリオのように、非常にダイナミックである場合は特に、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.
ホームネットワーク内の構成サーバーから構成データを取得するための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.
いくつかの3Gネットワークでのインバウンド要求に対して行うことができるよう、ホームネットワーク内のルックアップテーブルの3.、。これは、データベース操作の面で比較的高いオーバーヘッドがあります。
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を処理する上流ノード（表向きUA）を引き起こす、新しい連絡先としてサービスプロキシを示す302応答を返します。これは、前の代替のデータベース操作を共有しながら、それが明示的にそれによって潜在的にデータベース操作の頻度と数を減らす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由来将来の要求にサービスルートとしてそれを再利用する、UAと関連するレジストラの間のREGISTERトランザクションでルーティングを記録する操作と等価を行います。効率のよいが、これは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-----|
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.
このシナリオでは、RとHSPの両方で使用されるルーティングプロキシP2、レジストラR、ホームサービスプロキシHSP、およびデータベースのDBMSを含む「ホームネットワーク」を持っています。 P2は、SIPの観点から、ホームネットワークの「エッジ」を表し、「エッジプロキシ」と呼ばれるかもしれません。 UA1は、プロキシP1の背後にある外部UAです。 UA1は、動的ホスト構成プロトコル（DHCP）（これは単なる一例であり、DHCP以外の他のメカニズムが可能です）を介してP1を検出します。 UA2は、インターネット上の別のUAで、デフォルトのアウトバウンドプロキシを使用しません。私たちは、この図では、ドメインネームシステム（DNS）の要素を表示しませんが、議論での合理的な利用可能性を想定します。 UA1からの発信要求がそれによってHSPからのアウトバウンドサービスを受け、HSPを介して（UA1の裁量で）送ることができるようにUA1はHSPを発見するための使命です。
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?"
UAは訪問すると、潜在的に一つ以上のプロキシによってサービスされることが要求を強制する初期要求の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に知らせるサービス-Routeヘッダーフィールドを使用してもよいです。サービスルートヘッダーフィールドは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.
サービス・ルートメカニズムによって確立されたルーティングは、ユーザエージェントに送信された要求にのみ適用されます。それはそれだけでUAに要求を発し、そしてないその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は、サービスプロキシを経由することを意図UAによって発信要求にプリロードRouteヘッダーフィールドとして挿入することによってこの経路を使用します。
The mechanism by which the registrar constructs the header field value is specific to the local implementation and outside the scope of this document.
レジストラは、ヘッダフィールド値を構成するメカニズムは、ローカルの実装に、この文書の範囲外に特異的です。
The Service-Route mechanism is applicable when:
サービス・ルート・メカニズムは、該当する場合です：
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によって使用されるサービス・プロキシの知識を持っています。この知識は、動的な割り当て、またはこの文書の範囲外のいくつかの他のメカニズムの結果であり得ます。
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.レジストラ（S）を有する/妥当サービス経路を構築することができるように、ネットワークトポロジ、ポリシー、および状況の十分な知識を有しています。
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.
UAにサービスルートを提案する5.その他のメカニズムが利用できないか、または特定の環境内での使用のために不適切です。
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がサービスルートが通知されるかもしれない利用できます。そのような代替的な方法は、この文書の範囲外です。そうすることが適切であるかもしれないとき、一方または登録時にサービスルートを割り当てるかもしれない理由の説明は、この文書の範囲外です。
The syntax for the Service-Route header field is:
サービス-Routeヘッダーフィールドの構文は次のとおりです。
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].
[3]で定義されるようにサービスルートヘッダフィールド値をルート要素の構文に準拠しなければならないことに留意されたいです。 「; 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.
ヘッダフィールドの許容使用量を表2及び[3]の3に記載されています。この表に以下の追加はサービス・ルートのために必要とされます。
Addition of Service-Route to SIP Table 3:
SIPの表3にサービス・ルートの追加：
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Service-Route 2xx ar - - - - - o -
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応答はサービスルートヘッダフィールドを含んでいてもよいです。そうである場合、UAは、REGISTERトランザクションが接触を登録した対象のアドレスのレコードに対応付けてサービスルートヘッダフィールドの値を格納することができます。 UAは、複数のアドレス・オブ・レコードをサポートしている場合、アドレスのレコードごとに、複数のサービスのルートを格納することができます。 UAが登録をリフレッシュする場合は、サービスルートの格納された値は、最新の200クラス応答のサービスルートヘッダフィールドに応じて更新されます。応答にはサービスルートヘッダフィールドが存在しない場合、UAは、UAによって以前格納されたアドレスのレコードのための任意のサービス経路をクリアします。再登録要求は拒否されたり、既存の登録の有効期限が切れると、UAは再登録しないことを選択した場合、UAはそのアドレス・オブ・レコードの任意の保存されたサービスルートを破棄するかどうか。
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は、サービスルートが知られているために与えられたアドレスのレコードに関連した将来の要求のためのサービスルートを行使することを選択するかもしれません。もしそうなら、それは発信初期要求[3]におけるプリロードRouteヘッダフィールドとしてサービスルートヘッダフィールドの内容を使用します。 UAは、複数のサービス-Routeヘッダーフィールドまたはヘッダフィールド値が存在する場合には、順序を保持しなければなりません。
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ルーティングポリシーとそのノードのサービスルーティングポリシーと一致する必要があります。
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.
サービスルートヘッダフィールドは、一般的に、中間プロキシによって、他の未知のヘッダフィールドと同様に扱われます。彼らは単に目的地に向けてそれを転送します。いつものように、ダイアログ内の将来の要求によって横断する必要がある中間プロキシがレコードルートを可能性があることに注意してください。プロキシは、彼らがサービス-Routeヘッダーフィールドに現れるという理由だけで、ダイアログの今後のリクエストによって横断されることを仮定するべきではありません。
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応答を処理するプロキシがサービス-Routeヘッダーフィールドに設定されたルートに自分自身を追加することかどうかの質問があります。これは、サービスルートの動的な構築を可能にするだろうが、それは二つの重要な問題があります。レジストラで見られるように最初は、透明性の一つである：中間プロキシは、レジストラの知識や同意なしに自分自身を追加することができます。第二の問題は、エンドツーエンドのセキュリティとの相互作用です。レジストラは、REGISTER応答を保護するために、S / MIME技術を使用している場合、そのような添加は応答の変化「中間者」としてUAに見えるであろう。その結果、中間プロキシはREGISTER応答のサービス・ルートの値を変化させてはならない、と彼らがしなければ、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つのインターフェイスで受信し、別のネットワーク・インタフェースを介してプロキシされるように2つ（またはそれ以上）の異なるネットワークに接続されている意味、「デュアル・マルチホーム」である場合は、追加の考慮事項が適用されます。送信インターフェースと[3]のレコードルート要求に記載されるように正確マルチホーミングを実現するプロキシ。応答を処理するとき、彼らはその上にそれらが代理応答をするインターフェイスを表す新しい値を持つリクエストをプロキシその上にインタフェースを表すレコードルートヘッダフィールド値を置き換えます。これにより、ユーザエージェントサーバ（UAS）で見られるルートベクトルはユーザエージェントクライアント（UAC）で見られる経路ベクトルの正確な逆数ではありません。それ自体では無害が、これは将来の使用のためのサービス経路の決意に（[4]に従って、又は記録されたパスベクトル）を記録ルートベクターを使用するノード事項を複雑にします。
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]の手順に従って要求を処理するとき、レコードルートまたはパスヘッダフィールド値を挿入しているサービス・ルートに使用されるプロキシは一つではなく2つのルートの値を記録する必要があります。記録された最初の値は、受信インタフェースを示し、第二は、送信インタフェースを示します。応答を処理するときに、記録された経路の修正が必要とされません。この最適化は効果的にサービスルートの構築に使用することができ、完全に可逆ルートを提供します。
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つまたは複数のサービス-Routeヘッダーフィールド（複数可）を返すために選ぶかもしれません。挿入するために、200クラス応答とどのような値（複数可）に、これらのヘッダフィールド（複数可）を含めるかどうかの決意（単数または複数）は、ローカルポリシーのこの文書の範囲外の問題です。
Having inserted a Service-Route header field or fields, the registrar returns the 200 class response to the UA in accordance with standard procedures.
サービスルートヘッダフィールドまたはフィールドを挿入したが、レジストラは、標準的な手順に従って、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.
アドレス・オブ・レコード問題のための対応する前REGISTER応答で返されるフェッチバインディングを行うレジスタ動作（すなわち、NO接点ヘッダーフィールドがリクエスト中に存在していない）サービス・ルートの同じ値を返す必要があります。いくつかのケースでは、サービスルートを動的に格納されているのではなく、レジストラによって計算することができる、そしてこのルートがフェッチバインディング操作の際に再計算されるべきかどうかの決定は、実装に委ねられます。
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によって使用することができます。また、このような状況ではUAがjust-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.
特定のネットワークトポロジは、ホームサービスプロキシの前に横断するように特定のプロキシ（例えば、ファイアウォール、プロキシ）を必要とするかもしれません。したがって、ネットワーク・トポロジの特定の知識を持つレジストラ200クラス応答して複数のサービスルートヘッダフィールドまたは要素を返すかもしれ。一番上のサービス・ルートエントリを意味するトップダウンは、最初に訪問されるように順序が指定されています。このような構造は、実装固有の、このドキュメントの範囲外です。
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.
一般的には、サービス-Routeヘッダーフィールドは、厳密にレジストラとホームサービスプロキシの管理ドメイン内の要素への参照が含まれています。例えば、ユーザが「ホーム」ネットワークを離れると「訪問」ネットワークにローミングする場合を考えます。レジストラは、訪問先ネットワークのトポロジーの知識を持っていると仮定することはできませんので、それは返すサービス-ルートは、ホームネットワーク内の要素が含まれています。
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].
[3]で定義されるように挿入されたサービスルート要素（単数または複数）がルート要素の構文に準拠しなければならないことに留意されたいです。そこに示唆したように、そのような経路要素がルーズルーティングインジケータパラメータを含まなければなりません「; LR」[3]を完全に遵守するため。
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:
私たちは、このドキュメントの背景の項で提示シナリオのコンテキストでの例を提示します。ネットワーク図を以下に複製されます。
Scenario
シナリオ
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HSP-----|
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がレジストラR. RはUA1はHOME.EXAMPLEからアウトバウンドサービスを受信するためにホームサービスプロキシHSP.HOME.EXAMPLE.COMを使用することができることを示すサービス・ルートを返す使用HOME.EXAMPLE.COMに登録するためのメッセージシーケンスを示します.COM。
Please note that some header fields (e.g., Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation.
いくつかのヘッダフィールド（例えば、コンテンツの長さ）とセッション記述が短く、うまくいけば、より読みやすいプレゼンテーションを提供するために省略されていることに注意してください。
Message sequence for REGISTER returning Service-Route:
REGISTERサービス-ルートを返すためのメッセージシーケンス：
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 SIP / 2.0経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRApへ：弁護士<SIP：UA1@HOME.EXAMPLE.COM>から：弁護士<一口：UA1@HOME.EXAMPLE.COM>;タグ= 981211コールID：843817637684230のCSeq 998sdasdh09 @：1826 REGISTER連絡先：<SIP：UA1@UADDR1.VISITED.EXAMPLE.ORG>。 。 。
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 SIP / 2.0経由：SIP / 2.0 / UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch= z9hG4bKcR1ntRApへ：弁護士<SIP：UA1@HOME.EXAMPLE.COM>から：弁護士<SIP：UA1@HOME.EXAMPLE.COM>;タグ= 981211コールID：843817637684230のCSeq 998sdasdh09 @：1826 REGISTER連絡先：<SIP：UA1 @ UADDR1.VISITED.EXAMPLE.ORG>。 。 。
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 SIP / 2.0経由：SIP / 2.0 / UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T経由：SIP / 2.0 / UDP P1.VISITED.EXAMPLE.ORG:5060;branch= z9hG4bKlJuB1mcr経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRApへ：弁護士<SIP：UA1@HOME.EXAMPLE.COM>から：弁護士<SIP：UA1@HOME.EXAMPLE.COM>。タグ= 981211コールID：843817637684230 998sdasdh09 @のCSeq：1826 REGISTER連絡先：<SIP：UA1@UADDR1.VISITED.EXAMPLE.ORG>。 。 。
F4 R executes Register
F4 Rは、登録を実行します
R Stores: For <sip:UA1@HOME.EXAMPLE.COM> Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
R店舗：については<SIP：UA1@HOME.EXAMPLE.COM>連絡先：<SIP：UA1@UADDR1.VISITED.EXAMPLE.ORG>
F5 R calculates Service Route
F5 Rは、サービスルートを算出し、
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>
サービス-ルート：<SIP：P2.HOME.EXAMPLE.COM; LR>、<SIP：HSP.HOME.EXAMPLE.COM; LR>
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> . . .
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T経由：SIP / 2.0 / UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRApへ：弁護士<SIP：UA1@HOME.EXAMPLE.COM>;タグ= 87654から：弁護士<SIP：UA1@HOME.EXAMPLE.COM>;タグ= 981211コールID：843817637684230 998sdasdh09 @のCSeq：1826 REGISTER連絡先：<SIP：UA1@UADDR1.VISITED.EXAMPLE.ORG>サービス-ルート：<SIP：P2.HOME.EXAMPLE.COM; LR>、<SIP：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> . . .
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRApへ：弁護士<一口：UA1@HOME.EXAMPLE.COM>;からタグ= 87654：弁護士<SIP：UA1@HOME.EXAMPLE.COM>;タグ= 981211コールID：843817637684230 998sdasdh09 @のCSeq：1826 REGISTER連絡先：<SIP：UA1 @ UADDR1 .VISITED.EXAMPLE.ORG>サービス-ルート：<SIP：P2.HOME.EXAMPLE.COM; LR>、<SIP：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> . . .
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRApへ：弁護士<SIP：UA1@HOME.EXAMPLE.COM>;からタグ= 87654：弁護士<SIP：UA1 @ HOME.EXAMPLE.COM>;タグ= 981211コールID：843817637684230のCSeq 998sdasdh09 @：1826 REGISTER連絡先：<SIP：UA1@UADDR1.VISITED.EXAMPLE.ORG>サービス-ルート：<SIP：P2.HOME.EXAMPLE。 COM; LR>、<SIP：HSP.HOME.EXAMPLE.COM; LR>。 。 。
F9 UA1 stores service route for UA1@HOME.EXAMPLE.COM
F9 UA1はUA1@HOME.EXAMPLE.COMのためにサービスルートを保存します
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:
サービス・ルートを使用して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 SIP：UA2@HOME.EXAMPLE.COM SIP / 2.0経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7へ：お客様<SIP：UA2@HOME.EXAMPLE.COM>から：弁護士<一口：UA1@HOME.EXAMPLE.COM>; = 456248のCall-IDタグ：s1i1l2j6uのCSeq @ 38615183343：18には、連絡先をINVITE：<SIP：UA1@UADDR1.VISITED.EXAMPLE.ORG>ルート：<SIP：P2.HOME。 EXAMPLE.COM; LR>、<SIP：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> . . .
SIPのINVITE：UA2@HOME.EXAMPLE.COM SIP / 2.0経由：SIP / 2.0 / UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060。ブランチ= z9hG4bKnashds7へ：お客様<SIP：UA2@HOME.EXAMPLE.COM>から：弁護士<SIP：UA1@HOME.EXAMPLE.COM>; = 456248のCall-IDタグ：s1i1l2j6uのCSeq @ 38615183343：18連絡先をINVITE：<SIP ：UA1@UADDR1.VISITED.EXAMPLE.ORG>レコードルート<SIP：P1.VISITED.EXAMPLE.ORG; LR>ルート<SIP：P2.HOME.EXAMPLE.COM; LR>、<SIP：HSP.HOME .example.comと; LR>。 。 。
Note: P1 has added itself to the Record Route.
注意：P1は、レコードのルートに自分自身を追加しました。
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> . . .
SIPのINVITE：UA2@HOME.EXAMPLE.COM SIP / 2.0経由：SIP / 2.0 / UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908経由：SIP / 2.0 / UDP P1.VISITED.EXAMPLE.ORG:5060。ブランチ= z9hG4bK34ghi7ab04経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7へ：お客様<SIP：UA2@HOME.EXAMPLE.COM>から：弁護士<SIP：UA1@HOME.EXAMPLE.COM >;タグ= 456248コールID：38615183343 s1i1l2j6uのCSeq @：18には、連絡先をINVITE：<SIP：UA1@UADDR1.VISITED.EXAMPLE.ORG>レコード・ルート：<SIP：P2.HOME.EXAMPLE.COM; LR>記録的ルート：<SIP：P1.VISITED.EXAMPLE.ORG; LR>ルート：<SIP：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はHOME.EXAMPLE.COM内HSPのためのDNSルックアップを使用して選択されます。 P2は、レコードルートに自分自身を追加しました。 P2は、ルートからの接続を解除しました。
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「SIP：UA2@HOME.EXAMPLE.COM」を検索して、UA2の現在の連絡先がホストUAADDR2.HOME.EXAMPLE.COMであることを発見。これは、ネクストホップの要求URIがINVITEになります。
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>
SIPのINVITE：UA2@UAADDR2.HOME.EXAMPLE.COM SIP / 2.0経由：SIP / 2.0 / USP HSP.HOME.EXAMPLE.COM:5060;branch=z9hG4bKHSP10120323経由：SIP / 2.0 / UDP P2.HOME.EXAMPLE.COM： 5060;ブランチ= z9hG4bKiokioukju908経由：SIP / 2.0 / UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04経由：SIP / 2.0 / UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7へ：カスタマー<一口：UA2@HOME.EXAMPLE.COM>から：弁護士<SIP：UA1@HOME.EXAMPLE.COM>;タグは= 456248コールID：s1i1l2j6uのCSeq @ 38615183343：18連絡先をINVITE：<SIP：UA1@UADDR1.VISITED.EXAMPLE .ORG>レコードルート<SIP：HSP.HOME.EXAMPLE.COM; LR>レコードルート<SIP：P2.HOME.EXAMPLE.COM; LR>レコードルート<SIP：P1.VISITED.EXAMPLE。 ORG; LR>
. . .
。 。 。
Note: P2 selected by outbound proxy rule on HSP. HSP has removed itself from the Route.
注：HSP上のアウトバウンドプロキシルールによって選択されたP2。 HSPはルートからの接続を解除しました。
INVITE propagates toward UA2 as usual.
いつものようにUA2に向かって伝播し、INVITE。
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.
REGISTERトランザクション中にUAとレジストラ間のプロキシがレジストラによって返されたサービス・ルートの値を変更するために、または1つがレジストラによって返されていなかった場合でも、サービス・ルートを挿入することが可能です。このような攻撃の結果は、サービスルートを使ってUAによって行われた将来の要求が、あるいは正常に訪問されるよりも、他のノードを介して流用されるかもしれないということです。 INVITEパス上のプロキシは、さまざまな攻撃を実行することも可能です。そのような攻撃を防ぐために、または他の利用可能なメカニズム：SIPを使用して推移相互認証を適用することが望ましいです。
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.
「一口：」URI [3] 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.
サービス・ルートを使用するシステムは、ホップバイホップメッセージの整合性と相互認証を提供する必要があります。 URI：UAは「一口」を使って、このサポートを要求する必要があります。サービス・ルートを返すレジストラは、S / MIMEを使用して、エンドツーエンドの保護を実装しなければならないし、すべてのそのような応答を保護するためにS / MIMEを使用すべきです。存在する場合サービス-ルートを受け取るUAは、付属のS / MIMEボディを認証する必要があります。
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.
この文書では、SIPの拡張ヘッダフィールド「サービス・ルート」[3]で定義されたSIPヘッダフィールドのレジストリに含まれている定義します。 SIPの変更処理は、[5]一般的なSIP拡張ヘッダフィールドが標準トラックRFCによって定義されることが義務付け。この文書では、必要な定義を提供します。
The following is the registration for the Service-Route header field:
以下は、Service-Routeヘッダーフィールドの登録です。
RFC Number: RFC 3608
RFC番号：RFC 3608
Header Field Name: Service-Route
ヘッダーフィールド名：サービス-ルート
Compact Form: none
コンパクトなフォーム：なし
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[2]ポステル、J.、およびJ.レイノルズ、 "RFC作者への指示"、RFC 2223、1997年10月。
[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.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、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を、 "セッション開始プロトコル（SIP）拡張ヘッダフィールドは非隣接コンタクトを登録するための"、RFC 3327、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.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427 、2002年12月。
[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.、進歩、2002年10月の作業「第三世代パートナーシッププロジェクト（3GPP）は、セッション開始プロトコル（SIP）の5つの要件をリリース」。
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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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専務に情報を扱ってください。
Dean Willis dynamicsoft Inc. 3100 Independence Parkway #311-164 Plano, TX 75075 US
ディーンウィリスdynamicsoft株式会社3100インディパークウェイ＃311から164プラノ、TX 75075米国
Phone: +1 972 473 5455 EMail: dean.willis@softarmor.com
電話：+1 972 473 5455 Eメール：dean.willis@softarmor.com
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland
バーニーHoeneisenはリマト河岸138 CH-8001チューリッヒスイスの切り替え
Phone: +41 1 268 1515 EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org URI: http://www.switch.ch/
電話：+41 1 268 1515 Eメール：hoeneisen@switch.ch、b.hoeneisen@ieee.org URI：http://www.switch.ch/
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。