Dear colleagues, for your information. Best regards, Simao

-----Original Message----- From: Stephen Casner [mailto:casner@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@ietf.org avt@ietf.org mmusic@ietf.org sip@ietf.org vpim@lists.neystadt.org packetcable-test-codecs@cablelabs.com packetcable-codecs@cablelabs.com tsg11bicc@ties.itu.ch (Study Group 11 Q. 11 (BICC signaling)) tsg11q15@ties.itu.ch (Study Group 11 Q. 15 (AAL2 signaling)) ITU-SG16@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@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@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@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@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@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@ietf.org https://www1.ietf.org/mailman/listinfo/avt

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