MSRP Relay deployment scenarios

This document describes several use case scenarios of how MSRP relay functionality may be deployed in the field. The implementation that is under development should eventually be able to support each of these scenarios. For each of these scenarios there are diagrams indicating the flow of traffic between the different components. All diagrams on this page are also downloadable as PDF.

The image above is a time-sequence diagram that describes the typical flow of messages when using a MSRP relay, including both SIP and MSRP traffic.

The example described is a MSRP session between two endpoints that are behind NAT, each using its own SIP proxy and MSRP relay. When the endpoints are switched on they will each register with their SIP proxy so that the proxies know where the endpoint can be reached and NAT can be traversed. When endpoint A wishes to start a MSRP conversation with endpoint B, it will first authenticate itself at MSRP relay A, which will give the endpoint a new session identifier included in a MSRP URI. Note that endpoint A does not strictly need to use its MSRP relay in order to traverse NAT, as it will be the one initiating the MSRP TCP connection, but it may choose to do so for other reasons. Once the endpoint has obtained the session identifier, it will include the URI of MSRP relay A in the MSRP SDP description of the initial SIP INVITE message, which it will send through its SIP proxy. This starts the regular SIP invite handshake, which will eventually reach endpoint B. Before accepting the session, endpoint B needs to obtain a session identifier from its own MSRP relay B, which it does by authenticating itself with the AUTH method. It the includes the returned MSRP URI in the SIP OK response, so that endpoint A knows which path the MSRP messages need to follow. It can then send MSRP messages through the SEND method and by including this path in the To-Path header. Messages from endpoint B to endpoint A will use the reverse path. In this example endpoint B closes the MSRP session by sending a SIP BYE message.

Relaying between MSRP UAs behind NAT

This the simplest scenario and the one that is described in the MSRP relay specification. One UA will propose a MSRP session to another UA over SIP, probably through one or more SIP proxys. Prior to this each UA will have authorized itself at its local MSRP relay. In the SDP exchange over SIP both UAs will reference their MSRP relay. The MSRP session will then take place through the relays in order to traverse the NAT on either end. Note that the UA that sent the original SIP INVITE is not strictly required to us its MSRP relay for this session, as it will be the endpoint that creates the TCP connection to the other endpoint, or in this case the MSRP relay of the other endpoint, which will work through its own NAT.

The diagram for this scenario describes the flow of SIP and MSRP traffic between the different components described. Client A wishes to have a MSRP session with Client B and sends it an INVITE message over SIP, describing in the SDP contained in this INVITE that the desired medium is MSRP, possibly along with other media. Also contained within the SDP is the MSRP path to Client A, which consists of the MSRP URI of this endpoint and the URI of the MSRP relay used by Client A. If Client B wishes to accept the session, it will reply with a SIP response message with a code if 200 and SDP containing the MSRP path to itself, i.e. its own MSRP URI and that of its relay. Once Client A receives this OK response it will send a SIP ACK and start a MSRP session to Client B, through both proxys. It then starts the conversation with Client B by sending the first message.

Relaying to a XMPP gateway

Since in XMPP media and signalling are not separated, as they are when using SIP and MSRP, a MSRP to XMPP gateway would be logically located within the SIP proxy. To a MSRP relay the SIP proxy would be the MSRP endpoint, so from the point of view of the MSRP relay this scenario is not different from communicating between two actual endpoints.

IM communication between a MSRP and a XMPP client is show in the diagram. Both SIP and MSRP traffic are terminated at the SIP proxy which serves as XMPP gateway and communicates with the XMPP server. In order to traverse the NAT on the side of the MSRP client, the MRSP relay is used to relay traffic between the MSRP client and the SIP proxy acting as XMPP gateway.

Relaying in conjunction with a MSRP switch

draft-ietf-simple-chat-00.txt specifies the use of MSRP switches for multi-party chat sessions. From the prespective of a MSRP relay, traffic between a MSRP relay and an endpoint behaves the same as traffic between two MSRP endpoints, so no special operation for using MSRP switches is required. In those scenarios that would normally require use of a MSRP relay between two endpoints, a relay will also be needed during a session between an endpoint and a MSRP switch. That means that if the party that receives the original SIP invite is behind NAT, it should use a MSRP relay.

The diagram shows the flow of both SIP and MSRP traffic in a switched chat session with two endpoints. Typically a multi party chat session will include more endpoints, however they are not shown due to space requirements. The MSRP switch is an endpoint for both the signaling (SIP) and media (MSRP) flows and needs to be aware of both.

Relaying integrated in a P2P scenario

Eventually the MSRP relay functionality could be implemented in each peer, allowing endpoints that are not behind NAT to perform relaying for those that are, based on some trust or trading relationship. This deployments fits within a P2P SIP scenario.

The diagram depicts traffic flows for an example of this scenario, where two endpoints that are both behind NAT, clients A and B, are communicating in a MSRP session. MSRP traffic is relayed by MSRP client C, which is not behind NAT, so can be reached from both clients A and B. The negotiation about this relaying is not shown in the diagram. Note that SIP traffic will need some proxy entity as well, although because this diagram deals with MSRP, it is not clearly defined.