Network Working Group                                          D. Willis
Request for Comments: 3327                              dynamicsoft Inc.
Category: Standards Track                                   B. Hoeneisen
                                                                  Switch
                                                           December 2002
        
        Session Initiation Protocol (SIP) Extension Header Field
                 for Registering Non-Adjacent Contacts
        

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 (2002). All Rights Reserved.

著作権(C)インターネット協会(2002)。全著作権所有。

Abstract

抽象

The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism.

REGISTER機能は主に、アドレスのレコードとの一時的な連絡先を関連付けるためにセッション開始プロトコル(SIP)システムで使用されています。この接触は、接点としてのURI(Uniform Resource Identifier)の形式で一般的である。<SIP:alice@pc33.atlanta.com>一般的に動的とSIPユーザエージェント(UAのIPアドレスまたはホスト名に関連付けられています)。問題は、ネットワークトポロジが登録UAに、ユーザのホームネットワークから旅任意の要求がこれらのプロキシを通過しなければならないようなUAとレジストラ間の1つのまたは複数のSIPプロキシを、持っていることです。 REGISTERメソッドは、私たちに発見し、将来の使用のためのレジストラにプロキシのこのシーケンスを記録するためのメカニズムを与えるものではありません。この文書では、そのような機構を提供する拡張ヘッダフィールド、「パス」を定義します。

Table of Contents

目次

   1.    Background . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Applicability Statement  . . . . . . . . . . . . . . . . . .  3
   4.    Path Header Field Definition and Syntax  . . . . . . . . . .  3
   5.    Usage of Path Header Field . . . . . . . . . . . . . . . . .  5
   5.1   Procedures at the UA . . . . . . . . . . . . . . . . . . . .  5
   5.2   Procedures at Intermediate Proxies . . . . . . . . . . . . .  5
   5.3   Procedures at the Registrar  . . . . . . . . . . . . . . . .  6
   5.4   Procedures at the Home Proxy . . . . . . . . . . . . . . . .  6
   5.5   Examples of Usage  . . . . . . . . . . . . . . . . . . . . .  7
   5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . .  7
   5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   6.1   Considerations in REGISTER Request Processing  . . . . . . . 13
   6.2   Considerations in REGISTER Response Processing . . . . . . . 14
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
         Normative References . . . . . . . . . . . . . . . . . . . . 16
         Non-Normative References . . . . . . . . . . . . . . . . . . 16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
        
1. Background
1.背景

3GPP established a requirement for discovering intermediate proxies during SIP registration and published this requirement in [5].

3GPPは、SIP登録時に中間プロキシを発見するための要件を確立し、この要求を発行した[5]。

Scenario:

シナリオ:

   UA1----P1-----P2-----P3------REGISTRAR
        

UA1 wishes to register with REGISTRAR. However, due to network topology, UA1 must use P1 as an "outbound proxy", and all requests between UA1 and REGISTRAR must also traverse P1, P2, and P3 before reaching REGISTRAR. Likewise, all requests between REGISTRAR and UA1 must also traverse P3, P2, and P1 before reaching UA1.

UA1は、レジストラに登録することを希望します。しかしながら、ネットワークトポロジに起因し、UA1は、「アウトバウンドプロキシ」としてP1を使用しなければならない、とUA1およびレジストラの間のすべての要求はまたREGISTRARに到達しなければならないトラバースP1、P2、およびP3の前に。同様に、REGISTRARとUA1間のすべての要求にもUA1に到達しなければならトラバースP3、P2、およびP1の前に。

UA1 has a standing relationship with REGISTRAR. How UA1 establishes this relationship is outside the scope of this document. UA1 discovers P1 as a result of configuration, DHCP assignment or other similar operation, also outside the scope of this document. REGISTRAR has a similar "default outbound proxy" relationship with P3.

UA1は、レジストラに立って関係を持っています。どのようにUA1は、この関係を確立することは、この文書の範囲外です。 UA1は、この文書の範囲外で、コンフィギュレーション、DHCP割り当てまたは他の同様の動作の結果として、P1を検出します。レジストラはP3と同様の「デフォルトのアウトバウンドプロキシ」の関係を持っています。

Eventually, REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) closely related to it will receive a request destined for UA1. It needs to know which proxies must be transited by that request in order to get back to UA1. In some cases, this information may be deducible from SIP routing configuration tables or from DNS entries. In other cases, such as that raised by 3GPP, the information is not readily available outside of the SIP REGISTER transaction.

最終的に、レジストラまたは密接にそれに関連した「ホームプロキシ」(アドレスのレコードをルーティングするための終端点となるプロキシは)UA1宛てのリクエストを受信します。それは戻ってUA1に取得するためには、その要求によって遷移しなければならないプロキシを知る必要があります。いくつかの場合において、この情報はSIPルーティング設定テーブルから、またはDNSエントリから推定してもよいです。そのような3GPPにより隆起したそのような他のケースでは、情報は、SIPレジスタトランザクションの外で容易に入手できません。

The Path extension header field allows accumulating and transmitting the list of proxies between UA1 and REGISTRAR. Intermediate nodes such as P1 may statefully retain Path information if needed by operational policy. This mechanism is in many ways similar to the operation of Record-Route in dialog-initiating requests. The routing established by the Path header field mechanism applies only to requests transiting or originating in the home domain.

パス拡張ヘッダフィールドは、蓄積しUA1およびレジストラの間のプロキシのリストを送信することができます。運用ポリシーによって必要に応じて、このようなP1と中間ノードは、ステートフル経路情報を保持してもよいです。このメカニズムは、ダイアログ開始要求で録音・ルートの動作と同様、多くの点です。パスヘッダフィールドメカニズムによって確立されたルーティングが通過するか、ホームドメインに送信された要求にのみ適用されます。

2. Terminology
2.用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[3]。

3. Applicability Statement
3.適用性に関する声明

The Path mechanism is applicable whenever there are intermediate proxies between a SIP UA and a SIP Registrar used by that UA where the following conditions are true:

