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

RTP Packet length

0

For RTP Packets, i see length = 214 and under IPV4, i see total length = 200

what is the difference between above mentioned length? How to compute throughput for a particular RTP Packet

asked 12 Jun '14, 03:39

lte007's gravatar image

lte007
41668
accept rate: 100%

edited 12 Jun '14, 03:39

The IP length should not be less than any length in the payload, unless the IP frame is fragmented.

BTW: Where did you see the RTP payload length? Usually there is no length field in a RTP frame.

Can you please post a sample capture file somewhere (google drive, dropbox, cloudshark.org)?

(12 Jun '14, 05:04) Kurt Knochner ♦

Err, RTP packets have no length. The underlying transport protocol has to define length. Therefore UDP is used, which does determine payload length, and thus the length of the RTP packet.

Exactly where do you read these lengths? What fields are these?

(12 Jun '14, 05:11) Jaap ♦

Hey.. Here is the link having a screenshot... http://www.freeuploadsite.com/do.php?img=43935

(12 Jun '14, 08:50) lte007

One Answer:

1

Hey.. Here is the link having a screenshot... http://www.freeuploadsite.com/do.php?img=43935

Ah, O.K. that's not related to RTP!

The number in the length column is the total size of the captured frame (ethernet + ip) in your case 214. The length in the IP header shows the length of the IP frame (including the UDP frame and the RTP frame withing UDP). In your case that's 200 bytes. The delta of 14 bytes is the length of the Ethernet frame in front of the IP frame.

src mac: 6 bytes
dst mac: 6 bytes
ether type: 2 bytes

Regards
Kurt

answered 12 Jun '14, 08:59

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Hey Kurt, thanks for writing... what i understand from your points is... Total Frame Length (ethernet + ip) = 214 bytes Ethernet Frame Length = 14 bytes [(src mac: 6 bytes,dst mac: 6 bytes, ether type: 2 bytes(are these fixed values?)] IP Frame Length = Total Frame Length - Ethernet Frame Length IP Frame Length = 214 - 14 = 200 bytes Can you please check this screenshot too and explain.... http://www.freeuploadsite.com/do.php?img=43937

Does it mean that UDP length is considered as RTP Length? Please check this screenshot... http://www.freeuploadsite.com/do.php?img=43938

(12 Jun '14, 09:53) lte007

(are these fixed values?)]

yes, unless there are VLAN tags, which will add extra bytes to the ethernet layer.

Can you please check this screenshot too and explain.... http://www.freeuploadsite.com/do.php?img=43937

If you capture on one of the systems, Wireshark will see frames shorter than they should be, according to the ethernet standard (64 bytes). The nic driver will do the padding, if the real frame is shorter. However, Wireshark sees the frame before the nic driver, thus it shows only 60 bytes.

Why the IP length show only 41 bytes, I can't tell you. I don't do detailed packet analysis based on screen shots ;-)

Does it mean that UDP length is considered as RTP Length?

No. The UDP length field is the total length of the UDP layer (header + payload). So, the RTP 'length' is UDP length - UDP header (8 bytes).

http://en.wikipedia.org/wiki/User_Datagram_Protocol

BTW: Do you know the following functions:

Telephony -> RTP -> Show all Streams
Telephony -> RTP -> Stream Analysis

(12 Jun '14, 11:23) Kurt Knochner ♦

Thanks for helping me out, kurt! Yes i know the functions "Telephony -> RTP -> Stream Analysis"

Can you share any document which can help me understand all these in detail?

(12 Jun '14, 19:54) lte007

Hey Kurt..just want to be double sure on my understanding... Have done some calculations...Please check the below link... http://www.freeuploadsite.com/do.php?img=43971

appreciate your help!

(12 Jun '14, 22:21) lte007

The calculations seem in order, the layout of the RTP packet not so much. These short frames are either Comfort Noise or RTP Event packets. I think the former, where the required padding hasn't been taken into account. The RTP packets are wrong because the payload type still says 8 (PCMA), while the size suggests a different contents. But as Kurt says: "I don't do detailed packet analysis based on screen shots ;-)"

(13 Jun '14, 02:28) Jaap ♦

Can you share any document which can help me understand all these in detail?

understand what exactly?

Have done some calculations...

as @Jaap said: Looks good, however there might be some issues with the RTP frames. However, we cannot give any more advice, as you did not provide the pcap file!

(13 Jun '14, 06:15) Kurt Knochner ♦

Kurt, Jaap, Would really appreciate if you guys can do the analysis. Please let me know your email-id so that i can share the file.

thanks a ton!

(13 Jun '14, 09:58) lte007

Please post the capture file on google drive, dropbox or cloudshark.org (cannot be deleted!).

(13 Jun '14, 11:44) Kurt Knochner ♦

Hello, here is the link to download the file... https://www.dropbox.com/s/1rhfru4net8365f/Sample_VoIP.pcap

(16 Jun '14, 22:22) lte007

Hello guys... Please do the analysis and help me understand the conundrum of RTP Packets.....

(20 Jun '14, 00:17) lte007
showing 5 of 10 show 5 more comments