Enabling IP Authentication in FusionPBX

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.

Configuring IP Authentication in a Multitenant FreeSWITCH (aka FusionPBX)

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).

Create the ACL

Within FusionPBX WEB GUI go to menu Advanced -> Access Control and create/edit the domain ACL. Add in that ACL the following rule:

• Type: allow
• Domain: customer1.pbx-inside.xyz

Leave the CIDR field blank.

Link the IP with the SIP User

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.

Why I need IP Authentication Instead of Forwarding directly with a Bridge Command?

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.

Good luck!