Erft wrote: 06/29/2025
Since you asked me to make my first, second, and third codecs G711u
Make everything G711u. G729a sounds worse.
Perhaps one analogy that works for you is G729a is like listening to AM radio. G711u is like listening to FM radio. While that's not exactly true, the point is that one sounds worse than the other.
I can't stand G.729a.
I assume, then, that Inband is preferable.
No, it depends on what's being called.
Inband sends DTMF tones as audible sounds within the audio stream (what you hear and what the other person hears). If that audio stream is heavily compressed by G.729a (a lossy audio codec), the tones get distorted and become unrecognizable to the receiving IVR (Interactive Voice Response) system. Recognizing beeps over AM radio is harder than recognizing beeps over FM radio, for example. This is why Inband tends to be unreliable, especially when not using the uncompressed G.711u audio codec. This is also the reason why consumer ATAs don't default to Inband.
Inband relies on what is heard. AVT does not.
AVT sends DTMF tones (key presses) as data outside the audio stream. Because the tones are not part of the audio, it doesn't matter if you are using G.711u or G.729a for your voice stream (the audio); the tones arrive perfectly intact. This is why AVT is the modern, more reliable standard. However, in order for AVT ( (RFC 2833) to work, the receiving IVR (Interactive Voice Response) system must be set up to recognize RFC 2833.
Data (AVT) vs. Sound (Inband)
The core difference is that AVT sends a keypress as digital data, while Inband sends key presses as analogue sound carried over a digital network. Digital data is simply more robust: it either arrives correctly or it doesn't. Analogue sound can be heavily degraded by internet issues (high pings and high jitter), rendering it useless. A system designed to handle RFC 2833 (AVT) is specifically engineered to be less susceptible to the jitter, delay, and packet loss common in packet networks.
In fact, provided the receiving (IVR) system is setup to accept RFC 2833 (AVT), AVT is more reliable than Inband.
As I stated before, there are certain circumstances where using Inband DTMF may be necessary. For example, some door-entry or intercom systems use access panels that require audible DTMF tones to unlock doors or activate gates. Those panels lack SIP-info or RFC 2833 stacks, so in-band audio is the only way to use them properly.
If an older alarm panel or the central station receiver doesn't properly support RFC 2833 signals, communication will fail. In that case, if you were using the G.711u audio codec for the connection, trying Inband DTMF might be a last-resort troubleshooting step, as it sends the tones as audio. Most alarm communicators simply dial in DTMF over the line. They do not support RFC 2833 (AVT) or SIP INFO natively. Here's an example:
viewtopic.php?p=75441#p75441.
You may come across an Interactive Voice Response (IVR) system (such as phone banking with customer service menus) that is older or poorly configured and doesn't recognize the standard RFC 2833 (AVT) signals being sent. If your key presses aren't registering on a specific system when using RFC 2833 (AVT), and you are using the G.711 codec, switching to inband might work for interacting with that specific system.
However, generally, avoid InBand DTMF unless out-of-band (AVT) methods are failing first.
The reality is that it's impossible to guarantee acceptance by all phone systems with a single setting since different IVRs (Interactive Voice Response systems) can have unique or outdated configuration requirements. Your issue, where tones work initially but fail later (on a survey after speaking to an agent), often happens when the call is transferred to a different system that expects a different DTMF method than the one your ATA is using or has already negotiated.
Obihai 2xx/3xx/Poly 4xx ATAs seem to have an advantage over other consumer ATAs:
viewtopic.php?p=82479#p82479. However, even then there's no 100% guarantee.
Is AVT G729a?
No. AVT is Not an audio codec. G.729a is Not a DTMF Method.
AVT (RFC 2833) is a method for sending DTMF tones as separate data packets, independent of the voice audio. The audio codec used doesn't matter with AVT.
G.729a is a low-bandwidth audio codec that compresses your voice to save data. It sounds worse than G.711u. Don't use G.729a.
G.729a provides noticeably worse voice quality than G.711u. With modern internet connections, the bandwidth savings (G.729a uses less data than G.711u: 8kbps vs. 64 kbps) are negligible and not worth the trade-off. Bad sound quality affects Inband DTMF--but it doesn't necessarily affect AVT. If your ATA were ever to negotiate a call using G.729a and you had Inband DTMF set, your keypresses would be guaranteed to fail.
Sticking with G.711u as your only enabled codec simplifies troubleshooting.
Do you think that would give my phone line more options when encountering specific systems (they both use Bell) and enable me to call through?
No. The problem you describe (ringing for two minutes and then being prompted for a remote code) is not a symptom of an audio codec mismatch. Bell's network is fully capable of handling G.711u calls. This symptom points to a signalling failure where the receiving system doesn't correctly identify your call.
Your ATA's firmware is 1.3.3 (115), while the latest version is 1.4.1 SR5. That's a significant gap.
The SPA122 is known to have a specific bug in older firmware where it sends a "double-digit" signal (both an AVT packet and an Inband tone), which can confuse IVR systems. That could be causing problems for you. Firmware updates often contain a bunch of small fixes for compatibility with various carrier networks and systems. Firmware updates can improve performance. Frankly, I would update firmware.
Again, I accept no responsibility for failed firmware updates.
After updating, I would use “Auto” for DTMF TX method, unless a a IVR system I try to call fails. Then I would try to see whether AVT or Inband works for that specific system.
