In this section:
Related articles:
SBC Core systems process SIP offer and answer with MSRP SDP and establish TCP connections with the UAs. Once the connections are established between the SBC and UAs, MSRP messages are exchanged between the UAs through the SBC.
After accepting the MSRP offer, the SBC initiates an offer to the egress UA. The SBC performs the following procedures before sending the INVITE with MSRP SDP:
After accepting the MSRP answer from egress UA, the SBC sends an answer to the ingress UA. The following procedures are taken before it sends the INVITE with MSRP SDP:
MSRP UAs when making an offer can include a “setup” attribute as per RFC 4145, TCP based media transport in the SDP. MSRP UAs may also assume a default setup role and not include this attribute which basically means the UA that initiates the MSRP offer assumes a TCP client role.
The setup attribute as defined in the RFC 4145 may contain one of the three possible values “actpass”, “active” or “passive”. UAs that offer “actpass” are capable of being either a client or a server and expect the answering UA to select a specific role for the TCP connection. UAs that offer “active” or “passive” have already decided on their TCP role and expect the peer UA to take up the opposite role of what has been offered.
The SBCalways includes this attribute in the egress offer towards a MSRP UA. The value it includes by default is “actpass”. If the SBC does not receive a setup attribute in the answer, it takes up a TCP client role according to RFC 4975 where the offerer takes up by default a TCP client role. When a setup attribute is included by the UA in the answer, the TCP role is chosen based on RFC 4145.
When the SBC receives an offer SDP with “actpass”, the answer SDP sent by the SBC is always “passive”. If the SBC receives an offer without a setup attribute, according to RFC 4975, it is assumed to play a TCP client role and so the answer SDP sent by the SBC is “passive”. Otherwise the roles are chosen based on RFC 4145.
Upon completion of the offer/answer, if the SBC’s negotiated setup role is “active”, the SBC initiates a TCP connection towards the UA. The address and port it uses to connect to the UA is derived from the c line and the m line of the SDP. If the peer does not respond to the TCP connect request sent by the SBC, it can retry up to ten attempts before the connection attempt is considered as failure.
If the negotiated role of the SBC is “passive”, the listener TCP socket is open and ready to accept connection from the UA.
When the SBC sends or receives an offer to or from a MSRP UA that is behind a NAT, it always includes a setup attribute with a value “passive” thereby allowing the UAs to become a TCP client. TheSBC can accept connections from the natted UAs with the necessary security validations.
The SBC terminates the TCP connections on each side of the session – so this means each leg of the MSRP session uses its own separate TCP Connection. MSRP application is responsible to bind the two TCP connections for a specific session, so any payload received on either of the connections is simply relayed to the paired TCP connection.
TCP connections are normally terminated along with the SIP sessions. UAs may close TCP connections prior to terminating the SIP session. In those scenarios, if the SBC was the TCP server, it simply goes back to the listening state on the same TCP port that was used prior to the connection being closed. This allows the UAs to reconnect with the same transport information and there is no need for a SIP reINVITE. Similarly, if the SBC is the TCP client and if the connection is torn down by the server, the SBC reattempts connecting to the server.
Each MSRP session leg consists of a policer (also referred to as a microflow) that is installed once the TCP connections are established. The microflow is defined as a rule that contains the following configuration:
All incoming MSRP packets are checked against the above configuration.
If incoming MSRP TCP packets match an ipAccessControlList with action "discard", the packets are discarded even though the packets match up with 1 through 3.
Both conforming and non-conforming packets are subjected to another level of policer known as the Link Aggregate Policer. The configuration (see configuration section for Reserving Interface Bandwidth) of this policer is derived from the amount of bandwidth reserved for MSRP. Any available bandwidth out of the reserved bandwidth is first used for the 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.
Refer to IP Interface Group - CLI or Ip Interface Group - Ip Interface (EMA) for configuring a bandwidth contingency to reserve interface bandwidth for this scenario.