Ah  I see! There is an option somewhere on the wiki (memory fails me right now) to disable voicemail on a per user basis, set in their profile. In the case of setting variables per user, it's best to keep them in the user profile so that they are called when the user makes a call. In the case of pulling variables when the user is _being_ called, you can execute actions inline to pull and set those variables when the call hits the extension in the dialplan. I've done this on intercom calls, where you can set variables in both the caller's and callee's profile, then the extension just sets them when a call is made. The idea is that you only create extensions for different functions just once, and keep user settings with the users. There are some exceptions, like when you need some convoluted ring group strategy and using the groups feature is too limited to accomodate this, so it's better to list the users in an extension that does what you want. Another case would be when you have a group of extensions that you want to behave fundamentally different from another group, then it might make sense to create a different extension and match it to a specific range. There are two places that matter when it comes to users:

/etc/freeswitch/dialplan/default.xml
/etc/freeswitch/directory/default/<user-profiles-go-here.xml>

The dialplan is for dialling/execution, nothing more or less. Extensions are not users or endpoints, they are just chunks of code that do things. The directory is for users/endpoints. You need both for a call to work, otherwise all those xml extensions are trying to call users that don't exist, and FS expects them to be there. If you wanted your gui to use multiple extensions, you'd also have to make it create a user profile as well for each user. Again, this is going to add a very large amount of redundency to your system if it is creating the same core functions over and over, when they could be just declared once and matched to a group of users. It also opens your system up to a performance penalty, because FS has to traverse the dialplan until it finds a match, and if you have 200 users each with a unique extension, then that's 200 extensions hogging memory and up to 200 attempts that FS has to try before it finds a match, whereas having only one extension means that it only has one extension to load and match.  The ideal situation is to build the functionality into the dialplan that you want, catering for all scenarios that you are expecting to encounter, then use variables in the user's profiles to trigger those functions as needed.

Francis


On 8/06/2014 4:04 PM, Richard Mace wrote:
Hi Francis,
Thanks for your detailed email.
​I have purchased the FS 1.2 book and read it a few times, I think I might have to go back and read it again :)
The reason I wanted to do it in "per extension" files was because I am creating a FS GUI, and want to give users the choice, on a per extension basis, as to whether their extension diverts to voice mail or not, such as 200 and 202 may want to divert to voicemail, whereas 201 and 203 don't want that. So, I thought that if I had separate .xml files for each extension in the /etc/freeswitch/dialplan/default/ directory, then I could have any behaviour I wanted on a per "extension dialled" basis, unless of course I am completely missing something here? :)​

Richard


On 8 June 2014 02:27, Francis <sms@icefire.qza.net.au> wrote:
This would make sense in Asterisk, but FS differentiates between 'extensions' and 'users'. An extension is simply a destination for a number, with a set of conditions and actions. A user is still necessary if you want to register a phone or a soft client. Hence, FS vanilla only declares the extension once, but has multiple users that reference to it. Declaring the extension multiple times isn't necessary and has no effect since there is no user-no.xml to reference to it, so it fails. Simply changing the destination_number condition to match your number range and creating normal users (like the 1000 - 1019 that come with vanilla) is enough to do what you are trying to do.

The Freeswitch 1.2 book on PaktPub is well worth the coin if you have it, just to save many hours of tinkering and being trapped by 'Asterisk logic'. FS has built in heuristics for detecting guesswork and it exacts the most terrifying revenge upon the offender.

Francis



On 8/06/2014 6:09 AM, Richard Mace wrote:
Hi Francis,
I have actually commented that out, and replaced it with multiple files, in the /etc/freeswitch/dialplan/default/ such as this, which I believe is the same as splitting out the vanilla local extension, that is, when 203 is dialled, FreeSWITCH would look through all of the .xml files until it found this code, and would then ring the extension?:

