Showing results for 
Search instead for 
Did you mean: 

SPA122 - AVT DTMF from station to server causes audio path lockup


SPA122 running Beta FW 1.2.0 (Although this bug is present all the way back to 1.0.1)

Start with a completely defaulted ATA. Configure proxy address, sip user, and sip password.

Originate a call from the FXS port. After call is answered by far end, dial with the touch tone pad on the phone. If you dial too quickly, the SPA locks up, and inhibits the forward audio path from the FSX port towards the called party - at least that's how it appears because the called party can't hear you, but you can hear them on the analog phone connected to the FXS port.

I say appears because examining the packet capture - attached - the ATA actually is getting confused into sending a continuous stream of RFC2811 events with an ever increasing event duration. Hanging up and making another call results in normal conversation...until you dial too quickly for it's liking.

It's not possible to duplicate this with a "senderized" phone, like a cordless phone, or any other phone that doesn't let you dial fast, and buffers the digits so they are like 100 ms long. Use a "nomal" 2500 set with a "real" touch tone pad, and all you have to do is dial fast, and it locks the ATA up in this condition. Simple way duplicate this is to dial a call, and rake rapidly down the "2 5 8 0" and the ATA will lock up instantly.

In the attached cap file, I make a call, and answer it. I then dial 1 2 3 4 5 6 slowly. The ATA actually misses the one and the two that I dialed, and doesn't translate them to RFC2833. It does send the 3 4 5 ,and 6 correctly without issue. I then dialed 2 5 8 0 rapidly. It got locked up on the digit 2.

We use these for home based users to dial into our conference bridge, so RFC2833 has to work. We didn't have this problem with the now discontinued SPA-2102s. We saw this issue as soon as we started using the SPA-122's though.

2 Replies 2

Dan Miley

Hi Bob,

if you're having difficulty with a unit that is running beta firmware, the best thing to do is contact the escalation engineer who provided it, and let them know.

That way the issue can be quickly resolved through the engineering process.

We would be more than happy to assist you if you wish to call into the Small  Business TAC at 866-606-1866 and point to this post, we'll contact the escalation engineer, after troubleshooting, data gathering and approval for escalation.  We only support the 'released' firmware here, so this may require verifying the issue exists on the released firmware.

- Dan

Hi Dan,

I did all that.

I responded back to the original engineer, but the case was closed where the Beta FW was provided.

Ticket opened with TAC. The response from TAC was that since I was running Beta FW, there was nothing they can do as they do not handle issues with Beta FW.  That got a little hot, as these have major issues, and we customers are caught in the middle.

Where things are now is that "yes there's a problem". It's a regression that crept into the Beta FW, and it's been "sent to the developers" which takes an unknown amount of time to get a response.

I was also supposed to be send yet a newer version of Beta FW, but no link has been received.

Kind of a wierd position to be in with a commercial product as production FW 1.1.0 can't resolve DNS names for provisioning, and the Beta FW that fixes that breaks DTMF.

So, everything I can do has been done.


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers