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

Randell Jesup <> Tue, 07 August 2012 01:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B47E711E80E9 for <>; Mon, 6 Aug 2012 18:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FtnK92QLmdo5 for <>; Mon, 6 Aug 2012 18:48:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 176E911E809C for <>; Mon, 6 Aug 2012 18:48:05 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1SyYtx-0007fN-B3 for; Mon, 06 Aug 2012 20:48:05 -0500
Message-ID: <>
Date: Mon, 06 Aug 2012 21:46:15 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "" <>
References: <> <> <> <>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Aug 2012 01:48:06 -0000

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:

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