Duplicate DIDs across multiple trunks no longer working in V20 U3

[SebBNE]

Have noticed that in V20 U3 Alpha if you have duplicate DIDs across multiple trunks (load balanced trunks) that you can only assign one to an extension or queue, and the other can no longer be assigned. Going from V20 U2 to U3 seems to unbind all the duplicates and the only work around is to put a leading * to make it slightly different and then rebind all the DIDs. Have verified this on two different 3cx boxes running V20 U3.

Anyone else having this issue? Concerned all the other 3CX running V20 U2 we have will break when U3 rolls releases.

 

[mattdarnell]

Not an answer to your problem but, are the 2+ trunk coming from the same carrier? Do you have some magic to load balance a single DID between multiple carriers?

 

[YiannisH_3CX]

Hello @SebBNE

We are currently looking into this so thank you for reporting.
How did you update from SP2 to SP3? Did you upgrade directly or did you use backup and restore? Also what do you mean by unbind all duplicates? They are visually no longer bound or the functionality broke?

 

[SebBNE]

Thanks! Upgrade was performed through the normal update method within 3CX. At first, I thought it was visually, but it actually removes the duplicate DID and it seems to choose at random which trunk it unbinds from. Sometimes it will visually show both are bound but when you go into the DIDs on the trunks you can see only one of the trunks will actually have a destination on the DID.

 

[YiannisH_3CX]

Thank you for the clarification. We will investigate this and let you know once we have an update.
Again thank you for reporting.

 

[VoIPTools]

I'll point out that there is a "beta" version available now.

 

[SebBNE]

I'll point out that there is a "beta" version available now.

Can confirm this is also affecting the beta version - Version 20.0 Update 3 (Build 762 Beta)

 

[SebBNE]

Thank you for the clarification. We will investigate this and let you know once we have an update.
Again thank you for reporting.

Looks like the U3 RC (Version 20.0 Update 3 (Build 786 Beta)) fixed the issue, thanks!