Network Working Group T. Froment
Request for Comments: 5658 Tech-invite
Category: Standards Track C. Lebel
B. Bonnaerens
Alcatel-Lucent
October 2009
Addressing Record-Route Issues in
the Session Initiation Protocol (SIP)
Abstract
抽象
A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution.
セッション開始プロトコル（SIP）プロキシの典型的な機能は、要求がそれを通過するに、ダイアログ、後続するために最初、ダイアログ作成要求にRecord-Routeヘッダを挿入することです。このヘッダは、どこでどのように後続の要求がプロキシに到達するために送られるべきで示すSIPユニフォームリソース識別子（URI）またはSIPS（セキュアSIP）URIを含んでいます。これらのSIPまたはSIPS URIは、IPv4またはIPv6アドレスと、そのようなトランスポートパラメータ（例えば、トランスポート= TCP）などのルーティングに影響を与える可能性がURIパラメータを含む、または「COMP = SigCompの」のような圧縮表示することができます。プロキシは（IPv6のシナリオ、等のマルチホームプロキシは、トランスポートプロトコルの切り替え、またはIPv4）、その着信および発信インターフェイスの間、これらのパラメータの一部を変更する必要がある場合、問題は、（Record-Routeヘッダに置かれるべきで生じ秒）。 1つのヘッダが同時に両方のインタフェースの特性を持たせることは不可能です。この文書では、これらのシナリオを明確にし、すでにこのトピックに関する特定されたバグを修正することを目指して。それは正式にのみ録音・ルート書き換えソリューションを説明し、現在のRFC 3261のテキストの代替として、二重のレコード・ルート技術の使用を推奨しています。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Problem Statement ...............................................4
3.1. Background: Multi-Homed Proxies ............................4
3.2. Identified Problems ........................................5
4. Record-Route Rewriting ..........................................6
5. Double Record-Routing ...........................................6
6. Usage of Transport Protocol Parameter ..........................10
6.1. UA Implementation Problems and Recommendations ............10
6.2. Proxy Implementation Problems and Recommendations .........14
7. Conclusion .....................................................15
8. Security Considerations ........................................16
9. Acknowledgments ................................................16
10. References ....................................................17
10.1. Normative References .....................................17
10.2. Informative References ...................................17
Over the years, it has been noticed in interoperability events like SIPit, that many implementations had interoperability problems due to various Record-Routing issues or misinterpretations of [RFC3261]; in particular, when a change occurs between the incoming and outgoing sides of a proxy: transport protocol switching, "multi-homed" proxies (including IPv4 to IPv6 interface changes), etc. Multiple documents have addressed the question, each of them generally providing an adequate recommendation for its specific use case, but none of them gives a general solution or provides a coherent set of clarifications:
長年にわたり、多くの実装は、さまざまなレコード・ルーティングの問題か、[RFC3261]の誤解による相互運用性の問題を抱えていたことを、SIPitのような相互運用性のイベントで注目されています。具体的には、変化がプロキシの着信および発信側との間で発生した場合：トランスポートプロトコル切り替え、「マルチホーム」プロキシは、それらの各々は、一般的に提供する、複数の文書は問題に対処している等、（IPv6インタフェースの変更へのIPv4を含みます）その具体的なユースケースのための適切な勧告は、それらのどれも一般解を与えないか、明確化の一貫したセットを提供します：
- [RFC3486], Section 6, describes the double Record-Routing as an alternative to the Record-Route rewriting in responses. This document is limited in scope to the "comp=sigcomp" parameter when doing compression with Signalling Compression (SIGCOMP).
- [RFC3486]、セクション6は、反応に書き換えレコードルートの代替として、二重レコードルーティングを記述する。シグナリング圧縮（SigCompの）で圧縮を行っているときに、この文書は、「COMP = SigCompの」パラメータの範囲に限定されています。
- [RFC3608], Section 6.2, recommends the usage of double Record-Routing instead of the rewriting solution described in [RFC3261] for "Dual-homed" proxies. Those are defined as "proxies connected to two (or more) different networks such that requests are received on one interface and proxied out through another network interface".
- [RFC3608]セクション6.2は、代わりに「デュアルホーム」プロキシに[RFC3261]で説明書き換え溶液の二重レコードルーティングの使用を推奨しています。それらは、「2つ（またはそれ以上）に接続されたプロキシ要求は一つのインタフェース上で受信され、他のネットワークインターフェースを介してプロキシされているように、異なるネットワーク」として定義されます。
- Section 3.1.1 of [V6Tran] mandates double Record-Routing for multi-homed proxies doing IPv4/IPv6 transitions, when the proxy inserts IP addresses in the Record-Route header URI.
- プロキシがRecord-RouteヘッダURIのIPアドレスを挿入したIPv4 / IPv6の遷移を行うマルチホームプロキシの[V6Tran]義務二重レコードルーティングのセクション3.1.1。
The observed interoperability problems can be explained by the fact that, despite these multiple documents, the RFC 3261 description has not been changed, and many implementations don't support extensions like Service-Route ([RFC3608]) or SIGCOMP ([RFC3486]).
観測され、相互運用性の問題は、これらの複数のドキュメントにもかかわらず、RFC 3261の記述が変更されていない、という事実によって説明することができ、多くの実装は、サービス・ルート（[RFC3608]）またはSigCompのような拡張をサポートしていません（[RFC3486]） 。
This document also aims to clarify an identified bug referenced in [BUG664]. In particular, it takes into account the [BUG664] recommendation, which says that "the language that describes this, needs to clearly capture that this applies to all types of different interface on each side issues, including IPv4 on one side and IPv6 on the other".
この文書はまた、[BUG664]で参照識別バグを明確にすることを目指しています。特に、それは考慮に入れ、これを記述する言語は、明らかにこれは上の一方の側のIPv4とIPv6を含め、それぞれの側の問題に異なるインターフェイスのすべてのタイプに適用されることをキャプチャする必要があります」と述べている[BUG664]勧告を取ります「他。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
A multi-homed proxy is a proxy connected, like a router, to two or more different networks, with an interface into each network, such that traffic comes "in" one network and goes "out" a different one. A simple example is shown here:
マルチホームプロキシが接続されているプロキシで、ルータのように、二つ以上の異なるネットワークに、各ネットワークへのインターフェースで、その結果、トラフィックは、一つのネットワーク「に」来て、「アウト」異なるものになります。簡単な例を次に示します。
+-----+
| UA1 |
+--+--+
| .66
192.0.2.64/26 |
----------------+---+-...
|
| .65
+-+-+
| P |
+-+-+
| .129
| 192.0.2.128/26
...---+------+------------------
|
| .130
+--+--+
| UA2 |
+--+--+
Figure 1: Multi-Homed Proxy Illustration
図1：マルチホームプロキシイラスト
UA1 has one interface with IP address 192.0.2.66.
UA1は、IPアドレス192.0.2.66とのインターフェイスを1つ持っています。
The Proxy P has two interfaces and two addresses:
プロキシPは、二つのインタフェースと2つのアドレスを有しています。
--192.0.2.65
ーー１９２。０。２。６５
--192.0.2.129
ーー１９２。０。２。１２９
UA2 has one interface with address, 192.0.2.130. There is potentially no IP-level route between UA1 and UA2 (pinging or traceroute does not work between these two hosts). They live in entirely different subnetworks. But they can still exchange SIP messages, because P is a SIP Proxy. This works in SIP because P can apply Record-Routing.
UA2は、アドレス、192.0.2.130とのインターフェイスを1つ持っています。 UA1とUA2（pingを実行するか、トレースルートは、これら2つのホスト間では動作しません。）との間にはIPレベルのルートが潜在的にありません。彼らは完全に異なるサブネットワークに住んでいます。 Pは、SIPプロキシであるので、しかし、彼らはまだ、SIPメッセージを交換することができます。 Pは、レコード・ルーティングを適用することができますので、これはSIPで動作します。
In most cases, there is still some IP connectivity between UA1 and UA2, but SIP proxy has to manage the SIP traffic between the two different "sides", e.g., with two different IP addresses, or one side using SIGCOMP and the other side not, etc.
ほとんどの場合、そこにはないUA1とUA2の間にいくつかのIP接続はまだですが、SIPプロキシは、2つの異なるIPアドレスで、例えば、二つの異なる「側面」とのSIPトラフィックを管理するために持っている、またはのSigCompを使用して1つの側と反対側など
Handling of the Record-Route header in SIP Proxies is specified by following sections of [RFC3261]:
SIPプロキシでRecord-Routeヘッダの処理は[RFC3261]のセクションを以下で指定されます。
On the request processing side, [RFC3261], item 4 of Section 16.6 states that:
要求処理側、[RFC3261]、セクション16.6状態の項目4にその：
The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI. [...] The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport.
URIは、SIPでなければなりませんRecord-Routeヘッダフィールド値に置かれ又はURIをSIPS。プロキシは後続の要求の経路であろう次の下流素子がそのトランスポートをサポートすること（例えば、プライベートネットワークのように）知識を持っていない限り、[...] URIは、トランスポートパラメータを含むべきではありません。
Following this statement, it is not clear how to decide when the proxy should insert the transport protocol parameter in the Record-Route URI.
この文の後に、プロキシが録音・ルートURIにトランスポートプロトコルパラメータを挿入する必要があるときを決定する方法が明確ではありません。
On the response processing side, [RFC3261] recommends in step 8 of Section 16.7 that:
応答処理側に、[RFC3261]は、セクション16.7ことのステップ8でお勧めします。
If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response. This allows the proxy to provide different URIs for itself to the next upstream and downstream elements. A proxy may choose to use this mechanism for any reason. For instance, it is useful for multi-homed hosts.
選択された応答は、もともとこのプロキシによって提供Record-Routeヘッダフィールドの値が含まれている場合、プロキシは応答を転送する前に値を書き換えることを選ぶかもしれ。これは、プロキシが次の上流と下流の要素に自分自身のために異なるURIを提供することを可能にします。プロキシが何らかの理由でこのメカニズムを使用することもできます。例えば、それは、マルチホームホストのために有用です。
If the proxy received the request over Transport Layer Security (TLS), and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI.
プロキシはトランスポート層セキュリティ（TLS）を超える要求を受信し、非TLS接続を介してそれを送信した場合、プロキシはSIPS URIであることをRecord-RouteヘッダーフィールドにURIを書き換えなければなりません。
Note that [RFC5630] has weakened the SIP/SIPS URI rewriting requirement in the Record-Route header by removing this second paragraph.
[RFC5630]はSIP /この第二項を除去することによってURIがRecord-Routeヘッダに要求を書き換えるSIPを弱体化していることに留意されたいです。
Indeed, [RFC3261] suggests rewriting the Record-Route header in responses.
実際、[RFC3261]は応答のRecord-Routeヘッダを書き換えることを示唆しています。
This list highlights the utility of rewriting and double Record-Routing techniques that apply for any multi-homed proxy use case: whenever the proxy changes its IP address, the transport protocol, or the URI scheme between incoming and outgoing interfaces. Rewriting and double Record-Routing are described, compared, and discussed in Sections 4 and 5; the specific question of whether or not to insert the transport parameter in the Record-Route URI is then discussed in Section 6.
プロキシは、そのIPアドレス、トランスポートプロトコル、または着信と発信インタフェースとの間のURIスキームを変更するたびにこのリストには、書き換えと任意マルチホームプロキシユースケースに適用二重レコードルーティング技術の有用性を強調する。書き換え二重レコード・ルーティングは、記載比較し、セクション4および5に記載されています。レコードルートURIトランスポートパラメータを挿入するか否かの特定の問題は、その後、セクション6で説明されています。
As frequently outlined in IETF mailing list discussions, Record-Route rewriting in responses is not the optimal way of handling multi-homed and transport protocol switching situations. Additionally, the consequence of doing rewriting is that the route set seen by the caller is different from the route set seen by the callee, and this has at least two negative implications:
頻繁にIETFメーリングリストでの議論で概説し、応答に書き換えレコード・ルートは、マルチホームの取り扱いおよびトランスポートプロトコルは、状況の切り替えに最適な方法ではありません。また、書き換えやっての結果は、呼び出し側から見たルートセットは、呼び出し先から見たルートセットとは異なり、これは、少なくとも2つの負の影響を持っているということです。
1) The callee cannot sign the route set, because it gets edited by the proxy in the response. Consequently, end-to-end protection of the route set cannot be supported by the protocol. This means the Internet's principles of openness and end-to-end connectivity are broken.
それが応答して、プロキシによって編集されますので、1）被呼者は、ルートセットに署名することができません。したがって、ルートセットのエンドツーエンドの保護は、プロトコルによってサポートすることができません。これは、オープン性とエンドツーエンドの接続のインターネットの原則が破られることを意味します。
2) A proxy must implement special "multi-homed" logic. During the request forwarding phase, it performs an output interface calculation and writes information resolving to the output interface into the URI of the Record-Route header. When handling responses, the proxy must inspect the Record-Route header(s), look for an input interface, and selectively edit them to reference the correct output interface. Since this lookup has to be done for all responses forwarded by the proxy, this technique implies a CPU drag.
2）プロキシは、特別な「マルチホーム」のロジックを実装する必要があります。要求転送フェーズ中は、出力インタフェースの計算を実行し、Record-RouteヘッダのURIへの出力インタフェースに解決情報を書き込みます。応答を処理するとき、プロキシは、Record-Routeヘッダ（単数または複数）を検査する入力インタフェースを探し、選択的正しい出力インターフェイスを参照するためにそれらを編集する必要があります。この検索は、プロキシによって転送され、すべての応答を行う必要がありますので、この技術は、CPUのドラッグを意味します。
Therefore, this document recommends using the double Record-Route approach to avoid rewriting the Record-Route. This recommendation applies to all uses of Record-Route rewriting by proxies, including transport protocol switching and multi-homed proxies.
したがって、このドキュメントは、レコード・ルートを書き換え避けるために、二重のレコード・ルート・アプローチを使用することをお勧めします。この勧告は、レコードルートは、トランスポートプロトコルの切り替えとマルチホームプロキシなどのプロキシによって書き換えのすべての使用に適用されます。
The serious drawbacks of the rewriting technique explain why the double Record-Routing solution has consequently been recommended in SIP extensions like [RFC3486] or [RFC3608].
書き換え技術の重大な欠点は、二重録音・ルーティング・ソリューションは、結果的に、[RFC3486]か[RFC3608]のようなSIP拡張で推奨されている理由を説明します。
This technique consists of inserting before any existing Record-Route header, a Record-Route header with the URI reflecting to the input interface, including schemes and/or URI parameters, and secondly, a Record-Route header with the URI reflecting to the output interface. When processing the response, no modification of the recorded route is required. This is completely backward compatible with [RFC3261]. Generally speaking, the time complexity will be less in double
この技術は、出力に反映URIとのスキームおよび/またはURIパラメータを含む入力インタフェース、および第二に、Record-Routeヘッダに反映URIと既存のRecord-Routeヘッダ、Record-Routeヘッダの前に挿入することから成りインタフェース。応答を処理するときに、記録された経路の修正が必要とされません。これは[RFC3261]との互換性が完全に後方です。一般的に言って、時間の複雑さは、二重で少なくなります
Record-Routing since, on processing the response, the proxy does not have to do any rewrites (and thus, no searching). Moreover, the handling of in-dialog requests and responses requires no special handling anymore.
レコードルーティング応答を処理する上で、プロキシが、任意の書き換えを行う必要がない（従って、無検索）、以来。また、中・ダイアログ要求と応答の取り扱いはもう特別な処理は必要ありません。
When double Record-Routing, the proxy will have to handle the subsequent in-dialog request(s) as a spiral, and consequently devote resources to maintain transactions required to handle the spiral. What is considered to be a spiraling request is explained in Section 6 of [RFC3261]. In order to avoid a spiral, the proxy can be smart and scan an extra Route header ahead to determine whether the request will spiral through it. If it does, it can optimize the second spiral through itself. Even though this is an implementation decision, it is much more efficient to avoid spiraling. So, this means, in Section 16.4, "Route Information Preprocessing" [RFC3261], implementors can choose that a proxy MAY remove two Route headers instead of one when using the double Record-Routing.
ときにダブルを記録・ルーティング、プロキシがスパイラルのように、後続で、対話要求（複数可）を処理する必要があり、その結果、スパイラルを処理するために必要な取引を維持するために資源を投入します。どのようならせん状の要求であると考えられていると、[RFC3261]のセクション6で説明されています。スパイラルを避けるために、プロキシはスマートに、要求がそれを介してスパイラルになるかどうかを判断するために先に余分なルートヘッダをスキャンすることができます。もしそうであれば、それは自分自身を介して第2のスパイラルを最適化することができます。これは実装上の決定であるにもかかわらず、それがスパイラルを回避するためにはるかに効率的です。だから、これは意味し、セクション16.4で、「ルート情報の前処理」[RFC3261]、実装者は、二重のレコード・ルーティングを使用した場合、プロキシは、1の代わりに2つのRouteヘッダを削除することができることを選択することができます。
The following example is an extension of the example given in [V6Tran]. It illustrates a basic call flow using double Record-Routing in a multi-homed IPv4 to IPv6 proxy, and annotates the dialog state on each User Agent (UA). In this example, proxy P1, responsible for the domain biloxy.example.com, receives a request from an IPv4-only upstream client. It proxies this request to an IPv6-only downstream server. Proxy P1 is running on a dual-stack host; on the IPv4 interface, it has an address of 192.0.2.254. On the IPv6 interface, it is configured with an address of 2001:db8::1. Some mandatory SIP headers have been omitted to ease readability.
次の例は、[V6Tran]で与えられた例の拡張です。これは、マルチホームのIPv4からIPv6へのプロキシで、二重のレコード・ルーティング使用して基本的なコールフローを示しており、各ユーザーエージェント（UA）に対話状態に注釈を付けます。この例では、ドメインbiloxy.example.comを担うプロキシP1は、IPv4専用上流のクライアントからの要求を受信します。これは、IPv6のみの下流のサーバにこの要求をプロキシ。プロキシP1は、デュアルスタックホスト上で実行されています。 IPv4インタフェース上で、それは192.0.2.254のアドレスを持っています。 DB8 :: 1：IPv6インタフェース上では、2001年のアドレスが設定されています。いくつかの必須SIPヘッダーは読みやすくするために省略されています。
UA1 Proxy "P1" UA2
(IPv4) (IPv4/IPv6) (IPv6)
| | |
| F1 INVITE | |
|------------------->| F2 INVITE |
| |------------------->|
| 100 Trying | |
|<-------------------| |
| | F3 200 OK |
| F4 200 OK |<-------------------|
|<-------------------| |
| | |
| F5 ACK | |
|------------------->| F6 ACK |
| |------------------->|
| | |
| | F7 BYE |
| F8 BYE |<-------------------|
|<-------------------| |
Figure 2: IPv4 to IPv6 Multi-Homed Proxy Illustration
図2：IPv4からIPv6マルチホームプロキシイラストに
F1 INVITE UA1 -> P1 (192.0.2.254:5060)
F1はUA1をINVITE - > P1（192.0.2.254:5060）
INVITE sip:bob@biloxi.example.com SIP/2.0 Route: <sip:192.0.2.254:5060;lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com> Contact: <sip:alice@192.0.2.1>
bob@biloxi.example.com SIP / 2.0経路：<SIP：192.0.2.254：5060; LR> SIPのINVITEから：アリス<SIP：alice@atlanta.example.com>;タグ= 1234：をボブ<SIP： bob@biloxi.example.com>連絡先：<SIP：alice@192.0.2.1>
F2 INVITE P1 (2001:db8::1) -> UA2
F2は、P1 INVITE（2001：DB8 :: 1） - > UA2
INVITE sip:bob@biloxi.example.com SIP/2.0 Record-Route: <sip:[2001:db8::1];lr> Record-Route: <sip:192.0.2.254:5060;lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com> Contact: <sip:alice@192.0.2.1>
SIPのINVITE：bob@biloxi.example.com SIP / 2.0レコードルート<SIP：[2001：DB8 :: 1]; LR>レコードルート<SIP：192.0.2.254：5060; LR>から：アリス< SIP：alice@atlanta.example.com>;タグ= 1234：ボブ<SIP：bob@biloxi.example.com>連絡先：<SIP：alice@192.0.2.1>
Dialog State at UA2:
Local URI = sip:bob@biloxi.example.com
Remote URI = sip:alice@atlanta.example.com
Remote target = sip:alice@192.0.2.1
Route Set = sip:[2001:db8::1];lr
sip:192.0.2.254:5060:lr
F3 200 OK UA2 -> P1 (2001:db8::1)
F3 200 OK UA2 - > P1（2001：DB8 :: 1）
SIP/2.0 200 OK Record-Route: <sip:[2001:db8::1];lr> Record-Route: <sip:192.0.2.254:5060;lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com>;tag=4567 Contact: <sip:bob@[2001:db8::33]>
SIP / 2.0 200 OKレコードルート<SIP：[2001：DB8 :: 1]; LR>レコードルート<SIP：192.0.2.254：5060; LR>：アリス<SIP：alice@atlanta.exampleから。コム>;タグ= 1234：ボブ<SIP：bob@biloxi.example.com>;タグ= 4567連絡先：<SIP：ボブ@ [2001：DB8 :: 33]>
F4 200 OK P1 -> UA1
F4 200 OK P1 - > UA1
SIP/2.0 200 OK Record-Route: <sip:[2001:db8::1];lr> Record-Route: <sip:192.0.2.254:5060;lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com>;tag=4567 Contact: <sip:bob@[2001:db8::33]>
SIP / 2.0 200 OKレコードルート<SIP：[2001：DB8 :: 1]; LR>レコードルート<SIP：192.0.2.254：5060; LR>：アリス<SIP：alice@atlanta.exampleから。コム>;タグ= 1234：ボブ<SIP：bob@biloxi.example.com>;タグ= 4567連絡先：<SIP：ボブ@ [2001：DB8 :: 33]>
Dialog State at UA1: Local URI = sip:alice@atlanta.example.com Remote URI = sip:bob@biloxi.example.com Remote target = sip:bob@[2001:db8::33] Route Set = sip:192.0.2.254:5060:lr sip:[2001:db8::1];lr
UA1のダイアログ州：ローカルURI = SIP：alice@atlanta.example.comリモートURI = SIP：bob@biloxi.example.comリモートターゲット= SIP：ボブ@ [2001：DB8 :: 33]ルート設定= SIP：192.0 .2.254：5060：LRのSIP：[2001：DB8 :: 1]; LR
F5 ACK UA1 -> P1 (192.0.2.254:5060)
F5 ACK UA1 - > P1（192.0.2.254:5060）
ACK sip:bob@[2001:db8::33] SIP/2.0 Route: <sip:192.0.2.254:5060:lr> Route: <sip:[2001:db8::1];lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com>;tag=4567
ACK SIP：ボブする@ [2001：DB8 :: 33] SIP / 2.0経路：<SIP：192.0.2.254：5060：LR>ルート<SIP：[2001：DB8 :: 1]; LR>から：アリス<SIP ：alice@atlanta.example.com>;タグ= 1234：ボブ<SIP：bob@biloxi.example.com>;タグ= 4567
F6 ACK P1 (2001:db8::1) -> UA2
F6 ACK P1（2001：DB8 :: 1） - > UA2
ACK sip:bob@[2001:db8::33] SIP/2.0 From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com>;tag=4567 (both Route headers have been removed by the proxy)
ACK SIP：ボブする@ [2001：DB8 :: 33] SIP / 2.0：アリス<SIP：alice@atlanta.example.com>;タグ= 1234：ボブ<SIP：bob@biloxi.example.com>;タグ= 4567（両方のルートヘッダがプロキシによって除去されています）
F7 BYE UA2 -> P1 (2001:db8::1)
F7 BYE UA2 - > P1（2001：DB8 :: 1）
BYE sip:alice@192.0.2.1 SIP/2.0 Route: <sip:[2001:db8::1];lr> Route: <sip:192.0.2.254:5060:lr> From: Bob <sip:bob@biloxi.example.com>;tag=4567 To: Alice <sip:alice@atlanta.example.com>;tag=1234
BYEをSIP：alice@192.0.2.1のSIP / 2.0経路：<SIP：[2001：DB8 :: 1]; LR>ルート<SIP：5060：192.0.2.254 LR>から：ボブ<SIP：ビロクシ@ボブ。 example.com>;タグ= 4567：をアリス<SIP：alice@atlanta.example.com>;タグ= 1234
F8 BYE P1 (192.0.2.254:5060) -> UA1
F8 BYE P1（192.0.2.254:5060） - > UA1
BYE sip:alice@192.0.2.1 SIP/2.0 From: Bob <sip:bob@biloxi.example.com>;tag=4567 To: Alice <sip:alice@atlanta.example.com>;tag=1234
BYEをSIP：ボブ<SIP：bob@biloxi.example.com>からalice@192.0.2.1のSIP / 2.0;タグ= 4567：をアリス<SIP：alice@atlanta.example.com>;タグ= 1234
Figure 3: Multi-Homed IPv4 to IPv6 Double Record-Routing Illustration
図3：マルチホームIPv4からIPv6ダブルレコード・ルーティングイラストへ
This section describes a set of problems that is related to the usage of transport protocol URI parameters in the Record-Route header. In some circumstances, interoperability problems occur because it is not clear whether or not to include the transport parameter on the URI of the Record-Route header. This was identified as a frequent problem in past SIPit events.
このセクションでは、Record-Routeヘッダ内のトランスポート・プロトコルURIパラメータの使用に関連する問題のセットを記述する。 Record-RouteヘッダのURIに輸送パラメータを含めるかどうかは明らかではないので、いくつかの状況では、相互運用性の問題が発生します。これは、過去SIPitのイベントで頻繁に問題があると同定されました。
[RFC3261], step 8 of Section 16.7 says:
[RFC3261]、セクション16.7のステップ8は言います：
The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport.
プロキシが後続の要求のパスになります次の下流の要素は、そのトランスポートをサポートしていること（たとえば、プライベートネットワークのような）知識を持っていない限り、URIは、トランスポート・パラメータを含めることはできません。
The preceding seems to confuse implementors, resulting in proxies that insert a single Record-Route without a transport URI parameter, resulting in the problems described in this section.
以上が、このセクションで説明する問題が生じる、輸送URIパラメータなしで単一レコードルートを挿入プロキシその結果、実装者を混同するようです。
Consider the following scenario: a SIP proxy, doing TCP to UDP transport protocol switching.
SIPプロキシ、UDPトランスポートプロトコルの切り替えにTCPをやって、次のシナリオを検討してください。
In this example, proxy P1, responsible for the domain biloxy.example.com, receives a request from Alice UA1, which uses TCP. It proxies this request to Bob UA2, which registered with a Contact specifying UDP as transport protocol. Thus, P1 receives an initial request from Alice over TCP and forwards it to Bob over UDP. For subsequent requests, it is expected that TCP could continue to be used between Alice and P1, and UDP between P1 and Bob, but this can not happen if a numeric IP address is used and no transport parameter is set on Record-Route URI. This happens because of procedures described in [RFC3263]. Some mandatory SIP headers have been omitted to ease readability.
この例では、ドメインbiloxy.example.comを担当するプロキシP1は、TCPを使用していますアリスUA1からの要求を受け取ります。これは、トランスポートプロトコルとしてUDPを指定する連絡先に登録ボブUA2、この要求をプロキシ。このように、P1は、TCP上でアリスから最初の要求を受信して、UDPを介してボブに転送します。後続の要求のためには、数字のIPアドレスが使用され、何の輸送パラメータを記録し、ルートURIに設定されていない場合、TCPはアリスとP1、及びP1とボブの間でUDPの間で使用されることを続けることができるが、これは起こらないことが予想されます。これは、[RFC3263]に記載の手順起こります。いくつかの必須SIPヘッダーは読みやすくするために省略されています。
Alice UA1 ===== TCP ===== Proxy P1 ===== UDP ===== Bob UA2
| | |
| F1 INVITE | |
|----------------------->| F2 INVITE |
| |------------------------>|
| 100 Trying | |
|<-----------------------| |
| | F3 200 OK |
| F4 200 OK |<------------------------|
|<-----------------------| |
| | |
| F5 ACK | |
|---(sent over UDP) X--->| ACK |
| |------------------------>|
| | |
| | F6 BYE |
| BYE |<------------------------|
|<-----------------------| |
Figure 4: TCP to UDP Transport Protocol
Switching Issue Illustration
F1 INVITE UA1 -> P1 (192.0.2.1/tcp)
F1はUA1をINVITE - > P1（192.0.2.1/tcp）
INVITE sip:bob@biloxi.example.com SIP/2.0 Route: <sip:192.0.2.1;lr;transport=tcp> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com> Contact: <sip:alice@ua1.atlanta.example.com;transport=tcp>
bob@biloxi.example.com SIP / 2.0ルート：SIP INVITEアリスから<SIP 192.0.2.1を; LR輸送= TCP> <SIP：alice@atlanta.example.com>;タグ= 1234：ボブ< SIP：bob@biloxi.example.com>連絡先：<SIP：alice@ua1.atlanta.example.com;運輸= TCP>
F2 INVITE P1 -> UA2 (ua2.biloxi.example.com/udp)
F2は、P1をINVITE - > UA2（ua2.biloxi.example.com/udp）
INVITE sip:bob@ua2.biloxi.example.com;transport=udp SIP/2.0 Record-Route: <sip:192.0.2.1;lr> (NO transport param) From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com> Contact: <sip:alice@ua1.atlanta.example.com;transport=tcp>
<SIP：192.0.2.1; LR>（NO輸送PARAM）から：アリス<SIP：alice@atlanta.example.com;輸送= UDP SIP / 2.0レコードルートbob@ua2.biloxi.example.com：SIPのINVITE >;タグ= 1234：ボブ<SIP：bob@biloxi.example.com>連絡先：<SIP：alice@ua1.atlanta.example.com;運輸= TCP>
Dialog State at UA2: Local URI = sip:bob@biloxi.example.com Remote URI = sip:alice@atlanta.example.com Remote target = sip:alice@ua1.atlanta.example.com;transport=tcp Route Set = sip:192.0.2.1;lr
UA2のダイアログ州：ローカルURI = SIP：bob@biloxi.example.comリモートURI = SIP：alice@atlanta.example.comリモートターゲット= SIP：alice@ua1.atlanta.example.com;運輸= tcpのルートを設定= SIP：192.0.2.1; LR
F3 200 OK UA2 -> P1 (192.0.2.1/udp)
F3 200 OK UA2 - > P1（192.0.2.1/udp）
SIP/2.0 200 OK Record-Route: <sip:192.0.2.1;lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com>;tag=4567 Contact: <sip:bob@ua2.biloxi.example.com>
SIP / 2.0 200 OKレコードルート<SIP：192.0.2.1; LR>から：アリス<SIP：alice@atlanta.example.com>;タグ= 1234：ボブ<SIP：bob@biloxi.example.com> ;タグ= 4567連絡先：<SIP：bob@ua2.biloxi.example.com>
F4 200 OK P1 -> UA1 (ua1.atlanta.example.com/tcp)
F4 200 OK P1 - > UA1（ua1.atlanta.example.com/tcp）
SIP/2.0 200 OK Record-Route: <sip:192.0.2.1;lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com>;tag=4567 Contact: <sip:bob@ua2.biloxi.example.com>
SIP / 2.0 200 OKレコードルート<SIP：192.0.2.1; LR>から：アリス<SIP：alice@atlanta.example.com>;タグ= 1234：ボブ<SIP：bob@biloxi.example.com> ;タグ= 4567連絡先：<SIP：bob@ua2.biloxi.example.com>
Dialog State at UA1: Local URI = sip:alice@atlanta.example.com Remote URI = sip:bob@biloxi.example.com Remote target = sip:bob@ua2.biloxi.example.com Route Set = sip:192.0.2.1;lr
UA1のダイアログ州：ローカルURI = SIP：alice@atlanta.example.comリモートURI = SIP：bob@biloxi.example.comリモートターゲット= SIP：bob@ua2.biloxi.example.comルートを設定= SIP：192.0。 2.1; LR
F5 ACK UA1 -> P1 (192.0.2.1/udp)
F5 ACK UA1 - > P1（192.0.2.1/udp）
ACK sip:bob@ua2.biloxi.example.com SIP/2.0 Route: <sip:192.0.2.1;lr> From: Alice <sip:alice@atlanta.example.com>;tag=1234 To: Bob <sip:bob@biloxi.example.com>;tag=4567
ACKをSIP：bob@ua2.biloxi.example.com SIP / 2.0経路：<SIP：192.0.2.1; LR>から：アリス<SIP：alice@atlanta.example.com>;タグ= 1234：ボブ<SIP： bob@biloxi.example.com>;タグ= 4567
F6 BYE UA2 -> P1 (192.0.2.1/udp)
F6 BYE UA2 - > P1（192.0.2.1/udp）
BYE sip:alice@ua1.atlanta.example.com;transport=tcp SIP/2.0 Route: <sip:192.0.2.1;lr> From: Bob <sip:bob@biloxi.example.com>;tag=4567 To: Alice <sip:alice@atlanta.example.com>;tag=1234
BYEをSIP：alice@ua1.atlanta.example.com;輸送= TCP SIP / 2.0経路：<SIP：192.0.2.1; LR>から：ボブ<SIP：bob@biloxi.example.com>;タグ= 4567に。アリス<SIP：alice@atlanta.example.com>;タグ= 1234
Figure 5: TCP to UDP Transport Protocol
Switching Issue Description
Since the proxy P1 does not insert any transport parameter in the Record-Route URI, subsequent in-dialog requests of UA1, like the ACK sent in F5, will be sent according to the behavior specified in Section 12.2 (requests within a Dialog) of [RFC3261]. That means that the routeset is used, and then, applying [RFC3263], the Route "sip:192.0.2.1" will resolve to a UDP transport by default (since no transport parameter is present here), and no Naming Authority Pointer (NAPTR) request will be performed since this is a numeric IP address.
プロキシP1は、レコードルートURI内の任意のトランスポートパラメータを、挿入しないので、後続に、ダイアログUA1の要求、F5で送信ACKように、（ダイアログ内リクエスト）セクション12.2で指定された行動に応じて送信されます[RFC3261]。それはroutesetが使用されていることを意味しないし、次に、[RFC3263]を適用し、ルートの「SIP：192.0.2.1は」（なし輸送パラメータがここに存在していないので）、デフォルトではUDPトランスポートに解決されます、そして何の命名権限ポインタ（NAPTRこれは数字のIPアドレスであるため）要求が実行されます。
In general, the interoperability problems arise when UA1 is trying to send the ACK: it is not ready to change its transport protocol for a mid-dialog request and just fails to do so, requiring the proxy implementor to insert the transport protocol in the Record-Route URI.
UA1はACKを送信しようとしたとき、一般的には、相互運用性の問題が発生する：ダイアログ中のリクエストのためのトランスポートプロトコルを変更する準備ができていないし、ちょうどそれを行うに失敗し、録音中のトランスポートプロトコルを挿入するために、プロキシ実装を必要としますURIを-route。
What happens if the proxy had Record-Routed its logical name (biloxi.example.com)? Since Bob is to be contacted over UDP, protocol switching will be avoided only if the resulting transport protocol of [RFC3263] procedures is UDP. For any other resulting transport protocol, the transport protocol switching issue described above will occur. Also, if one of the UAs sends an initial request using a different transport than the one retrieved from DNS, this scenario would be problematic.
プロキシはその論理名（biloxi.example.com）レコード・ルーテッドていた場合はどうなりますか？ボブはUDP上に接触するので、プロトコルの切り替えは[RFC3263]の手順の結果として得られるトランスポートプロトコルがUDPである場合にのみ回避されます。他の結果として得られるトランスポートプロトコルのために、上記トランスポート・プロトコル・スイッチングの問題が発生します。 UAの一つはDNSから取得とは異なるトランスポートを使用して、最初のリクエストを送信した場合にも、このシナリオは問題であろう。
In practice, there are multiple situations where UA implementations don't use logical names and NAPTR records when sending an initial request to a proxy. This happens, for instance, when:
実際には、プロキシへの最初の要求を送信するときに、UAの実装は、論理名とNAPTRレコードを使用していない複数の状況があります。これは、例えば、のために、発生します。
1) UAs offer the ability to "choose" the transport to be used for initial requests, even if they support [RFC3263]. This is a frequent UA functionality that is justified by the following use cases:
1）UAは、彼らが[RFC3263]をサポートしていても、初期の要求に使用するトランスポートを「選択」する機能を提供します。これは、次のユースケースによって正当化される頻繁UAの機能であります：
- when it is not possible to change the DNS server configuration and the implementation doesn't support all the transport protocols that could be configured by default in DNS (e.g., TLS).
- それは、DNSサーバーの構成と実装を変更することができない場合にDNS（例えば、TLS）にデフォルトで設定することができたすべてのトランスポートプロトコルをサポートしていません。
- when the end-user wants to choose his transport protocol for whatever reason, e.g., needing to force TCP, avoiding UDP/congestion, retransmitting, or fragmenting, etc.
- エンドユーザーは、例えば、など、UDP /渋滞、再送信、または断片化を避け、TCPを強制する必要が、何らかの理由で彼のトランスポートプロトコルを選択したい場合
This ability to force the transport protocol in UAs for initial requests SHOULD be avoided: selecting the transport protocol in the configuration of an outbound proxy means that [RFC3263] procedure is bypassed for initial requests. As a consequence, if the proxy Record-Routed with no transport parameter as is recommended in [RFC3261], the UA will be forced to use the [RFC3263]-preferred transport for subsequent requests anyway, which leads to the problematic scenario described in Figure 4.
最初の要求のためのUAにトランスポートプロトコルを強制するこの能力は避けるべきである：アウトバウンドプロキシの構成では、トランスポートプロトコルを選択する[RFC3263]の手順は、初期要求に対してバイパスされることを意味します。プロキシがないトランスポートパラメータでレコード・ルーテッド場合その結果、[RFC3261]に推奨されるように、UAは、[RFC3263]を使用することを余儀なくされ、図に記載問題のシナリオにつながる、いずれにせよ、後続の要求のための輸送を-preferred 4。
2) UAs decide to always keep the same transport for a given dialog. This choice is erratic, since if the proxy is not Record-Routing, the callee MAY receive the subsequent request through a transport that is not the one put in its Contact. If a UA really wants to avoid transport protocol switching between the initial and subsequent request, it SHOULD rely on DNS records for that; thus, it SHOULD avoid configuring statically the outbound proxy with a numeric IP address. A logical name, with no transport parameter, SHOULD be used instead.
2）UAは常に与えられたダイアログで同じ輸送を維持することを決定しました。プロキシは、ルーティングを記録していない場合、呼び出し先はその連絡先の1つのプットではないトランスポートを介して、後続の要求を受信することができるので、この選択は、不安定です。 UAは本当に初期とその後の要求間のトランスポートプロトコルの切り替えを避けたい場合は、そのためのDNSレコードに頼るべきです。したがって、それは数字のIPアドレスで静的にアウトバウンドプロキシを設定することは避けてください。論理名は、ノー輸送パラメータで、代わりに使用する必要があります。
3) UAs don't support [RFC3263] at all, or don't have any DNS server available. In that case, as illustrated previously, forcing UA1 to switch from TCP to UDP between initial request and subsequent request(s) is clearly not the desired default behavior, and it typically leads to interoperability problems. UA implementations SHOULD then be ready to change the transport protocol between initial and subsequent requests. In theory, any UA or proxy using UDP must also be prepared to use TCP for requests that exceed the size limit of path MTU, as described in Section 18.1.1 of [RFC3261].
3）UAは、すべての[RFC3263]をサポートしていない、または任意のDNSサーバーが使用できていません。その場合には、先に示したように、（S）最初の要求と次の要求との間のUDPにTCPから切り替えることUA1を強制することは、明らかに、所望のデフォルトの動作ではなく、それは、典型的には、相互運用性の問題につながります。 UA実装は、初期及び後続のリクエスト間のトランスポートプロトコルを変更する準備が整いました。理論的には、UDPを使用して、任意のUAまたはプロキシは、[RFC3261]のセクション18.1.1に記載されているように、パスMTUのサイズ制限を超えた要求に対してTCPを使用するように用意されなければなりません。
In order to prevent UA implementation problems, and to maintain a reasonable level of interoperability, the situation can be improved on the proxy side. Thus, if the transport protocol changed between its incoming and outgoing sides, the proxy SHOULD use the double Record-Route technique and SHOULD add a transport parameter to each of the Record-Route URIs it inserts. When TLS is used on the transport on either side of the proxy, the URI placed in the Record-Route header field MUST encode a next-hop that will be reached using TLS. There are two ways for this to work. The first way is for the URI placed in the Record-Route to be a SIPS URI. The second is for the URI placed in the Record-Route to be constructed such that application of [RFC3263] resolution procedures to that URI results in TLS being selected. Proxies compliant with this specification MUST NOT use a "transport=tls" parameter on the URI placed in the Record-Route because the "transport=tls" usage was deprecated by [RFC3261]. Record-Route rewriting MAY also be used. However, the recommendation to put a transport protocol parameter on Record-Route URI does not apply when the proxy has changed the transport protocol due to the size of UDP requests as per Section 18.1.1 of [RFC3261]. As an illustration of the previous example, it means one of the following processing will be performed:
UAの実装上の問題を防止するために、および相互運用性の合理的なレベルを維持するために、状況は、プロキシ側に改善することができます。トランスポート・プロトコルは、その着信および発信側の間に変更された場合したがって、プロキシは二重レコードルート技術を使用しなければならず、それが挿入レコードルートURIの各々に輸送パラメータを追加する必要があります。 TLSがプロキシのいずれかの側の搬送に使用される場合、Record-Routeヘッダフィールドに配置されたURIは、TLSを使用して到達される次のホップを符号化しなければなりません。これが機能するための2つの方法があります。第一の方法は、SIPS URIであることがレコードルートに配置されたURIのためのものです。レコードルートに配置されたURIは、TLSでそのURIの結果に[RFC3263]解決手順のアプリケーションが選択されるように構成するための第二です。 「輸送= TLS」使用は[RFC3261]によって非難されたため、レコードルートに配置されたURIに「輸送= TLS」パラメータを使用してはいけません。この仕様に準拠プロキシ。書き換えレコードルートを使用することもできます。プロキシは[RFC3261]のセクション18.1.1あたりとしてUDP要求のサイズのためのトランスポートプロトコルを変更したときただし、録音・ルートURIにトランスポートプロトコルパラメータを置くための勧告は適用されません。前の例の実例としては、以下の処理のいずれかが実行されることを意味します。
- Double Record-Routing: the proxy inserts two Record-Route headers into the SIP request. The first one is set, in this example, to Record-Route: <sip:192.0.2.1;lr;transport=tcp>, the second one is set to Record-Route: <sip:192.0.2.1;lr> with no transport, or with transport=udp, which basically means the same thing.
- ダブルレコードルーティング：プロキシは、SIPリクエストに2レコードルートヘッダを挿入します。最初のものは、この例では、レコードルートに設定されます。<SIP：192.0.2.1; LR;輸送= TCP>; NOと：<LR 192.0.2.1 SIP>、第1のレコードルートに設定されています輸送、または基本的に同じことを意味し、トランスポート= udpの、と。
- Record-Route rewriting on responses: in the INVITE request sent in F2, the proxy puts the outgoing transport protocol in the transport parameter of Record-Route URI. Doing so, UA2 will correctly send its BYE request in F6 using the same transport protocol as previous messages of the same dialog. The proxy rewrites the Record-Route when processing the 200 OK response, changing the transport parameter "on the fly" to "transport=tcp", so that the Route set will appear to be <sip:192.0.2.1;lr;transport=tcp> for UA1 and <sip:192.0.2.1;lr;transport=udp> for UA2.
- 応答に書き換えレコードルート：F2で送信されたINVITEリクエストに、プロキシは、レコードルートURIの輸送パラメータの送信トランスポート・プロトコルを置きます。そう、UA2は正しく同じダイアログの以前のメッセージと同じトランスポートプロトコルを使用してF6でそのBYE要求を送信します。ルートセットは<SIPであることが表示されるように、「輸送= TCP」を「オンザフライ」のトランスポートパラメータを変更、200 OK応答を処理するとき、プロキシは、レコードルートを書き換える：192.0.2.1; LR;輸送= UA1のTCP>と<SIP：192.0.2.1; LR; UA2のための輸送= udpの>。
It is a common practice in proxy implementations to support double Record-Route AND to insert the transport parameter in the Record-Route URI. This practice is acceptable as long as all SIP elements that may be in the path of subsequent requests support that transport. This restriction needs an explanation. Let's imagine you have two proxies, P1 at "p1.biloxi.example.com" and P2 on the path of an initial request. P1 is Record-Routing and changes the transport from UDP to Stream Control Transmission Protocol (SCTP) because the P2 URI resolves to SCTP applying [RFC3263]. Consequently, the proxy P1 inserts two Record-Route headers:
二重のレコード・ルートをサポートするために、レコード・ルートURIで輸送パラメータを挿入するために、プロキシ実装で一般的に行われています。この方法であれば、後続の要求の経路であってもよく、すべてのSIP要素が輸送することをサポートするとしてもよいです。この制限は、説明が必要。あなたが最初の要求の経路上に2つのプロキシ、「p1.biloxi.example.com」でP1とP2を持っている想像してみましょう。 P1は、レコードルーティングであり、P2 URIは、[RFC3263]を適用SCTPを解決するため、UDPからストリーム制御伝送プロトコル（SCTP）への輸送を変化させます。したがって、プロキシP1は、二つのRecord-Routeヘッダを挿入します。
Record-Route: <sip:p1.biloxi.example.com;transport=udp> and
レコードルート：<SIP：p1.biloxi.example.com;運輸= udpの>と
Record-Route: <sip:p1.biloxi.example.com;transport=sctp>.
レコードルート：<SIP：p1.biloxi.example.com; = SCTP輸送>。
The problem arises if P2 is not Record-Routing, because the SIP element downstream of P2 will be asked to reach P1 using SCTP for any subsequent, in-dialog request from the callee, and this downstream SIP element may not support that transport.
P2は、ルーティングを記録していない場合はP2の下流SIP要素は被呼者からの後続の、イン・ダイアログ要求のSCTPを使用してP1に到達するように依頼され、この下流SIP要素がそのトランスポートをサポートしない可能性があるため問題が生じます。
In order to handle this situation, this document recommends that a proxy SHOULD apply the double Record-Routing technique as soon as it changes the transport protocol between its incoming and outgoing sides. If proxy P2 in the example above would follow this recommendation, it would perform double Record-Routing and the downstream element would not be forced to send requests over a transport it does not support.
この状況に対処するためには、この文書では、プロキシは、すぐにそれはその着信と発信側の間のトランスポートプロトコルを変更すると、二重のレコード・ルーティング技術を適用すべきであることをお勧めします。上記の例では、プロキシP2は、この勧告に従うならば、それは二重のレコード・ルーティングと下流の要素を実行することになり、それはサポートしていないトランスポート上の要求を送信することを強制されることはありません。
By extension, a proxy SHOULD also insert a Record-Route header for any multi-homed situation (as the ones described in this document: scheme changes, sigcomp, IPv4/IPv6, transport changes, etc.) that may impact the processing of proxies being on the path of subsequent requests.
プロキシの処理に影響を与える可能性があります拡張することによって、プロキシは、（等スキームの変更、のSigCompはIPv4 / IPv6の、輸送変化は、この文書に記載されたもののような）任意のマルチホーム状況にRecord-Routeヘッダを挿入する必要があります以降のリクエストのパス上にあります。
As a conclusion of this document, it is to notice that:
本書の結論としては、それはそれに気づくことです。
- Record-Route rewriting is presented as a technique that MAY be used, with the drawbacks outlined in Section 4.
- レコードルート書き換えはセクション4に概説した欠点で使用することができる技術として提示されます。
- Double Record-Routing is presented as the technique that SHOULD be used, and is documented in Section 5.
- ダブルレコードルーティングを使用する必要があり、そして、セクション5に記載されている技術として提示されます。
- Record-Route header interoperability problems on transport protocol switching scenarios have been outlined and described in Section 6. This last section gives some recommendations to UA and proxy implementations to improve the situation. Proxies SHOULD use double Record-Routing for any multi-homed situation that MAY impact the further processing, and they SHOULD put transport protocol parameters on Record-Route URIs in some circumstances. UAs SHOULD NOT offer options to overwrite the transport for initial requests. Further, UAs SHOULD rely on DNS to express their desired transport and SHOULD avoid IP addresses with transport parameters in this case. Finally, UAs SHOULD be ready to switch transports between the initial request and further in-dialog messages.
- トランスポートプロトコルスイッチングシナリオに関するレコードルートヘッダの相互運用性の問題は、この最後のセクションでは、状況を改善するためにUAプロキシ実装するためにいくつかの勧告を与える第6節に概説し、説明してきました。プロキシは、さらなる処理に影響を与える可能性のあるマルチホームな状況のために、二重のレコード・ルーティングを使用すべきである、と彼らはいくつかの状況で録音・ルートのURIのトランスポートプロトコルパラメータを配置する必要があります。 UAは、最初の要求のための輸送を上書きするオプションを提供すべきではありません。さらに、UAは自分の希望の輸送を表現するためにDNSに依存している必要があり、この場合、トランスポートパラメータでIPアドレスを避ける必要があります。最後に、UAは、最初の要求の間で、さらにに、ダイアログメッセージのトランスポートをスイッチする準備ができているはずです。
The recommendations in this document describe a way to use the existing protocol specified in RFC 3261 rather than introducing any new protocol mechanism. As such, they do not introduce any new security concerns, but additional consideration of already existing concerns is warranted. In particular, when a message is transiting two interfaces, the double Record-Route technique will carry information about both interfaces to each of the involved endpoints (and any intermediaries between this proxy and those endpoints), where the rewriting technique would only expose information about the interface closest to each given endpoint. If issues such as topology hiding or privacy (as described in [RFC3323]) are a concern, the URI values placed in the Record-Route for each interface should be carefully constructed to avoid exposing more information than was intended.
このドキュメントの推奨事項ではなく任意の新しいプロトコルメカニズムを導入するよりも、RFC 3261で指定された既存のプロトコルを使用する方法について説明します。そのように、彼らはすべての新しいセキュリティ上の懸念を導入していないが、既存の懸念の追加の考慮事項は保証されています。メッセージは、2つのインターフェイスを通過したとき、特に、二重レコードルート技術は、関連エンドポイント（このプロキシとこれらのエンドポイントの間の任意の媒体）のそれぞれに両方のインタフェースに関する情報を伝送する、書き換え技術のみに関する情報を公開する場所各特定のエンドポイントに最も近いインターフェース。このようなトポロジ隠蔽または（[RFC3323]に記載されているように）、プライバシーなどの問題が懸念される場合は、各インターフェイスのためのレコードルートに配置されたURIの値は、注意深く意図したよりも多くの情報の公開を回避するように構築されるべきです。
Thank you to Dean Willis, Vijay K. Gurbani, Joel Repiquet, Robert Sparks, Jonathan Rosenberg, Cullen Jennings, Juha Heinanen, Paul Kyzivat, Nils Ohlmeier, Tim Polk, Francois Audet, Adrian Farrel, Ralph Droms, Tom Batsele, Yannick Bourget, Keith Drage, and John Elwell for their reviews and comments.
ディーンウィリス、ビジェイK. Gurbani、ジョエルRepiquet、ロバート・スパークス、ジョナサン・ローゼンバーグ、カレン・ジェニングス、ユハHeinanen、ポールKyzivat、ニルスOhlmeier、ティムポーク、フランソワAudet、エードリアンファレル、ラルフDroms、トムBatsele、ヤニック・ブルジェに感謝し、彼らのレビューとコメントのためのキース糖剤、およびジョンエルウェル。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630] Audet、F.、RFC 5630 "セッション開始プロトコル（SIP）におけるSIPS URIスキームの使用"、2009年10月。
[BUG664] Sparks, RS., "Bug 664: Double record routing, http://bugs.sipit.net/show_bug.cgi?id=664", October 2002.
[BUG664]スパークス、RS、 "バグ664：ダブルレコードルーティング、http://bugs.sipit.net/show_bug.cgi?id=664"。2002年10月。
[RFC3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[RFC3486]キャマリロ、G.、RFC 3486 "セッション開始プロトコルを（SIP）圧縮"、2003年2月。
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[RFC3608]ウィリス、D.とB. Hoeneisen、 "登録時にサービス経路探索のためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド"、RFC 3608、2003年10月。
[V6Tran] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", Work in Progress, August 2009.
【V6Tran]キャマリロ、G.、エルMalki、K.、およびV. Gurbani、 "セッション開始プロトコル（SIP）におけるIPv6移行"、進歩、2009年8月に働いています。
Authors' Addresses
著者のアドレス
Thomas Froment Tech-invite
トーマス・フロマンテックの招待
EMail: thomas.froment@tech-invite.com
メールアドレス：thomas.froment@tech-invite.com
Christophe Lebel Alcatel-Lucent Lieu dit Le Mail Orvault 44708 France
クリストフ・ルベルは言ったアルカテル・ルーセント場所メール44708オルヴォフランス
EMail: christophe.lebel@alcatel-lucent.com
メールアドレス：christophe.lebel@alcatel-lucent.com
Ben Bonnaerens Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
ベンBonnaerensアルカテル・ルーセントCopernicuslaan 50アントワープベルギー
EMail: ben.bonnaerens@alcatel-lucent.com
メールアドレス：ben.bonnaerens@alcatel-lucent.com