Docs
Get startedGuidesReferenceBlogChangelog
  1. Home
  2. Reference Docs
  3. Daily JS
  4. Instance Methods
  5. testCallQuality()

testCallQuality()

testCallQuality(): Promise;

Compatibility:
Prebuilt
Custom

This method cannot be run manually when using Prebuilt because it already runs automatically as part of Prebuilt's prejoin UI.

The testCallQuality() method assesses a user's network performance prior to joining a Daily call. It automatically connects to a Daily room and streams video to Daily's infrastructure on your behalf. The test runs for up to 30 seconds. During the test period, outbound WebRTC stats are collected. Upon completion, the results are returned as the average values over the time period.

The test results provide an indication of how the call will perform for the user. They allow your application to detect issues and make adjustments to the settings, all before joining the call.

For in-depth network stats during a call, refer to getNetworkStats().

testCallQuality() must be called after a call to either preAuth() or startCamera() and before the call to join(). The test relies on internal state initialization, which occurs after calling the preAuth() or startCamera() methods. We are looking to remove this requirement in the future.

It returns a Promise that resolves to an object providing information about the connection quality test results:

  • result: A string indicating the overall connection quality. Can be "good", "bad", "warning", "aborted" or "failed".
  • secondsElapsed: The number of seconds over which the data was collected. i.e. The timer starts after the test has successfully joined a call and begun to send data, not when testCallQuality() is initially called. If the test is run to completion, this number should be 30.
  • data: An object containing the underlying statistics gathered during the test and which were used to determine the result. See below for details on each.
  • id: The session id for the test call that was made. The test call uses a private domain, so you will not see the test calls on your account's dashboard. If you require test results, contact us for help.

If Adaptive Bitrate is enabled (note: it is enabled by default for 1:1 calls), then in addition to returning the results, the results are stored on the call instance and used at join time to properly initialize the highest simulcast layer to a setting the connection can handle.

Also see:

The results of the test provide an estimate of future call performance and is not indicative of whether a user is "allowed" to join a call based on their result.

Test results in detail

During the test, WebRTC stats are polled and stored once every second. At the end of the test (either because we have reached 30 seconds or the test has been stopped), the data is sanitized (e.g. outliers and nulls are removed) and calculated. If at any point, the test call ends in error, a result of failed is returned.

An example test result looks like this:

Meaning of result:

The result will return a value of good, warning, bad, failed, or aborted. Below is an explanation of exactly what each of these indicates:

  • "good":
    • avgSendPacketLoss < 5%
    • maxRoundTripTime < 300ms
    • avgSendBitsPerSecond >= 1100000
  • "warning":
    • avgSendPacketLoss >= 5% and < 10%
    • maxRoundTripTime >= 300ms and < 600ms
    • avgSendBitsPerSecond < 1100000 and >= 700000
  • "bad":
    • avgSendPacketLoss >= 10%
    • maxRoundTripTime >= 600ms
    • avgSendBitsPerSecond < 700000
  • "failed": The test meeting ended in error. This can be for any of the reasons a Daily call can end in error. When this occurs, the error and all of its details will be included. See the example below.
  • "aborted": test aborted before data gathering could start. This happens if either join() of stopTestCallQuality() are called quickly after the test is started.

Data details

maxRoundTripTime (seconds): The maximum of all currentRoundTripTime values sampled over the duration of the test.

avgRoundTripTime (seconds): The average of all currentRoundTripTime values sampled over the duration of the test.

avgSendPacketLoss (percentage): The average of all the reported outbound packet loss measurements. Depending on the browser, this is based off either fractionLost or packetsLost/ packetsSent.

avgAvailableOutgoingBitrate (bps): The average of all availableOutgoingBitrate values sampled over the duration of the test. (not available on Firefox).

avgSendBitsPerSecond (bps): The average of all bitsPerSecond values sampled over the duration of the test, where bitsPerSecond is literally just the delta of bytesSent / delta time (delta since last sampling).

All averages are calculated using an exponential moving average, biasing the most recent data received.

Example Test Failure

The following shows an example of the network disconnecting during the test.

Example usage of testCallQuality():

If the test returns a 'bad' result and you have adaptive bitrate disabled or the client is on Firefox, we suggest adjusting your send settings accordingly. For example, call updateSendSettings() with 'bandwidth-optimized' or provide your own optimized settings. Note: We do this in our own Prebuilt product for all clients regardless of browser/adaptive bitrate settings since adaptive bitrate will continue to override the top-layer settings and attempt to deliver the highest quality possible.

Related methods and events

Previous
Next