I think if you always wait until a command has been executed before you send a new command, it can't happened that you stop the wrong playback. If you pass Event-UUID in sendmsg like … sendmsg Event-UUID: 5bf340cd-7a7e-4965-9285-95ed365ed242 call-command: ... execute-app-name: ... execute-app-arg: ... … you will get this UUID back as Application-UUID in the CHANNEL_EXECUTE and CHANNEL_EXECUTE_COMPLETE events, so we are able to match it. So you can wait until you get CHANNEL_EXECUTE_COMPLETE before you send your second playback. See also "Correlate SendMsg reply with request in async mode" in the mailing list. - Markus Am 31.05.2013 um 16:38 schrieb D D <tru083@yahoo.com>:
Hi,
If I have an async ESL playback operation running, and I issue a 'break', immediately followed by a new playback, is there any chance that the second playback will be stopped by the 'break' ?
In my testing I never observed something like this happening, but I was wondering if event-lock is really needed in this case. The event-lock causes other side effects that I would like to avoid if possible.
Thanks, David
_________________________________________________________________________ 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