RFC 7977

The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) 💖

• RFC number: 7977
• Title: The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
• Authors: P. Dunkley and G. Llewellyn (Xura), V. Pascual (Oracle), G. Salgueiro and R. Ravindranath (Cisco)
• Category: Standards Track
• Date: September 2016
• ISSN: 2070-1721
• Updates: RFC 4975 and RFC 4976 (Updates: 4975, 4976)
• Obsoletes: none listed

---

Abstract 🌸

okay so WebSocket lets two-way, real-time chatter happen between clients and servers when you can't directly touch TCP or UDP (think JavaScript running inside a web browser) 🦋 this doc defines a brand new WebSocket subprotocol that acts as a reliable transport between MSRP clients and relays, so MSRP can show up in brand new scenarios ✨ it also normatively updates RFC 4975 and RFC 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.

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.

Copyright Notice 🌈

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

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.

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 🎀

okay so the WebSocket [RFC6455] protocol lets clients and servers swap messages over a persistent TCP connection (optionally wrapped in Transport Layer Security (TLS) [RFC5246]) 🔥 the opening handshake speaks HTTP [RFC7230], which means WebSocket can reuse all the existing HTTP infrastructure. iconic behavior honestly 💅

Modern web browsers ship a WebSocket client stack that follows the WebSocket API [WS-API] from the W3C. other client apps, like the ones on personal computers and smartphones, are expected to offer a WebSocket client stack too ✨ this specification is what makes Message Session Relay Protocol [RFC4975] usable in those scenarios 🦋

This specification defines a new WebSocket subprotocol (as defined in Section 1.9 in [RFC6455]) for carrying MSRP messages between a WebSocket client and an MSRP relay [RFC4976] that contains a WebSocket server. It also brings in a new transport for MSRP, plus the procedures MSRP clients and relays need to implement that WebSocket transport 🧚

MSRP over WebSocket is a great fit for MSRP interactions between clients and servers. common use cases include:

• Human-to-machine messaging
• Client-to-server data exchange (for example, application control signaling)
• Human-to-human messaging where local policy requires authentication and/or logging

MSRP Connection Establishment for Media Anchoring (MSRP-CEMA) [RFC6714] is outside of the scope of this document, because this document is about connecting to a WebSocket server that is an MSRP relay. not that one 🙈

2. Terminology 💜

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].

2.1. Definitions 🍓

MSRP WebSocket Client: an MSRP entity that can open outbound connections to MSRP relays that are WebSocket servers, and talk to them using the WebSocket MSRP subprotocol defined by this document 💖

MSRP WebSocket Server: an MSRP entity (specifically an MSRP relay [RFC4976]) that can listen for inbound connections from WebSocket clients and talk to them using the WebSocket MSRP subprotocol defined by this document 🌸

3. WebSocket Protocol Overview 🦋

The WebSocket protocol [RFC6455] is a transport layer that sits on top of TCP (optionally secured with TLS [RFC5246]), and both the client and the server can send message units in both directions 🔥 it covers a connection handshake, negotiation of subprotocols and extensions, a frame format for application and control data, a masking mechanism, and status codes for telling you why a disconnection happened.

The WebSocket connection handshake is based on HTTP [RFC7230] and uses the HTTP GET method with an "Upgrade" request. The client sends it, and the server answers with an HTTP 101 status code if the negotiation succeeded. once the handshake is done, the connection switches from HTTP over to the WebSocket protocol. this handshake is designed to reuse the existing HTTP infrastructure, which is so smart 🧠 during the handshake, client and server agree on the application protocol to run on top of the WebSocket transport. that application protocol (also called a "WebSocket subprotocol") defines the format and meaning of the messages the endpoints swap. it could be a custom protocol or a standardized one, like the WebSocket MSRP subprotocol defined in this document ✨ after the HTTP 101 response is processed, both sides reuse the same underlying TCP connection to send WebSocket messages and control frames to each other. unlike plain HTTP, this connection is persistent and can carry multiple message exchanges 🫶

WebSocket defines message units that applications use to exchange data, so it gives you a transport layer that preserves message boundaries 👑 these message units can hold either UTF-8 text or binary data, and the WebSocket stack can split them across several WebSocket text/binary transport frames as needed.

The WebSocket API [WS-API] for web browsers only defines callbacks that run when an entire message unit has arrived. it doesn't matter whether that unit came in one WebSocket frame or was split across several 😭

