FW: [AVT] Resolution of G.726 payload format endian-issue

[Campos, Simao]

Dear colleagues,
 for your information.
Best regards,
Simao

-----Original Message-----
From: Stephen Casner [mailto:casner at acm.org]
Sent: 15 November 2002 02:30
To: AVT WG
Subject: [AVT] Resolution of G.726 payload format endian-issue


This is a summary of the mailing list discussion regarding the
packetization of G.726 audio in RTP.  This topic is also on the agenda
for the AVT meeting next week.

  Background

Based on a request to align the sample packing order with that of ATM
AAL2 transport, it was proposed that the draft RTP Profile
packetization be changed to be consistent with ITU-T Recommendation
I.366.2 Annex E before the draft is published as an RFC.  The MIME
subtype registrations for G726-16, G726-24, G726-32, and G726-40 in
draft-ietf-avt-rtp-mime-06, which refer to the specification of the
packetizations in draft-ietf-avt-profile-new-12, would therefore apply
to the changed packetization.  In addition, RTP static payload type 2,
which is bound to the G726-32 encoding and packetization by
draft-ietf-avt-profile-new-12, would also change its meaning.

The request for input was distributed to the following mailing lists
(and perhaps elsewhere):

    ietf at ietf.org
    avt at ietf.org
    mmusic at ietf.org
    sip at ietf.org
    vpim at lists.neystadt.org
    packetcable-test-codecs at cablelabs.com
    packetcable-codecs at cablelabs.com
    tsg11bicc at ties.itu.ch (Study Group 11 Q. 11 (BICC signaling))
    tsg11q15 at ties.itu.ch (Study Group 11 Q. 15 (AAL2 signaling))
    ITU-SG16 at echo.jf.INTEL.COM (Study Group 16)
    Nortel internal distribution list

  Summary of Comments

All the comments received on the AVT mailing list both when the issue
was first raised and in response to the request for input are included
below, edited for brevity.  The number of comments was surprisingly
small, which indicates that there may not be many implementations of
G.726 transport in RTP.  Only one mentions an implementation of the
G726 payload format as specified in draft-ietf-avt-profile-new-12.txt,
although there are at least two other implementations: the publicly
available RAT audio tool, and one by Magnus Westerlund which was
interop tested with RAT.

Two comments (from one company) suggest that the existing G726-*
payload format specifications remain as is and that new MIME types be
defined for the ITU I366.2 packetization.  This possibility was
discussed at the last IETF meeting in Yokohama.

Another comment requested that the payload format remain as it is in
the RTP Profile draft because the Voice Profile for Internet Mail (RFC
2421/2) uses the same sample packing.  This is consistent with ITU-T
Recommendation X.420 for X.400 mail, which means there is an existing
inconsistency within ITU-T recommendations.

One comment was neutral, but leaning toward preserving backward
compatibility (i.e., not changing the payload format).

There was one comment in favor of making the change, from the original
requester.

  Conclusion

The primary justification for changing the existing MIME types and the
static payload type 2 for G726-32 to indicate the ITU I366.2
packetization would be existence of multiple implementations that had
implemented the RTP payload format as if it were the same as ITU
I366.2.  No such implementations were mentioned, even though the
original request did say that "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".  (The G726-32 mode
has been in the draft RTP Profile since 1997, but the other rates were
added more recently and the draft is not yet published as a standard.)

Based on the feedback received, the working group chairs and Area
Directors have agreed that the proposed change should NOT be accepted
and that the G726-* payload formats specified in the RTP Profile draft
should remain as they are.  We will specify a new set of RTP payload
formats designated by MIME subtypes AAL2-G726-16, -24, -32 and -48
which specify the sample packing in the order of I.366.2 Annex E.

If the IESG is willing to have these new payload formats added to the
draft RTP Profile in the form of an "RFC Editor note" when the IESG
sends its approval of the draft RTP Profile to the RFC Editor, then we
will do so.  One problem would be that the RTP Profile is to be
published as a Draft Standard, which means there should first be two
interoperable implementations.  Alternatively, a separate draft can be
produced quickly to be published as a Draft Standard.

