All Posts by Amit Shachak

Welcome to testRTC

Welcome to testRTC! Our support and documentation portal (knowledge base) was built to help you get familiar with our products and explore their features.

testRTC focuses on the product lifecycle of WebRTC applications, offering tools that assist clients in improving their services.

There are 3 product domains at testRTC:

  1. Testing
  2. Monitoring
  3. Support

There are several ways to explore our knowledge base:

  • By topic – browse our knowledge base by topics, organized into product categories. Each product has its own “Getting Started” section
  • Search – the search text box appears on every page in the knowledge base. When you enter the search query, before hitting enter, we will show you the most relevant topics right below the search text box.  You can click on one of the results to see the corresponding item. If what you are looking for doesn’t appear in the quick search list, hit “Enter” while your cursor is in the search tab. After you hit enter, you will be taken to the search results page where all results will be shown, sorted based on relevance
  • Intro videos – these appear in the Getting Started section of each product category in this knowledge base

For more general information about testRTC, please check our overview section.

You are also invited to view our release notes.


For testing, we’ve created a large scale, geographically spread infrastructure of probes that can be launched on demand to execute whatever testing scenario you need.

The Testing products of testRTC include:

  1. testingRTC – browser testing for regression, sizing and stress testing
  2. analyzeRTC – lightweight collection, debug and analysis tools


testRTC offers both active and passive monitoring capabilities.

  1. upRTC – active monitoring focused at making sure your infrastructure is up and running at all times, offering media quality that meets your expected SLA. To do that, we host, schedule and launch our own probes, running browsers that continuously run your service as if they were real users. If things go wrong for them – you will be notified immediately, making sure you are aware of the issues well ahead of your users
  2. watchRTC – passive monitoring focused on collecting, aggregating and analyzing data from your real users. This can be used to understand your deployment as well as drilldown and troubleshoot specific issues


testRTC offers products targeted at assisting support teams manage and troubleshoot customer issues a lot faster.

In that domain, we have two main products:

  1. qualityRTC – an adhoc network testing service, which is meant to give you a 360-view of a user’s network
  2. probeRTC – a continuous network testing probe, requiring no installation, which is used to analyze a customer’s network over time

The testRTC dashboard

When you login to testRTC, you will be greeted by our home dashboard. This is where you will be able to see in a snapshot the status of all the products you’ve subscribed for with testRTC.


Cross Platform WebRTC Browser Testing: Chrome, Firefox, Edge & Safari

This is a guest post by Philipp Hancke. He was kind enough to share the work he’s done already in automating his own WebRTC Safari tests.

Now that Apple added WebRTC to its Safari browser, it is time to ask –

How do you test WebRTC four browsers on different operating systems? Using Selenium Grid it is surprisingly easy, learn how.

Webkit recently joined the WebRTC ship which means we now have 5 major browsers to test:

  • Chrome, any operating system
  • Firefox, any operating system
  • Microsoft Edge, Windows 10
  • Safari (Technology Preview), OSX

Until a few days ago it was feasible to run tests all WebRTC supported browsers only on a single operating system (Getting Chrome, Firefox and Edge tested on Windows 10). With Safari, that has changed. Sounds like a big problem, no?

This kind of testing is typically done using Selenium which is used to remotely control the browser. And if it is remotely controlled it can be done with selenium’s grid functionality. Which is surprisingly easy.

Say we want to test Edge and Safari from a Windows machine. First step is to download the selenium standalone jar file. I am still sticking to version 3.3.1. Next, set up a selenium grid hub on one machine by running:

java -jar selenium-server-standalone-3.3.1.jar -role hub

This will start a hub which is where you connect your selenium nodes as well as test clients to. It will also tell you the URL that you need to connect your nodes to.

Next, start a node on your OSX machine by running:

java -jar selenium-server-standalone-3.3.1.jar -role node -hub http://where-your-hub-tells-you-it-is-running -browser “browserName=safari”

This will start a node that will run your Safari instance.

Now, in the code running selenium you need to instruct it to do two things:

  • Use Safari Technology Preview as shown in this PR
  • Make it use the hub as shown here

Next run your test code. If it works out of the box, great. If it does not you will probably spend a lot of time figuring out the issues. The most common issue here is forgetting to include the respective WebDriver binary in a path where it is found.