So you have shown that Wireshark is capable of dissecting SIP and RTP packets to identify DTMF digits being transmitted. You should study how this is achieved (e.g. from RFC 4733) and study the captures you have to see how it's done in that particular case.
Whether Wireshark can show this or not depends on a multitude of causes, e.g. the encodings used, the preferences set, the protocol elements present in the capture file and the capabilities Wireshark has to correlate all these combinations. I'm not saying there can't be a bug, but it's usually capable of working out the most common cases. It's your job to find out whats going on in detail, hopefully with the packet dissections that Wireshark gives you and the protocol specification in hand.
Asked: 2017-12-24 00:16:56 +0000
Seen: 654 times
Last updated: Dec 26 '17
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Just tried with SIP_DTMF2, works fine. Can you confirm with that file?
Jaap,
I confirm: Wireshark 2.4.2 works fine. Wireshark 2.4.3 works fine. Why does not work fine with the capture files I have ? I am capturing with Wireshark 2.4.2.
Regards
Maybe something else is going on. At least we know that the sample capture works, so what's the difference between that and yours? Analyse the protocol details and you'll find out. That is what this program is for.
Jaap,
Please tell me where I can analyse the protocol details.
With Wireshark portable 1.6 I can see the DTMF digits in the call flow.
However with Wireshark 2.4.3 I can not see the DTMF digits in the call flow.
Regards
Jaap,
I went to menu Analyze --> Enabled Protocols... In the check box of RTP I checked rtp_udp box.
Somtimes I can see the DTMF digits in the call flow others not. This happens for both Windows and Linux version of Wireshark.
Looks like a bug in Wireshark.
Do you know if this bug is documented ?
Regards