> On Nov. 21, 2013, 4:40 p.m., Tilghman Lesher wrote: > > Shouldn't something like this be a channel function from which you retrieve > > the value, instead of specifying a variable into which the name is placed? > > Seems like a significant regression in spitting things out to channel > > variables, instead of using dialplan functions to retrieve values when > > needed.
So you're thinking something like: exten => blah,1,Answer() same => n,MixMonitor(file.wav,i(ID)) same => n,NoOp(Filename is MIXMONITOR(${ID},file)) ? I'd be okay with it. The main reason I went with the channel variable approach was because of app_mixmonitor's pre-existing 'i' option. My thought was that this feels more "consistent" than providing a separate method of getting an instance-specific value. Of course the attraction of the dialplan function route is that it is more scalable in case there are other instance-specific values that people wish to retrieve from a mixmonitor. - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3023/#review10242 ----------------------------------------------------------- On Nov. 20, 2013, 9:12 p.m., Mark Michelson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3023/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2013, 9:12 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > This change introduces an 'f' option for the MixMonitor() application. The > argument for this option specifies a channel variable into which the > application should store the filename (as in, the full path) instead of the > standard MIXMONITOR_FILENAME. > > The rationale for this option is that MixMonitor is structured in such a way > that a single channel may have multiple simultaneous MixMonitors running at > any given time. Thus, the MixMonitor application should not have any > assumptions that the channel has only a single MixMonitor being run on it. > Setting a single MIXMONITOR_FILENAME channel variable violates such > assumptions by overwriting the value set from previous invocations of > MixMonitor. By using the 'f' and 'i' options for MixMonitor, a user can > easily manage multiple recordings on a single channel. > > > Diffs > ----- > > /trunk/apps/app_mixmonitor.c 402883 > > Diff: https://reviewboard.asterisk.org/r/3023/diff/ > > > Testing > ------- > > See https://reviewboard.asterisk.org/r/3024/ > > > Thanks, > > Mark Michelson > >
-- _____________________________________________________________________ -- 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