<include>
  <extension name="203">
    <condition field="destination_number" expression="^(203)$">
      <action application="export" data="dialed_extension=$1"/>
      <!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> -->
      <action application="bind_meta_app" data="1 b s execute_extension::dx XML features"/>
      <action application="bind_meta_app" data="2 b s record_session::$${recordings_dir}/${caller_id_number}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav"/>
      <action application="bind_meta_app" data="3 b s execute_extension::cf XML features"/>
      <action application="bind_meta_app" data="4 b s execute_extension::att_xfer XML features"/>
      <action application="set" data="ringback=${uk-ring}"/>
      <action application="set" data="transfer_ringback=$${hold_music}"/>
      <action application="set" data="call_timeout=14"/>
      <!-- <action application="set" data="sip_exclude_contact=${network_addr}"/> -->
      <action application="set" data="hangup_after_bridge=true"/>
      <!--<action application="set" data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/> -->
      <action application="set" data="continue_on_fail=true"/>
      <action application="hash" data="insert/${domain_name}-call_return/${dialed_extension}/${caller_id_number}"/>
      <action application="hash" data="insert/${domain_name}-last_dial_ext/${dialed_extension}/${uuid}"/>
      <action application="set" data="called_party_callgroup=${user_data(${dialed_extension}@${domain_name} var callgroup)}"/>
      <action application="hash" data="insert/${domain_name}-last_dial_ext/${called_party_callgroup}/${uuid}"/>
      <action application="hash" data="insert/${domain_name}-last_dial_ext/global/${uuid}"/>
      <!--<action application="export" data="nolocal:sip_secure_media=${user_data(${dialed_extension}@${domain_name} var sip_secure_media)}"/>-->
      <action application="hash" data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/>
      <action application="bridge" data="user/${dialed_extension}@${domain_name}"/>
      <action application="answer"/>
      <action application="sleep" data="1000"/>
      <action application="bridge" data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>
    </condition>
  </extension>
</include>

Richard


On 7 June 2014 18:23, Francis <sms@icefire.qza.net.au> wrote:
Close, that tells it to include the files you created, but it doesn't tell FS to actually recognize them when they are dialed. There is an extension in this file with a condition statement:

<condition field="destination_number" expression="^(10[0,1][1-9])$">

You should see some comments before the extension describing what it is and does. This extension has all the actions that are/can be executed when an internal endpoint is dialed. As you can see, the statement above uses PCRE to match the number dialed, and it needs to match your desired numbering scheme in order to work. Just make sure that when you modify it, that it doesn't clash with any of the other extensions in the dialplan, most of which are in this file. If you haven't already, have a sift though the wiki on dialplan settings:

https://wiki.freeswitch.org/wiki/Dialplan_XML

Francis



On 8/06/2014 2:42 AM, Richard Mace wrote:
Hi Franics,
When you say "recognize this numbering plan" do you mean this line?:

    <!--
        You can place files in the default directory to get included.
    -->
    <X-PRE-PROCESS cmd="include" data="default/*.xml"/>

Or am I missing something else?

​ Richard​


On 7 June 2014 12:45, Francis <sms@icefire.qza.net.au> wrote:
Have you modified the file:

/etc/freeswitch/dialplan/default.xml

to recognize this numbering plan? If not, just saving extensions won't work.

-Francis



On 7/06/2014 9:30 PM, Richard Mace wrote:
Hi Francis,
It is a vanilla install, with the addition of extensions 201,202 and 203 all saved as seperate .xml files in /etc/freeswitch/dialplan/default/ directory

Richard


On 7 June 2014 10:57, Francis <sms@icefire.qza.net.au> wrote:
Is this the vanilla config of Freeswitch? Vanilla only recognizes extensions 1000 to 1019, unless you modify the match string in the dialplan.

-Francis



On 7/06/2014 5:53 AM, Richard Mace wrote:
Thanks for your help Matt.
Did I include a good enough sip trace in my first post?

Richard


On 6 June 2014 16:07, Matt Broad <matt@inveroak.com> wrote:
strange :|
Sorry to say but I think I may have to step out and let someone else see if they can offer some assistance.

thanks
Matt 



_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org