2.2.0

2.2.0 (February 21, 2020)

New Features

• You will now be disconnected from a Room with a MediaDTLSTransportFailedError (error code 53407)
  when media cannot published to the Room due to a DTLS handshake failure. (JSDK-2552)
• Media reconnections are now time-bound. Now, if the media connection to the Room
  is not recovered after a certain time period, which is 30 seconds for now, then you
  will be disconnected from the Room with a MediaConnectionError (error code 53405). (JSDK-2552)

Bug Fixes

• Fixed a bug where switching between networks (or connecting to VPN) sometimes caused media flow to stop. (JSDK-2667)
• Fixed a bug where twilio-video.js failed to load due to a TypeError on Chrome iOS. (JSDK-2670)

1.20.1

1.20.1 (February 6, 2020)

Bug Fixes

• Fixed a bug where Room.getStats() sometimes returned null stats in a Peer-to-Peer
  Room on Chrome 81+. (JSDK-2640)

• Fixed a bug where sometimes enabling simulcast prevented media flow on screen share tracks on Chrome 81+. (JSDK-2658)

2.1.0

2.1.0 (February 4, 2020)

New Features

• A RemoteParticipant will now emit a "reconnecting" event when it is trying to re-establish its signaling connection to the Room after a network disruption/handoff. Once it has successfully reconnected to the Room, it will emit a "reconnected" event. (JSDK-2662)

  function reconnecting(participant) {
    console.log(`${participant.identity} is rejoining the Room`);
    assert.equal(participant.state, 'reconnecting');
  }
  
  function reconnected(participant) {
    console.log(`${participant.identity} has rejoined the Room`);
    assert.equal(participant.state, 'connected');
  }
  
  room.on('participantConnected', participant => {
    participant.on('reconnecting', () => {
      reconnecting(participant);
    });
  
    participant.on('reconnected', () => {
      reconnected(participant);
    });
  });
  
  // You can also listen to these events at the Room level.
  room.on('participantReconnecting', participant => {
    reconnecting(participant);
  });
  
  room.on('participantReconnected', participant => {
    reconnected(participant);
  });

  NOTE: It can take up to 15 seconds for our signaling backend to detect that a RemoteParticipant's connection has been disrupted due to a network degradation or handoff. This is because we don't want to be too aggressive in attempting reconnections. We encourage you to reach out to us with any feedback you may have in terms of the effect of this delay on your application's user experience.

  The LocalParticipant will now also emit "reconnecting" and "reconnected" events when the local client is recovering/successfully recovered from a signaling connection disruption:

  const { localParticipant } = room;
  
  localParticipant.on('reconnecting', () => {
    reconnecting(localParticipant);
  });
  
  localParticipant.on('reconnected', () => {
    reconnected(localParticipant);
  });

2.0.1

2.0.1 (January 21, 2020)

New Features

