Generating RTCP
The Oracle Communications Session Border Controller is capable of creating and sending RTCP reports using Transcoding resources. This produces RFC 3550 compliant RTCP report information on media traffic for active sessions. The system calculates these statistics using measurements on traffic between a target end station and itself. With respect to a given media session, the system does not produce end-to-end reports. In addition, the system can drop RTCP reports generated upstream so target stations don't receive RTCP reports that are redundant to its own.
RTCP reporting generated at the Oracle Communications Session Border Controller provides the following benefits:
- Provide RTCP reporting to core applications that may otherwise not be receiving this data.
- Provide RTCP reporting to access elements, including mobile client applications, that may otherwise not be receiving this data.
- Generate valid RTCP data for transcoded calls.
- Generate RTCP data from the Oracle Communications Session Border Controller's perspective.
- Applicable RTCP reports continue to be sent when a call is muted or placed on-hold.
The user enables and specifies the type of calls on which the system generates RTCP reports via configuration. Applicable configuration includes creating rtcp-policy objects and applying them to realms. These objects specify whether to issue reports for transcoded or all calls traversing the realm. There is also a configuration to disable the policy.
How it Works
The Oracle Communications Session Border Controller generates RTCP by sending RTCP sender report information to the media termination point within 5 seconds after an RTP session starts, per RFC 3550. All RTCP messaging includes Sender Reports and, if the end station is receiving media, statistics corresponding to the received media. This messaging persists, within 5-second windows for the duration of the session. The system sends a goodbye message no more than 20 ms after the call is complete. The network administrator should note this timing and ensure that network NAT configuration does not block these final messages. Depending on call type and configuration, the system listens for and drops RTCP reports generated upstream. RTCP reports generated prior to transcoding provide unreliable information.
All reports include the source description with a CNAME string. The CNAME string is the IP address and port number used for the corresponding media stream's RTCP in the format:
<UDP Local Port Num for RTCP>@<IP address of the applicable steering pool>
The system sources this data from the applicable steering pool configuration.
Functional Matrix - Configuration vs. Call Type
RTCP generation and any corresponding RTCP blocking is a function of the type of call (transcoded or non-transcoded), and configuration. Applicable rtcp-policy configuration includes specifying whether the system should generate RTCP for all calls, or for transcoded calls only.
The behavior is as follows:- For Non-Transcoded Calls—Based on the RTCP-generation configuration:
- xcoded-calls-only—No RTCP generated; existing RTCP passes
- all-calls—RTCP generated; existing RTCP blocked
- For Transcoded Calls—RTCP generated; existing RTCP blocked for both configurations
- The RTCP generation setting includes a disabled setting (none) that is set by default. This specifies that the policy never generate RTCP. Realms configured with these disabled policy settings cause the system to pass existing RTCP for non-transcoded calls and block existing RTCP for transcoded calls.
When RTCP generation is enabled for non-transcoded calls using the all-calls setting, these calls must negotiate a codec that the Oracle Communications Session Border Controller can transcode. This ensures that the call utilizes the system's transcoding resources, which can then generate the RTCP.
Note:
A realm's rtcp-policy takes precedence over its block-rtcp setting. Specifically, if block-rtcp is disabled and the rtcp-policy is set to block, the system blocks existing RTCP.
