DTMF tones

[VOIPoTim]

I noticed that in Vpanel there is a option for support and it has a recent ticket summery but it only has two old tickets? Were you aware that tickets do not show up there?

Thanks,

Edited out part of the above after getting a reply from support.

Have support verify the email associated with your vPanel account. The tickets are linked through e-mail.

[dswartz]

Confused about something here. If the false tones happen because the ATA hears a sound from the other end that it mistakes for a DTMF tone, why would making the setting "Inband" fix it? If the ATA is doing RFC2833, why would this ever happen, since it would not be looking for DTMF tones in the inbound audio stream? Obviously, I am misunderstanding something here...

[VOIPoTim]

Confused about something here. If the false tones happen because the ATA hears a sound from the other end that it mistakes for a DTMF tone, why would making the setting "Inband" fix it? If the ATA is doing RFC2833, why would this ever happen, since it would not be looking for DTMF tones in the inbound audio stream? Obviously, I am misunderstanding something here...

It doesn't make complete sense to me either (or I'm misunderstanding it) but check around on Google and there are tons of PAP2 situations where changing it to inband fixes completely with a bunch of different providers.

I think it's some kind of bug they have, but it happens with so few people they refuse to look at it.

Whenever we've had reports of it, that almost always fixes it.

[bwarden]

In RFC2833, the ATA is listening on the local port for DTMF. When it thinks it senses it, it sends an out-of-band message. Wherever the call enters the PSTN, the corresponding DTMF sound is regenerated and inserted. If the DTMF detection in the PAP2T is buggy, it will mistake speech, generate an out-of-band message to the PSTN gateway, and that gateway will regenerate the tones as instructed.

With inband DTMF, the ATA just passes through the audio unchanged, without itself attempting to detect DTMF, so normal conversation is uninterrupted. The problem is that with various compression schemes, while speech is still intelligible, DTMF is sufficiently damaged that an IVR at the other end will have trouble recovering it.

[dswartz]

But what people are reporting are false DTMF tones inbound, not outbound, so I am not getting how tweaking any of these settings would change that (except as Tim said, maybe a PAP2 bug?) FWIW, I don't have NAT or STUN or a PAP2 (I have a GS503 unit), and I still hear this sometimes

[sommerfeld]

But what people are reporting are false DTMF tones inbound, not outbound, so I am not getting how tweaking any of these settings would change that (except as Tim said, maybe a PAP2 bug?) FWIW, I don't have NAT or STUN or a PAP2 (I have a GS503 unit), and I still hear this sometimes

At least three posters (myself in #3 on this thread,
mrkarron in #5, and TomP in #6) heard false outbound DTMF tones listening on a non-voipo phone when a female was speaking on a voipo phone.