Re: [Freeswitch-users] Unloop extension
FreeSWITCH 1.0.6 book on p. 187 says: ... When you set a variable during this phase, that variable is considered global automatically and becomes accessible throughout the application as $${variable} elsewhere in the XML. ... You can utilize global variables in your conditions, your variable and parameter declarations, pretty much anywhere, like this: <condition field="$${global_variable}"> This should had an addition, that ${g_v} can be used as well. ----- Original Message ----- From: Michael Collins [mailto:msc@freeswitch.org] To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org] Sent: Thu, 17 Jan 2013 07:17:31 +0600 Subject: Re: [Freeswitch-users] Unloop extension
No, it's available globally, whether used with $${} or ${} notation. You can also see it from fs_cli:
freeswitch@default> global_getvar unroll_loops true
More info about $${} vs. ${} is found here<http://wiki.freeswitch.org/wiki/Channel_Variables#.24.7Bvariable.7D_vs._.24.24.7Bvariable.7D> .
-MC
On Tue, Jan 15, 2013 at 8:09 PM, Ержан Тулепов <e.tylepov@btcom.kz> wrote:
Ain't what was set with <x-PRE-PROCESS cmd="set" ... gets set *only* when used in $${...} notation?
----- Original Message ----- From: Michael Collins [mailto:msc@freeswitch.org] To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org] Sent: Wed, 16 Jan 2013 06:54:12 +0600 Subject: Re: [Freeswitch-users] Unloop extension
Yes, it's okay. The pre-process does a set and ${unroll_loops} gets set as needed. Then this dp entry does the work: <extension name="unloop"> <condition field="${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition> </extension>
More info on sip_looped_call var: http://wiki.freeswitch.org/wiki/Variable_sip_looped_call
-MC
On Mon, Jan 14, 2013 at 9:33 PM, Ержан Тулепов <e.tylepov@btcom.kz> wrote:
What unloop extension is used for? BTW: vars.xml pre-(process)-sets unroll_loops, whereas DPs (public and default) are using channel variable syntax? Is this ok?
Y.
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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Yes, that needs to be rephrased. It really should be ${var} not $${var} since $${var} is meant to address a different scenario. -MC On Wed, Jan 16, 2013 at 8:05 PM, Ержан Тулепов <e.tylepov@btcom.kz> wrote:
FreeSWITCH 1.0.6 book on p. 187 says:
... When you set a variable during this phase, that variable is considered global automatically and becomes accessible throughout the application as $${variable} elsewhere in the XML.
... You can utilize global variables in your conditions, your variable and parameter declarations, pretty much anywhere, like this: <condition field="$${global_variable}">
This should had an addition, that ${g_v} can be used as well.
----- Original Message ----- From: Michael Collins [mailto:msc@freeswitch.org] To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org] Sent: Thu, 17 Jan 2013 07:17:31 +0600 Subject: Re: [Freeswitch-users] Unloop extension
No, it's available globally, whether used with $${} or ${} notation. You can also see it from fs_cli:
freeswitch@default> global_getvar unroll_loops true
More info about $${} vs. ${} is found here< http://wiki.freeswitch.org/wiki/Channel_Variables#.24.7Bvariable.7D_vs._.24....
.
-MC
On Tue, Jan 15, 2013 at 8:09 PM, Ержан Тулепов <e.tylepov@btcom.kz> wrote:
Ain't what was set with <x-PRE-PROCESS cmd="set" ... gets set *only* when used in $${...} notation?
----- Original Message ----- From: Michael Collins [mailto:msc@freeswitch.org] To: FreeSWITCH Users Help [mailto: freeswitch-users@lists.freeswitch.org] Sent: Wed, 16 Jan 2013 06:54:12 +0600 Subject: Re: [Freeswitch-users] Unloop extension
Yes, it's okay. The pre-process does a set and ${unroll_loops} gets set as needed. Then this dp entry does the work: <extension name="unloop"> <condition field="${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition> </extension>
More info on sip_looped_call var: http://wiki.freeswitch.org/wiki/Variable_sip_looped_call
-MC
On Mon, Jan 14, 2013 at 9:33 PM, Ержан Тулепов <e.tylepov@btcom.kz> wrote:
What unloop extension is used for? BTW: vars.xml pre-(process)-sets unroll_loops, whereas DPs (public and default) are using channel variable syntax? Is this ok?
Y.
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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
OK lets put this to rest. 1. the reason is this. You can global_setvar to change the value without a reloadxml 2. Lets not beat a dead horse... -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH_Wire T: +1.918.420.9266 | F: +1.918.420.9267 | M: +1.918.424.WEST iNUM: +883 5100 1420 9266 UK: +44 20 3298 4900 ISN: 410*543 On Jan 18, 2013, at 4:56 PM, Michael Collins <msc@freeswitch.org> wrote:
Yes, that needs to be rephrased. It really should be ${var} not $${var} since $${var} is meant to address a different scenario. -MC
participants (3)
-
Brian West
-
Michael Collins
-
Ержан Туле пов