[asterisk-dev] features.conf applicationmap issues

Alexander Lopez Alex.Lopez at OpSys.com
Sat Aug 5 08:14:52 MST 2006


Sorry right Brain was awake but the left rain was still asleep!  

> -----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 11:06 AM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] features.conf applicationmap issues
> 
> Hi Alex,
> 
> when I am right, you can already do so.
> you have to activate applicationmap features in your dialplan to use
them:
> [from anywhere]
> exten =>
_.,1,Set(DYNAMIC_FEATURES=featurename1#featurename2#featurenamen)
> 
> hth, Martin
> 
> ----- Original Message -----
> From: "Alexander Lopez" <Alex.Lopez at OpSys.com>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Saturday, August 05, 2006 4:38 PM
> Subject: RE: [asterisk-dev] features.conf applicationmap issues
> 
> 
> 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
> _______________________________________________
> --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



More information about the asterisk-dev mailing list