×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

SPA122 - AVT DTMF does not filter inband DTMF tones

Unanswered Question
Jul 30th, 2012
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
powerinternet Fri, 12/21/2012 - 10:03
User Badges:

Hello Daniel, Bob


Have there been any udpdates from Cisco regarding this issue, I have exactly the same issue myself and don't have SIP INFO support on my SIP gateway, so I am constrained to use either In-band DTMF or RFC2833 DTMF (AVT on the SPA122) and the In-band solution does not work.


I would really appreciate any response you can give.


Regards,


Mark.

Daniele Giordano Fri, 12/21/2012 - 10:22
User Badges:
  • Gold, 750 points or more

Do you have already try the firmware version 1.2.1?


Regards.

powerinternet Mon, 12/24/2012 - 01:52
User Badges:

Hello Daniele,


I am currently using the latest firmware, version 1.2.1 (004).


Thanks,


Mark.

powerinternet Mon, 12/24/2012 - 04:41
User Badges:

Hello Paul,


That firmware has fixed this issue!  Terriffic!  What  is this firmware, a home cooked one, or do you work for Cisco and this  is a test/development firmware? Will there be an official one including  the fixes in the future?  What is difference between the version 1.2.1  and 1.3.1?


Thank you very much for your help,


Mark.

Actions

This Discussion

Related Content