[Freeswitch-users] ESL and application "break" (to stop file playback) - timing issues.

Tue Mar 16 06:54:33 PDT 2010

These events sent via sendmsg are designed to be asynchronous.
artificial waiting may be adding to the problem.

Step outside of what you are trying to do and consider that the sendmsg
command itself
is designed to send a 1 way message to the channel, the reply is only to
confirm that it was sent not the reply from
the application you are executing, because executing an app is not the only
thing you can do.

if you don't like async behaviour you could always send a blocking
instruction like the read or play_and_get_digits app to collect your info.

If anything, it might be ok to put this in the "break" app at the end

switch_channel_wait_for_flag(channel, CF_BROADCAST, SWITCH_FALSE, 2000,
NULL);

On Tue, Mar 16, 2010 at 6:41 AM, Peter Olsson <
peter.olsson at visionutveckling.se> wrote:

>  I agree, that is a possibility. However, when sending a “SendMsg” with
> application “break”, and receive “+OK” as it’s reply, you kind of expect
> that it was received correctly, and will be handled in the event queue
> properly.
>
>
>
> I have a created a small patch that (probably) will fix this in FS, without
> breaking anything else. I just need to test it first – if everything seems
> ok I will add a jira for it, with the patch attached.
>
>
>
> /Peter
>
>
>
> *Från:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *För *Anthony Minessale
> *Skickat:* den 15 mars 2010 17:21
>
> *Till:* freeswitch-users at lists.freeswitch.org
> *Ämne:* Re: [Freeswitch-users] ESL and application "break" (to stop file
> playback) - timing issues.
>
>
>
> you could also wait for the execute_complete of the file you were playing
>
> On Mon, Mar 15, 2010 at 9:40 AM, Peter Olsson <
> peter.olsson at visionutveckling.se> wrote:
>
> Thanks for the reply.
>
>
>
> Yes, I thought of this.
>
>
>
> But that still shouldn’t solve the issue? It will only tell that the
> CF_BREAK flag was set on the channel, not that the current playback detected
> the flag in the loop (which I guess is done in a different thread), or is
> this event sent once the playback really did stop?
>
>
>
> /Peter
>
>
>
> *Från:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *För *Anthony Minessale
> *Skickat:* den 15 mars 2010 16:31
> *Till:* freeswitch-users at lists.freeswitch.org
> *Ämne:* Re: [Freeswitch-users] ESL and application "break" (to stop file
> playback) - timing issues.
>
>
>
> you could wait for the execute_complete event for your break command.
>
> On Mon, Mar 15, 2010 at 3:20 AM, Peter Olsson <
> peter.olsson at visionutveckling.se> wrote:
>
> I’m not sure if this belongs in Jira, or if it’s possible to do it another
> way – so I try the list first :)
>
>
>
> I’m using ESL to do some IVR functions. Basically I play some sound files,
> wait for DTMF, and then do something, like record a message, transfer the
> call to a mobile phone etc. Quite basic and simple.
>
>
>
> I’ve noticed one problem with this, and it’s when I want to stop playback
> using command “break”. In 99% of the time everything works as expected, but
> sometimes I get this problem – and the problem is that the current file
> doesn’t stop playing. And I think I know why this is happening.
>
>
>
> Lets say I first send playback(tone_stream://%(1500, 3500, 440.0,
> 0.0);loops=100) to the channel. This will play a ring-tone (swedish) and
> loop through it 100 times.. When I want to stop this tone I send the break
> command, and directly after this a new playback command. Maybe 1 time in 100
> tries the tone_stream doesn’t stop playing. I think this is becuase how
> break works. From what I understand from the source it just sets the
> CF_BREAK flag on the channel, and then the playback application will detect
> this and stop the playback. However, when I send a new playback command
> immediately after break it will reset the CF_BREAK-flag again, to make sure
> it won’t cause any problems for the new playback. So if the original
> playback (tone_stream) didn’t check the flag before it was reset, it won’t
> known that it was supposed to stop playing.
>
>
>
> I guess I could wait 50ms before sending the new playback message, but I
> can really never be sure that it was handled properly.
>
>
>
> Is there any other way around this? How about “break <uuid> all”, will it
> make any difference in this case? Or should this just be treated as a timing
> bug, and filed to Jira? Any help on this would be greatly appreciated.
>
>
>
> These are the messages I’m sending;
>
>
>
> SendMsg <uuid>
>
> call-command: execute
>
> execute-app-name: playback
>
> execute-app-arg: tone_stream://%(1500, 3500, 440.0, 0.0);loops=100
>
>
>
> When I don’t want this to play anymore I send a break;
>
>
>
> SendMsg <uuid>
>
> call-command: execute
>
> execute-app-name: break
>
>
>
> And immediately after this I want to play another file;
>
>
>
> SendMsg <uuid>
>
> call-command: execute
>
> execute-app-name: playback
>
> execute-app-arg: file/to/play.wav
>
>
>
>
>
> Regards,
>
>
>
> Peter Olsson
>
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:+19193869900
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:+19193869900
> !DSPAM:4b9e60d032938314917241!
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100316/0a02e678/attachment-0002.html 