1. User's Guide
  2. ECB Sync

14 ECB Sync

The Oracle Enterprise Communications Broker (OECB) allows you to configure multiple OECBs to interact with each other and share operational information. This functionality, called ECB Synchronization, works like layer-three routers dynamically exchanging routing information. This results in extensible OECB deployments where any OECB can use information from a peer OECB to make a routing decision, including simply forwarding to that peer so that it can perform the routing.

ECB sync uses the Cluster Network Protocol (CNP). OECBs configured for synchronization share the following information:

  • User database
  • Routes
  • Dial plan
  • Agents

ECB sync shares information between OECBs configured as pairs, where a transmitter sends to a receiver. The receiver updates its configuration with data from the transmitter. Categories of information exchanged include:

  • Routing information - how to reach a destination.
  • Context information - how to handle a given endpoint.

ECB sync configurations begin with establishing peers. Peers can operate as:

  • Transmitter—Provides its peers with its information.
  • Receiver—Uses the information received from a transmitter to extend its operational scope.
  • Both Transmitter and Receiver.

Any OECB can peer with up to 10 other OECBs. A transmitter can provide its information to no more than 10 receivers. A receiver can obtain information from no more that 10 transmitters.

ECB Sync uses SIP SUBSCRIBE to establish relationships and exchange data. The system never displays the data in SIP SUBSCRIBE traffic in clear text, providing a layer of obfuscation. The system also uses SIP Digest authentication for authentication and authorization of peers. Optionally, you can configure TLS to secure ECB Sync traffic.

As soon as you add agents to the ECB Sync agent list and the configuration activated, the OECB begins to send SUBSCRIBEs to its Sync agents. Subscriptions, subscription refreshes, and subscription termination all follow standard SIP procedures. Transmitters use NOTIFYs to send information to receivers. The process can use multiple, concurrent NOTIFY messages if the amount of information in the NOTIFY exceeds maximum payload. The transmitter also compresses information. The receiver un-compresses information.

Detail on transmitter/receiver interaction includes:

  • The transmitter sends only its own configuration data, not data learned from another OECB.
  • The transmitter updates all of its receivers with full configuration information upon an activate if any applicable configuration information has changed. Changes, for example, to a network interface would not trigger an ECB Sync update.
  • The receiver's subscription refresh interval is 1/2 the expires time (30 seconds). This timing is not configurable. If the transmitter does not receive any refresh within the expires time, it terminates the subscription.
  • The transmitter does not send subsequent NOTIFY messages without positive confirmation of the previous NOTIFY by the receiver.
  • The receiver re-sends unanswered and rejected SUBSCRIBE messages in 60 second intervals until it receives a response.
  • The transmitter cancels all NOTIFY procedures upon receipt of an error message from the receiver. When this happens, the receiver restarts the NOTIFY process from the beginning. The transmitter makes this additional attempt to resend the configuration/user data only once if it receives such an error.
  • When the receiver encounters an unrecoverable error, it discards all information previously learned from the transmitter, cancels the subscription, and initiates a new subscription.
  • The receiver un-subscribes from a transmitter gracefully upon activation of a configuration change that removes that transmitter from the receiver's list.

The OECB secures SUBSCRIBE and NOTIFY transactions using SIP Digest procedures. The transmitter challenges the receiver upon receipt of a subscription. Using SIP Digest, the receiver replies to the challenge with standard SIP Digest user, realm, and password hash for the transmitter to verify. ECB sync configuration includes specifying the secret to use for the password. You must configure all receivers and all transmitters to use the same secret for this purpose.

The receiver tracks ECB sync information, differentiating between its own configuration and that of each transmitter. Grouping sync information by its source allows the receiver to discard the correct information if a transmitter becomes unreliable or invalid. The receiver also uses this grouping to prioritize overlapping configuration information. Overlapping configuration objects include those using the identical key. The rules include:

  • A receiver uses it's own object if it is in the running configuration.
  • If multiple transmitters provide information on the same object, the receiver uses transmitter name alphabetical order to determine which information to use.

Receivers keep all objects from all sources in memory should the source in use become invalid.

Note that all transmitters and receivers must use the same CNP version to operate properly. If a receiver gets CNP data from a higher version, it returns a 489 "Bad Event" error and drops the payload.

Note:

After you configure ECB Sync, you must reboot the system.

ECB Sync and High Availability

A receiver updates its standby OECB with ECB sync data and status. If an active OECB stops responding, the standby becomes available for immediate use as a receiver. Conversely, if a transmitter transitions from active to standby, the receiver assumes its subscription is still valid until it refreshes and receives a 481 error message. Upon receiving the 481 message, the receiver terminates the existing subscription and starts a new one with the new active. Note that the receiver retains learned configuration information despite the subscription change.