<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1242177642;
mso-list-type:hybrid;
mso-list-template-ids:1741991244 1732517832 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-style-link:botelist;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:40.5pt;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:76.5pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:112.5pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:148.5pt;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:184.5pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:220.5pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:256.5pt;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:292.5pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:328.5pt;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>You can test against any channel variable in the dialplan, not just the destination number. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:Consolas'><extension name="CallCentric inbound"><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:Consolas'> <condition field="${sip_to_user}" expression="^(12024561000)$"><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:Consolas'> <action application="transfer" data="target-nummer XML default"/><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:Consolas'> </condition><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:Consolas'></extension><o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Where sip_to_user is *<b>my</b>* 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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Hope this helps.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:10.0pt;color:#7F7F7F'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;color:#7F7F7F'>John Boteler<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;color:#7F7F7F'>Bote Communications</span><span style='font-size:10.0pt;color:#7F7F7F'><o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Martyn Davies<br><b>Sent:</b> Tuesday, 5 January, 2021 06:32<br><b>To:</b> FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org><br><b>Subject:</b> [Freeswitch-users] Automatically authenticating client<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I'm trying to support a downstream client (actually a phone on a VoIP gateway) that must work without sending a registration to Freeswitch. <br>I have a definition in the client directory that looks like this:<br><br><include><br> <user id="0101" cidr="<a href="http://192.168.1.0/24">192.168.1.0/24</a>"><br> <variables><br> :<br> <variable name="user_context" value="default"/><br><br>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 <br>be set to 'default' to go through the dialplan.<br><br>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.<br><br>I also tried adding entries to the acl.conf file, e.g.<br><br>e.g.<br> <list name="lan" default="allow"> <br> <node type="allow" cidr="<a href="http://192.168.1.0/24">192.168.1.0/24</a>"/> <br> </list> <br> <br> or <br> <list name="localnet.auto" default="allow"> <br> <node type="allow" cidr="<a href="http://192.168.1.0/24">192.168.1.0/24</a>"/> <br> </list> <br> <br>or adding an 'allow' line to the existing 'domains' list.<br><br>When I run 'reloadacl', it looks like the rules are being picked up, e.g.<br><br>2021-01-05 11:06:07.631090 [NOTICE] switch_utils.c:642 Adding <a href="http://192.168.1.0/24">192.168.1.0/24</a> (allow) [] to list localnet.auto<br>2021-01-05 11:06:07.631090 [NOTICE] switch_utils.c:642 Adding <a href="http://192.168.1.97/32">192.168.1.97/32</a> (allow) [<a href="mailto:0101@192.168.1.241">0101@192.168.1.241</a>] to list domains<br><br><br>However, none of this works, and I still end up in the public context when a call is placed.<br><br>I would appreciate any examples or advice that people could offer to get my client authenticated, or could anyone give me pointers on <br>how to debug the authentication process when the invite arrives?<br><br><br>Regards,<br>Martyn<o:p></o:p></p></div></div></body></html>