SIP Configuration
You must ensure there are both sip-interface and sip-config SIP configurations operating on the Oracle Communications Session Border Controller (OCSBC) for it to participate as a member of an Oracle Communications Subscriber-Aware Load Balancer SLB cluster.
With respect to the sip-config, the SLB uses your hostname setting as the identification of the OCSBC, for example, within its show commands. This allows you to segregate individual OCSBC behavior on the SLB. In many cases, administrators have already configured an OCSBC hostname for other purposes. This setting must be unique on each OCSBC.
westy# configure terminal
westy(configure)# session-router
westy(session-router)# sip-config
westy(sip-interface)# select
westy(sip-interface)# sip-config
westy(sip-interface)# hostname SLB-member1
In a traditional 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 SLB service-port advertised on the access network. The process of encapsulating the packets between the SLB 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 SLB cluster and register the service port 10.0.0.1:5060/UDP as the realm LosAngeles with the SLB. The SLB 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 SLB, with no explicit configuration required on the SLB whatsoever.