I've run across a major issue with these units with regard to DTMF. They DO NOT filter the user's tones when dialing towards something that needs DTMF. Our gateways and SIP providers expect DTMF to be sent via AVT (RFC2833).
What's happening is that it is impossible to dial digits towards voicemail systems, conference systems, etc.
The way these ATAs operate is a major departure from the way the SPA-2102, and other ATAs operate. It's expected that if the DTMF method is AVT, then the originally dialed DTMF will be filtered, or at least as much of it as is practical. The SPA122 passes complete decodable inband DTMF in addition to creating AVT (RFC2833). This results in whatever is on the other end hearing the original digit, AND the results of the AVT.
Some history and maybe some design info here:
While it takes a bit of time to detect the tones on the part of the ATA, as soon as the input is identified as DTMF - even if it's not been determined if the tone is long enough, or what digit it is, the audio path must be split. Early DTMF decoders had something called early line split, or something along those lines. That basically interrupts the audio path when the decoder "thinks" it hears what might be DTMF. That keeps double digits, etch from happening.
In the case of an ATA, since there's some delay going on due to the nature of RTP audio, there exists the possibility of even muting the audio prior to the beginning of decoding the digit since the audio is still in a buffer prior to being transmitted.
None of that is happening on the SPA122. It passes tones that are nearly as long as the user is pressing the touch tone pad.
The SPA2102 works reasonably well - not perfect, but at least it mutes most of the originally dialed digits much of the time when it's converting to AVT.
I have attached two .cap files. Both were calls to a voicemail system and 1 2 3.... 0 # was dialed twice on each call. The voicemail reads back what it hears digit-wise, which correlates back to what you see when you decode the RTP stream with wireshark.
spa122.cap - unit starts as completely defaulted except for sip user, sip password, and sip proxy.
1st call - default 70 ms, strict
2nd call - 70 ms normal
3rd call - 30ms normal
4th call 30 ms strict
Absolutely no change visible in what it is doing to the tones regardless of settings.
spa2102.cap - unit starts as completely defaulted except for sip user, sip password, and sip proxy.
1st call - 40 ms strict - this is the spa2102's default
2nd call - 70 ms, strict
3rd call - 70 ms normal
4th call - 30ms normal
5th call 30 ms strict
There are differences in the slight tone blips depending on how the ATA is set. 40 ms normal seems to work well, although the occasional decodable tone sneaks through.
This is on Beta FW 1.2.0(038), but the problem exists all the way back to 1.0.1 as comes on the units.
I've attempted to open a case for this, but sitting on hold for over an hour is unreasonable. If a Cisco engineer sees this - this is my hope since it seems the primary support for this is apparently via the online community - feel free to give me a call via my profile contact info. At the very least, everything needed to reproduce this is included in this post.
