RACF-only AVPs

Diameter AAR Query Post SDP Exchange

The Oracle Communications Session Border Controller supports sending the Authentication-Authorize-Request (AAR) query upon SDP answer instead of the SDP offer. This change can useful in WiMax environments where mobile phones go idle and become semi-detached from their base stations and from the WiMax access controller (WAC). In such a case, the WAC receives an AAR from the idle user but, because it cannot determine that user’s base station, rejects the request.

You enable this behavior by setting the reserve-incomplete parameter to orig-realm-only.

The Proxy Bit

When a signaling protocol receives an event request, the Oracle Communications Session Border Controller must ensure that the external policy server on the other end has enough bandwidth to maintain the requested call. The SDP information from the signaling message is stripped and encoded into the Diameter Band Request to be forwarded onto the external policy server. This feature is used with the Gq and other Diameter based interfaces.

The proxy bit allows the Oracle Communications Session Border Controller to tell the external policy server whether it wants the main server to handle the Diameter message, or if it is okay to proxy it to another server on the network. A parameter in the ext-policy-server configuration element called allow-srv-proxy has been developed. When this parameter is enabled, the proxy bit is set and the external policy server must process this Diameter request. When the parameter is disabled, the Oracle Communications Session Border Controller gives the external policy server permission to proxy the request along.

If you do not use this feature, this external policy server either handles the Diameter message on its own or proxies it to another server, depending on how much traffic it is handling at the time. This is done without any input from the Oracle Communications Session Border Controller.

Experimental-Result-Code AVP: RACF

The Diameter RACF interface takes special actions based upon what AVPs are present inside the Experimental-Result AVP in the User-Data-Answer (UDA) message. If the Experimental-Result-Code AVP found within an Experimental-Result AVP has any value that is not considered successful, per RFC 3588, the response will be handled as non-successful response and a 503 error code will be issued back to the endpoint. If the value is a successful one, the normal call flow will proceed.

Transport-Class AVP

When the Oracle Communications Session Border Controller, running as a Diameter-based RACF, receives a SIP INVITE triggering external bandwidth management, the Oracle Communications Session Border Controller performs SDP stripping and—through internal processes—selects an external bandwidth manager to use. If the options parameter in the selected external bandwidth manager is set to transport-class, the Oracle Communications Session Border Controller’s Diameter RACF interface will issue authentication authorization requests (AARs) with the transport class AVP. The Oracle Communications Session Border Controller does not insert the transport-class AVP messages when the option is not configured.

The transport-class AVP will:

  • Be identified with the AVP code 311
  • Always have the vendor (V) bit set in the AVP flags
  • Never have the mandatory (M) bit set in the AVP flags
  • Have the Vendor-Id field set to 13019 (a value specified by ETSI TISPAN)
  • Be formatted as an unsigned integer
  • Reside in the Media-Component AVP, a grouped AVP

In addition, the transport-class AVP’s payload field will be a 32-bit unsigned integer corresponding to a specific media type. The Oracle Communications Session Border Controller learns the specific media type from the m-line of the SDP it received. The following table shows how the Oracle Communications Session Border Controller evaluates the SDP’s m= lines and concludes a default service type classification.

Service Class Classification SDP evaluation Default transport-class value
video At least 1 m=video line 1
audio No m= video

At least 1m=audio

0
application No m=video, No m=audio

At least 1 m=application

3
data No m=video, No m=audio, No m=application

At least 1 m=data

2
control No m=video, No m=audio, No m=application, No m=data

At least 1 m=control

4
image No m=video, No m=audio, No m=application, No m=data, No m=control

At least 1 m=image

10
text No m=video, No m=audio, No m=application, No m=data, No m=control, No m=image

At least 1 m=text

5
message No m=video, No m=audio, No m=application, No m=data, No m=control, 
No m= image, No m=text

At least 1 m=message

6

After the service class classification has been chosen, the Oracle Communications Session Border Controller inserts the corresponding default transport class value in the transport-class AVP to send to the RACF.

Overriding Transport- Class AVP Value

You can override the Transport class AVP value sent to the RACF in a Diameter message by configuring the service class options parameter. Custom service class option values are configured as a <service-class-option>=<user-entered-value> value pair. For example, to configure the Oracle Communications Session Border Controller to send sending the value 80 instead of the value 8 for a message service class classification, you would configure message=80 in the service class options parameter.

Transport-class AVP Configuration

You configure the Oracle Communications Session Border Controller to send the Transport-Class AVP in the external bandwidth manager’s options parameter.

