#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));