#The Future of WebRTC ##ORTC, WebRTC 1.0 & NV Created by [Xander Dumaine](https://www.xdumaine.com) / [@xanderdumaine](https://twitter.com/xanderdumaine) Slides adapted from [Dr. Alex Gouaillard](http://www.slideshare.net/alexpiwi5/2015-q4-webrtc-standards-update) released under [cc by-nc 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)
## Heads Up Most of this work is still in progress. Stay up to date! These updates are as of December 2015. Who to follow: - Dr Alex / Justin Uberti / Philipp Hancke - webrtchacks.com - discuss-webrtc google group - Google / MSEdgeDev / Mozilla / Citrix / HookFlash - IETF / W3C / &yet
## Review Current State ### WebRTC 0.x ### Standards, Early 2015 ### Implemented, Late 2015
### JSEP Overview ![jsep](images/jsep.png) via [html5rocks](http://www.html5rocks.com/en/tutorials/webrtc/basics/jsep.png)
### Another View ![peer connection jsep](images/peerconnection.png) An "omnipotent" Peer Connection
### Open Questions 1. How do I handle bandwidth preferences? 2. How do I check fingerprint (MITM attack prevention) 3. How do I handle codecs and their parameters? - *Modify SDP and hope it works* 4. How do I know which candidate pair is being used? 5. How do I restrict ICE gathering? 6. How do I get more info about ICE failures? 7. How do I speed up ICE handshakes? 8. How do I avoid JSEP, SDP, O/A altogether? - *You can't*
## Object Model APIs ### ORTC and WebRTC Merge ### Object Model concept from ORTC
### ORTC Big Picture ![ORTC Big Picture](images/ortc-big-picture.png) via [ortc.org](http://ortc.org/wp-content/uploads/2014/08/ortc.html)
### Why Object Models? - Each Object only does one thing - Each Object can be probed for capabilities in js - Parameters can be get/set dynamically in js

Object Model Example -
RTPSender

  RTPSender
  ----------------------------------------------------
  -	MediaStreamTrack	track
  -	DTLSTransport		transport
  -	DTLSTransport		rtcpTransport
  ----------------------------------------------------
  -	Promise<void>	replaceTrack(track)
  -	RTPCapabilities		getCapabilities()
  -	Void				setParameters(RTPParameters)
						

Object Model Example -
DtlsTransport

  DtlsTransport
  ----------------------------------------------------
  -	readonly IceTransport				transport
  -	readonly DtlsTransportState			state
  ----------------------------------------------------
  -	EventHandler			onstatechange
  -	seq<ArrayBuffer>	getRemoteCertificates(track)
						
### Open Questions *now* 1. How do I handle bandwidth preferences? 2. How do I check fingerprint (MITM attack prevention) 3. How do I know which candidate pair is being used? 4. How do I avoid JSEP, SDP, O/A? 5. Can I switch camera/microphone without renegotiation? - *Yep. Final API in place* 6. How do I handle codecs and their parameters? 7. How can I restrict ICE gathering? - *You can to a limited degree; it's not ideal* 8. How can I speed up ICE handshakes? - *You can't; not yet addressed*
###
RTPTransceiver
- Object Model + JSEP (WebRTC + ORTC) - m-lines in SDP are intrinsically bi-directional - m-lines in SDP have attributes that fit neither sender/receiver object model (mid) or that would be duplicated in both RTPTransceiver represents a combination of RTPSender and RTPReceiver with a common mid
# ICE is Painful - Slow - Full = 10s; Trickle = 1s+ - Problematic on mobile (handover, complex networks)
### ICE improvement - ideas - Start before the call - ICE pool - Pre-gathering - Simplify pairing/checking
### Other Imrovements - Ideas - Warmup and async all the things - ICE, DTLS, media all ready before signaling - Transceiver + replace track - Start sending media at the same time as sending answer
# Bandwidth is Painful ### Multiple streams, Simulcast, SVC
### Multiple Streams/Tracks - Several uploaded streams/tracks - Decodable separately - Bandwidth management separated - App manages many connections/streams - lots of ports, very high bandwidth
### Simulcast - Several uploaded tracks - Tracks have a single source - Decodable separately - Smart bandwidth management possible - App manages many tracks - Reduced port usage with rtcp-mux/bundling
### SVC - Several tracks - Tracks have a single source - Not decodable separately (except base layer) - Smart bandwidth management mandatory - Less bandwidth, more resilience - Few tracks to manage - downgrading handled on the wire
### Reminder - Stream/Track management - Multiple Streams/Tracks - App manages many connections/streams - Simulcast - App manages many tracks - SVC - Track downgrading handled on the wire
### ... and lots more - client stream recording - DOM capture - Better statistics - DataChannels in workers - Security - Audio output devices - Better screen capture API

Thank You.


        				crowd.on('question', (q) => xander.answer(q));