以下の条件が満たされていることをUAが使用するSIP UAとSIPレジストラの間の中間プロキシが存在するときはいつでもパス機構が適用可能です。

1. One or more of the intermediate proxies are visited by registration requests from the UA to the Registrar. 2. The same intermediate proxies or a set of proxies known to the intermediate proxies must be traversed, in reverse order, by requests sent through a home proxy to the UA. In the simplest form, the route between the home proxy and the UA is the exact inverse of the route between the UA and the route between the UA and the registrar. 3. The network topology is such that the intermediate proxies which must be visited are NOT implied by SIP routing tables, DNS, or similar mechanisms.

中間プロキシの1つ以上は、レジストラへのUAからの登録要求が訪れています。 2.同じ中間プロキシまたは中間プロキシに知られているプロキシのセットは、UAのホームプロキシを介して送信された要求によって、逆の順序で、横断されなければなりません。最も単純な形態では、ホームプロキシとUAとの間の経路は、UAとUAとレジストラとの間の経路の間の経路の正確な逆数です。 3.ネットワークトポロジを訪問しなければならない中間プロキシは、SIPルーティングテーブル、DNS、または同様の機構によって暗示されないようです。

4. Path Header Field Definition and Syntax
4.パスヘッダーフィールドの定義と構文

The Path header field is a SIP extension header field with syntax very similar to the Record-Route header field. It is used in conjunction with SIP REGISTER requests and with 200 class messages in response to REGISTER (REGISTER responses).

Pathヘッダフィールドは、Record-Routeヘッダフィールドに非常に類似した構文を持つSIPの拡張ヘッダフィールドです。これは、SIP REGISTER要求にと(応答をREGISTER)レジスタへの応答で200クラスのメッセージと一緒に使用されます。

A Path header field MAY be inserted into a REGISTER by any SIP node traversed by that request. Like the Route header field, sequential Path header fields are evaluated in the sequence in which they are present in the request, and Path header fields MAY be combined into compound Path header in a single Path header field. The registrar reflects the accumulated Path back into the REGISTER response, and intermediate nodes propagate this back toward the originating UA. The originating UA is therefore informed of the inclusion of nodes on its registered Path, and MAY use that information in other capacities outside the scope of this document.

Pathヘッダフィールドは、その要求が横断する任意のSIPノードによってレジスタに挿入することができます。 Routeヘッダーフィールドのような、シーケンシャルPathヘッダフィールドは、それらがリクエスト中に存在する順序で評価され、パスヘッダフィールドは、単一のパスヘッダフィールド中の化合物Pathヘッダに結合されてもよいです。レジストラは、バックREGISTER応答に蓄積されたパスを反映して、中間ノードは、発信UAに向かって、このバックを伝播します。発信UAは、したがって、その登録された経路上のノードを含めることが通知され、この文書の範囲外の他の能力にその情報を使用することができます。

The difference between Path and Record-Route is that Path applies to REGISTER and 200 class responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatibility. Furthermore, the vector established by Record-Route applies only to requests within the dialog that established that Record-Route, whereas the vector established by Path applies to future dialogs.

パスおよびRecord-ルートとの違いは、そのパスレジスタに適用され、200クラスの応答は、登録することです。レコードルートはない、との後方互換性の理由のためにREGISTERに定義することはできません。また、録音・ルートによって確立されたベクトルは、パスのみによって確立されたベクトルは、将来のダイアログに適用されるのに対し、そのレコード・ルートを確立し、ダイアログ内のリクエストに適用されます。

The syntax for Path is defined as follows:

次のようにパスの構文は定義されています。

Path = "Path" HCOLON path-value *( COMMA path-value )

パス=「パス」HCOLONパス値*(COMMAパス値)

path-value = name-addr *( SEMI rr-param )

パス値=名前-addrには*(SEMI RR-PARAM)

Note that the Path header field values conform to the syntax of a Route element as defined in [1]. As suggested therein, such values MUST include the loose-routing indicator parameter ";lr" for full compliance with [1].

[1]で定義されるようにパスヘッダフィールド値をルート要素の構文に準拠していることに注意してください。 「; LR」に完全に準拠するための[1]そこに示唆したように、このような値は、ルーズルーティングインジケータパラメータを含まなければなりません。

The allowable usage of header fields is described in Tables 2 and 3 of SIP [1]. The following additions to this table are needed for Path.

ヘッダフィールドの許容使用量は、[1] SIPの表2および3に記載されています。この表に以下の追加がパスのために必要とされます。

Support for the Path header field MAY be indicated by a UA by including the option-tag "path" in a Supported header field.

Pathヘッダフィールドのサポートは、サポートされているヘッダフィールドのオプションタグ「パス」を含むことにより、UAによって示すことができます。

Addition of Path to SIP Table 3:

SIPの表3へのパスの追加:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Path                    R       ar   -   -   -   -   -   o
      Path                   2xx       -   -   -   -   -   -   o
        
5. Usage of Path Header Field
パスヘッダーフィールドの使用方法5.
5.1 Procedures at the UA
UAで5.1手順

The UA executes its register operation as usual. The response MAY contain a Path header field. The general operation of the UA is to ignore the Path header field in the response. It MAY choose to display the contents of the Path header field to the user or take other action outside the scope of this document. The Path information in the REGISTER response lets the UA know what intermediate proxies were added during registration. Examination of this information may be important from a security perspective, as such inspection might allow the UA to detect intermediate proxies that have inappropriately added themselves.

UAは、いつものように、そのレジスタの動作を実行します。応答は、Pathヘッダフィールドを含むかもしれません。 UAの一般的な動作は、応答のパスヘッダフィールドを無視することです。これは、ユーザーにPathヘッダフィールドの内容を表示したり、この文書の範囲外で他のアクションを取ることを選ぶかもしれません。 REGISTER応答のパス情報は、UAは、中間プロキシが登録時に追加されたかを知ることができます。この情報の調査は、このような検査はUAが不適切に自分自身を追加した中間プロキシを検出することを可能にするかもしれないとして、セキュリティの観点から重要であるかもしれません。

