Re: [AVT] WGLC request for G.711.1 payload format

<aurelien.sollaud@orange-ftgroup.com> Tue, 15 April 2008 07:46 UTC

Return-Path: <avt-bounces@ietf.org>
X-Original-To: avt-archive@optimus.ietf.org
Delivered-To: ietfarch-avt-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9350328C156; Tue, 15 Apr 2008 00:46:32 -0700 (PDT)
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF673A6D0D for <avt@core3.amsl.com>; Tue, 15 Apr 2008 00:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.375
X-Spam-Level:
X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2qpzcJ5x02o for <avt@core3.amsl.com>; Tue, 15 Apr 2008 00:46:30 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 64F653A6AEF for <avt@ietf.org>; Tue, 15 Apr 2008 00:46:29 -0700 (PDT)
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 09:46:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 15 Apr 2008 09:46:52 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD104B377D9@ftrdmel1>
In-Reply-To: <657A651D-60FD-4706-9ED4-7E1CE2707DFD@csperkins.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVT] WGLC request for G.711.1 payload format
thread-index: AcicFLU7YvChqOeQSKyQO0Fe6cMfJACtWBWQ
References: <20080409100001.C30D63A6B5F@core3.amsl.com> <DD8B8FEBBFAF9E488F63FF0F1A69EDD104AE2A2C@ftrdmel1> <657A651D-60FD-4706-9ED4-7E1CE2707DFD@csperkins.org>
From: aurelien.sollaud@orange-ftgroup.com
To: csp@csperkins.org
X-OriginalArrivalTime: 15 Apr 2008 07:46:54.0929 (UTC) FILETIME=[E0096C10:01C89ECC]
Cc: avt@ietf.org
Subject: Re: [AVT] WGLC request for G.711.1 payload format
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

> 
> I had one question on this: what's the rationale for having 
> both fixed and dynamic modes? It would seem you could have 
> the same effect as the dynamic mode by signalling several RTP 
> payload types, and changing RTP payload type when you want to 
> change mode.
> 
> Colin
> 

Hi Colin,

I agree it seems equivalent and you can do everything with several fixed mode payload types. But in practice, it leads to some annoyances :
- it consumes a lot of payload types. If you want to declare the 4 current modes both in A-law and mu-law, it is 8 payload types. In the future we can expect more modes to be defined, like super-wideband quality, stereo... It will be 10, 12, ... payload types.
- it leads to a larger SDP, that could be a problem regarding the path MTU for SIP messages. Again, with more modes in the future, it will be worse.

G.711.1 is an embedded codec, all modes are supported by the standardized decoder, so there is no reason in my opinion to force separate payload type per mode. Dynamic mode currently is the default in the media type registration.
See RFC 4749 for G.729.1, it does not define a payload type per bit rate (12 would be needed). It is the same rationale.

In earlier (unpublished) version of the draft, I only defined the dynamic mode. Some reviewers have asked for a payload-header-free format, with fixed mode, so I added it. I think both have their use cases.

Do you think it is an issue to have the 2 options?

Regards,
Aurelien


> 
> 
> 
> On 9 Apr 2008, at 13:15, <aurelien.sollaud@orange-ftgroup.com> wrote:
> > Hi
> >
> > The ITU-T has approved G.711.1. Now a payload format RFC is needed.
> > I have updated the draft to update the reference and to fix some  
> > minor editorial things.
> >
> > I believe draft-ietf-avt-rtp-g711wb-01.txt is ready for WGLC.
> >
> > Thanks,
> > Aurelien
> >
> >
> >> -----Message d'origine-----
> >> De : avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] De la
> >> part de Internet-Drafts@ietf.org
> >> Envoyé : mercredi 9 avril 2008 12:00
> >> À : i-d-announce@ietf.org
> >> Cc : avt@ietf.org
> >> Objet : [AVT] I-D Action:draft-ietf-avt-rtp-g711wb-01.txt
> >>
> >> A New Internet-Draft is available from the on-line
> >> Internet-Drafts directories.
> >> This draft is a work item of the Audio/Video Transport
> >> Working Group of the IETF.
> >>
> >>
> >> 	Title           : RTP Payload Format for ITU-T
> >> Recommendation G.711.1
> >> 	Author(s)       : A. Sollaud
> >> 	Filename        : draft-ietf-avt-rtp-g711wb-01.txt
> >> 	Pages           : 15
> >> 	Date            : 2008-04-09
> >>
> >> This document specifies a Real-time Transport Protocol (RTP)
> >> payload format to be used for the International
> >> Telecommunication Union
> >> (ITU-T) G.711.1 audio codec.  Two media type registrations
> >> are also included.
> >>
> >> A URL for this Internet-Draft is:
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g711wb-01.txt
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt