Diameter: RACF

As the Oracle Communications Session Border Controller proxies and forwards calls, caller media information is known before the INVITE reaches the callee. The Oracle Communications Session Border Controller, acting as a P-CSCF, requests a specific amount of bandwidth for a call, and the RACF can reserve this amount of bandwidth for a call before the called phone rings. A call's required bandwidth can also be reserved by network devices along the path from the caller to callee if the QoS admission criteria is pushed from the RACF to other edge nodes (PEPs) such as routers, along this path to the callee.

Implementation Features

Bandwidth-based CAC is performed according to the following typical scenario. When the Oracle Communications Session Border Controller, known as the Policy Enforcement Point (PEP), receives a SIP INVITE, it sends a Diameter Authentication Authorization Request (AAR) message to the Policy Decision Point (PDP) or Resource and Admission Control Function (RACF). The Oracle Communications Session Border Controller does not forward the INVITE to its destination at this point.

The AAR message includes call identification information and the SDP-based bandwidth requirements for the call. The RACF responds with a Diameter Authentication Authorization Answer (AAA) message to either the install or remove the call. An install command directs the Oracle Communications Session Border Controller to forward the INVITE to the next SIP device. A remove command directs the Oracle Communications Session Border Controller send a SIP 503 Service Unavailable message sent back to the UA and reject the call.

When the RACF is unreachable, incoming calls are rejected by default with a 503 message, as bandwidth can not be reserved. It is possible to configure the Oracle Communications Session Border Controller to allow all calls when the RACF is unreachable if this is the desired behavior.

Displays the components of a policy server deployment.

The Oracle Communications Session Border Controller can be configured so that both sides of a call, based on realm, are subject to bandwidth enforcement. Each flow is treated as a unique call/event, because from a media and signaling perspective, they are distinct. As the Oracle Communications Session Border Controller functions as one side of a call, its IP address is inserted into the AAR message regardless of whether it is the calling or called party. This allows for the Diameter install or remove decision to be made before the Oracle Communications Session Border Controller receives the 200 OK response, and before ringing the far-end phone. Only one external policy server can be used within a single realm.

When a call ends, either with the expected SIP BYE or CANCEL methods, or due to other error conditions, the Oracle Communications Session Border Controller alerts the RACF by sending it a Diameter Session Termination Request (STR) message. All ended calls must be deleted from the RACF in order to accurately track used and available bandwidth.

The RACF can apply its hosted policies for calls originating at SIP UAs located behind NATs. This is a standard part of the Oracle Communications Session Border Controller's ability to provide seamless HNT.

Displays the protocols used by components of a policy server.

Bandwidth Negotiation

Because the decision whether to admit or reject a call is made before the INVITE is forwarded to the called party, some information is not available to the PDP at the initial request. The final IP Address, UDP port number, that transport the RTP flow, and the codec used are not known by the Oracle Communications Session Border Controller until the called party responds with its own SDP information (either in the 180 or 200 response).

The Oracle Communications Session Border Controller examines the Session Description Protocol (SDP) value in the body of the SIP INVITE to determine what codecs are available for the call. If the INVITE specifies more than one codec, the Oracle Communications Session Border Controller bases its request to the RACF on the most bandwidth-hungry codec to ensure that all bandwidth requests will succeed or fail on the first attempt.

Note:

The amount of bandwidth requested depends on the configured media profiles.

If the call is admitted, and when the called party returns finalized SDP information, the Oracle Communications Session Border Controller modifies the original reservation with the chosen codec's bandwidth requirements. This ensures the RACF has current and accurate information with which to make policy decisions.

Session Lifetime

When receiving a successful Diameter response message for bandwidth from the RACF, a session lifetime timer may be included in the message. If included, this timer states how long the session can last. If the session continues past 3/4 of session lifetime, the Oracle Communications Session Border Controller sends another bandwidth request for that session to ultimately refresh the lifetime timer. If the RACF grants this bandwidth request, the Oracle Communications Session Border Controller continues to allow the session to proceed uninterrupted. If a lifetime timer for a session is not returned to the Oracle Communications Session Border Controller by the RACF, the Oracle Communications Session Border Controller assumes the session can last forever and never issues a refresh in this manner.

Opening for RTCP Flows

When the Oracle Communications Session Border Controller functions as the AF (i.e., A-SBC or P-CSCF), you can configure it to explicitly open RTCP ports, just as it does for RTP. Without explicitly opening these ports, the Oracle Communications Session Border Controller relies on possibly unreliable PDN-GWs and BRAs to open RTCP ports and it sends only RTP information in AARs.

In external bandwidth managements configurations where the application mode is Rx and the include-rtcp-in-request parameters is enabled, the Oracle Communications Session Border Controller ensures RTCP ports are opened. It sends AAR requests to the policy server (PCRF) that contain both RTP and RTCP, opening the gates (ports) for both RTP and RTCP flows. RTCP information in the AAR is the number of the RTP port plus one (RTP port + 1 = RTCP ports) for all sessions. Flow information for RTCP is part of a different Media-Sub-component AVP as the RTP, but under the same Media-Component-Description AVP. RTCP flow information will also include the Flow-Usage AVP with RTCP (1). The RTCP port is set to 0 when the RTP ports is also unknown and therefore set to 0.