Philipp,

Thanks for putting these details here. This adds another perspective, which is the fact that a lot of the features we see in Google’s roadmap are derived from requests coming in from the Hangouts team (who are also testing the features before they are shared with everyone).

— Improved BWE: I think that is the googLeakyBucket:true constraint, possibly also the googImprovedWifiBwe:true one

— CPU Adaptation: if you use hangouts in canary, you will see googCpuOveruseEncodeUsage:true, googCpuUnderuseThreshold:55, googCpuOveruseThreshold:85 peerconnection constraints.

— Improved permissions UX — see https://code.google.com/p/chromium/issues/detail?id=400285 for some of the problems they still need to solve. This won’t come in M37 (which my stable channel has already upgraded to)

— Improved RTX — yep, you can now see a=ssrc-group:FID for video in the SDP negotiation in M37. Also a=rtpmap:96 rtx/90000
lines in the SDP.

— Adaptive Opus FEC — apprtc shows how to enable that through SDP mangling:
https://github.com/GoogleChrome/webrtc/blob/master/samples/web/content/apprtc/js/main.js#L271

— RTPSender/Receiver APIs: those are unfortunately still missing even from Canary 🙁

— Audio output selection API — see the googDucking:false andchromeRenderToAssociatedSink:true flags in hangout. This shows the first signs, Navigator.getMediaDevices is targeted for M39 I think.

— IceTransport API: well… this is actually just to restrict the candidate types to relay ones. Doable in Javascript currently by dropping any onicecandidate event where the candidate is not of type relay. No new usecases.

— It will be harder to take the WebRTC code in the future and repurpose it and port it on your own.
It already got harder: https://groups.google.com/forum/#!topic/discuss-webrtc/QbC6KXWoaB4 — I am surprised nobody complained yet.

Point taken Richard. Thanks.

Plus sometimes the user just wants to be able to save their own copy of course, in which case you save a lot of effort.