Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6135 Ericsson
Category: Standards Track S. Blau
ISSN: 2070-1721 Ericsson AB
February 2011
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6135 Ericsson
Category: Standards Track S. Blau
ISSN: 2070-1721 Ericsson AB
February 2011
An Alternative Connection Model for the Message Session Relay Protocol (MSRP)
消息会话中继协议（MSRP）的替代连接模型
Abstract
摘要
This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT.
本文档定义了消息会话中继协议（MSRP）用户代理（UAs）的替代连接模型；该模型使用面向连接的媒体（COMEDIA）机制来创建MSRP传输连接。该模型允许网络地址转换器（NAT）后面的MSRP UAs协商哪个端点启动传输控制协议（TCP）连接的建立，以便MSRP消息穿过NAT。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6135.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6135.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Applicability Statement .........................................3
4. COMEDIA for MSRP ................................................3
4.1. General ....................................................3
4.2. a=setup ....................................................3
4.2.1. General .............................................3
4.2.2. Attribute Usage .....................................4
4.3. TLS ........................................................5
4.4. a=connection ...............................................5
4.5. MSRP Relay Connection ......................................6
5. Interoperability with the Connection Model Defined in RFC 4975 ..6
6. Security Considerations .........................................6
7. Acknowledgements ................................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Applicability Statement .........................................3
4. COMEDIA for MSRP ................................................3
4.1. General ....................................................3
4.2. a=setup ....................................................3
4.2.1. General .............................................3
4.2.2. Attribute Usage .....................................4
4.3. TLS ........................................................5
4.4. a=connection ...............................................5
4.5. MSRP Relay Connection ......................................6
5. Interoperability with the Connection Model Defined in RFC 4975 ..6
6. Security Considerations .........................................6
7. Acknowledgements ................................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
The Message Session Relay Protocol (MSRP) core specification [RFC4975] states that the MSRP User Agent (UA) that sends the Session Description Protocol (SDP) offer is "active", and it is responsible for creating the MSRP transport connection towards the remote UA if a new connection is required. The core specification also allows, but does not define, alternate mechanisms for MSRP UAs to create MSRP transport connections.
消息会话中继协议（MSRP）核心规范[RFC4975]规定，发送会话描述协议（SDP）要约的MSRP用户代理（UA）处于“活动”状态，如果需要新连接，它负责创建指向远程UA的MSRP传输连接。核心规范还允许但未定义MSRP UAs创建MSRP传输连接的替代机制。
[RFC4145] defines a connection-oriented media (COMEDIA) mechanism, which endpoints can use to negotiate the endpoint that initiates the creation of media transport connection.
[RFC4145]定义了一种面向连接的媒体（COMEDIA）机制，端点可以使用该机制协商发起媒体传输连接创建的端点。
COMEDIA is especially useful when one of the endpoints is located behind a Network Address Translator (NAT). The endpoint can use the mechanism to indicate that it will create the media transport connection, in order for the media to traverse the NAT without the usage of relays and without being required to support more complex mechanisms (e.g., "TCP Candidates with Interactive Connectivity Establishment (ICE)" [ICE-TCP]). In addition, COMEDIA allows the usage of identical procedures in establishing Transmission Control Protocol (TCP) [RFC0793] connections for different types of media.
当其中一个端点位于网络地址转换器（NAT）后面时，COMEDIA特别有用。端点可以使用该机制来指示它将创建媒体传输连接，以便媒体在不使用中继的情况下穿越NAT，并且不需要支持更复杂的机制（例如，“具有交互式连接建立（ICE）的TCP候选者”[ICE-TCP]）。此外，COMEDIA允许使用相同的程序为不同类型的媒体建立传输控制协议（TCP）[RFC0793]连接。
An example is the Open Mobile Alliance (OMA)-defined "Instant Message using SIMPLE" [OMA-SIMPLE], where one MSRP UA of every MSRP transport connection represents a media server, which is always located in the carrier network. The media server has a globally reachable IP
例如，开放移动联盟（OMA）定义的“使用SIMPLE的即时消息”[OMA-SIMPLE]，其中每个MSRP传输连接的一个MSRP UA代表始终位于运营商网络中的媒体服务器。媒体服务器具有全局可访问的IP
address and handles application-specific policy control as well as NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA for NAT traversal, and all OMA IM MSRP clients support COMEDIA.
寻址并处理特定于应用程序的策略控制以及NAT遍历。OMA IM（Instant Messenger）使用COMEDIA进行NAT遍历，所有OMA IM MSRP客户端都支持COMEDIA。
This document defines how an MSRP UA uses COMEDIA in order to negotiate which UA will create the MSRP transport TCP connection towards the other UA. The document also defines how an MSRP UA that uses COMEDIA can establish an MSRP transport connection with a remote UA that does not support COMEDIA.
本文件定义了MSRP UA如何使用COMEDIA来协商哪个UA将创建指向其他UA的MSRP传输TCP连接。该文件还定义了使用COMEDIA的MSRP UA如何与不支持COMEDIA的远程UA建立MSRP传输连接。
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]中所述进行解释。
Support of this specification is OPTIONAL for MSRP UAs in general. UAs that are likely to be deployed in networks with NATs SHOULD support this specification. It will improve the odds of being able to make TCP connections successfully traverse NATs, since UAs behind NATs can be requested to initiate the establishment of the TCP connections.
一般而言，MSRP UAs可选择支持本规范。可能部署在具有NAT的网络中的UAs应支持此规范。这将提高TCP连接成功穿越NAT的几率，因为可以请求NAT后面的UAs启动TCP连接的建立。
This section defines how an MSRP UA that supports this specification uses the COMEDIA SDP attributes defined in [RFC4145].
本节定义了支持本规范的MSRP UA如何使用[RFC4145]中定义的COMEDIA SDP属性。
An MSRP UA uses the SDP a=setup attribute [RFC4145] in order to negotiate which endpoint will create the MSRP transport connection towards the other UA.
MSRP UA使用SDP a=设置属性[RFC4145]协商哪个端点将创建指向其他UA的MSRP传输连接。
An MSRP UA MUST always include an explicit a=setup attribute in its SDP offers and answers, since it might be useful for the other endpoint, or for entities in the network, to know whether the UA supports COMEDIA or not.
MSRP UA必须始终在其SDP报价和应答中包含明确的a=设置属性，因为它可能有助于其他端点或网络中的实体了解UA是否支持喜剧。
An MSRP UA MUST support the a=setup "active", "actpass", and "passive" attribute values. An MSRP UA MUST NOT send the "holdconn" attribute value. If an MSRP UA receives the "holdconn" attribute value, it MUST ignore it and process the message as if it did not contain an a=setup attribute.
MSRP UA必须支持a=设置“主动”、“actpass”和“被动”属性值。MSRP UA不得发送“holdconn”属性值。如果MSRP UA接收到“holdconn”属性值，则必须忽略该属性值，并将该消息视为不包含a=设置属性进行处理。
When the a=setup attribute value is "actpass" or "passive", the IP address and port values in the MSRP URI of the SDP a=path attribute MUST contain the actual address and port values on which the UA can receive a TCP connection for the MSRP transport connection.
当a=设置属性值为“actpass”或“passive”时，SDP a=路径属性的MSRP URI中的IP地址和端口值必须包含UA可以接收MSRP传输连接的TCP连接的实际地址和端口值。
In accordance with [RFC4145], if the a=setup attribute value is "active", the port number value should be 9.
根据[RFC4145]，如果a=设置属性值为“活动”，则端口号值应为9。
If an MSRP UA can provide a globally reachable IP address that the other endpoint can use as a destination for a TCP connection, the UA MUST use the a=setup "actpass" attribute value in SDP offers. This is in order to allow the remote UA to send an SDP answer with an a=setup "active" attribute value if the UA is located behind a NAT, and in order to be compatible with UAs that do not support COMEDIA and thus always will act as passive endpoints. If an MSRP UA cannot provide the actual transport address, the UA MUST use the a=setup "active" attribute value.
如果MSRP UA可以提供另一个端点可以用作TCP连接目的地的全局可访问IP地址，则UA必须使用SDP中的a=setup“actpass”属性值。这是为了在UA位于NAT后面时，允许远程UA发送带有a=设置“主动”属性值的SDP应答，并与不支持喜剧的UAs兼容，因此始终充当被动端点。如果MSRP UA无法提供实际的传输地址，UA必须使用a=setup“active”属性值。
The UA MUST NOT use the a=setup "passive" attribute value in an SDP offer.
UA不得在SDP报价中使用a=设置“被动”属性值。
The MSRP UA can determine that it provides a globally reachable IP address in the following scenarios:
MSRP UA可在以下情况下确定其提供全球可访问的IP地址：
o the UA can determine that it is not located behind a NAT;
o UA可以确定其不位于NAT后面；
o the UA relays its MSRP transport connections via a relay (e.g., an MSRP relay or Traversal Using Relay NAT (TURN) server); or
o UA通过中继（例如，MSRP中继或使用中继NAT（TURN）服务器的穿越）中继其MSRP传输连接；或
o the UA has used Session Traversal Utilities for NAT (STUN) [RFC5389] signaling to retrieve the NAT address and port through the local port to be used for the eventual transport connection, while also having determined that the NAT has endpoint-independent mapping and filtering behavior [RFC5382], e.g., using the mechanism defined in [RFC5780].
o UA已使用NAT（STUN）[RFC5389]信令的会话遍历实用程序，通过用于最终传输连接的本地端口检索NAT地址和端口，同时还确定NAT具有端点独立映射和过滤行为[RFC5382]，例如，使用[RFC5780]中定义的机制。
Some UAs can determine whether the SIP [RFC3261] signaling has traversed a NAT by inspecting the SIP Via header field in the 200 (OK) response to the initial SIP REGISTER request, and comparing the IP addresses in the Via sent-by and the received header field
一些ua可以通过检查对初始SIP寄存器请求的200（OK）响应中的SIP Via报头字段，并比较发送的Via中的IP地址和接收的报头字段，来确定SIP[rfc326]信令是否已经穿越NAT
parameters. If the IP addresses are not the same, then the UA can determine that there is a NAT in the path. Even though the media transport might not traverse the NAT, it is safe to assume that it will. This comparing mechanism does not work in all scenarios, though. For example, if SIP a request crosses a SIP proxy before crossing a NAT, the UA will not be able to detect the NAT by comparing the IP addresses.
参数。如果IP地址不相同，则UA可以确定路径中存在NAT。即使媒体传输可能不会穿越NAT，也可以安全地假设它会穿越NAT。不过，这种比较机制并不适用于所有场景。例如，如果SIP a请求在穿越NAT之前穿越SIP代理，UA将无法通过比较IP地址来检测NAT。
If an SDP offer includes an a=setup "actpass" attribute value, the SDP answerer MAY include an a=setup "active" attribute value in the SDP answer, but SHOULD include an a=setup "passive" attribute value if it knows that it is not located behind a NAT.
如果SDP报价包含a=setup“actpass”属性值，则SDP应答者可在SDP应答中包含a=setup“ACT”属性值，但如果知道其不位于NAT后面，则应包含a=setup“被动”属性值。
Once the active UA has established the MSRP transport connection, the UA must immediately send an MSRP SEND request, as defined in [RFC4975].
一旦活动UA建立了MSRP传输连接，UA必须立即发送MSRP发送请求，如[RFC4975]中所定义。
NOTE: According to [RFC4975], the initiating UA is always active, but when COMEDIA is used, the a=setup attribute is used to negotiate which UA becomes active.
注：根据[RFC4975]，起始UA始终处于活动状态，但当使用COMEDIA时，a=设置属性用于协商哪个UA处于活动状态。
If an MSRP UA conformant to this document uses Transport Layer Security (TLS), it MUST use the TLS mechanisms defined in [RFC4975] and [RFC4976].
如果符合本文件要求的MSRP UA使用传输层安全（TLS），则必须使用[RFC4975]和[RFC4976]中定义的TLS机制。
According to [RFC4975], the connection can be established with or without TLS mutual authentication. In case mutual authentication is not used, the listening device waits until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description. From the TLS authentication point of view, it is thus irrelevant whether an endpoint takes the active or passive role.
根据[RFC4975]，可以通过TLS相互认证或不通过TLS相互认证建立连接。在不使用相互认证的情况下，侦听设备等待直到它接收到连接上的请求，此时它从相关联的会话描述推断连接设备的身份。因此，从TLS身份验证的角度来看，端点是扮演主动角色还是被动角色无关紧要。
If an MSRP UA uses a self-signed TLS certificate to authenticate itself to MSRP peers, it also includes its certificate fingerprint in the SDP.
如果MSRP UA使用自签名TLS证书向MSRP对等方验证自身，则它还将其证书指纹包含在SDP中。
Note that fingerprints can only be exchanged in peer-to-peer communication, as MSRP relays [RFC4976] will not receive the SDP payloads containing the fingerprint attributes.
请注意，指纹只能在对等通信中交换，因为MSRP中继[RFC4976]不会接收包含指纹属性的SDP有效载荷。
MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] defines connection reuse procedures for MSRP, and this document does not modify those procedures.
MSRP UAs不得使用SDP a=连接属性。[RFC4975]定义了MSRP的连接重用过程，本文档不修改这些过程。
If an MSRP UA receives an a=connection attribute, the UA MUST ignore it.
如果MSRP UA收到a=连接属性，UA必须忽略该属性。
If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST always initiate a transport connection towards the relay, no matter what value the client has provided in the a=setup attribute.
如果MSRP UA位于MSRP中继器[RFC4976]后面，则UA必须始终向中继器发起传输连接，无论客户端在a=setup属性中提供了什么值。
NOTE: Even if an MSRP UA initiates the TCP connection towards its relay, the UA will only send a SEND request if the UA is active, based on the COMEDIA negotiation.
注意：即使MSRP UA向其中继发起TCP连接，UA也仅在UA处于活动状态时才会根据喜剧协商发送发送请求。
An MSRP UA conformant to this document can interoperate with a UA that follows the connection model defined in [RFC4975]. However, if an MSRP UA conformant to this document is located behind a NAT, does not proxy its MSRP communication via an MSRP relay, and receives an SDP offer from a remote UA that follows the connection model defined in [RFC4975], then NAT traversal can only be achieved if the MSRP UA supports ICE [ICE-TCP] or if the network supports Session Border Controller (SBC)-assisted NAT traversal for TCP.
符合本文件要求的MSRP UA可以与遵循[RFC4975]中定义的连接模型的UA进行互操作。但是，如果符合本文件要求的MSRP UA位于NAT后面，不通过MSRP中继代理其MSRP通信，并从遵循[RFC4975]中定义的连接模型的远程UA接收SDP报价，则只有在MSRP UA支持ICE[ICE-TCP]的情况下，才能实现NAT穿越或者如果网络支持会话边界控制器（SBC）辅助的TCP NAT穿越。
According to the connection model defined in [RFC4975], the MSRP UA that sends the SDP offer becomes the active party, and it is responsible for creating the MSRP transport connection towards the remote UA if a new connection is required.
根据[RFC4975]中定义的连接模型，发送SDP报价的MSRP UA成为活动方，如果需要新连接，它负责创建指向远程UA的MSRP传输连接。
When COMEDIA is used, either the sender or the receiver of the SDP offer can become the active party. [RFC4975] requires that the active party immediately issue an MSRP SEND request once the connection has been established. This allows the passive party to bind the inbound TCP connection to the message session identified by the session id part of its MSRP URI. The use of COMEDIA does not change this requirement, but the sender of the SDP offer is no longer assumed to always become the active party.
当使用喜剧时，SDP报价的发送方或接收方都可以成为主动方。[RFC4975]要求活动方在建立连接后立即发出MSRP发送请求。这允许被动方将入站TCP连接绑定到由其MSRP URI的会话id部分标识的消息会话。喜剧的使用不会改变这一要求，但SDP提议的发送者不再被认为总是积极的一方。
The active party also takes the role of the TLS client, if TLS is used to protect the MSRP messages. However, there are no procedures in [RFC4975] that would break in case the receiver of the SDP offer takes the role of the TLS client, and the level of security provided by TLS is not affected.
如果TLS用于保护MSRP消息，则活动方还担任TLS客户端的角色。但是，[RFC4975]中没有任何程序会在SDP报价的接收者担任TLS客户的情况下中断，并且TLS提供的安全级别不受影响。
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, and Shida Schubert for their guidance and input in producing this document.
感谢Ben Campbell、Remi Denis Courmont、Nancy Greene、Hadriel Kaplan、Adam Roach、Robert Sparks、Salvatore Loreto和Shida Schubert在编写本文件过程中提供的指导和意见。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[RFC4976]Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 49762007年9月。
[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月。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010.
[RFC5780]MacDonald，D.和B.Lowekamp，“使用NAT会话遍历实用程序进行NAT行为发现（STUN）”，RFC 57802010年5月。
[ICE-TCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, February 2011.
[ICE-TCP]Rosenberg，J.，Keranen，A.，Lowekamp，B.，和A.Roach，“具有交互式连接建立（ICE）的TCP候选者”，正在进行的工作，2011年2月。
[OMA-SIMPLE] Open Mobile Alliance, "Instant Messaging using SIMPLE", OMA-TS-SIMPLE_IM-V1_0-20090901-D, September 2009.
[OMA-SIMPLE]开放式移动联盟，“使用SIMPLE的即时通讯”，OMA-TS-SIMPLE_IM-V1_0-200901-D，2009年9月。
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com
Staffan Blau Ericsson AB PO Box 407 Sweden
Staffan Blau Ericsson AB邮箱407瑞典
EMail: staffan.blau@ericsson.com
EMail: staffan.blau@ericsson.com