DTMF issue with Aastra phones

General Help
1

I’ve got a couple of locations that are having the same problem. This has been going on for … ever (3yrs).

They all have this in common:
Aastra Phones
Rhino Ceros box
PRI (Rhino PRI TDM)

Users have a problem hearing DTMF tones during a conversation.

I can change:
In the web GUI on the Aastra handset - “Global SIP” section, make the following changes:
Under RTP Settings:
Force RFC2833 Out-of-Band DTMF - UN-checked
DTMF Method - changed to SIP Info

That will correct the DTMF issue, but then touchtones will not be recognized if you dial into an interactive menu e.g. enter your CC number using the touchpad, some of the digits are heard twice or not at all.

2

detection is often a tricky problem, ultimately you VSP will need to undertsand what your dtmf is saying, normally in freepbx dtmfmode=auto will work on your trunks but you might need rfc2833 or info depending on the abilities of your VSP, inband will only work with ulaw/alaw and only on a pristine network.

If you overide that signalling on your phone and many older versions of Asterisk are fraught with properly transcoding those signals, then you will might well have a problem.

One possible way of getting down to basics is to use an fxs analog phone on your local system to check, this will guarentee that you are using ulaw/alaw from the “endpoint” to talk to your serverm on the localnet with no “clever” shit in the way, you can try anything else but beware of so stated “clever shit”, how the server trsanscibes that successfully to the VSP is a “black art” try a few remote IVR’s etc. if you get the signalling right with the VSP then move on to the next stage, some VSP’s have trouble with Sonus endpoints (many banks) that is their problem and there is nothing you can do but bitch and whine to your VSP to properly reroute such calls to a sonus friendly network.

The other possibility is to try another VSP, believe me some are better than others.

Basically don’t change it on the Aastra’s change it in your trunks.

Good luck and welcome to the the bemused “dual tone multi frequency” over voip klub.

dicko

3

I failed to mention, that this doesn’t always occur, but when it starts, it’s consistent. Rebooting the phone has no affect.

4

This is one of the most complicated subjects in VoIP and very difficult to troubleshoot. This is a bit of a dissertation however I hope it gives a better understanding of why talk off occurs and that it is not easy to eliminate when we converge the analog and digital worlds.

First to clarify a a point, DTMF would never be transcoded unless the inband method was used.

The symptom the OP is describing is called “talk off”, it happens when the DTMF receiver code (it’s all DSP’s) “falses” and regenerates the tone on the distant end. SNOM’s are horrific for this issue, Aastra’s are next.

In order to understand why the phenomena occurs a review of how VoIP handles DTMF is useful.

DTMF is as pointed out dual frequency. If you visualize the two sine waves of the tones they will cross at a certain point. In the early day this was done with filters. When the tones crossed the filters would conduct and decode the tone. There are 8 tones total arranged in a matrix of 4x4, this gives 16 tones (the ABCD tones are not used anymore). Here is illustrations of both:

If you look at the basis function where the purple and green waveforms cross, that is the point of the tones detection.

As was pointed out this is useless technology in the digital age. It was originally designed to transmit the data (2^4) over an audio link.

However we are stuck with it.

Compressed CODEC’s often used in voice do a terrible job of reproducing sine waves such as DTMF. In order to get around this limitation the DTMF is detected by the endpoint (phone) and converted to out of band data.

Two popular formats exist:

1 - RFC2883

This uses specific data words inserted into the RTP stream. Software at each end recognizes the data pattern and reproduces the DTMF tone.

2 - SIP Info

A SIP info message is utilized to send the DTMF

The data is never transcoded, the key to the two methods is they must be configured the same on both ends of the session.

Asterisk has a method called auto that will try and figure it out. It is less than perfect in practice.

You can use one method on your trunks and one method on your phones. Asterisk has it’s own internal DTMF architecture that is used as the common denominator.

VoIP providers redirect traffic to gateways that are located close to the rate center you are calling to reduce toll charges. Keeping track of thousands of gateways owned by many different providers is a challenge. If these gateways do not use the same DTMF method you will have intermittent DTMF recognition and transmission.

Lastly, if you are using a non-compressed linear CODEC (ulaw or alaw) you can choose to leave the DTMF as audio. This method is called inband and the tones are digitized along with the speech. This is the least reliable DTMF transmission method.

The talk off often occurs when the digital audio level is very high (loud speech patterns).

I have found that using RFC2833 to your endpoints is the most effective way of reducing talk off.

5

OK …

So … it’s going to take me a while (days) to properly digest this information, and implement it. I will follow up with the steps I take to troubleshot/correct the issue.

Thank you for the information. Having too much information is good. I’m in this for the long haul, so I need to properly understand.

6

