You can call an extension whatever you want... It doesn't have to be a number... But using the separate context allows you to keep the destination number field in the CDR something same like that actual destination number... On 9/19/12 7:25 AM, "Emrah" <lists@kavun.ch> wrote:
Is there a way to address an extension without assigning it to a destination_number? I don't want the extension to be reachable directly and would gladly avoid creating a dedicated context. Can I transfer a call to an extension that doesn't have a destination_number?
Best, Emrah On Sep 19, 2012, at 7:10 AM, Emrah <lists@kavun.ch> wrote:
Easy indeed, but I wanted to avoid it thinking there was some other alternative. Thanks for your quick response, will use it.
Cheers, Emrah On Sep 19, 2012, at 12:50 AM, Ken Rice <krice@freeswitch.org> wrote:
This is easy to handle... Do it as 2 different extensions and after you collect the PIN, use the transfer application to transfer the call to a pin validating extension... Problem fixed with a very simple solution
On 9/18/12 11:42 PM, "Emrah" <lists@kavun.ch> wrote:
Please bypass the inline="true"Š A fantasy of mine. On Sep 19, 2012, at 12:32 AM, Emrah <lists@kavun.ch> wrote:
Hi all,
My example below cannot work because FS does not store the value of ${pin} until the call goes into execution state. While keeping it simple, what would be your take on this? Is there a way to instruct FS to start executing at some point and discovering the dialplan along the way?
<extension name="pin test"> <condition field="destination_number" expression="^111$" break="never"> <action application="answer"/> <action application="sleep" data="1000"/> <action application="read" data="4 4 $${base_dir}/sounds/en/us/callie/conference/8000/conf-pin.wav pin 10000 #,*" inline="true" /> </condition> <condition field="${pin}" expression="^1234$"> <action application="transfer" data ="3000 XML local" /> </condition> <condition field="${pin}" expression="^\d{4}$"> <action application="hangup" /> </condition> </extension>
Thanks and all the best, as always. Emrah
_________________________________________________________________________ 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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
_________________________________________________________________________ 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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch