Subject: [AVT] G726 packing specified in draft-ietf-avt-profile-new-12.txt

From: "Rajesh Kumar" <[email-masked]>
Date: Fri, 7 Jun 2002 13:32:04 -0700

Henning and Steve,
The packing of G.726 code words into octets as specified in section 4.5.4
of draft-ietf-avt-profile-new-12.txt  is at odds with ITU I.366.2, which has
been an approved standard since February 1999.

In the ITU  specification, you start packing code words into octets starting
from the most significant rather than the least significant positions in the
octet. Thus, when you start packing, the most significant bit in the
codeword aligns with the most significant bit in the octet. This is more in
harmony with "network byte order" or big-endian order, since it does not
result in splitting a code word as the example in your internet draft does.

Further, for systems that concurrently support RTP and AAL2 modes, the G726
packing in your internet draft  places an unnecessary burden on DSP design,
integration and testing since two inconsistent packing rules need to be
followed for RTP and AAL2.

Since the IETF AVT specifications did not specify ADPCM byte packing rules
for RTP until recently, many vendors had taken a cue from the AAL2
specifications (approved in 1999) and have designed DSPs  that use the
I.366.2 ADPCM code word packing rules for RTP. Using a different, and
obviously less elegant,  rule for RTP without sufficient justification poses
a major backward compatibility issue for those vendors. I call the rule in
your internet draft less elegant since, when using network byte order
transmission, it splits code words gratuitously.

Is there a reason why these rules for packing G726 in RTP could not be
changed?

Thanks!

--------------
Rajesh Kumar
Cisco Systems

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Stephen Casner <[email-masked]>
Date: Fri, 7 Jun 2002 19:20:14 -0700 (PDT)

Rajesh,

Because network byte order is big-endian, we generally prefer
big-endian codec bit-packings for RTP as well.  In the particular case
of G.726, the 32K mode was added to draft-ietf-avt-profile-new-00.txt
in March, 1997.  That specification puts the first 4-bit sample in the
least significant bits of an octet, and then puts the second 4-bit
sample in the most significant bits of the octet.  I do not recall now
how this design was chosen and whether or not it was based on some
other reference.

The other data rates, G726-40, -24 and -16, were added more recently
in March, 2001.  Orion Hodson initially suggested a big-endian packing
for these, but I argued that the order should be consistent for all of
the data rates.

Because it has taken us an exceedingly long time to bring the revised
RTP profile to RFC publication, the drafts have served as the
reference for many implementations.  I do not know how many
implementations there are of the initial G726 format (32K) or of the
more recently added G726-40, -24 and -16 formats.

Procedurally, I believe the working group would be justified in
rejecting the request for a change because the IESG Last Call has been
completed and the draft has received tentative approval from the IESG
for publication.

However, I would be interested in hearing guidance from our ADs on
whether a change should be considered at this point, and input from
implementers who have already implemented what is specified in the draft.

							-- Steve