All Posts by Tsahi Levent-Levi

Deep integration with qualityRTC

In some cases, you will want to embed the qualityRTC frontend inside your own web application. This is a powerful capability that gives you greater control over the user experience, letting you stitch the network test step inside your own application’s workflow.

qualityRTC offers several tools that you can use to reach this goal:

  • Use ?embedded=true in the URL and wrap the page as an iframe in your own web page
    • This way, you can place the page wherever you want in your web application
    • To use it, be sure to contact our support since it requires us to reduce some of the privacy protections we have be default on qualityRTC pages
  • Pass ?micid=x and ?camid=x in the URL
    • You can now let your user select in your own UI which camera and/or microphone to use
    • These will be used during the test as well
  • Use ?hidewidgets=true to remove all displayed widgets
    • You will be left with our popup progress bar for the test
    • The purpose of this is to allow you to display whatever data and UI you’d like to your end user
  • Use ?returnurl=url to go to your own page after the test completes
    • If you want to show only partial result, or not show the result at all, or simply move forward at the end of the network test – you can use this feature
    • This way, you can move forward in your workflow automatically
    • This is best used in conjunction to GET /qualityrtc/result/{testid} to collect the result of the test and decide what data of it to display to your user

Popup message customization

hen conducting a qualityRTC test, a popup message appears:

From time to time, our clients are looking to change the content of the message there.

There are two customization alternatives we offer here:

  1. Change the content of the popup to your own custom message
  2. Rotate between 2 or more text messages. In this case, the messages will appear for around 10 seconds each before switching to the next one in the rotation

If you’d like to have the message changed, contact support.

Sessions and minutes information

The Sessions block at the top ribbon of watchRTC Highlights gives you the gist on your account’s activity:

The Sessions and Minutes values adhere to the filters selected on the Highlights page, enabling you to slice and dice the data in various different segments.

Here’s what this information means:

  • # – the total number of sessions conducted based on the filtering criteria
  • Minutes – the total number of minutes collected and analyzed by watchRTC based on the filtering criteria
  • Duration – the average duration of a session in the filtering criteria
  • Participants – the average number of participants in the filtering criteria

Email integration in qualityRTC

Whenever a test is conducted by a user in qualityRTC, we collect the results and analyze them. Once done, we assign a total result indication to it: 🔴 failed; 🟡 borderline; 🟢 good

You can decide to receive such results via an email to your support team or even your ticketing service. If you go to the Settings in the sidebar and select qualityRTC, you will be able to make these decisions:

Note that choosing when to alert can be either based on the results (only when failed – Red; only if borderline or failed – Yellow; Always or Never). And you can also have the user decide if he wants to report the results or not by setting the “Alert when” field to Ask.

The alert email received will include a link to the test result itself.

If needed, the email can also include a PDF attachment with the result itself, and the PDF can be configured to include the detailed logs in it if needed. If you want the PDF to be included in the email, contact our support.

Daily sample test scripts

Daily is a CPaaS vendor focusing on faster time to market with a mixture of APIs and Prebuilt (lowcode/nocode) solutions.

If you are using Daily, then your best starting point for testRTC testing scripts for Daily WebRTC applications would be to use the samples created by Daily directly.

Read more about the Daily test scripts: Testing Daily’s WebRTC performance with testRTC

Github repo (sample app+scripts):

Note: These scripts are written and maintained by Daily

Integrating the watchRTC SDK with server-side rendering frameworks like Next.js

When using server side rendering frameworks such as Next.js, the watchRTC SDK gets integrated and built on a server platform instead of inside the browser itself. This may lead to execution errors once you import and include the watchRTC SDK.

You may bump into something like this error message:

To avoid this error message, you just need load our watchRTC SDK dynamically:

useEffect(() => { async function initWRTC() { const watchrtc = await import("@testrtc/watchrtc-sdk"); watchrtc.init({...}); } initWRTC(); });
Code language: TypeScript (typescript)

testRTC July 2022 Release Notes

testRTC was always about simplifying the complex world of WebRTC for our clients. While most of our customers to date have been developers, we are starting to see more and more IT and support customers, who want to have a simpler interface – or at least figure out faster what is wrong as why.

Why am I sharing it with you? Because we are starting to work hard from this release and on improving that specific thing – how to figure out faster what is wrong and why.

We are starting with the results ribbons, adding threshold colors to them, and improving their readability. This is a first step in many that you will be seeing in our upcoming releases.

Single Sign-on

SSO is coming to testRTC!

We are now able to offer single sign on for our enterprise clients.

Read more about Single Sign-on support.

