You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

MSRP session setup is the same as an audio or video session as depicted in the example call flow below.

MSRP Call Flow Example

Upon a successful establishment of the SIP session, the MSRP TCP connections are established using the TCP IP and Port that was negotiated in the SDP thereby enabling the MSRP payload to be exchanged over the connection. This is based on RFC 4975 where the EP1 is always assumed to the TCP client and EP2 is the TCP server. In other words, the TCP connection will always be initiated from EP1 or the MSRP session “offerer “.

Referencing the above example, the call flow proceeds as follows.

 

Step 1: EP1 sends INVITE that contains MSRP SDP EP2:

EP1 -> EP2(SIP):
INVITE sip:bob@example.com
 
SDP:
v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
m=message 7777 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp 
MSRP SDP definitions:

m=<media> <port> <protocol> <format-list>

media = message

protocol   =  TCP/MSRP (for an unencrypted connection) or TLS/TCP/MSRP (for an encrypted connection)   

format-list =*

port =  The TCP port (7777 in the SDP example, although any valid port number can be specified) monitored by the message originator for a response to the SDP offer

accept-types contains a list of media types that the message originator is willing to receive. It may contain zero or more registered media-types, or an * wildcard character in a space-delimited string.

a=path contains the MSRP URI of the message originator. An MSRP URI is constructed as shown below.

     scheme  = msrp (for an unencrypted connection) or msrps (for an encrypted connection)

     address  = IP address of the MSRP message originator, or FQDN of the MSRP message originator  

     port = (7777 in the SDP example although any valid port number can be specified) Port used by the message originator for MSRP responses.

     session-id = a random local value generated by the message originator used to produce an ephemeral MSRP URI lasting only for the duration of the current MSRP session

     protocol = tcp

Step 2: EP2 sends SIP 200 OK to EP1 with SDP consisting of EP2 MSRP attributes. EP2 generates its own local session id in the path URI. EP2 includes its local port number on which it’s listening to TCP connections in the m line.

EP2->EP1 (SIP):
SIP/2.0 200 OK
 
SDP:
v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com
s=
c=IN IP4 bob.example.com
m=message 8888 TCP/MSRP *
a=accept-types:text/plain 
a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp 

 

Step 3: EP1 sends ACK to acknowledge the receipt of the final answer from EP2 and a SIP session is established.

Both the MSRP UA are following the SIP offer answer model by including the MSRP session attributes and transport parameters in the SDP. Once the UAs have negotiated the SDPs and the SIP session is established, EP1 shall initiate a TCP connection towards EP2 thereby establishing a TCP connection between the UAs. 

Step 4: EP1 initiates a MSRP message towards EP2 as follows

EP1->EP2 (MSRP):
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer Byte-Range: 1-16/16
Content-Type: text/plain
Hi, I'm Alice! -------d93kswow$

 

All MSRP requests begin with the MSRP start line containing three elements.

  • protocol-id = MSRP
  • transaction-id = an ephemeral transaction identifier (d93kswow in the following MSRP example) used to correlate MSRP requests and responses, and to frame the contents of the MSRP message
  • method = SEND (MSRP method that supports data transfer)

The MSRP start line is followed by the To-Path and From-Path headers containing destination and source addresses (the MSRP URIs exchanged during the MSRP negotiation).

  • Message-ID: The header contains a random string generated by the message originator. This ephemeral value whose lifetime is measured from message start to message end, is used to correlate MSRP status reports with a specific message, and to re-assemble MSRP message fragments (chunks in MSRP terminology).
  • Byte-Range: The Byte-Range header contains the message length, in bytes, and the specific byte range carried by this message. Contents of this header are generally of interest only if the message is fragmented.
  • Content-Type: The Content-Type header describes the message type, and must conform to the results of the MSRP negotiation.

The MSRP payload or content (i.e the instant message) follows the Content-Type header. Finally, the SEND request is closed with an end-line of seven hyphens, the transaction-id, and the "$" symbol to indicate that this request contains the end of a complete message, or a "+" symbol to indicate that this request does not contain the message end.

Step 5: EP2 sends an MSRP response as follows. The transaction id in the first line matches the initiator originated transaction-id.

MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
-------d93kswow$

 

Step 6 and 7: MSRP message exchange on the reverse direction.

Step 8: EP1 terminates the SIP and MSRP session by sending a BYE.

Step 9: EP2 acknowledges the BYE request with a 200 OK. Both SIP and MSRP sessions are terminated.                                                                   

  • No labels