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 SBC 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.
Double Steering Pool Port Allocation
You can enable the double-port-allocation parameter in the msrp-config to make the SBC use two ports per MSRP call instead of one on a per-realm basis.
Recall that you can configure a realm with multiple steering-pools and set a strategy for each pool. The SBC creates a port list from which it selects ports on a per-call basis. By default, the SBC assigns the first two ports that are sequential for audio calls and single ports for MSRP calls. When a call is completed, the SBC puts the newly available port (or ports) at the top of the list. Because calls can terminate at any time, the system may re-populate the available port list with non-consecutive port pairs.
You can enable this parameter to make the system assign two sequential ports for MSRP calls as well as audio calls. This results in the system re-populating its available port list with consecutive port pairs for each audio and MSRP call.
Consider the SBC behavior with respect to double-port-allocation configuration and port allocation based on call type:
- double-port-allocation disabled:
- Audio Calls:
- The system uses ports from pair strategy pools first
- When pair port pools are not configured or exhausted, the system selects ports from mixed strategy pools
- The system never uses ports from single strategy pools
- MSRP Calls:
- The system uses ports from single strategy pools first
- When single port pools are not configured or exhausted, the system selects ports from mixed strategy pools
- The system never uses ports from pair strategy pools
- double-port-allocation enabled:
- Audio Calls—The system does not change is port pool selection order
- MSRP Calls:
- The system uses ports from pair strategy pools first
- When pair port pools are not configured or exhausted, the system selects port from mixed strategy pools
- The system never uses ports from single strategy pools
- Audio Calls:
As shown above, the SBC effectively eliminates the use of single strategy pools in realms with double-port-allocation enabled, ensuring the available port list always uses two consecutive ports to support audio and MSRP calls.
Oracle recommends that you do not use existing mixed strategy pools within realms when you enable double-port-allocation on a realm. Instead, use the following procedure so that the existing unordered list becomes a consecutive port list:
- Enable double-port-allocation.
- Delete the mixed strategy pool(s) from the applicable realm.
- Save and activate your configuration.
- Recreate the deleted pool(s) from scratch using the same port range and strategies.
- Save and activate your configuration again.
This process enables the system to clear the available port list, create a fresh available consecutive port list, and start using the port allocation rules above for when double-port-allocation is enabled. You enable this feature using the syntax below:
Oracle (msrp-config)# double-port-allocation enabledCertificate 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.
MSRP B2BUA Support for NG911
The Oracle Communications Session Border Controller (SBC) supports Message Session Relay Protocol (MSRP) and Back to Back User Agent (B2BUA) networking for Next Generation 911 (NG911). MSRP is used for messaging and file sharing in Session Initiation Protocol (SIP), which is widely used in NG911 markets that utilize MSRP with either an MSRP application server or in Peer-to-Peer (P2P) mode. Such support enables (SBC) customers to deploy the SBC as a Public Safety Answering Point (PSAP). The SBC supports this functionality only on Virtual Machines.
In P2P mode, the SBC uses MSRP, SIP, and the Session Delivery Protocol (SDP) offer-answer to establish a TCP or TLS media bearer plane between two MSRP endpoints. For MSRP B2BUA operation, the SBC terminates the bearer plane from one peer, and routes the message to the bearer of the other peer that is also anchored by the SBC.
For client-server MSRP, the SBC terminates the TCP or TLS bearer plane from the client and then connects it with a separate TCP or TLS bearer plane initiated by the SBC towards the server.
In addition to terminating and re-originating TCP or TLS for MSRP, the B2BUA modifies the To-Path and From-Path headers of the MSRP messages. The following example shows the modifications to the MSRP "To-Path" and "From-path" headers during traversal:
Figure 22-1 MSRP Flow with No Middlebox Present
MSRP and Middlebox Traversal Using the CEMA Extension and Session-ID
The Oracle Communications Session Border Controller (SBC) requires the Connection Establishment for Media Anchoring (CEMA) extension (RFC6714) and the session-id matching mechanism to allow the SBC to exchange Message Session Relay Protocol (MSRP) messages through middleboxes that do not act as MSRP Back to Back User Agents (B2BUA). When such a middlebox passes the MSRP messages through without updating the SDP a=path attribute, the SBC cannot establish a TCP connection through the middlebox. The CEMA mechanism makes the connection possible. In a scenario where the middlebox does update the SDP a=path attribute, the MSRP messages will not pass validation and will be dropped. The Session-id matching mechanism prevents that situation. The SBC supports this functionality only on Virtual Machines.
With the CEMA extension enabled, the SBC detects the presence of a middlebox that anchors the media and does not update the SDP a=path attribute by comparing the SDP c and m lines to the SDP a=path attribute. When the CEMA-enabled SBC plays the active role in establishing the TCP connection it establishes the connection to the endpoint identified by the c and m lines instead of the a=path.
Figure 22-2 Signaling Flow with a Middlebox and CEMA Enabled
Figure 22-3 MSRP Flow with a Middlebox and CEMA Enabled
- Disabled (default)-When playing the active role, the SBC establishes the TCP connection to the IP address and port number specified in the SDP a=path attribute of the peer. If the SDP a=path attribute contains a DNS name, the ESBC attempts to use the c line. If the c line also contains a DNS name, the SBC rejects the session.
- Enabled-When the SBC detects the presence of a middlebox, it tries to negotiate the CEMA support by including the a=msrp-cema-support media attribute. When playing the active role, the SBC establishes a TCP connection to the IP address and port number indicated in the peer's SDP c and m lines rather than the a=path media attribute. If you enable msrp-cema-support, you must disable msrp-sessmatch.
Note:
The SBC does not perform DNS name resolution for either the SDP a=path or the c and m lines.To-path Authority Validation
The presence of middleboxes that anchor the media and update the SDP a=path attribute to match the updated SDP c and m lines cannot be detected in the signaling plane. An MSRP B2BUA that is not enabled for CEMA correctly sets up TCP connections to the middlebox because the SDP a=path attribute points to the middlebox. Because the middleboxes do not accordingly update the MSRP message To-Path headers, MSRP messages passing through such a middlebox cannot validate because the authority part of the To-Path header does not match the authority part of the SDP a=path attribute. In such scenarios the validation of the MSRP URI is based only on the session-id part of the MSRP URI, the MSRP scheme, and transport (Session-Id matching).
- Disabled (default)-The MSRP URI comparison between the SDP a=path attribute and the To-Path header in the MSRP messages received from a realm includes the MSRP URI scheme, authority IP address, port number, session-id, and transport. If the comparison is unsuccessful and the sender requires a report, the SBC returns an MSRP 481 error response to the sender.
- Enabled-The MSRP URI comparison between the SDP a=path attribute and the To-Path header in the MSRP messages received from a realm includes only the MSRP URI scheme, session-id, and transport. If the comparison is unsuccessful and the sender requires a response, the SBC sends an MSRP 481 error response to the sender. If you enable msrp-sessmatch, you must disable msrp-cema-support.
Figure 22-4 Signaling Flow with Session Matching Enabled
Figure 22-5 MSRP Flow with Session Matching Enabled
MSRP Media Types Filtering
You can configure the Oracle Communications Session Border Controller (SBC) to use an allowlist to filter media types and sub-types that you want the system to allow. During SIP signaling, the SBC removes media types not listed on the allowlist from the SDP offer. The SBC also rejects Message Session Relay Protocol (MSRP) SEND requests that announce media types in the MSRP content-type header other than those negotiated during the SDP offer-answer exchange. The SBC supports this functionality only on Virtual Machines.
Use the msrp-types-allowlist parameter in the tcp-media-profile configuration to set a list of media types and sub-types that you want the system to accept in MSRP messages. Each entry represents one media type and sub-type. When the parameter contains a valid value, the system checks that incoming MSRP SEND requests contain only the media types specified in the SDP a=accept-types attribute. Leave the msrp-types-allowlist parameter empty to tell the system not to perform any media types filtering. Use the asterisk character (*) to allow all MSRP media types. Valid values: empty | MsrpMediaTypeList | *. Default: empty.
The SBC does not provide filtering
for the attributes that may accompany a media type, for example, the attribute 'charset'
in,text/html;charset=ISO-8859-1. When an SDP offer contains a media type on
the allowlist that includes attributes, the SBC does not touch the
attributes.
MSRP Message Size Limiting
To set a limit on the Message Session Relay Protocol (MSRP) size of the message that the Oracle Communications Session Border Controller (SBC) can receive from a given realm, the tcp-media-profile configuration includes the msrp-message-size, msrp-message-size-file, and msrp-message-size-enforce options. The SBC supports this functionality only on Virtual Machines.
- in the signaling plane - in the SDP a=max-size attribute
- in the data plane - in the MSRP Byte-Range header.
- fills in the SDP offer-answer and a=max-size attribute, if missing.
- adjusts its value to the configured limits, if the value of the SDP a=max-size attribute exceeds the limit.
message/cpim header.
(512 to 1024 bytes fits most scenarios.) When the msrp-message-size-file value
is greater than zero, the
SBC:
- fills in the SDP offer-answer a=max-size attribute, if missing.
- adjusts its value to the configured limit, if the value of the SDP a=max-size attribute exceeds the limit.
The msrp-message-size-enforce parameter, when enabled, performs byte counting on the MSRP messages to enforce compliance with the negotiated maximum MSRP message size. The negotiated maximum MSRP message size is the minimum between the SDP a=max-size attribute value (if one is provided by the B2BUA) and the configured value for msrp-message-size or msrp-message-size-file. If the SBC detects that the actual size of the MSRP chunk does not match the negotiated maximum size, it immediately stops forwarding the chunk. When the MSRP session is a file transfer, the SIP session terminates by sending a BYE on both the originating and the terminating legs.
Note:
The maximum negotiated size applies to MSRP chunks rather than MSRP messages.MSRP and High Availability
Following a High Availability (HA) switchover on platforms that support Message Session Relay Protocol (MSRP), the new active Oracle Communications Session Border Controller (SBC) responds with a TCP RST to the first MSRP message received on an MSRP session that a UA established with the former active SBC. This response provides for a timely detection of the HA switchover and enables the UA to re-initiate the MSRP session by sending a SIP re-INVITE.
Upon a switchover, the first MSRP packet arriving at the newly active SBC triggers a TCP RST to be sent back immediately because the newly active does not have the TCP connection to receive the packet. This timely response allows the UA that sends the packet to quickly detect the connection interruption and send a reINVITE to set up a replacement session.
MSRP Configuration
MSRP configuration consists of the following steps.
- Configure the msrp-config configuration object that governs MSRP global behavior.
- Configure one or more tcp-media-profile configuration objects that define MSRP operations within a realm.
- Assign a tcp-media-profile to a target realm.
- If MSRP sessions are secured with TLS, create and assign tls-profile configuration objects to the tcp-media-profile of the target realm.
- Create and assign steering-pools configuration objects to target realms.
Configure tcp-media-profile
The tcp-media-profile defines Message Session Relay Protocol (MSRP) operations within a realm. You specify settings that are common to every tcp media profile, as well as optional settings that you use to customize a particular tcp media profile.
- If you want to set an allow list for allowed MSRP types, create the list before you perform this configuration.
Use the following procedure to build a TCP media profile that defines MSRP operations within a realm.
- Repeat the procedure to configure each additional tcp-media-profile that you need.
- Apply the profile to a realm.
MSRP Statistics
MSRP byte and packet counters are available at the end of each MSRP call.
- ACLI output. See the ACLI Configuration Guide and the Maintenance and Troubleshooting Guide. You can configure the system to display additional ACLI statistics.
- RADIUS VSAs and Local CDR. See "Oracle RADIUS VSAs" and "AVP Definitions" in the Accounting Guide for details.
- Diameter Rf ACR messages. See "Acme-Packet-Specific-Extension-Rf AVP" in the Accounting Guide for details.
- MSRP Objects for SNMP. See "SIP MIB" (ap-sip.mib) in the MIB Reference Guide for details. You can configure the system to display additional SNMP statistics.
Transmitted and received counters are available in Acme-Extended-Attributes. See "Acme-Extended-Attributes Explanation" in the Accounting Guide for more information.
MSRP Management Monitoring
When you want to see MSRP flow, cumulative, and state counts statistics for the Oracle Communications Session Border Controller (SBC), use the show mbcd statistics, show msrp statistics, and show mbcd msrp commands.
The show mbcd statistics command displays MSRP flow counts for the current statistics window. For example:
ORACLE# show mbcd statistics
16:38:49-145
MBCD Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Client Sessions 1 1 0 1 1 1
...
Flow-MSRP 2 2 0 2 2 2
...
Flow Rate = 0.0
Load Rate = 0.0
ORACLE#The show msrp statistics command can display the cumulative count for dozens of statistics. The system always displays the default set of statistics, even when the value is zero, plus any other statistics that do have a value. For example:
ORACLE# show msrp statistics
FD Table Size: 0
Session-ID Table Size: 0
Total Active Sessions: 0
Maximum Active Sessions: 0
Total Established Sessions: 0
Total Provisioned Sessions: 0
Total Finished Sessions: 0
Total Accepted Connections: 0
Total Connected Connections: 0
Total Released Connections: 0
Total Requests Received: 0
Total Requests Sent: 0
Total Responses Received: 0
Total Responses Sent: 0
Total Global Buffer Data: 0
Total MSRP Nat Flows Added: 0
Total MSRP Nat Flows Deleted: 0
Total Active CEMA Sessions: 0
Total Established Sessmatch Sessions: 0
Total Provisioned Sessmatch Sessions: 0
Total Active Sessmatch Sessions: 0
The show mbcd msrp command displays MSRP session state counts. For example:
ORACLE# show mbcd msrp
14:35:15-194
MSRP Statistics ---- Lifetime ----
Recent Total PerMax
Provision Sessions Unreleased 0 0 0
Listening Sessions Unreleased 0 0 0
Established Sessions Unreleased 0 0 0
Closed Sessions Unreleased 0 0 0
Finished Sessions Unreleased 0 0 0
PPM Messages Received 0 0 0
PPM Messages Processed 0 0 0
PPM Messages Sent 0 0 0
PPM Messages Send Fail 0 0 0
MSRP Flow States -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
MSRP-FlowListen 0 0 0 0 0 0
MSRP-FlowProvision 0 0 0 0 0 0
MSRP-FlowProvisioned 0 0 0 0 0 0
MSRP-FlowEstablished 0 0 0 0 0 0
MSRP-FlowShared 0 0 0 0 0 0
MSRP-FlowClose 0 0 0 0 0 0
MSRP-FlowFinished 0 0 0 0 0 0
MSRP-FlowReleased 0 0 0 0 0 0
MSRP-FlowWaitDrop 0 0 0 0 0 0
You can configure the system to extend the show mbcd msrp output. After configuration, the system provides additional arguments. The additional arguments provide a broad set of system-wide or realm-based statistics, and include SEND and REPORT statistics. See "Extended MSRP Statistics" in the ACLI Configuration Guide and "MSRP Protocol Performance" in the Maintenance and Troubleshooting Guide for more information, including configuration.
Extended MSRP Statistics
You can configure the Oracle Communications Session Border Controller (SBC) to display additional protocol statistics on MSRP methods using SNMP and CLI.
The SBC displays MSRP traffic statistics on a per-window, periodic basis (100 seconds) and on a lifetime basis. The SBC correlates statistics using MSRP method type, including SEND and REPORT, and on a per-realm and system-wide basis. You can display the statistics using the ALCI by specifying method and basis. You can also collect the statistics using SNMP walks. Use the reset all and reset mbcd commands to reset MSRP KPI statistics.
The SBC supports Extended MSRP statistics on the following physical platforms, only:
- Acme Packet 4600
- Acme Packet 4900
- Acme Packet 6100
- Acme Packet 6300
- Acme Packet 6350
- Acme Packet 6400
The SBC uses SIP and SDP to signal MSRP media traffic. MSRP traffic includes:
- MSRP SEND requests, which present the following methods:
- CHAT
- IS-TYPING
- RECEIPT
- REPORT traffic, which indicates delivery success and failure
- Transaction response status traffic, which indicates success and failure in response to a request
You can use extended MSRP statistics to segregate MSRP method traffic, track cause values and byte counts on a receive and transmit basis. This allows you to analyze sessions within the context of specific transaction types, across relays, and across MSRP chunks.
Note:
RADIUS, CDR, and DIAMETER do not support Extended MSRP statistics.The MSRP complexities that extended KPIs can help you analyze include:
- The session-oriented nature of MSRP requires the use of Message-ID and byte ranges, if present, to correlate traffic.
- Cause codes can change over the course of a session, based on circumstances across the relay path or the endpoints.
- SEND requests deliver a complete message or a chunk, which is a portion of a complete message, which can be supported by monitoring byte ranges to correlate components of associated requests.
- REPORT requests report on the status of a previously sent message, or a range of bytes inside a message.
You enable extended MSRP statistics by enabling the msrp-kpi parameter in msrp-config.
ORACLE(msrp-config)# msrp-kpi
<enabled/disabled> To enable the MSRP KPI statistics
Default: disabledWhen you enable these extended statistics, the SBC provides additional MSRP statistics commands.
show mbcd msrp
show mbcd msrp realm <identifier>
show mbcd msrp SEND
show mbcd msrp REPORT
show mbcd msrp REPORT failure
show mbcd msrp SEND responses
show mbcd msrp realm <identifier> SEND
show mbcd msrp realm <identifier> REPORT
show mbcd msrp realm <identifier> REPORT failure
show mbcd msrp realm <identifier> SEND responses
See the MSRP Protocol Performance section in the Oracle® Communications Session Border Controller Maintenance and Troubleshooting Guide for detail on these commands.
Statistic Calculation Formulas
The SBC implements MSRP KPI statistics for total, average, and rate using the formulas shown below. The examples below use SEND transactions for the average and total statistics, and REPORT failure transactions for rate statistics:
- System wide:
- Average calculation - MSRP-AvgSENDTransTx = Sum of all Tx SEND transactions of peer and core/number of MSRP sessions.
- Total calculation - MSRP-SENDMsgBytesTx = Sum of Message bytes of all Tx SEND transactions of peer and core
- Rate calculation - MSRP-REPORTFailureRateTx = (sum of all Tx REPORT failure transactions of peer and core / sum of all Tx REPORT success and failure transactions of peer and core) * 100
- Per Realm:
- Average calculation - MSRP-AvgSENDTransTx = Sum of all Tx SEND transactions per realm/number of MSRP sessions
- Total calculation - MSRP-SENDMsgBytesTx = Sum of Message bytes of all Tx SEND transactions per realm
- Rate calculation - MSRP-REPORTFailureRateTx = (sum of all Tx REPORT failure transactions per realm /sum of all Tx REPORT success and failure transactions per realm) * 100
SNMP
Extended MSRP KPI statistics are also available by way of SNMP. These are the same statistics available from the ACLI, and also require configuration. Extended SNMP statistics are realm and system-wide.
Realm—The MSRP KPI realm labels are contained in OID APAPPS-MIB. The apAppsMSRPKPIRealmEntry entry consists of apMSRPKPIRealmName, which is configured in ACLI and apMSRPKPIRealmIndex, which is the object ID of the ACLI config element. Syntax for complete OIDs follow this sequence:
- The root label for the MSRP KPI realm Stats SNMP table is
APAPPS-MIB:: ApAppsMSRPKPIRealmStatsEntry
The OID of each realm is the same ID as the configuration object instance. This means the table starts from the config-object ID, not from 0.
- Next is the Instance OID (msrp-realm).
- Next is the type of stats: recent, high, total, ltotal, lpermax,
lhigh.
The system distinguishes between apMsrpKpiStatsCounterType using the following values:
- Period window values:
- recent (1)
- high (2)
- total (3)
- Lifetime window values:
- ltotal (4)
- lpermax (5)
- lhigh (6)
- Period window values:
- The last label is the type of statistic, including msrp-AvgSENDTransTx, msrp-AvgChatSENDTransTx, and so forth.
SystemWide—The ApAppsMSRPKPISystemStatsEntry entry consists of apMsrpKpiStatsCounterType and apMSRPKPIStatsType. Syntax for complete OIDs follow this sequence:
- The root label for the MSRP KPI system Stats SNMP table is APAPPS-MIB:: ApAppsMSRPKPISystemStatsEntry
- The type of stats: recent, high, total, ltotal, lpermax, lhigh
The system distinguishes between apMsrpKpiStatsCounterType using the following values:
- Period window values:
- recent (1)
- high (2)
- total (3)
- Lifetime window values:
- ltotal (4)
- lpermax (5)
- lhigh (6)
- Period window values:
- The type of statistic, including msrp-AvgSENDTransTx, msrp-AvgChatSENDTransTx, and so forth.
See the Oracle® Communications Session Border Controller MIB Guide for detail on these tables.
MSRP Session Limitations Based on Entitlements
This section provides some guidelines on how the SBC determines whether your configured MSRP entitlement does or does not allow new sessions when you are reaching your configured session limit.
Within the context of MSRP, session definitions include:
- Active MSRP sessions—The MSRP TCP/TLS connections that are in the connected state. Active sessions include those in the Listen, Provisioning, Provisioned, Established and Shared states.
- InActive MSRP sessions—The MSRP TCP/TLS connections which are in terminated state. Inactive sessions include those in states the Close, Finished, and WaitDrop states.
When evaluating your system's MSRP session capacity, the SBC uses the following guidelines to calculate Active MSRP sessions:
- Your configured entitlement minus the currently Active (connected) sessions, OR
- The total number of sessions shall be derived using the configured entitlement as a base value by keeping some additional buffer minus the current number of sessions (ACTIVE+INACTIVE).
Note:
MSRP Flow States shows the counts in terms of flows. One B2B MSRP session is equal to '2' MSRP flows.The examples below explain how the SBC is allowing the new calls/sessions by considering configured entitlement and MSRP states.
Example 1
Assume for this example, you have set your MSRP B2BUA Sessions entitlement to 1.
- The SBC has received the
first call, which is in Provisioned
state.
ORACLE# show mbcd msrp MSRP Flow States --–----- Period –------------- Lifetime -------- Active High Total Total PerMax High MSRP-FlowInitial 0 0 0 0 0 0 MSRP-FlowListen 0 0 0 0 0 0 MSRP-FlowProvision 0 0 0 0 0 0 MSRP-FlowProvisioned 2 2 2 0 0 0 MSRP-FlowEstablished 0 0 0 0 0 0 MSRP-FlowShared 0 0 0 0 0 0 MSRP-FlowClose 0 0 0 0 0 0 MSRP-FlowFinished 0 0 0 0 0 0 MSRP-FlowReleased 0 0 0 0 0 0 MSRP-FlowWaitDrop 0 0 0 0 0 0 - When the SBC receives a second call, it rejects that call with a 503 message because it can support a maximum of one call/session based on the configured entitlement.
Example 2
Assume for this example, you have set your MSRP B2BUA Sessions entitlement to 3.
- The SBC has received three
calls, which are in Provisioned, Established, Shared
states.
ORACLE# show mbcd msrp MSRP Flow States --–----- Period –------------- Lifetime -------- Active High Total Total PerMax High MSRP-FlowInitial 0 0 0 0 0 0 MSRP-FlowListen 0 0 0 0 0 0 MSRP-FlowProvision 0 0 0 0 0 0 MSRP-FlowProvisioned 2 2 2 0 0 0 MSRP-FlowEstablished 2 2 2 0 0 0 MSRP-FlowShared 2 2 2 0 0 0 MSRP-FlowClose 0 0 0 0 0 0 MSRP-FlowFinished 0 0 0 0 0 0 MSRP-FlowReleased 0 0 0 0 0 0 MSRP-FlowWaitDrop 0 0 0 0 0 0 - When the SBC receives a fourth call, it rejects that call with a 503 message because it can support a maximum three call/session based on configured entitlement.
- When the SBC receives a BYE
for, for example, the first call and has closed the associated MSRP connections,
the show mbcd msrp statistics appear as
follows.
ORACLE# show mbcd msrp MSRP Flow States --–----- Period –------------- Lifetime -------- Active High Total Total PerMax High MSRP-FlowInitial 0 0 0 0 0 0 MSRP-FlowListen 0 0 0 0 0 0 MSRP-FlowProvision 0 0 0 0 0 0 MSRP-FlowProvisioned 2 2 2 0 0 0 MSRP-FlowEstablished 0 2 2 0 0 0 MSRP-FlowShared 2 2 2 0 0 0 MSRP-FlowClose 0 0 0 0 0 0 MSRP-FlowFinished 0 0 0 0 0 0 MSRP-FlowReleased 2 2 2 0 0 0 MSRP-FlowWaitDrop 0 0 0 0 0 0 - When the SBC receives a new
call, it allows that call because it now has two only Active calls and can
support one new
call.
ORACLE# show mbcd msrp MSRP Flow States --–----- Period –------------- Lifetime -------- Active High Total Total PerMax High MSRP-FlowInitial 0 0 0 0 0 0 MSRP-FlowListen 0 0 0 0 0 0 MSRP-FlowProvision 0 0 0 0 0 0 MSRP-FlowProvisioned 2 2 2 0 0 0 MSRP-FlowEstablished 2 2 2 0 0 0 MSRP-FlowShared 2 2 2 0 0 0 MSRP-FlowClose 0 0 0 0 0 0 MSRP-FlowFinished 0 0 0 0 0 0 MSRP-FlowReleased 2 2 2 0 0 0 MSRP-FlowWaitDrop 0 0 0 0 0 0
At any point in time, whatever the configured MSRP entitlements value, the SBC supports that many Active MSRP sessions within the context of the best case scenario (which does not include inactive state sessions).