Trunk configuration multiples IPs for signalling

[Telcreek]

Hi All. What is the best practice in 3CX v15 for setting up a for example a single DID but with a termination provider that signals on multiple IPs? I am guessing this is most of them but mine in particular signals origination and termination across 3-4 IPs each, primary and backup. I've had little problems with just setting up the primary signalling IPs but it wouldn't be good to miss calls coming in on or going out back-ups. How do others do this or what is the recommended way to capture all signalling across primary and back-up sources?

 

[JasonNadeau]

Set up separate trunks for each IP used. ... with V15 though I think you can only have an incoming rule associated to a single trunk - I'm really hoping 3cx will chime in here and tell me I'm wrong.

 

[craigreilly]

you can set up the incoming DID's 2 ways
1) with the DID phone number as sent
2) with the * before the DID phone number as sent

this should help with the issue of DID assigned to 2 trunks... right?

 

[Telcreek]

Hi Jason, thanks. I experimented with multiple incoming trunks and one outgoing paired with one inbound rule and one outbound rule and ran into a bizarre error after some time. When signalling came from the term provider I would get a busy on the caller end and the logs would post the following error:

"Device callersdid@(Ln.10001@OutgoingTrunk) had no available trunk(s) for Call(XX)"

From docs this is a outbound specific error but it coincides with a incoming call in my case. It's error 12289 here:

https://www.3cx.com/blog/docs/list-of-events-generated-by-3cx-phone-system/

From this it seems like either 3CX or perhaps my term provider was not allowing one or more calls out of the set IP. But why this error on an incoming call is the next mystery, I am not doing any forwarding on this config and it's a little used system, this call was the only one being fielded on this system at the time.

In any event, I wanted to see what others did to make sure it wasn't me doing something strange before I bothered 3CX support.

 

[JasonNadeau]

you can set up the incoming DID's 2 ways
1) with the DID phone number as sent
2) with the * before the DID phone number as sent

this should help with the issue of DID assigned to 2 trunks... right?

I'll try that tomorrow. I thought wildcards were out in v15. If this still works it would indeed help the issue of assigning multiple trunks to a single did. Thanks Craigreilly!

 

[craigreilly]

I'll try that tomorrow. I thought wildcards were out in v15. If this still works it would indeed help the issue of assigning multiple trunks to a single did. Thanks Craigreilly!

All of my inbound DID's are * followed by area code and number. I think because my old provider sent 11 digits. And when we moved to a new provider the DID's were not working. So I tried a * in place of the 1. Later found out they didn't send the 1... but just left them alone instead of removing the *.

 

[JasonNadeau]

Works, thanks for the tip CraigReilly !

 

[Telcreek]

I tried the wildcard Craig, that works for me too, sweet! I've also learned a bit more in the meanwhile. I've had a chance to play with multiple trunks for backup IP signalling with verbose logging on 3CX and tcpdump on Debian. I think I can establish that the first trunk used is the first that matches the DID and then the IP, from bottom to top. I should first say my setup uses IP auth not user/pass. I tested this with the following trunks in this order:
Name Host DID
IN1 z.z mydid
IN2 x.y mydid
OUT x.y 1111

The above trunk setup, incoming calls come in on IP x.y and match mydid, so IN2 is used. If I change the DID field the OUT trunk to mydid, the OUT rule is used for incoming calls. So the bogus '1111' is useful for 3CX to bypass this trunk since no DID match and go up the trunks until the first match. I inverted the Host section for IN1 and IN2 and now see trunk IN1 being utilized on the inbound call. I'd love to force the provider to send signalling on another IP but I'm fairly confident this works.

So now it's clear that 3CX was using my OUT rule before because it was the first trunk that matched my DID and Host both. I had the Allow Inbound Calls Option unchecked on that OUT rule before and while it's obvious why I didn't get an inbound call because of that, I find the error 3CX gave is a bit bizarre.