(This is the first in a series of posts about MSRP, or the Message Session Relay Protocol.)
You’ve probably noticed several mentions of a messaging protocol known as MSRP in this blog. MSRP stands for the Message Session Relay Protocol (not manufacturer’s suggested retail price). MSRP was developed in the IETF by the SIMPLE working group. It’s documented in RFC 4975 and RFC 4976. The former describes the base protocol, and the latter describes the use of relays.
(Full Disclosure: I was the editor of RFC 4975. I am also a co-chair of SIMPLE–but not at the time the RFC was published.)
SIP also has a built in mechanism for sending instant messages: the MESSAGE method. With the MESSAGE method, the content of an instant message is carried as the payload in a SIP message. That is, message content is carried as part of the signaling path, much like with SMS. Also like SMS, the MESSAGE method provides a “pager” like user experience, where there’s no inherent connection between one message and another. Client devices may simulate conversation threads, but there’s no concept of conversations in the protocol itself. And even more like SMS, the MESSAGE method also has some pretty strict limitations on the size of the content in a single message.
MSRP is a fundamentally richer approach, and differs from the MESSAGE method in several ways. The biggest difference is that MSRP uses a media session that is separate from the SIP signaling, similarly to how RTP is used for audio, video, or other real-time media sessions. You use a SIP INVITE transaction, carrying an SDP Offer/Answer exchange to establish an MSRP session, and a SIP BYE request to terminate the session.
The explicit start and stop of an MSRP session makes it easier to provide “chat-room” style user experiences. A user enters a chat room with an INVITE request, and leaves it with a BYE. And the fact MSRP is treated much like any other media makes it easier to mix messaging sessions with other media streams. For example, you might have a video conference stream with an associated text conference stream. Floor control features could apply to both streams.
MSRP is inherently multi-media. It can carry any arbitrary type of content, and has no built-in size limitations. Even though it was originally designed with messaging in mind, it’s really a generic content transfer mechanism. For example, I’ve seen demonstrations of an MSRP-based mechanism for sending a photo to the person on the end of a pre-existing VoIP call.
MSRP clients can communicate directly, just like RTP clients. They can also use intermediaries called MSRP Relays. (Remember, that’s the “R” in MSRP.) The main point of MSRP relays is for firewall and NAT traversal. The relays can also be used for policy enforcement and for content-logging. MSRP allows devices to multiplex many MSRP sessions over a single TCP session, which allows a pair of adjacent relays between peering partners to minimize the number of TCP connections.
MSRP is a young protocol, as protocols go. It has not seen a lot of deployment yet–but that is starting to change. We’re starting to see some MSRP deployment by operators, along with some very innovative applications–one of which Adam Roach recently pointed out.
I’ve only scratched the surface of MSRP in this post. Next time, I’ll delve into how MSRP works with the SDP Offer/Answer model, and some SDP extensions that were required to make it work.
But before I sign off for today, I’ve got to get a rant in. (Surely the reader has come to expect a rant from me, yes?) Way back when we were putting the finishing touches on the MSRP RFCs, I was working in a shared office environment. The building had very thin walls (fortunately I’m in a much nicer space now). I overheard a rather loud person on the phone, talking about MSRP with quite a bit of energy. Wow, I thought–people were already using this! Only later did I realize he was talking about MSRP as the list price of something or another.
The moral of this story is, when you choose a name for a new protocol, go do a web search. If you find hundreds of unrelated hits, it’s a bad name choice. In the case of MSRP, I’m not to blame–I didn’t name it. But what can you expect from a work group named “SIMPLE”?
No related posts.