This document discusses common mistakes made when implementing WebRTC and how to avoid them. It covers misconfiguring NAT traversal, selecting the wrong signaling framework, testing locally instead of across different networks, ignoring security considerations, not collecting usage statistics and traces, and failing to fully understand WebRTC. The key recommendations are to properly configure TURN servers for NAT traversal, use a well-maintained signaling library, test across various environments, implement security best practices, collect diagnostic data, and take a long-term view of maintenance and upgrades.

1. Common WebRTC mistakes and how to avoid
them
Tsahi Levent-Levi

2. Tsahi Levent-Levi
• Consultant and analyst in digital communications
• Focus on WebRTC, CPaaS (and recently also
ML/AI)
• Co-founder and CEO of testRTC
BlogGeek.me

3. In this session
• A bit about WebRTC
• A shopping list of common mistakes…

4. A bit about WebRTC

5. WebRTC offers real time communication
natively from a web browser
WebRTC is a media engine with JavaScript
APIs

7. WebRTC is a Technology
not a Solution

8. How are calls made in WebRTC?
1
2
3
4
5

15. The usual
stuff

16. 15% (?) of
sessions
The usual
stuff

17. 15% (?) of
sessions
The usual
stuff
Concurrency
& scaling out

18. 15% (?) of
sessions
The usual
stuff
Concurrency
& scaling out
Throughput

19. At an intersection of worlds
Our
Internet
Web
Traditional
VoIP

20. 1Mis-configuring NAT traversal

21. DON’T use STUN servers lists
MORE IS LESS

22. DON’T use public STUN servers

23. DON’T use “public” TURN servers

24. [
"turn:<HOSTNAME>:<PORT>?transport=udp", // UDP
"turn:<HOSTNAME>:<PORT>?transport=tcp // TCP
];

25. [
"turn:<HOSTNAME>:<PORT>?transport=udp", // UDP
"turn:<HOSTNAME>:<PORT>?transport=tcp", // TCP
"turns:<HOSTNAME>:<PORT>?transport=tcp" // TLS
];

26. [
"turn:<HOSTNAME>:443?transport=udp", // UDP
"turn:<HOSTNAME>:443?transport=tcp", // TCP
"turns:<HOSTNAME>:443?transport=tcp" // TLS
];

27. What else?
• Globally deploy your TURN servers
• Add ephemeral passwords for TURN sessions
• Test that the configuration actually works
• Monitor behavior over time

28. 2Selecting the WRONG signaling framework

29. No really good, popular github signaling project for WebRTC
• Lots of projects, but no well maintained ones
• Google’s AppRTC is usually unsuitable

30. peerjs
https://peerjs.com/

31. EasyRTC
http://easyrtc.com/

32. Muaz Khan WebRTC Experiment
https://www.webrtc-experiment.com/

33. 3Testing locally

34. DON’T test locally
10.0.0.1 10.0.0.2

35. 80.246.130.243
DON’T test locally
10.0.0.1 10.0.0.1
176.231.82.46

36. Things to consider
• Different regions around the globe
• Network conditions
• Firewall configurations
• Operating systems and browser versions
• …

37. 4Ignoring (or forgetting) security

38. WebRTC is secure
• Media
• Only on SRTP
• Which is encrypted
• Keys exchanged over DTLS
• Signaling
• Web apps forced to use HTTPS (or WSS)

39. You have a role to play in security
• Application logic and signaling
• TURN server access
• Media server resources
• Keeping up with WebRTC releases
• …

40. 5Not collecting stats and traces

42. It isn’t always in your control
• Access to network (landline, WiFi, cellular, …)
• # of devices on local network (and what they are doing)
• Automatic browser upgrades

43. People will still assume you are to blame

44. Be sure you can analyze issues
• Log at the edge (from devices)
• Collect whatever you can
• Have the means to analyze it. Visually
• Look at https://github.com/lifeonairteam/rtcstats

45. 6Thinking short term

46. New browser version
Every
6-8weeks

47. WebRTC 1.0

48. WebRTC NV

49. Design Implement Maintain

50. 7Failing to understand WebRTC

51. webrtccourse.com
20% discount
with coupon code RTCEXPO2019
until Oct 31