Further and to be informational and trying to supplement Skykings analysis, on an Aastra, If “Out of band” DTMF is unchecked, the dsp (digital signal processor) in the phone will suppress the dtmf signal as soon as it is “heard” and “transcode” in the raw sense , ie, replace that inband dtmf with an inline sip info or rf2833 “signal” as otherwise chosen, you will not hear anything but the tiniest “blip” at the beginning of a detected dtmf sound whether it be a legitimate dtmf signal or “talk off”, so as you OP stated you will hardly hear any dtmf but the ongoing SIP conversation will be semi aware of what is going on.

I suggest that we are not talking talk off here but local dsp suppression, as the dtmf is either played inband or not depending on the Aastra local setting. The asterisk box will further attempt to do exactly the same as it monitors the raw audio stream, and similarly process the same audio stream plus the added complication of the added SIP messages, here we have to decide out who has the bigger balls to authoritatively process that “flow of dtmf conscience”, I suggested that you let your Aastra phones defer to Asterisk as in my experience two clever peers will often knock heads on this, Asteriks is ultimately the “authority” on what gets passed downline, if there are too many cooks in the kitchen, occasionaly both will get bruised and Bank of America will not let you log in. . .

Just my two cents worth, been there done it, both with Aastras and BofA, Capital One, the Jury Duty processing system in California et al. (that last one not working hurt :slight_smile: )YMMV of course, it is the nature of dtmf “standards” over VOIP, again thank you Sonus :wink:

I concur with skyking though that in a “controlled environment” rfc2283 will work between your Aastrii and your Asterii, this is the default for both systems. So if problems remain, look downline at your VSP/

7

edited

8

Dicko,

You are a hair above my math level. If two sine waves are produced in phase of different frequencies the waveforms will cross at some point. This crossing point is what the detectors are looking for.

I am not a mathemtician. I know how to fix things, especially analog circuits. I do understand in basic terms how FFT’s work. I would imagine some sort of polar chart would have more illustrative value.

When I designed circuits to detect tones we had the 8 tone decoders. They would simply be BCD encoded and when the two would fire off you had your data. These were analog filter R/C devices. If the tones got “twisted” for lack of a better term (looking at a scope) like they would through a side band microwave the decoders would not work. You would line these things up using a tone generator and a dual trace scope to produce a Lissajous pattern. When it stopped spinning you were good to go.

I pilfered those documents off the web to illustrate my point.

What I imagine in the FFT world to create the talk off issue (I have experienced this myself) is when the CODEC is saturated at the upper end of the dynamic range you run out of bits to encode the data, this highly saturated data falses a poorly written DTMF code in the DSP.

This has been my educated guess, certainly I would like to learn more and if you think I am wrong, especially in how I am applying my knowledge to explain why talk off happens then please enlighten me. This is great stuff.

The sad thing is we can understand why it happens but the phone manufacturers have to write better code to truly fix it. Anything we do is to mitigate at best and not solve the issue.

9

Sorry, I tried to let yopur post go but . . .

They are truly pretty pictures but misleading surely, most cosines will lag the same sine by 90 degrees ;), hence your “basis function” is trivial and nothing to do with “tone detection”, the bit you did not expand on is the cross product f(x) of the row and col. of the out of phase tones (row, col), this “energy” is what the fft (fast fourier transform) dtmf detection algorithm does.

I don’t mean to bust your chops as you are normally correct and righteous but rigor is surely to be preferred over bs here, I would prefer the OP does not get confused by wrongful math or analysis of a basic algorithm :slight_smile:

regards

dicko

10

in fact they will cross many times, it is not the crossing but the additive energy, this is why it works when you “bucket” the energy in each frequency band. and dtmf has a well defined (4x4) set of cross products, this makes it quite easy to analyse with fft transforms

DTMF processing needs to be left to the guy with the biggest balls
the fft process needs to be left to the guy with the biggest balls

Asterisk unless running on an arm/pfsense/wrt type thingy will always have bigger balls than the embedded Aastra cpu.

I have danced around this maypole for many years, there is no one solution, but kicking the sous chef out of the kitchen is often a good start until you trust her. . . . (Aastra is good but no Jamie Oliver)

. . . .

We will meet down line I am sure, we did before, but that was a long time ago when I was still a kitchen hand.

regards

dicko

11

We have met?

So your suggest is to use Inband for the endpoints and RFC2833 for the trunks and let Asterisk do the detection?

This seems counterintuitive with lossy CODECs as you want the infofmation out of band before the coder gets a hold of it.

For the lurkers Coder is the CO in CODEC coder/decoder.

All the lossy CODEC’s resuce the dynamic range so significantly that inband signalling seems impossible.

On the simpler end, why would the phone need to do an FFT? It simply encodes the kepress and decodes the message on the other end. Am I missing sometning?

12

