You can test against any channel variable in the dialplan, not just the destination number. It sounds like a shady workaround, but you could test for a unique information element sent by the remote VoIP device in the public dialplan, then if it matches transfer it to the desired (default, I imagine?) dialplan along with the destination number. This is the way I handle incoming calls from my VoIP provider on my home FS box, along with a few other tests for security and sanity preservation. <extension name="CallCentric inbound"> <condition field="${sip_to_user}" expression="^(12024561000)$"> <action application="transfer" data="target-nummer XML default"/> </condition> </extension> Where sip_to_user is *my* number, in other words the number that the caller dialed to reach me. Then I have an extension in the default dialplan that looks for “target-nummer” and routes it to a bunch of phones in my house. In your case I’m guessing you would probably want to change target-nummer to a variable that contains what the remote phone actually dialed. FS is very flexible in this way. Just make sure you test enough conditions that only the desired remote VoIP device can route to the default dialplan this way and you should be fine. FWIW, I have never been able to figure out the ACL system in FS. It has some unexpected interactions, notably with the status subscriptions so I just went back to the conventional challenge/authentication system so that it works as expected. Sometimes I think it helped to stop and restart FS rather than just issue the reloadacl command sometimes. Hope this helps. John Boteler Bote Communications From: Martyn Davies Sent: Tuesday, 5 January, 2021 06:32 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: [Freeswitch-users] Automatically authenticating client I'm trying to support a downstream client (actually a phone on a VoIP gateway) that must work without sending a registration to Freeswitch. I have a definition in the client directory that looks like this: <include> <user id="0101" cidr="192.168.1.0/24 <http://192.168.1.0/24> "> <variables> : <variable name="user_context" value="default"/> So, I'm assuming that if the source address matches 192.168.1.x, an invite from 0101 will automatically be authenticated, and the user context will be set to 'default' to go through the dialplan. However, what seems to happen is that the dialplan gets executed in the public context, 0101 doesn't match anything, and so the call fails. I also tried adding entries to the acl.conf file, e.g. e.g. <list name="lan" default="allow"> <node type="allow" cidr="192.168.1.0/24 <http://192.168.1.0/24> "/> </list> or <list name="localnet.auto" default="allow"> <node type="allow" cidr="192.168.1.0/24 <http://192.168.1.0/24> "/> </list> or adding an 'allow' line to the existing 'domains' list. When I run 'reloadacl', it looks like the rules are being picked up, e.g. 2021-01-05 11:06:07.631090 [NOTICE] switch_utils.c:642 Adding 192.168.1.0/24 (allow) [] to list localnet.auto 2021-01-05 11:06:07.631090 [NOTICE] switch_utils.c:642 Adding 192.168.1.97/32 <http://192.168.1.97/32> (allow) [0101@192.168.1.241 <mailto:0101@192.168.1.241> ] to list domains However, none of this works, and I still end up in the public context when a call is placed. I would appreciate any examples or advice that people could offer to get my client authenticated, or could anyone give me pointers on how to debug the authentication process when the invite arrives? Regards, Martyn