Re: [AVT] Working Group Last Call: draft-ietf-avt-rfc3047-bis-06.txt

Hi,
This will cause a backward computability problem.
Adding a mandatory parameter will break existing implementations that use RFC3047.
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: <aurelien.sollaud@orange-ftgroup.com>
> 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, <aurelien.sollaud@orange-ftgroup.com> 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=32000"
> > 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=16000; bitrate=32000" 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é : mercredi 25 juin 2008 09:41
> >> À : 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=rtpmap" 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