[AVT] Profile: G726 payload format

[Stephen Casner <casner@acm.org>]

We've discussed the issue of sample packing order for G726 payload
format in a sequence of steps on this list.  The conclusion was sent
in a message on November 14.  As I said in that message we would do, I
have added a note explaining the incompatibility and referring to an
alternate set of payload formats called AAL2-G726 to be defined in a
separate document, as well as a note deprecating the use of static
payload type 2 for G726-32.  In addition, I took Simao Campos's
suggestion to clarify which bits in the diagrams are LSBs.

At the time we decided on this conclusion, Allison Mankin suggested
that the AAL2-G726-* payload formats could be added into the RTP
profile itself so readers of the profile would have complere
information on both formats.  However, there are some issues that
would result:

  - Nobody has actually implemented any of the names AAL2-G726-* yet
    since we just made that up, therefore we don't have two
    interoperating implementations as required for Draft Standard
    (which is the status at which the profile is to be published).

  - The MIME subtypes for the payload formats in the profile draft are
    registered via draft-ietf-avt-rtp-mime-06 which is already at the
    RFC Editor.  We'd need to send an RFC Editor note to add the
    registrations for AAL2-G726-* into that draft, which would cause a
    bunch of sections to be renumbered, which has to be done manually
    in the way the RFC Editor prepares documents.

Therefore, I believe it would be better to define the AAL2-G726-*
payload formats in a new document that we should publish as a Proposed
Standard post haste.

My resulting edits follow.  First, the note:

   Note that the "little-endian" direction in which samples are packed
   into octets in the G726-16, -24, -32 and -48 payload formats
   specified here is consistent with ITU-T Recommendation X.420, but is
   the opposite of what is specified in ITU-T Recommendation I.366.2
   Annex E for ATM AAL2 transport.  A second set of RTP payload formats
   matching the packetization of I.366.2 Annex E and identified by MIME
   subtypes AAL2-G726-16, -24, -32 and -48 will be specified in a
   separate document.

Second, the deprecation of static payload type 2, in Section 6:

   Payload type 2 was assigned to G721 in
   RFC 1890 and to its equivalent successor G726-32 in draft versions of
   this specification, but its use is now deprecated and that static
   payload type is marked reserved due to conflicting use for the
   payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4).

In the "Changes from RFC 1890" appendix:

        o The payload format for G721 was renamed to G726-32 following
          the ITU-T renumbering, and the payload format description for
          G726 was expanded to include the -16, -24 and -40 data rates.
          Because of confusion regarding draft revisions of this
          document, some implementations of these G726 payload formats
          packed samples into octets starting with the most significant
          bit rather than the least significant bit as specified here.
          To partially resolve this incompatibility, new payload formats
          named AAL2-G726-16, -24, -32 and -48 will be specified in a
          separate document (see note in Section 4.5.4), and use of
          static payload type 2 is deprecated as explained in Section 6.

Finally,  the clarification of the diagrams:

   An example of the packing scheme for G726-32 codewords is as shown,
   where bit 7 is the least significant bit of the first octet, and
   bit A3 is the least significant bit of the first codeword:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |B B B B|A A A A|D D D D|C C C C| ...
   |0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   An example of the packing scheme for G726-24 codewords follows,
   where again bit 7 is the least significant bit of the first octet,
   and bit A2 is the least significant bit of the first codeword:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
   |1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Are these changes sufficient?  (I realize they won't be satisfying to
those who wanted a different conclusion.)

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt