ATA CPE and RFC2833
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
On 02/16/2012 01:40 AM, Peter Childs wrote:
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).
Out of curiosity, how did you arrive at this conclusion? If you play back such a stream in, say, Wireshark, it will generally inject some sort of acoustic tone when it encounters the out-of-band named events. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
In a isolated environment I plugged one of our lab switching nodes (ip->tdm) into a loopback device on the other side to 'loop' back audio. Using a soft-client that only sends rfc2833 (rtp.p_type==101) I can 'see' the DTMF digits in both directions (and hear them fed back via the loopback), however in Wireshark (1.4.2 on MacOSX) they generate no visible or audible artefacts in the RTP stream playback (they are visible in the capture, and the 'flow diagram'). Then using my suspect ATA I see rtp.p_type==101 digits again (and confirmed by 'debug voip rtp named-event') however in my wireshark RTP stream I can 'see' audio and 'hear' it as well as seeing the nte events. I also just created a 'display filter' in wireshark 'rtp.p_type != 101 || mgcp' to show only the MGCP and RTP (without named events) and then saved a copy of only displayed packets. Loading this capture (the filtered capture) and decoding the voice playback shows audio tones in packet. -- Peter Childs - Voice Engineer Internode/Agile Ph: 08 8228 2380 Mb: 0406 388 405 Fax: 08 8235 6801 On 16/02/2012, at 6:29 PM, Alex Balashov wrote:
On 02/16/2012 01:40 AM, Peter Childs wrote:
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).
Out of curiosity, how did you arrive at this conclusion?
If you play back such a stream in, say, Wireshark, it will generally inject some sort of acoustic tone when it encounters the out-of-band named events.
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Ah. Well, then it's pretty definitively a buggy ATA. :-) On 02/16/2012 03:16 AM, Peter Childs wrote:
In a isolated environment I plugged one of our lab switching nodes (ip->tdm) into a loopback device on the other side to 'loop' back audio.
Using a soft-client that only sends rfc2833 (rtp.p_type==101) I can 'see' the DTMF digits in both directions (and hear them fed back via the loopback), however in Wireshark (1.4.2 on MacOSX) they generate no visible or audible artefacts in the RTP stream playback (they are visible in the capture, and the 'flow diagram').
Then using my suspect ATA I see rtp.p_type==101 digits again (and confirmed by 'debug voip rtp named-event') however in my wireshark RTP stream I can 'see' audio and 'hear' it as well as seeing the nte events.
I also just created a 'display filter' in wireshark 'rtp.p_type != 101 || mgcp' to show only the MGCP and RTP (without named events) and then saved a copy of only displayed packets. Loading this capture (the filtered capture) and decoding the voice playback shows audio tones in packet.
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Are you certain payload type 101 was the one dynamically assigned by both sides of the call? It would be specified in the m= line and assigned in the rtpmap attribute. On Feb 16, 2012, at 3:47, Peter Childs <PChilds at internode.com.au> wrote:
In a isolated environment I plugged one of our lab switching nodes (ip->tdm) into a loopback device on the other side to 'loop' back audio.
Using a soft-client that only sends rfc2833 (rtp.p_type==101) I can 'see' the DTMF digits in both directions (and hear them fed back via the loopback), however in Wireshark (1.4.2 on MacOSX) they generate no visible or audible artefacts in the RTP stream playback (they are visible in the capture, and the 'flow diagram').
Then using my suspect ATA I see rtp.p_type==101 digits again (and confirmed by 'debug voip rtp named-event') however in my wireshark RTP stream I can 'see' audio and 'hear' it as well as seeing the nte events.
I also just created a 'display filter' in wireshark 'rtp.p_type != 101 || mgcp' to show only the MGCP and RTP (without named events) and then saved a copy of only displayed packets. Loading this capture (the filtered capture) and decoding the voice playback shows audio tones in packet.
-- Peter Childs - Voice Engineer Internode/Agile Ph: 08 8228 2380 Mb: 0406 388 405 Fax: 08 8235 6801
On 16/02/2012, at 6:29 PM, Alex Balashov wrote:
On 02/16/2012 01:40 AM, Peter Childs wrote:
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).
Out of curiosity, how did you arrive at this conclusion?
If you play back such a stream in, say, Wireshark, it will generally inject some sort of acoustic tone when it encounters the out-of-band named events.
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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
participants (4)
-
abalashov＠evaristesys.com -
lindsey＠e-c-group.com -
PChilds＠internode.com.au -
ryandelgrosso＠gmail.com