RFC 7701
Multi-party Chat Using the Message Session Relay Protocol (MSRP)
RFC 7701 🎀
Okay bestie, so this is RFC 7701, called Multi-party Chat Using the Message Session Relay Protocol (MSRP) ✨. It's an IETF Request for Comments published in December 2015 with ISSN 2070-1721, and it's filed as Standards Track 🌈. The authors are A. Niemi, M. Garcia-Martin (both at Ericsson), and G. Sandbakken (at Cisco Systems) 💖. The header doesn't say it obsoletes or updates any other RFCs, so it's standing on its own 🌸.
Abstract 🦋
Okay so MSRP is the protocol for sending instant messages (IMs) inside a peer-to-peer session, and those sessions get set up using SIP and SDP 💬. This doc gives you the necessary tools for multi-party chat sessions, aka chat rooms, using MSRP. It's giving organized group chat energy 🫶.
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, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚.
For the latest on this doc's status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7701 🔗.
Copyright Notice ⚖️
Copyright (c) 2015 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), as they stand on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, the same way the Simplified BSD License says 💅.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls the copyright in those 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 🚫. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌍.
Table of Contents 🗺️
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Motivations and Requirements ....................................6
4. Overview of Operation ...........................................7
4.1. Policy Attributes of the Chat Room ........................10
5. Creating, Joining, and Deleting a Chat Room ....................12
5.1. Creating a Chat Room ......................................12
5.2. Joining a Chat Room .......................................12
5.3. Deleting a Chat Room ......................................14
6. Sending and Receiving Instant Messages .........................14
6.1. Regular Messages ..........................................14
6.2. Private Messages ..........................................17
6.3. MSRP Reports and Responses ................................19
6.4. Congestion Avoidance ......................................20
7. Nicknames ......................................................21
7.1. Using Nicknames within a Chat Room ........................22
7.2. Modifying a Nickname ......................................24
7.3. Removing a Nickname .......................................25
7.4. Nicknames in Conference Event Packages ....................25
8. The SDP 'chatroom' Attribute ...................................25
9. Examples .......................................................28
9.1. Joining a Chat Room .......................................28
9.2. Setting Up a Nickname .....................................30
9.3. Sending a Regular Message to the Chat Room ................31
9.4. Sending a Private Message to a Participant ................33
9.5. Chunked Private Message ...................................35
9.6. Nickname in a Conference Information Document .............35
10. IANA Considerations ...........................................37
10.1. New MSRP Method ..........................................37
10.2. New MSRP Header ..........................................37
10.3. New MSRP Status Codes ....................................37
10.4. New SDP Attribute ........................................38
11. Security Considerations .......................................38
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................43
Acknowledgments ...................................................43
Contributors ......................................................43
Authors' Addresses ................................................441. Introduction 🌷
Okay so MSRP [RFC4975] is the mechanism for sending a series of instant messages inside a session 📨. SIP [RFC3261] together with SDP [RFC4566] lets two peers set up and manage those sessions 🤝.
SIP can also do multi-party conversations, called "conferences," hosted by a specialized UA called a "focus" [RFC4353] 🎪. A conference can totally involve MSRP sessions too 💕. Here's the key bit: the entity handling the media has to relay IMs it gets from one participant to everyone else in the conference 🔁.
There are already a bunch of systems out there that do this. Participants in a chat room can go by a pseudonym or nickname, and they get to decide whether their real identifier is shared with other participants 🎭. They can also use a super rich set of features, like sending private instant messages to other participants 🤫.
Similar conferences with chat room functionality already exist too. Some examples are Internet Relay Chat (IRC) [RFC2810], Extensible Messaging and Presence Protocol (XMPP): Core [RFC6120], plus plenty of proprietary systems 🌐. Specifying equivalent functionality for MSRP-based systems makes it easier for these systems to work together 🫶.
This document defines the requirements, conventions, and extensions for private messages and nickname management in centralized chat rooms with MSRP 💜. Participants in a chat room can be identified by a pseudonym and decide whether their real identifier should be disclosed to other participants 🦋. This memo uses the SIP Conferencing Framework [RFC4353] as its design basis, and it also aims to be compatible with "A Framework for Centralized Conferencing" [RFC5239] ✨. If requirements come up later, future mechanisms for similar functionality in generic conferences might be developed, for example where the media isn't restricted to MSRP only 🔮. The mechanisms in this document are a future-compatible short-term solution for MSRP centralized chat rooms 🧚.
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 BCP 14 [RFC2119], and they indicate requirement levels for compliant implementations 🔥.
This memo deals with "Tightly Coupled SIP Conferences" as defined in the SIP Conferencing Framework [RFC4353], and it adopts the terminology from that doc 🧠. We also introduce some new terms:
- Nickname: a pseudonym or descriptive name associated with a participant. See Section 7 for details 🎀.
- Multi-party Chat: an instance of a tightly coupled conference, where the media exchanged between the participants consists of MSRP-based IMs. Also known as a chat room 💬.
- Chat Room: a synonym for a multi-party chat 🏠.
- Chat Room URI: a URI that identifies a particular chat room and that is a synonym of a "Conference URI" as defined in RFC 4353 [RFC4353] 🔗.
- Sender: the chat room participant who originally created an IM and sent it to the chat room server for further delivery 📤.
- Recipient: the destination chat room participant(s). This defaults to the full conference participant list minus the IM Sender 📥.
- MSRP Switch: a media-level entity that is an MSRP endpoint. It's a special MSRP endpoint that receives MSRP messages and delivers them to the other chat room participants. It has a similar role to a conference mixer, with one difference: the MSRP switch does not actually "mix" together different input media streams. It just relays the messages between chat room participants 🔀.
- Private IM: an IM sent in a chat room intended for a single participant. Generally speaking, a private IM is seen by the MSRP switch, in addition to the sender and recipient. A private IM is usually rendered distinctly from the rest of the IMs, which shows that the message was a private communication 🤫.
- Anonymous URI: a URI that conceals the participant's SIP address of record (AOR) from the other participants in the chat room. The allocation of such a URI is out of scope of this specification. An anonymous URI must be valid for the length of the chat room session, and the MSRP switch will use it to forward messages to and from anonymous participants. Privacy and anonymity are discussed in greater detail in RFC 3323 [RFC3323] and RFC 3325 [RFC3325] 🕶️.
- Conference Event Package: a notification mechanism that lets conference participants learn conference information, including roster and state changes in a conference. This would typically be the mechanisms defined in "A Session Initiation Protocol (SIP) Event Package for Conference State" [RFC4575] or "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)" [RFC6502] 📡.
- Identifier: a string used to recognize or establish someone as a particular user 🪪.
- To log in: to enter identifying data, like a name or password, into a chat room, so you can do work with the chat room 🔑.
3. Motivations and Requirements ✨
okay so conference frameworks already exist, like "A Framework for Centralized Conferencing" [RFC5239] and the SIP Conferencing Framework [RFC4353] 📚 but the exact details of session-based instant messaging conferences (aka chat rooms) are still kinda undefined 🙈
so we need some conventions for MSRP chat rooms so that chat implementations can actually work together 🫶 this is true for both conference-aware and conference-unaware UAs. it also makes sense to add a set of features on top of baseline multi-party MSRP. that way we can build systems that are just as iconic as existing chat apps and also build interworking gateways to those apps 💅
here are the requirements we're working with:
- REQ-1: the basic one. There has to be a chat room where participants can join, leave, and swap IMs with everyone else in it 💬
- REQ-2: when you get an IM in a chat room, you must be able to tell who sent it 👀 the identifier you see depends on the one the sender used when they joined the room.
- REQ-3: when you get an IM in a chat room, you must be able to tell who it was addressed to 🎯 it could be the whole room or just one person (a private message). The identifier you see might depend on the one the recipient used when they joined the room.
- REQ-4: it must be possible to send a message to one single participant in the chat room. that's a private IM 🤫
- REQ-5: a chat room participant may have a nickname or pseudonym tied to their real identifier 🎀
- REQ-6: it must be possible for a participant to change their nickname while the chat room session is still going 🔄
- REQ-7: it must be possible for a participant to be known only by an anonymous identifier, and not by their real identifier, to the rest of the room 🦋
- REQ-8: it must be possible for chat room participants to find out the chat room capabilities described in this document 🌈
4. Overview of Operation 🗺️
okay first things first: a chat room must be created before anyone can enter it 🏗️ if you want to host one yourself, go for it! your UA just levels up from an ordinary UA into a special one called a "Focus UA" 👑 another super common setup is a dedicated node in the network that works as the Focus UA 🖥️
every chat room gets its own identifier: a SIP URI that people use to join, for example by sending an INVITE request to it 💌 the conference focus handles those invitations, so it keeps SIP dialogs going with each participant 🤝 in a multi-party chat (a.k.a. a chat room), MSRP is one of the established media streams 🌊 each participant sets up an MSRP session with the MSRP switch, which is a special-purpose MSRP application ⚡ the MSRP sessions can get relayed by one or more MSRP relays, which are specified in RFC 4976 [RFC4976] 🛰️ here's the picture (Figure 1):
MSRP Sessions
+--------------------------+
| |
+---+--+ +---+--+ |
| SIP | | SIP | |
| MSRP | | MSRP | +-----+-----+
|Client| |Client| | MSRP |
+---+--+ ++--+--+ | Relay |
| | \ +-----+-----+
SIP Dialogs | / +----+ |
| | \ | MSRP Sessions
+----+------+--+ | |
| | +-+-----+-----+
| Conference | | MSRP |
| Focus UA |........| Switch |
| | | |
+----+-------+-+ +-+-----+-----+
| \ | |
SIP Dialogs | | +------+ | MSRP Sessions
| \ / |
+---+--+ +-+--+-+ +-----+-----+
| SIP | | SIP | | MSRP |
| MSRP | | MSRP | | Relay |
|Client| |Client| +-----+-----+
+---+--+ +------+ |
| |
+--------------------------+
MSRP Sessions
Figure 1: Multi-party Chat Overview Shown with MSRP Relays
and a Conference Focus UAthe MSRP switch is kinda like a conference mixer 🎚️ it handles the media sessions with every participant AND bridges those streams together 🌉 but here's the tea: unlike a conference mixer, the MSRP switch just forwards messages between participants. it does NOT mix the streams in any way 🙅♀️ here's the setup (Figure 2):
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Figure 2: Multi-party Chat in a Centralized Chat Roomusually, chat room participants also subscribe to a conference event package 📬 that's how they get the conference roster through conference state notifications. so they can see who else is there, including their nicknames 👯
every message in the chat room uses the Message/CPIM wrapper content type [RFC3862] 🎁 this is how the room tells private messages apart from regular ones. when a participant wants to send an IM to the room, they build an MSRP SEND request and hand it to the MSRP switch with a regular payload inside (like a Message/CPIM message with text, HTML, an image, etc.) 🖼️ the Message/CPIM To header is set to the chat room URI 🎯 then the switch fans out the SEND request to all the other participants over their existing MSRP sessions 📣
a participant can also send a private IM to someone whose identifier they already learned, for example through a conference event package 🤫 in this case, the sender makes an MSRP SEND request with a Message/CPIM wrapper whose To header holds the recipient's URI, NOT the chat room URI 💌 the MSRP switch then forwards the SEND request to that recipient. this spec supports private messages to one and only one recipient. BUT if that recipient is logged in from different endpoints, the MSRP switch will deliver the private message to each endpoint they're logged in on 📱💻
we also extend the MSRP negotiation that happens in SDP [RFC4566] 🪄 this lets participants find out whether the chat room supports functions defined in this memo, like nicknames or private messaging, AND whether it's willing to accept them (for example, because of local policy restrictions) 🛡️ this is done with a new 'chatroom' attribute in SDP (check out Section 8 for the full details ✨).
when a participant wants to leave a chat room, they send a SIP BYE request to the Focus UA 👋 that ends the SIP dialog with the focus and the MSRP sessions with the MSRP switch 🚪
this document assumes each chat room gets its own SIP URI 🔗 a user joining a chat room sends an INVITE request to that URI, and as a result, a new MSRP session gets set up between the user and the MSRP switch 🌸 it's assumed that an MSRP session maps to a chat room. if a user wants to join a second chat room, they create a different INVITE request through a different SIP dialog, which creates a second MSRP session between them and the MSRP switch 👯♀️ and yes, these two MSRP sessions can still be multiplexed over the same TCP connection, following the usual MSRP procedures 🧦 BUT each chat room is tied to its own unique MSRP session AND its own unique SIP dialog 🦋
4.1. Policy Attributes of the Chat Room 💅
okay so the Conference Framework with SIP [RFC4353] defines a Conference Policy as "The complete set of rules governing a particular conference." 📜 a chat room is a super specific type of conference, and sometimes its policy gets extra chat-only rules sprinkled on top ✨. this section is the checklist of every Conference Policy attribute this doc uses, and it tells you where each one gets the full explanation 🫶
- Nicknames: whether the chat room accepts users to be recognized with a nickname 🏷️. see Sections 7, 7.1, and 8 for details. also, the scope of uniqueness of the nickname: the chat room (conference instance), a realm or domain, a server, etc.
- Nickname quarantine: the quarantine that gets imposed on a nickname once it's not currently in use (e.g., because the participant holding it abandons the chat room), before the nickname is widely available to other users ⏳. this lets the original holder join the chat room during the quarantine period and claim the same nickname they were using before 💜. see Section 11 for details.
- Private messaging: whether the chat room lets users send private messages to other users of the chat room through the MSRP switch 🤫. see Sections 6.2 and 8 for details.
- Deletion of the chat room: whether the chat room can be deleted when the creator leaves the chat room, or through an out-of-band mechanism 🗑️. see Section 5.3 for details.
- Simultaneous access: whether a user can log in from different endpoints using the same identity 📱💻. see Sections 6.1 and 6.2 for details.
- Force TLS transport: whether the MSRP switch accepts only Transport Layer Security (TLS) as an MSRP transport, to guarantee confidentiality and privacy 🔐. see Section 11 for details.
- Maximum message size in congested MSRP sessions: the maximum size of messages that can be distributed to a user over a congested MSRP session 🚦. see Section 6.4 for details.
- Chunk reception timer: the value of a time that controls the maximum time the MSRP switch waits to receive the different chunks belonging to the same message ⏱️. if the timer expires, the MSRP switch discards the associated message state 💀. see Section 6.1 for details.
- Supported wrapped media types: the list of media types that the MSRP switch accepts in Message/CPIM wrappers sent from participants 🎁. this list is included in the
accept-wrapped-typesattribute of the MSRP message media line in SDP. if the MSRP switch accepts additional media types beyond the ones explicitly listed, a"*"gets added to the list. a single"*"means the chat room accepts any wrapped media type 🌈.
5. Creating, Joining, and Deleting a Chat Room 🎀
5.1. Creating a Chat Room 🌸
since a chat room is treated as a special kind of conference that has MSRP media, the methods the SIP Conference Framework [RFC4353] uses for creating conferences totally apply to chat rooms too ✨.
once a chat room is created, it's identified by a SIP URI, just like any other conference 🪪.
5.2. Joining a Chat Room 🚪
participants usually join by sending an INVITE request to the chat room URI 💌. the chat room then uses regular SIP mechanisms to authenticate the participant 🔑. that can include stuff like client certificates, SIP Digest authentication [RFC3261], asserted network identity [RFC3325], SIP Identity header field [RFC4474], etc. as long as the user is authenticated, the focus accepts the INVITE request and brings the user into the actual chat room 🎉.
this spec requires all IMs to be wrapped in a Message/CPIM wrapper [RFC3862] 📦. so the accept-types attribute for the MSRP message media in both the SDP offer and answer needs to include at least the value Message/CPIM (notice that RFC 4975 [RFC4975] mandates this accept-types attribute in SDP). if the accept-types attribute doesn't contain Message/CPIM, the conference focus rejects the request 🙅♀️. the actual instant message payload type is negotiated in the accept-wrapped-types attribute in SDP (see RFC 4975 [RFC4975] for details). there is no default wrapped type 🤷♀️. typical wrapped type values include text/plain, text/html, image/jpeg, image/png, audio/mp3, etc. It is RECOMMENDED that participant endpoints add an accept-wrapped-types attribute to the MSRP message media line in SDP, where the supported wrapped types are declared, as per RFC 4975 procedures [RFC4975] 💖.
the MSRP switch needs to know the URIs of the participant (SIP, tel, or IM URIs) so it can validate messages sent from that participant before forwarding them 🕵️♀️. this info is known to the focus of the conference, so an interface between the focus and the MSRP switch is assumed. however, that interface is outside the scope of this document 🧱.
conference-aware participants will detect that the peer is a focus because of the "isfocus" feature tag [RFC3840] in the Contact header field of the 200-class response to the INVITE request 👀. conference-unaware participants won't notice it's a focus, so they can't apply the extra mechanisms defined in this document 😭. participants also know the mixer is an MSRP switch because of a message media type and either TCP/MSRP or TCP/TLS/MSRP as the protocol field in the media line of SDP [RFC4566] 🧠.
the conference focus of a chat room MUST only use a Message/CPIM [RFC3862] top-level wrapper as a payload of MSRP messages, and the focus MUST declare it in the SDP offer or answer as per regular procedures in RFC 4975 [RFC4975] 🫡. this means that if the conference focus gets an SDP offer from a participant's endpoint that doesn't include Message/CPIM in the accept-types attribute for the MSRP message media line, the conference focus SHOULD either reject the MSRP message media stream or reject the complete SDP offer using regular SIP or SDP procedures. for example, it can create an SDP answer that sets the port of the MSRP message media line to zero, or respond to the INVITE with a 488 response, etc. 🙅♀️.
if the conference focus accepts the participant's SDP offer, then when it generates the SDP answer, it MUST set the accept-types attribute for the MSRP message media line to Message/CPIM 📝. since this spec requires all IMs to be wrapped in a Message/CPIM wrapper, the accept-types attribute in this SDP body contains a single value of Message/CPIM 💅. the actual IM payload type is negotiated in the accept-wrapped-types attribute in SDP (see RFC 4975 [RFC4975] for details). The conference focus MAY also add an accept-wrapped-types attribute to the MSRP message media line in SDP containing the supported wrapped types, according to the supported wrapped media types policy 🎈.
Note that the Message/CPIM wrapper carries the sender information, which otherwise wouldn't be available to the recipient 🕊️. it also carries the recipient information (e.g., To and Cc headers) 💌.
if the UA supports anonymous participation and the user chooses to use it, the participant's UA SHOULD do at least one of these options 🥷:
- (a) provide an anonymous URI in SIP headers that would otherwise reveal identifiers. please refer to RFC 3323 [RFC3323] for a detailed description of which headers are subject to revealing identifiers and how to populate them; or
- (b) trust the conference focus and request privacy of their URI, e.g., by means of the SIP Privacy header field [RFC3323], network asserted identity [RFC3325], or a similar privacy mechanism 🔒.
if the participant has requested privacy, the conference focus MUST expose a participant's anonymous URI through the conference event package [RFC4575] 🫣.
the conference focus of a chat room learns the supported chat room capabilities of the endpoint through the 'chatroom' attribute exchanged in the SDP offer/answer (please refer to Section 8 for a detailed description) 🔍. the conference focus MUST inform the MSRP switch of the chat room capabilities of each participant that joins the chat room (note that the interface between the conference focus and the MSRP switch is outside the scope of this specification) 📣. this info lets the MSRP switch, e.g., avoid distributing private messages to participants whose endpoints don't support private messaging 🙈.
5.3. Deleting a Chat Room 🧹
just like with creating a conference, the methods the SIP Conference Framework [RFC4353] defines for deleting a conference are directly applicable to a chat room 💫. the MSRP switch will terminate the MSRP sessions with all the participants 👋.
deleting a chat room depends a lot on the policy of the chat room 📋. for example, the policy can decide whether the chat room gets deleted when the creator leaves the room, or whether an out-of-band mechanism is responsible for the deletion 🤔.
6. Sending and Receiving Instant Messages 💌
6.1. Regular Messages ✨
okay so this section is all about how we send and receive IMs addressed to everyone in the chat room 💬 these go out as a regular MSRP SEND request, and that request carries a Message/CPIM wrapper [RFC3862] holding the actual payload (text, image, video clip, whatever) 🎀
when a participant wants to send an IM to all the other people in the room, they build an MSRP SEND request following the procedures in RFC 4975 [RFC4975]. the sender MAY choose the MSRP report model they want, like filling in the Success-Report and Failure-Report MSRP header fields 📝
on a regular message, the sender MUST populate the To header of the Message/CPIM wrapper with the URI of the chat room. the sender MUST also populate the From header of the Message/CPIM wrapper with a proper identifier that the room recognizes them by 🫶 some identifiers that work (among others) are:
- A SIP URI [RFC3261] representing the participant's address-of-record
- A tel URI [RFC3966] representing the participant's telephone number
- An IM URI [RFC3860] representing the participant's instant messaging address
- An anonymous URI representing the participant's anonymous address
🙈 the anonymity bit
if the participant wants to stay anonymous, their endpoint MUST populate an anonymous URI in the From header of the Message/CPIM wrapper. other participants will then use this anonymous URI in the To header of the Message/CPIM wrapper when sending private messages. notice that in order for the anonymity mechanism to work, the anonymous URI MUST NOT reveal the participant's SIP AOR. the mechanism for acquiring an anonymous URI is outside the scope of this specification, so it's not in here 🦋
🛡️ the switch checks the vibes (aka validation)
an MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI of a participant. this means the focus of the conference has to tell the MSRP switch which URIs each participant is known by, so the switch can validate messages 💅 Section 6.3 has more on what to do if this validation fails.
then the MSRP switch should inspect the To header field of the Message/CPIM wrapper. if the MSRP switch gets a message with several To header fields in the Message/CPIM wrapper, it MUST reject the MSRP SEND request with a 403 response, as per the procedures in RFC 4975 [RFC4975]. 💀 otherwise, if the To header field contains the chat room URI and there are no other To header fields, the MSRP switch can make a copy of the SEND request for each participant in the chat room except the sender. the MSRP switch MUST NOT modify the content received in the SEND request. however, the MSRP switch MAY re-chunk any of the outbound MSRP SEND requests ✨
🎀 checking what each person can actually open
when making a copy of the SEND request for each participant, the MSRP switch MUST evaluate the wrapped media types that the recipient is able to accept. this info comes from the 'accept-wrapped-types' attribute on the MSRP message media line in SDP 🌸 if the MSRP switch knows the media type of the wrapped content isn't acceptable to the recipient, the MSRP switch SHOULD NOT forward this message to that endpoint. fair warning: this version of the spec does not require the MSRP switch to tell the sender about this failure. extensions to this spec may improve how unknown media types get handled 🔥
⚡ fast forwarding (the speedy route)
the MSRP switch doesn't have to wait for the complete MSRP chunk or MSRP message before it starts distributing to everyone else. instead, once it has received the headers of the Message/CPIM wrapper, it SHOULD start the distribution process. but bear in mind that the MSRP switch SHOULD still implement some sanity checking. for the details, check the security considerations in Section 11 🔐
when forwarding chunked messages as soon as they arrive, the Message/CPIM wrapper only shows up at the very beginning, usually in the first chunk. later chunks have the rest of the message but not the Message/CPIM headers 😭 so an MSRP switch handling a later message might struggle to figure out who the recipients are. an MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-ID of the MSRP message to correlate the different chunks. it MUST also temporarily store the list of recipients the initial chunks went to. the MSRP switch SHOULD forward subsequent chunks only to those recipients who were sent the initial chunks, unless the MSRP switch knows one of the recipients of the initial chunks has dropped from the chat room. this also keeps new participants who joined after the first chunk went out from receiving later chunks that would otherwise have to be thrown away 🧚
once the MSRP switch gets the last chunk of a message, and that chunk is successfully sent to each recipient, it discards the temporary storage of the MSRP Message-ID and the associated list of recipients 🧹
⏰ the chunk timer (don't let storage get clogged!)
sometimes a sender hits a transport error (like losing connectivity or running out of battery) and the message ends up incomplete, e.g., some chunks made it to the MSRP switch but not all of them 🪫 this is already covered in the core MSRP spec (see RFC 4975 [RFC4975] Section 5.4). the tricky part in a chat room is the temporary storage used for fast forwarding. to prevent attacks that exhaust that storage with chunked messages, when the MSRP switch gets a first chunk of a message and is using the fast forward method, it MUST set a chunk reception timer to control the reception of the remaining chunks 🚨
this chunk reception timer can be reset every time a new chunk of the same message comes in. when the timer expires, the MSRP switch MUST consider the sending of the message to have been aborted, and it MAY discard all the message state tied to it, including the Message-ID and the list of recipients. if the timer expires, the MSRP switch MAY also choose to send an abort chunk (i.e., one with the "#" flag set) to each of the recipients. this is just an optimization, since MSRP endpoints need to be able to handle incomplete messages as per regular MSRP 💜
the specific value of this chunk reception timer is not standardized; it is subject of local policy. however, it is recommended not to be a short value. for example, a time interval on the order of a normal TCP timeout (i.e., around 540 seconds) would be reasonable. a value on the order of a few seconds would not 🙅♀️
📥 the endpoint's turn
an MSRP endpoint that receives a SEND request from the MSRP switch containing a Message/CPIM wrapper SHOULD first inspect the To header field of the Message/CPIM wrapper. if the To header field is set to the chat room URI, it should render it as a regular message that has been distributed to all the participants in the chat room. then the MSRP endpoint SHOULD inspect the From header field of the Message/CPIM wrapper to identify the sender. the From header field will include a URI that identifies the sender. the endpoint might also have received further identifier information through a subscription to a conference event package 👑
🦋 same person, multiple devices
it's possible that a participant, identified by a SIP AoR or other valid URI, joins a chat room at the same time from two or more different SIP UAs. it is recommended that the MSRP switch implements means to map a URI to two or more MSRP sessions 🌈 if the policy of the chat room allows simultaneous access, the MSRP switch MUST copy all regular messages intended for the recipient through each MSRP session mapped to the recipient's URI. main character energy, no cap 💖
6.2. Private Messages
okay so this section is all about private IMs 🫣🎀 the ones addressed to just ONE participant instead of everyone in the chat room. 💌 Whether a chat room even does private messages is up to its local policy, and it's like a little signal: the room can say "yep, private messages are a thing here" using the 'chatroom' attribute in SDP (go peek at Section 8 for the full tea 🍵).
So when a participant wants to slide into someone's DMs, they follow the exact same steps as a regular message to build a SEND request (Section 6.1) ✨. The ONLY difference is that the MSRP endpoint MUST put a single To header in the Message/CPIM wrapper with the identifier of the person they're messaging 💅. That identifier can be a SIP, tel, or im URI, and it's usually something you learned from notifications of a conference event package 📬.
This version of the spec doesn't do group DMs 🙅♀️ Like, sending one private message to multiple recipients (aka having multiple To headers in the Message/CPIM wrapper of the MSRP SEND request) is a no-go right now. Why? Because it gets messy fast 😭 think about figuring out whether a message didn't reach some of the people it was meant for. If you still want that vibe, just send a bunch of single private messages, one per person 🫶. The endpoint can then correlate all of them so it looks like one message to a group. Iconic workaround, honestly 🧚
As for regular messages, when an MSRP switch gets a SEND request from a participant, it SHOULD first check that the From header field of the Message/CPIM wrapper is correctly filled in with a valid URI (basically, is this URI actually a participant of this chat room? 🕵️♀️). Section 6.3 covers what happens if that check fails.
Next up, the MSRP switch looks at the To header field of the Message/CPIM wrapper 👀. If it sees several To header fields in there, the switch MUST reject the MSRP SEND request with a 403 response, following the procedures in RFC 4975 [RFC4975] 🚫. Then it checks that the To header matches the URI of someone in the chat room. If that To header doesn't contain a participant's URI, or it can't be resolved at all (like if there's a typo in the URI 🙃), the switch MUST reject the request with a 404 response. This is a brand new 404 status code that specifically means "I couldn't resolve the recipient URI in the To header of the Message/CPIM wrapper" 💀.
Okay bestie, pay attention to this one 🚨 The From and To headers in the Message/CPIM wrapper are SUPER important. If some intermediary modifies those values, the MSRP switch might not be able to tell who sent the message or who it's meant for, and then the message gets rejected 😭 no cap.
Finally, the MSRP switch checks that the recipient actually supports private messages 🥺. If they don't, the switch MUST reject the request with a 428 response. This brand new 428 response basically says "this recipient doesn't do private messages" 🙅. Any REPORT request the MSRP switch might send back to the sender MUST include a Message/CPIM wrapper that has the original From header from the SEND request AND the To header from the original Message/CPIM wrapper 📝. And the MSRP switch MUST NOT forward private messages to anyone who doesn't support private messaging. Period. No exceptions, main character energy 👑.
If everything checks out, the MSRP switch SHOULD look up its mapping table to find the MSRP sessions that were set up toward the recipient 🗺️. If it finds a match, the switch MUST create a SEND request and MUST copy the contents of the sender's message into it ✨.
When an MSRP endpoint gets a SEND request from the MSRP switch, it runs the same validations as it would for regular messages (Section 6.1) 🔍. If the To header is different from the chat room URI, the endpoint knows "ooh, this is a private message" 🤫. It SHOULD render who it's from based on the From header of the Message/CPIM wrapper 🎭. It can also use the sender's nickname, maybe learned through a conference event package, to show who sent it instead of their actual URI 🌸.
And just like regular messages, if the chat room policy allows simultaneous access, the MSRP switch MUST copy all private messages meant for the recipient through EACH MSRP session mapped to that recipient's URI 🦋.
6.3. MSRP Reports and Responses
okay so this section covers the shared rules for regular AND private messages when it comes to MSRP reports and responses 📋💖. Anything that only affects one type gets its own spot in the previous sections (6.1 for regular, 6.2 for private) 🧚.
MSRP switches MUST follow the success report and failure report handling from Section 7 of RFC 4975 [RFC4975], plus the extra stuff in this section 🫶. The MSRP switch MUST act as an MSRP endpoint receiver of the request, following Section 5.3 of RFC 4975 [RFC4975] 🎀.
If the MSRP switch gets an MSRP SEND request with NO Message/CPIM wrapper, it MUST reject the request with a 415 response (which is specified in RFC 4975 [RFC4975]) 🙅♀️.
If the MSRP switch receives an MSRP SEND request where the URI in the From header of the Message/CPIM wrapper is NOT valid (like if it doesn't "belong" to the sender or isn't a valid participant of the chat room 😤), the switch MUST reject the request with a 403 response. In cases without an error, the MSRP switch MUST construct responses according to Section 7.2 of RFC 4975 [RFC4975] ✨.
When the MSRP switch forwards a SEND request, it MAY use any report model for the copies going to the recipients 📨. The receiver reports from the recipients MUST NOT be forwarded back to the originator of the original SEND request 🙈. This could mean the sender gets multiple reports for a single MSRP request, so be ready for that 😭💅.
6.4. Congestion Avoidance
okay real talk, congestion can happen when a bunch of users on different kinds of connections are all in one chat room, especially when paths get overloaded by any app 🚦💀. Some people have fast paths with high throughput 🚀, while others are on slow, constrained paths 🐢. Some paths only get congested because of the chat app, and others get clogged by other apps too 😩. So it's totally possible that some participants can blast out tons of messages in a short time (or huge ones, like pictures 📸), while others just can't keep up 🥲.
Also, MSRP uses a connection-oriented transport like TCP, so TCP congestion control is expected to kick in if congestion happens 🌊. The details live in RFC 5681 [RFC5681] 📖.
This document doesn't REQUIRE any one MSRP-specific way to avoid congestion on those paths 🙅, since that's considered outside its scope. But it does give some recommendations for implementors to think about 💡.
It is RECOMMENDED that MSRP switches implement one or more MSRP-specific strategies to detect and avoid congestion 🫧. Some possible strategies (and this is definitely NOT a full list 🙈) include:
- If the MSRP switch is writing data to a send buffer and sees that the send buffer for that TCP connection is getting full (say, close to 80% capacity 📊), the switch marks the MSRP sessions using that TCP connection as "congested" 🚩.
- Before sending a new MSRP message to a user, the MSRP switch checks the congested flag on that MSRP session 🔎. If the session is marked congested, the switch can apply a congestion avoidance mechanism, such as:
- The MSRP switch MAY discard regular MSRP messages sent to that user while the congestion flag is raised for the user's TCP connection 🗑️. To let the user know what's going on, the MSRP switch MAY send a regular MSRP message to the congested user saying some messages are being dropped because of network congestion 📣. Heads up though: this message can get stuck at the MSRP switch if the path is fully congested, so it may not be delivered at all 😬.
- The MSRP can implement a temporary policy to stop distributing messages larger than a certain size to congested MSRP sessions 🚫📦. Similarly, the MSRP switch should let the user know about this by sending a regular MSRP message that explains the situation 💌.
- If the MSRP switch notices the congestion flag on a TCP connection has been raised for quite some time (on the order of a few minutes ⏳), or if the interface is down 🔌, that may mean the TCP connection couldn't recover from congestion. The MSRP switch MAY close this congested TCP connection, as well as the MSRP session and SIP session 🧹.
7. Nicknames
okay so, a super common thing in chat room services is that participants can show up with a nickname for everyone else in the room 🎀. It's how people get easily referenced, and it can give anonymous participants a fun, descriptive name too 🦋.
Nicknames are useful in lots of situations, and MSRP chat is just one of them 🌈. A nickname is tied to a URI, and the focus knows a participant by that association 🔗. So if someone joins the chat room with the same URI from multiple devices, they can ask for the same nickname on all of them 📱📱.
A nickname is a user-picked moniker that a participant wants everyone else to know them by 💅. It's NOT a 'display-name', but it gets used kind of like one 🫶. The big difference is that a nickname MUST be unique inside a chat room so you can reference someone unambiguously 🔍. Nicknames can be long-lived or temporary ⏰, and users also need to reserve a nickname before they start using it 📝.
This memo specifies the nickname as a string 🧵. The nickname string MUST unambiguously be associated with a single user within the scope of the chat room (conference instance) 🎯. This scope is kind of like having a nickname unique per user inside a chat room, the way "Extensible Messaging and Presence Protocol (XMPP): Core" [RFC6120] describes 💖. The chat room may have policies about nicknames 📜. It might not accept nickname strings at all, or it might offer a wider unambiguous scope, like a domain or server, similar to IRC [RFC2810] 🌸✨.
7.1. Using Nicknames within a Chat Room ✨
okay so this section is about reserving a nickname 💖 that stays yours for as long as you're logged into the chat room 🎀. It works through a NICKNAME MSRP method (more on that below 👇) plus a brand new "Use-Nickname" header 💅. Other ways to reserve one might exist too, like a web page reservation system 🌸, but those are outside the scope of this doc, so we're not getting into them 🙈.
A chat room participant who has an MSRP session going with the MSRP switch can send a NICKNAME request, but only if the switch has said it supports nicknames through the nicknames token in the chatroom SDP attribute ✨. That's the participant who MAY send a NICKNAME request to the MSRP switch 🦋. The request MUST include a new Use-Nickname header holding the nickname string you want to reserve. That string MUST NOT be zero octets long and MUST NOT be more than 1023 octets long. And last but not least, MSRP NICKNAME requests MUST NOT include Success-Report or Failure-Report header fields 🙅♀️.
pro tip, bestie: nickname strings are UTF-8 just like the rest of the MSRP message [RFC3629] 🌈, so one character can take up more than one octet. Don't count characters, count octets!
When an MSRP switch gets a NICKNAME request with a Use-Nickname header, it SHOULD first check whether the chat room's policy allows nicknames at all 👀. If nicknames aren't allowed, the MSRP switch MUST reject the request with a 403 response, as per RFC 4975 [RFC4975] 🚫.
If the policy DOES allow nicknames, then any new nickname requested MUST be prepared and compared with nicknames that are already in use or reserved, following the rules in "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames" [RFC7700] 🧼.
This takes care of duplicate nicknames 🙌, but it doesn't stop people from picking look-alike characters. For example, BOY and B0Y are different nicknames that can totally mislead people 💀. The first one uses the capital letter "O" and the second uses the number zero "0". In a lot of fonts those two look almost identical, so they're hard to tell apart. Chat rooms MAY provide a mechanism to mitigate confusable nicknames 🫶.
On top of all the preparing and comparing above, the MSRP switch SHOULD only allow reserving an already-used nickname if the same user (for example, someone identified by the SIP AOR) is the one currently using it and making this new request 💜. This could mean the participant's URI is allowed to use the same nickname when they've joined the chat room from different devices under the same URI 📱💻. The participant's authenticated identifier can come from a successful SIP Digest Authentication [RFC3261], from a trusted SIP P-Asserted-Identity header field [RFC3325], from a valid SIP Identity header field [RFC4474], or from any other present or future SIP authentication mechanism 🔐. Once the MSRP switch has checked that the participant is allowed to reserve the requested nickname, it verifies whether the suggested nickname can be accepted (see below) ✅.
Reserving a nickname can fail in a few different ways 😬. If the NICKNAME request has a malformed value in the Use-Nickname header field, the MSRP switch MUST answer the NICKNAME request with a 424 response code. That happens when the value of the Use-Nickname header field doesn't follow the syntax 📏.
Reservation can also fail if the Use-Nickname value in the NICKNAME request is a reserved word (nobody is allowed to use it as a nickname) or if that exact value is already taken by another user 🚧. In those cases, the MSRP switch MUST answer the NICKNAME request with a 425 response code.
Either way, with a 424 or a 425, the nickname usage counts as failed and the nickname is NOT given to that user. The user can pick a different nickname and send another NICKNAME request 🔁.
And if the MSRP switch CAN accept the suggested nickname for this user, the MSRP switch MUST answer the NICKNAME request with a 200 response, following the regular MSRP procedures 🎉.
As I mentioned earlier, this spec introduces a new MSRP header field called Use-Nickname 🆕. It carries a nickname string and is only defined for use in NICKNAME requests. If a need comes up, usages of Use-Nickname in other MSRP methods should be specified separately 📝.
According to RFC 4975 [RFC4975], MSRP uses the UTF-8 transformation format [RFC3629] 🌍. The syntax of the MSRP NICKNAME method and the Use-Nickname header field is built on the MSRP formal syntax [RFC4975] using Augmented Backus-Naur Form (ABNF) [RFC5234] 🧩. Here's the grammar, bestie 🤓:
other-method =/ NICKNAMEm
; other-method defined in RFC 4975
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header defined in RFC 4975
Use-Nickname = "Use-Nickname:" SP nickname
nickname = DQUOTE 1*1023(qdtext / qd-esc) DQUOTE
; qdtext and qd-esc defined in RFC 4975Also, per RFC 4975 [RFC4975], "quoted-string" only admits a subset of UTF-8 characters [RFC3629]. Check out Section 9 of RFC 4975 [RFC4975] for all the juicy details 📖💅.
Once the MSRP switch has reserved a nickname and bound it to a URI (for example, a SIP AoR) 🔗, the MSRP server MAY allow that same user (identified by the same URI, such as a SIP AoR) to use the same nickname over a second MSRP session 👯♀️. This could happen if the user joins the same chat room from a different SIP UA 📲. In that case, the user MAY request a nickname that's the same as or different from the one used with the first MSRP session, and the MSRP server MAY accept the same nickname from that same user 💫. The MSRP switch MUST NOT automatically assign the same nickname to more than one MSRP session established from the same URI 🙅♀️, because that can confuse the user about whether the nickname is bound to the second MSRP session 😵💫.
7.2. Modifying a Nickname 🦋
Usually, a participant reserves a nickname as soon as they join the chat room 🚪. But you can also change your own nickname to a new one at any time while your MSRP session is going 🔄. Changing it works just like the first reservation and usage of a nickname, so the NICKNAME method gets used the same way as described in Section 7.1 💁♀️.
If a NICKNAME request that tries to change your current nickname fails for some reason, your current nickname just stays in effect 🛡️. The new nickname only comes into effect, and the old one only gets released, once a NICKNAME request is accepted with a 200 response ✨.
7.3. Removing a Nickname 🧹
If you no longer want to be known by a nickname in the chat room, you can follow the method described in Section 7.2 🫠. The nickname element of the Use-Nickname header MUST be set to an empty quoted string 🫙.
7.4. Nicknames in Conference Event Packages 🎀
Typically the conference focus acts as a notifier of the conference event package, RFC 4575 [RFC4575] 📣. It is RECOMMENDED that conference foci and endpoints support RFC 6502 [RFC6502] 🗂️, which is for sharing info about the conference and, in particular, the roster of the conference 👥. It is also RECOMMENDED that conference foci and endpoints support RFC 6501 [RFC6501] 💜, which extends the <user> element originally specified in RFC 4575 [RFC4575] with a new 'nickname' attribute. That's how endpoints get to learn the nicknames of chat room participants 🥹✨.
8. The SDP 'chatroom' Attribute ✨
okay so there are a handful of times when a participant really wants to know what the chat room can do, based on the local policy of the MSRP switch and the chat room itself 🧐 like, she wants to find out if the MSRP switch does private messaging. otherwise she might send what she thinks is a private IM to one person, but since the switch doesn't support the stuff in this memo, it ends up going to EVERYONE in the room 💀 not it.
and the reverse is also a thing 😭 say Alice joins with a UA that doesn't do the extensions in this document. the MSRP switch figures out her app can't do private messaging or nicknames. if Bob sends her a private message, the switch won't deliver it to her, because she can't tell it apart from a regular message to the whole roster 🙈 and if she replied, she'd be replying to the whole roster. so the MSRP switch also keeps track of users who don't support the extensions in this document. main character energy for the switch, honestly 💅
then there's the chat room policy. it might say certain functions aren't allowed, like nicknames or private messages being forbidden 🚫
so to make the chat room experience actually good, we define a brand new 'chatroom' SDP attribute 🎀 it's a media-level value attribute [RFC4566] that MAY be included with an MSRP media stream (aka when the "m=" line says "TCP/MSRP" or "TCP/TLS/MSRP"). if you use 'chatroom' with no extra modifiers (like chat-tokens), that just means the endpoint supports the procedures in this document for moving MSRP messages to and from a chat room 🦋 you can also add more modifiers to show where support and local policy overlap for the functions in this document. specifically, you can say whether nicknames and private messaging are supported.
the 'chatroom' attribute only tells you what's supported and allowed by local policy 🧚 it is NOT a negotiation under the SDP offer/answer model [RFC3264], it's just a declaration. so a 'chatroom' attribute in an SDP answer doesn't have to be a subset of the one in its matching SDP offer. which also means an SDP answer MAY contain a 'chatroom' attribute even if its SDP offer didn't have one 🌈
in later SDP offer/answer [RFC3264] exchanges for the same session, the 'chatroom' attribute MAY be changed compared to an earlier exchange 🔄 the new value shows the current support and policy, so some restrictions might be on now, or might have been lifted. and if the 'chatroom' attribute isn't in a later offer/answer but the MSRP stream is still up, that means support for the procedures in this document is turned off ❌
the 'chatroom' SDP attribute has this ABNF [RFC5234] syntax:
attribute =/ chatroom-attr
; attribute defined in RFC 4566
chatroom-attr = chatroom-label [":" chat-token
*(SP chat-token)]
chatroom-label = "chatroom"
chat-token = (nicknames-token / private-msg-token /
ext-token)
nicknames-token = "nickname"
private-msg-token = "private-messages"
ext-token = private-token / standard-token
private-token = toplabel "." *(domainlabel ".") token
; toplabel defined in RFC 3261
; domainlabel defined in RFC 3261
; token defined in RFC 3261
standard-token = tokena given 'chat-token' value MUST NOT appear more than once in a 'chatroom' attribute 🚫 no doubles, bestie.
if a conference focus puts the 'nicknames' token in the session description, it's saying the MSRP switch supports it AND the chat room allows the procedures in Section 7 🏷️ same deal for 'private-messages': that means support plus permission for the procedures in Section 6.2 💜
here's an example of the 'chatroom' attribute for an MSRP media stream that says nicknames and private messages are welcome:
a=chatroom:nickname private-messagesand here's one for an MSRP media stream where the endpoint (like an MSRP switch) doesn't allow nicknames or private messages:
a=chatroomthe 'chatroom' attribute can be extended by adding new tokens ✨ no IANA registry is set up for this right now, since no extensions were expected when this was written. extensions can be defined in IETF documents or as private-vendor extensions 🛠️
extensions defined in an IETF document MUST follow the 'standard-token' ABNF we already defined 🫶 with these, you have to be careful picking the token so it doesn't clash with any of the tokens that already exist.
private extensions MUST follow the 'private-token' ABNF we defined earlier 🔐 the 'private-token' MUST be included in the vendor's DNS name, and then the token gets reversed so tokens don't collide. here's an example of an extension called "foo.chat" from a vendor called "example.com" 🍓
a=chatroom:nickname private-messages com.example.chat.fooone more thing: feature names made by different organizations aren't meant to have the same meaning, or even to interoperate 🙃 so don't assume they match just because the names look alike!
9. Examples 🎀
9.1. Joining a Chat Room
okay, Figure 3 shows Alice joining a chat room by sending an INVITE request 📞 that INVITE carries a session description with the chat room extensions from this document.
Alice Conference Focus
| |
|F1: (SIP) INVITE |
|----------------------->|
|F2: (SIP) 200 OK |
|<-----------------------|
|F3: (SIP) ACK |
|----------------------->|
| |Figure 3: Flow Diagram of a User Joining a Chat Room
F1: Alice builds an SDP description with an MSRP media stream 💖 she also says she supports the chat room extensions from this document. then she sends the INVITE to the chat room server.
INVITE sip:chatroom22@chat.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 290
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 client.atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-messagesF2: the chat room server accepts the session 🥳 it puts the 'isfocus' and other relevant feature tags in the Contact header field of the response. it also builds an SDP answer that forces messages to arrive wrapped in Message/CPIM wrappers 🎁 and it includes the 'chatroom' attribute with the extensions that are allowed.
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: 290
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
a=chatroom:nickname private-messagesF3: the session is set up and acknowledged (details not shown) ✅
9.2. Setting Up a Nickname
Figure 4 shows Alice setting up a nickname through the chat room as the provider 💅 her first proposal gets turned down because somebody already has that name. so she tries again with a new nickname, and this second one gets accepted 🙌
Alice MSRP Switch
| |
|F1: (MSRP) NICKNAME |
|----------------------->|
|F2: (MSRP) 425 |
|<-----------------------|
|F3: (MSRP) NICKNAME |
|----------------------->|
|F4: (MSRP) 200 |
|<-----------------------|
| |Figure 4: Flow Diagram of a User Setting up Her Nickname
F1: Alice sends an MSRP NICKNAME request with her proposed nickname in the Use-Nickname header field 💌
MSRP d93kswow NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice the great"
-------d93kswow$F2: the MSRP switch checks the nicknames already handed out and sees that "Alice the great" already belongs to another participant in the chat room 😬 so it answers with a 425 response.
MSRP d93kswow 425 Nickname reserved or already in use
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------d93kswow$F3: Alice gets the response and proposes a new nickname in a second NICKNAME request 🔁
MSRP 09swk2d NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice in Wonderland"
-------09swk2d$F4: the MSRP switch accepts the new nickname and answers with a 200 response 🎉 "Alice in Wonderland" is officially hers!
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$9.3. Sending a Regular Message to the Chat Room ✨
okay so this is the big group-chat moment 💬 Figure 5 shows Alice sending a regular message to the chat room, and the MSRP switch passes it along to everyone else in the room 🫶
Alice MSRP Switch Bob Charlie
| | | |
| F1: (MSRP) SEND | | |
|--------------------->| F3: (MSRP) SEND | |
| F2: (MSRP) 200 |----------------------->| |
|<---------------------| F4: (MSRP) SEND | |
| |------------------------------->|
| | F5: (MSRP) 200 OK | |
| |<-----------------------| |
| | F6: (MSRP) 200 OK | |
| |<------------------------------ |
| | | |
| | | |
Figure 5: Sending a Regular Message to the Chat RoomF1 💌 Alice writes a text message and wraps it in a Message/CPIM wrapper, addressed to the chat room. She then packs that wrapper into an MSRP SEND request and sends it to the MSRP switch over the existing TCP connection.
MSRP 3490visdm SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------3490visdm$F2 ✅ The MSRP switch replies with a 200 (OK) response to confirm it got the SEND request.
MSRP 3490visdm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: 99s9s2
-------3490visdm$F3 🦋 The MSRP switch builds a brand new MSRP SEND request that carries the same Message/CPIM wrapper and sends it to Bob.
MSRP 490ej23 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: 304sse2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------490ej23$Here's the key bit 🔑 Bob can tell this is a regular message and not a private DM, because the From header of the Message/CPIM wrapper is the chat room URI. He knows it's meant for everyone in the room, not just him 💅
The rest of the message flows are analogous to the previous ones. They're not shown here 🌸
9.4. Sending a Private Message to a Participant 🎀
Figure 6 is a flow diagram where Alice sends a private message addressed to Bob's SIP AOR. This time the MSRP switch delivers it only to Bob 🙈
Alice MSRP Switch Bob
| | |
| F1: (MSRP) SEND | |
|--------------------->| F3: (MSRP) SEND |
| F2: (MSRP) 200 |----------------------->|
|<---------------------| F4: (MSRP) 200 |
| |<-----------------------|
| | |
Figure 6: Sending a Private Message to BobF1 💌 Alice writes a text message and wraps it in a Message/CPIM wrapper, addressed to Bob's URI. She learned that URI from a notification in the conference event package. Then she packs the wrapper into an MSRP SEND request and sends it to the MSRP switch over the existing TCP connection.
MSRP 6959ssdf SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------6959ssdf$F2 ✅ The MSRP switch acknowledges the SEND request with a 200 (OK) response.
MSRP 6959ssdfm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: okj3kw
-------6959ssdfm$F3 🦋 The MSRP switch makes a new MSRP SEND request with the same Message/CPIM wrapper and sends it only to Bob. Bob can see who sent it from the From header of the wrapper. He also knows it's a private message because his own SIP AOR is in the To header of the wrapper 👑
MSRP 9v9s2 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: d9fghe982
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------9v9s2$F4 ✅ Bob acknowledges the SEND request with a 200 (OK) response.
MSRP 9v9s2 200 OK
To-Path: msrp://chat.example.com:5678/jofofo3;tcp
From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
Message-ID: d9fghe982
-------9v9s2$9.5. Chunked Private Message 🧩
The MSRP message below is the same private message from Section 9.4, but this time it's split into two chunks 🍓 The MSRP switch has to wait for the complete set of Message/CPIM headers before it distributes anything 💀
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 1-*/174
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
-------7443ruls$
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 68-174/174
Content-Type: message/cpim
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob
-------7443ruls$9.6. Nickname in a Conference Information Document 🌈
Figure 7 shows an XML conference information document that arrives in a SIP NOTIFY request as a notification to the XCON Conference Event Package, RFC 6502 [RFC6502]. That document follows the XCON Data Model from RFC 6501 [RFC6501] 📋
This document has info on two users in the conference, one <user> element each. Every participant is tied to a nickname, which lives in the 'nickname' attribute of the <user> element 🫧
NOTE: Figure 7 exists to show the user-to-nickname relationship. It is believed that the example is correct according to RFC 6501 [RFC6501]. If this specification and RFC 6501 [RFC6501] ever contradict each other, RFC 6501 [RFC6501] wins 👑
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="sip:chatroom22@chat.example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>MSRP nickname example</subject>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>2</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com"
state="full"
xcon:nickname="Dopey Donkey">
<display-text>Bob Hoskins</display-text>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com"
state="full"
xcon:nickname="Alice the great">
<display-text>Alice Kay</display-text>
</user>
</users>
</conference-info>Figure 7: Nickname in a Conference Information Document
10. IANA Considerations 📝
10.1. New MSRP Method
This specification defines a new MSRP method that has been added to the "Methods" subregistry of the "Message Session Relay Protocol (MSRP) Parameters" registry:
NICKNAMESee Section 7 for details ✨
10.2. New MSRP Header
This specification defines a new MSRP header that has been added to the "Header Fields" subregistry of the "Message Session Relay Protocol (MSRP) Parameters" registry:
Use-NicknameSee Section 7 for details 💖
10.3. New MSRP Status Codes
This specification defines four new MSRP status codes that have been added to the "Status Codes" subregistry of the "Message Session Relay Protocol (MSRP) parameters" registry.
The 404 status code means the recipient's URI in the To header field of the Message/CPIM wrapper in the SEND request couldn't be resolved, for example because the recipient is unknown. See Section 6.2 for details 🔍
The 424 status code means the requested nickname couldn't be allocated because the Use-Nickname header field has malformed syntax. See Section 7 for details 🙃
The 425 status code means the requested nickname couldn't be allocated because it's reserved or already in use by another user. See Section 7 for details 🚫
The 428 status code means the recipient of a SEND request doesn't support private messages. See Section 6.2 for details 🙅♀️
Table 1 sums up the IANA registration data for the new MSRP status codes 📊
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 404 | Failure to resolve recipient's URI | RFC 7701 |
| 424 | Malformed nickname | RFC 7701 |
| 425 | Nickname reserved or already in use | RFC 7701 |
| 428 | Private messages not supported | RFC 7701 |
+-------+-------------------------------------+-----------+
Table 1: New Status Codes10.4. New SDP Attribute 🎀
This specification defines a new media-level attribute in the "Session Description Protocol (SDP) Parameters" registry. The registration data is as follows:
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: chatroom
Long-form attribute name: Chat Room
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute identifies support and local policy
allowance for a number of chat room related functions
Specification: RFC 7701 (this document)See Section 8 for details 🦋
11. Security Considerations 🔐
Okay bestie, security time 🫶 This doc extends MSRP [RFC4975], so all of that document's security considerations apply here too 💅 No skipping them!!
A chat room is, like, a potential Denial-of-Service (DoS) accelerator by its whole nature 💀 It takes one message from one entity and sends it to many people. Both UA and switch implementers need to really think about which anti-DoS measures fit this app 🚨 Switch implementations ought to include appropriate anti-DoS features. What counts as appropriate changes over time and depends on what each implementation needs, so this doc can't spell it out 🤷♀️
If the participant's SIP UA doesn't understand the "isfocus" feature tag [RFC3840], it won't know it's connected to a conference instance 🙈 The participant might not be told that its MSRP client will try to send messages with potentially multiple recipients to the MSRP switch. If the participant's MSRP client doesn't support this spec's extensions, it's unlikely to send a message using the Message/CPIM wrapper content type [RFC3862], and the MSRP switch will reject the request with a 415 response [RFC4975]. Still, if a participant's MSRP client does create a message with a valid Message/CPIM wrapper content type [RFC3862] where the To header is the URI of the chat room and the From header is the URI of the participant as known to the chat room, the participant might not realise the message can get forwarded to multiple recipients 👀 Equally, if the To header is set to a valid URI of a recipient known to the chat room, the message can be forwarded as a private message without the participant knowing 😬
To fix these problems, when the chat room detects a UA that doesn't support this doc's procedures (aka the SIP UA is not chat room aware), the MSRP switch SHOULD send a regular MSRP message. That message says the SIP UA is actually part of a chat room and that all correctly formatted messages it sends will be distributed to a number of participants 📣 The MSRP switch SHOULD also send a regular MSRP text message with the list of chat room participants, so the user knows who's in the roster 📋
If a participant wants to dodge security concerns on the path between themself and the MSRP switch (e.g., eavesdropping, faked packet injection, or packet corruption) 😱, the participant's UA can force MSRP over a TLS [RFC5246] transport connection. This is negotiated in the SDP offer/answer exchange as per the regular procedures of RFC 4975 [RFC4975]. That negotiation leads both endpoints to set up a TLS [RFC5246] transport connection, and that's what they use to swap MSRP messages 🔒 The MSRP switch may also have local policy forcing TLS transport for all MSRP sessions, which is also negotiated in SDP per the regular procedures of RFC 4975 [RFC4975] 💜
Nicknames are how participants show up to each other in the chat room 🎀 A successful takeover of a nickname could send private messages to the wrong destination 😭 The recipient's URI would be different from the URI tied to the original nickname owner, but the sender might not notice 👻 To avoid takeovers, the MSRP switch MUST make sure a nickname is unique inside a chat room. Also, the security considerations for any authenticated identity mechanisms used to validate the SIP AOR apply to this doc too 🔑 The chat room has a policy for how long a nickname stays reserved for its holder once it's no longer in use 🕰️ That's useful if, e.g., a user accidentally loses connectivity and wants to reconnect and keep using the same nickname 🔌 Whether a nickname that was previously used by another participant can be reserved is up to the chat room's policy 🤔
Section 7.1 talks about nicknames that look similar but aren't the same (e.g., thanks to similar-looking characters) 👯 Chat rooms MAY provide a mechanism to mitigate confusable nicknames ✨
Recipients of IMs should be cautious about rendering content, because it can be malicious in nature 🚩 This includes, but isn't limited to, HTML and JavaScript scripts, executable code, phishing attempts, and so on. Endpoints SHOULD always request permission from the user before executing any of these actions 🛑
Endpoints using a TLS client side certificate with real names in the certificates won't be anonymous to the MSRP switch they connect to 🫣 The name in the certificate might not be used by MSRP, but the server will still have a certificate with the actual name in it.
12. References 📚
12.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>.
[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>.
[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>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323,
DOI 10.17487/RFC3323, November 2002,
<http://www.rfc-editor.org/info/rfc3323>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004,
<http://www.rfc-editor.org/info/rfc3860>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862,
DOI 10.17487/RFC3862, August 2004,
<http://www.rfc-editor.org/info/rfc3862>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
DOI 10.17487/RFC4353, February 2006,
<http://www.rfc-editor.org/info/rfc4353>.
[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>.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
Session Initiation Protocol (SIP) Event Package for
Conference State", RFC 4575, DOI 10.17487/RFC4575, August
2006, <http://www.rfc-editor.org/info/rfc4575>.
[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>.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239,
June 2008, <http://www.rfc-editor.org/info/rfc5239>.
[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>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized
Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501,
March 2012, <http://www.rfc-editor.org/info/rfc6501>.
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", RFC 6502,
DOI 10.17487/RFC6502, March 2012,
<http://www.rfc-editor.org/info/rfc6502>.
[RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison
of Internationalized Strings Representing Nicknames",
RFC 7700, DOI 10.17487/RFC7700, December 2015,
<http://www.rfc-editor.org/info/rfc7700>.12.2. Informative References
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
DOI 10.17487/RFC2810, April 2000,
<http://www.rfc-editor.org/info/rfc2810>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<http://www.rfc-editor.org/info/rfc3325>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <http://www.rfc-editor.org/info/rfc6120>.Acknowledgments 🙏
The authors want to give a huge thank-you to Eva Leppanen, Adamu Haruna, Adam Roach, Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian Georgescu, Nancy Greene, Cullen Jennings, Flemming Andreasen, Suresh Krishnan, Christer Holmberg, Saul Ibarra, Enrico Marocco, Alexey Melnikov, Peter Saint-Andre, Stephen Farrell, and Martin Stiemerling for providing comments 🫶💖
Contributors 🌈
This work would have never been possible without the fruitful discussions on the SIMPLE WG mailing list, especially with Brian Rosen (Neustar) and Paul Kyzivat (Huawei), who provided extensive review and improvements throughout the document 👑✨
Authors' Addresses 💌
Okay bestie, the final squad goals moment: here's who wrote this and how to reach them 🫶
Aki Niemi
Email: aki.niemi@iki.fi
Miguel A. Garcia-Martin
Ericsson
Calle Via de los Poblados 13
Madrid, ES 28033
Spain
Email: miguel.a.garcia@ericsson.com
Geir A. Sandbakken
Cisco Systems
Philip Pedersensvei 1
1366 Lysaker
Norway
Email: geirsand@cisco.com📦 where this page comes from
- ietf: rfc7701 2015-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms