Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability

[Randell Jesup <[e-mail]>]

On 8/6/2012 5:51 PM, Matthew Kaufman wrote:
> In addition to these differences that fall out of not baking in the
> full ICE and SDP O/A state machines, our proposal provides several
> other capabilities, including hooks that allow a developer to
> customize their application's response to changing network
> conditions... an area which is currently completely unaddressed in the
> current WebRTC draft.

We've said repeatedly that we need such capability, and I have a 
proposed JS API for just that:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861

The other side of this is in the hands of the Media Capture Task Force, 
where we've been discussing the best way to modify a MediaStream/Track 
after they're created.  There are two rough proposals, one to re-use the 
constraints API for getUserMedia(), and the other I've proposed 
(verbally only so far, no draft API) uses events and lets them "bubble 
up" the chain of MediaStreams/Tracks from a consumer to a source (which 
could be a remote source, and the application could signal that request 
(such as a resolution or frame-rate change) across to the remote source 
of the stream.  This is relevant even without a remote connection.

> I wouldn't be surprised if the existing use-case document(s) is (are)
> inadequate to describe situations where, for instance, a developer
> might wish to prioritize video quality over frame rate, or drop video
> in order to continue audio, but that just means that we all need to
> provide more input on those documents as well. Matthew Kaufman

I think most of those concerns are covered in what I describe above. 
(For example, the application could override the automatic allocation of 
bits and close a video stream, change the resolution, etc.)

I'd love to your input on these proposals, API suggestions, 
alternatives, etc!  I'm glad you're willing to help flesh out them out 
and bring them to completion, and get them into the spec drafts ASAP.


-- 
Randell Jesup
[e-mail]