> On April 15, 2014, 10:21 a.m., Joshua Colp wrote: > > /branches/12/main/app.c, line 1128 > > <https://reviewboard.asterisk.org/r/3427/diff/3/?file=57210#file57210line1128> > > > > This doesn't allow the tone zone to be specified by the user, > > restricting us to US only. This needs to be made configurable somehow.
So I actually was thinking a bit on this... I thought about adding tonezone as a field to the play function, but that seems like it's a little URI specific. Would it be appropriate maybe to repurpose the language field in this case? I know languages are distinct from tonezones though... It was mentioned elsewhere in this review that forming the arguments in the URI is also bad form. That said, I think tonezone can be set at the channel level can't it? Via the CHANNEL(tonezone) function. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3427/#review11606 ----------------------------------------------------------- On April 10, 2014, 3:55 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3427/ > ----------------------------------------------------------- > > (Updated April 10, 2014, 3:55 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 > ----- > > /branches/12/rest-api/api-docs/channels.json 412061 > /branches/12/rest-api/api-docs/bridges.json 412061 > /branches/12/res/res_stasis_playback.c 412061 > /branches/12/res/ari/resource_channels.h 412061 > /branches/12/res/ari/resource_bridges.h 412061 > /branches/12/main/app.c 412061 > /branches/12/include/asterisk/app.h 412061 > /branches/12/CHANGES 412061 > > 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
