Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 8124 G. Salgueiro
Category: Standards Track Cisco
ISSN: 2070-1721 March 2017
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 8124 G. Salgueiro
Category: Standards Track Cisco
ISSN: 2070-1721 March 2017
The Session Description Protocol (SDP) WebSocket Connection URI Attribute
会话描述协议（SDP）WebSocket连接URI属性
Abstract
摘要
The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.
WebSocket协议支持基于web的应用程序中客户端和服务器之间的双向实时通信。本文档指定使用WebSocket作为传输的应用程序协议对会话描述协议（SDP）的扩展。
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/rfc8124.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8124.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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. SDP Considerations ..............................................3
3.1. General ....................................................3
3.2. "websocket-uri" SDP Attribute ..............................4
3.3. "websocket-uri" Multiplexing Considerations ................4
4. SDP Offer/Answer Procedures .....................................5
4.1. General ....................................................5
4.2. Generating the Initial Offer ...............................5
4.3. Generating the Answer ......................................6
4.4. Offerer Processing of the Answer ...........................7
4.5. Modifying the Session ......................................7
4.6. Offerless INVITE Scenarios .................................8
5. Procedures at WebSocket Client ..................................8
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
7.1. Registration of the "websocket-uri" SDP Media Attribute ....9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
1. Introduction ....................................................2
2. Terminology .....................................................3
3. SDP Considerations ..............................................3
3.1. General ....................................................3
3.2. "websocket-uri" SDP Attribute ..............................4
3.3. "websocket-uri" Multiplexing Considerations ................4
4. SDP Offer/Answer Procedures .....................................5
4.1. General ....................................................5
4.2. Generating the Initial Offer ...............................5
4.3. Generating the Answer ......................................6
4.4. Offerer Processing of the Answer ...........................7
4.5. Modifying the Session ......................................7
4.6. Offerless INVITE Scenarios .................................8
5. Procedures at WebSocket Client ..................................8
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
7.1. Registration of the "websocket-uri" SDP Media Attribute ....9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
The WebSocket protocol [RFC6455] enables bidirectional 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 Hypertext Transfer Protocol (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 compliant with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (e.g., those running on personal computers, mobile devices, etc.) will also make a WebSocket client stack available. Several specifications have been written that define how different applications can use a WebSocket subprotocol as a reliable transport mechanism.
现代web浏览器包括一个WebSocket客户端堆栈，该堆栈符合W3C指定的WebSocket API[WS-API]。预计其他客户端应用程序（例如，在个人计算机、移动设备等上运行的客户端应用程序）也将提供WebSocket客户端堆栈。已经编写了一些规范，定义了不同的应用程序如何将WebSocket子脚本用作可靠的传输机制。
For example, [RFC7118] defines a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP)[RFC3261] entities to enable use of SIP in web-oriented deployments. Additionally, [RFC7977] defines a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays. [RFC7395] defines a WebSocket subprotocol for the Extensible Messaging and Presence Protocol (XMPP). Similarly, [BFCP-WEBSOCKET] defines a WebSocket subprotocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) [BFCP] entities to enable usage of BFCP in new scenarios.
例如，[RFC7118]将WebSocket子策略定义为会话启动协议（SIP）[RFC3261]实体之间的可靠传输机制，以便在面向web的部署中使用SIP。此外，[RFC7977]将新的WebSocket子策略定义为消息会话中继协议（MSRP）客户端和中继之间的可靠传输机制。[RFC7395]为可扩展消息和状态协议（XMPP）定义WebSocket子策略。类似地，[BFCP-WEBSOCKET]将WEBSOCKET子目录定义为二进制地板控制协议（BFCP）[BFCP]实体之间的可靠传输机制，以支持在新场景中使用BFCP。
When a WebSocket subprotocol is used as a transport mechanism between a server and client, there needs to be a way to indicate the connection URI from the server to the WebSocket client. For applications that use Session Description Protocol (SDP) [RFC4566] to negotiate, the connection URI can be indicated by means of an SDP attribute. This specification defines new SDP attributes to indicate the connection URI for the WebSocket client. Applications that use SDP for negotiation and WebSocket as a transport protocol can use this specification to advertise the WebSocket client connection URI.
当WebSocket子目录用作服务器和客户端之间的传输机制时，需要有一种方法来指示从服务器到WebSocket客户端的连接URI。对于使用会话描述协议（SDP）[RFC4566]进行协商的应用程序，可以通过SDP属性指示连接URI。此规范定义了新的SDP属性，以指示WebSocket客户端的连接URI。使用SDP进行协商并将WebSocket用作传输协议的应用程序可以使用此规范公布WebSocket客户端连接URI。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Applications that use the SDP Offer/Answer mechanism [RFC3264] for negotiating media and also use WebSocket or secure WebSocket as a transport protocol MAY indicate the connection URI for the WebSocket client via a new SDP "a=" media-level attribute defined in Section 3.2.
使用SDP提供/应答机制[RFC3264]协商媒体并将WebSocket或安全WebSocket用作传输协议的应用程序，可通过第3.2节中定义的新SDP“a=”媒体级别属性指示WebSocket客户端的连接URI。
This section defines a new SDP media-level attribute, "websocket-uri", which can appear in any of the media sections.
本节定义了一个新的SDP媒体级属性“websocket uri”，它可以出现在任何媒体节中。
Example:
例子：
a=websocket-uri:wss://example.com/chat
a=websocket-uri:wss://example.com/chat
Where "wss://example.com/chat" is the ws-URI defined in Section 3 of [RFC6455].
“在哪里”wss://example.com/chat“是[RFC6455]第3节中定义的ws-URI。
When the "websocket-uri" attribute is present in the media section of the SDP, the IP address in "c=" line SHALL be ignored and the full URI SHALL be used instead to open the WebSocket connection. The clients MUST ensure that they use the URI to open the WebSocket connection and ignore the IP address in the "c=" line and the port in the "m=" line.
当SDP的媒体部分中存在“websocket uri”属性时，应忽略“c=”行中的IP地址，而应使用完整uri打开websocket连接。客户端必须确保使用URI打开WebSocket连接，并忽略“c=”行中的IP地址和“m=”行中的端口。
Multiplexing characteristics of SDP attributes are described in [SDP-MUX]. Various SDP attribute multiplexing categories are introduced there.
SDP属性的复用特性在[SDP-MUX]中描述。这里介绍了各种SDP属性复用类别。
o The multiplexing category of the "a=websocket-uri" attribute is CAUTION.
o “a=websocket uri”属性的多路复用类别为“小心”。
There are no multiplexing rules specified for the "websocket-uri" SDP media-level attribute. Additionally, the specification of multiplexing rules for the "websocket-uri" attribute is outside the scope of this document.
没有为“websocket uri”SDP媒体级别属性指定多路复用规则。此外，“websocket uri”属性的多路复用规则规范不在本文档的范围之内。
While it is technically possible to bundle WebSocket, there are a variety of reasons that make it impractical; thus, it is considered unlikely to be used in practice. Therefore, the "websocket-uri" SDP media-level attribute defined in Section 3.2 for using WebSocket as a transport protocol is not likely to be used with SDP bundle and is consequently categorized as CAUTION for multiplexing.
虽然在技术上可以捆绑WebSocket，但有多种原因使其不切实际；因此，它被认为不太可能在实践中使用。因此，第3.2节中定义的用于将websocket用作传输协议的“websocket uri”SDP媒体级属性不太可能与SDP捆绑包一起使用，因此被归类为多路复用注意事项。
If future extensions define how to bundle WebSocket, then multiplexing rules for the "a=websocket-uri" attribute need to be defined as well, for instance, in an extension of this SDP based WebSocket negotiation specification.
如果将来的扩展定义了如何绑定WebSocket，那么还需要定义“a=WebSocket uri”属性的多路复用规则，例如，在这个基于SDP的WebSocket协商规范的扩展中。
An endpoint (i.e., both the offerer and the answerer) that wishes to negotiate WebSocket as transport protocol MUST indicate that it wishes to use WebSocket or secure WebSocket in the "proto" field of the "m=" line. Furthermore, the server side, which could be either the offerer or answerer, MUST add an "a=websocket-uri" attribute in the media section whose value can be either "ws-URI" or "wss-URI", as defined in Section 3 of [RFC6455], depending on whether it wishes to use WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in Section 3. The procedures in this section apply to an "m=" line associated with any media stream that uses WebSocket or secure WebSocket as transport.
希望将WebSocket协商为传输协议的端点（即，报价人和应答人）必须在“m=”行的“proto”字段中指明希望使用WebSocket或安全WebSocket。此外，服务器端（可以是提供方或应答方）必须在媒体部分添加“a=websocket uri”属性，其值可以是[RFC6455]第3节中定义的“ws-uri”或“wss-uri”，这取决于它希望使用websocket还是安全websocket。此新属性必须遵循第3节中定义的语法。本节中的步骤适用于与任何使用WebSocket或secure WebSocket作为传输的媒体流关联的“m=”行。
Both offerer or answerer can initiate a WebSocket connection. It is expected that, based on the topology (for example, if the client is behind NAT and server is on global IP address), the offerer and answerer applications decide on who will initiate the WebSocket connection and appropriately set the "setup" attribute in SDP following the procedures of [RFC4145].
报价人或应答人都可以启动WebSocket连接。预计，根据拓扑结构（例如，如果客户端位于NAT后面，服务器位于全局IP地址），报价人和应答人应用程序将决定谁将启动WebSocket连接，并按照[RFC4145]中的步骤在SDP中适当设置“设置”属性。
In order to negotiate WebSocket as a transport, an SDP offerer MUST indicate that it wishes to use it in the "proto" field of the "m=" line. For example, to negotiate BFCP-over-WebSocket, the "proto" value in the "m=" line is TCP/WSS/BFCP if WebSocket is over TLS; else, it is TCP/WS/BFCP, as specified in [BFCP-WEBSOCKET].
为了将WebSocket作为传输进行协商，SDP报价人必须在“m=”行的“proto”字段中表明其希望使用WebSocket。例如，要通过WebSocket协商BFCP，“m=”行中的“proto”值是TCP/WSS/BFCP（如果WebSocket通过TLS）；否则，它就是[BFCP-WEBSOCKET]中指定的TCP/WS/BFCP。
The offerer SHOULD assign the SDP "setup" attribute with a value of "active" (the offerer will be the initiator of the outgoing TCP connection) or "passive" if the offerer wishes to be a receiver of an incoming connection. The offerer MUST NOT assign an SDP "setup" attribute with a "holdconn" value. The offerer MUST follow the procedures described in [RFC4145] while using the "setup" attribute. If the "setup" attribute has a value of "passive", it MUST have a URI in the "a=websocket-uri" attribute.
如果发盘方希望成为传入连接的接收方，发盘方应将SDP“设置”属性的值指定为“主动”（发盘方将是传出TCP连接的发起方）或“被动”。报价人不得为SDP“设置”属性分配“holdconn”值。在使用“设置”属性时，报价人必须遵循[RFC4145]中描述的程序。如果“setup”属性的值为“passive”，则在“a=websocket URI”属性中必须有一个URI。
The following is an example of an "m=" line for a BFCP connection:
以下是BFCP连接的“m=”线路示例：
Offer (browser):
m=application 9 TCP/WSS/BFCP *
a=setup:active
a=connection:new
a=floorctrl:c-only
m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31
Offer (browser):
m=application 9 TCP/WSS/BFCP *
a=setup:active
a=connection:new
a=floorctrl:c-only
m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31
In the above example, the client is intending to set up the TLS/TCP connection; hence, the port is set to a value of 9, which is the discard port.
在上面的示例中，客户端打算建立TLS/TCP连接；因此，端口设置为值9，即丢弃端口。
If the answerer accepts the offered WebSocket transport connection, in the associated SDP answer, the answerer MUST assign an SDP "setup" attribute with a value of either "active" or "passive", according to the procedures in [RFC4145]. The answerer MUST NOT assign an SDP "setup" attribute with a value of "holdconn".
如果应答者接受提供的WebSocket传输连接，则在相关的SDP应答中，应答者必须根据[RFC4145]中的程序，为SDP“设置”属性分配一个值为“主动”或“被动”的属性。应答者不得将SDP“设置”属性的值指定为“holdconn”。
If the answerer assigns an SDP "setup" attribute with a value of "active", the answerer MUST initiate the WebSocket connection handshake by acting as client on the negotiated media stream, towards the URI specified in the "a=websocket-uri" SDP attribute using the procedures described in Section 4 of [RFC6455].
如果应答者为SDP“setup”属性分配了一个值为“active”的属性，则应答者必须使用[RFC6455]第4节中描述的过程，作为协商媒体流上的客户端，向“a=WebSocket URI”SDP属性中指定的URI发起WebSocket连接握手。
If the answerer assigns an SDP "setup" attribute with a value of "passive", then it MUST have a value of "ws-URI" or "wss-URI", as defined in Section 3 of [RFC6455] in an "a=websocket-uri" SDP attribute, depending on whether the application uses WebSocket or secure WebSocket. This attribute MUST follow the syntax defined in Section 3.
如果应答者为SDP“setup”属性分配了一个值为“passive”的属性，则该属性的值必须为“ws-URI”或“wss-URI”，如[RFC6455]第3节在“a=websocket-URI”SDP属性中所定义，具体取决于应用程序使用的是websocket还是安全websocket。此属性必须遵循第3节中定义的语法。
The following example shows a case where the server responds with a BFCP media stream over a WebSocket connection running TLS. It shows an answer "m=" line for the BFCP connection. In this example, since WebSocket is running over TLS, the server answers back with an "a=websocket-uri" attribute in the media section of SDP having a "wss-URI" connection URI:
以下示例显示了服务器通过运行TLS的WebSocket连接使用BFCP媒体流进行响应的情况。它显示了BFCP连接的答案“m=”行。在本例中，由于WebSocket在TLS上运行，因此服务器在SDP的媒体部分使用“wss uri”连接uri中的“a=WebSocket uri”属性进行应答：
Answer (server):
m=application 50000 TCP/WSS/BFCP *
a=setup:passive
a=connection:new
a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
a=floorctrl:s-only
a=confid:4321
a=userid:1234
a=floorid:1 m-stream:10
a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0
a=label:10
m=video 50004 RTP/AVP 31
a=label:11
Answer (server):
m=application 50000 TCP/WSS/BFCP *
a=setup:passive
a=connection:new
a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
a=floorctrl:s-only
a=confid:4321
a=userid:1234
a=floorid:1 m-stream:10
a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0
a=label:10
m=video 50004 RTP/AVP 31
a=label:11
When the offerer receives an SDP answer, if the offerer ends up initiating the TCP connection, then it MUST follow the procedures in Section 5.
当报价人收到SDP应答时，如果报价人最终启动TCP连接，则必须遵循第5节中的程序。
Once an offer/answer exchange has been completed, either endpoint MAY send a new offer in order to modify the session. The endpoints can reuse the existing WebSocket connection by adding an "a=connection:existing" attribute in the media section of the SDP following the rules mentioned in [RFC4145], if the "websocket-uri" SDP value and the transport parameters indicated by each endpoint are unchanged. Otherwise, following the rules for the initial offer/ answer exchange, the endpoints can negotiate and create a new WebSocket connection on top of TLS/TCP or TCP.
一旦提供/应答交换完成，任一端点都可以发送新的提供以修改会话。如果“WebSocket uri”SDP值和每个端点指示的传输参数不变，则端点可以按照[RFC4145]中提到的规则，通过在SDP的媒体部分中添加“a=connection:existing”属性来重用现有的WebSocket连接。否则，按照初始提供/应答交换的规则，端点可以协商并在TLS/TCP或TCP之上创建新的WebSocket连接。
In some scenarios, an endpoint (e.g., a browser) originating the call (a User Agent Client or UAC) can send an offerless INVITE to the server. The server will generate an offer in response to the INVITE. In such cases, the server MUST send an offer with the "setup" attribute with a value of "passive" so as to accept incoming connection and MUST include an "a=websocket-uri" attribute in the media section whose value MUST be either "ws-URI" or "wss-URI", depending on whether the server wishes to use WebSocket or secure WebSocket. The SDP offer sent by the server will look like the example in Section 4.3.
在某些场景中，发起呼叫的端点（例如浏览器）（用户代理客户端或UAC）可以向服务器发送无报价邀请。服务器将生成一个报价以响应邀请。在这种情况下，服务器必须发送一个带有“setup”属性、值为“passive”的offer，以便接受传入连接，并且必须在媒体部分中包含一个“a=websocket uri”属性，该属性的值必须是“ws uri”或“wss uri”，这取决于服务器希望使用websocket还是安全websocket。服务器发送的SDP报价将类似于第4.3节中的示例。
The WebSocket client MUST always initiate the outgoing TCP connection; hence, the SDP "setup" attribute MUST always be "active" for the WebSocket client in its SDP offer/answer. In the example below, the WebSocket client is the offerer; hence, it assigns a "setup" attribute with a value of "active".
WebSocket客户端必须始终启动传出TCP连接；因此，WebSocket客户端在其SDP提供/应答中的SDP“setup”属性必须始终处于“活动”状态。在下面的示例中，WebSocket客户端是报价人；因此，它将“设置”属性的值指定为“活动”。
The WebSocket server is a server on the Internet; hence, it MUST always assign an SDP "setup" attribute with a value of "passive". This also avoids the need to use Interactive Connectivity Establishment (ICE) between WebSocket client and WebSocket server, as the connection model here would be a typical client-to-server web connection.
WebSocket服务器是Internet上的服务器；因此，必须始终将SDP“设置”属性的值指定为“被动”。这也避免了在WebSocket客户端和WebSocket服务器之间使用交互式连接建立（ICE），因为这里的连接模型是典型的客户端到服务器的web连接。
Once the offer/answer is complete, the client MUST initiate the WebSocket connection handshake by sending a GET message on the negotiated media stream, towards the URI specified in an "a=websocket-uri" attribute, as per the procedures described in [RFC6455]. When no port is passed in the "a=websocket-uri" attribute, the default port (80 or 443) is used depending on whether the value was "ws-URI" or "wss-URI".
一旦提供/应答完成，客户机必须按照[RFC6455]中描述的过程，通过在协商的媒体流上向“a=WebSocket URI”属性中指定的URI发送GET消息来启动WebSocket连接握手。在“a=websocket uri”属性中未传递任何端口时，将根据值是“ws-uri”还是“wss-uri”使用默认端口（80或443）。
An attacker may attempt to add, modify, or remove an "a=websocket-uri" attribute from a session description. This could result in an application behaving undesirably. Consequently, it is RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [RFC3261], S/MIME is available to provide such end-to-end integrity protection.
攻击者可能试图从会话描述中添加、修改或删除“a=websocket uri”属性。这可能会导致应用程序表现不理想。因此，建议对SDP会话描述应用完整性保护。对于SIP[RFC3261]中的会话描述，可以使用S/MIME来提供这样的端到端完整性保护。
As described in Section 10 of [RFC6455], application signalling traffic being transported over WebSocket MUST support secure WebSocket and SHOULD employ it when communicating with their peers.
如[RFC6455]第10节所述，通过WebSocket传输的应用程序信令流量必须支持安全WebSocket，并应在与对等方通信时使用它。
The WebSocket clients have to initiate the TCP connection to the WebSocket server identified by the Fully Qualified Domain Name (FQDN) in an "a=websocket-uri" attribute. Further, as with any other web connection, the clients will verify the server's certificate. The WebSocket client MUST follow the procedures in [RFC7525] (including host name verification as per Section 6.1 in [RFC7525]) while setting up a TLS connection with a WebSocket server.
WebSocket客户端必须启动到WebSocket服务器的TCP连接，该服务器由“a=WebSocket uri”属性中的完全限定域名（FQDN）标识。此外，与任何其他web连接一样，客户端将验证服务器的证书。在设置与WebSocket服务器的TLS连接时，WebSocket客户端必须遵循[RFC7525]中的步骤（包括根据[RFC7525]第6.1节进行的主机名验证）。
This document defines a new SDP media-level attribute "websocket-uri" in Section 3.2; IANA has registered the following SDP att-field under the "Session Description Protocol (SDP) Parameters" registry as follows:
本文档在第3.2节中定义了一个新的SDP媒体级属性“websocket uri”；IANA已在“会话描述协议（SDP）参数”注册表下注册了以下SDP att字段，如下所示：
+---------------------+---------------------------------------------+
| Attribute name: | websocket-uri |
| Long-form attribute | WebSocket Connection URI |
| name: | |
| Type of attribute: | media |
| Mux category: | CAUTION |
| Charset Dependent: | No |
| Purpose: | The "websocket-uri" attribute is intended |
| | to be used as a connection URI for opening |
| | the WebSocket connection. |
| Appropriate values: | A ws-URI or wss-URI, as defined in Section |
| | 3 of [RFC6455] |
| Contact name: | Gonzalo Salgueiro |
| Contact email: | gsalguei@cisco.com |
| Reference: | RFC 8124 |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Attribute name: | websocket-uri |
| Long-form attribute | WebSocket Connection URI |
| name: | |
| Type of attribute: | media |
| Mux category: | CAUTION |
| Charset Dependent: | No |
| Purpose: | The "websocket-uri" attribute is intended |
| | to be used as a connection URI for opening |
| | the WebSocket connection. |
| Appropriate values: | A ws-URI or wss-URI, as defined in Section |
| | 3 of [RFC6455] |
| Contact name: | Gonzalo Salgueiro |
| Contact email: | gsalguei@cisco.com |
| Reference: | RFC 8124 |
+---------------------+---------------------------------------------+
[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>.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <http://www.rfc-editor.org/info/rfc4145>.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 4145，DOI 10.17487/RFC4145，2005年9月<http://www.rfc-editor.org/info/rfc4145>.
[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>.
[BFCP] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", Work in Progress, draft-ietf-bfcpbis-rfc4582bis-16, November 2015.
[BFCP]Camarillo，G.，Drage，K.，Kristensen，T.，Ott，J.，和C.Eckel，“二进制地板控制协议（BFCP）”，正在进行的工作，草案-ietf-bfcpbis-rfc4582bis-162015年11月。
[BFCP-WEBSOCKET] Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., and R. R, "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Work in Progress, draft-ietf-bfcpbis-bfcp-websocket-15, February 2017.
[BFCP-WEBSOCKET]Pascual，V.，Roman，A.，Cazeaux，S.，Salgueiro，G.，和R.R，“作为二进制地板控制协议（BFCP）传输的WEBSOCKET协议”，正在进行的工作，草案-ietf-bfcpbis-BFCP-WEBSOCKET-15，2017年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[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>.
[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>.
[RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket", RFC 7395, DOI 10.17487/RFC7395, October 2014, <http://www.rfc-editor.org/info/rfc7395>.
[RFC7395]Stout，L.，Ed.，Moffitt，J.，和E.Cestari，“WebSocket的可扩展消息和状态协议（XMPP）子策略”，RFC 7395，DOI 10.17487/RFC7395，2014年10月<http://www.rfc-editor.org/info/rfc7395>.
[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>.
[RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., and R. Ravindranath, "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", RFC 7977, DOI 10.17487/RFC7977, September 2016, <http://www.rfc-editor.org/info/rfc7977>.
[RFC7977]Dunkley，P.，Llewellyn，G.，Pascual，V.，Salgueiro，G.，和R.Ravindranath，“作为消息会话中继协议（MSRP）传输的WebSocket协议”，RFC 7977，DOI 10.17487/RFC7977，2016年9月<http://www.rfc-editor.org/info/rfc7977>.
[SDP-MUX] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", Work in Progress, draft-ietf-mmusic-sdp-mux-attributes-16, December 2016.
[SDP-MUX]Nandakumar，S.，“复用时SDP属性的框架”，正在进行的工作，草稿-ietf-mmusic-SDP-MUX-Attributes-162016年12月。
[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/>.
Acknowledgements
致谢
Thanks to Christer Holmberg for raising the need for a BFCP-independent SDP attribute for WebSocket Connection URI.
感谢Christer Holmberg提出WebSocket连接URI需要一个独立于BFCP的SDP属性。
The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, Christer Holmberg, Charles Eckel, Dan Wing, Alissa Cooper, and Joel Halpern for their invaluable suggestions and review comments.
作者希望感谢Paul Kyzivat、Suhas Nandakumar、Christer Holmberg、Charles Eckel、Dan Wing、Alissa Cooper和Joel Halpern提出的宝贵建议和评论。
Thanks to Mirja Kuehlewind, Alexey Melnikov, Ben Campbell, and Kathleen Moriarty for their comments and feedback during IESG reviews.
感谢Mirja Kuehlewind、Alexey Melnikov、Ben Campbell和Kathleen Moriarty在IESG审查期间的评论和反馈。
Authors' Addresses
作者地址
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Ravindranath Cisco Systems，Inc.印度卡纳塔克邦班加罗尔Sarjapur Marathahalli外环路Varthur Hobli Kadabeesanahalli村塞斯纳商业园，邮编：560103
Email: rmohanr@cisco.com
Email: rmohanr@cisco.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