Session Description Protocol (SDP) WebSocket Connection URI Attribute

The WebSocket protocol enables bidirectional message exchange between clients and servers on top of a persistent TCP connection (optionally secured with Transport Layer Security (TLS) ). The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure. Modern web browsers include a WebSocket client stack compliant with the WebSocket 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. For example, defines WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments. Additionally, defines a new WebSocket sub-protocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays. defines a WebSocket subprotocol for the Extensible Messaging and Presence Protocol (XMPP). Similarly, defines a WebSocket sub-protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. When WebSocket sub-protocol 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) 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.

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 .

Applications that use the SDP Offer/Answer mechanism 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 .

This section defines a new SDP media-level attribute, "websocket-uri" which can appear in any of the media sections. Example:

Where "wss://example.com/chat" is the ws-URI defined in Section 3 of . 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 'c=' line and port in m= line.

Multiplexing characteristics of SDP attributes are described in . Various SDP attribute multiplexing categories are introduced there. The multiplexing category of the "a=websocket-uri:" attribute is CAUTION. 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. While it is technically possible to bundle WebSocket, there are a variety of reasons that make it impractical and it is thus considered unlikely to be used in practice. Therefore, the "websocket-uri" SDP media-level attribute defined in for using WebSocket as a transport protocol is not likely to be used with SDP bundle and is consequently categorized as CAUTION for multiplexing. 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.

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" defined in Section 3 depending on whether it wishes to use WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in . The procedures in this section apply to an "m=" line associated with any media stream that uses WebSocket or secure WebSocket as transport. 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 answers applications decides on who will initiate the webSocket connection and appropriately set the "setup" attribute in SDP following the procedures of .

An SDP offerer in order to negotiate WebSocket as a transport MUST indicate the same 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 . 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 while using the "setup" attribute. If the "setup" attribute has a value "passive" it MUST have a URI in the "a=websocket-uri" attribute. The following is an example of an "m=" line for a BFCP connection:

In the above example, the client is intending to setup the TLS /TCP connection and hence the port is set to a value of 9, which is the discard port.

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 . The answerer MUST NOT assign an SDP "setup" attribute with a value of "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 "a=websocket-uri" SDP attribute using the procedures described in Section 4 of . If the answers assigns SDP "setup" attribute with "passive", then it MUST have a "ws-URI" or "wss-URI" defined in Section 3 of in "a=websocket-uri" SDP attribute depending on whether the application uses WebSocket or secureWebSocket. This attribute MUST follow the syntax defined in . 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 WebSockets is running over TLS, the server answers back with "a=websocket-uri" attribute in the media section of SDP having a "wss-URI" connection URI:

When the offerer receives an SDP answer, if the offerer ends up being active it MUST follow the procedures in .

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 "a=connection:existing" attribute in the media section of SDP following the rules mentioned in 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.

In some scenarios an endpoint (e.g., a browser) originating the call (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 setup attribute as "passive" so as to accept incoming connection and MUST include "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 .

The webSocket client MUST always initiate the outgoing TCP connection and hence the SDP a=setup attribute MUST be always "active" for the WebSocket client in its SDP offer/answer. In the below example, the WebSocket client is the offerer and hence assigns "setup" attribute with a value of "active". The WebSocket server is a server on the Internet and hence MUST always assign SDP "setup" attribute with a value of "passive". This also avoids the need to use ICE between WebSocket Client and WebSocket Server as the connection model here would be a typical client to server web connection. 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 "a=websocket-uri" as per the procedures described in . When no port is passed in the "a=websocket-uri" attribute, the default port (80 or 443) is used depending on whether the value has "ws-URI" or "wss-URI".

An attacker may attempt to add, modify, or remove "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 , S/MIME is available to provide such end-to-end integrity protection. As described in Section 10 of , application signalling traffic being transported over WebSocket MUST support secure WebSocket and SHOULD employ it when communicating with their peers. The WebSocket clients have to initiate the TCP connection to the WebSocket server identified by the FQDN in a=websocket-uri. Further as with any other web connection, the clients will verify the servers certificate. The WebSocket client MUST follow the procedures in (including hostname verification as per section 6.1 in ) while setting up TLS connection with webSocket server.

NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document defines a new SDP media-level attribute "websocket-uri" in and requests that IANA to register the following SDP att-field under the Session Description Protocol (SDP) Parameters registry as follows: Attribute name: websocket-uri Long-form attribute name: Websocket Connection URI 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 Contact name: Gonzalo Salgueiro Contact e-mail: gsalguei@cisco.com Reference: RFCXXXX

Thanks to Christer Holmberg for raising the need for a BFCP-independent SDP attribute for WebSocket Connection URI. 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. Thanks to Mirja Kuehlewind, Alexey Melnikov, Ben Campbell and Kathleen Moriarty for their comments and feedback during IESG reviews.