Preflight API

The Preflight API is included with the Twilio Video JavaScript SDK in versions 2.16.0 and above. Versions 2.16.0 through 2.19.1 of the JavaScript SDK contain a beta version of the Preflight API. Version 2.20.0 and above of the JavaScript SDK contain the generally available Preflight API, which is no longer in beta.

You can include the JavaScript SDK in your application either by installing it with Node Package Manager (npm) or using the Twilio CDN.

See the supported browsers.

Install the Video JavaScript SDK using npm:

npm install --save twilio-video

Then, you can start using the Preflight API in your application (note that the Preflight API is under the name runPreflight):

const { runPreflight } = require('twilio-video');

You can also copy twilio-video.min.js from the twilio-video/dist folder after npm installing it and include it directly in your web app using a <script> tag.

<script src="https://my-server-path/twilio-video.min.js"></script>

Using this method, you can access the PreflightTest API like so:

const runPreflight = Twilio.Video.runPreflight;

You can also include the JavaScript SDK in your application from Twilio's CDN:

<script src="https://sdk.twilio.com/js/video/releases/2.34.0/twilio-video.min.js"></script>

Using the CDN, the JavaScript SDK will set a browser global that you can use to reference the Preflight API:

const runPreflight = Twilio.Video.runPreflight;

The following example shows how to use the Preflight API to start a diagnostic connectivity test and handle events during the test.

1
// import the Preflight API, which is called `runPreflight`,
2
// from the Twilio Video JavaScript SDK
3
const { runPreflight } = require('twilio-video');
4

5
// if you are using the Video JavaScript SDK via the Twilio CDN or
6
// a script tag, you would reference the Preflight API this way:
7
// const runPreflight = Twilio.Video.runPreflight;
8

9
// this assumes you have a function called getAccessToken
10
// to retrieve an Access Token from your server
11
const token = getAccessToken();
12

13
// run a preflight test, passing in an Access Token with
14
// a VideoGrant
15
const preflightTest = runPreflight(token);
16

17
// handle preflight test events
18

19
// while the test is in progress, the progress event fires
20
// whenever a particular PreflightProgress step completes
21
preflightTest.on('progress', (progress) => {
22
  console.log('preflight progress:', progress);
23
});
24

25
// if the test failed, the failed event fires and returns the error
26
// along with the partial test results it was able to collect
27
preflightTest.on('failed', (error, report) => {
28
  console.error('preflight error:', error);
29
  console.log('Received partial report:', report);
30
});
31

32
// if the test completed without error, the completed event fires
33
// and returns the preflight test report
34
preflightTest.on('completed', (report) => {
35
  console.log("Test completed in " + report.testTiming.duration + " milliseconds.");
36
  console.log(" It took " + report.networkTiming.connect?.duration + " milliseconds to connect");
37
  console.log(" It took " + report.networkTiming.media?.duration + " milliseconds to receive media");
38
});

To run a diagnostic test with the Preflight API, call the runPreflight() method and pass in an Access Token with a VideoGrant. This allows you to set up test connections to Twilio's servers.

When you run the test, you can pass in other PreflightOptions. The options include setting your preferred signaling region within the Twilio cloud (default: gll, which connects to the nearest signaling server based on latency) and the amount of time, duration, to run the test (default: 10000 ms, or 10 seconds).

The Access Token you pass to the runPreflight must contain a VideoGrant.

Because the Preflight API is connecting to a test Video Room that the Preflight API sets up, any value you pass in for the room and identity fields in the VideoGrant will be ignored during the preflight test. The Access Token you use does require an identity field, but this identity can be any value for the purpose of the test.

After you start running the preflight test with the runPreflight method, the test can generate three types of events. The code example above demonstrates how to listen for each event type.

• progress: The test is in progress and a PreflightProgress step in the test completed. This event passes the specific PreflightProgress step that completed.
• failed: The test failed with an error. This event passes back the error and any partially generated test results.
• completed: The test completed successfully and you can review the results. This event passes back the completed test report.

While the Preflight Test is in progress, it will emit ProgressEvents indicating it completed specific connectivity checks. You can use these events to track the test progress and provide additional feedback to end users about their connections.

The completed event will pass back a report containing the results from the successful test. The report will contain the following fields:

You can stop an in-progress test with the stop() method. This will stop the test and emit a failed event along with partial test results that completed up to the point that the test stopped.

The preflight test answers two questions: "Can this device connect to Twilio?" and "What will the call quality be like?" This section explains how to interpret the test results to answer both.

Use the combination of progress events and the failed event to determine connectivity:

The preflight test forces iceTransportPolicy: 'relay' on the publisher connection, meaning it only tests the Twilio TURN relay path. If the preflight succeeds, the real call (which can also use direct or STUN paths) also works. If the preflight fails, your network blocks relay traffic entirely.

The networkTiming field provides duration measurements for each connection phase. The connect.duration value reflects multiple sequential round-trips (WebSocket handshake and TURN credential exchange), not a single RTT measurement. An expected baseline is 800-1000 ms for connect.duration.

