Message Session Relay Protocol

MSRP Platform Support

All platforms except the Acme Packet 1100 support Message Session Relay Protocol (MSRP).

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

MSRP IP Address Family Support

The Oracle® Enterprise Session Border Controller supports MSRP over IPv4 and IPv6. The Oracle® Enterprise 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

In compliance with RFC4145 and RFC6135, the ESBC can act as offerer or answerer when using SDP to negotiate MSRP sessions. As answerer, the ESBC receives MSRP signaling from a UA that wants to start an MSRP session. As offerer, it acts as an MSRP B2BUA and starts an MSRP session. Within a connection-oriented media architecture, SDP negotiates these roles from the a=setup parameter, which determines which end station is responsible for initiating the session as active, and which is passive.

As an MSRP session offerer, a user agent client can follow RFC 4145 and include an a=setup attribute in a MSRP media line, or it may follow the default connection direction specified in RFC 4975, 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 SDP offer. You can configure this setup value on the ESBC by configuring the preferred-setup-role parameter within the tcp-media-profile, profile-list element. Parameter values include:

active—The ESBC explicitly requests the active role.
passive—The ESBC sends actpass to the UA as its setup role. This allows the ESBC to be either active or passive, depending on the response from the UA. If the UA responds requesting active, the ESBC takes the passive role, and vice-versa. This actpass value ensures that the ESBC can either:
- Initiate an outgoing connection to a remote UA
- Accept an incoming connection from a remote UA
The absence or value of the “a=setup” attribute in the answer SDP received from the remote UA determines the actual role performed by the ESBC, as specified by RFC 4145.
- When the ESBC receives “a=setup:active”, it performs the passive role, listening on the advertised port.
- When the ESBC receives “a=setup:passive”, it performs the active role.
- When the ESBC receives an offer SDP with the attribute a=setup:actpass attribute, it sets the a=setup attribute of its SDP answer to the value set in the preferred-setup-role parameter.
- When the ESBC 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, takes the active role as specified in RFC 4975, and makes the outgoing connection.

The default and recommended preferred-setup-role configuration is passive, which allows the remote UA to choose its role.

Whether taking the active or passive role on the caller side (ingress), the ESBC initiates an outgoing connection towards the callee (egress) on-demand and its MSRP requests to the callee. Again, the ESBC as B2BUA sends its SDP offer with the setup line using its configured value.

Key behavior also includes:

When active, the ESBC refers to the applicable tcp-media-profile, profile-list to see if you have configured the listen-port. If you have configured a listen-port, the ESBC listens for traffic on that port. By default, the listen-port is set to 0, which causes the ESBC to listen using a port it allocates from the steering-pool of the applicable realm.
When it is the answerer, the ESBC is forced into a specific role and does not always use the configured preferred-setup-role value. The ESBC uses the actpass value to negotiate in scenarios where:
- The remote UA is negotiating the connection using the passive value or,
- When the remote UA is using passive improperly during the negotiation, which is prohibited by RFC 6135.
Sending “a=setup:actpass” value in an offer from the ESBC is also compliant if the remote UA does not support the COMEDIA mechanism described in RFC 4145, and is, therefore, always a passive endpoint. If the remote UA sends back an answer with SDP that indicates the role it is going to take, the ESBC takes the other role.
When configured to propose actpass, via the passive setting, it is possible that ESBC could end up performing the active role on both the ingress and egress sides of the session. In this case, there may not be any MSRP request received from the UA on one side of the ESBC to trigger the outgoing connection on the other side. It is, therefore, mandatory for the ESBC to establish a connection right after successful negotiation of offer/answer exchange and send an empty MSRP request on the established connection. This behavior is in compliance with RFC 4145.
The ESBC initiates the egress outbound TCP connection right after it receives the answer SDP from the ingress remote UA. The TCP initiation processing from the data path happens when the host sends a MSRP session provision message to the data path after receiving the answer SDP. From the call flow perspective, this outbound TCP initiation by the ESBC can happen before it sends any SIP ACK message.

ESBC as Answerer

The table below shows the values the ESBC inserts into its SDP setup attribute when it answers an offer from a remote UA.

Offer	Answer	Rationale
Active	Passive	The ESBC is forced into this role so it can comply with the section 4.1 of RFC 4145.
Passive	Active	The ESBC is forced into this role so it can comply with the section 4.1 of RFC 4145.
Actpass	Use configured value	The user configures the ESBC with an appropriate value according to the network requirement in which it is deployed.
No “a=setup” attribute	Passive	Since the remote UA does not support RFC 4145, per RFC 4975, the ESBC takes the passive role as the answerer.

ESBC as Offerer

The table below shows the values the ESBC inserts into its SDP setup attribute when it sends an offer to a remote UA. When initiating an SDP offer, the ESBC prefers to use the configured value of the preferred-setup-role parameter. As shown in the table, this is not always the case.

Configured Preferred-setup-role	Offer	Answer	Final role performed by the ESBC	Rationale
Active	Active	Passive	active	The ESBC uses the configured value in its offer SDP, per RFC 4145.
Passive	Actpass	Active/Passive	Opposite role of what comes in the answer SDP	RFC 6135 prohibits the use of “a=setup:passive”, So the ESBC offers “a=setup:actpass”. This allows the remote UA to choose the role. *
Active/Passive	Active/actpass	No “a=setup” attribute	active	The remote UA does not support RFC 4145. As offerer, the ESBC takes the active role, per RFC 4975.

* Note the second row. Even though you configured the preferred-setup-role to passive, the ESBC uses a=setup:actpass when it sends an offer to a remote UA. The remote UA may:

If compliant with RFC 6135, send an answer SDP with “a=setup:active” because the UA knows that it is located behind a NAT.
If the remote UA knows that it is not behind a NAT, it should send an a=setup:passive.

Reporting on MSRP Session Setup

Key reporting on MSRP setup signaling using the show msrp statistics command includes:

Total Requests Sent—When the ESBC successfully sends the MSRP SEND request, it increments the show msrp statistics counters.
Total message send failure—In case of failure to send out this message for any reasons, then ESBC increments this counter in CDR/ACR information. (The current implementation does not display this in the show msrp statistics command).

Also, the ESBC includes the transmitted bytes for this message and the MSRP SEND request count for the calling party in MSRP CDR and diameter ACR data.

When the ESBC issues an MSRP SEND message with no body. it includes all mandatory header fields, including the following header fields with specific values:

Success—Report header field with a value of “no”.
Failure—Report header field with a value of “no”.

This message prevents the receiving MSRP UA from sending any response to this request or REPORT request back to the ESBC.

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® Enterprise 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 termination 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.