Message Session Relay Protocol

The Oracle Communications Session Border Controller supports Message Relay Protocol (MSRP) sessions initiated by Session Description Protocol (SDP) messages exchanged via the Session Initiation Protocol (SIP) offer/answer model. MSRP usage with SDP and SIP is described in Section 8 of RFC 4975, The Message Relay Protocol. The Oracle Communications Session Border Controller functions as a Back-to-Back User Agent (B2BUA) for MSRP sessions, terminating incoming MSRP, proxying for the MSRP session originator, initiating outgoing MSRP to the endpoint peer, and providing Network Address Translation (NAT) services.

MSRP Platform Support

The following platforms support Message Session Relay Protocol (MSRP):

OVM, KVM, VMWare
Acme Packet 4600
Acme Packet 6100
Acme Packet 6300
Acme Packet 6350

The Oracle Communications Session Border Controller supports MSRP over IPv6 and IPv4-IPv6 Inter-working function for MSRP.

MSRP IP Address Family Support

The Oracle Communications Session Border Controller supports MSRP over IPv4 and IPv6. The Oracle Communications Session Border Controller also can perform IPv4-to-IPv6 and IPv6-to-IPv4 interworking. This support is available automatically and does not require any configuration.

MSRP Operational Description

A sample RFC 4975-compliant Offer/Answer SDP exchange for an MSRP session is shown below.

           Alice                     Bob
             |                        |
             |(1) (SIP) INVITE        | The first three messages
             |----------------------->| use a SIP offer/answer
             |(2) (SIP) 200 OK        | model with accompanying
             |<-----------------------| SDP to negotiate an MSRP
             |(3) (SIP) ACK           | session
             |----------------------->|
             |(4) (MSRP) SEND         | Message 4 starts the MSRP
             |----------------------->| connection
             |(5) (MSRP) 200 OK       |
             |<-----------------------|
             |(6) (SIP) BYE           |
             |----------------------->| Message 7 terminates the
             |(7) (SIP) 200 OK        | SIP and MSRP connection
             |<-----------------------|

Alice sends an INVITE request with accompanying SDP to Bob.
The SDP media (M) line is defined in RFC 4975, and adheres to the format

m=<media> <port> <protocol> <format-list>
MSRP operations require the following values:
- media—message
- protocol—TCP/MSRP (for an unencrypted 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
The required SDP attributes, accept-types and path, are also defined in RFC 4975.

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.
path contains the MSRP URI of the message originator. An MSRP URI is constructed as shown below.
1. scheme
  - msrp (for an unencrypted connection), or
  - msrps (for an encrypted connection)
2. //
3. address
  - IP address of the message originator, or
  - FQDN of the message originator
4. ;
5. port
  - the port (7777 in the SDP example, although any valid port number can be specified) monitored by the message originator for MSRP responses
6. 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
7. ;
8. protocol
  - tcp
```
Alice->Bob (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
```
Bob accepts the SDP offer, generates a local session-id (contained in his MSRP URI specified by the path attribute), and issues a 200 OK response to Alice.
The port parameter in the Media line indicates that Bob listens for MSRP messages on TCP port 8888
```
Bob->Alice (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
```
Alice ACKs Bob’s answer, establishing a SIP session between the two.
```
Alice->Bob (SIP):

ACK sip:bob@example.com
```
Alice initiates an MSRP session with an MSRP SEND request to Bob.
All MSRP requests begin with the MSRP start line, which contains 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, which contain destination and source addresses — the MSRP URIs exchanged during the MSRP negotiation.

The Message-ID 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).

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 has been fragmented.

The Content-Type header describes the message type, and must conform to the results of the MSRP negotiation.

The actual message follows the Content-Type header.

Finally, the SEND request is closed with an end-line of seven hyphens, the transaction-id, and a

$ to indicate that this request contains the end of a complete message, or

+ to indicate that this request does not contain the message end
```
Alice->Bob (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$
```

Bob acknowledges receipt with an MSRP 200 OK response to Alice.

