Re: [rtcweb] New version of -overview posted

[Harald Alvestrand <[e-mail]>]

On 10/04/2011 05:49 PM, Colin Perkins wrote:
> Harald,
>
> On 28 Sep 2011, at 13:09, Harald Alvestrand wrote:
>> I've just posted version -02 of the -overview document.
>> I'll just paste the change log from the document here:
>>
>>> A.6.  Changes from draft-ietf-rtcweb-overview -01 to -02
>>>
>>>    Added pointers to use cases, security and rtp-usage drafts (now WG
>>>    drafts).
>>>
>>>    Changed description of SRTP from mandatory-to-use to mandatory-to-
>>>    implement.
>>>
>>>    Added the "3 principles of negotiation" to the connection management
>>>    section.
>>>
>>>    Added an explicit statement that ICE is required for both NAT and
>>>    consent-to-receive.
>> Comments are always welcome, and version numbers are cheap!
>
> A minor editorial point: the 3rd bullet in section 7 suggests that SDP for new codecs is specified by MMUSIC. This is inaccurate: the SDP is done by PAYLOAD, as an algorithmic mapping from the parameters of the new media type. Suggest changing:
>
>     3.  When a new codec is specified, and the SDP for the new codec is
>         specified in the MMUSIC WG, no other standardization would should
>         be required for it to be possible to use that in the web
>         browsers.  Adding new codecs which might have new SDP parameters
>         should not change the APIs between the browser and javascript
>         application.  As soon as the browsers support the new codecs, old
>         applications written before the codecs were specified should
>         automatically be able to use the new codecs where appropriate
>         with no changes to the JS applications.
>
> to
>
>     3.  When a new codec is specified, and the media type parameters
>         for the new codec are specified in the PAYLOAD WG, no other
>         standardization would should be required for it to be possible to
>         use that in the web browsers.  Adding new codecs which might have
>         new media type parameters should not change the APIs between the
>         browser and javascript application.  As soon as the browsers
>         support the new codecs, old applications written before the codecs
>         were specified should automatically be able to use the new codecs
>         where appropriate with no changes to the JS applications.
Will do. Thanks!
> You might also want to add something like "The representation of codec names and their parameters in the web browsers must be algorithmically derivable from the media type name and parameters defined in the RTP payload format specification for the codec. This can be done by using the media type name and its parameters directly; by using the existing encoding of that name and parameters into SDP; or by defining an algorithmic mapping from the media type name and parameters onto a new signalling format".
I'll leave this to drafts that discuss codec negotiation, I think. The 
PeerConnection proposal for an API has no need to represent names or 
parameters of codecs independent of their SDP form; other proposals, 
such as the "Low level API" currently being discussed in WEBRTC, would 
have such a need.