Developing for a successful product
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
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!
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...
- Jitsi Videobridge (https://jitsi.org/Projects/JitsiVideobridge)
- Licode (http://lynckia.com/licode/)
- Janus (https://janus.conf.meetecho.com)
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
Some frameworks include signalling implementations.
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
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!
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.
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).
Recently, WebRTC has received significant negative publicity around a few issues:
Websites can use WebRTC to identify the IP addresses of the local computer, leading to privacy concerns around tracking and identification.
In conjunction with WebSockets, can also be used to scan networks exposed on the local computer for active hosts.
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.
Cross Browser Test Runners
- Chrome + Firefox locally + SauceLabs for everything else
- Local testing (via URL) + SauceLabs for remote
+ Travis MultiRunner (https://github.com/DamonOehlman/travis-multirunner)
- Local Testing + Chrome/Firefox on Travis CI
Testling (https://github.com/substack/testling) (endangered)
Monitoring the health of WebRTC connections forms a crucial part of helping to detect and resolve issues.
Lots of moving parts in a WebRTC application, and therefore lots of things that can go wrong.
No problems, traditional monitoring
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
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)
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
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)
Discuss WebRTC Group
AppRTC (a reference application)