3CX V20 Trunk Call Routing

[chrism_ctai]

I've had multiple trunks running with the same registrar / server working for a while in V18. Since V20, I am unable to run multiple trunks going to the same SIP server without 3CX appearing to get 'confused' and routing calls all through the same trunk and destination regardless of the authentication ID and password, and main trunk number.

For instance:
Trunk 1, has a server of sip1.pstn.twilio.com,
Username1 and Password1 as the authentication, and this supposed to be routing to ext. 1000

Trunk 2, has a different number, but the same server of sip1.pstn.twilio.com.
It has a different username and password, and supposed to route to ext. 1001.

Trunk 2 was created after 1, and therefore now seems to 'overrule' and all calls to the number on trunk 1 will now go to the settngs on trunk 2.
I suspect this is a bug. Creating a trunk with a different server address will work.

Could anyone provide more information or a solution, if I am doing something wrong, or if you need more information.

Help is appreciated.

 

[randybell]

Did you ever get this resolved? I just ran into this exact issue when I added 2 voip.ms trunks. I haven't figured out a way to fix it besides merging the accounts on the voip.ms provider side.

 

[chrism_ctai]

Unfortunately not I'm afraid. Me and couple engineers looked at this for a couple days for a way around it or a solution but the issue I suspect is likely a bug on 3CX's side, which they have still not addressed.

This is especially annoying given the removal of explicit inbound rules, and it appears 3CX may be matching the destinations for trunks based on the Trunk Address, hence why the newest one takes priority.

It's interesting to see other people with this issue. For now the only solution we found was to use a different host name for each separate trunk.

There may be another way to solve this but I'm unsure as of right now.

 

[Guillaume Bourgeois]

We should analyze the traces, but I'm convinced that it is related to rinstance.

The SIP provider must support rInstance. Therefore, to verify that the provider supports it correctly, we would need to analyze the rinstance value sent by 3CX during the registration and compare it with a received SIP INVITE, which should contain the same value.

If this is not the case, it explains everything.
This is not a bug. It is a requirement from 3CX.

https://www.3cx.com/docs/supported-sip-trunk-requirements/#h.bk1jnv6eqwu8


This is one of the excellent reasons to use providers supported by 3CX.

Take the example of Voip.MS ... is supported provider.
They are well aware of the requirements of 3CX.
They are compliant; you just need to follow their instructions.

https://wiki.voip.ms/article/3CX_StartUP

Isn't that great?
Long live the providers supported by 3CX.

I searched on Twilio's website. I couldn't find this information ( rinstance ).
But believe me, if they are not compliant with 3CX's requirements, they will need to be. If they don't, they could lose their privileges of being listed as a supported provider by 3CX. Well, I admit these are assumptions because, so far (and probably forever), I'm not included in their internal meetings! However, I have my passport, and I wouldn't refuse to participate in 3CX meetings in Cyprus, if everything is paid for. Well, I must be back before 10 PM, as my wife imposes a curfew on me.