Return-Path: X-Original-To: avt-archive@optimus.ietf.org Delivered-To: ietfarch-avt-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46123A6961; Wed, 25 Jun 2008 23:24: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 DE2623A694A for ; Wed, 25 Jun 2008 23:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 QKXeXeGzDsGt for ; Wed, 25 Jun 2008 23:24:29 -0700 (PDT) Received: from isrexch01.israel.polycom.com (fw.polycom.co.il [212.179.41.2]) by core3.amsl.com (Postfix) with ESMTP id 37A933A6940 for ; Wed, 25 Jun 2008 23:24:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 09:25:03 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C05BD1237@IsrExch01.israel.polycom.com> In-Reply-To: <393B13F4-D01F-4224-9FFA-0395A2171458@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Working Group Last Call: draft-ietf-avt-rfc3047-bis-06.txt Thread-Index: AcjW8Len7KjdCKcaRS6xwO8BirKvmQAZFw7g References: <485A6198.50204@rogers.com> <144ED8561CE90C41A3E5908EDECE315C05B56C94@IsrExch01.israel.polycom.com> <144ED8561CE90C41A3E5908EDECE315C05BD0FE6@IsrExch01.israel.polycom.com> <393B13F4-D01F-4224-9FFA-0395A2171458@csperkins.org> From: "Even, Roni" To: "Colin Perkins" , Cc: avt-ads@tools.ietf.org, tom.taylor@rogers.com, avt@ietf.org Subject: Re: [AVT] Working Group Last Call: draft-ietf-avt-rfc3047-bis-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org Hi, This will cause a backward computability problem. Adding a mandatory parameter will break existing implementations that use R= FC3047. I assume that if having the rate is a MUST I will need to have two payload = subtype (G711 and G711C) or do you have another suggestion. Roni = > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, June 25, 2008 9:24 PM > To: > Cc: Even, Roni; tom.taylor@rogers.com; avt@ietf.org; avt- > ads@tools.ietf.org > Subject: Re: [AVT] Working Group Last Call: draft-ietf-avt-rfc3047-bis- > 06.txt > = > Right - the clock rate in the SDP takes the value of the "rate" media > type parameter. > = > Colin > = > = > On 25 Jun 2008, at 09:20, wrote: > > We agree on the fact that the rate is clearly defined in SDP by > > rtpmap. That is SDP. > > My comment here is for the media type registration itself. > > > > For example if I have the media description "audio/G7221 > > bitrate=3D32000" > > I don't know how to map it to SDP because I don't know if the RTP > > clock rate is 16000 or 32000. I need the "rate" parameter to know it. > > e.g. "audio/G7221 rate=3D16000; bitrate=3D32000" is OK. > > > > I think it is just a matter of formal description, it does not > > affect the rest of the draft to add the rate parameter. > > > > See RFC4598 S5.1 for example. It defines 3 possible rates in the > > "rate" parameter. I think it is the same for your draft. > > > > Aurelien > > > >> -----Message d'origine----- > >> De : Even, Roni [mailto:roni.even@polycom.co.il] > >> Envoy=E9 : mercredi 25 juin 2008 09:41 > >> =C0 : SOLLAUD Aurelien RD-CORE-LAN; tom.taylor@rogers.com; > avt@ietf.org > >> Cc : avt-ads@tools.ietf.org > >> Objet : RE: [AVT] Working Group Last Call: > >> draft-ietf-avt-rfc3047-bis-06.txt > >> > >> Aurelien, > >> I think that in this case we have a fix rate since each > >> payload type uses just one rate, so the rtpmap parameter > >> uniquely defines it. > >> Roni > >> > >>> -----Original Message----- > >>> From: aurelien.sollaud@orange-ftgroup.com > >>> [mailto:aurelien.sollaud@orange-ftgroup.com] > >>> Sent: Wednesday, June 25, 2008 10:34 AM > >>> To: Even, Roni; tom.taylor@rogers.com; avt@ietf.org > >>> Cc: avt-ads@tools.ietf.org > >>> Subject: RE: [AVT] Working Group Last Call: > >> draft-ietf-avt-rfc3047-bis- > >>> 06.txt > >>> > >>>> > >>>>> 4.1.1) a "rate" parameter must be defined in the media type > >>>>> registration, with 16000 or 32000 as possible values > >>>> > >>>> [RE:]Only the bit rate is needed and is defined. The > >> 16000 and 32000 > >>>> are clock rates and are part of the rtpmap parameter. See > >> example in > >>>> section 5.1 > >>> > >>> Roni, > >>> > >>> IMO, when multiple values are possible, the "rate" parameter must > >>> appear in the media type registration as a required parameter. > >>> > >>> See RFC 4855 Section 2 : > >>> > >>> Required parameters: > >>> If the payload format does not have a fixed RTP timestamp > >>> clock rate, then a "rate" parameter is required > >> to specify > >>> the > >>> RTP timestamp clock rate. A particular payload format > may > >>> have additional required parameters. > >>> > >>> > >>> I agree that is actually mapped in the SDP rtpmap > >>> > >>> (Section 3) > >>> o The general (possibly optional) parameters "rate" and > >>> "channels" also go in "a=3Drtpmap" as clock rate and > encoding > >>> parameters, respectively. > >>> > >>> Aurelien > >> > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > = > = > = > -- > Colin Perkins > http://csperkins.org/ > = > = _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt