systems process SIP offer and answer with MSRP SDP and establish TCP connections with the UAs. Once the connections are established between 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 an answer to the ingress UA. The following procedures are taken before it sends the INVITE with MSRP SDP
- If SBC 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.
- SBC picks an interface IP address from the assigned interface group and includes this as the C line in the SDP.
- SBC includes a “setup” attribute with the appropriate value based on its TCP role.
- SBC includes “msrp_cema” attribute in the SDP to the ingress UA indicating that SBC 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 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.