CLF-only AVPs

Globally-Unique-Address AVP

When endpoints registering through the Oracle Communications Session Border Controller reside in nested realms, the Oracle Communications Session Border Controller allows you to set the realm that appears in the Globally-Unique-Address AVP in Diameter UDR messages destined for a CLF.

The ingress-realm-location parameter in the external policy server configuration specifies whether to use the realm on which a signaling message arrived, or to use that realm’s parent. If you choose to use the parent realm, the Oracle Communications Session Border Controller uses the one associated with the SIP interface on which the REGISTER request arrived.

e2 Interface

You can configure a value to be sent in the Address-Realm AVP (communicated in the Globally-Unique-Address AVP) for the Diameter e2 interface. This AVP is sent on a per-realm basis in the Location Information Query (UDR) query the Oracle Communications Session Border Controller (as a P-CSCF) sends to the CLF.

The CLF maintains details about IP connectivity access sessions associated with user equipment connected in the network. This CLF supports the standardized Diameter e2 interface with an Application Function; from it, the application function (i.e., the Oracle Communications Session Border Controller in the role of P-CSCF) retrieves location information and other data related to the access session. To do so, the AF sends a UDR containing Global-Unique-Address and Requested Information attributes. Then the CLF returns a Location Information Response (UDA) containing either a success result code with location information or an error result code.

In the UDR’s Global-Unique-Address, the Oracle Communications Session Border Controller currently supports the mandatory parameters: the Framed-IP-Address AVP and the Address-Realm AVP. The address realm AVP is the realm address in FQDN form, populated based on the realm on which a REGISTRATION arrived or the SIP interface. With nested realms configured, using a realm for this value can quickly become complicated.

You can configure the value sent in the Address-Realm AVP on a per-realm basis. You set the external policy server’s ingress-realm-location parameter to the diam-address-realm value, pointing the Oracle Communications Session Border Controller to the associated realm from which it will learn Address-Realm AVP information. This access realm (or child realm, the realm on which enter registration came in) has its diam-e2-address-realm value set to the value with which to populate the Address-Realm AVP for the outgoing UDR message.

CLF e2 Interface User-Name AVP Support

In compliance with ETSI ES 283 -35 V1.2.1, the Oracle Communications Session Border Controller’s e2 interface can query the CLF using the SIP endpoint’s IP address or its NASS User-ID. The system’s e2 interface uses the uses the SIP-URI to query the CLF by including the User-Name AVP in the User Data Request (UDR). The CLF can then furnish the P-CSCF (i.e., the Oracle Communications Session Border Controller) with the INSEE code in the Location-Information AVP in its User Data Answer (UDA).

This diagram shows how this capability works. The Oracle Communications Session Border Controller acts as the P-CSCF.

The CLF e2 Interface User-Name AVP diagram is described above.

Registering users—When it receives a registration request, the Oracle Communications Session Border Controller checks the incoming SIP interface to determine CLF use. If CLF use is unnecessary, the Oracle Communications Session Border Controller forwards the registration message to its destination.
When CLF is required, the Oracle Communications Session Border Controller selects the AVPs to send the CLF, including the User-Name AVP before sending it a UDR. A none setting for this parameter means the Oracle Communications Session Border Controller does not include the User-Name AVP in any UDRs. The Oracle Communications Session Border Controller adds the User-Name AVP to the UDR if the user-name-mode parameter in the external policy server configuration is set to:
- endpoint-id—IP address of the registering endpoint is sent as the payload for the User-Name AVP
- public-id—SIP-URI portion of the TO header from the register message is sent as the payload for the User-Name AVP
- auth-user—Username attribute of the Authorization header from the register is sent as the payload for the User-Name AVP; if there is no authorization header, the Oracle Communications Session Border Controller will not consult the CLF and will forward the registration message
Unregistered users—When it receives an INVITE request, the Oracle Communications Session Border Controller checks the incoming SIP interface to determine if it should use an external policy server. If it does not need to use an external policy server, the Oracle Communications Session Border Controller forwards the INVITE message to its destination.
When the Oracle Communications Session Border Controller does need to use an external policy server, it also checks to determine if the INVITE is in a registration and if location data in the registration cache is avaible for that endpoint. These requirements being met, the Oracle Communications Session Border Controller inserts the P-Access-Network-Info header with the location string into the INVITE it forwards to the destination. If these requirements are not met, the Oracle Communications Session Border Controller consults the CLF before forwarding the INVITE. The following describe the impact of the user-name-mode setting in such instance:
- endpoint-id—IP address of the endpoint that issued the INVITE is sent as the payload for the User-Name AVP
- public-id and auth-user—SIP-URI portion of the INVITE is sent as the payload for the User-Name AVP:
  With a P-Asserted-Id header present in the INVITE, the Oracle Communications Session Border Controller uses the first PAID header (if there are multiple PAID headers)
  
  Without a P-Asserted-Id header present in the INVITE’s P-Preferred-Identity header, the Oracle Communications Session Border Controller uses the first PPI (if there are multiple PPI headers)
  
  With neither P-Asserted-Id nor P-Preferred-Identity header present, the Oracle Communications Session Border Controller uses the From header

HA Functionality

The location strings generated by the CLF are replicated on the standby Oracle Communications Session Border Controller in an HA pair. This is required so that a Oracle Communications Session Border Controller in an HA pair can instantly continue processing calls using the previously learned CLF information.