This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RTP DTMF digits are no longer displayed in VoIP graph analysis

I discovered today that, Wireshark 1.8.6 does not display RFC2833 DTMF telephony events in VoIP call graph analysis anymore.

It was a very convenient way to see, which DTMF digits are transmitted in the RTP packets. alt text

This example displays 7 DTMF digits and is taken with wireshark 1.8.3. The same trace shows only "RTP (telephone-event)" and not which digit is transmitted anymore as of (at least) wireshark 1.8.6. Which digit is transmitted, has to be figured out at the packet view.

Is this a bug or may be enabled by a new option?

Thanks & Greetings, Chris

digits payload 2833 dtmf rtp

asked 22 Apr '13, 12:06

ChrisVoIP
11●1●1●2
accept rate: 0%

I am having this issue 64bit 1.12.4

(18 Mar '15, 16:26) Samfiller

2 Answers:

That behavior changed between 1.8.5 (shows DTMF event info in graph) and 1.8.6 (does not show DTMF event info). Looks like a bug to me.

Regards
Kurt

answered 22 Apr '13, 13:17

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

This is probably a side effect of the fix for bug 8321

(22 Apr '13, 14:07) Pascal Quantin

@Pascal Quantin: Care to elaborate?

(22 Apr '13, 14:16) Jaap ♦

@Jaap: reverting revision 47729 solves the issue. I do not have the time to dig further right now.

(22 Apr '13, 15:41) Pascal Quantin

This a regression tracked by bug 8610 and now fixed in the soon to be released 1.10rc1. The fix will also be backported in 1.8.7 and 1.6.15 releases.

answered 24 Apr '13, 08:57

Pascal Quantin
5.5k●10●60
accept rate: 30%

edited 24 Apr '13, 14:35

HI Wireshark Team, I report this problem with the latest wireshark Version 1.10.5 (SVN Rev 54262 from /trunk-1.10), the RTP DTMF digits are not displayed in the flow graph. However, the Version 1.6.8 (SVN Rev 42761 from /trunk-1.6) display the RTP DTMF digits in the flow graph for the same .pcapng file

(21 Jan '14, 06:50) krash

Could you share a capture showing the issue? The capture from Wireshark wiki http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=SIP_DTMF2.cap is working as expected with 1.10.5

(21 Jan '14, 14:38) Pascal Quantin

alt text Still not fixed in 1.10.5, subsequently it is not recognized by the rtp.event_id filter.

(03 Mar '14, 16:06) jrounds

jrounds: we can't do anything about it without the capture file. We don't need everything - just the SIP messages with the SDP, and a few of the RTP packets. According to the screenshot you pasted above, SDP did setup the RTP flow, but didn't assign it to telephone-events. So even just seeing a screenshot of the SDP protocol details window might be sufficient.

(04 Mar '14, 22:40) Hadriel

Still not fixed in R1.12.6, the DTMF number is not shown. Any idea when the fix will be available?

(30 Oct '15, 05:20) TechSupport

Please provide a capture showing the issue (even better, create a bug report on https://bugs.wireshark.org and attach the capture here). Without it, we cannot look at the issue. I just tested the capture found here http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=SIP_DTMF2.cap with Wireshark 2.0rc2 and it works fine, so it means your use case is different.

(31 Oct '15, 01:23) Pascal Quantin

Pascal, as it seems that some people are bothered by this and similar issues more than me, I'll add my observations here:

I've just tried to open the SIP_DTMF2.cap you've mentioned above and the VoIP calls flow graph in 1.12.8 on Windows 7 does not show RTP at_all (while the packet list does show some G.711 packets, so decoding of the SDPs and marking matching UDP packets as RTP does work).

(1.12.8 is the latest published stable release at the time of writing this.)

I've got other captures in my collection where [email protected] does show RTP including the DTMF symbol value, but the value is only visible if the arrow is long enough, which means that whenever the arrow goes between two directly neighbouring IP addresses in the graph, there is no way to see the DTMF symbol (or e.g. longer information contents of SIP INVITEs). Placing the mouse cursor over the arrow doesn't help, nor can the dashed vertical lines be moved horizontally. This is definitely not a bug, but the practical consequence is similar. What is the right input pipe for this "improvement wish"?
there are more real issues in addition to the first item above: in particular captures only some (parts of) RTP flows are shown, or the same RTP (sub)flow is shown several times, this leads me to a question whether to open all that as a single bug or as several independent ones, suspecting that in fact they are all caused by just a couple of root causes?

(31 Oct '15, 03:59) sindy

I just tested Wireshark 1.12.8 and indeed it was broken again. But it's working as expected in Wiresahrk 2.rc2 (as stated above).

Improvement requests must be done on https://bugs.wireshark.org (enhancement category) but be aware that the GTK UI is being deprecated and replaced by Qt UI starting from version 2.0. Don't worry, it suffers from the same sizing issue ;)

If you face issues, please create bug reports with captures. Without it, do not expect to see things improving (as without pcap files showing the issues, we cannot fix bugs). If you have a doubt, simply fill one with pcap samples. If required, we will split it in several bugs if the root causes are different.

(31 Oct '15, 11:26) Pascal Quantin

showing 5 of 8 show 3 more comments