Ask Your Question
0

RTP DTMF digits are no longer displayed in VoIP graph analysis

asked 2017-12-24 00:16:56 +0000

Hello,

I have wireshark version 2.4.2, but RTP DTMF digits are no longer displayed in VoIP graph analysis.

How can I solve this situation ?

Regards

edit retag flag offensive close merge delete

Comments

Just tried with SIP_DTMF2, works fine. Can you confirm with that file?

Jaap gravatar imageJaap ( 2017-12-24 11:37:37 +0000 )edit

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

ajosebar gravatar imageajosebar ( 2017-12-25 03:51:29 +0000 )edit

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 gravatar imageJaap ( 2017-12-25 10:28:44 +0000 )edit

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

ajosebar gravatar imageajosebar ( 2017-12-25 14:35:28 +0000 )edit

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

ajosebar gravatar imageajosebar ( 2017-12-25 14:48:13 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-12-26 13:53:16 +0000

Jaap gravatar image

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.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2017-12-24 00:16:56 +0000

Seen: 691 times

Last updated: Dec 26 '17