To set the transport-class AVP support for an external bandwidth manager:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type media-manager and press Enter.
    ORACLE(configure)# media-manager
    ORACLE(media-manager)#
  3. Type ext-policy-server and press Enter.
    ORACLE(media-manager)# ext-policy-server
    ORACLE(ext-policy-server)#
  4. options—Set the options parameter by typing options, a Space, the option name transport-class with a plus sign in front of it. Then press Enter.
    ORACLE(ext-policy-server)# options +transport-class

    If you type options and then the option value without the plus sign, you will overwrite any previously configured options. In order to append the new options to this configuration’s options list, you must prepend the new option with a plus sign as shown in the previous example.

  5. service-class-options—Set this options parameter by typing service-class-options, a <space>, the service-class type, an equal sign, your custom value. Then press Enter. Enter multiple service class/value pairs separated by a comma. For example:
    ORACLE(ext-policy-server)# service-class-options message=80,text=70
  6. Save and activate your configuration.

Service-Info-Status AVP

When the Oracle Communications Session Border Controller (SBC), running as a Diameter-based RACF, receives a SIP INVITE triggering external bandwidth management, the SBC uses the Service-Info-Status AVP to indicate the status of the service information that the SBC provides to the external policy server. If the Service-Info-Status AVP is not provided in the AA request, the policy servers assumes the service information is final.

The initial context for the SBC's support of this AVP is to support the reservation of resources over diameter, supporting call flows for Mobile Originating (MO), Mobile Terminating (MT) and non-mobile scenarios:

  • Invite with SDP offer payload (MO)
  • UE sends invite without offer, and an SDP answer is sent in PRACK (MO)
  • 183 Response with SDP answer payload from UE (MT)
  • UE sending SDP offer payload in 183 response (MT)
  • UE in origination realm sends re-invite, SDP is renegotiated with AAR
  • UE in origination realm sends update resulting in SDP exchange
  • Scenarios where SDP is inserted by OCSBC

When triggered, the SBC sends AAR messages to the external policy server over Diameter Rx interface. The supported protocol specification is Policy and Charging Control over Rx reference point 3GPP TS 29.214. The Service-Info-Status AVP (AVP code 527) carries an enumerated value, as follows:

  • PRELIMINARY SERVICE INFORMATION (1) —This value indicates that the service information provided to the external policy server is preliminary and needs to be further negotiated between the two endpoints.
  • FINAL SERVICE INFORMATION (0) — This value indicates that the service has been fully negotiated between the two endpoints. The service information provided is the result of that negotiation.

Note:

Using the Service-Info-Status to discriminate between the status of service information is limited to cases where optimize-AAR is disabled and reserve-incomplete= original-realm-only.

Rx-Request-Type AVP

When the Oracle Communications Session Border Controller (SBC), running as a Diameter-based RACF, supports external bandwidth management, the SBC uses this AVP to specify the status of the request.

The SBC can use this AVP in conjunction with the service-info-status AVP to specify whether the referenced SDP is fully negotiated and will be used for the call.

When triggered, the SBC sends AAR messages to the external policy server over Diameter Rx interface. The supported protocol specification is Policy and Charging Control over Rx reference point 3GPP TS 29.214.

The Rx-Request-Type AVP (AVP code 533) carries an enumerated value, as follows:

  • INITIAL_REQUEST (0) — The SBC is initiating the Rx session for the first time.
  • UPDATE_REQUEST (1) — The SBC is updating information related to SDP parameters of an existing Rx session.

Note:

The value PCSCF_RESTORATION is not supported within this AVP.

SIP-Forking-Indication AVP (523)

When handling access VoLTE sessions with multiple early dialogs, the Oracle Communications Session Border Controller (SBC), acting as A-SBC or P-CSCF, includes the SIP-Forking-Indication AVP in the Rx request sent to the PCRF. This occurs when the SBC receives several responses (provisional or not) with different To-Tag identifiers and different SDP.

The SIP-Forking-Indication AVP (AVP code 523) is of type Enumerated, and indicates whether or not multiple SIP dialogs are related to one Diameter session:

  • SINGLE_DIALOGUE (0) - This value indicates that the Diameter session relates to a single SIP dialog. This is the default value applicable if the AVP is omitted.
  • SEVERAL_DIALOGUES (1) - This value indicates that the Diameter session relates to several SIP dialog.

Considering the usual Access VoLTE call flow at the A-SBC level, the SBC behaves as follows:

  • When receiving a first 183 to establish a first early dialog (CALL_ID_1, From_Tag_1 and To_Tag_1 ), the SBC does not include the SIP-Forking-Indication AVP in the Rx request it sends to the PCRF
  • When receiving subsequent 183 to establish another early dialog (CALL_ID_1, From_Tag_1 and To_Tag_N ), the SBC includes the SIP-Forking-Indication AVP with the value SEVERAL_DIALOGUES in the Rx request it sends to the PCRF.
  • On receiving the first final SIP response, the SBC sends the AAR without the SIP-Forking-Indication AVP and includes the service information derived from the SDP corresponding to the dialogue of the final response.
  • In a multi-dialog scenario, the SBC sends the SIP-Forking-Indication AVP with the value SEVERAL_DIALOGUES in any PRACK or UPDATE requests that are involved in subsequent SDP exchanges that target further service provisioning.