Recently I upgraded to Wireshark 1.12.2 and it started decode some RTP packets as STU packets. Why? Upgrade to 1.12.4 showed the same behavior. Now, according to STUN RFC5389, the UDP payload bits 0 and 1 are both 0 and the RTP packets are version 2 so there is no way to misinterpret the two. asked 24 Apr '15, 14:20  prorad edited 25 Apr '15, 04:18  Bill Meier ♦♦ showing 5 of 7 show 2 more comments |
One Answer:
Wireshark's STUN/TURN dissector is, as indicated, dissecting the RTP packets as TURN packets. This would either require a stronger TURN heuristic or a way to disable the TURN heuristic. Please file a bug at the Wireshark Bugzilla, and attach a capture file containing the mis-dissected packets. answered 25 Apr '15, 11:36  Guy Harris ♦♦ Thank you. Will do. (25 Apr '15, 11:43) prorad Created a bugzilla but report "Bug 11152" (27 Apr '15, 08:33) prorad |
Do you have the "Try to decode RTP outside of conversations" preference for RTP set?
According to RFC 3489, the UDP payload bits 0 and 1 are not necessarily both 0; Wireshark dissects both "classic STUN" (RFC 3489) and "current" STUN (RFC 5389).
Yes I do have this set.
So are those packets showing up as "ChannelData TURN Message" packets? Those are described in section 11.4 of RFC 5766.
According to rfc3489, all supported STUN message types have both bits 0 and 1 equal zero.
That's why these two bits would be nailed to zero. As such, there should be no collision between the STUN protocol and the RTP version 2.
That's my understanding.
I was going say "that's why rfc5389 could nail the bits 0 and 1 to zero."
...and RFC 5766 says that ChannelData messages don't necessarily have both bits 0 and 1 equal zero, so they're not nailed to zero, and there is a risk of collision between TURN and RTP version 2.
Correct, those packets are showing up as "ChannelData TURN Message" packets.