Message Session Relay Protocol
The Oracle Communications Session Border Controller (SBCsupports Message Relay Protocol (MSRP) sessions initiated by Session Description Protocol (SDP) messages exchanged through the Session Initiation Protocol (SIP) offer and answer model. MSRP usage with SDP and SIP is described in Section 8 of RFC 4975, The Message Relay Protocol. The SBC functions as a Back-to-Back User Agent (B2BUA) for MSRP sessions, terminating incoming MSRP, proxying for the MSRP session originator, initiating outgoing MSRP to the endpoint peer, and providing Network Address Translation (NAT) services.
The Oracle Session Border Controller (SBC) supports the re-creation of a Message Session Relay Protocol (MSRP) session after a connection interruption, as specified in section 5.4 of RFC 4975. A User Agent engaged in an MSRP session with the SBC can send a reINVITE to the SBC to set up a new MSRP session to replace the existing MSRP session when the TCP connection is interrupted, disconnected, or otherwise unresponsive.
MSRP Platform Support
All platforms except the Acme Packet 1100 support Message Session Relay Protocol (MSRP).
The Oracle Communications Session Border Controller supports MSRP over IPv6 and IPv4-IPv6 Inter-working function for MSRP.
Entitlement Configurations for MSRP on Virtualized Platforms
- With the setup entitlements command, set IMS-AKA Endpoints to 0.
- Perform a system reboot.
- With the setup entitlements command, set MRSP B2BUA sessions to a number greater than 499.
MSRP IP Address Family Support
The Oracle Communications Session Border Controller supports MSRP over IPv4 and IPv6. The Oracle Communications 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
|<-----------------------|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.
- 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:ABAnswer 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:09MSRP 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.
Connection Negotiation
In compliance with RFC4145 and RFC6135, the SBC can act as offerer or answerer when using SDP to negotiate MSRP sessions. As answerer, the SBC 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 SBC by configuring the preferred-setup-role parameter within the tcp-media-profile, profile-list element. Parameter values include:
- active—The SBC explicitly requests the active role.
- passive—The SBC
sends actpass to the UA as its setup role. This allows the SBC to be either active or passive,
depending on the response from the UA. If the UA responds requesting active, the SBC takes the passive role, and vice-versa.
This actpass value ensures that the SBC 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 SBC, as specified by RFC 4145.
- When the SBC receives “a=setup:active”, it performs the passive role, listening on the advertised port.
- When the SBC receives “a=setup:passive”, it performs the active role.
- When the SBC 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 SBC 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 SBC initiates an outgoing connection towards the callee (egress) on-demand and its MSRP requests to the callee. Again, the SBC as B2BUA sends its SDP offer with the setup line using its configured value.
Key behavior also includes:
- When active, the SBC 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 SBC listens for traffic on that port. By default, the listen-port is set to 0, which causes the SBC to listen using a port it allocates from the steering-pool of the applicable realm.
- When it is the answerer, the SBC is
forced into a specific role and does not always use the configured
preferred-setup-role value. The SBC 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 SBC 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 SBC takes the other role.
- When configured to propose actpass, via the passive setting, it is possible that SBC 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 SBC to trigger the outgoing connection on the other side. It is, therefore, mandatory for the SBC 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 SBC 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 SBC can happen before it sends any SIP ACK message.
SBC as Answerer
The table below shows the values the SBC inserts into its SDP setup attribute when it answers an offer from a remote UA.
| Offer | Answer | Rationale |
|---|---|---|
| Active | Passive | The SBC is forced into this role so it can comply with the section 4.1 of RFC 4145. |
| Passive | Active | The SBC 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 SBC 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 SBC takes the passive role as the answerer. |
SBC as Offerer
The table below shows the values the SBC inserts into its SDP setup attribute when it sends an offer to a remote UA. When initiating an SDP offer, the SBC 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 SBC | Rationale |
|---|---|---|---|---|
| Active | Active | Passive | active | The SBC 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 SBC 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 SBC takes the active role, per RFC 4975. |
* Note the second row. Even though you configured the preferred-setup-role to passive, the SBC 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 SBC 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 SBC increments this counter in CDR/ACR information. (The current implementation does not display this in the show msrp statistics command).
Also, the SBC 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 SBC 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 SBC.
Specifying the Connection Delay Timer
When the SBC takes the active role, it can initiate an MSRP TCP/TLS outbound connection towards the remote MSRP UA immediately after it receives the answer SDP. But the remote UA may not be ready to accept the MSRP connection request on its advertised IP/port right away. Per RFC 3264, a SIP UA should listen on its advertised IP and port immediately to receive connections, but there are end stations that do not comply with this. To alleviate the risk of failed sessions, you can configure the conn-setup-delay-timer parameter under the msrp-config within the media-manager element to wait the configured number of milleseconds before initiating the outbound connection.
When setting up sessions with UAs that are not compliant in this respect, the TCP connection attempt from the SBC can fail. This can happen if the SBC receives the TCP-RST from the remote UA for the SYN it sent, and the stops attempting the connection. This presents the risk of experiencing SIP session and MSRP connection termination, for example, when the flow guard timer expires. A remote UA cannot send any MSRP (instant) message towards the other participant through the SBC until the SBC successfully establishes the connection.
You can avoid this issue and provide flexibility for non-standard UAs by configuring the conn-setup-delay-timer parameter. This setting delays the initiation of the outbound TCP connection towards the remote UA until the SBC takes the active role. The default is 0 and the range is from 0 to 1500 milleseconds.
Configure this value if you have UA’s that do not listen on advertised ports within this window to ensure the SBC:
- Delays TCP initiation.
- Buffers any data received on the other call leg, waiting for the connection to be established.
- Sends this data after the timer expires.
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 Communications 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.
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.