SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
My session for WebRTC Summit, Nov 2015, Santa Clara
WebRTC sits at the intersection between VoIP and the Web. As such, it poses some interesting challenges for those developing services on top of it, but also for those who need to test and monitor these services.
In this session, Tsahi Levent-Levi will review the various challenges posed by WebRTC when it comes to testing and monitoring and on ways to overcome them.
Overcoming the Challenges in Testing WebRTC Services
Overcoming the Challenges in
Testing WebRTC Services
Let me tell you a little secret
People don’t usually test
Why is that?
• WebRTC is still niche/experimental to their
• They are a startup with limited resources
• Adding features takes priority over stability
• Is this VoIP or Web?
At an intersection of worlds
The world of VoIP testing
• Focused on DUTs (Devices Under Test)
• Rely heavily on slow moving standards and
• Vast majority of testing solutions are on
• Assume limited geographies
The world of Web testing
• Focused on different browsers
• Rely heavily on the GUI
• Responsive design causes GUI changes
• GUI and API testing treated as separate
• Geography doesn’t matter for functionality
5 Major Challenges
When trying to test your WebRTC service
Do you know if your service will not break next
Browsers update cycle in 2015
This translates to a regression test needed on a monthly
basis – not taking into account changes you make to the
Dec-14 Feb-15 Apr-15 May-15 Jul-15 Sep-15 Oct-15 Dec-15
Stable, Beta, Dev and Canary
Stable What your customers are using
Beta What you should expect in the next release
Where you can complain about breakage – and expect fixes
A nightly build of whatever is available at that moment in
Testing only against the Stable version of browsers means you find out
issues only after the service breaks for your customers.
A Word about Mobile
At what pace do you update you app’s WebRTC lib?
6-8 weeks update cycle
How does your service fair in varying network
WebRTC isn’t always P2P
Anywhere between 5-50% of your calls get
relayed via TURN servers
Have you setup your relays
• Support for UDP
• Support for TCP
Location, Location, Location
When a call in Paris gets relayed through a TURN server
in the US – you lose a customer…
Have you tested your service with 10 browsers?
100? 1,000? More?
What do you test at scale?
• Media relays?
• Backend media processing?
• Single session multiparty scale?
• End-to-end service scale?
• Do you add variance to your scale testing?
A typical conversation…
Oh, it should work for 100 people in the
same conference. We did test it with 12
people – the number of machines we had
available – and it worked perfectly fine.
Do you know if your service is really running?
What people monitor today
• There are many moving parts in your service
• WebRTC requires 3 or more servers to operate
• You need to make sure it runs end-to-end
How do you automate the mechanics of
communications in your service?
Web testing is simpler (most of
1. Write your script for a browser
2. Run it once
3. Run it in parallel on 10,000 browsers at once
4. You’re done
WebRTC is about coordinating
1. A user and an agent
2. A user and a PSTN/mobile call
3. N users joining in on a single call
4. Automatic/dynamic/manual pairing of the