Hosting guest speaker Jan-Ivar Bruaroey of Mozilla Firefox WebRTC R&D team and contributor to adapter.js talking about Chrome and Firefox interoperability.

1. WebRTC Standards & Implementation
Q&A
Amir Zmora
TheNewDialTone
Dan Burnett
StandardsPlay

2. Guest Speaker – Jan-Ivar Bruaroey
• Senior Software Engineer on the WebRTC team at Mozilla .
• Works on both the Media capture and PeerConnection APIs in the Firefox platform
• Contributor to adapter.js open source and W3C specs

3. Watch video recording of this session
http://ccst.io/e/webrtcstandards16

4. Session sponsored by
WebRTC.ventures is a custom design and development shop dedicated to building WebRTC based applications
for web and mobile. We have built end-to-end broadcast solutions for events and entertainment clients,
telehealth solutions for multiple clients, live support tools, as well as communication tools for a variety of other
applications. WebRTC.ventures is a recognized development partner of TokBox and has also built native
WebRTC solutions

5. We use CrowdCast….It’s WebRTC

6. About Us
• Amir Zmora • Dan Burnett

7. Save The Date: July 10th
Register Now: http://ccst.io/e/webrtcstandards17
Next Session

8. The Browser ~ Standards Gap
Frits Ahlefeldt

9. The evolution of WebRTC 1.0.
Follow along at
https://blog.mozilla.org/webrtc
https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

10. Why now?
The WebRTC spec is nearing completion, going to Candidate
Recommendation real soon. With Google planning to finish 1.0 in
Chrome by the end of the year, it seems a good time to recap what this
means, as far as changes to what folks are doing today.

11. Wait for Unified Plan; Prepare for JS API.
Under the hood, the biggest remaining obstacle to advanced wire
interop, is that, unlike Firefox, Chrome hasn’t implement the spec’s
“Unified Plan” for multiple audio and video tracks yet. Be sad or happy,
but this blog isn’t about bridging that gap through SDP mangling. At
this point, it’s probably better to wait for Google to address this.
But web developers need to prepare, because the JavaScript API will
be different. This may be a surprise to those who haven’t followed the
spec. A good start is to look at what Firefox is already doing. But
there’s more. I don’t mean superficial things like promises, which all
browsers support now. Instead, expect a change in the media model.

12. The API gap: How the RTCPeerConnection API pivoted
twice
The RTCPeerConnection API has endured three design iterations on this topic over
the years. As a result, each browser today implements a snapshot from a different
point in the timeline of an evolving spec.
The three main stages in the design were:
• addStream and removeStream (Chrome today)
• addTrack, removeTrack, and sender.replaceTrack (Firefox today)
• addTransceiver and early media (No-one today)

13. Stage 1: addStream and removeStream
(async = )({ >
stream = await navigator.mediaDevices.getUserMedia({video: true, audio: true });
stream.removeTrack(videoTrack = stream.getVideoTracks()[ 0)];
pc1.addStream(stream );
})();
checkbox.onclick = )( ={ >
pc1.removeStream(stream );
if (checkbox.checked ){
stream.addTrack(videoTrack );
} else{
stream.removeTrack(videoTrack );
}
pc1.addStream(stream );
}
pc2.onaddstream = e ={ >
e.stream.onaddtrack = e ={ >
video.srcObject = video.srcObject;
e.track.onended = e => video.srcObject = video.srcObject;
}
video.srcObject = e.stream;
}

14. Stage 2: addTrack, removeTrack, and replaceTrack
(async = )({ >
stream = await navigator.mediaDevices.getUserMedia({video: true, audio: true });
videoTrack = stream.getVideoTracks()[ 0];
pc1.addTrack(stream.getAudioTracks()[0], stream );
})();
checkbox.onclick = )( ={ >
if (checkbox.checked ){
videoSender = pc1.addTrack(videoTrack, stream );
} else{
pc1.removeTrack(videoSender );
}
}
pc2.ontrack = e ={ >
video.srcObject = e.streams[ 0];
e.track.onended = e => video.srcObject = video.srcObject;
}

15. Stage 2: addTrack, removeTrack, and replaceTrack
This model adds quite a bit of control. But this abstraction still doesn’t cover the following realities well:
• ICE allocates bi-directional media ports, yet no way to know which sender & receiver go together.
• No clear re-use model for ports that wouldn’t risk sending the wrong media to a receiver at times.
• Kludgy {offerToReceiveVideo: 3} offer-options way to allocate additional m-lines (ports.)
• Using stream ids to correlate local & remote streams can collide with ids from other participants.

16. Stage 3: addTransceiver and early media
Solves the remaining 4 problems, plus one more: With call-setup time being critical more often than not,
some users want to send media early, before negotiation has even completed.
First, the main difference with this model is it naturally groups a sender and a receiver together into a
transceiver. The second, less obvious, difference is that this triumvirate is always created together.
This differs quite substantially from all implementations today where remote tracks are created by
setRemoteDescription.

17. Stage 3: addTransceiver and early media
(async = )({ >
stream = await navigator.mediaDevices.getUserMedia({video: true, audio: true });
videoTrack = stream.getVideoTracks()[ 0];
pc1.addTransceiver(stream.getAudioTracks()[0], {direction: "sendonly "});
videoTransceiver = pc1.addTransceiver("video", {direction: "inactive "});
})();
checkbox.onclick = async = )({ >
if (checkbox.checked ){
videoTransceiver.sender.setDirection("sendonly )";
await videoTransceiver.sender.replaceTrack(videoTrack );
} else{
videoTransceiver.sender.setDirection("inactive )";
await videoTransceiver.sender.replaceTrack(null );
}
}
pc2.ontrack = e ={ >
video.srcObject = e.streams[ 0];
e.track.onended = e => video.srcObject = video.srcObject;
}

18. Correlate by transceiver.mid instead of stream/track.id.
let videos = {[camStream.id]: videoA, [blankStream.id]: videoB;}
pc2.ontrack = ({streams: [stream ]}= ){ >
let video = videos[stream.id ];
if (!video.srcObject) video.srcObject = stream;
}
let videos = {[camTransceiver.mid]: videoA, [blankTransceiver.mid]: videoB;}
pc2.ontrack = ({transceiver, streams: [stream ]}= ){ >
let video = videos[transceiver.mid ];
if (!video.srcObject) video.srcObject = stream;
}

19. Conclusion
This blog covers only a piece of the API. There are lots of other
changes not covered here, in the API and on the wire. A lot of effort
has gone into this spec, and hopefully knowing the evolution of at least
one part of it might help with appreciating all it does. Looking forward
to seeing it all implemented soon!

21. Save The Date: July 10th
Register Now: http://ccst.io/e/webrtcstandards17
Next Session

22. Session sponsored by

23. Thanks to our guest speaker: Jan-Ivar Bruaroey

24. WebRTC Standards & Implementation
Q&A
Amir Zmora
TheNewDialTone
Dan Burnett
StandardsPlay