Subject: APP packet padding

From: "Timur Friedman" <[email-masked]>
Date: Mon, 16 Aug 1999 16:39:34 -0400

Would it be possible to loosen the requirements that the number of padding
octets in an APP packet be divisible by four, and that an APP packet can
only have padding if it is at the end of a compound packet?

The RTP Internet Draft seems to imply that the only reason that one would
need padding in an APP packet would be for encryption purposes.  This denies
to APP packets the flexibility allowed to data packets.

An example of where this poses a problem: I have written an APP packet that
contains a series of encodings, each 16 bits long.  If 2 octet padding is
disallowed then we must allow for a null encoding and add code to handle it.

- Timur Friedman <http://www.cs.umass.edu/~friedman>

---

From: Stephen Casner <[email-masked]>
Date: Tue, 17 Aug 1999 20:10:40 -0700 (Pacific Daylight Time)

> only have padding if it is at the end of a compound packet?

The APP packet must be a multiple of 4 octets long because that is the
unit of the length field.  The P-bit padding may be applied if the
compound packet needs to be extended to a larger block size, and must
only be added at the end as is clarified in the draft revision of the
RTP spec.

> to APP packets the flexibility allowed to data packets.

The P-bit padding needs to be available to the encryption process (or
other framing procedures) independently of how the individual RTCP
packets are constructed.  The P-bit method of padding
is not appropriate for what you want to do.

> disallowed then we must allow for a null encoding and add code to handle it.

You may specify the layout of the data portion of the APP packet
however you like.  If necessary, you can include your own length field
at the start of the data field to specify how much of the data field
contains valid data (vs. padding).  Or, if it is possible to
distinguish a padding value from data, then you can just add padding
to the end of your data to pad to a 4-octet boundary.  That may be
what you are saying when you talk about a null encoding.

							-- Steve

---

From: "Timur Friedman" <[email-masked]>
Date: Wed, 18 Aug 1999 08:29:25 -0400

----- Original Message -----
From: Stephen Casner <[email-masked]>
To: Timur Friedman <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 17, 1999 11:10 PM
Subject: Re: APP packet padding

> what you are saying when you talk about a null encoding.

Yes, that is exactly right: I am using a distinguished value that is
understood by my application in order to pad out to the end of a 32-bit
word, without using the padding mechanism provided by the header.

What I am a little unclear on, and have found nothing in the archives or
minutes that explains this design decision, is why data and control packets
are treated differently for padding purposes.

For example, if we were to take X to be an octet of data and O to be an
octet of padding, consider the following tail ends of packets.

  A        B
  ....     ....
  XXXX     XXXX
  XXXX     XXXX
  OOOO     XOOO

An RTP packet may take forms A or B, among others, but an RTCP packet may
only take form A.

I see the distinction, but the underlying difference that explains it is
opaque to me.

- Timur <http://www.cs.umass.edu/~friedman>