<div dir="ltr"><div>So, is it fair then to make the definition that the default context is best for calls that are considered outbound and that public is best for inbound?</div>
<div> </div>
<div>If that is the case, then can I lobby to have the public.xml also include a line maybe like:</div>
<div> </div>
<div><X-PRE-PROCESS cmd="include" data="public/*.xml"/><br></div>
<div>and then I would drop in my provider DID stuff in there?</div>
<div> </div>
<div>Secondly, can I get the additional logging element (bullet point #3)?</div>
<div> </div>
<div>Lastly, regarding the windows build, is that a known issue or should I hunt it down?</div>
<div> </div>
<div>Thanks!</div>
<div>Christian<br></div>
<div class="gmail_quote">On Thu, Sep 18, 2008 at 9:09 AM, Brian West <span dir="ltr"><<a href="mailto:brian@freeswitch.org">brian@freeswitch.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div style="WORD-WRAP: break-word"><br>
<div>
<div class="Ih2E3d">
<div>On Sep 18, 2008, at 5:24 AM, Christian Jensen wrote:</div><br>
<blockquote type="cite">
<div dir="ltr">
<div>Hi everyone,</div>
<div> </div>
<div>I am in the process of doing something very straightforward - hooking up a DID from Link2Voip into my FS instance (built from SVN Curent on Debian)</div>
<div> </div>
<div>In an effort to only change as little as possible to get this baby to respond to a phone call, I have simply added my provider into the /conf/sip_profiles/external and also added in the extension file into /conf/dialplan/extensions</div>
<div> </div>
<div>I am able to get the system to Register and I am also able to get an incoming call - however that is where the fun stops.</div>
<div> </div>
<div>I hit F8 on my console and this is what I got:</div>
<div> </div>
<div>2008-09-18 02:11:38 [INFO] mod_dialplan_xml.c:228 dialplan_hunt() Processing 6044880583->18665780244 in context public
<div>2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions ${unroll_loops}(true) =~ /^true$/</div>
<div>2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions ${sip_looped_call}() =~ /^true$/</div>
<div>2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:115 parse_exten() Regex mismatch</div>
<div>2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions destination_number(18665780244) =~ /^(10[01][0-9])$/</div>
<div>2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:115 parse_exten() Regex mismatch</div>
<div>2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions destination_number(18665780244) =~ /^(5551212)$/</div>
<div>2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:115 parse_exten() Regex mismatch</div>
<div>2008-09-18 02:11:38 [INFO] switch_core_state_machine.c:114 switch_core_standard_on_routing() No Route, Aborting</div>
<div></div></div>
<div>I <em>think</em> I understand what is going on here - but I <strong>disagree</strong> with defaults.</div>
<div> </div></div></blockquote>
<div><br></div></div>
<div>This is because the inbound call hits the public context NOT default. It wouldn't be wise to open up your default context to the world for anyone to hit. If you add your extension to dialplan/public.xml and transfer it into the default context this would work perfectly. We have a diagram on the wiki that explains the security model. If you notice it says clearly in the line "Processing 6044880583->18665780244 in context public". Everything you put in the extensions folder is processed and added to the default context.</div>
<div class="Ih2E3d">
<div><br></div>
<div><br></div><br>
<blockquote type="cite">
<div dir="ltr">
<div>For most users, I would expect them to do exactly what I just did - try to change as little as possble and only add files as needed. </div>
<div> </div></div></blockquote>
<div><br></div></div>
<div>That is inbound vs outbound and the way its setup by default so you don't open your dialplan to toll fraud. </div>
<div class="Ih2E3d">
<div><br></div><br>
<blockquote type="cite">
<div dir="ltr">
<div>So finding that the initial root of the dialplan matching happens within public.xml, I attempted to see if there was a better regex match (better than the 5551212 :) and tried ^\d{10,15}$ - basically any number between 10 and 15 digits, good for most of the planet generically. I got no matches, so I though maybe the syntax was strange and went for something simpler - ^[0-9]{10,15}$ - still no matches. Then I brute forced it - ^(18665780244)$ - got a match! yay! - Fun stops again :(</div>
</div></blockquote>
<div><br></div></div>
<div>You need to understand that inbound calls should NEVER hit default. You should always have inbound and outbound in different context's. Think of it as a sandbox so you can control security.</div><br>
<blockquote type="cite">
<div class="Ih2E3d">
<div dir="ltr">
<div><br></div>
<div>So as a Recap, here is what I would like to have changed if possible:</div>
<ol>
<li>A better regex for the default DID install</li>
<li>Fix the regex on the enum extension OR remove it OR Better documentation surrounding the name of a file for custom extensions</li>
<li>It would be awesome to see the dialplan hunt debugs indicate the name of the extension of the match it is currently looking at, for example</li>
<ul>
<li>2008-09-18 03:08:28 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions destination_number(18665780244) =~ /^9998$/</li>
<li>would become:</li>
<li>2008-09-18 03:08:28 [DEBUG] mod_dialplan_xml.c:113 parse_exten() <strong>{tone_stream}</strong> test conditions destination_number(18665780244) =~ /^9998$/</li></ul>
<li>
<div>Fix the infinite loop on the enum extension</div></li></ol>
<div>Thanks for listening!</div>
<div>Christian</div>
<div> </div>
<div>P.S. I originally tried this out on Windows and instead of my destination number getting set correctly, the destination number kept coming back as the username I used to log in with. Is this a known issue or shall I debug?</div>
<div> <br></div></div></div>_______________________________________________<br>Freeswitch-dev mailing list<br><a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div><br>_______________________________________________<br>Freeswitch-dev mailing list<br><a href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br><br></blockquote></div><br></div>