The UA SHOULD include the option tag "path" as a header field value in all Supported header fields, and SHOULD include a Supported header field in all requests.

UAは、すべてのサポートされているヘッダフィールド内のヘッダフィールド値としてオプションタグ「パス」を含むべきである、とすべての要求にSupportedヘッダーフィールドを含むべきです。

The UA MAY include a Path header field in a request. This is not broadly applicable and caution must be taken to insure proper function, as the Path header field inserted by the UA may have additional Path header field values appended by intermediate proxies. Such proxies are not aware that the Path header field value was inserted by a UA, and will treat it as if it had been inserted by a previously traversed proxy, which could result in unexpected routing behavior wherein the UA is asked to act as a proxy.

UAは、要求のパスヘッダフィールドを含んでいてもよいです。これは、広く適用されず、注意がUAによって挿入パスヘッダフィールドは、中間プロキシによって添付追加パスヘッダフィールド値を有することができるように、適切な機能を保証するために注意しなければなりません。このようなプロキシは、Pathヘッダフィールドの値はUAによって挿入されたことを認識していない、そしてそれはUAがプロキシとして動作するように要求された予想外のルーティング動作につながる可能性が以前に横断プロキシ、によって挿入されたかのように扱います。

5.2 Procedures at Intermediate Proxies
中間プロキシで5.2手順

When a proxy processing a REGISTER request wishes to be on the path for future requests toward the UA originating that REGISTER request, the proxy inserts a URI for that proxy as the topmost value in the Path header field (or inserts a new topmost Path header) before proxying that request. It is also possible for a proxy with specific knowledge of network topology to add a Path header field value referencing another node, thereby allowing construction of a Path which is discongruent with the route taken by the REGISTER request. Such a construction is implementation specific and outside the scope of this document.

REGISTER要求を処理プロキシは、要求を登録UAの発信元に向けて今後の要求のためにパス上にあることを望む場合、プロキシはパスヘッダフィールドの一番上の値としてそのプロキシのURIを挿入(または、新たな最上位Pathヘッダを挿入します)その要求をプロキシする前に。ネットワークトポロジの特定の知識を持つプロキシがそれによってREGISTERリクエストによって撮影された経路にdiscongruentされているパスの構築を可能にする、他のノードを参照するパスヘッダフィールド値を追加することも可能です。このような構成は、実装固有の及び本文書の範囲外です。

Intermediate proxies SHOULD NOT add a Path header field to a request unless the UA has indicated support for this extension with a Supported header field value. If the UA has indicated support and the proxy requires the registrar to support the Path extension, then the proxy SHOULD insert a Requires header field value for this extension. If the UA has not indicated support for the extension and the proxy requires support for it in the registrar, the proxy SHOULD reject the request with a 421 response indicating a requirement for the extension.

UAは、Supportedヘッダーフィールド値でこの拡張機能のサポートを示していない限り、中間プロキシがリクエストにPathヘッダフィールドを追加しないでください。 UAがサポートを示しており、プロキシはパス拡張をサポートするために登録が必要な場合、プロキシは、この拡張のためのヘッダーフィールド値を必要と挿入する必要があります。 UAは、拡張のサポートを示しておらず、プロキシがレジストラでのサポートを必要とする場合、プロキシは、拡張のための要件を示す421応答でリクエストを拒否すべきです。

Proxies processing a REGISTER response SHOULD NOT alter any Path header field values that may be present in the response. The registrar MAY protect the Path header field in the response by including it in a protected S/MIME body, and alterations of the Path by an intermediate proxy can therefore be detected by the UA as man-in-the-middle attacks. Proxies SHOULD only consider altering the value of a Path header field in the REGISTER response if they have the credentials to correctly alter the S/MIME body to account for the change.

REGISTER応答を処理するプロキシは、応答中に存在し得る任意のパスヘッダフィールド値を変更しないでください。レジストラは、保護されたS / MIMEボディにそれを含めることによって、応答してパスヘッダフィールドを保護することができる、中間プロキシによる経路の変更は、したがって、man-in-the-middle攻撃としてUAによって検出することができます。彼らは正しく変更を考慮するために、S / MIMEボディを変更する資格情報を持っている場合、プロキシはREGISTER応答にパスヘッダフィールドの値を変更することを検討してください。

5.3 Procedures at the Registrar
レジストラで5.3手順

If a Path header field exists in a successful REGISTER request, the registrar constructs an ordered list of route elements (a path vector) from the nodes listed in the Path header field values, preserving the order as indicated in the Path header field values. The registrar then stores this path vector in association with that contact and the address-of-record indicated in the REGISTER request (the "binding" as defined in [1]). The registrar copies the Path header field values into a Path header field in the successful (200 class) REGISTER response. In the event that the home proxy and registrar are not co-located, the registrar MAY apply a locally-determined transformation to the stored path vector.

Pathヘッダフィールドは、成功したREGISTERリクエスト内に存在する場合、レジストラは、Pathヘッダフィールド値に示されるように順序を維持し、パスヘッダフィールド値にリストされたノードからルート要素(パスベクター)の順序付きリストを構築します。レジストラは、その接触およびアドレス・オブ・レコードに関連して、このパスベクトルはREGISTER要求([1]で定義されるように「結合」)に示されて格納されています。成功した(200クラス)REGISTER応答のパスヘッダフィールドにレジストラコピーパスヘッダフィールド値。ホームプロキシとレジストラが同一場所に配置されない場合には、レジストラは、格納されたパスベクトルに局所的に決定された変換を適用してもよいです。

If a registrar receives a REGISTER request containing a Path header field and there is no indication of support for the extension in the UA (via a Supported header field), the registrar must rely on local policy in determining how to treat this request. The recommended policy is for the registrar to reject the request with a 420 "Bad Extension" response indicating the Path extension. This approach allows the UA to detect that an intermediate proxy has inappropriately added a Path header field. However, the Path mechanism should technically work in the absence of UA support (at some compromise to security), so some registrars MAY choose to support the extension in the absence of a Supported header field value in the request.

