FW: [MMUSIC] Seeking input from G.726 ADPCM implementers

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Tue Oct 15 08:33:09 EDT 2002


For your action if it affects you.  There is a clash between the
packetization of G.726 over RTP and AAL2, and a proposal to adopt the AAL2
packetization universally.  Comments are requested.

-----Original Message-----
From: Stephen Casner [mailto:casner at packetdesign.com]
Sent: Tuesday, October 15, 2002 1:31 AM
To: mmusic at ietf.org
Subject: [MMUSIC] Seeking input from G.726 ADPCM implementers


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.org.

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.           *
********************************************************************

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20021015/17a24cb4/attachment-0003.html>


More information about the sg16-avd mailing list