MSRP Support

The SBC Core uses SIP and the Message Session Relay Protocol (MSRP) defined in RFC 4975 to provide support for session-oriented instant messaging and file transfer applications. Similar to other types of media sessions, the participating peers negotiate the setup details of an MSRP session using the Session Description Protocol (SDP) offer/answer model. When the SBC is anchoring media, the SBC establishes MSRP sessions over TCP connections between the SBC and each of the participating peers. If it is configured for direct media, the SBC also supports direct media flows for MSRP sessions. The SBC can establish MSRP sessions in isolation or along with voice or video sessions. 

All SBC platforms support MSRP, including distributed SBC (D-SBC) deployments. In a D-SBC deployment, the signaling packets flow through the signaling SBC (S-SBC), and the MSRP media packets flow through the media SBC (M-SBC). Together, the S-SBC and M-SBC(s) flows provide the same type of MSRP support as other SBC platforms.

MSRP support is a key component of the SBC support for Rich Communication Services (RCS), an industry initiative to define a set of features and specifications providing advanced messaging communications. RCS specifications are widely supported across carriers, devices, and platforms. Refer to Rich Communication Suite Support for more information on SBC support of RCS.

In setting up MSRP sessions, the SBC supports both RFC 6714 “Connection Establishment for Media Anchoring” (CEMA) and the back-to-back user agent (B2BUA) behavior typical of the SBC. The SBC determines the type of handling based on whether the participating endpoints assert support for CEMA by including the “msrp-cema” attribute in their SDP messages.  The following sections describe each of these MSRP session scenarios in greater detail. For information on MSRP-related configuration, refer to Configuring MSRP Support.

MSRP-CEMA Processing

When an incoming INVITE request for an MSRP session contains the attribute 'msrp-cema' in the SDP offer, the SBC treats the request as an MSRP-CEMA call request. In this scenario, the SBC forwards the INVITE request to the egress peer, including the 'msrp-cema' attribute in the egress SDP offer. If the egress peer includes the 'msrp-cema' attribute in its SDP answer, the SBC proceeds with setting up an MSRP-CEMA call because both participants have indicated CEMA support. The SBC updates the address information in the SDP c- and m-lines with the appropriate SBC media interface IP and port values to enable establishing two TCP connections, one with the ingress peer and another with the egress peer. The SBC completes the call setup by establishing MSRP-CEMA sessions with each of the peers over the established TCP connections.

During the MSRP-CEMA setup sequence the SBC does not modify the 'path' attribute; it relays the path lines unchanged between the ingress and egress peers. Thus, the SBC does not provide topology hiding for MSRP-CEMA sessions. The SBC simply relays the MSRP messages; it does not modify them. 

The SBC does not support reuse of TCP connections (MSRP multiplexing) for MSRP-CEMA sessions. 

MSRP-B2BUA Processing

When an incoming INVITE request for an MSRP session does not contain the attribute 'msrp-cema' in the SDP offer, the SBC does not insert one in the outgoing request. The SBC instead attempts to set up an MSRP-B2BUA session between the peers. In this scenario, the SBC inserts its egress media interface IP/port and session id (generated by SBC) in the MSRP URI of the SDP 'path' attribute in the egress offer. Similarly, before forwarding the INVITE response to the ingress side, the SBC inserts its ingress media interface IP/port and session id (generated by SBC) in the MSRP URI of the SDP 'path' attribute. Thus in the MSRP-B2BUA case, the SBC provides topology hiding between the peers.

In the subsequent MSRP messages, the SBC continues to update the MSRP-URI in the To-Path and From-Path headers. The SBC relays all other fields in the MSRP messages as is.

The SBC Core supports a 240 kB payload size for the Message Session Relay Protocol (MSRP) back-to-back user agent (B2BUA). The SBC Core rejects any payload size for the MSRP B2BUA that is equal to or greater than 256 kB.

Establishing TCP Connections

Folowing the role negotiation process outlined in RFC 4145, the SBC always sends "a=setup:actpass" to the egress peer in an INVITE request, meaning based on the response from the egress peer, the SBC can take either the active or passive role in setting up the TCP connection. Similarly, if the initial offer from the ingress peer is specifically "a=setup:active" or "a=setup:passive," the SBC takes the opposite role in response. If the ingress peer sends "a=setup:actpass," the SBC takes the passive role.

Once the SDP negotiation is complete, if the SBC has the active role, it initiates a dummy MSRP SEND message to the peer so the peer can bind the new MSRP session to the TCP connection. For cases when the SBC has the passive role, it listens on its MSRP server port and binds to the TCP session when it receives the first MSRP SEND message from the peer.

TCP Connection Reuse - MSRP Multiplexing

If an additional MSRP-B2BUA session is requested with an IP peer with which a TCP connection already exists, the SBC can be configured at the trunk group level to reuse the existing connection for the new session. This is referred to as MSRP multiplexing and it enables conserving resources and greater scale. When MSRP multiplexing is in effect and the SBC initiates an MSRP session toward an egress peer, the SBC checks the IP and port in the SDP answer from the peer to determine whether a TCP connection with that IP and port already exists. If a connection does exist, the SBC sends its dummy MSRP SEND message to that location so that the peer binds the new MSRP session to the existing TCP connection. On the ingress side, the determination of whether a TCP connection already exists and whether to reuse it resides with the ingress peer. The SBC listens on its MSRP server port and binds to the TCP session (existing or new) when it receives the first MSRP SEND message from the ingress peer.