• Video.isSupported now returns true for [Chromium-based Edge(https://www.microsoftedgeinsider.com/). (JSDK-2633)
• Support for Safari is no longer experimental. Hence, twilio-video.js will not log a console warning in Safari 12.1+. (JSDK-2635)

Bug Fixes

• Fixed a bug where Room.getStats() sometimes returned null stats in a Peer-to-Peer Room on Chrome 81+. (JSDK-2639)

2.0.0

2.0.0 (December 20, 2019)

2.0.0-beta16 has been promoted to 2.0.0 GA and Network Bandwidth Profile is also GA! Thank you to all our beta users and for all the feedback you sent us during the beta period.

About Twilio Video JS SDK 2.0

Twilio Video Javascript SDK 2.0 introduces the Track Priority API, Network Bandwidth Profile API, Reconnection States and Events, and the Region Selection API.

Track Priority and Network Bandwidth Profile API gives developers the ability to specify how bandwidth should be allocated between the video tracks. Furthermore, the three profiles, (“grid”, “collaboration”, and “presentation”), specify when tracks should be switched off (or not) to conserve bandwidth for the highest priority tracks.

The Reconnection States and Events will automatically attempt to reconnect when a transient network error is encountered.

With Region Selection API, the SDK will automatically connect to the lowest latency data center. This API can also be configured to connect to a specific data center for cases where compliance might be required.

If migrating from a 1.x version, please refer to our migration guide.

To get started with Twilio Video JS, check our Getting Started Guide

2.0.0-beta16

2.0.0-beta16 (December 10, 2019)

New Features

• This release supports all the features of the Track Priority and Bandwidth Profile APIs.

• You can now specify the mode to control Track switch off behavior by specifying a
  property trackSwitchOffMode in BandwidthProfileOptions.
  trackSwitchOffMode can be set to one of

  • detected - In this mode, RemoteVideoTracks are switched off only when network congestion
    is detected.
  • predicted - In this mode, RemoteVideoTracks are pro-actively switched off when network
    congestion is predicted by the bandwidth estimation mechanism. This mode
    is used by default if not specified.
  • disabled - In this mode, RemoteVideoTracks will not be switched off. Instead tracks
    will be adjusted to lower quality. (JSDK-2549)

  const { connect } = require('twilio-video');
  const room = await connect(token, {
    bandwidthProfile: {
      video: {
        dominantSpeakerPriority: 'high',
        maxTracks: 2,
        mode: 'collaboration'
        trackSwitchOffMode: 'detected' // possible values: "predicted", "detected" or "disabled".
      }
    }
  });

• You can now change the priority of an already published LocalTrack using a new method
  setPriority on the corresponding LocalTrackPublication. (JSDK-2442)

  const localTrackPublication = await room.localParticipant.publishTrack(localTrack, {
    priority: 'high' // LocalTrack's publish priority - "low", "standard" or "high"
  });
  
  // After a while, change the priority to "low".
  localTrackPublication.setPriority(`low`);

  This will update publishPriority on all corresponding RemoteTrackPublications and
  emit a new event "publishPriorityChanged" to notify the user:

  remoteTrackPublication.on('publishPriorityChanged', priority => {
    console.log(`The publisher has changed the priority this Track to "${priority}"`);
    assert.equal(remoteTrackPublication.publishPriority, priority);
  });

• In a Group Room, You can now override for yourself the priority of a RemoteTrack set by the publisher
  by using a new method setPriority. (JSDK-2347)

    remoteTrack.setPriority('high');

• If you want to revert back to the priority set by the publisher, you can do so as shown below:

    remoteTrack.setPriority(null);

Bug Fixes

• Worked around an issue in chrome where it would sometimes stop sending updates on screen-share track if maxVideoBitrate was set for the track.
  You can limit bitrates on outgoing tracks using Localparticipant.setParameters api. With this workaround, any bitrates set will not be applied to screen share track on chrome. (JSDK-2557)

• Fixed a race condition, that would sometimes cause a track to not get published if multiple tracks were added in quick succession (JSDK-2573)

• Fixed a bug where publishPriorityChanged, trackDisabled and trackEnabled events were getting fired for initial track state (JSDK-2603)

• Fixed an issue where loading twilio-video.js in firefox with media.peerconnection.enabled set to false in about:config caused page errors. (JSDK-2591)

1.20.0

1.20.0 (November 11, 2019)

• As of this release, twilio-video.js will no longer use the deprecated Plan B SDP format when publishing or subscribing to tracks. It will use the Unified Plan
  format. Google has advised that they will remove Plan B support from Chrome during Q1 2020. Therefore, we recommend updating to SDK 1.20.0+ as soon as possible. This change will not impact interoperability with existing twilio-video.js versions or other supported versions.

Bug Fixes

• Fixed a bug where, the local and remote AudioTracks' audioLevels returned by
  Room.getStats() were not in the range [0-32767]. (JSDK-2318)
• Fixed a bug where Video.isSupported evaluated to true on Chromium-based Edge browser,
  even though twilio-video.js does not support it at this moment. (JSDK-2515)

2.0.0-beta15

2.0.0-beta15 (October 24, 2019)

New Features

• twilio-video.js will now support the Unified Plan SDP format for Google Chrome. Google Chrome
  enabled Unified Plan as the default SDP format starting from version 72. In December 2018, we
  published an advisory recommending customers to upgrade to the latest versions of twilio-video.js in order to not be affected by Google Chrome switching to Unified Plan starting from version 72. The way we ensured support of newer versions of Google Chrome in the versions of twilio-video.js released between December 2018 and now was by overriding the default SDP format to Plan B. Starting with this version, twilio-video.js will use Unified Plan where available, while also maintaining support for earlier browser versions with Plan B as the default SDP format. (JSDK-2312)

  NOTE:

  Since Unified Plan SDPs are usually larger than Plan B SDPs, this will lead to some increased signaling
  traffic whenever Participants join/leave a Room or publish/unpublish Tracks. Our load tests using Group
  Rooms with 35+ Participants revealed between 45% to 160% increase in peak signaling traffic. We did not
  notice any significant change in the media traffic. We also noticed about a 20% increase in peak CPU usage,
  which may be partly due to the browser having to process the larger Unified Plan SDPs. Please reach out to
  [email protected] to report any issues you may experience while adopting
  this release.

• Worked around a bug in Chrome and Safari where browser continued to play WebRTC-based MediaStreamTrack even after corresponding audio element was removed from the DOM. With this fix twilio-video.js now disables any RemoteMediaTrack when it's not attached to any media elements. (JSDK-2490)

Bug Fixes

• Fixed a bug where Video.isSupported evaluated to true on Chromium-based Edge browser,
  even though twilio-video.js does not support it at this moment. (JSDK-2515)

1.19.2

Bug Fixes

• Fixed a bug where LocalVideoTracks were being published at a very low bitrate even
  when there was sufficient bandwidth to publish at higher bitrates. (JSDK-2509)

2.0.0-beta14

2.0.0-beta14 (September 17, 2019)

New Features

• In a Group Room, you can now control how your available downlink bandwidth is distributed among the RemoteVideoTracks that you have subscribed to. twilio-video.js introduces the Bandwidth Profile APIs. Note that this feature is currently in private beta and hence will be opt-in. Please reach out to [email protected] for more information about how to enable these APIs for your Twilio Account.

  Using these APIs in a Peer-to-Peer Room will have no effect.

  Bandwidth Profile (private beta)

  You can now configure how your available downlink bandwidth will be distributed among your subscribed RemoteVideoTracks by using a new optional ConnectOptions parameter bandwidthProfile. For more details, please refer to the BandwidthProfileOptions documentation. Here is an example:

  const { connect } = require('twilio-video');
  const room = await connect(token, {
    bandwidthProfile: {
      video: {
        dominantSpeakerPriority: 'high', // Min. subscribe priority of Dominant Speaker's RemoteVideoTracks.
        maxSubscriptionBitrate: 150000, // Max. bandwidth (bps) to be allocated to subscribed RemoteVideoTracks.
        maxTracks: 3, // Max. number of visible RemoteVideoTracks. Other RemoteVideoTracks will be switched off.
        mode: 'collaboration', // Subscription mode: "collaboration", "grid" or "presentation".
        renderDimensions: {
          low: { // Desired render dimensions of RemoteVideoTracks with priority "low".
            width: 320,
            height: 240
          },
          standard: { // Desired render dimensions of RemoteVideoTracks with priority "standard".
            width: 640,
            height: 480
          },
          high: { // Desired render dimensions of RemoteVideoTracks with priority "high".
            width: 1080,
            height: 720
          }
        }
      }
    }
  });  

  Track Priority (private beta)

  While publishing a LocalTrack, you can now optionally specify its publish priority in the following way:

  const localTrackPublication = await room.localParticipant.publishTrack(localTrack, {
    priority: 'high' // LocalTrack's publish priority - "low", "standard" or "high"
  });
  
  // LocalTrackPublication has a new property "priority" which stores the publish
  // priority set while publishing the corresponding LocalTrack.
  assert.equal(localTrackPublication.priority, 'high');

  This signals to the media server the relative importance of this LocalTrack with respect to other Tracks that may be published to the Room. The media server takes this into account while allocating a subscribing RemoteParticipant's bandwidth to the corresponding RemoteTrack. If you do not specify a priority, then it defaults to standard.

  You can also find out about the priorities of RemoteTracks published by other RemoteParticipants by accessing a new property publishPriority on the corresponding RemoteTrackPublications:

  remoteParticipant.on('trackPublished', remoteTrackPublication => {
    console.log(`RemoteParticipant published a Track with priority ${remoteTrackPublication.publishPriority}`);
  });

  Switching on/off RemoteVideoTracks (private beta)

  When a subscribing Participant's downlink bandwidth is insufficient, the media server tries to preserve higher priority RemoteVideoTracks by switching off lower priority RemoteVideoTracks, which will stop receiving media until the media server decides to switch them back on. You can now get notified about these actions by listening to the switchedOff and switchedOn events on the RemoteVideoTrack:

  remoteTrackPublication.on('subscribed', remoteTrack => {
    remoteTrack.on('switchedOff', () => {
      // You can now determine whether a particular RemoteTrack is switched off.
      assert.equal(remoteTrack.isSwitchedOff, true);
      console.log(`The RemoteTrack ${remoteTrack.name} was switched off`);
    });
  
    remoteTrack.on('switchedOn', () => {
      assert.equal(remoteTrack.isSwitchedOff, false);
      console.log(`The RemoteTrack ${remoteTrack.name} was switched on`);
    });
  });

Bug Fixes

• Fixed a bug where LocalVideoTracks were being published at a very low bitrate even when there was sufficient bandwidth to publish at higher bitrates. (JSDK-2509)