ietf
[Top] [All Lists]

Seeking input from G.726 ADPCM implementers

2002-10-15 13:19:29
The IETF Audio/Video Transport working group is seeking input from
any implementers of systems using the G.726 ADPCM audio encoding, in
particular any that use the MIME audio subtypes G726-16, G726-24,
G726-32, and G726-40 or the RTP static paylod type 2 for G726-32.

This notice is being sent to multiple mailing lists to reach as many
interested parties as possible; please reply only to 
avt(_at_)ietf(_dot_)org(_dot_)

Background:

The AVT working group is seeking to advance the Real-time Transport
Protocol (RTP) and its associated Profile for A/V Conferences (RFCs
1889 and 1890, respectively) to Draft Standard status.  Two drafts
have been prepared to revise these RFCs for advancement:

    draft-ietf-avt-rtp-new-11.txt
    draft-ietf-avt-profile-new-12.txt

These drafts have been "tentatively approved" for publication by the
IESG.  In addition, a new companion draft has been approved for
publication as a Proposed Standard to specify MIME subtype
registrations for all the encoding names defined in the RTP Profile:

    draft-ietf-avt-rtp-mime-06.txt

Issue:

The packetization of G.726 audio specified in the RTP Profile packs
audio samples into octets beginning with the least-significant bit of
the octet.  This is at odds with the packetization of G.726 audio for
ATM AAL2 transport specified in ITU-T Recommendation I.366.2 Annex E,
which begins with the most-significant bit.  Implementers of systems
that operate with both transports or gateway between the two have
requested that the RTP packetization be changed to match the I.366.2
packetization to avoid requiring two different DSP implementations
and/or translation between packings.

Both specifications have existed for some time: I.366.2 has been an
approved standard since 1999, and the packing for the G726-32 rate has
been part of the RTP Profile drafts since 1997.  Therefore,
implementations of both packings are likely to exist.  Furthermore,
since the RTP Profile did not include packetizations for rates other
than 32K until 2001, some RTP implementations may have used the
I.366.2 packings for those rates.  As a consequence, there is no
course of action that will make everyone happy.

Proposal:

After consultation with the IETF Transport Area Directors, it is
proposed that the draft RTP Profile packetization be changed to be
consistent with I.366.2 Annex E before it 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.

Consequences:

We have already heard from one vendor that has implemented the
packetizations according to the current RTP Profile draft and
therefore objects to the change.  Any such systems already in the
field would produce garbled audio when interoperated with
RFC-compliant implementations, and not detect the error.  This is a
significant consideration, although draft specifications are not
guaranteed to remain unchanged.

We have also been informed that the format for G.726 audio in the
Voice Profile for Internet Mail (RFC 2421/2) uses the same sample
packing as currently specified in the RTP Profile draft.  This is
consistent with ITU-T Recommendation X.420 for X.400 mail.  Since the
VPIM systems use MIME type audio/32KADPCM rather than audio/G726-32,
there would not be conflict in meaning if the latter were changed as
proposed.  However, voicemail systems that transmit messages over RTP
would be forced to reformat the data.

********************************************************************
*  We are seeking statements from interested parties both for and  *
*  against this proposal, particularly with motivations.           *
********************************************************************



<Prev in Thread] Current Thread [Next in Thread>
  • Seeking input from G.726 ADPCM implementers, Stephen Casner <=