On Sep 18, 2008, at 5:24 AM, Christian Jensen wrote:

Hi everyone,
 
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)
 
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
 
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.
 
I hit F8 on my console and this is what I got:
 
2008-09-18 02:11:38 [INFO] mod_dialplan_xml.c:228 dialplan_hunt() Processing 6044880583->18665780244 in context public
2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions ${unroll_loops}(true) =~ /^true$/
2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions ${sip_looped_call}() =~ /^true$/
2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:115 parse_exten() Regex mismatch
2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions destination_number(18665780244) =~ /^(10[01][0-9])$/
2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:115 parse_exten() Regex mismatch
2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions destination_number(18665780244) =~ /^(5551212)$/
2008-09-18 02:11:38 [DEBUG] mod_dialplan_xml.c:115 parse_exten() Regex mismatch
2008-09-18 02:11:38 [INFO] switch_core_state_machine.c:114 switch_core_standard_on_routing() No Route, Aborting
I think I understand what is going on here - but I disagree with defaults.
 

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.



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.
 

That is inbound vs outbound and the way its setup by default so you don't open your dialplan to toll fraud.  


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 :(

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.


So as a Recap, here is what I would like to have changed if possible:
  1. A better regex for the default DID install
  2. Fix the regex on the enum extension OR remove it OR Better documentation surrounding the name of a file for custom extensions
  3. 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
    • 2008-09-18 03:08:28 [DEBUG] mod_dialplan_xml.c:113 parse_exten() test conditions destination_number(18665780244) =~ /^9998$/
    • would become:
    • 2008-09-18 03:08:28 [DEBUG] mod_dialplan_xml.c:113 parse_exten() {tone_stream} test conditions destination_number(18665780244) =~ /^9998$/
  4. Fix the infinite loop on the enum extension
Thanks for listening!
Christian
 
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?
 
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org