COPS: RACF

CAC is performed according to the following typical scenario. When the Oracle Communications Session Border Controller receives a SIP INVITE, it sends a COPS request (REQ) message to the PDP. The REQ message includes the call ID, the SIP client's IP address, the Oracle Communications Session Border Controller’s IP address and port number of the ingress interface for the call, and SDP based bandwidth requirements. The PDP responds with a COPS Decision (DEC) message with either the Install or Remove command. 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.

The Oracle Communications Session Border Controller can be configured so that both sides of a call, based on realm, are subject to COPS 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 REQ message regardless of whether it is the calling or called party. This allows for the COPS 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 will delete the reservation on the PDP by sending a COPS delete request state (DRQ) message to the PDP. All ended calls must be deleted from the PDP in order to accurately track used and available bandwidth.

Implementation Features

As the Oracle Communications Session Border Controller proxies and forwards calls, caller media information is known before the INVITE reaches the callee. The PEP can request a specific amount of bandwidth for a call, and the PDF 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 to PEPs such as routers, along this path to the callee.

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.

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 OCSBC sends a request to the PDP requesting as much bandwidth as the codec with the highest bandwidth in the SDP message requires. If the call is admitted, and when the called party returns finalized SDP information, the OCSBC modifies the original reservation with the chosen codec's bandwidth requirements. This ensures the PDP has current and accurate information with which to make policy decisions.