Chrome 66 AudioContext and Twilio Voice JavaScript SDK 1.4 – Twilio Support

In Chrome 66, released to stable on April 17, 2018, Google tightened restrictions around their autoplay policy. In this release, Chrome stores a history of each user’s media consumption on every site they visit and calculates a Media Engagement Index (MEI). Chrome will not permit any page that fails to meet a minimum MEI score to play audio through an AudioContext until a user gesture is registered on the page.

The Twilio Voice JavaScript SDK 1.4 (formerly "Twilio Client") uses the AudioContext to play client-side sounds - such as the incoming call notification, outgoing call tone, disconnect tone, and DTMF sounds - and also to obtain the audio levels it reports.

Because Chrome’s MEI score is based on past browsing behavior, users who are using your app for the first time are more likely to see this problem. Conversely, if a user regularly uses your application, and has previously engaged with media on your site, Chrome is more likely to calculate a high MEI for your app, and allow it to play sounds. Your existing users, as well as developers and testers of your application, are less likely to encounter this behavior.

To work around this issue, starting with Chrome 66, you must initialize the Twilio Voice SDK only after a user gesture has been registered, or some of your users may not hear incoming call sounds, and API calls to report the current audio volume may incorrectly return zero values.

See this ongoing issue on the Chromium bug tracker for more information.

Which products are impacted?

In Twilio Voice JS 1.3 and prior, we do not use AudioContext, so versions 1.3 and less are not affected.

In Twilio Voice JS 1.4, an AudioContext is used to:

Play incoming, outgoing, disconnected, and DTMF sounds
Measure and report the volume for Connection.volume() and Device.audio.on('inputVolume')
Split audio output to multiple devices via Device.audio.speakerDevices.set() and Device.audio.ringtoneDevices.set()

Therefore, any end user who does not have a high MEI score (new users of your apps primarily) may see the following behavior:

Not hearing incoming, outgoing, disconnected or DTMF sounds. This may result in missed calls.
Reporting input volume and output volume erroneously as 0 through Connection.volume() and Device.audio.on('inputVolume'). This may break microphone or output volume indicators if you have implemented any. It may also result in incorrect Insights data for these values.
Setting audio output device(s) to something other than default may fail.

How can I tell if my app is impacted?

Your application may be affected if it calls Device.setup() without first waiting for a user gesture, such as a button click. Apps that call Device.setup() on page load will likely encounter the issues described above.

Your affected users may see the following warning in their browser console:

The AudioContext was not allowed to start. It must be resume (or created) after a user gesture on the page. https://goo.gl/7K7WLu

In your testing, you can check your MEI score by visiting chrome://media-engagement. If your tests show sounds still autoplaying, this information will let you determine whether they may be autoplaying due to a high MEI score because of your prior interactions with your application.

If you have indeed hit the high MEI score, you can reset it by launching Chrome with a --user-data-dir=/path/to/new/location parameter. This will start Chrome with a clean slate for the purposes of MEI scores.

What do I need to do now?

In order to comply with Chrome’s new requirements, your application should call Device.setup() only in response to a user gesture. For instance, this may be an “I’m ready” button. The AudioContext is set up inside Device.setup() so as long as Device.setup() is called after or in response to a user gesture, everything should run smoothly.

Example:

<button id="ready-button">I'm ready</button>
document.getElementById('ready-button').addEventListener('click', function() {
var device = Twilio.Device.setup(token);
document.getElementById('ready-button').style.display = 'none';
// Proceed to set up listeners on device, etc...
});

Alternatively, as a quick stop-gap solution, if your application:

Is not using Insights
Is not using volume indicators
Is not using audio output selection

You may quickly restore your application’s sounds by passing disableAudioContextSounds: true to Device.setup():

Twilio.Device.setup(myToken, {
disableAudioContextSounds: true
});

Note that our Safari implementation depends on AudioContext to play sounds successfully, so if your application may be run on Safari, you should only pass this flag when you detect the Chrome browser.

Can I disable this browser behavior?

In the rare case where you have control over the browsers of all your end users - such as in contact center scenarios, or certain enterprise applications - it is possible to disable this new behavior in the Chrome browser, by setting the browser flag autoplay-policy=no-user-gesture-required. To do this, navigate to chrome://flags, search for autoplay and change the Autoplay policy setting from Default to No user gesture is required. Restart Chrome to activate this change.