レジストラは、Pathヘッダーフィールドを含むREGISTERリクエストを受信して​​、(サポートされているヘッダフィールド経由)UAでの拡張のサポートの兆候がない場合、レジストラはこの要求を処理する方法を決定する際にローカルポリシーに依存しなければなりません。レジストラは、パスの拡張子を示す420「悪い拡張子」応答で要求を拒否することを推奨ポリシーがあります。このアプローチは、UAは、中間プロキシが不適切パスヘッダフィールドを追加したことを検出することを可能にします。しかし、パスのメカニズムは技術的に(セキュリティにある程度の妥協で)UAのサポートがない状態で動作するはずですので、いくつかのレジストラがリクエストでサポートされているヘッダフィールド値が存在しない場合に拡張をサポートすることを選択するかもしれません。

5.4 Procedures at the Home Proxy
ホームプロキシで5.4手順

In the common SIP model, there is a home proxy associated with the registrar for a user. Each incoming request targeted to the public address-of-record for the user is routed to this proxy, which consults the registrar's database in order to determine the contact to which the request should be retargeted. The home proxy, in its basic mode of operation, rewrites the request-URI from the incoming request with the value of the registered contact and retransmits the request.

一般的なSIPモデルでは、ユーザーのためのレジストラに関連するホームプロキシがあります。パブリックアドレス・オブ・レコードのユーザーのために目標と各着信要求は要求をリターゲットすべき接触を決定するために、レジストラのデータベースを調べ、このプロキシにルーティングされます。ホームプロキシは、操作の基本モードでは、登録した連絡先の値を持つ着信要求からのリクエストURIを書き換え、要求を再送信します。

With the addition of Path, the home proxy also copies the stored path vector associated with the specific contact in the registrar database into the Route header field of the outgoing request as a preloaded route. This causes the outgoing request to transit the proxies that were included in the Path header field of the REGISTER request.

パスを添加し、さらにホームプロキシ・コピープリロード経路として発信要求のRouteヘッダフィールドに登録データベース内の特定の連絡先に関連付けられて記憶されたパスベクター。これはトランジットに発信要求REGISTERリクエストのパスヘッダフィールドに含まれたプロキシを引き起こします。

In normal processing, the home proxy is the "terminal point" for the user's address-of-record (AOR). Consequentially, the Route header field on the incoming request will have been exhausted in reaching the home proxy. If it isn't, then things get interesting. In the most common case, the home proxy generates the outgoing Route header field by inserting the stored path vector ahead of the Route header field values contained in the incoming request. This procedure may be altered by a local policy at the home proxy.

通常の処理では、家庭用プロキシは、ユーザーのアドレス・オブ・レコード(AOR)のための「終点」です。結果的に、着信要求のRouteヘッダーフィールドは、ホームプロキシに達するに尽くされています。そうでない場合は、物事は面白く。最も一般的なケースでは、ホームプロキシは、先に着信要求に含まRouteヘッダーフィールド値の記憶されたパスベクトルを挿入することにより、発信ルートヘッダーフィールドを生成します。この手順では、ホームプロキシでローカルポリシーによって変更することができます。

Loose routes may interact with routing policy in interesting ways. The specifics of how the stored path vector integrates with any locally required default route and local policy are implementation dependent. For example, some devices will use locally-configured explicit loose routing to reach a next-hop proxy, and others will use a default outbound-proxy routing rule. However, for the result to function, the combination must provide valid routing in the local environment. In general, the stored path vector is appended to any locally configured route needed to egress the service cluster. The service proxy (or registrar, as noted earlier) MAY also transform the stored path vector as needed to provide correct functionality. Systems designers must match the Path recording policy of their nodes with the routing policy in order to get a workable system.

ルースルートは興味深い方法でルーティングポリシーと相互作用することができます。格納されたパスベクターは、任意のローカルで必要なデフォルトルートとローカルポリシーと統合する方法の詳細は実装依存です。例えば、いくつかのデバイスは、ネクストホッププロキシに到達するためにローカルに構成された明示的なルーズルーティングを使用し、他のものは、デフォルトのアウトバウンドプロキシルーティングルールを使用します。しかし、機能するには、結果のために、組み合わせは、ローカル環境での有効なルーティングを提供する必要があります。一般的に、保存されたパスベクトルは、出力サービスクラスタに必要な任意のローカルに設定ルートに追加されます。正しい機能を提供するために必要に応じて(前述のように、またはレジストラ)サービスプロキシはまた、格納されたパスベクトルを変換することができます。システム設計者は、実行可能なシステムを得るためにルーティングポリシーとそのノードのパス記録ポリシーと一致する必要があります。

5.5 Examples of Usage
使い方の例5.5

