Network Working Group T. Froment
Request for Comments: 5658 Tech-invite
Category: Standards Track C. Lebel
B. Bonnaerens
Alcatel-Lucent
October 2009
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）或SIPS（安全SIP）URI，指示后续请求应发送到何处以及如何到达代理。这些SIP或SIPS URI可以包含IPv4或IPv6地址以及可能影响路由的URI参数，例如传输参数（例如，传输=tcp）或压缩指示，如“comp=sigcomp”。当代理必须在其传入和传出接口（多宿主代理、传输协议切换或IPv4到IPv6场景等）之间更改某些参数时，问题在于应该在记录路由头中放置什么。不可能使一个标头同时具有两个接口的特征。本文档旨在澄清这些场景，并修复在本主题中已识别的错误；它正式推荐使用双记录路由技术作为当前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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第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
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节建议使用双记录路由，而不是[RFC3261]中描述的用于“双宿主”代理的重写解决方案。这些被定义为“连接到两个（或多个）不同网络的代理，以便在一个接口上接收请求，并通过另一个网络接口进行代理”。
- 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节规定，当代理在记录路由头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]中引用的已识别缺陷。特别是，它考虑了[BUG664]的建议，即“描述这一点的语言需要清楚地捕捉到，这适用于每一方的所有类型的不同接口问题，包括一方的IPv4和另一方的IPv6”。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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 |
+--+--+
+-----+
| 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的接口。
The Proxy P has two interfaces and two addresses:
代理P有两个接口和两个地址：
--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有一个地址为192.0.2.130的接口。UA1和UA2之间可能没有IP级路由（ping或traceroute在这两台主机之间不起作用）。他们生活在完全不同的子网络中。但它们仍然可以交换SIP消息，因为P是SIP代理。这在SIP中起作用，因为P可以应用记录路由。
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代理必须管理两个不同“端”之间的SIP流量，例如，使用两个不同的IP地址，或者一方使用SIGCOMP，另一方不使用，等等。
Handling of the Record-Route header in SIP Proxies is specified by following sections of [RFC3261]:
[RFC3261]的以下章节规定了SIP代理中记录路由头的处理：
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]通过删除第二段，削弱了记录路由头中的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
此列表突出显示了重写和双记录路由技术的实用性，这些技术适用于任何多宿主代理用例：每当代理更改其IP地址、传输协议或传入和传出接口之间的URI方案时。重写
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.
第4节和第5节对双记录路由进行了描述、比较和讨论；第6节将讨论是否在记录路由URI中插入传输参数的具体问题。
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邮件列表讨论中经常提到的，响应中的记录路由重写不是处理多宿和传输协议切换情况的最佳方法。此外，重写的结果是调用者看到的路由集与被调用者看到的路由集不同，这至少有两个负面影响：
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) 代理必须实现特殊的“多宿主”逻辑。在请求转发阶段，它执行输出接口计算，并将解析到输出接口的信息写入记录路由头的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
该技术包括在任何现有记录路由头之前插入一个URI反映到输入接口（包括方案和/或URI参数）的记录路由头，以及第二个URI反映到输出接口的记录路由头。处理响应时，不需要修改记录的路由。这与[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节解释了被视为螺旋式请求的内容。为了避免螺旋，代理可以是智能的，并在前面扫描额外的路由头，以确定请求是否会螺旋通过它。如果是这样，它可以通过自身优化第二个螺旋。尽管这是一个实施决策，但避免螺旋式增长要有效得多。因此，这意味着，在第16.4节“路由信息预处理”[RFC3261]中，实现者可以选择在使用双记录路由时，代理可以删除两个路由头，而不是一个路由头。
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 |<-------------------|
|<-------------------| |
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 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>
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
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>
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
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
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正常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
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
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)
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: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
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: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)
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
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
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: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代理，执行TCP到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接收来自Alice UA1的请求，Alice UA1使用TCP。它将此请求代理给Bob UA2，后者向指定UDP为传输协议的联系人注册。因此，P1通过TCP接收来自Alice的初始请求，并通过UDP将其转发给Bob。对于后续的请求，预期可以在Alice和P1之间继续使用TCP，在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 |<------------------------|
|<-----------------------| |
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 INVITE 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>
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 INVITE 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>
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
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>
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>
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
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
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
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中插入任何传输参数，UA1的后续对话内请求（如F5中发送的ACK）将根据[RFC3261]第12.2节（对话内请求）中指定的行为发送。这意味着使用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时，会出现互操作性问题：它没有准备好为mid对话请求更改其传输协议，只是没有这样做，需要代理实现者在记录路由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联系Bob，只有当[RFC3263]过程的传输协议为UDP时，才能避免协议切换。对于任何其他产生的传输协议，将发生上述传输协议切换问题。此外，如果其中一个UAs使用与从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,
2) UAs决定对给定的对话框始终保持相同的传输。这种选择是不稳定的，因为如果代理不是记录路由，被叫方可能会通过一个不是其联系人的传输接收后续请求。如果UA真的想避免在初始请求和后续请求之间切换传输协议，它应该依赖DNS记录；因此
it SHOULD avoid configuring statically the outbound proxy with a numeric IP address. A logical name, with no transport parameter, SHOULD be used instead.
它应该避免使用数字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实现应该准备好在初始和后续请求之间更改传输协议。理论上，如[RFC3261]第18.1.1节所述，任何使用UDP的UA或代理也必须准备好对超过路径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到达的下一跳。有两种方法可以实现这一点。第一种方法是将放置在记录路由中的URI设置为SIPS URI。第二个是用于构建放置在记录路由中的URI，以便对该URI应用[RFC3263]解析过程会导致选择TLS。符合此规范的代理不得在记录路由中放置的URI上使用“transport=tls”参数，因为[RFC3261]不赞成使用“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.
- 双记录路由：代理在SIP请求中插入两个记录路由头。在本例中，第一个被设置为记录路由：<sip:192.0.2.1；lr；transport=tcp>，第二个设置为记录路由：<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
- 响应时记录路由重写：在F2中发送的INVITE请求中，代理将传出传输协议放入记录路由URI的传输参数中。这样，UA2将正确地发送
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.
其BYE请求在F6中使用与同一对话框的先前消息相同的传输协议。代理在处理200 OK响应时重写记录路由，将传输参数“on The fly”更改为“transport=tcp”，使路由集看起来<sip:192.0.2.1；lr；对于UA1和<sip:192.0.2.1，传输=tcp>；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元素都支持该传输，这种做法是可以接受的。这种限制需要解释。假设您有两个代理，P1位于“P1.biloxi.example.com”，P2位于初始请求的路径上。P1是记录路由，将传输从UDP更改为流控制传输协议（SCTP），因为P2 URI解析为SCTP应用[RFC3263]。因此，代理P1插入两个记录路由头：
Record-Route: <sip:p1.biloxi.example.com;transport=udp> and
Record-Route: <sip:p1.biloxi.example.com;transport=udp> and
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、传输更改等）插入记录路由头。
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中规定的现有协议的方法，而不是引入任何新的协议机制。因此，它们不会带来任何新的安全问题，但有必要对已经存在的问题进行额外考虑。特别是，当消息传输两个接口时，双记录路由技术将把有关两个接口的信息传送到每个相关端点（以及该代理和这些端点之间的任何中介），其中，重写技术只会公开最接近每个给定端点的接口的信息。如果存在诸如拓扑隐藏或隐私（如[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.
感谢迪安·威利斯、维杰·古巴尼、乔尔·雷皮奎特、罗伯特·斯帕克斯、乔纳森·罗森博格、卡伦·詹宁斯、朱哈·海纳宁、保罗·基齐瓦特、尼尔斯·奥尔梅尔、蒂姆·波尔克、弗朗索瓦·奥德特、阿德里安·法雷尔、拉尔夫·德罗姆斯、汤姆·巴特勒、扬尼克·布吉、基思·德雷格和约翰·埃尔威尔的评论和评论。
[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：会话启动协议”，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]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，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.，“BUG664:双记录路由，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技术邀请
EMail: thomas.froment@tech-invite.com
EMail: thomas.froment@tech-invite.com
Christophe Lebel Alcatel-Lucent Lieu dit Le Mail Orvault 44708 France
克里斯托弗·勒贝尔·阿尔卡特·朗讯邮件室或保险库44708法国
EMail: christophe.lebel@alcatel-lucent.com
EMail: christophe.lebel@alcatel-lucent.com
Ben Bonnaerens Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
Ben Bonnaerens Alcatel-Lucent Copernicuslaan 50安特卫普2018比利时
EMail: ben.bonnaerens@alcatel-lucent.com
EMail: ben.bonnaerens@alcatel-lucent.com