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@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.