Re: [AVT] What is RTP payload length?

Ron Frederick <ronf@bluecoat.com> Fri, 16 July 2010 13:48 UTC

Return-Path: <ron.frederick@bluecoat.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C233A68FC for <avt@core3.amsl.com>; Fri, 16 Jul 2010 06:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Level:
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBDnXb9UOjZU for <avt@core3.amsl.com>; Fri, 16 Jul 2010 06:48:38 -0700 (PDT)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 4FD0B3A6A59 for <avt@ietf.org>; Fri, 16 Jul 2010 06:48:37 -0700 (PDT)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o6GDm95G007609; Fri, 16 Jul 2010 06:48:09 -0700 (PDT)
Received: from [127.0.0.1] ([216.52.23.36]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 06:48:04 -0700
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>
X-Mailer: Apple Mail (2.1081)
X-OriginalArrivalTime: 16 Jul 2010 13:48:04.0139 (UTC) FILETIME=[8372F7B0:01CB24ED]
Cc: avt@ietf.org
Subject: Re: [AVT] What is RTP payload length?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2010 13:48:40 -0000

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
ronf@bluecoat.com