4. The WebSocket MSRP Subprotocol 🧚

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, and it's the star of the show from here on 🌈

4.1. Handshake ✨

okay so the MSRP WebSocket Client and MSRP WebSocket Server agree on using the WebSocket MSRP subprotocol during the WebSocket handshake, following the steps 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 matching Sec-WebSocket-Protocol header. no cap, this is the handshake's main job 🫶

here's an example of a WebSocket handshake where the Client asks the Server for WebSocket MSRP subprotocol support 🦋

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

and the Server's response, accepting the WebSocket MSRP subprotocol, looks like this 🌸

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: msrp

once the negotiation is done, the WebSocket connection is set up and ready to carry MSRP requests and responses 🎀 the WebSocket messages sent over this connection MUST conform to the negotiated WebSocket subprotocol. it's giving well-behaved traffic only 💅

4.2. MSRP Encoding

bestie, WebSocket messages can travel in either UTF-8 text frames or binary frames 🧚 MSRP [RFC4975] allows both text and binary bodies in MSRP requests, so MSRP WebSocket Clients and Servers MUST accept both text and binary frames. 💜

the WebSocket API [WS-API] doesn't let developers pick between UTF-8 text and binary frames, but it also won't send non-UTF-8 characters in a text frame 🙈 so the content of text frames MUST be interpreted as binary by WebSocket Clients and Servers. yes, even the text ones get read as raw bytes, periodt 💀

5. MSRP WebSocket Transport

5.1. General

okay so WebSocket clients can't receive WebSocket connections started by other WebSocket clients or WebSocket servers 😭 which makes it kind of tricky for an MSRP client to talk directly to other MSRP clients. That's why all MSRP-over-WebSocket messages MUST be routed via an MSRP WebSocket Server 🌈 and MSRP traffic carried over WebSockets MUST be protected by using a Secure WebSocket (WSS) connection (using TLS [RFC5246] over TCP). no shortcuts, the encryption is non-negotiable 🔐✨

MSRP WebSocket Servers can route MSRP messages between MSRP WebSocket Clients, and also between MSRP WebSocket Clients and "normal" MSRP clients and relays 🦋

each MSRP chunk MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one MSRP chunk. 🍓 this keeps parsing simple for both clients and servers, which is honestly so iconic of it 👑 when a non-WebSocket peer sends large messages, 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. big messages get chopped up, no drama 🌸

5.2. Updates to RFC 4975

5.2.1. MSRP URI Transport Parameter

this document defines the value "ws" as the transport parameter for an MSRP URI [RFC3986] that's reached using the MSRP WebSocket subprotocol as its transport ✨

here's the updated ABNF [RFC5234] for this parameter (the original BNF is in [RFC4975], if you want to peek 👀)

transport  =  "tcp" / "ws" / 1*ALPHANUM

5.2.2. SDP Transport Protocol

this document doesn't define a new Session Description Protocol (SDP) transport protocol for MSRP over WebSockets 💅 since 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's the protocol non-WebSocket clients already use, and the one used between MSRP relays (see Section 8.1 of [RFC4975]) 🫶

the "ws" transport parameter shows up in the endpoint URI in the SDP "path" attribute (see Section 8.2 of [RFC4975]). MSRP was built with new transport bindings in mind (see Section 6 of [RFC4975]), so MSRP implementations are expected to allow unrecognized transports, as long as they don't have to set up a direct connection to the resource the URI describes 🧚 flexible and future-proof, ily MSRP 💖

5.3. Updates to RFC 4976

5.3.1. AUTH Request Authentication

the MSRP relay spec [RFC4976] says AUTH requests MUST be authenticated. this document changes that so that all connections between MSRP clients and relays MUST be authenticated 🔥 for MSRP WebSocket Clients, there are three possible authentication mechanisms:

1. HTTP Digest authentication in AUTH (as per [RFC4976]).
2. Cookie-based or HTTP Digest authentication in the WebSocket Handshake (see Section 7).
3. Mutual TLS between the WebSocket-based MSRP client and the WebSocket server.

the AUTH request is a required event when authentication happens at the WebSocket connection level 🎀 that's because the "Use-Path:" header, which is needed to create the SDP offer, comes back in the 200 OK response to the AUTH request. the AUTH request is kind of the main event here ⭐

6. Connection Keepalive

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] 🦋

