Help with "Unknown RTP Version 1" when analyzing RTP packets

asked 2022-10-21 20:07:56 +0000

I am trying to decode a wireless video stream over H.265/HECV. I set the "decode as" to RTP from UDP packets but now the in the info column It says Unknown RTP Version 1.

image description

I did make sure the port matches. I am also sure the stream is not encrypted as I made a decoder in a script that just straight decodes in H.265 with no decryption. My goal is to make this packet stream into a video playable file from wireshark.

For the most part the packet stream looks like this,

image description

My prediction is that the repeated len=1064 packets are the fragmented frame packets and maybe thats why the RTP decoder cant recognize it and just says "Unknown Version 1", however even knowing this I am not sure what to do. I am aware of the very few online resources on H.265 wireshark but none of them seemed to help me.

I am not sure where to go from here, I am new to wireshark, I have already spent over a week trying to learn how to do this but not having any luck. Any suggestions here would help.

answered 2022-10-22 06:49:22 +0000

Jaap

13742 ●711 ●115

Simply put, you are forcing Wireshark to look at these UDP packets (which are datagrams) to interpret their payload as RTP. The RTP dissector looks at these payloads and despite the little heuristics it can do, it sees that the version number field in the RTP interpretation of the UDP payload is '1', which is an unsupported number. There are no known sources that send RTP version 1 traffic, only version 2. So that begs the question, is this really RTP transport?

You talk about fragmentation. On the level of UDP and RTP there is no concept of fragmentation. Perhaps on the layer below that (IP), or in the RTP payload, but that's unknown at this point.

edit flag offensive delete link

Comments

Perhaps on the layer below that (IP),

In which case, if IP reassembly is not enabled in Wireshark, or the fragments can't be reassembled for some other reason, you'll see "Fragmented IP protocol" in the Info column.

or in the RTP payload

In which case, each of the fragments presumably would have to have a valid RTP header. which the "Unknown RTP version 1" packets do NOT have (if they did, they wouldn't be reported as "Unknwon RTP version 1", as they'd have version 2, not 1).

We'd have to see the raw capture file in order to figure out what's happening.

Guy Harris ( 2022-10-22 07:22:29 +0000 )edit

Thanks for your help. So what can I do here to move further, what are some other common protocols that HECV transmits over if not RTP? Could it be just pure UDP and I can extract the stream straight and convert it to a video?

AskedSuperior ( 2022-10-22 20:49:45 +0000 )edit

Here it becomes a matter of making educated guesses and seeing if the data in the UDP payloads match those assumptions. It might be a raw encoding stream, a MPEG container stream or something else entirely. Saving the UDP payloads in a file and feeding it to some video software may reveil what it is.

Jaap ( 2022-10-23 06:05:09 +0000 )edit

Ok thanks for help hopefully I find something. Also gotta just appreciate how nice people are here compared to stack overflow

AskedSuperior ( 2022-10-24 01:11:29 +0000 )edit

add a comment

Your Answer

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

Help with "Unknown RTP Version 1" when analyzing RTP packets

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Help with "Unknown RTP Version 1" when analyzing RTP packets edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Help with "Unknown RTP Version 1" when analyzing RTP packets