In a traditional Oracle Communications Session Border Controller (OCSBC) configuration the IP address assigned to a sip-port configuration element is contained within the address space defined by the network interface netmask. This is not be the case for clustered OCSBCs. Rather, the IP address assigned to the sip-port is identical to the address of an Oracle Communications Subscriber-Aware Load Balancer (OCSLB) service-port advertised on the access network. The process of encapsulating the packets between the OCSLB and OCSBC masks the fact that the IP address the OCSBC expects to receive IP packets on is different than the Layer 5 address the OCSBC expects the SIP address on.

Consistency of realm identification is vital to successful and predictable policy-based load balancing. Take particular care to ensure that the realm-id of the sip-interface configuration element mirrors the lb-realm assignments made while configuring distribution rules. See the Distribution Policy Configuration section.

In the following configuration example, the realm-id is LosAngeles. This OCSBC, when booted, will detect that it is a member of an OCSLB cluster and register the service port 10.0.0.1:5060/UDP as the realm LosAngeles with the OCSLB. The OCSLB will automatically create the OCSBC group LosAngeles (if it doesn’t exist) or join the OCSBC to the group LosAngeles (if it is not the first to advertise LosAngeles). Policy statements that direct packets to LosAngeles now consider this OCSBC as a potential destination, assuming the address:port/protocol also are consistent with the policy’s matching criteria.

This technique allows you to configure the same IP:port/protocol on multiple OCSBCs, with different realm-id labels, to indicate priority of one OCSBC or group of OCSBCs over another. As an example, consider several OCSBCs geographically situated together with the label LosAngeles, and several other OCSBCs geographically situated elsewhere with the label NewYork, all with the identical SIP interface and SIP port configuration. A policy can be easily defined to give preference to a source subnet of users in California to the LosAngeles member OCSBCs, with NewYork as a second priority. This provides flexibility in network design without undue burden in the configuration: OCSBCs’ tagged with the same realm name are joined in dynamically created OCSBC groups by the OCSLB, with no explicit configuration required on the OCSLB whatsoever.