the WebSocket API [WS-API] doesn't give web browser apps a way to control whether periodic WebSocket "Ping" frames get sent to the server 🙈 how the keepalive works is up to each web browser maker, and it may also depend on the browser's configuration.

a future WebSocket protocol extension that offers a similar keepalive mechanism could also be used ✨

when MSRP WebSocket Clients or Servers can't use WebSocket "Ping" frames to keep connections open, an MSRP implementation MAY use bodiless SEND requests as described in Section 7.1 of [RFC4975]. still, MSRP WebSocket Clients or Servers MUST be prepared to receive bodiless SEND requests 💜

7. Authentication

before sending any MSRP requests, an MSRP WebSocket Client connects to an MSRP WebSocket Server and does the connection handshake 🧚 as described in Section 3, the handshake is an HTTP GET method request from the Client, followed by a response from the Server that includes an HTTP 101 status code.

to authorize the WebSocket connection, the MSRP WebSocket Server MAY inspect any HTTP headers that are present (for example, Cookie [RFC6265], Host [RFC7230], or Origin [RFC6454]) in the HTTP GET request 👀 for lots of web apps, the Cookie value is handed out by the web server once the user has logged in, which can happen through many existing mechanisms.

there's also an alternative: the MSRP WebSocket Server could ask for HTTP authentication by answering the Client's GET request with an HTTP 401 status code 🔐 the WebSocket protocol [RFC6455] covers this in Section 4.1, and it's paraphrased like this:

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.

if the HTTP GET request includes 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 🌈

regardless of whether the MSRP WebSocket Server asks for authentication during the WebSocket handshake, authentication MAY be requested at the MSRP protocol level, with an MSRP Server challenging AUTH requests using a 401 response 🍓 so an MSRP WebSocket Client SHOULD support HTTP Digest [RFC7235] authentication, as stated in [RFC4976]. be the client that's ready for anything 💅

8. Examples

8.1. Authentication

8.1.1. WebSocket Authentication

Alice    (MSRP WSS)    a.example.com
|                             |
|HTTP GET (WS handshake) F1   |
|---------------------------->|
|101 Switching Protocols F2   |
|<----------------------------|
|                             |
|AUTH F3                      |
|---------------------------->|
|200 OK F4                    |
|<----------------------------|
|                             |

okay so Alice loads a web page in her web browser and gets JavaScript code that implements the WebSocket MSRP subprotocol defined in this document 🌸 the JavaScript code (an MSRP WebSocket Client) sets up a secure WebSocket connection with an MSRP relay (an MSRP WebSocket Server) at a.example.com. once the WebSocket connection is up, Alice builds and sends an MSRP AUTH request. since the JavaScript stack in a browser has no way to find out the local address the WebSocket connection came from, this implementation uses a random ".invalid" domain name for the hostpart of the From-Path URI (see Appendix A) 🙈✨

in this example, authentication is assumed to happen at the WebSocket layer (not shown), so no challenge gets issued for the MSRP AUTH message 🫶

F1 HTTP GET (WS handshake) 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

F2 101 Switching Protocols a.example.com -> Alice (TLS)

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)

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)

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$

8.1.2. MSRP Authentication 🎀

Okay so this one is the same scenario as Section 8.1.1, bestie, but this time the authentication happens at the MSRP layer instead of the WebSocket layer 🦋 The whole flow is laid out in this diagram:

   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                    |
   |<----------------------------|
   |                             |

Quick heads up 🙈 MSRP does not permit line folding! So the \ you'll see in these examples is only there to show a line continuation because this document has a line length limit. The backslash and the extra CRLF are NOT actually part of the MSRP message, periodt 💅

F1 HTTP GET (WS handshake) 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

F2 101 Switching Protocols a.example.com -> Alice (TLS) 🌸

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) 🧚

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) 🍓

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) 💜

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) 👑

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$

---

8.2. Example Session: MSRP WebSocket Client to MSRP Client 🦋

Okay so this section walks through a whole MSRP session where a WebSocket client chats with a regular non-WebSocket client 💖 Each subsection shows a different batch of message exchanges.

8.2.1. SDP Exchange 🌈

This example shows the SDP that could ride along in a SIP message to set up an MSRP session between Alice and Bob. Alice uses a WebSocket MSRP relay, and Bob uses a traditional MSRP client with no relay ✨

Same deal with the backslashes 🙈 A \ shows a line continuation because of the document's line length limits. Neither the backslash nor the extra CRLF is actually in the SDP.

