IP Authentication is the fact of linking a sip extension against a set of known IP's. Therefore, any call signalled to or from a given IP will be linked to a linked SIP account. IP Authentication is needed (not a must) if you want to configure your PBX as a Class 4 PBX. If you want to know more about the difference between Class 4 and Class 5, read the article I published some years ago in this blog.
So, our scenario is our FusionPBX (pbx-b) is the carrier of another PBX (pbx-a). The pbx-a uses pbx-b as a carrier configured without registration (IP authenticated). Users register into pbx-a. When an outbound call is done, the user signals the authenticate INVITE to pbx-a, then pbx-a forwards the SIP INVITE without authentication. Finally, pbx-b forwards the INVITE to the upstream carrier.
FusionPBX by default is shipped as a Class 5 PBX. You will need to do some web tuning to make it work as a Class 4 PBX. In this article, I will write about the SIP Authentication, which is one of the many steps you need to do.
The configuration is pretty straightforward. Let us say you have a brand new deployment and you have configured the customer1.inside-out.xyz tenant with an extension pbx1 (I recommend using alphanumeric extensions when dealing with Class 4 PBX configuration).
Within FusionPBX WEB GUI go to menu Advanced -> Access Control and create/edit the domain ACL. Add in that ACL the following rule:
Leave the CIDR field blank.
Edit the pbx1 extension and modify the CIDR field. Put all the IP's you now this extension will be using in CIDR format. Use a comma to specify more than one.
You are done. In your other PBX configure your FusionPBX as a carrier without registration. You may need to restart your freeswitch since the SIP Profiles will need to reapply the ACL. And yes, if you were wondering, with this approach you can have some tenants acting as Class 4 PBX and others as Class 5 PBX.
That is a really good question. Let's try to answer it.
When you do an inbound route (FusionPBX) that forwards directly to another number using the bridge command, you are not processing the dial plans that give FusioPBX all the necessary context to process your call correctly. For example, the domain_name variable will never be set, the context variable will remain as public and many other GUI options such as the call recording, time conditions, blacklists and the call direction won't apply. Also, billing with this approach it is a challenge.
Finally, FreeSWITCH 1.8.7 is available in an easy way for non-Debian users (aka CentOS). Today, I have published in OKay's RPM repository RPMs for FreeSWITCH 1.8.6. FreeSWITCH is a complete VoIP switch that works on many platforms, including CentOS 6 and CentOS 7. This is one of the biggest packages I have ever done; there are more than 1800 hours of work behind to make it work (mainly because of the CentOS 6 support). When updating, you will notice it will download many libraries, most part of them not available anywhere.
In addition, these RPM's have a patch that allows the console to filter by a regular expression. If you do VoIP debugging, you will understand right away what I am talking about.
Since this release, my RPM is going to be linked against tcmalloc. Release 1.8.7 focuses its bugfixes on the conference module, if you are a heavy conference user then you may be interested in updating your server.
Voxout it is the trunk service that Voxbone offers to make outgoing calls and emergency ones. I must say it is tricky to configure it, the PDF they give as a tech guide is next to useless and so far, if you google, you won't find any example of FreeSWITCH gateway configuration with Voxout. I will talk about how I did it.