Note that the response includes the initiator-originated transaction-id, d93kswow.

Bob->Alice (MSRP):

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

Alice sends a BYE request to Bob.
Alice sends a BYE request to terminate the SIP session and MSRP sessions. Alice can, of course, send more SEND requests to Bob before sending the BYE.
```
Alice->Bob (SIP):

BYE sip:bob@example.com
```
Bob sends a 200 OK response to Alice.
```
Bob->Alice (SIP):

SIP/2.0 200 OK
```
The SIP session and the MSRP session are terminated.

Secure MSRP Session Negotiation

An Offer/Answer SDP exchange for a TLS (secure) MSRP session is specified in RFC 4572, Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP). RFC 4572 defines the syntax and symantics for an SDP fingerprint attribute that identifies the certificate (most likely a self-signed certificate) that will be presented during the TLS negotiation. A sample SDP exchange is shown below.

The protocol field (TCP/TLS/MSRP) of the media (M) line designates a TLS encrypted connection.

The fingerprint attribute is constructed as follows:

protocol—identifies the hashing method used to produce the certificate fingerprint, SHA-1 in the following sample SDP
hash value—a sequence of uppercase hexadecimal bytes separated by colons with the sequence length determined by the hash function

Offer SDP: (Alice to Bob)

v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= 
c=IN IP4 1.1.1.1
m=message 7394 TCP/TLS/MSRP *
a=accept-types:text/plain
a=path:msrps://alice.example.com:7394/2s93i9ek2a;tcp
a=fingerprint:SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

Answer SDP: (Bob to Alice)

v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= -
c=IN IP4 2.2.2.2
t=0 0
m=message 8493 TCP/TLS/MSRP *
a=accept-types:text/plain
a=path:msrps://bob.example.com:8493/si438dsaodes;tcp
a=fingerprint:SHA-1
DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09

MSRP Session Setup

The B2BUA processes MSRP media descriptions in offer/answer SDPs to negotiate and establish MSRP sessions and then constructs internal data flows for the actual MSRP sessions. After establishing an MSRP session, the B2BUA forwards MSRP requests and responses from and to the session participants.

Initiating MSRP Sessions

After accepting an offer SDP with MSRP session initiation, the B2BUA constructs an egress offer SDP as follows.

The B2BUA sets the transport protocol of the m= line to the transport protocol of the selected egress profile.
If the value of listen-port of the selected egress profile is not zero, the B2BUA sets the port of the m= line to the value of listen-port. If the value of listen-port is zero, the port in the m= line is chosen from a steering port of the egress realm.
The B2BUA adds an a=setup attribute to the SDP. The value of this attribute is determined by the value of the preferred-setup-role ACLI command. For example, if the value of preferred-setup-role is passive (the default value) the B2BUA adds the attribute a=setup:passive.
The B2BUA performs NAT on the MSRP Universal Resource Identifier (URI) in the a=path attribute.

The B2BUA does not include an a=fingerprint in the offer SDP if the selected egress profile has TCP/TLS/MSRP transport protocol. However, if the egress profile specifies both TCP/MSRP and TCP/TLS/MSRP the B2BUA selects the TCP/TLS/MSRP transport protocol, resulting in an egress offer containing an m= line with TCP/TLS/MSRP transport protocol. The B2BUA offers only a single media line, TCP/MSRP or TCP/TLS/MSRP. The B2BUA does not perform recursion (that is, first initiation attempt with TCP/TLS/MSRP and re-attempt with TCP/MSRP if first attempt is rejected).

Connection Negotiation

When making the offer MSRP session, a user agent client can follow RFC 4145, TCP-Based Media Transport in the Session Description Protocol (SDP), and include an a=setup attribute in a MSRP media line, or it may assume the default connection direction as specified in section 8.5 of RFC 4975, The Message Session Relay Protocol, which specifies that the endpoint that sent the original offer is responsible for connecting to its remote peer. The B2BUA, in contrast, always includes an a=setup attribute in its offer SDP, the attribute value set by the preferred-setup-role ACLI command.

