Subject: Re: [AVT] What is RTP payload length?
From: Ron Frederick <[email-masked]>
To: Frank Shearar <[email-masked]>
Cc: [email-masked]
Date: Fri, 16 Jul 2010 06:48:03 -0700
List-Id: Audio/Video Transport Working Group <avt.ietf.org>

On Jul 16, 2010, at 5:18 AM, Frank Shearar wrote:
> 
> On 2010/07/15 09:41, Anurag Vashisth wrote:
>> Hi There,
>> 
>> I am using openDPI to sniff the RTP audio packets coming, I also want to
>> limit the audio data flowing from one point to another and in between I
>> am using openDPI to perform this task. But I’ve a problem here that in
>> the RTP header I am not able to get the information about the payload
>> length which is available in most of the protocol’s header. Is there any
>> other way to collect this information: the RTP payload length(actual
>> audio data)?
> 
> RTP doesn't have a payload length indicator. That's left up to the particular RTP-using protocol to define.

While there are some situations in which RTP requires an external framing mechanism as discussed in RFC 3550 section 11, the typical use of RTP over UDP does not need this. Generally, the UDP length field of the packet can be used to determine the end of the payload data, and the start of the payload data will be immediately after the fixed-size RTP header.

A few things can affect this:

If the "padding" bit is set in the RTP header, some number of padding bytes can be present at the end of the UDP packet which are not RTP payload data. The last octet of UDP packet data in this case contains the count of the number of padding octets (including itself). This moves the end of the payload data back by the specified amount of padding.  Padding like this is typically used when the RTP payload data is encrypted by an algorithm that uses fixed block sizes. See section 5.1 in RFC 3550 for more on this.

If the "extension" bit is set in the RTP header, the fixed RTP header is followed by a header extension as described in section 5.3.1 of RFC 3550. The header extension has a length field, indicating how many additional bytes needs to be skipped over to get to the start of the RTP payload data. Header extensions should be rare.

Using a combination of the UDP packet length, the padding length (if any), and the extension header length (if any), it should be possible to determine the position and length of the RTP payload data without any external framing mechanism, as long as the profile or payload format does not wish to combine multiple RTP packets into a single UDP packet.
-- 
Ron Frederick
[email-masked]