Alice makes an offer with a path that includes the relay (having already successfully authenticated with the relay):

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 wants to receive MSRP messages through the relay at a.example.com 🎀 She wants TLS as the transport for the MSRP session (beyond the relay), and she can accept message/cpim, text/plain, and text/html message bodies in SEND requests. Iconic behaviour 💅

Bob's answer to this offer could look like:

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 wants to receive the MSRP messages at bob.example.com 🍓 He can accept only message/cpim and text/plain message bodies in SEND requests, so he rejected the text/html content Alice offered. He doesn't need a relay to set up the MSRP session 🫶

8.2.2. SEND (MSRP WebSocket Client to MSRP Client) 🌸

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.

Message details (a \ shows a line continuation because of the document's line length limits; neither the backslash nor the extra CRLF is in the actual request or response):

F1 SEND Alice -> a.example.com (transport 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

Hi Bob, I'm about to send you file.mpeg
-------6aef$

F2 200 OK a.example.com -> Alice (transport WSS) 🍓

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) 💜

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$

F4 200 OK Bob -> a.example.com (transport TLS) 👑

MSRP juh76 200 OK
To-Path: msrps://a.example.com:2855/jui787s2f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------juh76$

8.2.3. SEND (MSRP Client to MSRP WebSocket Client) 🦋

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.

Message details (a \ shows a line continuation because of the document's line length limits; neither the backslash nor the extra CRLF is in the actual request or response):

F1 SEND Bob -> a.example.com (transport 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

Thanks for the file.
-------xght6$

F2 200 OK a.example.com -> Bob (transport TLS) 🌈

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) 🎀

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$

F4 200 OK Alice -> a.example.com (transport WSS) 🧚

MSRP yh67 200 OK
To-Path:  msrps://a.example.com:2855/jui787s2f;tcp
From-Path:  msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------yh67$

---

8.3. Example Session: Two MSRP WebSocket Clients 💜

Okay so this section shows an MSRP session between two WebSocket clients 🫶 Each subsection covers a different batch of message exchanges.

8.3.1. SDP Exchange 🌸

This example shows the SDP that could ride along in a SIP message to set up an MSRP session between Alice and Carol, where both of them use the same WebSocket MSRP relay ✨

Alice makes an offer with a path that includes the relay (having already successfully authenticated with the relay):

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 wants to receive MSRP messages through the relay at a.example.com 🎀 She wants TLS as the transport for the MSRP session (beyond the relay), and she can accept message/cpim, text/plain, and text/html message bodies in SEND requests 💅

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

Here Carol also wants to receive the MSRP messages via a.example.com 🍓 She can accept only message/cpim and text/plain message bodies in SEND requests, so she rejected the text/html content Alice offered 🦋

8.3.2. SEND 📨✨

   Alice    (MSRP WSS)     a.example.com     (MSRP WSS)    Carol
   |                             |                             |
   |SEND F1                      |                             |
   |---------------------------->|                             |
   |200 OK F2                    |                             |
   |<----------------------------|                             |
   |                             |SEND F3                      |
   |                             |---------------------------->|
   |                             |200 OK F4                    |
   |                             |<----------------------------|

okay so later on in the session, Alice sends Carol an instant message 💌 and the MSRP WebSocket Server at a.example.com acts as an MSRP relay 🧚, routing the message to Carol over secure WebSocket 🔐. literally the server is doing the hard work here, iykyk 💅

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. ✨

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): 🎀

F1 SEND Alice -> a.example.com (transport 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

Carol, I sent that file to Bob.
-------kjh6$

F2 200 OK a.example.com -> Alice (transport WSS) 🦋

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) 🫶

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$

F4 200 OK Carol -> a.example.com (transport WSS) 🌈

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 🦋

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. 💜

8.4.1. SDP Exchange 📝

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. 🌸

Alice makes an offer with a path including the relay (having already successfully authenticated with the relay): 💅

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. 🎀

Bob's answer to this offer could look like: 🧚

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. 🙈

8.4.2. SEND 📨

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. 🦋✨

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): 🎀

F1 SEND Alice -> a.example.com (transport 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

Bob, that was the wrong file - don't watch it!
-------Ycwt$

F2 200 OK a.example.com -> Alice (transport WSS) 🦋

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) 🫶

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$

F4 200 OK relay.example.net -> a.example.com (transport TLS) 🌈

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) 🧚

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$

