My incoming DIDs use RFC2833
My extensions are configured for RFC2833
My ATA’s are configured for RFC 2833
yet I constantly get the error message:
“WARNING[9835]: dsp.c:1353 ast_dsp_process: Inband DTMF is not supported on codec g729. Use RFC2833”
We are using the new distro. Can anyone help?
DCI, you are a trip, you really lack some fundamentals to be in the business.
I do love to teach so a lesson on DTMF is in order.
DTMF stands for Dual Tone Multi Frequency, invented by Bell Labs and originally marketed under the name “Touch Tone” it replaced the pulse method of dialing.
Later as computers were integrated with telephony DTMF was the only means of the user communicating with the CTI platform. Digital Paging is a great example of how DTMF was utilized by an external platform. Of course later Voice Mail and fully interactive IVR’s came along.
The Dual refers to the fact that each tone actually consists of two tones.
The keypad is layed out in a 4x4 arrangement (the ABCD column was used for signalling applications)
Tone 1 Tone 2 Tone 3 Tone 4
1 2 3 A | Tone 5
4 5 6 B | Tone 6
7 8 9 C | Tone 7
0 # D | Tone 8
So if you press button two for example tone 2 and tone 5 are mixed together to produce the DTMF tone.
This results in an overlap of two sine waves. If you can envision two sine waves of equal amplitude and different frequency at two places the wave forms will converge. This cross point is how DTMF is detected. It used to be done with filters, now those filters are emulated in software.
So how does this differ with CODEC’s you ask? This is where it gets somewhat more complicated.
g.711 is a lossless or linear CODEC, the waveform is reproduced within the numerical constraints of the sampling rate in a 1:1 relationship.
g.729 is a highly compressed CODEC that uses very advanced techniques including variable bandwidth depending on the Annex used (g.729 uses Annex instead of versions)
Lossy CODEC’s such as g.729 can’t reproduce the complex DTMF waveform with sufficient fidelity to allow it to be reliably decoded at the far end.
To solve the issue various Out of Band signalling methods are utilized to send the number DTMF and regenerate it at the far end. “In Band” coding refers exactly to what it describes the DTMF tones are transmitted in the RTP payload.
The out of band methods encode the DTMF in various methods as described below:
SIP Info: Sends a SIP info message for each DTMF keypress
RFC2833: Encodes the DTMF keypress in a special packet in the RTP stream
Either of these methods work fine with any lossy CODEC.
The key to successful DTMF coding is continuity of encoding method. Each voice hop that involves transcoding should be audited for DTMF method continuity.
As a for instance in Asterisk:
Phone DTMF method must match the peer method
Trunk DTMF method must match the provider method
If Asterisk SIP reinvite is used the Phone or endpoint encoding method must the provider as SIP sends the DTMF method in the SDP (Service Description) message.
This is critical information that must be understood to deploy a carrier class voice system.
I hope this explanation sheds some light on a complex subject.
Well I think that’s the best description I’ve ever seen. I had already figured out what I needed to do but now I actually understand why =)
Cheers
@skyking: OK at first I was a bit upset about your potentially offensive comments but I know you mean well and at least so answered my post, so I got over it and started thinking. My mssg stated already that our provider sends RFC2833 and our endpoints are also configured as RFC2833. Asterisk is of course also configured that way so in theory I should not get the error. Then I went back and checked all the ATAs our new tech configured and voila they were set to AUTO instead of RFC2833. Thanks for pointing me in the right direction.
@mrgoblin: If you know what to do you should share because others may not know and that’s the point of this forum.
@both: Thanks for replying to my post in the first place. It helps to have an active forum where people can challenge each other and exchange ideas.
Unfortunately I was referring more to the
[quote]Phone DTMF method must match the peer method
Trunk DTMF method must match the provider method[/quote]
part of it and have not see the error you mention.
Twice now I’ve had problems with my IVR’s not working and both times it’s turned out to be my provider making changes.
If I did know the answer to your specific query I’d certainly share it.
I"m a veteran Linux user but very new to the telephony world and while I can sometimes offer suggestions, I’m also very aware that bad advice can often be worse than no advice.
Providers changing settings are a real problem. My company is a local ITSP and we don’t have this problem on our Level 3 trunks. They clearly follow proper change management on their soft switches just like they do in the circuit switched world.
Packet Switched carriers don’t seem to have as evolved a process and frequently change configurations on working switches.
The problem is Level 3 and I am sure Global and XO are the same way, the minimum monthly commit is huge. $5k is usage just gets you in the door.
Well of course that’s my Interpretation of events.
I had to change the trunk dtmfmode from rfc2833 (worked for 4 months) to auto which worked for a couple of months after which I had to change to Inband.
We are probably only a $2kpm account but as you say, some notification would sure have been nice.
For 2k a month you sure should get better service than that!
Is this in the US? What carrier?
Snap Internet. They are both ISP and ITSP for us.
Being kind of new at this game I often doubt myself first (at least until I can prove otherwise =)
Overall their service has been great especially considering that their main Data Centre is in the quake stricken Christchurch.
to exonerate myself 
here is what is happening (IMHO).
We use g729 and allow sip fax detection for fax2email delivery.
When calls come in Asterisk starts CNG detection and wrongly posts the error mssg that inband dtmf are not allowed. I think it’s a bug because the error message is misleading and in fact dtmf detection is not affected but the guys at asterisk.org disagree.
https://issues.asterisk.org/view.php?id=19103&nbn=4
G.729 and fax don’t work together for the same reason g.729 does not work with inland Coders
but alaw allows fax and inband dtmf. The provider sends alaw and Asterisk answers the inband leg in alaw and checks for a fax. The extension however is g729 and gives the error message.
Skyking, didnt read this till now best explanation on the whole DTMF aspect…
We’re not worthy!
