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