I have a dahdi channel set up for my T1 trunk and have incoming calls terminate on the demo context for now. The issue I am having is that when the call is answered, it is muted to one way audio. I had this terminate to a SIP device where someone was answering and we were noticing that the SIP device could hear the PSTN caller, but not the other way around. I changed it to the demo context to continue testing without bothering the other person, especially since the audio not being heard was from PBX to the PSTN.
The weirdest thing is that if the PSTN side caller were to press a key on the keypad (ie. DTMF, also made no difference to which key I pressed) then the audio would be available again on both ends till the end of the call. I have spent hours trying to find out why that may be the case, but to no avail. It is always the case that there the PSTN can’t hear the PBX audio until the DTMF is pressed.
I checked the dahdi_monitor visualizer and I see the audio being transmitted, but still no audio on the PSTN side. After increasing the “core set debug” to 100 I still saw no log entries that would show me what was being changed by pressing the DTMF key. This afternoon, just by chance, I saw that while doing “dahdi show channel 1” I was seeing that the line “Actual Confmute: Yes” gets changed to “Actual Confmute: No” after I press the DTMF. When the channel is active, the setting there is No, but changes to Yes when the call is answered, and after the DTMF goes back to No when there is audio going through.
My question is, (a) how do I turn off Confmute permanently? (b) What is Confmute? Is is the conference bridge muting? © Can i turn it off on a per call basis from the dialplan, once the call is answered?
I have no audio where I can change that setting, so your help is much appreciated!
Adnan.
This is happening on the caller side, regardless if I call from the PSTN to a sip device, or from a SIP device to the PSTN. In both cases, the originator of the call is not hearing the other side until the DTMF is pressed.
I’ve tried the dial command in the dialplan with the option D(5:5) to send a DTMF key 5 to both called and calling parties, but that doesn’t change anything. The calling party still needs to press a dtmf to hear the calling party, whereas the calling party can hear the audio from the start already without the dtmf.
I have recompiled asterisk with the current LTS version based on the asterisk website,
Asterisk 13.7.2 built by root @ kuu-gsm-pstn on a x86_64 running Linux on 2016-02-12 20:16:30 UTC
and same with dahdi,
DAHDI Version: 2.11.0-rc1 Echo Canceller: HWEC
When the PSTN caller calls the SIP device, again there is no audio that the PSTN side caller hears until he presses any DTMF key. Looking at the “dahdi show channel 1” I see that it is the same “Actual Confmute: Yes” that changes. It is No when the channel is idle, goes the Yes as soon as the channel is answered, and then goes to No after the DTMF key is pressed.
For the SIP to PSTN call, the SIP side doesn’t hear anything until a DTMF key is pressed, in this case I have been able to do a SendDTMF entry in the dialplan and that work around works ok.
Why does the Confmute option get turned on? how to turn it off?
Adnan.
confmute was intended to be used to mute audio when DTMF is detected. This is because Asterisk will not generally want to pass the DTMF both inband and via SIP messages.
Looking at when it’s enabled and disabled, it’s hard to say in your case. Is your hardware interface sending a DTMF_DOWN event when the channel is first connected? If so, that could explain it and it would be something that you need to take up with your hardware interface provider.
So to answer your original questions:
(a) how do I turn off confmute permanently
You will need to edit the code and comment out the line in channels/chan_dahdi.c where DAHDI_CONFMUTE is set.
(b) What is Confmute?
I believe I answered that above
© can I turn it off on a per call basis from the dialplan, once the call is answered?
Not on a per-call basis that I’m aware of.
Thanks for that. I did the change that prevents it from turning on the mute, and all works fine now.
The t1 is an e&m wink with Feature Group B MF signalling trunk, so I’m not sure why it thought there was a DTMFdown event, I checked with the telco and they weren’t sending anything as such on the trunk.
The change done was as follows in the channels/chan_dahdi.c source file,
if (p->dsp && (!p->ignoredtmf || p->callwaitcas || p->busydetect || p->callprogress || p->waitingfordt.tv_sec || p->dialtone_detect) && !idx) {
/* Perform busy detection etc on the dahdi line */
int mute;
f = ast_dsp_process(ast, p->dsp, &p->subs[idx].f);
/* Check if DSP code thinks we should be muting this frame and mute the conference if so */
mute = ast_dsp_was_muted(p->dsp);
if (p->muting != mute) {
p->muting = mute;
/* dahdi_confmute(p, mute); */ /*Adnan hardcode change, don't mute regardless of state of DSP */
dahdi_confmute(p, 0);
}
After the change above was done, a simple make and make install applied the change for me.
Adnan.