----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3427/#review11619 -----------------------------------------------------------
/branches/12/main/app.c <https://reviewboard.asterisk.org/r/3427/#comment21381> I think this isn't quite correct. This will look to parse a tonezone out of a tone URI with & as the separator: tone:stutter&tonezone=at That isn't part of the URI at that point however. That's a separate query parameter, which isn't what I was suggesting. If it's a separate query parameter, then it should apply (as much as possible) to other media URIs - and in this case, it doesn't. What I was suggesting was: tone:stutter;tonezone=an In that case, there's no reason to iterate over everything either. You should be able to extract the tone and its tonezone modifier without having to look for '&' as a separator. (Unless this method gets passed the entire request line, but that seems very strange). That way other media resources don't have a query parameter in the HTTP request that they don't support. - Matt Jordan On April 15, 2014, 4:14 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3427/ > ----------------------------------------------------------- > > (Updated April 15, 2014, 4:14 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