F6 200 OK bob.example.com -> relay.example.net (transport TLS) 💜

MSRP kXeg 200 OK
To-Path: msrps://relay.example.net:2855/kwvin5f;tcp
From-Path: msrps://bob.example.com:49154/foo;tcp
-------kXeg$

---

9. Security Considerations 🔐

MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP). 🛡️

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]. 💀

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]. 🌸

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, as used in this document, should follow the best current practices defined in [RFC7525]. 💅

---

10. IANA Considerations 📋

Per this specification, IANA has registered the WebSocket MSRP subprotocol in the "WebSocket Subprotocol Name Registry" with the following data: 🍓

Subprotocol Identifier:  msrp

Subprotocol Common Name:  WebSocket Transport for MSRP (Message
   Session Relay Protocol)

Subprotocol Definition:  RFC 7977

Reference:  RFC 7977

---

11. References 📚

11.1. Normative References 🧠

[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>.

[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>.

[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>.

[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>.

[RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
           RFC 6455, DOI 10.17487/RFC6455, December 2011,
           <http://www.rfc-editor.org/info/rfc6455>.

11.2. Informative References ✨

okay bestie, these are the "for your info" sources 💅 Nothing here is required reading to build the thing, but they're the receipts for the stuff we borrowed from. Each one is listed with all the deets so you can go find it.

[CORS] van Kesteren, A., Ed., "Cross-Origin Resource Sharing", W3C Recommendation, January 2014, <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>. 🌸 This is the one with the reserved .invalid name, which we'll see again in the appendix.

[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>. 🦋 The URI basics, the foundation of everything.

[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>. 🔐 TLS 1.2, the secure-connection classic.

[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>. 🍪 Cookies, obviously.

[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>. 🌈 Origins, the "who's asking" of the web.

[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>. ✨ The MSRP media anchoring story.

[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>. 👑 This one's the inspo for the whole doc, so it gets the crown.

[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>. 💖 HTTP/1.1 message syntax, iconic.

[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>. 🙈 The auth part of the HTTP/1.1 duo.

[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>. 🫶 Secure-use advice for TLS and DTLS, very responsible of them.

[WS-API] Hickson, I., Ed., "The WebSocket API", W3C Candidate Recommendation, September 2012, <https://www.w3.org/TR/2012/CR-websockets-20120920/>. 🧚 The browser-side WebSocket API.

---

Appendix A. Implementation Guidelines: MSRP WebSocket Client Considerations 🎀

okay this part is a little plot twist, so pay attention 👀 The JavaScript stack in web browsers can't figure out the local transport address that's used for opening WebSocket connections. 😭 So the MSRP WebSocket Client makes up its own domain name, made of a random token followed by the .invalid top-level domain, as described in [RFC2606]. Then it uses that name inside its From-Path headers. Lowkey genius.

The From-Path URI that MSRP clients send when they use an MSRP relay doesn't get used for routing MSRP messages. So it's totally safe to put a random domain in the hostpart of that URI. 🌸 No routing drama, no cap.

Acknowledgements 🫶

Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and Victor Pascual, the authors of [RFC7118], which inspired this whole document. 👑

Additional thanks to Inaki Baz Castillo, who pointed out that "web browser" shouldn't be used all the time, since this spec should be valid for smartphones and apps other than browsers. He also suggested clarifications to the SDP handling for MSRP over WebSocket. 💅

Special thanks to James Wyatt from Crocodile RCS Ltd for helping with the JavaScript MSRP-over-WebSockets prototyping. 🐊

Special thanks to Anton Roman, who 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. 💜

Thanks to Ben Campbell, Inaki Baz Castillo, Keith Drage, Olle Johansson, and Christer Holmberg for their thoughtful discussion comments and review feedback, which 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. The whole squad showed up 🥹

Authors' Addresses 📮

Peter Dunkley
Xura
Lancaster Court
8 Barnes Wallis Road
Fareham  PO15 5TU
United Kingdom

Email: peter.dunkley@xura.com

Gavin Llewellyn
Xura
Lancaster Court
8 Barnes Wallis Road
Fareham  PO15 5TU
United Kingdom

Email: gavin.llewellyn@xura.com

Victor Pascual
Oracle

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

Email: gsalguei@cisco.com

Ram Mohan Ravindranath
Cisco Systems, Inc.

Email: rmohanr@cisco.com