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

Anthony Minessale anthony.minessale at gmail.com
Tue Mar 16 07:33:40 PDT 2010


my last email had a code suggestion

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

>  Anthony, thanks for further information!
>
>
>
> My goal is not to wait for the break to be executed, I just want to make
> sure it will be handled properly – and actually break the channel that is
> playing. So nothing wrong with the async behaviour itself - I like it the
> way it is.
>
>
>
> I’ve been digging into the FS code for a couple of hours, and I think the
> problem occurs when I’m “fast” enough to add the break command, and then a
> new playback command in the event queue (and they both exist there). Then in
> the main loop of switch_ivr_play_file(), after CF_BREAK flag is checked,
> switch_ivr_parse_all_events() will be called. If both events exist in the
> queue, the CF_BREAK will first be set, then on the next event it will be
> reset again, and the new playback will begin. But it will never break the
> original playback.
>
>
>
> Since I havn’t digging too deep in the code, I’m not 100% sure of this :) I
> was hoping you could help out with your expertice. My current patch looks
> something like this – do you think it’s possible this causes other problems?
> By the way – sorry for getting this technical in the users-list, I guess
> this belongs more to the dev-list...
>
>
>
> Index: src/switch_ivr.c
>
> ===================================================================
>
> --- src/switch_ivr.c                         (revision 17000)
>
> +++ src/switch_ivr.c                      (working copy)
>
> @@ -660,12 +660,16 @@
>
>  SWITCH_DECLARE(switch_status_t)
> switch_ivr_parse_all_events(switch_core_session_t *session)
>
>  {
>
>                              int x = 0;
>
> +                           switch_channel_t *channel =
> switch_core_session_get_channel(session);
>
>
>
> -
>
>                              switch_ivr_parse_all_messages(session);
>
>
>
> -                            while (switch_ivr_parse_next_event(session) ==
> SWITCH_STATUS_SUCCESS)
>
> +                           while (switch_ivr_parse_next_event(session) ==
> SWITCH_STATUS_SUCCESS) {
>
>                                                           x++;
>
> +                                                        if
> (switch_channel_test_flag(channel, CF_BREAK)) {
>
> +
> break;
>
> +                                                        }
>
> +        }
>
>
>
>                              if (x) {
>
>
> switch_ivr_sleep(session, 0, SWITCH_TRUE, NULL);
>
>
>
> /Peter Olsson
>
>
>
> *Från:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *För *Anthony Minessale
> *Skickat:* den 16 mars 2010 14:55
>
> *Till:* freeswitch-users at lists.freeswitch.org
> *Ämne:* Re: [Freeswitch-users] ESL and application "break" (to stop file
> playback) - timing issues.
>
>
>
> 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
>
>
> _______________________________________________
> 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:4b9f8f4132931389420256!
>
> _______________________________________________
> 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/ac3d28a7/attachment-0002.html 


More information about the FreeSWITCH-users mailing list