We have, I think it was in my trickybox days, that says how long ago!, I believe we disagreed about something trivial :slight_smile: but that was then and I suffer from CRS.

No I am suggesting rfc2833 as it is easy and works with g729 ( at least the legitimate one) g711 et al. It will not supress DTMF in the rtp path, but will “clue” the downline server that a DTMF event has occurred, there are many problems with asterisk versions before current, particularly in 1.6 and 1.4 and various releases, that will miscode dtmf evnts and produce them as double or none so I find that keeping up with asterisk will either help or hinder the process, Using 10.6 or 1.8.7 seem stable to me, I hope they both stay working.

13

I’ve read you guy’s posts, I printed them out, I’ve highlighted stuff, and re-read it.

So … I am not really a chef in the kitchen, I guess I’m more like a decent server that knows the menu, and has years of experience in the food industry (if that doesn’t mix metaphors too much)

Here’s a dumbed down understanding, please let me know if I’m off

The end users complains of beeping sounds during the conversation - that is called “talk off.” It happens when somehow the codec? misinterprets the audio, voice communication, as touch tones (which I used to think was DTMF - but I now know, I’m pretty igonorant about the whole process, and doubt my simplistic understandings).

In the past - and up to now, I would log into the phone, and remove the RFC2833, and change the DTMF method to both SIP and RTP, instead of just SIP.

Now - from what it seems like you guys are saying - that is opposite of what you would suggest, but then again maybe Asterisk pushing it Out-of-band - cause it has bigger balls. The network is pretty clean, so maybe that is better - it’s all dedicated IP with a PRI trunk.

I get that I should handle this problem at the PBX and the VSP (voice service provider?) - but I’d screwed around with the phones at this point, so I feel like I need to get the to a baseline before I change other stuff - I need some control here.

So at this point, this is what I’ve done
1 - I left the Force RFC2833 OFF on the Aastra handset, this appears to clear up the “talk off” - which is the most important
2 - I changed the DTMF method to RTP - my ignorant logic was that using RTP for the DTMF method more closely matched the in-band, and it’s the only other option, I’ve not tried yet.

I’m going to ask the end user to evaluate the quality, and I’ll go back and check the PRI settings with the PRX. I remembering it being pretty straight forward, simple, but that does not comfort me at this point.

14

A couple of clarifications, semantics but relevant.

1 Touch Tone is a Western Electric/Bell Labs trademark term for DTMF.

2 A CODEC is a format, a method of communications. No physical component is a CODEC. It is a step in the A to D proceess.

3 PRI’s only use inband for DTMF as a PRI uses a T1 or an E1 as transport. The B (bearer) channels are DS0’s, they use linear PCM encoding.

4 I don’t have an Aastra admin guide in front of me. Not sure what RTP method is. RTP is the protocol that transports the audio. RFC 2833 uses RTP to encode DTMF using bit robbing. Inband simply encodes the tones with the rest of the audio.

With Asterisk being open source you are in the position of having to integrate all of this. Closed source systems have this all worked out.

No doubt this is a pain.

15

(not sure anyone is reading this, but it’s helpful to me to have it documented)

So, after about 6months of user testing, it appears that changing
1 - Force RFC2833 OFF on the Aastra handset, this appears to clear up the “talk off” - which is the most important
2 - Changing the DTMF method to RTP - corrects the users inablity to navigate menus, other system IVRs, or entering CC information over the phone.

Now it appears that with these settings, user can not enter their password from the Comedian Mail menu. e.g. they press *97, then when they press their their password (e.g. 1111) it is unrecognized.

16

i found this in a trixbox forum digging for answers and have had no issues since implementing the change; it was a 2008 post but still did the trick for me… Support could not tell me why it worked and actually said it shouldn’t have had any effect - yet it was the only thing that ever made a difference

"Fix for DTMF issues

Sat, 05/08/2010 - 7:37am

Good morning,

We have deployed literally hundreds of the Aastra phones and the fix that we found for this (after much testing as well as reading through many forums) was to put the following into the aastra.cfg file.

Set DTMF Mode

sip dtmf method: 1

sip out-of-band dtmf: 0

What this does can be seen in the web GUI by looking at the “Global SIP” section, you will see the following changes:

Under RTP Settings:

Force RFC2833 Out-of-Band DTMF - will be UN-checked

DTMF Method - will be changed to SIP Info

You can also make this change manually if you prefer to test for yourself and confirm that the random DTMF tones are gone.

If you are using the autoconfig scripts you should be able to get this change onto the phones by logging off and then back onto the phone.

Let us know if this works for you so it can be helpful to others as well.

~Rich."

17

Just to confirm - because I ran across this, again today.
1 - Force RFC2833 OFF on the Aastra handset
2 - Changing the DTMF method to SIP info

This appears to correct all DTMF issues