If the B2BUA receives an answer SDP that does not include an a=setup attribute, it assumes that the user agent server does not support connection negotiation per RFC 4145. In that case, the B2BUA assumes the active role as specified in RFC 4975, and makes an outgoing connection.

If the B2BUA receives an offer or answer SDP that does include an a=setup attribute, it follows the connection negotiation as specified by RFC 4145. When the B2BUA receives an offer SDP with the attribute a=setup:actpass attribute, it will set the a=setup attribute of the answer SDP to the value set by the preferred-setup-role ACLI command.

Multiple MSRP Connections

The MSRP B2BUA supports sharing of a single TCP connection by multiple MSRP sessions. In such a topology, each TCP connection maintains a list active MSRP sessions.

With regard to the above figure, the upper Oracle Communications Session Border Controller’s TCP connection between Endpoint 1 and the MSRS B2BUA is shared by 2 MSRP sessions. At bottom, each MSRP session uses a separate TCP connection. When the B2BUA assumes the active role, it always initiate a separate connection to the MSRP endpoint peers, endpoints 2 and 3 as shown above.

When the list of active MSRP sessions for a shared TCP connection becomes empty as a result of SIP session terminations or disconnections of peer TCP connections, B2BUA disconnects the shared TCP connection. If the shared connection is disconnected by the peer, the B2BUA disconnects all the separate TCP connections it initiated for the MSRP sessions that use the shared connection.

Accepting Connections

When the B2BUA is in passive mode, it listens for incoming connection from the active party, monitoring the port specified by the listen-port ACLI command.

Making Connections

When the B2BUA is in active mode, it makes the connection to the passive party, selecting a port allocated from the steering-pool of the applicable realm.

MSRP Session Termination

An MSRP session is terminated by sending or receiving a BYE request in the parent SIP session, that is the session that set up the MSRP exchange, followed by the disconnect of the TCP connection that supports MSRP message exchange.

Some SIP endpoints close their MSRP TCP connections upon receiving a BYE possibly before its peer finishes sending all the MSRP messages and closes the connection. To facilitate graceful session completion, the B2BUA offers a configurable time delay between the receipt of a BYE request from an MSRP endpoint and the transmission of the BYE to the recipient endpoint peer.

With the configurable BYE delay enabled, the MSRP B2BUA upon receiving a BYE request acknowledges the request with a 200 OK response. The B2BUA, however, does not immediately forward the BYE to the other MSRP endpoint.

Rather, the B2BUA triggers two user-configurable timers that monitor the specific MSRP session initiated by the current SIP exchange. The first timer measures inactivity intervals on media flows (calling-to-called and called-to-calling) associated with the MSRP session to be closed. The second timer sets an unconditional outer limit at which point the delayed BYE is transmitted to the MSRP endpoint and the MSRP is terminated.

Expiration of either timer generates an internal stop event which generates transmission of the delayed BYE to the MSRP endpoint and tem ina ti on of the underlying SIP connection.

Note that the MSRP-specific timers, the session inactivity timer and the  MSRP delayed-BYE timer, are roughly analogous to two existing TCP timers, the TCP subsequent guard timer and the TCP flow time limit timer. The following sections summarize timer operations.

MSRP interval timer

Purpose: Measures inactivity periods within MSRP data sessions. The timer is triggered in the absence of MSRP data. If new MSRP is not detected prior to timer expiration, a stop event is generated resulting in delayed BYE transmission and MSRP connection termination. If new MSRP traffic is detected prior to timer expiration, the timer is reset.
Associated ACLI Command: session-inactivity-timer
Allowable command values: 0 | 5 to 10 (seconds). When set to 0, session monitoring is disabled. No MSRP session monitoring is done when the corresponding SIP session receives a BYE request.
Default value: 5
Timer Expiration: Initiates forwarding of the delayed BYE request to the recipient MSRP endpoint and tear down of the SIP connection.

