Internet Engineering Task Force (IETF) P. Dunkley
Request for Comments: 7977 G. Llewellyn
Updates: 4975, 4976 Xura
Category: Standards Track V. Pascual
ISSN: 2070-1721 Oracle
G. Salgueiro
R. Ravindranath
Cisco
September 2016
Internet Engineering Task Force (IETF) P. Dunkley
Request for Comments: 7977 G. Llewellyn
Updates: 4975, 4976 Xura
Category: Standards Track V. Pascual
ISSN: 2070-1721 Oracle
G. Salgueiro
R. Ravindranath
Cisco
September 2016
The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
作为消息会话中继协议（MSRP）传输的WebSocket协议
Abstract
摘要
The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFCs 4975 and 4976.
在无法直接访问TCP和UDP的情况下（例如，在web浏览器的JavaScript中），WebSocket协议支持客户端和服务器之间的双向实时通信。本文档指定了一个新的WebSocket子策略，作为消息会话中继协议（MSRP）客户端和中继之间的可靠传输机制，以便在新场景中使用MSRP。本文件规范性地更新了RFCs 4975和4976。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7977.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7977.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. WebSocket Protocol Overview . . . . . . . . . . . . . . . . . 5
4. The WebSocket MSRP Subprotocol . . . . . . . . . . . . . . . 6
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. MSRP Encoding . . . . . . . . . . . . . . . . . . . . . . 7
5. MSRP WebSocket Transport . . . . . . . . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . 7
5.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . 7
5.2.2. SDP Transport Protocol . . . . . . . . . . . . . . . 8
5.3. Updates to RFC 4976 . . . . . . . . . . . . . . . . . . . 8
5.3.1. AUTH Request Authentication . . . . . . . . . . . . . 8
6. Connection Keepalive . . . . . . . . . . . . . . . . . . . . 9
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 10
8.1.1. WebSocket Authentication . . . . . . . . . . . . . . 10
8.1.2. MSRP Authentication . . . . . . . . . . . . . . . . . 12
8.2. Example Session: MSRP WebSocket Client to MSRP Client . . 14
8.2.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 14
8.2.2. SEND (MSRP WebSocket Client to MSRP Client) . . . . . 15
8.2.3. SEND (MSRP Client to MSRP WebSocket Client) . . . . . 16
8.3. Example Session: Two MSRP WebSocket Clients . . . . . . . 18
8.3.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 18
8.3.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. Example Session: MSRP WebSocket Client to MSRP Client
Using a Relay . . . . . . . . . . . . . . . . . . . . . . 20
8.4.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 20
8.4.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Implementation Guidelines: MSRP WebSocket Client
Considerations . . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. WebSocket Protocol Overview . . . . . . . . . . . . . . . . . 5
4. The WebSocket MSRP Subprotocol . . . . . . . . . . . . . . . 6
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. MSRP Encoding . . . . . . . . . . . . . . . . . . . . . . 7
5. MSRP WebSocket Transport . . . . . . . . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . 7
5.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . 7
5.2.2. SDP Transport Protocol . . . . . . . . . . . . . . . 8
5.3. Updates to RFC 4976 . . . . . . . . . . . . . . . . . . . 8
5.3.1. AUTH Request Authentication . . . . . . . . . . . . . 8
6. Connection Keepalive . . . . . . . . . . . . . . . . . . . . 9
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 10
8.1.1. WebSocket Authentication . . . . . . . . . . . . . . 10
8.1.2. MSRP Authentication . . . . . . . . . . . . . . . . . 12
8.2. Example Session: MSRP WebSocket Client to MSRP Client . . 14
8.2.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 14
8.2.2. SEND (MSRP WebSocket Client to MSRP Client) . . . . . 15
8.2.3. SEND (MSRP Client to MSRP WebSocket Client) . . . . . 16
8.3. Example Session: Two MSRP WebSocket Clients . . . . . . . 18
8.3.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 18
8.3.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. Example Session: MSRP WebSocket Client to MSRP Client
Using a Relay . . . . . . . . . . . . . . . . . . . . . . 20
8.4.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 20
8.4.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Implementation Guidelines: MSRP WebSocket Client
Considerations . . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
The WebSocket [RFC6455] protocol enables message exchange between clients and servers on top of a persistent TCP connection (optionally secured with Transport Layer Security (TLS) [RFC5246]). The initial protocol handshake makes use of HTTP [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.
WebSocket[RFC6455]协议支持客户端和服务器之间在持久TCP连接（可选使用传输层安全性（TLS）[RFC5246]进行保护）的基础上进行消息交换。初始协议握手利用HTTP[RFC7230]语义，允许WebSocket协议重用现有HTTP基础设施。
Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. The specification in this document enables usage of Message Session Relay Protocol [RFC4975] in these scenarios.
现代web浏览器包括一个WebSocket客户端堆栈，它符合W3C指定的WebSocket API[WS-API]。预计其他客户端应用程序（在个人计算机和智能手机等设备上运行的应用程序）也将提供WebSocket客户端堆栈。本文档中的规范允许在这些场景中使用消息会话中继协议[RFC4975]。
This specification defines a new WebSocket subprotocol (as defined in Section 1.9 in [RFC6455]) for transporting MSRP messages between a WebSocket client and MSRP relay [RFC4976] containing a WebSocket server, a new transport for MSRP, and procedures for MSRP clients and relays implementing the WebSocket transport.
本规范定义了一个新的WebSocket子目录（如[RFC6455]第1.9节中的定义），用于在WebSocket客户端和包含WebSocket服务器的MSRP中继[RFC4976]之间传输MSRP消息、MSRP的新传输以及MSRP客户端和中继实现WebSocket传输的过程。
MSRP over WebSocket is well suited for MSRP interactions between clients and servers. Common use cases for MSRP over WebSocket include:
WebSocket上的MSRP非常适合于客户端和服务器之间的MSRP交互。基于WebSocket的MSRP的常见用例包括：
o Human-to-machine messaging
o 人机信息传递
o Client-to-server data exchange (for example, application control signaling)
o 客户端到服务器的数据交换（例如，应用程序控制信令）
o Human-to-human messaging where local policy requires authentication and/or logging
o 人与人之间的消息传递，其中本地策略需要身份验证和/或日志记录
MSRP Connection Establishment for Media Anchoring (MSRP-CEMA) [RFC6714] is outside of the scope of this document, as this document is intended to describe connecting to a WebSocket server that is an MSRP relay.
媒体锚定的MSRP连接建立（MSRP-CEMA）[RFC6714]不在本文件范围内，因为本文件旨在描述连接到作为MSRP中继的WebSocket服务器。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
MSRP WebSocket Client: An MSRP entity capable of opening outbound connections to MSRP relays that are WebSocket servers and communicating using the WebSocket MSRP subprotocol as defined by this document.
MSRP WebSocket客户端：一个MSRP实体，能够打开与作为WebSocket服务器的MSRP中继的出站连接，并使用本文档定义的WebSocket MSRP子目录进行通信。
MSRP WebSocket Server: An MSRP entity (specifically an MSRP relay [RFC4976]) capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket MSRP subprotocol as defined by this document.
MSRP WebSocket服务器：一个MSRP实体（特别是MSRP中继[RFC4976]），能够侦听来自WebSocket客户端的入站连接，并使用本文档定义的WebSocket MSRP子策略进行通信。
The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC5246]) in which both the client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket subprotocol and extensions negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes.
WebSocket协议[RFC6455]是TCP之上的一个传输层（可选地使用TLS[RFC5246]进行保护），其中客户端和服务器在两个方向上交换消息单元。该协议定义了连接握手、WebSocket子策略和扩展协商、用于发送应用程序和控制数据的帧格式、屏蔽机制以及用于指示断开原因的状态代码。
The WebSocket connection handshake is based on HTTP [RFC7230] and utilizes the HTTP GET method with an "Upgrade" request. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed, the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, client and server agree on the application protocol to use on top of the WebSocket transport. Such application protocol (also known as a "WebSocket subprotocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (such as the WebSocket MSRP subprotocol defined in this document). Once the HTTP 101 response is processed, both client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges.
WebSocket连接握手基于HTTP[RFC7230]，并利用HTTP GET方法和“升级”请求。这由客户端发送，然后由服务器（如果协商成功）用HTTP 101状态代码进行应答。握手完成后，连接将从HTTP升级到WebSocket协议。此握手过程旨在重用现有的HTTP基础结构。在连接握手过程中，客户端和服务器在WebSocket传输之上使用的应用程序协议上达成一致。这种应用程序协议（也称为“WebSocket子协议”）定义了端点交换的消息的格式和语义。这可以是自定义协议或标准协议（如本文档中定义的WebSocket MSRP子协议）。处理HTTP 101响应后，客户机和服务器都会重用底层TCP连接，以便相互发送WebSocket消息和控制帧。与普通HTTP不同，此连接是持久的，可用于多个消息交换。
WebSocket defines message units to be used by applications for the exchange of data, so it provides a message boundary-preserving transport layer. These message units can contain either UTF-8 text or binary data and can be split into multiple WebSocket text/binary transport frames as needed by the WebSocket stack.
WebSocket定义了应用程序用于数据交换的消息单元，因此它提供了一个保留消息边界的传输层。这些消息单元可以包含UTF-8文本或二进制数据，并且可以根据WebSocket堆栈的需要拆分为多个WebSocket文本/二进制传输帧。
The WebSocket API [WS-API] for web browsers only defines callbacks to be invoked upon receipt of an entire message unit regardless of whether it was received in a single WebSocket frame or split across multiple frames.
web浏览器的WebSocket API[WS-API]仅定义在接收到整个消息单元时调用的回调，而不管它是在单个WebSocket帧中接收的还是在多个帧中分割的。
The term WebSocket subprotocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket MSRP subprotocol for carrying MSRP requests and responses through a WebSocket connection.
术语WebSocket Subtocol是指分层在WebSocket连接之上的应用程序级协议。本文档指定了WebSocket MSRP子目录，用于通过WebSocket连接承载MSRP请求和响应。
The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage of the WebSocket MSRP subprotocol during the WebSocket handshake procedure as defined in Section 1.3 of [RFC6455]. The Client MUST include the value "msrp" in the Sec-WebSocket-Protocol header in its handshake request. The 101 reply from the Server MUST contain "msrp" in its corresponding Sec-WebSocket-Protocol header.
MSRP WebSocket客户端和MSRP WebSocket服务器在[RFC6455]第1.3节定义的WebSocket握手过程中协商WebSocket MSRP子策略的使用。客户端必须在其握手请求中包含Sec WebSocket协议头中的值“msrp”。来自服务器的101回复必须在其相应的Sec WebSocket协议头中包含“msrp”。
Below is an example of a WebSocket handshake in which the Client requests the WebSocket MSRP subprotocol support from the Server:
下面是一个WebSocket握手示例，其中客户端从服务器请求WebSocket MSRP子策略支持：
GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13
GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13
The handshake response from the Server accepting the WebSocket MSRP subprotocol would look as follows:
来自接受WebSocket MSRP子目录的服务器的握手响应如下所示：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp
Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of MSRP requests and responses. The WebSocket messages transmitted over this connection MUST conform to the negotiated WebSocket subprotocol.
协商完成后，将建立WebSocket连接，并可用于传输MSRP请求和响应。通过此连接传输的WebSocket消息必须符合协商的WebSocket子目录。
WebSocket messages can be transported in either UTF-8 text frames or binary frames. MSRP [RFC4975] allows both text and binary bodies in MSRP requests. Therefore, MSRP WebSocket Clients and Servers MUST accept both text and binary frames.
WebSocket消息可以在UTF-8文本帧或二进制帧中传输。MSRP[RFC4975]允许MSRP请求中的文本和二进制体。因此，MSRP WebSocket客户端和服务器必须同时接受文本和二进制帧。
The WebSocket API [WS-API] does not allow developers to choose whether to send UTF-8 text or binary frames but will not send non-UTF-8 characters in a text frame. The content of text frames MUST be interpreted as binary by WebSocket Clients and Servers.
WebSocket API[WS-API]不允许开发人员选择是发送UTF-8文本帧还是二进制帧，但不会在文本帧中发送非UTF-8字符。WebSocket客户端和服务器必须将文本帧的内容解释为二进制。
WebSocket clients cannot receive WebSocket connections initiated by other WebSocket clients or WebSocket servers. This means that it is challenging for an MSRP client to communicate directly with other MSRP clients. Therefore, all MSRP-over-WebSocket messages MUST be routed via an MSRP WebSocket Server. MSRP traffic transported over WebSockets MUST be protected by using a Secure WebSocket (WSS) connection (using TLS [RFC5246] over TCP).
WebSocket客户端无法接收由其他WebSocket客户端或WebSocket服务器启动的WebSocket连接。这意味着MSRP客户端直接与其他MSRP客户端通信是一项挑战。因此，所有MSRP over WebSocket消息必须通过MSRP WebSocket服务器路由。必须使用安全WebSocket（WSS）连接（通过TCP使用TLS[RFC5246]）来保护通过WebSocket传输的MSRP流量。
MSRP WebSocket Servers can be used to route MSRP messages between MSRP WebSocket Clients and between MSRP WebSocket Clients and "normal" MSRP clients and relays.
MSRP WebSocket服务器可用于在MSRP WebSocket客户端之间以及MSRP WebSocket客户端与“正常”MSRP客户端和中继之间路由MSRP消息。
Each MSRP chunk MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one MSRP chunk.
每个MSRP区块必须包含在单个WebSocket消息中，并且WebSocket消息不得包含多个MSRP区块。
This simplifies parsing of MSRP messages for both clients and servers. When large messages are sent by a non-WebSocket peer, MSRP chunking (as defined in Section 5.1 of [RFC4975]) MUST be used by the WebSocket MSRP Servers to split the message into several smaller MSRP chunks.
这简化了对客户端和服务器的MSRP消息的解析。当大型消息由非WebSocket对等方发送时，WebSocket MSRP服务器必须使用MSRP分块（定义见[RFC4975]第5.1节）将消息分为几个较小的MSRP分块。
This document defines the value "ws" as the transport parameter value for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket subprotocol as transport.
本文档将值“ws”定义为MSRP URI[RFC3986]的传输参数值，该URI将使用MSRP WebSocket子目录作为传输进行联系。
The updated ABNF [RFC5234] for this parameter is the following (the original BNF for this parameter can be found in [RFC4975]):
此参数的更新ABNF[RFC5234]如下所示（此参数的原始BNF可在[RFC4975]中找到）：
transport = "tcp" / "ws" / 1*ALPHANUM
transport = "tcp" / "ws" / 1*ALPHANUM
This document does not define a new Session Description Protocol (SDP) transport protocol for MSRP over WebSockets. As all MSRP-over-WebSocket messages MUST be routed via an MSRP WebSocket Server, the MSRP WebSocket Client MUST specify "TCP/TLS/MSRP" protocols in the SDP m-line -- that being the protocol used by non-WebSocket clients and between MSRP relays (see Section 8.1 of [RFC4975]).
本文档没有为WebSocket上的MSRP定义新的会话描述协议（SDP）传输协议。由于所有MSRP over WebSocket消息必须通过MSRP WebSocket服务器路由，MSRP WebSocket客户端必须在SDP m-line中指定“TCP/TLS/MSRP”协议，即非WebSocket客户端和MSRP中继之间使用的协议（见[RFC4975]第8.1节）。
The "ws" transport parameter will appear in the endpoint URI in the SDP "path" attribute (see Section 8.2 of [RFC4975]). MSRP was designed with the possibility of new transport bindings in mind (see Section 6 of [RFC4975]), so MSRP implementations are expected to allow unrecognized transports, provided that they do not have to establish a direct connection to the resource described by the URI.
“ws”传输参数将出现在SDP“path”属性的端点URI中（请参见[RFC4975]第8.2节）。MSRP的设计考虑到了新传输绑定的可能性（请参见[RFC4975]第6节），因此MSRP实现应允许未识别的传输，前提是它们不必建立到URI所描述资源的直接连接。
The MSRP relay specification [RFC4976] states that AUTH requests MUST be authenticated. This document modifies this requirement to state that all connections between MSRP clients and relays MUST be authenticated. In the case of the MSRP WebSocket Clients, there are three possible authentication mechanisms:
MSRP中继规范[RFC4976]规定必须对身份验证请求进行身份验证。本文件修改了该要求，规定MSRP客户端和继电器之间的所有连接必须经过认证。对于MSRP WebSocket客户端，有三种可能的身份验证机制：
1. HTTP Digest authentication in AUTH (as per [RFC4976]).
1. 验证中的HTTP摘要身份验证（根据[RFC4976]）。
2. Cookie-based or HTTP Digest authentication in the WebSocket Handshake (see Section 7).
2. WebSocket握手中基于Cookie或HTTP摘要的身份验证（参见第7节）。
3. Mutual TLS between the WebSocket-based MSRP client and the WebSocket server.
3. 基于WebSocket的MSRP客户端和WebSocket服务器之间的相互TLS。
The AUTH request is a required event when authentication occurs at the WebSocket connection level since the "Use-Path:" header required to create the SDP offer is included in the 200 OK response to the AUTH request.
当在WebSocket连接级别进行身份验证时，身份验证请求是必需的事件，因为创建SDP提供所需的“使用路径：”头包含在对身份验证请求的200 OK响应中。
It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their WebSocket connections open by sending periodic WebSocket "Ping" frames as described in Section 5.5.2 of [RFC6455].
建议MSRP WebSocket客户端和服务器通过发送[RFC6455]第5.5.2节所述的定期WebSocket“Ping”帧来保持其WebSocket连接打开。
The WebSocket API [WS-API] does not provide a mechanism for applications running in a web browser to control whether or not periodic WebSocket "Ping" frames are sent to the server. The implementation of such a keepalive feature is the decision of each web browser manufacturer and may also depend on the configuration of the web browser.
WebSocket API[WS-API]没有为在web浏览器中运行的应用程序提供一种机制来控制是否定期向服务器发送WebSocket“Ping”帧。这种保持功能的实现是每个web浏览器制造商的决定，也可能取决于web浏览器的配置。
A future WebSocket protocol extension providing a similar keepalive mechanism could also be used.
还可以使用提供类似keepalive机制的未来WebSocket协议扩展。
When MSRP WebSocket Clients or Servers cannot use WebSocket "Ping" frames to keep connections open, an MSRP implementation MAY use bodiless SEND requests as described in Section 7.1 of [RFC4975]. MSRP WebSocket Clients or Servers MUST be prepared to receive bodiless SEND requests.
当MSRP WebSocket客户端或服务器无法使用WebSocket“Ping”帧保持连接打开时，MSRP实现可以使用[RFC4975]第7.1节中所述的无体发送请求。MSRP WebSocket客户端或服务器必须准备好接收bodiless发送请求。
Prior to sending MSRP requests, an MSRP WebSocket Client connects to an MSRP WebSocket Server and performs the connection handshake. As described in Section 3, the handshake procedure involves a HTTP GET method request from the Client and a response from the Server including an HTTP 101 status code.
在发送MSRP请求之前，MSRP WebSocket客户端连接到MSRP WebSocket服务器并执行连接握手。如第3节所述，握手过程涉及来自客户端的HTTP GET方法请求和来自服务器的包括HTTP 101状态代码的响应。
In order to authorize the WebSocket connection, the MSRP WebSocket Server MAY inspect any HTTP headers present (for example, Cookie [RFC6265], Host [RFC7230], or Origin [RFC6454]) in the HTTP GET request. For many web applications, the value of such a Cookie is provided by the web server once the user has authenticated themselves to the web server, which could be done by many existing mechanisms. As an alternative method, the MSRP WebSocket Server could request HTTP authentication by replying to the Client's GET method request with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers this usage in Section 4.1 and is paraphrased as follows:
为了授权WebSocket连接，MSRP WebSocket服务器可以检查HTTP GET请求中存在的任何HTTP头（例如，Cookie[RFC6265]、主机[RFC7230]或源[RFC6454]）。对于许多web应用程序，一旦用户向web服务器进行了身份验证，web服务器就会提供此类Cookie的价值，这可以通过许多现有机制来完成。作为一种替代方法，MSRP WebSocket服务器可以通过使用HTTP 401状态代码响应客户端的GET方法请求来请求HTTP身份验证。WebSocket协议[RFC6455]在第4.1节中介绍了这种用法，并解释如下：
If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures; in particular, the client might perform authentication if it receives a 401 status code.
如果从服务器接收到的状态代码不是101，则WebSocket客户端堆栈根据HTTP[RFC7230]过程处理响应；特别是，如果客户端接收到401状态码，它可能会执行身份验证。
If the HTTP GET request contains an Origin header, the MSRP WebSocket Server SHOULD indicate Cross-Origin Resource Sharing [CORS] by adding an Access-Control-Allow-Origin header to the 101 response.
如果HTTP GET请求包含源站标头，MSRP WebSocket服务器应通过向101响应添加访问控制允许源站标头来指示跨源站资源共享[CORS]。
Regardless of whether the MSRP WebSocket Server requires authentication during the WebSocket handshake, authentication MAY be requested at the MSRP protocol level by an MSRP Server challenging AUTH requests using a 401 response. Therefore, an MSRP WebSocket Client SHOULD support HTTP Digest [RFC7235] authentication as stated in [RFC4976].
无论MSRP WebSocket服务器在WebSocket握手期间是否需要身份验证，MSRP服务器都可以使用401响应在MSRP协议级别请求身份验证。因此，MSRP WebSocket客户端应支持[RFC4976]中所述的HTTP摘要[RFC7235]身份验证。
Alice (MSRP WSS) a.example.com
| |
|HTTP GET (WS handshake) F1 |
|---------------------------->|
|101 Switching Protocols F2 |
|<----------------------------|
| |
|AUTH F3 |
|---------------------------->|
|200 OK F4 |
|<----------------------------|
| |
Alice (MSRP WSS) a.example.com
| |
|HTTP GET (WS handshake) F1 |
|---------------------------->|
|101 Switching Protocols F2 |
|<----------------------------|
| |
|AUTH F3 |
|---------------------------->|
|200 OK F4 |
|<----------------------------|
| |
Alice loads a web page using her web browser and retrieves JavaScript code implementing the WebSocket MSRP subprotocol defined in this document. The JavaScript code (an MSRP WebSocket Client) establishes a secure WebSocket connection with an MSRP relay (an MSRP WebSocket Server) at a.example.com. Upon WebSocket connection, Alice constructs and sends an MSRP AUTH request. Since the JavaScript stack in a browser has no way to determine the local address from which the WebSocket connection was made, this implementation uses a random ".invalid" domain name for the hostpart of the From-Path URI (see Appendix A).
Alice使用她的web浏览器加载网页，并检索实现本文档中定义的WebSocket MSRP子脚本的JavaScript代码。JavaScript代码（MSRP WebSocket客户端）在a.example.com上与MSRP中继（MSRP WebSocket服务器）建立安全的WebSocket连接。在连接WebSocket时，Alice构造并发送MSRP身份验证请求。由于浏览器中的JavaScript堆栈无法确定进行WebSocket连接的本地地址，因此此实现为from路径URI的主机部分使用随机的“.invalid”域名（请参见附录a）。
In this example, it is assumed that authentication is performed at the WebSocket layer (not shown), so no challenge is issued for the MSRP AUTH message:
在此示例中，假定在WebSocket层（未显示）执行身份验证，因此不对MSRP AUTH消息发出质询：
F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS)
F1 HTTP GET（WS握手）Alice->a.example.com（TLS）
GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13
GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13
F2 101 Switching Protocols a.example.com -> Alice (TLS)
F2101交换协议a.example.com->Alice（TLS）
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp
F3 AUTH Alice -> a.example.com (transport WSS)
F3验证Alice->a.example.com（传输WSS）
MSRP 49fi AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------49fi$
MSRP 49fi AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------49fi$
F4 200 OK a.example.com -> Alice (transport WSS)
F4 200 OK a.example.com->Alice（运输WSS）
MSRP 49fi 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
Expires: 900
-------49fi$
MSRP 49fi 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
Expires: 900
-------49fi$
Alice (MSRP WSS) a.example.com
| |
|HTTP GET (WS handshake) F1 |
|---------------------------->|
|101 Switching Protocols F2 |
|<----------------------------|
| |
|AUTH F3 |
|---------------------------->|
|401 Unauthorized F4 |
|<----------------------------|
|AUTH F5 |
|---------------------------->|
|200 OK F6 |
|<----------------------------|
| |
Alice (MSRP WSS) a.example.com
| |
|HTTP GET (WS handshake) F1 |
|---------------------------->|
|101 Switching Protocols F2 |
|<----------------------------|
| |
|AUTH F3 |
|---------------------------->|
|401 Unauthorized F4 |
|<----------------------------|
|AUTH F5 |
|---------------------------->|
|200 OK F6 |
|<----------------------------|
| |
This example uses the same scenario as Section 8.1.1 but with authentication performed at the MSRP layer.
本示例使用与第8.1.1节相同的场景，但在MSRP层执行身份验证。
Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual MSRP message.
请注意，MSRP不允许折线。示例中的“\”表示由于本文档行长度的限制而导致的行延续。反斜杠和额外的CRLF都不包含在实际的MSRP消息中。
F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS)
F1 HTTP GET（WS握手）Alice->a.example.com（TLS）
GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13
GET / HTTP/1.1
Host: a.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.example.com
Sec-WebSocket-Protocol: msrp
Sec-WebSocket-Version: 13
F2 101 Switching Protocols a.example.com -> Alice (TLS)
F2101交换协议a.example.com->Alice（TLS）
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp
F3 AUTH Alice -> a.example.com (transport WSS)
F3验证Alice->a.example.com（传输WSS）
MSRP 4rsxt9nz AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------4rsxt9nz$
MSRP 4rsxt9nz AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------4rsxt9nz$
F4 401 Unauthorized a.example.com -> Alice (transport WSS)
F4 401未经授权的a.example.com->Alice（传输WSS）
MSRP 4rsxt9nz 401 Unauthorized
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
WWW-Authenticate: Digest realm="example.com", \
nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", qop="auth"
-------4rsxt9nz$
MSRP 4rsxt9nz 401 Unauthorized
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
WWW-Authenticate: Digest realm="example.com", \
nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", qop="auth"
-------4rsxt9nz$
F5 AUTH Alice -> a.example.com (transport WSS)
F5验证Alice->a.example.com（传输WSS）
MSRP qy1hsow5 AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Authorization: Digest username="alice", realm="example.com", \
nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", \
uri="msrps://alice@a.example.com:443;ws", \
response="5011d0d58fe975e0d0cdc007ae26f4b7", \
qop=auth, cnonce="zic5ml401prb", nc=00000001
-------qy1hsow5$
MSRP qy1hsow5 AUTH
To-Path: msrps://alice@a.example.com:443;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Authorization: Digest username="alice", realm="example.com", \
nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", \
uri="msrps://alice@a.example.com:443;ws", \
response="5011d0d58fe975e0d0cdc007ae26f4b7", \
qop=auth, cnonce="zic5ml401prb", nc=00000001
-------qy1hsow5$
F6 200 OK a.example.com -> Alice (transport WSS)
F6 200 OK a.example.com->Alice（运输WSS）
MSRP qy1hsow5 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
Expires: 900
-------qy1hsow5$
MSRP qy1hsow5 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://alice@a.example.com:443;ws
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
Expires: 900
-------qy1hsow5$
The following subsections show various message exchanges occurring during the course of an MSRP session between a WebSocket client and a non-WebSocket client.
以下小节显示了在WebSocket客户端和非WebSocket客户端之间的MSRP会话过程中发生的各种消息交换。
The following example shows SDP that could be included in a SIP message to set up an MSRP session between Alice and Bob where Alice uses a WebSocket MSRP relay and Bob uses a traditional MSRP client without a relay.
下面的示例显示了可以包含在SIP消息中的SDP，用于在Alice和Bob之间建立MSRP会话，其中Alice使用WebSocket MSRP中继，Bob使用传统的MSRP客户端而不使用中继。
A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual SDP.
示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际SDP中既不包括反斜杠也不包括额外的CRLF。
Alice makes an offer with a path including the relay (having already successfully authenticated with the relay):
Alice提供包含中继的路径（已成功通过中继验证）：
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
In this offer, Alice wishes to receive MSRP messages via the relay at a.example.com. She wants to use TLS as the transport for the MSRP session (beyond the relay). She can accept message/cpim, text/plain, and text/html message bodies in SEND requests.
在此优惠中，Alice希望通过a.example.com上的中继接收MSRP消息。她希望使用TLS作为MSRP会话的传输（中继之外）。她可以接受SEND请求中的message/cpim、text/plain和text/html消息体。
Bob's answer to this offer could look like:
Bob对此提议的回答如下：
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://bob.example.com:49154/foo;tcp
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://bob.example.com:49154/foo;tcp
Here, Bob wishes to receive the MSRP messages at bob.example.com. He can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice. He does not need a relay to set up the MSRP session.
这里，Bob希望通过Bob.example.com接收MSRP消息。他只能接受SEND请求中的message/cpim和text/plain消息体，并拒绝了Alice提供的text/html内容。他不需要中继来建立MSRP会话。
Alice (MSRP WSS) a.example.com (MSRP TLS) Bob
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|
Alice (MSRP WSS) a.example.com (MSRP TLS) Bob
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|
Later in the session, Alice sends an instant message to Bob. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Bob over TLS.
稍后，Alice会向Bob发送一条即时消息。位于a.example.com的MSRP WebSocket服务器充当MSRP中继，通过TLS将消息路由到Bob。
Message details (A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response):
消息详细信息（示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际请求或响应中不包括反斜杠或额外的CRLF）：
F1 SEND Alice -> a.example.com (transport WSS)
F1发送Alice->a.example.com（传输WSS）
MSRP 6aef SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP 6aef SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------6aef$
Hi Bob, I'm about to send you file.mpeg
-------6aef$
F2 200 OK a.example.com -> Alice (transport WSS)
F2 200 OK a.example.com->Alice（运输WSS）
MSRP 6aef 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------6aef$
MSRP 6aef 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------6aef$
F3 SEND a.example.com -> Bob (transport TLS)
F3发送a.example.com->Bob（传输TLS）
MSRP juh76 SEND
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP juh76 SEND
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------juh76$
Hi Bob, I'm about to send you file.mpeg
-------juh76$
F4 200 OK Bob -> a.example.com (transport TLS)
F4 200 OK Bob->a.example.com（传输TLS）
MSRP juh76 200 OK
To-Path: msrps://a.example.com:2855/jui787s2f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------juh76$
MSRP juh76 200 OK
To-Path: msrps://a.example.com:2855/jui787s2f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------juh76$
Bob (MSRP TLS) a.example.com (MSRP WSS) Alice
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|
Bob (MSRP TLS) a.example.com (MSRP WSS) Alice
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|
Later in the session, Bob sends an instant message to Alice. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Alice over secure WebSocket.
在会话的后期，Bob向Alice发送了一条即时消息。位于a.example.com的MSRP WebSocket服务器充当MSRP中继，通过安全WebSocket将消息路由到Alice。
Message details (A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response):
消息详细信息（示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际请求或响应中不包括反斜杠或额外的CRLF）：
F1 SEND Bob -> a.example.com (transport TLS)
F1发送Bob->a.example.com（传输TLS）
MSRP xght6 SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://bob.example.com:49154/foo;tcp
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP xght6 SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://bob.example.com:49154/foo;tcp
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Thanks for the file.
-------xght6$
Thanks for the file.
-------xght6$
F2 200 OK a.example.com -> Bob (transport TLS)
F2 200 OK a.example.com->Bob（运输TLS）
MSRP xght6 200 OK
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------xght6$
MSRP xght6 200 OK
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------xght6$
F3 SEND a.example.com -> Alice (transport WSS)
F3发送a.example.com->Alice（传输WSS）
MSRP yh67 SEND
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://bob.example.com:49154/foo;tcp
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP yh67 SEND
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://bob.example.com:49154/foo;tcp
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Thanks for the file.
-------yh67$
Thanks for the file.
-------yh67$
F4 200 OK Alice -> a.example.com (transport WSS)
F4 200 OK Alice->a.example.com（运输WSS）
MSRP yh67 200 OK
To-Path: msrps://a.example.com:2855/jui787s2f;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------yh67$
MSRP yh67 200 OK
To-Path: msrps://a.example.com:2855/jui787s2f;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------yh67$
The following subsections show various message exchanges occurring during the course of an MSRP session between two WebSocket clients.
以下小节显示了在两个WebSocket客户端之间的MSRP会话过程中发生的各种消息交换。
The following example shows SDP that could be included in a SIP message to set up an MSRP session between Alice and Carol where both of them are using the same WebSocket MSRP relay.
下面的示例显示了可以包含在SIP消息中的SDP，用于在Alice和Carol之间建立MSRP会话，其中两人使用相同的WebSocket MSRP中继。
Alice makes an offer with a path including the relay (having already successfully authenticated with the relay):
Alice提供包含中继的路径（已成功通过中继验证）：
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
In this offer, Alice wishes to receive MSRP messages via the relay at a.example.com. She wants to use TLS as the transport for the MSRP session (beyond the relay). She can accept message/cpim, text/plain, and text/html message bodies in SEND requests.
在此优惠中，Alice希望通过a.example.com上的中继接收MSRP消息。她希望使用TLS作为MSRP会话的传输（中继之外）。她可以接受SEND请求中的message/cpim、text/plain和text/html消息体。
Carol's answer to this offer could look like:
卡罗尔对此提议的回答如下：
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://a.example.com:2855/iwnslt;tcp \
msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://a.example.com:2855/iwnslt;tcp \
msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
Here, Carol also wishes to receive the MSRP messages via a.example.com. She can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice.
在这里，Carol还希望通过a.example.com接收MSRP消息。她只能接受SEND请求中的message/cpim和text/plain消息正文，并拒绝了Alice提供的text/html内容。
Alice (MSRP WSS) a.example.com (MSRP WSS) Carol
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|
Alice (MSRP WSS) a.example.com (MSRP WSS) Carol
| | |
|SEND F1 | |
|---------------------------->| |
|200 OK F2 | |
|<----------------------------| |
| |SEND F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|
Later in the session, Alice sends an instant message to Carol. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Carol over secure WebSocket.
在课程的后期，Alice向Carol发送了一条即时消息。位于a.example.com的MSRP WebSocket服务器充当MSRP中继，通过安全WebSocket将消息路由到Carol。
In this example, both Alice and Carol are using MSRP WebSocket Clients and the same MSRP WebSocket Server. This means that a.example.com will appear twice in the To-Path in F1. a.example.com can either handle this internally or loop the MSRP SEND request back to itself as if it were two separate MSRP relays.
在本例中，Alice和Carol都使用MSRP WebSocket客户端和相同的MSRP WebSocket服务器。这意味着a.example.com将在F1中的“收件人”路径中出现两次。a、 example.com可以在内部处理此问题，也可以将MSRP发送请求循环回自身，就像它是两个独立的MSRP中继一样。
Message details (A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response):
消息详细信息（示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际请求或响应中不包括反斜杠或额外的CRLF）：
F1 SEND Alice -> a.example.com (transport WSS)
F1发送Alice->a.example.com（传输WSS）
MSRP kjh6 SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://a.example.com:2855/iwnslt;tcp \
msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP kjh6 SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://a.example.com:2855/iwnslt;tcp \
msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Carol, I sent that file to Bob.
-------kjh6$
Carol, I sent that file to Bob.
-------kjh6$
F2 200 OK a.example.com -> Alice (transport WSS)
F2 200 OK a.example.com->Alice（运输WSS）
MSRP kjh6 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------kjh6$
MSRP kjh6 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------kjh6$
F3 SEND a.example.com -> Carol (transport WSS)
F3发送a.example.com->Carol（运输WSS）
MSRP re58 SEND
To-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
From-Path: msrps://a.example.com:2855/iwnslt;tcp \
msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP re58 SEND
To-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
From-Path: msrps://a.example.com:2855/iwnslt;tcp \
msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Carol, I sent that file to Bob.
-------re58$
Carol, I sent that file to Bob.
-------re58$
F4 200 OK Carol -> a.example.com (transport WSS)
F4 200 OK Carol->a.example.com（运输WSS）
MSRP re58 200 OK
To-Path: msrps://a.example.com:2855/iwnslt;tcp
From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
-------re58$
MSRP re58 200 OK
To-Path: msrps://a.example.com:2855/iwnslt;tcp
From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
-------re58$
8.4. Example Session: MSRP WebSocket Client to MSRP Client Using a Relay
8.4. 示例会话：MSRP WebSocket客户端到使用中继的MSRP客户端
The following subsections show various message exchanges occurring during the course of an MSRP session between a WebSocket client and a non-WebSocket client, where the latter is also using an MSRP relay.
以下小节显示了在WebSocket客户端和非WebSocket客户端之间的MSRP会话过程中发生的各种消息交换，其中后者也使用MSRP中继。
The following example shows SDP that could be included in a SIP message to set up an MSRP session between Alice and Bob where Alice uses a WebSocket MSRP relay and Bob uses a traditional MSRP client with a separate relay.
下面的示例显示了可以包含在SIP消息中的SDP，用于在Alice和Bob之间建立MSRP会话，其中Alice使用WebSocket MSRP中继，Bob使用带有单独中继的传统MSRP客户端。
Alice makes an offer with a path including the relay (having already successfully authenticated with the relay):
Alice提供包含中继的路径（已成功通过中继验证）：
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
c=IN IP4 a.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid:2855/98cjs;ws
In this offer, Alice wishes to receive MSRP messages via the relay at a.example.com. She wants to use TLS as the transport for the MSRP session (beyond the relay). She can accept message/cpim, text/plain, and text/html message bodies in SEND requests.
在此优惠中，Alice希望通过a.example.com上的中继接收MSRP消息。她希望使用TLS作为MSRP会话的传输（中继之外）。她可以接受SEND请求中的message/cpim、text/plain和text/html消息体。
Bob's answer to this offer could look like:
Bob对此提议的回答如下：
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
Here, Bob wishes to receive the MSRP messages via the relay at relay.example.net. He can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice.
这里，Bob希望通过relay.example.net上的中继接收MSRP消息。他只能接受SEND请求中的message/cpim和text/plain消息体，并拒绝了Alice提供的text/html内容。
Alice (MSRP WSS) a.example.com (MSRP) relay.example.net (MSRP) Bob
| | | |
|SEND F1 | | |
|--------------------->| | |
|200 OK F2 | | |
|<---------------------| | |
| |SEND F3 | |
| |---------------------->| |
| |200 OK F4 | |
| |<----------------------| |
| | |SEND F5 |
| | |------------------->|
| | |200 OK F6 |
| | |<-------------------|
Alice (MSRP WSS) a.example.com (MSRP) relay.example.net (MSRP) Bob
| | | |
|SEND F1 | | |
|--------------------->| | |
|200 OK F2 | | |
|<---------------------| | |
| |SEND F3 | |
| |---------------------->| |
| |200 OK F4 | |
| |<----------------------| |
| | |SEND F5 |
| | |------------------->|
| | |200 OK F6 |
| | |<-------------------|
Later in the session, Alice sends an instant message to Bob. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Bob via his relay, relay.example.net.
稍后，Alice会向Bob发送一条即时消息。位于a.example.com的MSRP WebSocket服务器充当MSRP中继，通过Bob的中继relay.example.net将消息路由到Bob。
Message details (A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response):
消息详细信息（示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际请求或响应中不包括反斜杠或额外的CRLF）：
F1 SEND Alice -> a.example.com (transport WSS)
F1发送Alice->a.example.com（传输WSS）
MSRP Ycwt SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP Ycwt SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Bob, that was the wrong file - don't watch it!
-------Ycwt$
Bob, that was the wrong file - don't watch it!
-------Ycwt$
F2 200 OK a.example.com -> Alice (transport WSS)
F2 200 OK a.example.com->Alice（运输WSS）
MSRP Ycwt 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------Ycwt$
MSRP Ycwt 200 OK
To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
From-Path: msrps://a.example.com:2855/jui787s2f;tcp
-------Ycwt$
F3 SEND a.example.com -> relay.example.net (transport TLS)
F3发送a.example.com->relay.example.net（传输TLS）
MSRP 13GA SEND
To-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP 13GA SEND
To-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Bob, that was the wrong file - don't watch it!
-------13GA$
Bob, that was the wrong file - don't watch it!
-------13GA$
F4 200 OK relay.example.net -> a.example.com (transport TLS)
F4 200 OK relay.example.net->a.example.com（传输TLS）
MSRP 13GA 200 OK
To-Path: msrps://a.example.com:2855/iwnslt;tcp
From-Path: msrps://relay.example.net:2855/kwvin5f;tcp
-------13GA$
MSRP 13GA 200 OK
To-Path: msrps://a.example.com:2855/iwnslt;tcp
From-Path: msrps://relay.example.net:2855/kwvin5f;tcp
-------13GA$
F5 SEND relay.example.net -> bob.example.com (transport TLS)
F5发送中继.example.net->bob.example.com（传输TLS）
MSRP kXeg SEND
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP kXeg SEND
To-Path: msrps://bob.example.com:49154/foo;tcp
From-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
msrps://a.example.com:2855/jui787s2f;tcp \
msrps://df7jal23ls0d.invalid/98cjs;ws
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Bob, that was the wrong file - don't watch it!
-------kXeg$
Bob, that was the wrong file - don't watch it!
-------kXeg$
F6 200 OK bob.example.com -> relay.example.net (transport TLS)
F6 200 OK bob.example.com->relay.example.net（传输TLS）
MSRP kXeg 200 OK
To-Path: msrps://relay.example.net:2855/kwvin5f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------kXeg$
MSRP kXeg 200 OK
To-Path: msrps://relay.example.net:2855/kwvin5f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------kXeg$
MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP).
通过WebSocket传输的MSRP流量必须使用安全的WebSocket连接（通过TCP使用TLS[RFC5246]）进行保护。
When establishing a connection using MSRP over secure WebSockets, the client MUST authenticate the server using the server's certificate according to the WebSocket validation procedure in [RFC6455].
当通过安全WebSocket使用MSRP建立连接时，客户端必须根据[RFC6455]中的WebSocket验证过程，使用服务器的证书对服务器进行身份验证。
Any security considerations specific to the WebSocket protocol are detailed in the relevant specification [RFC6455] and are considered outside the scope of this document. The certificate name matching (described by [RFC6455]) and cryptosuite selection will be handled by the browser, and the browser's procedures will supersede those specified in [RFC4975].
WebSocket协议的任何特定安全注意事项在相关规范[RFC6455]中有详细说明，不在本文档范围内。证书名称匹配（由[RFC6455]描述）和cryptosuite选择将由浏览器处理，浏览器的过程将取代[RFC4975]中指定的过程。
Since the TLS session is always terminated at the MSRP WebSocket Server and the WebSocket server can see the plain text, the MSRP client (browser) SHOULD NOT indicate end-to-end security to user.
由于TLS会话始终在MSRP WebSocket服务器上终止，并且WebSocket服务器可以看到纯文本，因此MSRP客户端（浏览器）不应向用户指示端到端安全性。
TLS, as used in this document, should follow the best current practices defined in [RFC7525].
本文件中使用的TLS应遵循[RFC7525]中定义的当前最佳实践。
Per this specification, IANA has registered the WebSocket MSRP subprotocol in the "WebSocket Subprotocol Name Registry" with the following data:
根据本规范，IANA已使用以下数据在“WebSocket子目录名称注册表”中注册WebSocket MSRP子目录：
Subprotocol Identifier: msrp
次级方案标识符：msrp
Subprotocol Common Name: WebSocket Transport for MSRP (Message Session Relay Protocol)
子目录通用名称：MSRP（消息会话中继协议）的WebSocket传输
Subprotocol Definition: RFC 7977
次级方案定义：RFC 7977
Reference: RFC 7977
参考：RFC 7977
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 4975，DOI 10.17487/RFC4975，2007年9月<http://www.rfc-editor.org/info/rfc4975>.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <http://www.rfc-editor.org/info/rfc4976>.
[RFC4976]Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 4976，DOI 10.17487/RFC4976，2007年9月<http://www.rfc-editor.org/info/rfc4976>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <http://www.rfc-editor.org/info/rfc6455>.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 6455，DOI 10.17487/RFC6455，2011年12月<http://www.rfc-editor.org/info/rfc6455>.
[CORS] van Kesteren, A., Ed., "Cross-Origin Resource Sharing", W3C Recommendation, January 2014, <http://www.w3.org/TR/2014/REC-cors-20140116/>.
[CORS]van Kesteren，A.，Ed.，“跨来源资源共享”，W3C建议，2014年1月<http://www.w3.org/TR/2014/REC-cors-20140116/>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <http://www.rfc-editor.org/info/rfc2606>.
[RFC2606]Eastlake 3rd，D.和A.Panitz，“保留顶级域名”，BCP 32，RFC 2606，DOI 10.17487/RFC2606，1999年6月<http://www.rfc-editor.org/info/rfc2606>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<http://www.rfc-editor.org/info/rfc6454>.
[RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, DOI 10.17487/RFC6714, August 2012, <http://www.rfc-editor.org/info/rfc6714>.
[RFC6714]Holmberg，C.，Blau，S.，和E.Burger，“消息会话中继协议（MSRP）的媒体锚定连接建立（CEMA）”，RFC 6714，DOI 10.17487/RFC6714，2012年8月<http://www.rfc-editor.org/info/rfc6714>.
[RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", RFC 7118, DOI 10.17487/RFC7118, January 2014, <http://www.rfc-editor.org/info/rfc7118>.
[RFC7118]Baz Castillo，I.，Millan Villegas，J.，和V.Pascual，“作为会话启动协议（SIP）传输的WebSocket协议”，RFC 7118，DOI 10.17487/RFC7118，2014年1月<http://www.rfc-editor.org/info/rfc7118>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[WS-API] Hickson, I., Ed., "The WebSocket API", W3C Candidate Recommendation, September 2012, <https://www.w3.org/TR/2012/CR-websockets-20120920/>.
[WS-API]Hickson，I.，Ed.，“WebSocket API”，W3C候选推荐，2012年9月<https://www.w3.org/TR/2012/CR-websockets-20120920/>.
Appendix A. Implementation Guidelines: MSRP WebSocket Client Considerations
附录A.实施指南：MSRP WebSocket客户端注意事项
The JavaScript stack in web browsers does not have the ability to discover the local transport address used for originating WebSocket connections. Therefore, the MSRP WebSocket Client constructs a domain name consisting of a random token followed by the ".invalid" top-level domain name, as stated in [RFC2606], and uses it within its From-Path headers.
web浏览器中的JavaScript堆栈无法发现用于发起WebSocket连接的本地传输地址。因此，MSRP WebSocket客户端构建一个域名，该域名由随机令牌和“.invalid”顶级域名组成，如[RFC2606]中所述，并在其From路径头中使用。
The From-Path URI provided by MSRP clients that use an MSRP relay is not used for routing MSRP messages, thus, it is safe to set a random domain in the hostpart of the From-Path URI.
使用MSRP中继的MSRP客户端提供的From Path URI不用于路由MSRP消息，因此，在From Path URI的主机部分设置随机域是安全的。
Acknowledgements
致谢
Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and Victor Pascual, the authors of [RFC7118], which has inspired this document.
特别感谢[RFC7118]的作者Inaki Baz Castillo、Jose Luis Millan Villegas和Victor Pascual，这是本文的灵感来源。
Additional thanks to Inaki Baz Castillo, who pointed out that "web browser" shouldn't be used all the time, as this specification should be valid for smartphones and apps other than browsers and suggested clarifications to the SDP handling for MSRP over WebSocket.
还要感谢Inaki Baz Castillo，他指出“web浏览器”不应一直使用，因为本规范应适用于除浏览器以外的智能手机和应用程序，并建议澄清MSRP在WebSocket上的SDP处理。
Special thanks to James Wyatt from Crocodile RCS Ltd for helping with the JavaScript MSRP-over-WebSockets prototyping.
特别感谢鳄鱼RCS有限公司的jameswyatt，他通过WebSockets原型制作帮助了JavaScript-MSRP。
Special thanks to Anton Roman who has contributed to this document.
特别感谢安东·罗曼，他为本文件做出了贡献。
Thanks to Saul Ibarra Corretge for suggesting that the existing MSRP keepalive mechanism may be used when WebSocket pings are not available.
感谢Saul Ibarra Corretge建议，当WebSocket ping不可用时，可以使用现有的MSRP keepalive机制。
Thanks to Ben Campbell, Inaki Baz Castillo, Keith Drage, Olle Johansson, and Christer Holmberg for their thoughtful discussion comments and review feedback that led to the improvement of this document. Special thanks to Mary Barnes for both her technical review and for offering to act as Document Shepherd. Thanks also to Stephen Farrell, Alissa Cooper, Mirja Kuehlewind, Allison Mankin, Alexey Melnikov, and Kathleen Moriarty for their review comments.
感谢Ben Campbell、Inaki Baz Castillo、Keith Drage、Olle Johansson和Christer Holmberg，感谢他们深思熟虑的讨论意见和审查反馈，从而改进了本文件。特别感谢Mary Barnes的技术审查和担任文档管理员的提议。还要感谢斯蒂芬·法雷尔、艾莉莎·库珀、米佳·库勒温德、艾莉森·曼金、阿列克谢·梅尔尼科夫和凯瑟琳·莫里亚蒂的评论。
Authors' Addresses
作者地址
Peter Dunkley Xura Lancaster Court 8 Barnes Wallis Road Fareham PO15 5TU United Kingdom
Peter Dunkley Xura Lancaster Court 8 Barnes Wallis路Fareham PO15 5TU英国
Email: peter.dunkley@xura.com
Email: peter.dunkley@xura.com
Gavin Llewellyn Xura Lancaster Court 8 Barnes Wallis Road Fareham PO15 5TU United Kingdom
Gavin Llewellyn Xura Lancaster Court 8 Barnes Wallis路Fareham PO15 5TU英国
Email: gavin.llewellyn@xura.com
Email: gavin.llewellyn@xura.com
Victor Pascual Oracle
维克多·帕斯夸尔
Email: victor.pascual.avila@oracle.com
Email: victor.pascual.avila@oracle.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Gonzalo Salgueiro Cisco Systems，Inc.美国北卡罗来纳州Kit Creek Road研究三角公园7200-12号，邮编：27709
Email: gsalguei@cisco.com
Email: gsalguei@cisco.com
Ram Mohan Ravindranath Cisco Systems, Inc.
Ram Mohan Ravindranath思科系统公司。
Email: rmohanr@cisco.com
Email: rmohanr@cisco.com