Pragmatic WebRTC
Developing for a successful product
http://slides.com/noehlman/pragmatic-webrtc/live
This talk
Not a cool WebRTC technology demonstration
A quick (and incomplete!) primer on some of the things
you might want to know before making a WebRTC product.
The state of WebRTC
- Troubled childhood, but it's finally getting to a state where mainstream use is possible (adolescence?)
- Browser implementations, frameworks, tools all starting to mature
- Still not natively supported in Safari and IE (although Temasys provides a plugin exists for this)
- WebRTC specification (http://www.w3.org/TR/webrtc/) is still undergoing revisions (latest released draft 11 June)... but fundamentals are relatively stable
Developing a product
"Is WebRTC actually the right technology to use?"
Before jumping in, ask yourself...
WebRTC is one of the fancy new technologies of the web, with great potential.. however it is definitely not a "one size fits all" technology
Additionally, P2P architecture can greatly increase complexity, and potentially reduce scalability, reliability and security.
Can make for a challenging business model as well!
Not deterred?
Choosing a framework
Not a necessity, but certainly recommended.
- Insulation from the differing and ever changing implementations of WebRTC.
- Often provide abstraction of common tasks (such as signalling, media capture, file and screen sharing, chat, renegotiation, exception handling, broadcasting, recording, multiplexing...)
Plenty of options!
Some General Framework/SDK options... (not definitive)
- rtc.io (http://rtc.io)
- OpenTok (https://tokbox.com/developer/)
- SimpleWebRTC (http://simplewebrtc.com/)
- Peerjs (http://peerjs.com/)
- EasyRTC (https://www.easyrtc.com/)
- RTCMulticonnection (http://www.rtcmulticonnection.org/)
- ApiRTC (http://apirtc.com)
- SkylinkJS (https://github.com/Temasys/SkylinkJS)
- OpenWebRTC (http://www.openwebrtc.org/)
- AdapterJS (https://github.com/webrtc/adapter)
- Twilio (https://www.twilio.com/docs/client)
- Bistri (http://developers.bistri.com/)
And more options...
MCU/SFUs
- Jitsi Videobridge (https://jitsi.org/Projects/JitsiVideobridge)
- Licode (http://lynckia.com/licode/)
- Janus (https://janus.conf.meetecho.com)
STUN/TURN
- restund (http://creytiv.com/restund.html)
- Coturn (https://github.com/coturn/coturn)
- Xirsys (https://janus.conf.meetecho.com)
- Twilio (https://www.twilio.com/webrtc)
- StunProtocol (http://www.stunprotocol.org/)
Signalling
The backbone of any WebRTC application.
Can be any mechanism for identifying peers, exchanging session descriptions about a peer connection between peers, and setting up the connection.
- Realtime signalling server using WebSockets / SIP / XMPP / MQTT ...
- HTTP requests
- Email/copy-paste...
Some frameworks include signalling implementations.
Security
Important!
P2P !== implicitly secure
One of the big marketing points of WebRTC is that data no longer has to touch a server, but that doesn't mean it's protected.
A number of aspects:
- Transport security
- Signalling authentication/authorisation
- Peer/client security
- Data integrity
- WebRTC itself
Transport Security
Standard stuff - making sure nobody is snooping on your packets!
For peer connections, WebRTC enforces encryption as a mandatory feature. Chrome and Firefox use DTLS-SRTP to achieve this.
TURN (relay servers) are OK too - end-to-end encryption.
No such guarantee for signalling - application developers responsibility!
Signalling Security
Making sure that only authorised P2P connections are established
Data not touching a central server doesn't matter, if your application allows an unauthorised peer to access that data.
- Enforce signalling over a secure protocol - such as Secure Websockets (wss), HTTPS, SIPS, OpenSIP.
- Authenticate peers, and authorise their connections
If necessary, monitor calls for unauthorised participants.
Peer/client security
In a P2P architecture, peers assume a lot more of the responsibility for their own security.
Primarily, verifying the identity of their peers.
This may appear to be solved by signalling, but signalling servers may not/ always be able to be trusted.
Allowing independent authentication by peers against a separate Identity Provider service can help solve this (with appropriate transport security).
WebRTC itself
Recently, WebRTC has received significant negative publicity around a few issues:
IP Leakage
Websites can use WebRTC to identify the IP addresses of the local computer, leading to privacy concerns around tracking and identification.
Network scanning
In conjunction with WebSockets, can also be used to scan networks exposed on the local computer for active hosts.
Testing
If there's one thing that web applications (and web application developers) struggle with, it's having an appropriate suite of automated tests.
Web applications have been notoriously difficult to automate testing for:
- Different browser environments to test for (+OS requirements)
- Limited/fragile testing tools
All is not lost however
Testing is possible
Modular development helps contribute to small, easily unit testable code.
Module Bundler + Test Framework + Cross Browser Test Runner
=
Testable Code
Bundlers
Two main contenders at this time in the world of Javascript:
- Browserify (http://browserify.org)
- WebPack (https://webpack.github.io/)
Both have lots of things going for them!
Test Frameworks
A few options...
- Mocha (https://mochajs.org/)
- Tape (https://github.com/substack/tape)
- Jasmine (https://github.com/jasmine/jasmine)
- QUnit (https://qunitjs.com/
Cross Browser Test Runners
Smokestack (https://www.npmjs.com/package/smokestack)
- Chrome + Firefox locally + SauceLabs for everything else
Zuul (https://www.npmjs.com/package/zuul)
- Local testing (via URL) + SauceLabs for remote
Broth (https://github.com/DamonOehlman/broth)
+ Travis MultiRunner (https://github.com/DamonOehlman/travis-multirunner)
- Local Testing + Chrome/Firefox on Travis CI
Testling (https://github.com/substack/testling) (endangered)
Monitoring
Monitoring the health of WebRTC connections forms a crucial part of helping to detect and resolve issues.
Monitoring
Lots of moving parts in a WebRTC application, and therefore lots of things that can go wrong.
Signalling/web servers
No problems, traditional monitoring
WebRTC connections
Requires a little more work to report on connection and quality issues.
Generally an agent on the peer that sends QoS reports back to a server providing the peers perspective of the connection.
Primarily sourced from application, signaller and the getStats API
Monitoring (continued)
Not a large number of options...
Callstats.io (http://www.callstats.io/)
TestRTC (http://testrtc.com/) (in closed beta)
NICTA's monitoring platform (not publicly available, but we can talk...)
Inevitable Issues
WebRTC is hard... things will break!
Connectivity issues
WebRTC uses the ICE framework, together with the STUN and TURN to enable network traversal, and eliminate a lot of the difficulties in establishing a connection, but it's not perfect.
Few things to note:
- Firewalls (most corporate environments allow TCP 80/443 and UDP 53) - TURN servers can get around this
- Classic STUN servers (RFC 3489) will work only with UDP (not TCP) - newer STUN implementations (RFC 5389) support both.
- STUN does not work with symmetric NATs (dynamic port assignment)
Video/audio issues
Covers a range of potential problems, and is one of the primary contributors to customer dissatisfaction.
Some could be related to users...
- No audio can be caused by not having a working microphone, or speakers being turned off
- No video can be caused by no camera, or by a user blocking permission for a camera
While it may seem obvious to use as developers, applications dealing with video/audio should help users identify problems like these.
Video/audio issues (continued)
Some issues are environmental/technical:
- Insufficient bandwidth to handle the amount of data being sent (large number of peers/high quality data)
- Limited computing resources (CPU and memory) for the encoding/decoding/rendering of video streams
To get around these limitations can result in difficult/no-win choices, such as:
- Reducing media quality
- Renegotiating streams as required
- Applying different media constraints in SDP
- Imposing an artificial limit of concurrent connections
Distributed state
Most P2P applications will want to exchange data in some form, often in the form of a replicated, distributed state across peers, often over WebRTC data channels.
Requires careful architecture of the replication systems to support appropriate concurrency and robustness, such as the use of a gossip protocol.
Some handy starting points:
- Scuttlebutt (https://github.com/dominictarr/scuttlebutt)
- CRDT (https://github.com/dominictarr/crdt)
- rtc-mesh (https://github.com/rtc-io/rtc-mesh)
Helpful resources
WebRTC Specification
Discuss WebRTC Group
https://groups.google.com/forum/#!forum/discuss-webrtc
WebRTC Experiments
https://www.webrtc-experiment.com/
AppRTC (a reference application)
Pragmatic WebRTC
By noehlman
Pragmatic WebRTC
- 3,691