I wrote this a while back and wasn’t sure whether to post it on the forum. It’s long, technical, and honest.
I think we should all try sharing more ideas, and I want to set a good example by being open about the things we do with FreePBX in our businesses. So, here goes:
The Duck Test
Could I configure FreePBX to have all the hallmark characteristics of an SBC?
I’d love to hear your thoughts on an experiment that became our real-world setup.
Kieran
Good job on the solution. For what it is being used for, it looks like a good setup for it. Sadly though, it’s not a duck. It’s not possible for a B2BUA to have the hallmark characteristics of an SBC, specially for Asterisk.
On paper, FreePBX is not an SBC. It is a B2BUA. But the Duck Test applies. If it routes like an SBC, secures like an SBC, and bills like an SBC, then for us it is an SBC. Labels are less important than outcomes.
There’s a few issues here with this statement.
If it routes like an SBC
It doesn’t. It routes like an B2BUA which are fundamentally different mechanisms. Outcome may be the same but how you got there is completely different. An SBC makes a forwarding decision, Asterisk is making a bridging decision. Everything from failover, forwarding and simultaneous calls are handling completely different.
secures like an SBC
Again, does not do that. Some of the “security” is coming from the fact it’s a B2BUA such as hiding topology because it creates new channels and transactions for a single call. It’s not implementing any RFC implementations or privacy methods like an SBC. You can’t detect SIP anomalies, you can’t rate limit by method. Things like iptables/fail2ban etc are outside of the B2BUA as they would be for an SBC.
bills like an SBC
It does not. An SBC would have one CDR per transaction regardless of what happened during that transaction such as calling multiple contacts, call forwarding or any routing failover. The billing solution you created for this is a kludge a digit prefixes to help associate multiple CDR records into a single cal transaction record. It also lacks Spiral CDR transactions which will record a CDR transaction when told for each leg of the call (such as forwarding) so each leg can be billed properly.
Again, what you built is rock solid and based on what I read in the article pretty well designed for what it does. Which is provide workarounds to fill in SBC like feature gaps on a B2BUA where a full feature SBC/class 4 solution isn’t available. Again, awesome job but sadly it doesn’t pass the duck test.
Thanks Tom, I appreciate your feedback.
I accept that a dedicated SBC has specialised functionality, particularly some of the security controls you mention. I wasn’t trying to claim feature parity with a commercial carrier-grade SBC. The question was whether I could configure FreePBX to perform the SBC functions we actually needed for us.
It won’t surprise you to know that, a few months on, I am deep in Kamailio as a major network migration begins to demand more, and I am working on things FreePBX couldn’t get anywhere near. FreePBX does the job for the aggregating call routing described though, and we consider it to be a long-term solution.
For clarification on the billing side: the prefixes aren’t there to associate multiple CDRs into a single transaction. They identify the billing account and originating PBX, which gives me the clean billable record I wanted for an ANSWERED call.
In the context of your B2BUA point, Oracle describes its Enterprise SBC as a B2BUA:
Thanks again for taking the time to read it properly. You’ve given me a few things to think about, which is exactly why I finally decided to post it here for discussion.
This is where labels are important and why I was trying to specify Asterisk vs B2BUA in places. A Back to Back User Agent does originate and re-terminate (like Asterisk) each leg is its own transaction, channel, etc.. Essentially all SBCs are B2BUAs but not all B2BUAs are SBCs.
A true SBC has Proxy Mode and B2BUA Mode and can freely switch between as needed per sip transaction. Something like Asterisk is just a B2BUA. You know when something is just a standalone B2BUA because it requires the transaction to enter the SIP stack and generate an active dialog before you can do anything with the message. Even when you proxy through Asterisk dialogs are being created for it.
An SBC allows you to handle the request/message at the transactional layer before a dialog is even created. This makes it more lightweight, faster and allows for deeper control over the SIP message before the dialog is created like changing To/From/Contact headers, updating the SDP for NAT fixes, rate limiting based on methods, etc, etc.
An SBC lets you deal with routing, billing and security at the transaction level which gives complete control over how the SIP message is handled and avoids entering the SIP stack which can be more expensive to process.
I’d just throw one of dsip, Opensips SBC CE, yeti-switch or possibly Sipwise C5 or ivozprovider Retail in front of several FreePBXs and be on my merry way. I was fortunate to start my FreePBX experience at a business that had a Sansay SBC fronting their FreePBX instances and have not had to ever imagine multiple instances directly exposed to the internet
Yes, there are lots of ways to do it. I have since combined pfSense, HAProxy, WireGuard, Kamailio and Proxmox in another project, where none of the PBXs are exposed to the internet. I’m even developing my own Kamailio frontend for our particular requirement!
At the time, I didn’t want to get stuck into learning anything new, and LLMs weren’t yet mature enough for me to rely on as competent assistants.