Use of "Match (Permit)"

For our remote Agents, we previously setup their extensions with CHAN_SIP and using the FreePBX GUI, under the “Advanced” tab, set the “Permit” to be their IP address thereby preventing the phones from logging into the PBX from other locations.

Now our remote Agents are using PJSIP and using the FreePBX GUI, under the “Advanced” tab there is no “Permit” field but there is a “Match (Permit)”.

How does this “Match (Permit)” work? Does it serve the same function as the prior “Permit” field under CHAN_SIP?


Pjsip has the same permit/deny functionality as chansip, but with pjsip it’s not configurable from the GUI.

The “match” field allows Asterisk to determine what endpoint an incoming packet is coming from.

Issue tracker for enhancement:

Adding permit/deny:

I found that if the remote Agent’s IP address is not added to the firewall their phone will not operate. Is that not as effective as the CHAN_SIP permit/deny?

That seems to be a pretty good level of security or am I being naive?

This is not entirely accurate. The Deny/Permit sections for PJSIP are not configurable in the GUI, this part is true. However, they do not work the same as Chan_SIP. The Deny/Permit options are in the ACL section of PJSIP and it applies to all inbound SIP requests regardless of endpoint. It also has a deny_contact/permit_contact option that lets you Deny/Permit based on the Contact header vs the source IP.

Match is from the Identify section in PJSIP, this is PJSIP’s equivalent of Chan_SIP’s host= setting. These are the IPs/hostnames/subnets that the endpoint will accept requests from an identify to a particular endpoint. There is also the match_header option in the this section (not configurable in the GUI) that will let you match against custom headers.

So when ITSPs like Twilio or Flowroute have a /28 or /29 for their incoming POPs the Match section is where you would put that /28 or /29 or both. You could have both Twilio and Flowroutes subnets in the match= setting and use a single endpoint (trunk) to accept incoming calls from both of them.

Additionally, you have to tell the endpoint how it identify’s itself and the default settings (for extensions) are username,ip this means that the user/domain is checked first followed by the ip in the match= setting.

So the Deny/Permit are the same as they deny/permit source IPs but it’s not a per endpoint setting and impacts all incoming requests.

Hi Jeff:

When you add a ‘permit’ IP to a chan_sip extension, that IP can only register to that one extension. When you white list a user’s IP in the firewall, you effectively grant permission for that IP to register to any peer on the system. Since you typically have a SIP secret associated with each extension, and you would typically not share SIP secrets to more than a single extension with your users, the distinction is moot.

If you’ll accept the argumentum ad populum rhetorical fallacy, my experience is that virtually no PBX admins use permit/deny filters at the extension level for security, and instead rely on a firewall.


Not only do I accept the argument to the people - I teach it to my kids all the time.

Perfect !!!

And the crowd goes wild. Enjoy the day

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.