testingRTC & upRTC


  • We started with simplicity, so we’ve now added (i) icons to the ribbon boxes. Clicking them will get you to our knowledge base where each of the values is explained
  • We’ve added colors to the Quality box in the ribbon as well. This is configurable (on our end), so if you need changes to the threshold just let us know
  • There’s a download button now available on Advanced WebRTC Analytics. This can make it easier to share or analyze the data outside of testRTC


We’ve added some more logic to the email notifications and PDF reports that can be generated in qualityRTC:

  • PDF files can now contain the full logs of the test if needed
  • Users can be prompted at the end of the test if they want to send the results to your support
  • Thorough tests can be configured to try multiple data center regions sequentially when needed
  • Logs can be limited to not display certain elements and information if needed


  • probeRTC can now be installed on Mac machines
  • You can configure an automatic end date for a probe


Notifications now include trends in traffic and quality metrics:

Here and there

  • Analysis of potential failures was limited to the first RTCPeerConnection. We are now conducting the analysis across all peer connections collected
  • Trends charts now split bitrate and packet loss metrics between incoming and outgoing

Single Sign-on support

testRTC supports SSO for its clients. You can authenticate and login to our service using SSO.

In such a configuration, users get authenticated and authorized for access directly via your SSO provider. Upon authentication, a user account will be created in testRTC for a first time login for the given user in your project on testRTC.

Below are the SSO providers supported by testRTC.

Azure Active Directory

You can use Azure Active Directory to sign in to testRTC.

In your Azure account, navigate to Active Directory.

Select App registrations on the left side panel and then select New registration on the top bar.

Choose the Name of the application and the account type. Set the Redirect URI to{your-domain}/authorization-code/callback

Now that you created your application in the directory, it is time to configure it a bit and get the information needed on our end.

On the application page click Endpoints, then copy the link under OpenID Connect metadata document – we’ll need this later

Now click on Certificates and secrets on the application page, and create new client secret

Once completed, please provide our support the following information:

  • From OpenID Connect metadata document JSON:
    • issuer
    • authorizationURL (authorization_endpoint)
    • tokenURL (token_endpoint)
    • userInfoURL (userinfo_endpoint)
  • clientID (Application ID) – can be found on the application page
  • clientSecret (Client secret)
  • callbackURL –{your-domain}/authorization-code/callback


If you are using Okta as your SSO provider, please proceed with the following steps.

On Okta admin dashboard go to Applications | Applications on the left panel.

Select Create App Integration.

Now select OIDC as sign-in method and Web Application as application type, click Next.

Update the following fields:

Once completed, please provide our support the following information:

  1. App integration client key
  2. Secret
  3. Okta domain

We will then configure your account accordingly.

RTT values

RTT indicates the round trip time (latency) observed. The higher the RTT, the lower the overall media quality of the session is. testRTC shows RTT information at the top ribbon results across the various solutions available for testing and monitoring:

The RTT values shown indicate the outgoing round trip time in milliseconds and are split between audio and video channels. The data is averaged throughout the duration of the session.

RTT threshold

When the round trip time value is above a certain threshold value, it will be marked in red.

The default configuration is set to 250 milliseconds. This threshold can be changed through our support.

Things you should know about RTT

Here are a few things to remember in the back of your mind about round trip time:

  • Delay, latency and RTT. All these come to describe the time it takes to receive media packets. Delay and latency are one-way and round trip time is two-way in nature (and what is measured by WebRTC)
  • RTT is measured only on outgoing channels. The receiver of the outgoing media sends feedback that is then used to measure the round trip time
  • The lower the round trip the better the media quality will be – remember that what we are aiming for is real-time and conversational in nature
  • The round trip time measured is the network one – it isn’t glass-to-glass. Additional delays caused by the camera and display processing are left out of the measurements done here
  • High RTT may indicate any of the following:
    • Connecting to a peer located remotely
    • Connecting to a media server located remotely (when a closer one may be available)
    • Using proxies or VPNs that route traffic through a remote server
    • delays in the local network

Jitter values

Jitter indicates the deviation from the periodic receival of media packets in milliseconds. The higher the jitter, the lower the overall media quality of the session is. testRTC shows jitter information at the top ribbon results across the various solutions available for testing and monitoring:

The jitter values shown are split between incoming and outgoing jitter in milliseconds to the user or probe, as well as between audio and video. The data is averaged throughout the duration of the session.

Jitter threshold

When the jitter value is above a certain threshold value, it will be marked in red.

The default configuration is set to 30 milliseconds. This threshold can be changed through our support.

Things you should know about jitter

Here are a few things to remember in the back of your mind about jitter:

  • Jitter is highly affected by the stability of the system. This includes network conditions as well as device performance
  • In poor network conditions, you will be seeing high jitter, which will force WebRTC to either delay media playback in order to maintain smoothness or to drop audio and video frames arriving too late

1 2 3 32