At a minimum, we will request that the IESG add the following RFC
Editor note in Section 4.5.4 which defines the G726-* formats:

    Note that the order in which samples are packed into octets in the
    G726-16, -24, -32 and -48 payload formats for RTP is consistent
    with ITU-T Recommendation X.420, but it 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.

The description of the new AAL2-G726-* payload formats will include a
similar but complementary note.

Interoperability would have been optimized if there was a single
packetization that all agreed to use, but that is not the case.  If
there are some systems already in the field that use static payload
type 2 to indicate packetization according to the draft RTP Profile,
and other systems in the field that use static payload type 2 with
packetization according to I.366.2 Annex E, then we already have the
situation that those systems will produce garbled audio when they
interoperate, and the problem won't be detected when the session is
established.  We can't fix that problem without upgrading those
systems.

Therefore, we will also deprecate the use of static payload type 2,
such that all systems should negotiate a dynamic payload type using
the MIME subtypes G726-32 or AAL2-G726-32 depending upon which
packetization they want to use.  Vendors may be able to ease the
transition within their own implementations by offering the dynamic
payload type as the preferred value and the static payload type as the
secondary value.  An upgraded system that implements only G726-32 and
receives an offer of a dynamic payload type bound to AAL2-G726-32
along with static payload type 2 but no dynamic payload type bound to
G726-32 may want to assume that type 2 also indicates the AAL2 format
and reject the call, and vice versa.

To implement this deprecation, we will request another RFC Editor note
changing the assignment of static payload type 2 in Table 4 of the RTP
Profile to be "reserved" rather than "G726-32" and to add the
following note in the first paragraph of Section 6:

     Payload type 2 was assigned to G726-32 in draft versions of this
     specification, but its use is now deprecated and that static
     payload type is marked reserved.

Similar instructions will go in the IANA Considerations section so
that the assignment in IANA's registry is marked as deprecated.

Steve Casner
Colin Perkins
AVT Co-Chairs

--------------------------------------------------------------------
Comments received (edited):

Date: Wed, 10 Jul 2002 13:58:27 +0200
From: Eli Shoval <elish at audiocodes.com>

    I am sending this as a response to the recent request to change
    the G.726 packetization in ietf avt profile.  We at Audiocodes
    implemented the G.726 packetization according to ietf avt profile.
    We object to removing the original G.726 packetization from this
    standard because it will cause us to change our implementation.

    Why can't the ITU I366.2 packetization be added as additional
    vocoder to the ietf avt using dynamic payload type ?  In this case
    if it will have MIME registration with a different name than the
    regular G726 and if both gateways support it they will be able to
    communicate.


Date: Wed, 17 Jul 2002 22:20:39 -0400
From: Glenn Parsons <gparsons at nortelnetworks.com>

    In response to the G.726 agenda item, I just wanted to chime in
    VPIM (RFC2421/2) and the current AVT profile are aligned (with
    little endian).

    VPIM (and use of G.726) is widely deployed by voice mail vendors.
    Some of these systems support RTP as well.  So I would suggest
    maintaining this alignment.


Date: Tue, 15 Oct 2002 09:47:48 +0200
From: Oren Peleg <OrenP at audiocodes.com>

    Another Proposal could be: For the I.366.2 packetization, make a
    new MIME registration & Use a Dynamic Payload Type value.


Date: Thu, 17 Oct 2002 14:47:59 -0400
From: Tom-PT Taylor <taylor at nortelnetworks.com>

    Consultations within my organization seem to tend toward the point
    of view that the discrepancy is not a big deal and it would be
    better to preserve backward compatibility.


Date: Thu, 17 Oct 2002 11:34:39 -0700
From: Rajesh Kumar <rkumar at cisco.com>

    We would like to see the packetization of G.726 over RTP be made
    identical to what is defined for AAL2 in the ITU I.366.2
    recommendation. In this regard, we strongly recommend that the
    audio MIME subtypes G726-16, G726-24, G726-32, and G726-40 be
    aligned to the ITU I.366.2 recommendation.  This alignment would
    include the static payload type 2.

    If there is a need to interoperate with the "other," non-ITU
    packing scheme, we recommend that new MIME types be defined for
    those non-ITU schemes rather than for ITU-compatible schemes,
    which we think should be associated with the current MIME
    definitions.

[end]


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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com