Known Issues

The following table lists Known Issues and provides the Service Request ID number, a description of the issue, any workaround, when the issue occurred, and when Oracle fixed the issue. This table includes issues from previous releases that either remain open or are resolved in this release. Issues from previous releases that do not appear here do not apply to this release. You can also find information about resolved issues in the Build Notes for this release.

ID Number	Description	Found In	Fixed In
27240115	ECB Sync does not take effect. Workaround Reboot the system.	PCZ2.2.0	PCZ3.0.0
No ID number	If you want to establish a High Availability pair that uses IP addresses other than the defaults, perform the following procedure. Use this procedure regardless of whether the ECBs run on virtual or physical systems. The IP addresses you use must be available and valid in your network. If not, you must directly connect the two ECBs before performing this procedure to establish the HA pair initially. Note Primary default—169.254.1.1 Secondary default—169.254.1.2 Procedure Perform the standard HA setup with the run setup command, and allow both systems to come up in an HA pair. From the GUI, go to General, General, High Availability and assign the IP addresses that you want to use to the Primary and Secondary ECBs. Move the wancom1 connection to the network that you want to use. (Either the physical connection, or for VMs, change the vswitch used by the wancom1 interface.) Double reboot both systems, and they will come back up in an HA pair.	PCZ3.0.0	N/A
28314178	When you turn on SIP debugging, you may see various unrelated messages displayed on the console. The messages do not prevent the ECB from generating logs, but they can make the console hard to use. Workaround: Use SSH when you turn on SIP debugging.	PCZ3.0.0	PCZ3.0.0p6
No ID number	If you see mapping errors after upgrading, for example errors about redundancy or media traffic, you may need to swap interface addresses. Workaround: Compare the MAC addresses on your Virtual Machine (VM) to those on your hardware. If the addresses are different, you need to swap interface addresses. Set the addresses on the hardware to match those from your VM. Use the swap command from the ECB command line. Use SSH to access the command line prompt on the ECB. From the ECB prompt type sho interface mapping, and press ENTER. The system displays its mappings. Compare the mappings to your VM mappings. Type interface-mapping, and press ENTER. Type swap <eth-if-name_1 eth-if-name_2>, and press ENTER. Example: swap wancom0 s1p0 The system displays the interface mapping information after the swap and a warning that the change can affect services and requires a reboot. At the Continue prompt, type yes, and press ENTER. Exit the configuration. Reboot the ECB.	PCZ3.0.0	N/A
30576125	The ECB is reporting session limit inaccurately.	PCZ3.0.0	PCZ3.0.0p6

The following Known Issues have been found not to be present in this release. They are collected here for tracking purposes.

ID Number	Description	Found In	Fixed In
28207606	Registrations that expire at the producer are removed from the registration list. Removal happens when the registration of the endpoint is removed at the producer. The registration should be removed from the consumer the next time the two nodes sync registrations. Normal behavior on learned registrations is that an INVITE arriving at the consumer (learned the registration) is forwarded to the producer (of the registration). The producer then forwards the call to the registered endpoint. If the producer no longer has this registration, it will reject the call. Due to this defect, expired registrations are removed by the producer, but they are not removed by the consumer. The result is that the consumer continues to forward INVITES rather than rejecting them locally. At the producer, the expired registration is removed, and the call is rejected with a 4xx response. If the endpoint in question registers with a third ECB (node 3) that is also configured in the sync mesh, that registration is learned by the same consumer ECB. In this situation, both registrations exist in the learned registration database. One of those registrations is used to route a call. The behavior as to which registration is used is undefined. While the desired behavior is to send the call to node 3, the system may choose the stale registration and forward the call to node 2.	N/A	N/A

ID Number

Description

Found In

Fixed In

28207606

Registrations that expire at the producer are removed from the registration list. Removal happens when the registration of the endpoint is removed at the producer. The registration should be removed from the consumer the next time the two nodes sync registrations. Normal behavior on learned registrations is that an INVITE arriving at the consumer (learned the registration) is forwarded to the producer (of the registration). The producer then forwards the call to the registered endpoint. If the producer no longer has this registration, it will reject the call. Due to this defect, expired registrations are removed by the producer, but they are not removed by the consumer. The result is that the consumer continues to forward INVITES rather than rejecting them locally. At the producer, the expired registration is removed, and the call is rejected with a 4xx response.

If the endpoint in question registers with a third ECB (node 3) that is also configured in the sync mesh, that registration is learned by the same consumer ECB. In this situation, both registrations exist in the learned registration database. One of those registrations is used to route a call. The behavior as to which registration is used is undefined. While the desired behavior is to send the call to node 3, the system may choose the stale registration and forward the call to node 2.

N/A