[asterisk-dev] features.conf applicationmap issues

[Alexander Lopez]

I should just say 'Good Idea Russell' and end it there but....... 

Would there be space to set contexts that are able to access the
feature. Problem is that these are GLOBAL features. You may not want
some of your users to have access to these features.

A check to see if the 'extension' exists in the dialplan with the same
DTMF sequence would be great as it would allow.

Exten => #9,1,NoOp

Or alternately create a ApplicationMap Application that would allow for
customization based upon the context the caller and callee are in. 

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-
> bounces at lists.digium.com] On Behalf Of Martin Schrott -
thinking:systems
> eu
> Sent: Saturday, August 05, 2006 6:58 AM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] features.conf applicationmap issues
> 
> Hi,
> 
> yes, really a good idea. :-)
> But would also be great, to have the option BOTH at activate on!
> So we could activate a application on both, the caller and the callee.
> Now the second partie always is listening to silence.
> Or an option or syntaxs that looks like this:
> 
> featurename => DTMF, activate by, activate on caller, activate on
callee
> So you could decide to leave the activation field for caller or callee
> blank
> or not.
> 
> 
> Think that would be a great feature improovement.
> 
> regards,
> Martin
> 
> ----- Original Message -----
> From: "Russell Bryant" <russell at digium.com>
> To: <asterisk-dev at lists.digium.com>
> Sent: Saturday, August 05, 2006 9:03 AM
> Subject: [asterisk-dev] features.conf applicationmap issues
> 
> 
> Greetings everyone,
> 
> During our conference call at the AstriDevCon in Italy this Summer, we
> had a discussion regarding an update we needed to make to the
> application map so that you not only specified who could activate the
> feature, but which channel to activate the feature on.  This all made
> sense, under the assumption that the existing configuration option
was,
> in fact, to configure who gets to activate the feature.  However,
that's
> not quite the way it works ...
> 
> This is from features.conf.sample:
> 
> ;testfeature => #9,callee,Playback,tt-monkeys   ;Play tt-monkeys to
>                                           ;callee if #9 was pressed
> 
> >From the comment, it sounds like "callee" means that this feature
will
> be activated on the "callee".  However, in the code, this field is
used
> in more than way, and unfortunately, clearing it up is going to
require
> breaking some situations where it may have worked before.
> 
> When this field says "callee", the bridge config structure gets the
flag
> "AST_BRIDGE_DTMF_CHANNEL_1" set, which tells the bridge to watch for
> DTMF from the callee channel.  If it is set to "caller",
> "AST_BRIDGE_DTMF_CHANNEL_0" is set on the bridge config telling the
> bridge to watch for DTMF from the calling channel.  This all sounds
> fine, if the option were only used to determine who gets to activate
the
> feature.
> 
> Unfortunately, this option also does something else.  If an activated
> feature is one from the applicationmap, it uses the value of this
option
> to determine which channel to activate the feature on.
> 
> To make this even more of a mess, the behavior changes if you are
using
> any of the builtin features by including something like "tT" in the
> options to the Dial application.  By including "tT" in your Dial
> options, the bridge is already set up to monitor DTMF from both the
> caller and callee channels.  Then, the "callee" option in the
> testfeature above only applies to which channel the features is
> activated on.
> 
> So, what should we do to clean this up?
> 
> My current feeling is that we change the syntax to be the following:
> 
> <featurename> =>
> <DTMFsequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,<Data>]
> 
> The valid values of ActivateOn would be "callee" and "caller", while
the
> valid values for ActivatedBy would also include "both", which would
also
> be the default.
> 
> If I haven't confused you yet, any thoughts?
> 
> --
> Russell Bryant
> Software Developer
> Digium, Inc.
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev