Re: [rtcweb] codec and connection negotiation

[Matthew Kaufman <[e-mail]>]

Now, to follow up on my previous message with a bit of opinion...

I think we should not use SDP as the API, and we should not have the 
browser implementing SDP offer-answer.

1. If SDP offer-answer is all that is available to the Javascript 
programmer (and server programmer), it becomes very difficult to know 
what the full capability set is without complex probing. This 
significantly complicates the building of future innovative applications 
on top of the browser as platform. Many of the current applications that 
show off browser capabilities do so by using capabilities that were 
already present for other reasons, and we can expect the same innovation 
to occur here, if we provide the tools.

2. Using SDP offer-answer has the advantage of reusing all the IETF 
standards work that occurs to define SDP when a new codec comes along. 
But it also has the *disadvantage* of having to wait for the IETF to 
produce these standards, which may be incomplete, or unable to control 
parameters which are necessary for web applications.

3. Anything that is missing in SDP (example: forcing the Opus codec to 
"music" mode for encoding) will still need to be exposed as a Javascript 
API on the encoder. Thus we end up with a mix of possibly-conflicting 
settings that are adjusted via the explicit API and the opaque SDP API.

4. Other work in browsers (like recording camera and microphone to disk) 
will require the ability to directly control the encoders. If these APIs 
exist then there will definitely be conflicting settings. What happens 
if you feed in an SDP answer that requires VP8 encoding and then set the 
encoder to H.264 mode via the Javascript?


Matthew Kaufman