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)

And more options...

MCU/SFUs

 

STUN/TURN

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.

See https://github.com/mandatoryprogrammer/sonar.js

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:

 

 

Both have lots of things going for them!

Test Frameworks

A few options...

 

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:

 

Helpful resources

WebRTC Specification

http://www.w3.org/TR/webrtc/

 

Discuss WebRTC Group

https://groups.google.com/forum/#!forum/discuss-webrtc

 

WebRTC Experiments

https://www.webrtc-experiment.com/

 

AppRTC (a reference application)

https://github.com/webrtc/apprtc

Pragmatic WebRTC

By noehlman

Made with Slides.com

Pragmatic WebRTC

  • 3,727