Hi guys,
It seems like the telco is not forwarding DTMF signals over ISDN PRI to Asterisk, which my IVR can detect through the Read() application. I wanted to be sure about the fact, though, that I started monitoring what is coming in by recording and analyzing using tools like Multimon (-ng).
However, I am running Asterisk over Centos where I cannot install Multimon. Is there anything equivalent to use instead? Or, what other methods are recommended?
Thanks in advance!
one option is to install it from source
Great! It never appeared to me as an option when “yum” refused to do the job. Thank you!
You can use MixMonitor on Asterisk, to capture the file, and then analyze offline.
Some boards/appliances allows you to log call details, since call setup, dtmf exchanged and others.
Other options are checking dtmf mode between board and asterisk once you can choose between inband, rfc2833 and SIP.
Thanks once again. I just did as you recommended and got it to work!
Yes, thank you! I use Monitor for monitoring in combination with Audacity and, now, Multimon-ng, for analysis.
You got it! I could see things as you described them in real-time logs as well as filed ones. I just wanted to be extra cautious by clearing things out on my side before putting the blame on the telco. Thanks!
A couple of related questions, though, if I am allowed to:
Very grateful for your help!
The boards are not VoIP devices. The choices are inband or PCE[e], although I don’t know how to disable the latter, and it may be vendor dependent.
You should ask the card vendor about how to configure DTMF.
I’m not sure what you are expecting in terms of “noise reduction”. Gaussian noise is impossible to remove, although one can make it easier on the ear by working out which frequencies are currently carrying voice information, and reducing the system gain at others. That’s basically what modern hearing aids do, but the result is far from perfect. I think people have found this reduces listener fatigue, but doesn’t really affect ineligibility.
Such noise reduction is compute intensive, so would be done in the hardware and is something to ask the vendor about.
According to this article: Sangoma Support
Apply Noise Reduction Filter . This option applies a filter on calls to reduce analog line noise. This can improve quality on very old analog lines in rural areas. Before enabling this option, it’s best to call your provider to see if they can improve the signal quality or strength from their end, as this option only masks over the noise.
Right now, the system I am working on suffers from a lot of noise. Even if I am not sure of the exact reason, I would like to try all options available to improve the sound quality along with the effort from the local telco working to find out the reason.
On the other hand, I could live with the sound quality, but, related or not, DTMF signals are not reaching the IVR either. With the aforementioned arrangement, I could attest that the signals are reaching the system but not detected by the Asterisk. As a matter of fact, not even Multimon-ng could decode the incoming DTMF contents- I haven’t managed until now, anyway.
So, my belief is that even the DTMF signals “MUST” arrive highly distorted not to be decoded by Multimon-ng (unless I am doing something wrong), or, provided that I am doing wrong and the signals are OK, the hardware detector is trapping them before they got detected by Asterisk. This is a dilemma I have got to deal with. In the worst scenario, I will just disassemble the hardware echo canceller to see the results whether or not it’s causing the problem with the DTMF. Easier would have been if I could disable the hardware DTMF detector- on Digium te235 card- and even if I could apply noise reduction filter as above.
My guess is that relates to the Digium derived, Sangoma, commercial offering, Switchvox.
I would think the option would be in dahdi/system.conf, not any part of the Asterisk system, but the open source code has nothing that seems to match. My guess is that customers can get a closed source version of dahdi_cfg, that supports advanced options if the card supports them (and it is a genuine Digium/Sangoma one).
Historically even DAHDI support wasn’t provided on this forum, with enquirers being redirected to the vendor. That was intended to put vendors with good support at an advantage, with the assumption that clone vendors didn’t provide good support, and certainly shouldn’t benefit from Digiuam support. That did seem to put users of old cards at a disadvantage.
In any case, I don’t think that any of the Sangoma regulars here, know about DAHDI.
Back to nose reduction. It’s not clear what type of noise reduction is used. In analogue radio you use a completely different strategy, from the one I described, for impulse noise, which an ba cause by electric fences.
You are of label for the noise reduction, anyway, as you are not at the end of an analogue line.
Is it possible to make a recording (NB really must be either the original G.711, or signed linear format), of a garbled digit, available here, so that people can try and identify the noise?
Are you sure you have the timing source set to be from the line, as trying to provide timing yourself, will cause problems.
It looks like the open source device driver supports controlling hardware detection and muting, but I can find no user space code that uses these options:
That is correct (I mean I am on a digital line), from the standard perspective. But, in the place I live, it has come to my understanding that nothing abides to the standard procedures. One never knows what is around the corner. So, I just wanted to try it out of desperation, even if I know may not have an impact. 
Very generous of you! I could upload the clip containing the incoming DTMF signals once back in the office.
That is what I have been asking repeatedly the guys on the telco side to confirm. And I have been told they are the clock source, which I am not so sure about. Because, till today, the beginning part of the IVR was not audible (was missing), which I always related to the noise. But this morning I just made a new arrangement in timing, which resulted in the display of the whole message correctly. Meaning, I just feel like I left to myself, and cannot trust what is claimed by the telco.
The telco would normally always be the clock source.
I read somewhere, I can’t refer back now, someone with similar problem asked for help to disable hardware DTMF detection without the need to dismantle the hardware echo canceller. So, he was directed to find a row in the source files and make the adjustment there. Following that suggestion I tried to find something related to it in the “c” files in vain. So, tomorrow I am planning to dismantle the same component and see if it has an effect for me too.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.