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

[Stephen Casner <[e-mail]>]

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

On Fri, 7 Jun 2002, Rajesh Kumar wrote:

> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt