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

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2745D.149856C6
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

Any comments on the changing of the meaning of the encoding of G.726 in RTP
(see the last paragraph below)?

Glenn.

> -----Original Message----- 
> From: Stephen Casner [ mailto:[email protected]] 
> Sent: Tuesday, October 15, 2002 1:31 AM 
> To: [email protected] 
> 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 [email protected].
> 
> 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 
> [email protected] 
> https://www1.ietf.org/mailman/listinfo/mmusic 
> 
> 

------_=_NextPart_001_01C2745D.149856C6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>FW: [MMUSIC] Seeking input from G.726 ADPCM implementers</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Folks,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Any comments on the =
changing of the meaning of the encoding of G.726 in RTP (see the last =
paragraph below)?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Glenn.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Stephen Casner [</FONT><U> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:[email protected]">mailto:[email protected]</=
A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Tuesday, October 15, 2002 1:31 =
AM</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: [email protected]</FONT><FONT =
FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: [MMUSIC] Seeking input from =
G.726 ADPCM implementers</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This notice is being sent to multiple =
mailing lists to reach as many interested parties as possible; please =
reply only to [email protected].</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Background:</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.=A0 Two drafts have been prepared to revise these RFCs =
for advancement:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0=A0 =
draft-ietf-avt-rtp-new-11.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0=A0 =
draft-ietf-avt-profile-new-12.txt</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">These drafts have been =
&quot;tentatively approved&quot; for publication by the IESG.=A0 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:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0=A0 =
draft-ietf-avt-rtp-mime-06.txt</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Issue:</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.=A0 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.=A0 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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.=A0 Therefore, implementations of both packings are likely =
to exist.=A0 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.=A0 =
As a consequence, there is no course of action that will make everyone =
happy.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Proposal:</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.=A0 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.=A0 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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Consequences:</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.=A0 Any such systems =
already in the field would produce garbled audio when interoperated =
with RFC-compliant implementations, and not detect the error.=A0 This =
is a significant consideration, although draft specifications are not =
guaranteed to remain unchanged.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.=A0 This is consistent with ITU-T Recommendation X.420 =
for X.400 mail.=A0 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.=A0 However, voicemail systems that =
transmit messages over RTP would be forced to reformat the =
data.</FONT></P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">*********************************************************=
***********</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">*=A0 We are seeking statements from =
interested parties both for and=A0 *</FONT><FONT FACE=3D"Arial"> =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">*=A0 against this proposal, =
particularly with motivations.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
*</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">*********************************************************=
***********</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_______________________________________________</FONT><FO=
NT FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mmusic mailing list</FONT><FONT =
FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[email protected]</FONT><FONT =
FACE=3D"Arial"> </FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/mmusic" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/mmusic</A></FON=
T></U><FONT FACE=3D"Arial"> </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2745D.149856C6--
----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo