[VoiceOps] ATA CPE and RFC2833
ryandelgrosso at gmail.com
Thu Feb 16 18:08:46 EST 2012
I have seen a similar scenario play out when transmitting DTMF via
RFC2833 when the negotiated codec is G711, and the gateway is configured
to accept both in-band and RFC2833.
What we eventually found was happening was a faint echo of the DTMF as
produced by the handset as user-feedback was echoing back into the
handset microphone, and causing a faint "echo" of dtmf so there was
faint in-band, as well as rfc2833 event packets, and the gateway would
try to render them both. This naturally caused all kinds of headache. As
a litmus test, you might switch the negotiated codec to G729 and see if
the DTMF gets more reliable since it takes the in-band confusion off the
We had this exact problem with a very large tier 1 carrier whose border
controllers are configured to accept both in-band and RFC2833, and
re-constitute it all into in-band across their core, and we wound up
getting duplicate digits out to the PSTN for no reason we could discern.
On 02/15/2012 10:40 PM, Peter Childs wrote:
> Gday folks.
> I'm working through one of those lovely DTMF issues and have notice
> that a particular CPE that is experiencing a DTMF fault on our network
> sends both rfc2833 rtp packets _and_ the tone in audio stream (not
> named rtp packets, but how the device has 'heard' the tones from the
> originating handset).
> Just wondering if this sounds 'normal', or is common, or is broken.
> It appears to be causing the media-gateway on our end to sends some
> pretty awful junk to line (ds0) that is not recognised by most 'PSTN'
> connected equipment.
> Thoughts or comments?
> Peter Childs - Voice Engineer
> Ph: 08 8228 2380 Mb: 0406 388 405 Fax: 08 8235 6801
> VoiceOps mailing list
> VoiceOps at voiceops.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the VoiceOps