The past few months have seen several discussions regarding the so-called “Legacy APIs”, meaning anything not officially supported in the spec that might have been implemented in the past. Some APIs have had support removed, others retained. This session will briefly review the recent decisions in addition to the normal Q&A.

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

2. Watch video recording of this session
http://ccst.io/e/webrtcstandards17

3. 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

4. We use CrowdCast….It’s WebRTC

5. About Us
• Amir Zmora • Dan Burnett

6. Save The Date: August 28th
Register Now: http://ccst.io/e/webrtcstandards18
Next Session

7. Announcing allthingsrtc.org
We are: Dedicated to the Real-Time Communications industry
• Articles from and interviews of experts
• News of innovation, not just telephony replacements
• Open to all perspectives. We make it easy for you to tell your story.
We are not: A mouthpiece for a single entity
• I do not advertise my consulting services anywhere on the site
• All sponsored content is clearly marked
• We aim to get visitors to the content and providers that they need
If you are an expert in an aspect of Real-Time Communications, let's talk!
And yes, we are happy to point to your site!
• http://www.allthingsrtc.org/2017/05/25/welcome-to-allthingsrtc/

8. Legacy API Support Changes
• Most changes have been to new (unimplemented) APIs
• Some recent discussions have been around long-expected behavior

9. Data channel id
• Two ways to set up data channel, depending on value of negotiated attribute
• false: the normal way, where the browsers work out the channel ids themselves
• true: where the app code selects an id that must match one on the other end
• Question: what happens if someone provides an id when negotiated == false ?
• Answer: it will be ignored (but no PR for this yet and new proposals are coming in …)
• Why is this even an issue?
• Internally, SCTP channels are uni-directional, so it takes two to make a bidirectional
data channel. When the browsers handle it ('in-band negotiation'), the DTLS client is
expected to choose even ids and the DTLS server odd ids. To avoid collisions we
can't allow the app to interfere unless the app takes on the complete responsibility.

10. When does the dtmf attribute exist on RTCRtpSender?
• Originally pc.createDTMFSender() was needed to create an RTCDTMFSender object,
but now that object is automatically created on the RTCRtpSender (at some point). So
what happens if telephone-event (DTMF) is later removed from the SDP?
• Decisions:
• upon creation of an RTCRtpSender for an audio channel, the dtmf attribute will be
set (created).
• if DTMF capability is later negotiated away, the dtmf attribute remains but the
<sender>.dtmf.insertDTMF() method call will fail.

11. Track IDs are (still) a mess
• Background
• A MediaStreamTrack (MST) is a local concept – local to the browser. Very
convenient notion when only dealing with usage inside your local app.
• A track is not sent over a PC. But its contents can be.
• How does an app know that what it just received from the other browser came from
track X in that browser?
• Maybe we made a mistake with MSIDs
• It is important for the PC that we know which track contents are connected together in
a MediaStream since they should be synchronized.
• But saying in SDP (with MSIDs) which track *contents* are in a particular PC flow
(sender/receiver) is problematic
• replaceTrack() causes a sender/receiver to transport a different track's
contents.

12. Track IDs are (still) a mess
• So what track ID is sent over a PC?
• The ID of the original track on the sender side
• replaceTrack() does not update this!
• But what track ID shows up in ontrack?
• Hmmm
• Today, the ID of the original track on the sender side
• Which could be the same as the ID of a different local track
• My prediction => more changes before we are through
• p.s. to identify which remote track you got, you need to match up sender/receiver mids.

13. More details
• Decisions were from the June 28 telecon
• https://www.w3.org/2011/04/webrtc/wiki/June_28_2017
• Track IDs, removal were also discussed on
• May 2: https://www.w3.org/2011/04/webrtc/wiki/May_2_2017
• June 7: https://www.w3.org/2011/04/webrtc/wiki/June_7_2017

14. No IETF RTCWEB meeting next week!
• A group does this when
• they believe they are basically done and
• they don't think they will have anything they need to discuss
• This is a good thing, right? Right?
• The data channel docs are done, but
• JSEP has some blocking AD comments, and
• Much of WebRTC 1.0 is not even implemented yet

16. Save The Date: August 28th
Register Now: http://ccst.io/e/webrtcstandards18
Next Session

17. Session sponsored by

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