SIP Sessions

MSRP SDP Extensions with Relays

My last SIP Sessions post discussed the SDP offer/answer extensions used by MSRP in the peer-to-peer scenario. Today, we will look at how this changes when you introduce MSRP Relays into the mix.

RFC 4976 defines the MSRP relay extension. There's quite a bit to talk about with MSRP Relays. Today we're going to focus just on the parts that impact the offer/answer process. I'll cover more about relays in a future post.

An MSRP client that needs to use an MSRP relay must first authenticate to the relay and request an MSRP URI that represents the session at that relay. It does this using an MSRP extension method called "AUTH". We will dive into the gory details of AUTH after we discuss the general MSRP transaction model--also in future posts (Are you starting to see the pattern here?). But we need to understand it conceptually in order to explore how relays affect the offer/answer model.

The client sends the AUTH request to the relay over a TLS connection. The relay authenticates the client using a form of digest authentication much like that from HTTP and SIP. The client uses the TLS association to authenticate the relay.

Once the authentication completes the relay generates an MSRP URI that resolves to the relay itself. The relay puts this URI in a "Use-Path" header field in the 200 OK response that it sends back to the client in response to the AUTH request. The client then uses the relay's URI in the session negotiation.

This is conceptually similar to how some other relay-based NAT traversal mechanisms work. For example. SOCKS and TURN each allow a client to request a relay device allocate a port on its behalf.

Once the client gets a "Use-Path" header value from the relay, it can then build the SDP path attribute by appending its local URI to the relay URI. For example, assume the client's URI is "msrps://client.example.com:2855/asfd34;tcp" and the relay returned a Use-Path value of "msrps://relay.example.com:7212/d3asdf43;tcp" The path attribute would now look like the following: 

a=path:msrps://relay.example.com:7212/d3asdf43;tcp msrps://client.example.com:2855/asfd34;tcp

You're probably wondering why "Use-Path" is not called "Use-URI". The reason for this is, just like the SDP path attribute, "Use-Path" can contain more than one URI. There are few cases where a relay might need to return more than one URI. (You guessed it--we'll talk about those in a future post.) But regardless of why it might happen, the relay-using client would build the SDP path header by taking the entire contents of "Use-Path", reversing it, then adding its own URI to the end. Thus, the SDP path attribute becomes an assertion to "to get to me, follow this path from left to right. My local URI is on the end."

Let's look at a more complete example from RFC 4976. Alice invites Bob to an MSRP session. Alice does not use a relay, but Bob does. Alice's offer looks something like the following:

v=0

o=alice 2890844526 2890844526 IN IP4 alice.example.com

s= 

c=IN IP4 alice.example.com

t=0 0
m=message 7654 TLS/TCP/MSRP *
a=accept-types:text/plain
a=path:msrps://alice.example.com:7654/asfd34;tcp

When Bob sees the offer, he connects to his relay (relay.example.net), and performs an AUTH transaction. He gets back a 200 OK response containing, among other things, the following:

 Use-Path: msrps://relay.example.net:8211/asfioef;tcp

Bob's SDP answer then looks something like this:

v=0

o=bob 2890844542 2890844542 IN IP4 bob.example.net

s= 

c=IN IP4 bob.example.net

t=0 0
m=message 6581 TLS/TCP/MSRP *
a=accept-types:text/plain
a=path:msrps://relay.example.net:8211/asfioef;tcp msrps://bob.example.net:6581/asfd34;tcp

Note that in this case, Alice's client does not have to implement RFC 4976 at all. It won't know how to use the AUTH method, but even basic RFC 4975 clients can still talk to relay-using peers.

That's enough for now. Next time, we will talk about how these SDP path attributes get used inside MSRP proper.