2 New Features in Communications Broker Release 4.2.0

The Communications Broker Release 4.2.0 delivers the following enhancements and new features to improve the functionality, look, and behavior of the software.

Table 2-1 New Features

Feature Description
Support for FQDN for LDAP configuration This feature allows Communications Broker to support FQDN LDAP server configuration. The FQDN is further resolved into an IP address. Communications Broker supports both A and SRV FQDN configurations. Communications Broker resolves the IP addresses using the default realm. The resolved IP addresses are used for identifying LDAP servers. This feature provides the flexibility of managing multiple LDAP servers based on LDAP load balancing for A Records, weights and priority for SRV Records. You can modify the LDAP servers where servers can be added or dropped. This makes it easy to support multiple LDAP servers across different LDAP configurations.
Support for deployment on public cloud - AWS and Azure With Communications Broker Release 4.2.0 you can deploy Oracle Enterprise Communications Broker on the Azure and AWS environments.
OJET uplift (15.1.3), and Web GUI enhancements The Communications Broker Release 4.2.0 user interface has been upgraded to OJET version 15.1.3 to provide an interactive and seamless user experience.
Naming abbreviation update for Communications Broker As part of the organization-wide effort to use only the officially approved product names, the usage of the product name has been standardized across GUI, product documentation and Marketing collateral.
REST API Support for Communications Broker dialing context This feature supports CRUD operations using REST API on the Dial Plan configuration which can be done easily and the response can be verified at the same time. Both Dialing Contexts and Dial Pattern can be viewed, modified, added or deleted using the REST commands. REST API integration is supported on enabling secure HTTPS, making it more reliable and secure to configure Dial Plan parameters.
REFER source agent routing on Communications Broker Release 4.2.0 This feature when enabled, sets the source agent of the INVITE that Communications Broker creates when terminating the REFER, to the agent that sent the REFER message and NOT to the agent from which the original call was received from.

When you disable the refer-source-agent-routing, the look-up is based on the Source Agent of the Calling Party.

However, the headers of the new INVITE do not change. The overall call flow remains similar, except for the modification of the Source Agent as described above.