Search results

Was all working Monday morning after they told me they couldn't see anything wrong. I'm blaming the carrier!

I have passed this to the carrier as a SIP trunk from them on a different SBC cluster behaves as expected, with an identical configuration. So pretty sure this is their issue.

I am using inbound routes with a regex to catch the destination number and then bridge the call to a downstream PBX, like this: action bridge sofia/internal/$1@172.18.20.5 I have found that there is no ringback in this scenario. I just get silence from the outside, then it...

Is it? To me, the most readable approach would be one inbound route for each thing that I want to route calls to, with one number per line. It sounds like agree's approach would achieve this. For some context, this is a PBX and SIP trunk consolidation project. The inbound route is not sending...

I need to apply a destination number condition to route a long list of numbers with no obvious pattern. So I could cram them all in to a single regex like condition destination_number ^(01324334832|01742743501|01550239421)$ but it's going to be unreadable [at least 15 numbers...

https://www.pbxforums.com/threads/installation-on-debian-12.7139/ You using Debian 12 by any chance?

Just tried again on another instance of Debian 12, and it clearly says "Correct CPU and Operating System detected". It attempts to install PHP 8.1, which isn't available. So no, not ready for Debian 12 yet.

Can I assume that installation on Debian 12 is not possible yet? I have attempted this and the script "finishes" but it doesn't work. There are no Freeswitch or PHP binaries, tables missing, etc. Small snippet: resources/finish.sh: 55: /usr/bin/php: not found ERROR: relation "v_domains" does...

So what was the problem?

I know FreeSWITCH must be sending the packets out with the right L3 source IP, because if it wasn't, the firewall wouldn't be NATing the packets to the correct public IP, and if it didn't NAT the packets to the correct L3 IP then Gamma would be sending back a 403 and nothing would work.

I don't lack for hatred of NAT, but NAT actually makes things simpler in this scenario. I am not likely to ever need to try this with actual public IPs on the server running Fusion, but I can't think of any obstacles here - surely everything you need is handled by the abilities of the SIP profiles?

To fill in some potential blanks: The firewall has static routes to the Active SBC and the Standby SBC out of the appropriate WAN The Active Gateway configuration has the external-Active SIP Profile assigned so it knows which IP to talk out of when speaking to the Active SBC, the Standby...

Thankfully not, or it wouldn't work!

Here is how I handle something vaguely similar to what you are doing. Some notes about the scenario: The provider I'm using [Gamma Telecom] only offer IP authentication The provider gives me an Active and a Standby SBC to send/receive calls from My server is always NATed by a firewall that...

They tell me that they send us a 404 because that's what they got from their next hop. Their techs tested it and find that when it works, it works, but when it doesn't work, it always goes from 180 to 404 after exactly 15 seconds so they suspect something misconfigured on the destination phone...

No, it's not causing a problem, yet, but the the carrier's intention is that we only use the two SBCs in an active/standby fashion. It's more a case of technical fussiness on my part. Yes it's the UK. The carrier [Gamma Telecom] lets you choose what format to send calls in. I will ask them...

Have an outbound route [and this is the sole outbound route] programmed thusly: Gamma_MSX17 is the active peer and Gamma_MSX9 is the standby. Gamma_MSX17 has ping enabled and the idea is that MSX17 will be used all the time, and MSX9 only gets used if MSX17 has failed. What I can see in the...

What small systems have people got Fusion working on? I am thinking no-moving-parts hardware here. Obviously this would mean living within your means - no call recording or transcoding, for example. Rack mount would be great. Some hardware that I think could work: PC Engines APU2 - 1GHz quad...