DTMF tones

[Xponder1]

Out of curiosity, how long have you had STUN on? Depending on the network setup in some cases STUN can force the audio to be routed directly instead of being proxied regardless of what we set it to do.

Has it always been enabled or was it enabled around the time this started?

If STUN wasn't on for a reason, let's try disabling it (and rebooting) and see if that solves it since it being disabled will make sure the audio preference is followed.

I turned STUN on last night trying to resolve the other issues I am having. I did not really think it would make any difference (and it didn't). I have never needed a STUN server and have not changed my setup. As you requested I turned it back off.

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.

[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.