Use these signals to identify specific problems:

• connect.duration > 5000 ms: Signaling server latency is high, possibly a distant region. Consider specifying a closer region.
• media.duration > 10000 ms: Media path is degraded, even if the connection succeeds.
• ice.duration > 5000 ms: ICE connectivity check is slow, possible symmetric NAT or firewall interference.

The stats field in the completed report contains three metrics you can use to estimate call quality.

Use the following thresholds to interpret the stats:

The following reference implementation shows how to derive a quality estimate from the report:

1
function estimateQuality(report) {
2
  const { rtt, jitter, packetLoss } = report.stats;
3
  if (!rtt || !jitter || !packetLoss) return 'insufficient-data';
4

5
  // Use average values for overall assessment
6
  const rttMs = rtt.average;          // already in milliseconds
7
  const jitterSec = jitter.average;   // in seconds per WebRTC spec
8
  const lossPercent = packetLoss.average;
9

10
  if (rttMs < 100 && jitterSec < 0.030 && lossPercent < 1) return 'excellent';
11
  if (rttMs < 200 && jitterSec < 0.050 && lossPercent < 3) return 'good';
12
  if (rttMs < 300 && jitterSec < 0.100 && lossPercent < 5) return 'acceptable';
13
  return 'poor';
14
}

The selectedIceCandidatePairStats field shows how the connection was established. Because the preflight test forces iceTransportPolicy: 'relay' on the publisher connection, the selected pair always uses a relay candidate. The relayProtocol field indicates how constrained your network is:

The relay protocol is a proxy for how much overhead the connection carries. If you are on TURN-TLS, you generally experience worse quality than on TURN-UDP, all else being equal.

1
// report.stats shows:
2
// rtt: { average: 450, min: 200, max: 800 }
3
// jitter: { average: 0.085, min: 0.020, max: 0.150 }
4
// packetLoss: { average: 8.2, min: 0, max: 15 }

High RTT suggests the user is far from the nearest Twilio media region, or their network has congestion. High packet loss causes visible artifacts. Try specifying a closer region in Room options, or advise the user to switch to a wired connection.

1
// selectedIceCandidatePairStats.localCandidate shows:
2
// candidateType: "relay", relayProtocol: "tls"

The network blocks UDP and plain TCP, forcing the most restrictive relay path. Video works, but exclusively through TURN-TLS relay, which adds latency and results in degraded call experience. This can happen in corporate networks with strict firewalls where the Twilio media IP blocks and ports are not allowlisted. See Video IP addresses and firewall rules for the required network configuration.

1
// progressEvents shows: mediaAcquired, connected, mediaSubscribed, but no mediaStarted
2
// error: "Media connection failed or Media activity ceased"

The TURN relay connected but the media path failed. This may indicate deep packet inspection interfering with encrypted traffic, or UDP being blocked entirely.

Use this flowchart to decide what to tell your users based on the preflight result:

1
Run preflight test
2
       |
3
       v
4
  completed? ──No──> Check error + progressEvents
5
       |                    |
6
      Yes              Which stage failed?
7
       |                    |
8
       v              [See connectivity table]
9
  Check stats
10
       |
11
       v
12
  All "Good"? ──Yes──> "Ready for Video"
13
       |
14
      No
15
       |
16
       v
17
  Which metric is poor?
18
       |
19
  ┌────┼────────┐
20
  v    v        v
21
 RTT  Jitter  Packet Loss
22
  |    |       |
23
  v    v       v
24
 Suggest   Suggest    Suggest
25
 closer    wired      wired or
26
 region    connection less congested
27
                      network

The preflight test has the following limitations:

• No bandwidth testing: The preflight test only tests connectivity and path quality. It does not measure available bandwidth. Use the RTC Diagnostics SDK testMediaConnectionBitrate method for bandwidth testing.
• Synthetic media only: The test does not access the user's real camera or microphone. It uses synthetic audio and video tracks to verify the media path.
• Single pub/sub pair: The test does not replicate the exact topology of a multi-party room. It tests a single publish/subscribe pair through the Twilio TURN server.
• TURN-relay only: The test uses iceTransportPolicy: 'relay', so stats reflect the relay path. In a real call, if a direct connection is available, quality may be better than what the preflight reports.
• Test duration: The default duration is 10 seconds. The test collects stats once per second, yielding approximately 9 data points. Longer durations (configurable through options.duration in milliseconds) produce more samples and are better at detecting intermittent degradation, but increase user wait time.

Twilio offers an open-source Video Diagnostics Application that is built using the Preflight API and the RTC Diagnostics SDK. You can deploy and explore this application to see the different functionality of these diagnostic APIs in action. The application tests participants' device and software setup, connectivity with the Twilio Cloud, and network performance. It provides users feedback about their network quality and device setup, and also includes recommendations for improving their video call quality.