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.
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…
27. What else?
• Globally deploy your TURN servers
• Add ephemeral passwords for TURN sessions
• Test that the configuration actually works
• Monitor behavior over time
29. No really good, popular github signaling project for WebRTC
• Lots of projects, but no well maintained ones
• Google’s AppRTC is usually unsuitable
36. Things to consider
• Different regions around the globe
• Network conditions
• Firewall configurations
• Operating systems and browser versions
• …
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
• …
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
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