[要約] RFC 3608は、SIPの拡張ヘッダーフィールドであるService Route Discovery During Registrationに関するものです。このRFCの目的は、SIPの登録中にサービスルートの発見を可能にするための拡張機能を提供することです。
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
セッション開始プロトコル（SIP）登録中のサービスルート発見のための拡張ヘッダーフィールド
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、レジスタリクエストへの応答と併せて使用されるセッション開始プロトコル（SIP）拡張ヘッダーフィールドを定義します。これにより、レジストラがUAがアウトバウンドを要求するために使用できるサービスルートの登録ユーザーエージェント（UA）に通知できるメカニズムを提供することができます。レジストラのドメインからのサービス。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
第3世代のパートナーシッププロジェクト（3GPP）は、SIP登録中に家のプロキシを発見するための要件を確立し、[6]でこの要件を公開しました。3GPPネットワークは、各住所（AOR）にホームサービスプロキシを動的に割り当てます。この割り当ては、登録操作と組み合わせて発生し、必要に応じて、録音住所に登録がない場合にコールサービスをサポートするために必要に応じて発生する場合があります。このホームサービスプロキシは、インバウンド（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）は、ホームサービスプロキシに関連付けられたユーザーの録音アドレスと一致します。ホームサービスプロキシは、（ほとんどの場合）その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ネットワークでのインバウンドリクエストのために行われる可能性のあるホームネットワークでのルックアップテーブルの使用。これは、データベース操作の点で比較的高いオーバーヘッドを持っています。
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にそのルートを保存し、UAから発信される将来のリクエストでサービスルートとして再利用します。効率的ですが、これにより、プロキシ操作のサービスルートがレジスタメッセージで取られたルートと一致するように制約します。
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. レジスタ応答のヘッダーフィールドの値としてサービスルート情報を返す。以前の代替品と同様ですが、このアプローチは、レジストラがサービスルートの構築においてホームネットワークのトポロジに関する知識を選択的に適用する能力を付与します。
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.
このドキュメントでは、この最終的な代替案を定義します。これは、レジスタ応答のヘッダーフィールドとしてサービスルート情報を返すことです。この新しいヘッダーフィールドは、レジストラに関連付けられているプロキシネットワークからサービスを要求する場合、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、およびデータベースDBMを含む「ホームネットワーク」があります。P2は、SIPの観点からホームネットワークの「エッジ」を表し、「エッジプロキシ」と呼ばれる場合があります。UA1は、プロキシP1の背後にある外部UAです。UA1は、動的ホスト構成プロトコル（DHCP）を介してP1を発見します（これは単なる例であり、DHCP以外の他のメカニズムが可能です）。UA2はインターネット上の別のUAであり、デフォルトのアウトバウンドプロキシを使用しません。この図にはドメイン名システム（DNS）要素を表示しませんが、議論における合理的な可用性を想定します。ミッションは、UA1がHSPを発見することで、UA1からのアウトバウンド要求がHSPを通じて（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?"
UASには、最初の要求にルートヘッダーフィールドを含めることができます。その要求を強制的に訪問することを強制し、1つ以上のプロキシによってサービスを受ける可能性があります。このようなルート（「サービスルート」または「プリロードルート」と呼ばれる）を使用すると、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で使用する場合、そのレジストラに関連付けられたプロキシまたはプロキシのセットからサービスを提供するサービスルートをUAに通知することができます。サービスルートヘッダーフィールドは、レジスタリクエストへの応答にレジストラが含めることができます。その結果、登録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のサービスルートを生成し、各成功したレジスタリクエストへの応答でそれを返します。このサービスルートには、登録UAがレジストラが選択したサービスプロキシを介してリクエストを送信するために使用できるルートヘッダーフィールドの形式があります。UAは、Service Proxyを介したルーティングを目的とした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.
レジストラがヘッダーフィールド値を構築するメカニズムは、ローカルの実装に固有のものであり、このドキュメントの範囲外です。
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. レジストラは、合理的なサービスルートを構築できるように、ネットワークトポロジ、ポリシー、および状況について十分な知識を持っています。
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にサービスルートを通知することができる他の方法も利用できる場合があります。このような代替方法は、このドキュメントの範囲外です。登録中にサービスルートを割り当てたいのか、またはそうすることが適切な場合には、このドキュメントの範囲外である理由についての議論。
The syntax for the Service-Route header field is:
サービスルートヘッダーフィールドの構文は次のとおりです。
Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)
service-route = "service-route" hcolon sr-value *（comma sr-value）
sr-value = name-addr *( SEMI rr-param )
sr-value = name-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]で定義されているように、サービスルートヘッダーフィールド値は、ルート要素の構文に適合する必要があることに注意してください。そこに示唆されているように、そのような値には、[3]を完全に遵守するために、ルーズルーティングインジケータパラメーター "; lr"を含める必要があります。
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]の表2および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は通常どおり登録を実行します。レジスタ応答には、サービスルートヘッダーフィールドが含まれる場合があります。その場合、UAは、レジスタトランザクションが連絡先を登録したレコードアドレスと関連性に関連付けられているサービスルートヘッダーフィールドの値を保存することができます。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]で、サービスルートヘッダーフィールドのコンテンツをプリロードされたルートヘッダーフィールドとして使用します[3]。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.
ルーズルートは、興味深い方法でルーティングポリシーと対話する場合があります。サービスルートセットがローカルに必要なデフォルトルートと統合され、ローカルポリシーが実装に依存する方法の詳細。たとえば、一部のデバイスは、ローカルに構成された明示的なルーズルーティングを使用してNext-Hopプロキシに到達し、他のデバイスはデフォルトのアウトバウンドプロキシルーティングルールを使用します。ただし、機能するためには、組み合わせはローカル環境で有効なルーティングを提供する必要があります。一般に、サービスルートセットは、アクセスプロキシチェーンを脱出するために必要なローカルで構成されたルートに追加されます。システム設計者は、実行可能なシステムを取得するために、ノードのサービスルーティングポリシーを基本的な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.
サービスルートヘッダーフィールドは、一般に、中間プロキシによって他の未知のヘッダーフィールドと同様に扱われます。彼らは単に目的地に向かって転送します。いつものように、ダイアログ内の将来のリクエストによって移動する必要がある中間プロキシは、記録的なルートになる可能性があることに注意してください。プロキシは、サービスルートヘッダーフィールドに表示されるという理由だけで、ダイアログ内の将来のリクエストによって通過すると想定すべきではありません。
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.
登録応答の処理プロキシが、サービスルートヘッダーフィールドのルートセットに自分自身を追加する可能性があるかどうかという疑問があります。これにより、サービスルートの動的な構築が可能になりますが、2つの重大な問題があります。1つ目は、レジストラで見られるように、透明性の1つです。中級プロキシは、レジストラの知識や同意なしに自分自身を追加することができます。2番目の問題は、エンドツーエンドのセキュリティとの相互作用です。レジストラがS/MIMEテクニックを使用してレジスタの応答を保護する場合、そのような追加がUAに応答の「中央の男」の変更として表示されます。したがって、中間プロキシはレジスタ応答のサービスルートの価値を変えるべきではなく、もしそうなら、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.
プロキシが「デュアルホーム」である場合、追加の考慮事項が適用されます。つまり、2つの（またはそれ以上）異なるネットワークに接続され、1つのインターフェイスでリクエストが受信され、別のネットワークインターフェイスを介してプロキシが表示されます。[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]の手順に従う代わりに、レコードルートまたはパスヘッダーフィールド値を挿入しているサービスルートで使用されるプロキシは、リクエストの処理時に1つではなく2つのルート値を記録する必要があります。記録された最初の値は、受信インターフェイスを示し、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.
レジストラがレジスタリクエストを成功させると、200クラスの応答で1つ以上のサービスルートヘッダーフィールドを返すことを選択できます。これらのヘッダーフィールドを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.
サービスルートヘッダーフィールドまたはフィールドを挿入したレジストラは、標準手順に従って200クラスの応答をUAに返します。
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.
フェッチングバインディングを実行するレジスタ操作（つまり、リクエストには連絡先ヘッダーフィールドは存在しません）は、問題の住所の対応する以前のレジスタ応答で返されたのと同じサービスの値を返す必要があります。場合によっては、サービスルートは、保存されるのではなくレジストラによって動的に計算される場合があり、このルートがバインディング操作のフェッチが実装された場合に再計算されるかどうかの決定が実装に任されます。
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によって使用されて、サービスルートの失われた価値を回復するために使用できます。あるいは、この状況のUAは再登録するだけです。
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.
一般に、サービスルートヘッダーフィールドには、レジストラおよびホームサービスプロキシの管理領域内で厳密に要素への参照が含まれています。たとえば、ユーザーが「ホーム」ネットワークを離れて「訪問された」ネットワークにローミングする場合を検討してください。レジストラは、訪問されたネットワークのトポロジーに関する知識を持っていると想定できないため、返されるサービスルートにはホームネットワーク内にのみ要素が含まれています。
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]で定義されているように、挿入されたサービスルート要素は、ルート要素の構文に適合する必要があることに注意してください。そこに示唆されているように、そのようなルート要素には、[3]を完全に遵守するために、ルースルーティングインジケーターパラメーター "; lr"を含める必要があります。
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.
この例は、レジストラR.を使用してHome.example.comに登録するユーザーエージェントUA1のメッセージシーケンスを示していますR. Rは、UA1がHOMEサービスhsp.home.example.comを使用してHome.exampleからアウトバウンドサービスを受信できることを示します。.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:
登録済みサービスリットルのメッセージシーケンス：サービスルート：
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> . . .
SIPを登録：HOME.example.com SIP/2.0 Via：SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060; BRANCH=Z9HG4BKCR1NTRAP TO：UA1@HOME.EXAMPLE.COM>：ua1@home.example.com>; Tag = 981211 Call-ID：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<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> . . .
SIPの登録：HOME.EXAMPLE.COM SIP/2.0 Via：SIP/2.0/UDP P1.Visited.example.org：5060; franch = z9hg4bkljub1mcr経由：sip/2.0/udp uaddr1.visited.example.org:5060;z9hg4bkcr1ntrap to：lawyer <sip：ua1@home.example.com> from：lawyer <sip：ua1@home.example.com>;タグ= 981211コールID：843817637684230@998SDASDH09 CSEQ：1826レジスターコンタクト：<SIP：<SIP：@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> . . .
登録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;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登録連絡先：<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>
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>
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 VIA：SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060; BRANCH = Z9HG4BKVE0R2L07O2B6T VIA：SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG：5060;BRANCH = Z9HG4BKLJUB1MCR：SIP/2.0/2.0/2.0/udp uaddr1.visited.example.org：5060; branch = z9hg4bkcr1ntrap to：lawyer <sip：ua1@home.example.com>; tag = 87654981211 Call-ID：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<sip：ua1@uaddr1.visited.example.org> Service-Route：<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 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：sipyer：ua1@home.example.com>; tag = 87654 from：lawyer <sip：ua1@home.example.com>; tag = 981211 Call-id：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<SIP：UA1@UADDR1.visited.example.org> service-route：<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 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>;タグ= 981211コールID：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<sip：ua1@uaddr1.visited.example.org> service-route：<sip：p2.home.example。com; lr>、<sip：hsp.home.example.com; lr>。。。
F9 UA1 stores service route for UA1@HOME.EXAMPLE.COM6.4.2. Example of Mechanism in INVITE Transaction
F9 UA1 Store Service Route for Ua1@home.example.com 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から発生する招待トランザクションのメッセージシーケンスを示しています。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-routeを使用した招待のためのメッセージシーケンス：
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> . . .
sip：ua2@home.example.com sip/2.0経由：sip/2.0/udp uaddr1.visited.example.org:5060; branch=z9hg4bknashds7へ：customer <sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：sip：home.example.com><sip：ua1@home.example.com>; tag = 456248 call-id：38615183343@s1i1l2j6u cseq：18招待連絡先：<sip：ua1@uaddr1.visited.example.org>ルート：<sip：p2.home。embles.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を招待する：ua2@home.example.com SIP/2.0 Via：SIP/2.0/UDP P1.Visited.example.org:5060; Branch=Z9Hg4BK34GHI7AB04経由：SIP/2.0/UDP UADDR1.VISIED.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：：ua1@uaddr1.visited.example.org> record-route：<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：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>>; Tag = 456248 Call-ID：38615183343@S1I1L2J6U CSEQ：18招待連絡先：<sip：ua1@uaddr1.visited.example.org> Record-route：<sip：p2.home.example.com; lr> Record- Record-ルート：<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にあることを発見します。これは、Next-Hop Inviteのリクエスト-uriになります。
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>
. . .
。。。
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に伝播します。
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.
レジスタトランザクション中にUAとレジストラ間のプロキシが、レジストラが返品したサービスルートの価値を変更したり、レジストラによって返されなかった場合でもサービスルートを挿入することができます。このような攻撃の結果は、サービスルートを使用してUAが行った将来の要求が、通常訪問される以外のノードに転用される可能性があることです。また、多くの異なる攻撃を実行するための招待パスのプロキシも可能です。したがって、SIP：またはそのような攻撃を防ぐために、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.
[3]で定義されている「SIP：」は、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-Routeを使用するシステムは、ホップバイホップメッセージの整合性と相互認証を提供する必要があります。UASは、「sips：」uriを使用して、このサポートを要求する必要があります。サービスルートを返すレジストラは、S/MIMEを使用してエンドツーエンドの保護を実装する必要があり、S/MIMEを使用してそのようなすべての応答を保護する必要があります。UASを受け取るサービスルートは、存在する場合は付属の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.
このドキュメントでは、[3]で定義されているSIPヘッダーフィールドのレジストリに含まれているSIP拡張ヘッダーフィールド「サービスルート」を定義します。SIPの変更プロセス[5]は、一般的なSIP拡張ヘッダーフィールドを標準トラックRFCによって定義することを義務付けています。このドキュメントは、必要な定義を提供します。
The following is the registration for the Service-Route header field:
以下は、サービスルートヘッダーフィールドの登録です。
RFC Number: RFC 3608
RFC番号：RFC 3608
Header Field Name: Service-Route
ヘッダーフィールド名：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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[2] Postel、J。およびJ. Reynolds、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、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] Willis、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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J.、およびB. Rosen、「セッション開始プロトコルの変更プロセス（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] Garcia-Martin、M。、「セッション開始プロトコル（SIP）の第3世代パートナーシッププロジェクト（3GPP）リリース5要件」、2002年10月、作業進行中。
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
ディーン・ウィリス・ダイナミクス・インク3100インディペンデンス・パークウェイ＃311-164プラノ、テキサス州75075米国
Phone: +1 972 473 5455
EMail: dean.willis@softarmor.com
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland
Phone: +41 1 268 1515
EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。