[要約] RFC 5658は、SIPにおけるRecord-Routeの問題に対処するためのガイドラインを提供しています。その目的は、SIPベースの通信システムでの正確なルーティングとアドレッシングを確保することです。
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)
セッション開始プロトコル（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）プロキシの典型的な機能は、その後のダイアログ内リクエストを通過させるために、レコードルートヘッダーを初期のダイアログ作成リクエストに挿入することです。このヘッダーには、SIPユニフォームリソース識別子（URI）またはSIP（SECURE SIP）URIが含まれています。これらのSIPまたはSIP URIは、輸送パラメーター（輸送= TCPなど）、または「comp = sigcomp」などの圧縮指示などのルーティングに影響を与える可能性のあるIPv4またはIPv6アドレスとURIパラメーターを含めることができます。プロキシが、その着信と発信インターフェイスの間にこれらのパラメーターの一部を変更する必要がある場合（マルチホームプロキシ、輸送プロトコルスイッチング、またはIPv4シナリオなど）、レコードルートヘッダーに何を置くべきかという疑問が生じます（s）。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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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:
長年にわたり、SIPITのような相互運用性イベントでは、多くの実装には、さまざまな記録的な問題や[RFC3261]の誤解による相互運用性の問題があることが注目されてきました。特に、プロキシの着信側と発信側の間で変更が発生した場合：トランスポートプロトコルスイッチング、「マルチホーム」プロキシ（IPv4からIPv6インターフェイスの変更を含む）など。複数のドキュメントが質問に対処し、それぞれが一般的に提供します。特定のユースケースに適切な推奨事項ですが、それらのどれも一般的な解決策を提供したり、一貫した一連の明確化を提供したりしません。
- [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は、[Dual-Homed]プロキシの[RFC3261]に記載されている書き換えソリューションの代わりに、ダブルレコードルーティングの使用を推奨しています。これらは、「1つのインターフェイスでリクエストが受信され、別のネットワークインターフェイスを介してプロキシアウトするように、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.
- [V6tran]のセクション3.1.1は、ProxyがRecord-RouteヘッダーURIにIPアドレスを挿入する場合、IPv4/IPv6遷移を行うマルチホームプロキシの二重記録ルーティングを義務付けています。
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:
マルチホームのプロキシは、ルーターのような2つ以上の異なるネットワークに接続されたプロキシであり、各ネットワークにインターフェイスがあり、トラフィックが「1つのネットワーク」に「出て」というものを「外」するようにします。簡単な例をここに示します：
+-----+
| 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つのインターフェイスと2つのアドレスがあります。
--192.0.2.65
--192.0.2.65
--192.0.2.129
--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には、アドレス付きの1つのインターフェイス、192.0.2.130があります。UA1とUA2の間にはIPレベルのルートがない可能性があります（PingまたはTracerouteは、これら2つのホスト間で動作しません）。彼らはまったく異なるサブネットワークに住んでいます。ただし、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つの異なる「側面」、例えば2つの異なるIPアドレス、またはSigCompを使用して1つの側面を使用して、SIPトラフィック間のSIPトラフィックを管理する必要がありません。、など
Handling of the Record-Route header in SIP Proxies is specified by following sections of [RFC3261]:
SIPプロキシのレコードルートヘッダーの取り扱いは、[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またはSIPS URIでなければなりません。[...] 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.
選択した応答に、このプロキシによって元々提供されたレコードルートヘッダーフィールド値が含まれている場合、プロキシは応答を転送する前に値を書き換えることを選択できます。これにより、プロキシは次の上流および下流の要素に異なる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接続を介して送信した場合、プロキシはレコードルートヘッダーフィールドのURIをSIPS URIに書き換える必要があります。
Note that [RFC5630] has weakened the SIP/SIPS URI rewriting requirement in the Record-Route header by removing this second paragraph.
[RFC5630]は、この2番目の段落を削除することにより、記録的なヘッダーのSIP/SIPS URI書き換え要件を弱めたことに注意してください。
Indeed, [RFC3261] suggests rewriting the Record-Route header in responses.
実際、[RFC3261]は、応答で記録的なヘッダーを書き換えることを提案しています。
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メーリングリストのディスカッションで頻繁に概説されているように、応答での記録的な書き換えは、マルチホームおよび輸送プロトコルの切り替え状況を処理する最適な方法ではありません。さらに、書き換えの結果は、発信者が見たルートセットがCalleeで見られるルートセットとは異なることであり、これは少なくとも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) Calleeは、応答のプロキシによって編集されるため、ルートセットに署名できません。その結果、ルートセットのエンドツーエンドの保護は、プロトコルによってサポートできません。これは、インターネットのオープン性とエンドツーエンドの接続の原則が壊れていることを意味します。
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に解決する情報を書き込みます。応答を処理するとき、プロキシはレコードルートヘッダーを検査し、入力インターフェイスを探し、それらを選択的に編集して正しい出力インターフェイスを参照する必要があります。この検索は、プロキシによって転送されるすべての応答に対して行われなければならないため、この手法は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 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.
この手法は、既存のレコードルートヘッダーの前に挿入すること、スキームやURIパラメーターを含む入力インターフェイスを反映したURIのレコードルートヘッダー、および第二に、出力を反映したURIのレコードルートヘッダーで構成されています。インターフェース。応答を処理する場合、記録されたルートの変更は必要ありません。これは、[RFC3261]と完全に後方互換です。一般的に言えば、応答を処理すると、プロキシが書き直される必要がない（したがって、検索なし）ため、2倍のレコードルーティングでは時間の複雑さが少なくなります。さらに、ダイアログ内のリクエストと応答の処理には、特別な取り扱いはもう必要ありません。
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つのルートヘッダーを削除できることを選択できます。
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のアドレスがあります。IPv6インターフェイスでは、2001年のアドレス：db8 :: 1で構成されています。読みやすさを容易にするために、いくつかの必須の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)
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>
F2 INVITE P1 (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>
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)
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]>
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]>
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
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
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)
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
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
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.
このセクションでは、レコードルートヘッダーのトランスポートプロトコルURIパラメーターの使用に関連する一連の問題について説明します。状況によっては、相互運用性の問題が発生します。これは、レコードルートヘッダーの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トランスポートプロトコルの切り替えを行います。
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を使用するAlice UA1からリクエストを受け取ります。この要求は、輸送プロトコルとしてUDPを指定する連絡先に登録されたBoB UA2に依頼します。したがって、P1はTCPを介してアリスから初期リクエストを受け取り、UDPを介してボブに転送します。その後のリクエストでは、TCPはAliceとP1、およびP1とBOBの間でUDPの間で引き続き使用されると予想されますが、これは数値IPアドレスが使用され、レコードルートURIで輸送パラメーターが設定されていない場合は発生しません。これは、[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
図4：TCPからUDPへの輸送プロトコルの切り替え問題の図
F1 INVITE UA1 -> P1 (192.0.2.1/tcp)
F1招待UA1-> 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>
F2 INVITE P1 -> UA2 (ua2.biloxi.example.com/udp)
f2招待P1-> 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>
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
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>
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>
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
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
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
Figure 5: TCP to UDP Transport Protocol Switching Issue Description
図5：TCPからUDPへの輸送プロトコルの切り替え問題の説明
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に輸送パラメーターを挿入しないため、F5で送信されたACKのように、UA1のその後のダイアログ内リクエストは、セクション12.2（ダイアログ内のリクエスト）で指定された動作に従って送信されます。[RFC3261]。つまり、ルートセットが使用され、[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を送信しようとしているときに相互運用性の問題が発生します。輸送プロトコルをミッドダイアログリクエストのために変更する準備ができておらず、それを行うことができず、プロキシ実装者にレコードにトランスポートプロトコルを挿入する必要があります。-Route URI。
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である場合にのみ、プロトコルスイッチングが回避されます。他の結果として生じる輸送プロトコルについては、上記の輸送プロトコルスイッチングの問題が発生します。また、UASの1つが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) UASは、たとえ[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.
- エンドユーザーが何らかの理由で輸送プロトコルを選択したい場合、たとえば、TCPを強制する必要がある、UDP/混雑を避け、再送信または断片化するなど。
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.
初期リクエストのためにUASのトランスポートプロトコルを強制するこの機能は避ける必要があります。アウトバウンドプロキシの構成でトランスポートプロトコルを選択すると、[RFC3263]手順が最初のリクエストのためにバイパスされることを意味します。結果として、[RFC3261]で推奨されているように輸送パラメーターなしでプロキシレコードルーティングが行われた場合、UAはとにかく[RFC3263]に促進された輸送を使用することを余儀なくされます。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) UASは、特定のダイアログに対して常に同じトランスポートを保持することにしました。プロキシが記録的なルーティングでない場合、Calleeは接触していないトランスポートを介して後続の要求を受信する可能性があるため、この選択は不安定です。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) UASは[RFC3263]をまったくサポートしていないか、DNSサーバーを利用できません。その場合、前述のように、UA1に初期リクエストとその後のリクエストの間にTCPからUDPに切り替えることを強制することは、明らかに望ましいデフォルトの動作ではなく、通常、相互運用性の問題につながります。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を使用する場合、レコードルートヘッダーフィールドに配置されたURIは、TLSを使用して到達する次のホップをエンコードする必要があります。これが機能するには2つの方法があります。最初の方法は、記録的なルートに配置されたURIがSIPS URIになることです。2つ目は、URIが[RFC3263]解像度の手順を適用してURIにTLSが選択されるようになるように、Record-routeに配置されたURIが構築されることです。この仕様に準拠したプロキシは、「RFC3261]によって「Transport = TLS」使用法が非推奨であるため、レコードルートに配置されたURIの「Transport = 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.
- ダブルレコードルーティング：プロキシは、2つのレコードルートヘッダーをSIPリクエストに挿入します。最初の1つは、この例ではレコードルートに設定されています：<SIP：192.0.2.1; lr; Transport = TCP>、2番目のものはレコードルートに設定されています：<SIP：192.0.2.1; lr>輸送、または輸送= 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.
- RECORD-ROUTE Responses：F2で送信された招待リクエストでは、プロキシは発信トランスポートプロトコルをRecord-Route URIの輸送パラメーターに置きます。そうすることで、UA2は、同じダイアログの以前のメッセージと同じトランスポートプロトコルを使用して、F6でBYEリクエストを正しく送信します。プロキシは、200 OK応答を処理するときにレコードルートを書き直し、「トランスポート= TCP」に「トランスポートパラメーター」を「トランスポート」に変更します。ua1および<sip：192.0.2.1; lr; Transport = udp> for ua2の場合。
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:
Double Record-routeをサポートし、Record-Route URIにトランスポートパラメーターを挿入することは、プロキシ実装の一般的な慣行です。このプラクティスは、その後のリクエストの経路にある可能性のあるすべてのSIP要素がその輸送をサポートしている限り、受け入れられます。この制限には説明が必要です。「P1.Biloxi.example.com」のP1、およびP2の最初のリクエストのパスに2つのプロキシがあると想像してみましょう。P1は記録的なルーティングであり、P2 URIが[RFC3263]を適用するSCTPに解決するため、UDPからストリーム制御伝送プロトコル（SCTP）に輸送を変更します。その結果、プロキシP1は2つのレコードルートヘッダーを挿入します。
Record-Route: <sip:p1.biloxi.example.com;transport=udp> and
Record-Route: <sip:p1.biloxi.example.com;transport=sctp>.
Record-route：<SIP：p1.biloxi.example.com; Transport = 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の下流のSIP要素は、Calleeからのその後のダイアログ内リクエストに対してSCTPを使用してP1に到達するように求められ、この下流のSIP要素がその輸送をサポートしないため、P2が記録的なルーティングでない場合に問題が発生します。
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、輸送変更など）に記録的なヘッダーを挿入する必要があります。後続のリクエストの道にいること。
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.
- 輸送プロトコルスイッチングシナリオに関するレコードルートヘッダーの相互運用性の問題は、セクション6で概説および説明されています。この最後のセクションでは、状況を改善するためのUAおよびプロキシ実装に関するいくつかの推奨事項を示します。プロキシは、さらなる処理に影響を与える可能性のあるマルチホームの状況に二重のレコードルーティングを使用する必要があり、状況によっては、輸送プロトコルパラメーターを記録的なURIに配置する必要があります。UASは、最初のリクエストの輸送を上書きするオプションを提供してはなりません。さらに、UASはDNSに依存して目的の輸送を表現する必要があり、この場合は輸送パラメーターを使用したIPアドレスを避ける必要があります。最後に、UASは、最初のリクエストとダイアログ内のさらなるメッセージ間のトランスポートを切り替える準備ができている必要があります。
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・グルベイニ、ジョエル・レシケット、ロバート・スパークス、ジョナサン・ローゼンバーグ、カレン・ジェニングス、ジュハ・ハイナネン、ポール・キジバット、ニルズ・オールマイヤー、ティンバー・ポーク、フランコア・オーデット、エイドリアン・ファレル、ラルフキース・ドレイジとジョン・エルウェルのレビューとコメントについて。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、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。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630] Audet、F。、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、2009年10月。
[BUG664] Sparks, RS., "Bug 664: Double record routing, http://bugs.sipit.net/show_bug.cgi?id=664", October 2002.
[bug664] Sparks、rs。、 "Bug 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] Camarillo、G。、「セッション開始プロトコルの圧縮（SIP）」、RFC 3486、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] Willis、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] Camarillo、G.、El Malki、K。、およびV. Gurbani、「セッション開始プロトコル（SIP）におけるIPv6遷移」、2009年8月の作業。
Authors' Addresses
著者のアドレス
Thomas Froment Tech-invite
Thomas Froment Tech-Invite
EMail: thomas.froment@tech-invite.com
Christophe Lebel Alcatel-Lucent Lieu dit Le Mail Orvault 44708 France
クリストフ・レベル・アルカテル・ルーセント・リュー・ディット・ル・メール・オルヴォー44708フランス
EMail: christophe.lebel@alcatel-lucent.com
Ben Bonnaerens Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
Ben Bonnaerens Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
EMail: ben.bonnaerens@alcatel-lucent.com