It's been a while this bug is present and it's annoying as hell to explain everyone that it's not our code produces malformed packets but whireshark has this bug. Basically, when RTP extension is present wireshark shows this: Here's sample pcap file with malformed RTP packet (#8) Wireshark version: Version 1.10.2 (SVN Rev 51934 from /trunk-1.10) on Win2008 I suspect that it starts to parse RTP payload without advancing properly for extension header size, and, perhaps, it may have similar bug for CSRC fields (that's usually 0 in p2p calls) asked 29 Sep '13, 17:38  psp80 edited 29 Sep '13, 21:11 |
One Answer:
Here's the bug fix: http://pastie.org/8366148 I attached this bugfix to the bug report. By the way, if you check the pcap file, it uses our extension (it's standard now): How do I teach wireshark to understand that one-byte RFC 5285 header with id#1 is 3gpp:video-orientation (as specified in sdp) and properly interpret the data of that header according to 3gpp:video-orientation? answered 29 Sep '13, 23:15 psp80 |
can you please post a sample capture file (google docs, dropbox, cloudshark)?
And what is your OS and Wireshark version?
sample pcap and wireshark version info added.
O.K. looks 'kind of odd'. Please file a bug report at https://bugs.wireshark.org (please attach the sample capture file).
Added bug report: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9204