Scope, effect, and management of: "DYNAMIC_FEATURES"

Asterisk Asterisk Support
1

Hi, all.

I’m new to Askerisk, and to these forums, and I’m hoping someone here will kindly help me.

Despite much searching, I am unclear on the scope of DYNAMIC_FEATURES, it’s precise effect on each call-participant, and how it can be used to dynamically control the features available in bridged SIP call.

  1. What is the scope of DYNAMIC_FEATURES?

  2. Is it possible for two bridged SIP channels to each have different applicationmap features available whilst connected in the same call?

  3. If the answer to question 2 is “yes”, how can the available features can be dynamically changed, during the call, independently for each party? Either by using feature codes (as I’ve been testing with) or, perhaps, from an external application (which I have not tried - how?)

I’m running Asterisk 1.8.13.0 / ubuntu / VMWare.

What I’ve found so far, by experimenting, is a distinct value can be set/retrieved for DYNAMIC_FEATURES, for each of the two SIP parties in a bridged call. However, and this is where I’m slightly confused, if a feature is included in DYNAMIC_FEATUES for just one peer on the call (it doesn’t seem to matter which), it seems that both parties can access that feature.

FYI: In my experiments, I’ve added a couple of feature codes to allow each party to set the value of DYNAMIC_FEATURES for self or peer, along with feature codes to display the values in the CLI. My “test” feature simply invokes the “Morsecode” application to send “SOS” to the peer. The features to display diagnostic info (including the value for each peer’s DYNAMIC_FEATURES) invoke a dialplan macro - on peer or self, depending on which feature code is entered.

Thanks, in advance, for any help or guidance.

Regards,

2

Hi, again.

There has been no response to my original post, after 100 views.

Can someone please tell me if that means I posted in the wrong forum, or does it mean I didn’t explain my question correctly?

Thanks.

3

The question is a bit technical. Relatively few people use custom features. It is not clear exactly what scope you meant. Some of those views are by search engine crawlers.

As I understand it, the same feature code cannot have two different meanings, but you can control whether the feature is recognised from the caller or callee and you you can further restrict by the use of channel variables.