被叫(callee)怎么使用applicatemap功能

刚开始学习使用applicationmap功能时，根据features.conf中的说明，针对playmonkey的例子做了如下的配置:

features.conf

testfeature => *9,self/callee,Playback,tt-monkeys

sip.conf

canreinvite=no

[2001]
type=friend
secret=0000
context=testfeature
host=dynamic
dtmfmode=rfc2833
compensate=yes

[2002]
type=friend
secret=0000
context=testfeature
host=dynamic
dtmfmode=rfc2833
compensate=yes

extensions.conf

[testfeature]
exten => _X.,1,Ringing
exten => _X.,n,Set(DYNAMIC_FEATURES=testfeature)
exten => _X.,n,Dial(SIP/${EXTEN},60, tT)

测试中发现在2001作为主叫呼叫2002的过程中，被叫2002按*9不能正常的播放录音给2001.

在google搜索此类问题,在https://issues.asterisk.org/view.php?id=14657发现了对此问题的描述:

Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF.

Dynamic features defined in the applicationmap section of features.conf allow
one to specify whether the caller, callee, or both have the ability to use the
feature. The documentation in the features.conf.sample file could be interpreted
to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the
calling channel in order to allow for the callee to be able to use the features
which he should have permission to use. However, the DYNAMIC_FEATURES variable
would only be read from the channel of the participant that pressed the DTMF
sequence to activate the feature. The result of this was that the callee was
unable to use dynamic features unless the dialplan writer had taken measures
to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel.

This commit changes the behavior of ast_feature_interpret to concatenate the
values of DYNAMIC_FEATURES from both parties involved in the bridge. The features
themselves determine who has permission to use them, so there is no reason to believe
that one side of the bridge could gain the ability to perform an action that they

should not have the ability to perform.

Kevin Fleming pointed out on the asterisk-users list that the typical way that this
was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel
so that the value would be inherited by the called channel. While this works, the
documentation alone is not enough to figure out why this is necessary for the callee
to be able to use dynamic features. In this particular case, changing the code to match
the documentation is safe, easy, and will generally make things easier for people for
future installations.

This bug was originally reported on the asterisk-users list by David Ruggles.

(closes issue 0014657)

通过阅读上述内容,发现是因为没有在channel 2002 上进行Set(DYNAMIC_FEATURES=testfeature)操作,此问题可以打编号0014657的补丁解决,而我不想重新编译asterisk,进一步通过google搜索解决办法,在http://lists.digium.com/pipermail/asterisk-bugs/2007-December/008609.html找到了解决办法。

通过对extensions.conf的修改终于解决了问题。

新的extensions.conf

[testfeature]
exten => _X.,1,Ringing
exten => _X.,n,Set(DYNAMIC_FEATURES=testfeature)
exten => _X.,n,Dial(SIP/${EXTEN},60, tTM(dynamic-features))

[macro-dynamic-features]
exten => s,1,Set(DYNAMIC_FEATURES=testfeature) //在被叫通道设置DYNAMIC_FEATURES