Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=windows-1252
From: Ron Frederick <ronf@bluecoat.com>
In-Reply-To: <4C404E26.1020004@angband.za.org>
Date: Fri, 16 Jul 2010 06:48:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E9A79E1-8AEE-4E5E-9088-C00B8B3D14D1@bluecoat.com>
References: <C4B4B0CA79ACBA45AEEE91D793484E1301A79E9657@NDA-HCLT-EVS04.HCLT.CORP.HCL.IN>
 <4C404E26.1020004@angband.za.org>
To: Frank Shearar <frank.shearar@angband.za.org>
Cc: avt@ietf.org
Subject: Re: [AVT] What is RTP payload length?
Precedence: list

On Jul 16, 2010, at 5:18 AM, Frank Shearar wrote:
>=20
> On 2010/07/15 09:41, Anurag Vashisth wrote:
>> Hi There,
>>=20
>> 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=92ve 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=92s header. Is =
there any
>> other way to collect this information: the RTP payload length(actual
>> audio data)?
>=20
> 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.
--=20
Ron Frederick
ronf@bluecoat.com