Re: Microsoft API Proposal

On 8/27/2012 4:10 PM, Matthew Kaufman wrote:
> I'm not sure what would be easiest for the editors or chairs, but perhaps it would make sense to take a list of these individual differences and turn them into issues in the issue tracker to be resolved. Some of these are quite non-controversial, such as congestion feedback information that we have proposed exposing that others on the list have agreed should be exposed but for which APIs are not yet documented. Others, of course, will elicit some discussion and debate, such as the proposal to replace SDP or to remove the offer/answer state machine logic.

It sounds like you have a large number of suggestions.  The titles you 
propose are too generic to usually understand what the issue actually 
is, or what the concern is.  Trying to mix all these issues would be a 
mess, so we'd need them to be detailed individually. Some probably can 
be wrapped up in a group, but there are still a lot of 
groups-plus-separate issues.

> A starting, but likely incomplete list of issues, might have titles like:
>
> - Testing of continued connection liveness
> - Are MediaStreams mutable objects?
> - Provide congestion feedback API for flows

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861
There was associate (short) conversation on the list, please feel free 
to critique or propose alternatives.  I'd love to move this towards 
resolution.

> - Serialization of duplicated tracks
> - Rollback of offers
> - Programmatic description of described streams
> - Learning of network change events
> - Learn what ICE candidates are in use
> - Pausing and muting of streams

There has been extensive discussion (in the past) on Mute and Hold. For 
many applications it's normally helpful to replace outgoing audio and 
video with some placeholder.  For audio, this could be silence or some 
type of hold message (or music).  For video, it could no frames (freeze 
last image), black, or a "you're on hold/I've disabled/muted my camera" 
still image (or video clip).  If so, you want it to occur *immediately* 
(no before-implementing signaling, even in the media path).  It can and 
should be a low-bandwidth image (single IDR, at least if we know error 
recovery is working), with just enough future packets to keep the 
channel open (or count on STUN checks to do so).

If (and it's a real if) the MediaStream APIs let you do this without 
much/any involvement of the PeerConnection, then it's mostly a case of 
documenting "here's how you should do this" in an example, perhaps.

This whole bit is separate from how actual track pauses and disables are 
done.  (Which I'm distinguishing from "mute" and "hold", which have a 
lot of use-case baggage tied to them) - and you specified Pausing and 
muting, so perhaps you're making (partly) the same distinction.

In addition to Mute and Hold, there are needs to temporarily disable 
streams (pause), for example in a simulcast where the server has 
informed you that the high resolution stream isn't needed (for the 
moment).  However, you may not want to tear down the channel and state 
associated with the stream.

> - Description of state/behavior is currently incomplete
> - Priority allocation
> - DTMF onTone event
> - Control connection establishment based on certificate
> - API for discovering capabilities
> - Bandwidth allocation

We've pretty much stated that automatic allocation between streams is up 
to the engine/browser, with the JS API letting the app 
modify/watch/replace those decisions.  (See above).  We've also stated 
there will be priorities, without specifying what impact those have 
except as being input to the internal allocator.

> - Bandwidth estimation feedback

At the WebRTC/W3 level, or the IETF/rtcweb level?  This sounds like IETF.

> - Expose additional ICE state
> - Document how the different state machines interact
> - Interoperability with varying ICE and ICE-like agents
> - H.264 SVC support
> - Set Security Description
> - Remove offer/answer
> - Split SDP between PeerConnection and MediaStream
> - Remove SDP
>
> If it would be helpful, we could produce either a document or a series of emails to the list listing the specific changes proposed for each of these items.
>
> Matthew Kaufman
>
>
> -- 
> Randell Jesup
> randell-ietf@jesup.org

Received on Tuesday, 28 August 2012 15:32:47 UTC