Subject: reg. length and padding in compound rtcp packet

From: "T.V.Rami Reddy" <[email-masked]>
Date: Fri, 07 Apr 2000 18:54:11 +0530

I have a doubt regarding the length calculation and padding in compound
rtcp packet
 The document says that
1. "padding should only be required on thelast individual packet because

the compound packet is encrypted as a whole(page 23)"
2. "The length of this RTCP packet in 32-bit words minus one including
the header and any padding"
       for each individual packets in a rtcp compound packet

If i am sending an "RTCP-BYE" packet as one of the packets in the
RTCP-compound packet.  I must do padding only in the bye packet.  But
what if one of the packets previous to the bye packet fall inbetween a
32-bit boundary. Padding must not be done to that packet according to
point 1.  Then  how to calcualte the length of that packet, since it
doesn't fall on a 32-bit boundary (length must be always in units of
32-bits) and padding must not be done.

Can anyone give an solution for this problem.

---

From: Wenqing Jin <[email-masked]>
Date: Fri, 07 Apr 2000 13:27:51 -0700

> Can anyone give an solution for this problem.

I think you are confused with the padding associate with the padding field
and the padding for alignment of 32-bit. The former is some additional paddings
probably for encryption, that's not mandatory. But padding for 32-bit boundary
is required in any case. So pad bytes to the 32-bit boundary first, and then 
if you have additional padding, add them in the last packet.  
-- 
Wenqing Jin
Senior Software Engineer
Vovida Networks, Inc.
(408) 383-1077

---

From: "T.V.Rami Reddy" <[email-masked]>
Date: Sat, 08 Apr 2000 17:03:09 +0530

I have some more doubts regarding padding in rtcp compound packet.
We are not using encryption, so padding for it is not required.
In padding intermediate packets (rtpSR, rtpRR, etc), in compound packet to 32-bit
boundary should we set the corresponding padding field TRUE with the last padding
byte containing the count of the total padding bytes added.
rami reddy t.v.

---

From: Stephen Casner <[email-masked]>
Date: Mon, 10 Apr 2000 00:33:03 -0700 (Pacific Daylight Time)

On Sat, 8 Apr 2000, T.V.Rami Reddy wrote:

> We are not using encryption, so padding for it is not required.  In
> padding intermediate packets (rtpSR, rtpRR, etc), in compound packet
> to 32-bit boundary should we set the corresponding padding field
> TRUE with the last padding byte containing the count of the total
> padding bytes added.

Are you referencing RFC 1889 or the draft revisions of it?  See:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-07.ps

The RTCP SR and RR packets are naturally a multiple of 32 bits long,
so they don't need any padding to a 32-bit boundary.  Only the SDES
and BYE packets require padding to a 32-bit boundary.  For both of
those, the current text says:  "Note that this padding is separate
from that indicated by the P bit in the RTCP header."  So, the answer
to your question is "no".  Is the text not clear enough?  If not,
please point out a specific location that needs to be changed.

							-- Steve

---

From: "Nam Kyu Kim" <[email-masked]>
Date: Mon, 10 Apr 2000 18:52:15 +0900

Dear Reddy and all.

Let me add more explanation for clarification.

> please point out a specific location that needs to be changed.

The RTCP SR and RR packets are naturally a multiple of 32 bits long.
So only the SDES and BYE packets may require padding to a 32-bit boundary.
But Text says only last packet can set P bit, and BYE packet must be last if it exist.
So the problem is what I do if SDES packet need to pad.
RTP internet draft says in page33 
"The list of items in each chuck MUST be terminated by one or more null octets, 
the first of which is interpreted as an item type of zero to denote the end of the list.
No length octet follows the null item type octet, but additional null octet MUST be 
included if needed to pad until the next 32-bit boundary. Note that this padding 
is separate from that indicated by the P bit in the RTCP header."

And there is another question regarding above sentences.
What shall I do, if there is no need to pad null octets until 32-bit boundry.
But text says "The list of items in each chuck MUST be terminated by one or more null octets".
I have to pad 4 bytes null octets?

-----------------------------------------------------
Nam Kyu Kim 
R & D Team 9
Mobile Telecommunication Terminal Division
HYUNDAI ELECTRONICS INDUSTRIES Co., Ltd.

TEL : (82-2)580-5511       FAX : (82-2)580-5487
Home : (82-2)2282-3077   C.P. : 017-211-3077
E-mail : [email-masked]
-----------------------------------------------------

---

From: "T.V.Rami Reddy" <[email-masked]>
Date: Tue, 11 Apr 2000 10:55:48 +0530

Hi Nam Kyu Kim,
Please see my comments in the lines.

with regards.
-rami reddy t.v.

Nam Kyu Kim wrote:

> Dear Reddy and all. Let me add more explanation for clarification. >
> The RTCP SR and RR packets are naturally a multiple of 32 bits long.So
> only the SDES and BYE packets may require padding to a 32-bit
> boundary.But Text says only last packet can set P bit, and BYE packet
> must be last if it exist.So the problem is what I do if SDES packet
> need to pad.
>
> ****I guess we can add padding bytes at the end of SDES but not need
> to set
> padding bit.  I think we need to set padding bit only if encryption is
> used.  Otherwise all the component packets in a compound packet are
> aligned to 32bit boudary and padding bit  must not be set.
>
> RTP internet draft says in page33"The list of items in each chuck MUST
> be terminated by one or more null octets,the first of which is
> interpreted as an item type of zero to denote the end of the list.No
> length octet follows the null item type octet, but additional null
> octet MUST beincluded if needed to pad until the next 32-bit boundary.
> Note that this paddingis separate from that indicated by the P bit in
> the RTCP header." And there is another question regarding above
> sentences.What shall I do, if there is no need to pad null octets
> until 32-bit boundry.But text says "The list of items in each chuck
> MUST be terminated by one or more null octets".I have to pad 4 bytes
> null octets?**** I think yes.
>
>
>
>
>
> HYUNDAI ELECTRONICS INDUSTRIES Co., Ltd. TEL : (82-2)580-5511
> FAX : (82-2)580-5487

---

From: Stephen Casner <[email-masked]>
Date: Mon, 10 Apr 2000 23:06:57 -0700 (Pacific Daylight Time)

> So the problem is what I do if SDES packet need to pad.

I will say it again, please read carefully: Only the SDES and BYE
packets require padding to a 32-bit boundary.  For both of those, the
current text says:  "Note that this padding is separate from that
indicated by the P bit in the RTCP header."

In other words, the padding of SDES and BYE packets to be a multiple
of 32 bits long HAS NOTHING TO DO WITH THE P BIT!!!  Every instance of
an SDES or BYE packet gets padded will nulls to be a multiple of 32
bits long.  Then after the desired collection of individual RTCP
packets are stacked into a compound RTCP packet, if the whole length
needs to be increased to be a multiple of an encryption block length
or for some other purpose, then the P bit can be turned on in the last
of the individual RTCP packets, the length field of that RTCP packet
is increased by the number of 32-bit words in the padding, and the
number of octets of padding is written into the last octet of the
padding, as described in the spec.  Is that clear?

> "The list of items in each chuck MUST be terminated by one or more
> null octets, the first of which is interpreted as an item type of
> zero to denote the end of the list.  No length octet follows the
> null item type octet, but additional null octet MUST be included if
> needed to pad until the next 32-bit boundary. Note that this padding

Yes, you have to add 4 null octets, but the first one is not padding.
The first one is a null item octet, indicating the end of the item
list.  The remaining three null octets are padding.

Please help me understand why the text you quoted above was not clear
on this point.
							-- Steve