execute_on_xxx too persistent
FreeSWITCH Version 1.2.10 Got a call where the A-Leg triggers a bridge to a B-Leg where I want to have certain things happen on ring/answer. So I based my dial plan on the example code <action application="export" data="nolocal:execute_on_answer=lua incrInUse.lua ${uuid}"/> Although mine is in Lua session:execute("export","nolocal:execute_on_ring=lua cc_tell.lua ring "..CCNumIPN.." "..getSessVar("uuid")) And it works fine. However, it APPEARS that I have a problem when the B-Leg initiates a C-Leg, that the execute_on_xxx seems to be executed by the C-Leg too - not what I want! I think there are ways around this (i.e. put some more intelligence into the lua code) but I can't help thinking that I've misunderstood something about export and/or the execute_on_ family.
Don’t export no local the variable, set that in the {} for the B-Leg. Then the C-Leg won’t inherit the variable from the export no local. -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On Feb 7, 2014, at 4:00 AM, Alex Lake <alex@digitalmail.com> wrote:
FreeSWITCH Version 1.2.10
Got a call where the A-Leg triggers a bridge to a B-Leg where I want to have certain things happen on ring/answer.
So I based my dial plan on the example code
<action application="export" data="nolocal:execute_on_answer=lua incrInUse.lua ${uuid}"/>
Although mine is in Lua
session:execute("export","nolocal:execute_on_ring=lua cc_tell.lua ring "..CCNumIPN.." "..getSessVar("uuid"))
And it works fine. However, it APPEARS that I have a problem when the B-Leg initiates a C-Leg, that the execute_on_xxx seems to be executed by the C-Leg too - not what I want!
I think there are ways around this (i.e. put some more intelligence into the lua code) but I can't help thinking that I've misunderstood something about export and/or the execute_on_ family.
Ah, so exported variables are inherited - didn't know (or guess) that! Thanks.
Don't export no local the variable, set that in the {} for the B-Leg. Then the C-Leg won't inherit the variable from the export no local.
-- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com
T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
On Feb 7, 2014, at 4:00 AM, Alex Lake <alex@digitalmail.com> wrote:
FreeSWITCH Version 1.2.10
Got a call where the A-Leg triggers a bridge to a B-Leg where I want to have certain things happen on ring/answer.
So I based my dial plan on the example code
<action application="export" data="nolocal:execute_on_answer=lua incrInUse.lua ${uuid}"/>
Although mine is in Lua
session:execute("export","nolocal:execute_on_ring=lua cc_tell.lua ring "..CCNumIPN.." "..getSessVar("uuid"))
And it works fine. However, it APPEARS that I have a problem when the B-Leg initiates a C-Leg, that the execute_on_xxx seems to be executed by the C-Leg too - not what I want!
I think there are ways around this (i.e. put some more intelligence into the lua code) but I can't help thinking that I've misunderstood something about export and/or the execute_on_ family.
_________________________________________________________________________ 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
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7068 - Release Date: 02/06/14
participants (2)
-
Alex Lake
-
Brian West