The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
updates
Extracted elements (25)
All MSRP-over-WebSocket messages must be routed via an MSRP WebSocket Server because WebSocket clients are architecturally incapable of accepting inbound connections from other WebSocket clients or servers, making direct client-to-client MSRP communication impossible without a relay.
MSRP WebSocket Clients use a random token followed by the ".invalid" TLD (RFC 2606) in the hostpart of their From-Path URI because the JavaScript WebSocket API in browsers cannot discover the local transport address used for the WebSocket connection.
No new SDP transport protocol is defined for MSRP over WebSocket. Because all traffic goes through a relay, the client specifies "TCP/TLS/MSRP" in the SDP m-line (the protocol used between relays and non-WebSocket clients), while the "ws" transport appears only in the SDP path attribute URI.
The "ws" transport parameter appears in the endpoint URI in the SDP "path" attribute but not in the SDP m-line; MSRP was designed to allow unrecognized transports provided implementations do not need to establish a direct connection to such URIs.
When the same MSRP WebSocket Server appears twice in the To-Path (because both sender and receiver use the same relay), the server can handle this internally or loop the SEND request back to itself as if it were two separate relays.
All MSRP-over-WebSocket messages MUST be routed via an MSRP WebSocket Server, since WebSocket clients cannot receive connections initiated by other WebSocket clients or servers.
An MSRP WebSocket Client SHOULD support HTTP Digest authentication as stated in RFC 4976, since authentication MAY be requested at the MSRP protocol level via a 401 challenge to AUTH requests.
Because 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 rather than a new WebSocket-specific SDP transport protocol.
Each MSRP chunk MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one MSRP chunk.
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.
It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their connections open by sending periodic WebSocket Ping frames as described in RFC 6455 Section 5.5.2.
MSRP traffic transported over WebSockets MUST be protected by using a Secure WebSocket (WSS) connection (using TLS over TCP).
MSRP WebSocket Clients and Servers MUST accept both text and binary WebSocket frames. The content of text frames MUST be interpreted as binary by WebSocket Clients and Servers.
The AUTH request remains a required event even when authentication occurs at the WebSocket connection level, because the "Use-Path:" header needed to create an SDP offer is returned in the 200 OK response to the AUTH request.
The MSRP WebSocket Client MUST include the value "msrp" in the Sec-WebSocket-Protocol header in its handshake request, and the server's 101 reply MUST contain "msrp" in the corresponding Sec-WebSocket-Protocol header.
This document modifies RFC 4976 to require that all connections between MSRP clients and relays MUST be authenticated, not just AUTH requests. Three mechanisms are permitted: HTTP Digest in AUTH, cookie-based or HTTP Digest in the WebSocket handshake, or mutual TLS.
When large messages are sent by a non-WebSocket peer, MSRP chunking (per RFC 4975 Section 5.1) MUST be used by the WebSocket MSRP Server to split the message into several smaller MSRP chunks.
When WebSocket Ping frames cannot be used, an MSRP implementation MAY use bodiless SEND requests for keepalive, and MSRP WebSocket Clients and Servers MUST be prepared to receive bodiless SEND requests.
An MSRP WebSocket Client is an MSRP entity capable of opening outbound connections to MSRP relays that are WebSocket servers and communicating using the WebSocket MSRP subprotocol. An MSRP WebSocket Server is an MSRP relay capable of listening for inbound connections from WebSocket clients.
This document defines the value "ws" as the transport parameter for an MSRP URI to indicate use of the MSRP WebSocket subprotocol. The updated ABNF is: transport = "tcp" / "ws" / 1*ALPHANUM.
Three authentication mechanisms are defined for MSRP WebSocket Clients connecting to a relay: (1) HTTP Digest authentication in AUTH per RFC 4976, (2) cookie-based or HTTP Digest in the WebSocket handshake, and (3) mutual TLS between the WebSocket client and server.
This document registers the WebSocket MSRP subprotocol in the IANA "WebSocket Subprotocol Name Registry" with identifier "msrp", common name "WebSocket Transport for MSRP (Message Session Relay Protocol)", and definition RFC 7977.
MSRP traffic transported over WebSockets MUST be protected by a secure WebSocket connection (WSS/TLS). The client MUST authenticate the server using the server's certificate according to the WebSocket validation procedure in RFC 6455.
Since TLS is always terminated at the MSRP WebSocket Server and the server sees the plain text, the MSRP client (e.g., a browser) SHOULD NOT indicate end-to-end security to the user.
TLS, as used in this document, should follow the best current practices defined in RFC 7525.