Note that some header fields (e.g. Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation. The node marked REGISTRAR is a registrar and a proxy and serves as a home proxy. Thus, in the DNS the domain EXAMPLEHOME.COM points to the same host as REGISTRAR.EXAMPLEHOME.COM.

いくつかのヘッダフィールド(例えば、コンテンツの長さ)とセッション記述が短いとうまくいけば、より読みやすいプレゼンテーションを提供するために省略されていることに注意してください。 REGISTRARをマークしたノードは、レジストラとプロキシで、家庭用のプロキシとして機能します。したがって、DNSでREGISTRAR.EXAMPLEHOME.COMと同じホストにドメインEXAMPLEHOME.COMポイント。

5.5.1 Example of Mechanism in REGISTER Transaction
REGISTERトランザクションにおけるメカニズムの5.5.1例

As an example, we use the scenario from the Background section:

一例として、我々は背景のセクションからシナリオを使用します。

   UA1----P1-----P2----P3-----REGISTRAR
        

In this example, UA1 sends a REGISTER request to REGISTRAR. This request transits its default outbound proxy P1, an intermediate proxy P2, and the firewall proxy for the home domain, P3, before reaching REGISTRAR. Due to network topology and operational policy, P1 and and P3 need to be transited by requests from REGISTRAR or other nodes in the home network targeted to UA1. P2 does not. P1 and P3 have been configured to include themselves in Path header fields on REGISTER requests that they process. UA1 has a current IP address of "192.0.2.4".

この例では、UA1は、レジストラにREGISTERリクエストを送信します。この要求はREGISTRARに達する前に、デフォルトのアウトバウンドプロキシP1、中間プロキシP2、およびホームドメインのファイアウォール、プロキシ、P3を通過します。ネットワークトポロジや運用ポリシー、P1とP3とにUA1を対象とホームネットワーク内のREGISTRARまたは他のノードからの要求により遷移する必要があります。 P2はしていません。 P1およびP3は、彼らが処理REGISTERリクエストにPathヘッダフィールドで自分自身を含むように構成されています。 UA1は「192.0.2.4」の現在のIPアドレスを持っています。

Message sequence for REGISTER with Path:

パスとREGISTERのメッセージシーケンス:

F1 Register UA1 -> P1

F1登録UA1 - > P1

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path . . .

:<UA1@EXAMPLEHOME.COM一口>:UA1 <SIP:UA1@EXAMPLEHOME.COM REGISTRAR.EXAMPLEHOME.COM SIP / 2.0経由:::SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へUA1一口を登録>;タグ= 456248コールID:843817637684230のCSeq 998sdasdh09 @:1826 REGISTER連絡先:<SIP:UA1@192.0.2.4>サポート:パス。 。 。

F2 Register P1 -> P2

F2登録P1 - > P2

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P1.EXAMPLEVISITED.COM;lr> . . .

一口に登録:REGISTRAR.EXAMPLEHOME.COM SIP / 2.0経由:SIP / 2.0 / UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04経由:SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ:UA1 <SIP:UA1 @ EXAMPLEHOME.COM>から:UA1 <SIP:UA1@EXAMPLEHOME.COM>;タグ= 456248コールID:843817637684230のCSeq 998sdasdh09 @:1826 REGISTER連絡先:<SIP:UA1@192.0.2.4>サポート:パスのパス:<SIP :P1.EXAMPLEVISITED.COM; LR>。 。 。

Note: P1 has added itself to the Path.

注意:P1は、パスに自分自身を追加しました。

F3 Register P2 -> P3

F3登録P2 - > P3

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P1.EXAMPLEVISITED.COM;lr> . . .

一口に登録:REGISTRAR.EXAMPLEHOME.COM SIP / 2.0経由:SIP / 2.0 / UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908経由:SIP / 2.0 / UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04経由:SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ:から:UA1:UA1 <UA1@EXAMPLEHOME.COM一口> <一口:UA1@EXAMPLEHOME.COM>;タグ= 456248コールID:843817637684230のCSeq 998sdasdh09 @:1826 REGISTERお問い合わせ: <一口:UA1@192.0.2.4>サポート:パスのパス:<SIP:P1.EXAMPLEVISITED.COM; LR>。 。 。

Note: P2 did NOT add itself to the Path.

注意:P2は、パスに自分自身を追加しませんでした。

F4 Register P3 -> REGISTRAR

F4登録P3 - > REGISTRAR

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

一口に登録:REGISTRAR.EXAMPLEHOME.COM SIP / 2.0経由:SIP / 2.0 / UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363経由:SIP / 2.0 / UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908経由:SIP / 2.0 / UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04経由:SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ:UA1 <SIP:UA1@EXAMPLEHOME.COM>から:UA1 <SIP:UA1@EXAMPLEHOME.COM>。タグ= 456248コールID:843817637684230のCSeq 998sdasdh09 @:1826 REGISTER連絡先:<SIP:UA1@192.0.2.4>サポート:パスのパス:<SIP:P3.EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM ; LR>。 。 。

Note: P3 added itself to the Path.

注意:P3は、パスに自分自身を追加しました。

F5 REGISTRAR executes Register

F5 REGISTRARは、登録を実行します

REGISTRAR Stores: For UA1@EXAMPLEHOME.COM Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

REGISTRAR店舗:UA1@EXAMPLEHOME.COM問合せ先:<SIP:UA1@192.0.2.4>はサポートされている:パスのパス:<SIP:P3.EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM; LR>

F6 Register Response REGISTRAR -> P3

F6登録レスポンスREGISTRAR - > P3

SIP/2.0 200 OK Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP / 2.0 200 OK経由:SIP / 2.0 / UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363経由:SIP / 2.0 / UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908経由:SIP / 2.0 / UDP 112.68.155.4:5060。ブランチ= z9hG4bK34ghi7ab04経由:SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ:UA1 <SIP:UA1@EXAMPLEHOME.COM>;タグ= 251077から:UA1 <SIP:UA1@EXAMPLEHOME.COM>;タグ= 456248コールID:843817637684230 998sdasdh09 @のCSeq:1826 REGISTER連絡先:<SIP:UA1@192.0.2.4>サポート:パスパス:<SIP:P3.EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM; LR >。 。 。

Note: The Path header field in the response is identical to the one received in the REGISTER request.

注:レスポンスにパスヘッダフィールドは、REGISTERリクエストで受信したものと同じです。

F7 Register Response P3 -> P2

F7登録レスポンスP3 - > P2

SIP/2.0 200 OK Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP / 2.0 200 OK経由:SIP / 2.0 / UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908経由:SIP / 2.0 / UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04経由:SIP / 2.0 / UDP 192.0.2.4:5060。ブランチ= z9hG4bKnashds7へ:UA1 <SIP:UA1@EXAMPLEHOME.COM>;タグ= 251077から:UA1 <SIP:UA1@EXAMPLEHOME.COM>;タグ= 456248コールID:843817637684230 998sdasdh09 @のCSeq:1826 REGISTER連絡先:<SIP :UA1@192.0.2.4>サポート:パスのパス:<SIP:P3.EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM; LR>。 。 。

F8 Register Response P2 -> P1

F8登録レスポンスP2 - > P1

SIP/2.0 200 OK Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP / 2.0 200 OK経由:SIP / 2.0 / UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04経由:SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ:UA1 <SIP:UA1@EXAMPLEHOME.COM>。タグ= 251077から:UA1 <SIP:UA1@EXAMPLEHOME.COM>;タグ= 456248コールID:843817637684230 998sdasdh09 @のCSeq:1826 REGISTER連絡先:<SIP:UA1@192.0.2.4>サポート:パスのパス:<SIP:P3 .EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM; LR>。 。 。

F9 Register Response P1 -> UA1

F9登録レスポンスP1 - > UA1

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP / 2.0 200 OK経由:SIP / 2.0 / UDP 192.0.2.4:5060;branch=z9hG4bKnashds7へ:UA1:;:UA1 <一口UA1@EXAMPLEHOME.COM>からタグ= 251077 <一口:UA1@EXAMPLEHOME.COM>。タグ= 456248コールID:843817637684230のCSeq 998sdasdh09 @:1826 REGISTER連絡先:<SIP:UA1@192.0.2.4>サポート:パスのパス:<SIP:P3.EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM ; LR>。 。 。

5.5.2 Example of Mechanism in INVITE Transaction
機構の5.5.2の例は、INVITEトランザクション

This example shows the message sequence for an INVITE transaction originating from UA2 eventually arriving at UA1. REGISTRAR inserts a preloaded Route toward UA1 and retargets the request by replacing the request URI with the registered Contact. It then sends the retargeted INVITE along the Path towards UA1. Note that this example introduces foreign user agent UA2 (address "71.91.180.10") and foreign domain FOREIGN.ELSEWHERE.ORG. We have extended the diagram from the previous example by adding UA2, and by showing P2 out-of-line indicating that it did not include itself in the path during registration.

この例では、UA2は、最終的にUA1に到着から発信INVITEトランザクションのメッセージシーケンスを示しています。レジストラは、UA1に向けてプリロードルートを挿入し、登録した連絡先に要求URIを交換することにより、要求を再ターゲティング。その後、再標的化がUA1に向けた道に沿ってINVITEを送信します。この例では、外国人のユーザエージェントUA2(アドレス「71.91.180.10」)と外部ドメインFOREIGN.ELSEWHERE.ORGを紹介することに注意してください。我々は、UA2を加えることにより、それが登録時にパス自体に含まれていないことを示すアウトオブラインP2を示すことによって、前の例からの図を拡張しました。

Scenario

シナリオ

         UA1----P1---------P3-----REGISTRAR
                     |               |
                     P2              |
                                     |
         UA2--------------------------
        

Message sequence for INVITE using Path:

パスを使用してINVITEのメッセージシーケンス:

F1 Invite UA2 -> REGISTRAR

F1招待UA2 - > REGISTRAR

INVITE UA1@EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> . . .

UA1@EXAMPLEHOME.COM SIP / 2.0を介してのINVITE:SIP / 2.0 / UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3Rへ:UA1 <SIP:UA1@EXAMPLEHOME.COM>から:UA2 <SIP:UA2@FOREIGN.ELSEWHERE.ORG >;タグは= 224497コールID:48273181116@71.91.180.10のCSeq:<SIP:UA2@71.91.180.10> 29は、連絡先を招待します。 。 。

F2 REGISTRAR processing

F2 REGISTRAR処理

REGISTRAR looks up name "UA1@EXAMPLEHOME.COM" and returns: - Contact = <sip:UA1@192.0.2.4> - Path vector = <sip:P3.EXAMPLEHOME.COM;lr>, <sip:P1.EXAMPLEVISITED.COM;lr>

レジストラは名前 "UA1@EXAMPLEHOME.COM" とリターンを検索します: - 連絡先= <一口:UA1@192.0.2.4> - パスベクトル= <一口:P3.EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM ; LR>

Note: The Contact replaces the request-URI. The path vector is pushed onto the Route stack (preloaded Route) of the outgoing INVITE request. The topmost Route is used for making the routing decision (in conjunction with local policy).

注意:連絡先は、リクエストURIを置き換えます。パスベクトルは発信INVITE要求のルート・スタック(プリロードルート)にプッシュされます。一番上のルート(ローカルポリシーと併せて)ルーティング決定を行うために使用されます。

F3 Invite REGISTRAR -> P3

F3はREGISTRARを招待 - > P3

INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Route: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

INVITE UA1@192.0.2.4 SIP / 2.0経由:SIP / 2.0 / UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176経由:SIP / 2.0 / UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3Rへ:UA1 <SIP:UA1 @ EXAMPLEHOME .COM>から:UA2 <SIP:UA2@FOREIGN.ELSEWHERE.ORG>;タグ= 224497コールID:48273181116@71.91.180.10のCSeq:29連絡先をINVITE:<SIP:UA2@71.91.180.10>ルート:<SIP: P3.EXAMPLEHOME.COM; LR>、<SIP:P1.EXAMPLEVISITED.COM; LR>。 。 。

Note: In this example REGISTRAR does not want to stay on the Route and therefore does not insert a Record-Route.

注:この例ではREGISTRARは、ルート上に滞在するため、録音・ルートを挿入しません望んでいません。

F4 Invite P3 -> P1

F4はP3を招待 - > P1

INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Record-Route: <sip:P3.EXAMPLEHOME.COM;lr> Route: <sip:P1.EXAMPLEVISITED.COM;lr> . . .

UA1@192.0.2.4 SIP / 2.0を介してのINVITE:SIP / 2.0 / UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e経由を:SIP / 2.0 / UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176経由:SIP / 2.0 / UDP 71.91を。 180.10:5060;ブランチ= z9hG4bKe2i95c5st3Rへ:UA1 <SIP:UA1@EXAMPLEHOME.COM>から:UA2 <SIP:UA2@FOREIGN.ELSEWHERE.ORG>;タグ= 224497コールID:48273181116@71.91.180.10のCSeq:29は、INVITE連絡先:<SIP:UA2@71.91.180.10>レコード・ルート:<SIP:P3.EXAMPLEHOME.COM; LR>ルート:<SIP:P1.EXAMPLEVISITED.COM; LR>。 。 。

Note: P3 has added a Record-Route entry, indicating that it wants to be traversed by future messages in this dialog.

注意:P3は、このダイアログで今後のメッセージによって横断されるように望んでいることを示す、レコード・ルートエントリを追加しました。

F5 Invite P1 -> UA1

F5招待P1 - > UA1

INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Record-Route: <sip:P1.EXAMPLEVISITED.COM;lr> Record-Route: <sip:P3.EXAMPLEHOME.COM;lr> . . .

UA1@192.0.2.4 SIP / 2.0を介してのINVITE:SIP / 2.0 / UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p経由を:SIP / 2.0 / UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e経由:SIP / 2.0 / UDP 143.70を。 6.83:5060;ブランチ= z9hG4bKlj25C107a7b176経由:SIP / 2.0 / UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3Rへ:UA1 <SIP:UA1@EXAMPLEHOME.COM>から:UA2 <SIP:UA2@FOREIGN.ELSEWHERE.ORG>。タグ= 224497コールID:48273181116@71.91.180.10のCSeq:29 INVITE連絡先:<SIP:UA2@71.91.180.10>レコード・ルート:<SIP:P1.EXAMPLEVISITED.COM; LR>レコード・ルート:<SIP:P3 .EXAMPLEHOME.COM; LR>。 。 。

Note: P1 has added a Record-Route entry, indicating that it wants to be traversed by future messages in this dialog.

注意:P1は、このダイアログで今後のメッセージによって横断されるように望んでいることを示す、レコード・ルートエントリを追加しました。

6. Security Considerations
6.セキュリティの考慮事項

There are few security considerations for this document beyond those in SIP [1]. From a security perspective, the Path extension and its usage are identical to the Record-Route header field of basic SIP. Note that the transparency of the user expectations are preserved by returning the final Path to the originating UA -- that is, the UA is informed which additional proxies have been inserted into the path for the registration associated with that response.

SIP [1]のものを越えて、このドキュメントのいくつかのセキュリティ上の考慮事項があります。セキュリティの観点から、パス拡張及びその使用方法は、基本的なSIPのRecord-Routeヘッダフィールドと同一です。ユーザの期待の透明性が発信UAへの最終的なパスを返すことによって保存されることに注意してください - つまり、UAは、追加のプロキシはその応答に関連付けられている登録路に挿入されている通知されます。

The Path header field accumulates information in a hop-by-hop manner during REGISTER processing. The return information is essentially end-to-end, that is, it is not altered by intermediate proxies. This leads to two slightly different security approaches.

Pathヘッダフィールドは、登録処理中に、ホップバイホップ方式で情報を蓄積します。リターン情報は、本質的に、エンドツーエンド、つまり、中間プロキシによって変更されません。これは、わずかに異なる2つのセキュリティアプローチにつながります。

6.1 Considerations in REGISTER Request Processing
REGISTER要求の処理中に6.1の考慮事項

Information accumulated in REGISTER processing causes additional proxies to be included in future requests between the registrar's location and the UA. An attack that allowed an intruding proxy to add itself to this chain would allow the attacker to intercept future calls intended for the UA.

REGISTER処理に蓄積された情報は、追加のプロキシがレジストラの場所とUAの間に今後の要求に含まれるようになります。このチェーンに自分自身を追加するために侵入プロキシを許可された攻撃は、攻撃者はUAのために意図され、将来の呼び出しをインターセプトすることができます。

An attacker could conceivably alter the Path either by altering data "on the wire" or by other manipulations (such as impersonation) that would cause it to be included in the SIP routing chain (a "node insertion" attack). Altering data "on the wire" may be addressed adequately by the use of transport-layer integrity protection mechanisms such as TLS or IPSEC. Proxy insertion can be addressed by mutual authentication at the proxy layer, which can also be provided by TLS or IPSEC. The "sips:" URI class defined in [1] provides a mechanism by which a UA may request that intermediate proxies provide integrity protection and mutual authentication.

攻撃者は、おそらく「ワイヤ上に」またはそれがSIPルーティングチェーン(「ノード挿入」攻撃)に含まれることが原因であろう(例えば、なりすましなどの)他の操作によってデータを変更することにより、いずれかの経路を変化させることができます。 「ワイヤ上に」変更データは、TLSまたはIPSECなどのトランスポート層の完全性保護機構を用いて適切に対処することができます。プロキシ挿入はまた、TLSまたはIPSECによって提供することができるプロキシ層で相互認証によって対処することができます。 「一口:」で定義されたURIクラスは、[1] UAは、中間プロキシは、完全性保護と相互認証を提供することを要求することができる機構を提供します。

Systems using the Path mechanism SHOULD use appropriate mechanisms (TLS, IPSEC, etc.) to provide message integrity and mutual authentication. UAs SHOULD use "sips:" to request transitive protection.

適切なメカニズム(TLS、IPSEC、等)を使用する必要がありパスメカニズムを使用するシステムは、メッセージの整合性と相互認証を提供します。 UAは「一口:」を使用すべきで推移保護を要求します。

The registering UA SHOULD use S/MIME mechanisms to provide a protected copy of the original request to the registrar. In this case, the UA SHOULD include a Supported header field with a value indicating support for the Path extension in the protected copy. Registrars receiving such as request MUST honor the Path extension only if support is indicated in the protected header field. Further, they SHOULD compare the unprotected Supported header field with the protected Supported header field and take appropriate action in the event that an intermediate has altered the message to indicate support for Path when it was not indicated by the requesting UA.

登録UAは、レジストラに元の要求のコピープロテクトを提供するために、S / MIMEメカニズムを使用すべきです。この場合、UAは、保護されたコピーでパス拡張のサポートを示す値でサポートされているヘッダフィールドを含むべきです。要求などを受信するレジストラは、支持体は、保護されたヘッダフィールドに示されている場合にのみ、パス拡張を尊重しなければなりません。さらに、それらは、保護されたサポートされているヘッダ・フィールドと保護されていないサポートされているヘッダフィールドを比較し、それが要求するUAで示されなかった場合、中間パスのサポートを示すために、メッセージを変更した場合に適切なアクションを取るべきです。

6.2 Considerations in REGISTER Response Processing
REGISTER応答処理で6.2の考慮事項

The data returned to the UA by the Path header field in the response to the REGISTER request is there to provide openness to the UA. The registrar is telling the UA, "These are the intermediate proxies that will be included on future requests to you processed through me". By inspection of this header field, the UA may be able to detect node insertion attacks that involve inserting a proxy into the SIP routing chain. S/MIME techniques may be used to prevent alteration of this header field by intermediate proxies during response processing.

データは、UAに開放性を提供することであるREGISTERリクエストに応答して、PathヘッダフィールドによってUAに戻します。レジストラは、「これらはあなたが私を通って処理に今後の要求に含まれる中間プロキシです」、UAを語っています。このヘッダーフィールドの検査によって、UAは、SIPルーティングチェーンにプロキシを挿入することを含むノード挿入攻撃を検出することができます。 S / MIME技術は、応答処理中に中間プロキシによって、このヘッダフィールドの変更を防止するために使用されてもよいです。

As specified, there is no requirement for arbitrary proxies between the UA and the registrar to modify the Path header field in the REGISTER response. Consequently, we may use an end-to-end protection technique. The S/MIME technique defined in [1] provides an effective mechanism. Using this technique, the registrar makes a copy of the complete response, signs it, and attaches it as a body to the response. The UA may then verify this response, assuring an unmodified Path header field is received.

指定されたように、UAおよびREGISTER応答にパスヘッダフィールドを変更するためのレジストラの間の任意のプロキシの必要はありません。したがって、我々は、エンド・ツー・エンドの保護技術を使用することができます。 [1]で定義されたS / MIME技術は、効果的なメカニズムを提供します。この技術を使用して、レジストラは、完全な応答のコピーを作成し、それに署名し、その応答に体として、それを添付します。 UAは、次いで、非修飾パスヘッダフィールドは、受信される保証は、この応答を検証することができます。

In addition to the hop-by-hop integrity protection and mutual authentication measures suggested for REGISTER request processing in the preceding section, systems using Path header fields SHOULD implement end-to-end protection using S/MIME. More specifically, registrars returning a Path header field SHOULD attach a signed S/MIME of the response, and UAs receiving a REGISTER response containing a Path header field SHOULD validate the message using the

ホップバイホップ完全性保護および前節でREGISTER要求処理のために提案相互認証対策に加えて、Pathヘッダフィールドを使用するシステムは、S / MIMEを使用して、エンド・ツー・エンドの保護を実装する必要があります。具体的には、パスヘッダフィールドを返すレジストラは応答の署名されたS / MIMEを取り付ける必要があり、パスヘッダフィールドを含むREGISTER応答を受信するUAは、使用してメッセージを検証する必要があります

S/MIME technique. Furthermore, UAs receiving a Path header field in a REGISTER response SHOULD render it to the user, or (where feasible) check it programmatically.

S / MIME技術。また、REGISTER応答にパスヘッダフィールドを受信するUAは、ユーザ、または(可能な場合)、プログラムをチェックするために、それをレンダリングするべきです。

7. IANA Considerations
7. IANAの考慮事項

This document defines the SIP extension header field "Path", which the IANA has added to the registry of SIP header fields defined in SIP [1].

この文書は、IANAは、SIPで定義されたSIPヘッダフィールドのレジストリに追加したSIP拡張ヘッダ・フィールド「パス」を定義する[1]。

This document also defines the SIP option tag "path" which IANA has added to the registry of SIP option tags defined in SIP [1].

また、このドキュメントはIANAがSIPで定義されたSIPオプションタグのレジストリに追加したSIPオプションタグ「パス」を定義する[1]。

The following is the registration for the Path header field:

次は、Pathヘッダフィールドの登録です。

RFC Number: RFC3327

RFC番号:RFC3327

Header Field Name: Path

ヘッダーフィールド名:パス

Compact Form: none

コンパクトなフォーム:なし

The following is the registration for the path option tag:

以下は、パスオプションタグの登録です。

RFC Number: RFC3327

RFC番号:RFC3327

Option Tag: path

オプションタグ:パス

8. Acknowledgements
8.謝辞

Min Huang and Stinson Mathai, who put together the original proposal in 3GPP for this mechanism, and worked out most of the 3GPP procedures in 24.229.

このメカニズムのために3GPPでオリジナルの提案を一緒に入れて、24.229で3GPP手順のほとんどを働いた分黄とスティンソンマタイ、。

Keith Drage, Bill Marshall, and Miguel Angel Garcia-Martin who argued with everybody a lot about the idea as well as helped refine the requirements.

キース糖剤、ビル・マーシャル、そして皆でアイデアについて多くのことを主張しただけでなく、要件を洗練助けたミゲル・アンヘル・ガルシア・マーティン。

Juha Heinanen, who argued steadfastly against standardizing the function of discovering the home proxy with this technique in this document.

このドキュメントではこの技術を家庭用のプロキシを発見する機能を標準化に対して断固として主張ユハHeinanen、。

Normative References

引用規格

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル"、 RFC 3261、2002年6月。

[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[2]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

[4]ポステル、J.、およびJ.レイノルズ、 "RFC作者への指示"、RFC 2223、1997年10月。

Non-Normative References

非引用規格

[5] Garcia-Martin, MA., "3GPP Requirements On SIP", Work in Progress.

[5]ガルシア・マーティン、MA。、 "SIPでの3GPP要件" が進行中で働いています。

[6] Mankin, A., "SIP Change Process", Work in Progress.

[6]マンキン、A.、 "SIP変更処理"、進行中の作業。

Authors' Addresses

著者のアドレス

Dean Willis dynamicsoft Inc. 5100 Tennyson Parkway Suite 1200 Plano, TX 75028 US

ディーンウィリスdynamicsoft株式会社5100テニソンパークウェイスイート1200プラノ、TX 75028米国

Phone: +1 972 473 5455 EMail: dean.willis@softarmor.com URI: http://www.dynamicsoft.com/

電話:+1 972 473 5455 Eメール:dean.willis@softarmor.com URI:http://www.dynamicsoft.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/

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

著作権(C)インターネット協会(2002)。全著作権所有。

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 assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。