Subject: Re: [rtcweb] New version of -overview posted

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Oct 2011 16:49:31 +0100

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. 

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

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Oct 2011 14:09:28 +0200

>         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 defin…
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.