[VoiceOps] ATA CPE and RFC2833

[Ryan Delgrosso]

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

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?
>
> Ta.
>
> --
>  Peter Childs - Voice Engineer
>  Internode/Agile
>  Ph: 08 8228 2380 Mb: 0406 388 405 Fax: 08 8235 6801
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120216/457e0ab7/attachment.html>