systems process SIP offer and answer with MSRP SDP and establish TCP connections with the UAs. Once the connections are established between
the the and UAs, MSRP messages are exchanged between the UAs through the
.
Initiating MSRP Session
After accepting the MSRP offer, the
initiates an offer to the egress UA. The
performs the following procedures before sending the INVITE with MSRP SDP:
- Select an unused listen-port from the TCP media port range which is capable of accepting TCP connections. This port number is included in the media line of the SDP.
- Pick an interface IP address from the assigned interface group and include this as the C line in the SDP.
- Include a “setup” attribute with the value “actpass”.
- Include “msrp_cema” attribute in the SDP to the egress UA indicating that should be part of the session but does not behave as a MSRP B2BUA.
- Transparently pass all other attributes received in the SDP from the ingress UA to the egress UA, including the Path URI.
Answering MSRP Session
After accepting the MSRP answer from egress UA, the SBC sends
sends an answer to the ingress UA. The following procedures are taken before it sends the INVITE with MSRP SDP
:- If SBC has the has chosen a TCP server role, it selects an unused listen-port from the TCP media port range which is capable of accepting TCP connections. This port number is included in the media line of the SDP.
- The picks SBC picks an interface IP address from the assigned interface group and includes this as the C line in the SDP.
- The includes SBC includes a “setup” attribute with the appropriate value based on its TCP role.
- SBC includes The includes “msrp_cema” attribute in the SDP to the ingress UA indicating that SBC should the should be part of the session but does not behave as a MSRP B2BUA.
- All other attributes received in the SDP from the egress UA will be transparently passed to the ingress UA and this includes the Path URI.
- If the SBC’s ’s negotiated role is “active” or TCP client, it will include a port number “9” in the media line of the answer SDP.
Connection Negotiation
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
always includes this attribute in the egress offer towards a MSRP UA. The value it includes by default is “actpass”. If the
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
receives an offer SDP with “actpass”, the answer SDP sent by the
is always “passive”. If the
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
is “passive”. Otherwise the roles are chosen based on RFC 4145.
Upon completion of the offer/answer, if the
’s negotiated setup role is “active”, the
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
, it can retry up to ten attempts before the connection attempt is considered as failure.
If the negotiated role of the
is “passive”, the listener TCP socket is open and ready to accept connection from the UA.
When the
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. The
can accept connections from the natted UAs with the necessary security validations.
TCP Connection Management
The
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
reattempts connecting to the server.
| Caption |
|---|
|
|
MSRP Session Policer
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:
- MSRP UA IP and Port. This is derived from the SDP media and c line. In some cases when the peer is behind a NAT device, the UAs IP and Port is derived from the incoming TCP connection.
- IP and TCP port that is reserved for the MSRP session.
- TCP for MSRP sessions protocol.
- Maximum rate (in Kbps) at which MSRP UAs may send data over the established TCP connection. Instant messaging is configured with 10 Kbps and file transfer is set up with 100 Kbps.
All incoming MSRP packets are checked against the above configuration.
- If the incoming packet does not match up with 1 through 3, those packets are discarded. All the other packets are accepted by the microflow policer.
- Accepted packets that are within the configured packet rate as specified by 4 are “conforming” packets.
- Accepted packets that have exceeded the configured packet rates as specified by 4 are “non-conforming” packets.
| Panel |
|---|
| borderColor | #fff2cc |
|---|
| bgColor | #fffdf6 |
|---|
| title | Note |
|---|
|
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
.
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.