TCP subsequent guard timer

Purpose: Measures the maximum interval allowed between media-over-TCP packets.
Associated ACLI Command: tcp-subsq-guard-timer
Allowable command values: 0 to 999999999 (seconds)
Default value: 300
Timer Expiration: Initiates tear down of the TCP connection. In the possible, but unlikely event that the value assigned to this timer is less than the value assigned to the MSRP interval timer, expiration initiates forwarding of the delayed BYE request to the recipient MSRP endpoint and tear down of the TCP connection.

MSRP delayed -BYE timer

Purpose: Measures inactivity periods within MSRP traffic sessions. The timer is triggered in the absence of MSRP data. If new MSRP is not detected prior to timer expiration, a stop event is generated resulting in delayed BYE transmission and MSRP connection termination. If new MSRP traffic is detected prior to timer expiration, the timer is reset.
Associated ACLI Command: msrp-delayed-bye-timer
Allowable command values: 0 to 60 (seconds)
Default value: 15
Timer Expiration: Initiates forwarding of the delayed BYE request to the recipient MSRP endpoint and tear down of the SIP connection.

TCP flow time limit timer

Purpose: Measures the maximum allowed lifetime of a media-over-TCP connection.
Associated ACLI Command: tcp-flow-limit-timer
Allowable command values: 0 to 999999999 (seconds)
Default value: 86400 (1 day)
Timer Expiration: Initiates tear down of the TCP connection. In the possible, but unlikely event that the value assigned to this timer is less than the value assigned to the MSRP delayed-BYE timer, expiration initiates forwarding of the delayed BYE request to the recipient MSRP endpoint and tear down of the TCP connection.

Network Address Translation

If the value of the uri-translation ACLI command is enabled, the B2BUA performs network address translation on the MSRP URI in the a=path attribute and in the From-Path and To-Path of MSRP requests and response. The host part of the URI will be the IP address of the steering pool of the realm. The port will be chosen as follows:

If the B2BUA role is in passive mode, and the listen-port ACLI command is non-zero, the B2BUA monitors that specified port.

If the B2BUA role is in passive mode, and the listen-port ACLI command is zero, the B2BUA selects a port from the steering pool of the applicable realm and monitors that chosen port.

If the B2BUA role is in active mode, the port is chosen from the steering pool of the applicable realm. Since B2BUA is active, that port is used only to support the outgoing connection.

Certificate Fingerprint

If the value of the field require-fingerprint in the ingress and/or egress tcp-media-profile is enabled, and the transport protocol is TCP/TLS/MSRP the B2BUA requires the offer and/or the answer SDPs, respectively, to have an a=fingerprint attribute as specified in RFC 4572, Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP).

If the B2BUA receives an offer SDP without a=fingerprint attribute, it rejects the offer SDP. If the rejected SDP is in an INVITE request, the B2BUA issues a 488 Not Acceptable Here response. If the rejected SDP is in a 200 OK response, the B2BUA ACKs that 200 OK, sends a BYE to the server user agent, and a 503 Service Unavailable response to the client user agent.

If the B2BUA receives an answer SDP without a a=fingerprint attribute, it terminates the related SIP session. If the rejected SDP is in a 200 OK response, the B2BUA ACKs that 200 OK, sends a BYE to the server user agent, and a 503 Service Unavailable response to the client user agent. If the rejected SDP is in an ACK, the B2BUA simply sends a BYE to both the server and client user agent.

If the value of the field require-fingerprint in the profile is disabled, the B2BUA accepts offer and answer SDP that do not include an a=fingerprint attribute.

Because the B2BUA certificate is expected to be signed by a trusted Certification Authority, an a=fingerprint attribute is not included in offer and answer SDPs sent by the B2BUA.

The B2BUA maintains a fingerprint mismatch counter for each MSRP session. This counter is incremented when the B2BUA cannot match the certificate it receives during the TLS handshake with the fingerprint it receives in the SDP.