> 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.
>
> Mark Michelson wrote:
> 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.
>
> Tilghman Lesher wrote:
> ${MIXMONITOR(${ID},file)} but sure.
I think I agree with Tilghman - a function would be more consistent with how
things are done (tm).
- Matt
-----------------------------------------------------------
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
