Review requested: audio/atrac3 media type registration

[actech]

Hi, Colin,

We completely agree with your point that the SDP processing code
based on knowledge of the media type is not efficient.
It increase the complexity, and interrupt quick response in result,
we think.

So we keep as it is, regarding on the description of "rate" parameter
of ATRAC3 in our draft.

Best Regards,

> Tom, Mark,
> 
> The rate parameter is clearly redundant for this media type, since  
> the ATRAC3 codec only supports one rate. If having a required  
> parameter with only one legal value is a problem -- which it hasn't  
> been for some other  formats -- then it can be removed.
> 
> The reason I suggested it be included, however, is that this media  
> type will frequently be used with SDP signalling. SDP requires that  
> the rate parameter be  present. Rather than special-case the SDP  
> processing code to generate the rate parameter based on knowledge of  
> the media type, it seemed simpler to provide the parameter, even when  
> its value is fixed for this code.
> 
> Colin
> 
> 
> 
> 
> On 7 Mar 2008, at 03:53, Tom Taylor wrote:
>> One thing I should point out is what RFC 4855 says about the rate  
>> parameter:
>>
>> <quote>
>>
>> 2. Procedure For Registering Media Types for RTP Payload Types
>>  ...
>>     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. ...
>>
>> </quote>
>>
>> So the "rate" parameter is not essential in this particular case.
>>
>> I would qualify this by saying that I should review correspondence  
>> Colin had with the authors to see if it covered this.
>>
>>
>> Mark Baker wrote:
>>> Hi,
>>> On 2/29/08, actech <actech at jp.sony.com> wrote:
>>>>  In case of missing of required parameter, or ATRAC media type,  
>>>> ATRAC
>>>>  streaming session can not be started. The situation is exceptional,
>>>>  and it is out of scope in our ATRAC payload format document.
>>> But if the media type was atrac3, then it could be started because
>>> rate=44100 could be assumed, no?  Or is the generic processing model
>>> independent of the media type?  I guess a spec would be required for
>>> me to check that 8-)
>>>>  As you say, the above processing may also be realized by +atrac
>>>>  extension for particuler purpose, but our scope is more generic,
>>>>  and described for lower level negotiation at the beginning of
>>>>  the normal ATRAC streaming.
>>> Ok.  Plus the other legacy media types obviously can't be retrofitted
>>> with +atrac.
>>> Mark.
> 
> 
>