Per-channel FEATUREMAP settings

(Asterisk 13.17.2 installed from Ubuntu 17.10 repo)

I’m having some difficulty setting a new DTMF sequence when I am bridging a call. I’ve had no trouble with the statically defined feature codes in features.conf. My understanding is that I ought to be able to override a feature code DTMF on a per-channel basis, but maybe my understanding is incomplete.

My example uses “disconnect”, but I tried similar experiments with “parkcall”. I have this in features.conf:

[featuremap]
disconnect => *71

I have this in extensions.conf:

exten => 661,1,Verbose(0,==> ${CONTEXT},to:${EXTEN},from:${CALLERID(all)})
	same => n,Set(FEATUREMAP(disconnect)=*76)
	same => n,Verbose(0,FMd ... ${FEATUREMAP(disconnect)})
	same => n,Dial(SIP/SIPGRANDBLUEa,,KTWXktwxHh)

You can see that I set the DTMF for “disconnect” to *76. The Verbose() immediately following it agrees it’s *76.

When I make a call to that extension, *76 does nothing, and *71 disconnects. Here are the respective log snippets (I trimmed the timestamp/prefix clutter for readability).

*76:

res_rtp_asterisk.c: Creating BEGIN DTMF Frame: 42 (*), at 192.168.1.108:5150
res_rtp_asterisk.c: Creating END DTMF Frame: 42 (*), at 192.168.1.108:5150
bridge_channel.c: DTMF feature string on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) is now '*'
res_rtp_asterisk.c: Creating BEGIN DTMF Frame: 55 (7), at 192.168.1.108:5150
res_rtp_asterisk.c: Creating END DTMF Frame: 55 (7), at 192.168.1.108:5150
bridge_channel.c: DTMF feature string on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) is now '*7'
res_rtp_asterisk.c: Creating BEGIN DTMF Frame: 54 (6), at 192.168.1.108:5150
res_rtp_asterisk.c: Creating END DTMF Frame: 54 (6), at 192.168.1.108:5150
bridge_channel.c: DTMF feature string on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) is now '*76'
bridge_channel.c: No DTMF feature hooks on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) match '*76'
res_rtp_asterisk.c: Setting the marker bit due to a source update
bridge_channel.c: Playing DTMF stream '*76' out to 0x7fd558020b50(SIP/callcentric14-00000026)
res_rtp_asterisk.c: Setting the marker bit due to a source update

*71:

res_rtp_asterisk.c: Creating BEGIN DTMF Frame: 42 (*), at 192.168.1.108:5150
res_rtp_asterisk.c: Creating END DTMF Frame: 42 (*), at 192.168.1.108:5150
bridge_channel.c: DTMF feature string on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) is now '*'
res_rtp_asterisk.c: Creating BEGIN DTMF Frame: 55 (7), at 192.168.1.108:5150
res_rtp_asterisk.c: Creating END DTMF Frame: 55 (7), at 192.168.1.108:5150
bridge_channel.c: DTMF feature string on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) is now '*7'
res_rtp_asterisk.c: Creating BEGIN DTMF Frame: 49 (1), at 192.168.1.108:5150
res_rtp_asterisk.c: Creating END DTMF Frame: 49 (1), at 192.168.1.108:5150
bridge_channel.c: DTMF feature string on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) is now '*71'
bridge_channel.c: DTMF feature hook 0x7fd5600039c8 matched DTMF string '*71' on 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027)
res_rtp_asterisk.c: Setting the marker bit due to a source update
bridge_channel.c: Setting 0x7fd558023700(SIP/SIPGRANDBLUEa-00000027) state from:0 to:1

Any suggestions?

FWIW, I tried the same experiment with the current Asterisk 15 sources. Same result.

h - Allow the called party to hang up by sending the DTMF sequence defined for disconnect in features.conf.

H - Allow the calling party to hang up by sending the DTMF sequence defined for disconnect in features.conf.

Thanks for the suggestion.

That merely disabled the features.conf “*71” disconnect code, which is what I expected would happen. Were you expecting something different?

I made a few test and realized FEATUREMAP(disconnect)=*76 will only work if invoked on the calling party as it is linked to the calling channel, and disconnect => *71 defined on features.conf will only work if executed by called party, also keep H and h option on the dial command it is mandatory

1 Like

That’s interesting. I thought “h” and “H” would distinguish between callED and callING parties for who was allowed to do it, but they would both have the same feature code sequence. However, my experimental results almost** match yours. It kind of makes sense, I guess, and I’ll explore ways to see if I can set a new feature code sequence on the callED channel.

Thanks for taking the trouble to experiment and giving me a nudge in what might be the right direction!

**I said “almost” because a weird thing happened. When the callED party dials *71, it does disconnect the callING party. The callED party is not disconnnected; instead, it gets music on hold until it hangs up from its end. I’ll work on that one later :-).

Yes, you were right. I used the “b()” option on my Dial() command to apply settings to the callED channel.

I’m not sure I would have come to this key realization without your hint. Thanks!

In case anyone is curious, I describe my final solution in this post: How I set up my feature codes.

2 Likes