[asterisk-dev] [Code Review] 3427: ARI: Add tones playback resource

Jonathan Rose reviewboard at asterisk.org
Thu Apr 10 12:19:12 CDT 2014



> On April 9, 2014, 11:31 a.m., David Lee wrote:
> > /trunk/CHANGES, line 125
> > <https://reviewboard.asterisk.org/r/3427/diff/2/?file=57139#file57139line125>
> >
> >     How hard would it be to add something like ?timeMillis= to the URI for tones? Or are tones usually something like busy, where you usually just want to play the tone until the call ends?
> 
> Jonathan Rose wrote:
>     I don't imagine it would be extremely difficult... just a matter of setting a timestamp when starting and checking it after sleeps. During a standup we actually discussed something similar using a argument to the play function instead of as part of the media URI (I like the URI method better for what it's worth), but we settled on getting the basic functionality done first. I could go ahead and cook this up though.
> 
> Joshua Colp wrote:
>     Generally you just keep playing the tone until told otherwise, it's not really that common to play it for a specific period of time. Even if you did you could have a timer in your ARI app to discontinue it. I also fear that by adding such an option to tones we're going to progress further down the road of having different URI schemes support and implement different things. From a user perspective this could get confusing.
> 
> Matt Jordan wrote:
>     I actually think it is pretty common to have tones play for a period of time and then stop. I do agree, however, that (a) this could be done at the application level, and (b) having special parameters for particular URI schemes may get a bit confusing.
>     
>     I'd chalk this up to "if we need it, we'll add it". It wouldn't be a breaking change to add at a later time.

Alright then, I'll drop this for the time being.


- Jonathan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3427/#review11529
-----------------------------------------------------------


On April 8, 2014, 5:46 p.m., Jonathan Rose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3427/
> -----------------------------------------------------------
> 
> (Updated April 8, 2014, 5:46 p.m.)
> 
> 
> Review request for Asterisk Developers, David Lee, Joshua Colp, and Matt Jordan.
> 
> 
> Bugs: ASTERISK-23433
>     https://issues.asterisk.org/jira/browse/ASTERISK-23433
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Adds a tones URI type to the playback resource. The tone can be specified by name (from indications.conf) or by a tone pattern (comma separate pitch/duration list). Tones aren't like regular sounds in that they must be canceled manually before the control can move on to the next item in the queue.
> 
> Tones are capable of being paused and resumed (although they will always resumed from the beginning of the tone), restarted, and stopped.  Tones are not capable of being fastforwarded, skipped into by a duration, or rewound by a small amount. Those operations unfortunately report success rather than a lack of availability right now due to how control on playbacks is defined (a playback is either completely controllable or not). I could probably add a little more granularity to that if we want it.
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_stasis_playback.c 411884 
>   /trunk/main/app.c 411884 
>   /trunk/include/asterisk/app.h 411884 
>   /trunk/CHANGES 411884 
> 
> Diff: https://reviewboard.asterisk.org/r/3427/diff/
> 
> 
> Testing
> -------
> 
> I've written two testsuite tests (one for channels, one for bridges) which queue and stop tones with playback. I'll be posting them before too long.  I've also performed all the basic control operations by hand.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140410/64f0144e/attachment.html>


More information about the asterisk-dev mailing list