Issue with two SIP Trunks

[Juggyluggs]

Hello,

Basically trying to get an additional SIP trunk added into our 3cx console.

Now to bare in mind both are by the same provider iHub with the same SIP Server and port (might cause issues?), and we have different external IP address for each SIP trunk.

When we input the new one and require registration for incoming calls we then can't make external calls, but can call in.

Kinda new to 3cx as never really used it in anger before so any help or guidance would be worth while.

Thanks

 

[craigreilly]

Did you change any of the outbound parameters? I had this issue when I changed the From: User Part to change the caller id - suddenly it failed.
Luckily my provider had another switch we could use.

 

[lneblett]

Do I understand that you have two Public IPs at the 3CX site so that each provider is using a different one? Or, do you mean that the provider has given you an IP for each? I currently believe the first rather than the latter.

 

[craigreilly]

Good catch Larry... How would you even force 3cx to use a different NIC for each VoIP account and have this different NAT?

 

[Juggyluggs]

Yes so basically we have two public IP's and the same provider and each SIP Trunk is on a different public IP to each other

 

[lneblett]

I do not think this will work. The issue is that the interfaces used by 3CX allow for a single private IP and a single public IP (of FQDNs). The issue is that when the calls are being set up, and 3CX responds with the SDP messages, it will only be able to use the one that was established when the system was installed. I think the issue will be the pubic IP that 3CX is programmed to use.

You will need to get a wireshark capture and see how the SIP messages and associated RTP/SDP is being formed for each Trunk for both inbound and outbound calls.

My guess is that when you make an external call, the 3CXsystem is setting up the call and using the attributes that it knows which is not compatible with the provider. However, when the provider originates the call, then 3CX is getting the attributes from that source and is able to accommodate.

A wireshark will definitely help.

 

[Juggyluggs]

I shared the same thoughts as yourself as when looking through 3cx i could see that only one IP was mentioned which is obviously which one of the SIP trunks is running off.

So my fears are confirmed assume if i place them both on the same public IP then we will be able to rock and roll correct?

Thanks

 

[craigreilly]

in a perfect world - yes.
We all know this world isn't perfect.... but you should be ok in this regard.

 

[Juggyluggs]

Thanks for all the help much appreciated

 

[tsukraw]

We have ran into this issue multiple times on customer installs where they have 2 ISPs and want to use 2 ISPs for fail-over.
3CX does not have a way to handle this....
I mentioned it earlier today on another post. We have moved everything dealing with SIP Trunking over to using a true physical SBC. Not the 3CX software which is not a true SBC.
We are using Sangoma units. They came out with a new unit a few weeks back geared towards SMB that has all the enterprise features but not the enterprise price like they used to have.

With a Sangoma units they have 4 Ethernet ports. You can assign them however you like.
So port 1-LAN port 2-WAN port 3-WAN2.
The unit acts as a SIP Agent.
So a "Agent" connects from Sangoma to 3CX"
Agent from Sangoma to Trunk 1 over WAN1
Agent from Sangoma to Trunk 2 over WAN2

You then on the sangoma are able make Call Routing plans.
So you can pre-define call routing to trunks with rules.
So what happens is for a outgoing call 3CX to SBC / SBC tries to deliver call with rule 1 (Deliver call through Trunk 1-WAN1) if fail (Deliver call through trunk 2-WAN2).

Depending on your carrier the reverse could work for incoming calls. Take NexVortex for example. With them you can specify a failover IP (DR Routing). So NexVortex tries to deliver the call to use by our WAN-1 External IP. If that fails they automatically try to deliver the the call to our secondary WAN-2 IP addres.

I think that is what the end result you are looking for is correct?
I attached the diagram i use to kind of explain it.