Within the same connection, the SBC-generated session-id in the MSRP-URI identifies the specific session to which an individual MSRP message belongs.  The SBC also keeps track of how many sessions are using a particular TCP connection and closes the connection if there are no active sessions for some time.

MSRP Packet Policing

The SBC provides two levels of policing for MSRP sessions. For each MSRP TCP connection established, the SBC creates a table entry (referred to as a microflow) that records the connection details for the SBC and MSRP UA. The SBC discards arriving TCP media packets that do not match the entry (for example, IP address or port). Arriving MSRP data packets that match the table entry are accepted, but measured against a reasonable arrival rate. The arrival rate for an MSRP microflow is set to 10 Kbps for chat and 100 Kbps for file transfer. Packets received in excess of these rates (non-conforming packets) are processed when there is adequate MSRP bandwidth available on the interface.

The amount of bandwidth available for MSRP is derived from the system configuration for interface bandwidth dedicated for non-RTP media (refer to Reserving Interface Bandwidth for MSRP Packets). The SBC uses any available reserved bandwidth for conforming packets before using it for non-conforming packets. So, based on the amount of reserved bandwidth, all MSRP packets are subjected to a best effort policy to be admitted into the SBC.

MSRP Statistics and CDR Support

The SBC collects and displays basic statistics per MSRP session, such as the number of bytes exchanged and the IP and port information of the UAs involved in the session. View the statistics using either CLI commands (an excerpt appears below) or through the EMA UI. MSRP-related information and statistics appear in the Call Detail Record (CDR) as shown in the CDR excerpt below.

CLI Example:

> show status global callMediaStatus
    callMediaStatus 786432 {
    mediaStreamsInCall                         audio,TCP/MSRP/CHAT;
     :
    mediaStream3Label                          TCP/MSRP/CHAT;
    ingressMediaStream3OctetsSent              136;
    ingressMediaStream3OctetsReceived          136;
    egressMediaStream3OctetsSent               136;
    egressMediaStream3OctetsReceived           136;
    egressMediaStream3TcpRole                  server;
    ingressMediaStream3TcpRole                 server;
 
> show status global callDetailStatus
    callDetailStatus 786432 {
    mediaStreams                        audio,TCP/MSRP/CHAT;
    :
    ingressMediaStream3LocalIpSockAddr  "10.7.16.108/ 2000";
    ingressMediaStream3RemoteIpSockAddr "10.7.6.40/ 42580";
    egressMediaStream3LocalIpSockAddr   "10.7.16.109/ 2000";
    egressMediaStream3RemoteIpSockAddr  "10.7.6.40/ 42579"; 

Refer to Show Status Global (CLI) or Global - Call Media Status (EMA) for additional details on these commands.

Call Detail Record Example:

230.14 mediaType2                          :  TCP/MSRP/FILEXFER
     230.15 streamIndex2                   :  2
     230.16 ingress codec used2            :  n/a
     230.17 ingress local IP2              :  10.54.20.29:2000
     230.18 ingress remote IP2             :  10.70.56.124:59112
     230.22 egress local IP2               :  10.54.21.29:2000
     230.23 egress remote IP2              :  10.54.21.29:2001

231.16 mediaType2                         :  TCP/MSRP/FILEXFER
     231.17 streamIndex2                   :  2
     231.18 ingress packetSent2            :  0
     231.19 ingress packetReceived2        :  0
     231.20 ingress octetSent2             :  804
     231.21 ingress octetReceived2         :  5634
     231.22 ingress packetLost2            :  0
     231.23 ingress packetDiscarded2       :  0
     231.24 egress packetSent2             :  0
     231.25 egress packetReceived2         :  0
     231.26 egress octetSent2              :  5634
     231.27 egress octetReceived2          :  804
     231.28 egress packetLost2             :  0
     231.29 egress packetDiscarded2        :  0"

Refer to CDR Field Descriptions for more information on these fields.

MSRP-TLS Support 

The SBC enables communication over secure channels through support of TLS for MSRP and application sessions. In supporting TLS for MSRP, the SBC accepts SDP containing "TCP/TLS/MSRP" in the media description, such as the following example:

m=message 7654 TCP/TLS/MSRP *

For MSRP TLS sessions, the SDP path header must contain "msrps," such as the following example:

a=path:msrps://456@10.54.81.88:1031/jshA7taswez;tcp

The SBC only establishes a TLS connection if it receives an appropriate TLS certificate with a fingerprint that matches the TLS fingerprint in the SDP. Specifically, for INVITE requests, the SBC only establishes a TLS connection if the SDP fingerprint matches the fingerprint in the TLS certificate the SBC receives on the ingress leg. For 200 OK responses, the SBC only establishes a TLS connection if the SDP fingerprint matches the fingerprint in the TLS certificate the SBC receives on the egress leg. In either case, if the fingerprints do not match, the SBC does not establish a TLS connection but the SIP session is still active. The peer is responsible for releasing the session. 

In conjunction with this feature, the TLS profile contains a parameter to specify a hash type. The options are:

• Md5
• Sha1 (default)

• Sha224
• Sha256
• Sha384
• Sha512

The SBC supports MSRP and application TLS sessions for certificates generated for each one of these hash types. Further, the SBC Packet Service Profile (PSP) provides an option (nonRtpTlsProfileName) to specify a TLS profile to apply specifically to TLS for non-RTP streams.