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

finding the packetization interval of a RTP packet

0

How do I create a filter to find the packetization interval for a RTP packet?

I can figure it out manually by looking at the size of the rtp payload and the codec used. For example, A 160 byte payload of G.711 has a packetization interval of 20 ms, 240 bytes of G711 has a packetization interval of 30 ms.

Also, the packetization interval can be found as a media attribute in the SIP/SDP INVITE packet, which will usually be "a=ptime:30" or "a=ptime:20".

alt text

asked 09 Oct '14, 16:43

gsalomon's gravatar image

gsalomon
11112
accept rate: 0%


2 Answers:

0

I'm not sure exactly what you want to do... a filter doesn't "find" a value, it filters the packets shown based on the values or fields you tell it to filter for.

  1. Do you want to only see SIP messages with a certain ptime attribute value? If so, you'd apply a display filter of 'sdp.media_attr == "ptime:10"' (or whatever ptime value you want to see the value of). Of course that will only show the SIP messages with SDP containing the ptime attribute, which is not a mandatory attribute and not always included by SIP clients.
  2. Do you want to only see RTP packets of a specific ptime value? Since RTP has no ptime field to filter by, you'd do it by the packet size as you mentioned. So you'd do something like 'udp.length == 100' for an 80-byte G.711 10ms RTP payload, or 'udp.length == 180' for an 160-byte G.711 20ms RTP payload, etc. (the UDP length field includes the 8 byte UDP header and 12 byte RTP header, so it's 20 bytes larger than the RTP payload)
  3. Or is it something else you want to do?

answered 10 Oct '14, 08:58

Hadriel's gravatar image

Hadriel
2.7k2939
accept rate: 18%

0

You can't. Well, sorta, but it depends.

Packetizing takes place in the RTP endpoint. That's were a timer runs to collect samples into an RTP packet and set its timestamp. But, depending on the actual codec used, this may or may not lead to an RTP packet transmission. And it's only the transmitted RTP packets we can analyze.

So, assuming there's a constant packet stream (no VAD, etc) you could pick out the timestamps of subsequent RTP packets and do the math. But that requires calculation spanning multiple packets. Oke, MATE may be helpful here. Another one is already calculated: delta from previously displayed packet. If you setup a display filter just showing the RTP packets you're interested in then you can use this field. Still it's only an approximation; it's the delta of packet reception, which is somewhat correlated to packetization.

So, the real answer is in the control protocol, as you have already stated.

answered 10 Oct '14, 08:59

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%