Having an issue with twilio-video.js? Unable to see remote Participants' Tracks? Review this list of common issues to determine whether or not your issue is known or a workaround is available. Please also take a look at the CHANGELOG.md to see if your issue is known for a particular release. If your issue hasn't been reported, consider submitting a new issue.
This happens primarily due to this Chromium Bug. We have added a workaround to the SDK in version 2.4.0. For earlier versions of the SDK, please apply the workaround discussed in this GitHub Issue.
This happens primarily due to a Chromium bug, where the decoded video frames are corrupted when the resolution is reduced in order to accommodate bandwidth constraints.
Because of this bug, sometimes Mobile Safari Participants on iOS 13.0.1 fail to send audio.
Because of this Firefox bug Participants that join a Peer-to-Peer Room after a DataTrack has been published by a Firefox Participant fail to subscribe to it. You can work around this issue by publishing a DataTrack while connecting to the Room. (JSDK-2615)
Chrome, Firefox and Safari enforce the autoplay policy, which blocks automatically playing audio or video if the user has not interacted with your application (ex: clicking a button to join a Room). You can find more details about the autoplay policies here:
Playback of RemoteAudioTracks should not be affected since its playback does not depend on the <audio> element. However, for RemoteVideoTracks, there are two ways to ensure playback:
-
Make sure that the user interacts with your application before joining a Room. Here is an example:
document.getElementById('join_room').addEventListener('click', () => { Twilio.Video.connect(token, { name: 'my-room' }); });
-
If your application needs to join a Room on page load, set the
mutedattribute of the <video> element returned byVideoTrack.attach()to true. The autoplay policy allows muted video to be automatically played.const video = videoTrack.attach(); video.muted = true;
Because of this bug, if you
set the maximum outgoing audio bitrate (maxAudioBitrate) to values greater than or equal to
64000 bps in a Group Room, then the outgoing video bitrate gets stuck at a very low value
resulting in degraded quality for Participants subscribing to your VideoTrack.
Chrome 76 added support for a new SDP format for RTCDataChannel negotiation. This new SDP format is not compatible with 2.x Android and iOS Video SDKs when used with Peer-to-Peer Rooms. In a Peer-to-Peer room, Chrome 76+ Participants and affected mobile SDKs might not be able to subscribe to each other’s DataTracks. Please refer to the upgrade paths listed in this issue to address this.
Because of this bug and this bug, Firefox is not able to recover media connections with other Participants in a Room after network interruptions or handoffs.
Because of this bug, Firefox
Participants are not able to constrain their audio bandwidth using LocalParticipant.setParameters().
Mozilla introduced a regression in Firefox 64, because of which Firefox 64/65 Participants in a Group Room may sometimes experience media loss. For more details, please refer to this issue.
Firefox 63 introduced a new SDP format for data channel negotiation. This new SDP format has caused incompatibility with the 1.x and 2.x Android and iOS Video SDKs when used with Peer-to-Peer Rooms. Please refer to this issue to find out if your app is impacted and how to overcome it.
We always ensure compatibility with the current Chrome and Firefox stable releases; however, because some of the APIs we rely upon, like WebRTC, are under active development in the browsers, we cannot guarantee compatibility with Canary or Nightly releases. We will, however, stay abreast of changes in browser beta releases so that we can adopt changes in advance of each browser's next stable release.
Because of this Safari 12.1 bug, once a Participant unpublishes a MediaTrack of any kind (audio or video), it will not be able to publish another MediaTrack of the same kind. DataTracks are not affected. We have escalated this bug to the Safari Team and are keeping track of related developments.
twilio-video.js 1.2.1 introduces experimental support for Safari 11 and newer. Support for Safari is "experimental" because, at the time of writing, Safari does not support VP8. This means you may experience codec issues in Group Rooms. You may also experience codec issues in Peer-to-Peer (P2P) Rooms containing Android- or iOS-based Participants who do not support H.264. However, P2P Rooms with browser-based Participants should work.
Also, there is an existing bug in twilio-video.js where publication of
DataTracks after joining a Group Room never reaches completion (JSDK-2161).
While we work to fix this bug, you can work around this by publishing your
DataTracks while connecting to a Room using the tracks property of
ConnectOptions.
There is a misinteraction between one of Angular's libraries, Zone.js, and Safari's RTCPeerConnection APIs. For more information, see here for the issue filed against Zone.js and here for the issue filed against WebKit. In order to work around this issue, you should include Zone.js's webapis-rtc-peer-connection.js in your app, after loading Zone.js. For example,
<script src="node_modules/zone.js/dist/zone.js"></script>
<script src="node_modules/zone.js/dist/webapis-rtc-peer-connection.js"></script>Although Microsoft Edge includes some WebRTC support, it also includes some limitations that make it difficult to support today. We plan on adding Edge support to twilio-video.js, but we may do so by leveraging Edge's ORTC APIs instead.
twilio-video.js requires WebRTC, which is not supported by Internet Explorer. While twilio-video.js will load in Internet Explorer and other browsers that do not support WebRTC, attempting to connect to a Room or attempting to acquire LocalTracks will fail.
Android Firefox 68 does not reject the Promise returned by getUserMedia if the user
dismisses the media permissions dialog by touching elsewhere on the application. So, we
recommend that the application should start a timer when using connect or createLocalTracks
to acquire local media. When it expires, and the returned Promise is still not resolved,
notify users and ask them to reload the application.
function wait(delay) {
return new Promise(resolve => setTimeout(resolve, delay));
}
async function connectToRoomOnAndroidFirefox68OrLower(token, options) {
const tracks = await Promise.race([
Twilio.Video.createLocalTracks(),
wait(/* A time in milliseconds of your choice */)
]);
if (!tracks) {
/* Instruct the user to reload the web app */
return;
}
return connect(token, {
...options,
tracks
});
}This issue will be fixed in Firefox Fenix,
where the Promise will be rejected with a NotAllowedError.
Firefox has not yet implemented getter's for RTCDataChannel's
maxPacketLifeTime and maxRetransmits properties. As such, we cannot raise
accurate values for the maxPacketLifeTime and maxRetransmits properties on
RemoteDataTrack. (Setting these values still works, though!) See below for
issues on the Firefox bug tracker:
Also, because of this Firefox bug, Participants will be able to successfully publish LocalDataTracks to a Group Room only when:
- They are connecting to the Room.
- They have connected to the Room and have not published or unpublished any LocalAudioTracks and LocalVideoTracks since then.
Some browser extensions and plugins will disable WebRTC APIs, causing twilio-video.js to fail. Examples of such plugins include
- uBlockOrigin-Extra
- WebRTC Leak Prevent
- Easy WebRTC Block
These are unsupported and likely to break twilio-video.js. If you are having trouble with twilio-video.js, ensure these are not running.