Skip to content

Latest commit

 

History

History
1016 lines (795 loc) · 45.1 KB

CHANGELOG.md

File metadata and controls

1016 lines (795 loc) · 45.1 KB
Raw

The Twilio Programmable Video SDKs use Semantic Versioning. Twilio supports version N-1 for 12 months after the first GA release of version N. We recommend you upgrade to the latest version as soon as possible to avoid any breaking changes. Version 2.x is the lastest Video JavaScript SDK.

Support for 1.x will cease on December 4th, 2020. This branch will only receive fixes for critical issues until that date. Check this guide when planning your migration to 2.x. For details on the 1.x changes, go here.

2.9.0 (December 2, 2020)

Changes

  • Previously, Room.isRecording indicated whether recording is enabled for the Room. Now it indicates if the Track published to the Room are being recorded. If recording is enabled for the Room, then Room.isRecording is set to true when the first Track is published to the Room. It is set to false when the last Track is unpublished from the Room. The recordingStarted and recordingStopped events will be emitted on the Room when Room.isRecording toggles. (JSDK-3064)

Bug Fixes

  • Fixed a bug where LocalTrack event listeners attached by the SDK were not being cleaned up after disconnecting from a Room. (JSDK-2985)

2.8.0 (November 20, 2020)

New Features

  • Enabled discontinuous transmission (DTX) in the Opus audio codec by default, which will result in bandwidth and CPU savings during silence and background noise. You can control this feature using the ConnectOptions property preferredAudioCodecs. (JSDK-3022)

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

// Disable DTX for Opus.
connect('token', {
  preferredAudioCodecs: [{ codec: 'opus', dtx: false }]
});

Bug Fixes

  • Fixed a bug where Chrome Participants failed to restart a LocalAudioTrack or LocalVideoTrack on some android devices. (JSDK-3003)
  • Fixed a bug where sometimes Tracks that were added in quick succession were not published due to a race condition. (JSDK-2807)

2.7.3 (October 21, 2020)

Bug Fixes

  • Fixed a bug where an iOS 14 Safari Participant is not heard by others in a Room after handling an incoming phone call. (JSDK-3031)

2.7.2 (August 12, 2020)

Bug Fixes

  • Fixed a bug where a Participant in a large Group Room sometimes gets inadvertently disconnected with a MediaServerRemoteDescFailedError. (JSDK-2893)

  • Fixed a bug where Room.getStats() returned stats for only one of the temporal layers of a VP8 simulcast VideoTrack. Now, you will have a LocalVideoTrackStats object for each temporal layer, which you can recognize by the trackId and trackSid properties. (JSDK-2920)

    async function getBytesSentOnLocalVideoTrack(room, trackSid) {
  const stats = await room.getStats();
  let totalBytesSent = 0;
  stats.forEach(stat => {
    totalBytesSent += stat.localVideoTrackStats
      .filter(localVideoTrackStats => trackSid === localVideoTrackStats.trackSid)
      .reduce((bytesSent, localVideoTrackStats) => bytesSent + localVideoTrackStats.bytesSent, 0);
  });
  return totalBytesSent;
}

2.7.1 (July 28, 2020)

Bug Fixes

  • Fixed a bug where, sometimes an iOS Safari Participant is not heard by others in a Room after handling an incoming phone call. (JSDK-2932)
  • In version 2.6.0, we had introduced a workaround for this iOS Safari bug which causes your application to lose the microphone when another application (Siri, YouTube, FaceTime, etc.) reserves the microphone. This release refactors the workaround to work for iOS versions 13.6 and above. (JSDK-2928)
  • Fixed a bug where, sometimes an iOS Safari Participant's <audio> and <video> elements were paused after handling an incoming phone call. Because of this, RemoteParticipants could not be seen and/or heard. (JSDK-2899)
  • Fixed a bug where iOS Safari Participants stopped sending video frames after an incoming phone call. (JSDK-2915)
  • Fixed a bug where audio only Firefox 79+ and Chrome Participants could not hear each other in a Peer to Peer Room due to this Chromium bug. (JSDK-2914)
  • Fixed a bug where isSupported returned false for Android Chrome browser on Motorola phones. (JSDK-2878)

2.7.0 (July 8, 2020)

New Features

  • Previously, if you wanted to change the MediaTrackConstraints of an audio or video LocalTrack that is published to a Room, you would have to unpublish it, create a new LocalTrack with the desired MediaTrackConstraints and publish it to the Room. Now, you can just restart the LocalTrack with the desired MediaTrackConstraints. For details, please refer to the LocaAudioTrack.restart() and LocalVideoTrack.restart() documentation. (JSDK-2870)

Bug Fixes

  • Restored es5 support which was broken in 2.5.0. (JSDK-2913)

2.6.0 (June 26, 2020)

Changes

  • Worked around this iOS Safari bug which causes your application to lose the microphone when another application (Siri, YouTube, FaceTime, etc.) reserves the microphone. Now your application will regain the microphone after foregrounding. As a result of this, the LocalAudioTrack's mediaStreamTrack property will now point to the newly acquired MediaStreamTrack, and the started event is fired again on the LocalAudioTrack. The id of the LocalAudioTrack is now no longer guaranteed to be equal to the id of the MediaStreamTrack. Also, if you want to listen to events on the MediaStreamTrack, we recommend that you do so in the started event handler, since it guarantees that you are always listening to events on the most recently acquired MediaStreamTrack. (JSDK-2828)
const { createLocalAudioTrack } = require('twilio-video');

const localAudioTrack = await createLocalAudioTrack();

function onMute() {
  console.log('MediaStreamTrack muted!');
}

function onUnmute() {
  console.log('MediaStreamTrack unmuted!');
}

localAudioTrack.on('started', () => {
  const { mediaStreamTrack } = localAudioTrack;
  mediaStreamTrack.addEventListener('mute', onMute);
  mediaStreamTrack.addEventListener('unmute', onUnmute);
});

localAudioTrack.on('stopped', () => {
  const { mediaStreamTrack } = localAudioTrack;
  mediaStreamTrack.removeEventListener('mute', onMute);
  mediaStreamTrack.removeEventListener('unmute', onUnmute);
});
  • Worked around this iOS Safari bug where, when the application is foregrounded, it sometimes does not resume playback of the HTMLMediaElements attached to RemoteTracks that are paused when the application is backgrounded. (JSDK-2879)

2.5.1 (June 5, 2020)

Changes

  • Removed support for versions of Chrome (23 - 55) and Firefox (22 - 43) that support prefixed versions of the WebRTC APIs that have been deprecated. isSupported will now return false for these browser versions. (JSDK-2832)

Bug Fixes

  • Moved npm dependencies chromedriver and puppeteer to devDependencies from optionalDependencies. (JSDK-2848)

2.5.0 (May 27, 2020)

New Features

  • The client now retries connection attempts when connect() is called and the signaling server is busy. The client may attempt one or more connection attempts with a server specified backoff period. If the client exceeds all attempts the CancelablePromise is rejected with a SignalingServerBusyError. The status of the signaling connection can now be monitored by passing an EventListener in ConnectOptions as shown in the code snippet below. Each event is documented here. (JSDK-2777)

    const { EventEmitter } = require('events');
const { connect } = require('twilio-video');

const sdkEvents = new EventEmitter();

// Listen to events on the EventListener in order to monitor the status
 // of the connection to Twilio's signaling server.
sdkEvents.on('event', event => {
  const { level, name } = event;
  if (name === 'waiting') {
    assert.equal(level, 'warning');
    console.warn('Twilio\'s signaling server is busy, so we wait a little while before trying again.');
  } else if (name === 'connecting') {
    assert.equal(level, 'info');
    console.log('Connecting to Twilio\'s signaling server.');
  } else if (name === 'open') {
    assert.equal(level, 'info');
    console.log('Connected to Twilio\'s signaling server, joining the Room now.');
  } else if (name === 'closed') {
    if (level === 'error') {
      const { payload: { reason } } = event;
      console.error('Connection to Twilio\'s signaling server abruptly closed:', reason);
    } else {
      console.log('Connection to Twilio\'s signaling server closed.');
    }
  }
});

connect('token', { eventListener: sdkEvents }).then(room => {
  console.log('Joined the Room:', room.name);
}, error => {
  if (error.code === 53006) {
    console.error('Twilio\'s signaling server cannot accept connection requests at this time.');
  }
});

  • Reduced connection times by acquiring RTCIceServers during the initial handshake with Twilio's signaling server rather than sending a HTTP POST request to a different endpoint. Because of this, the ConnectOptions properties abortOnIceServersTimeout and iceServersTimeout are no longer applicable, and they will be ignored. (JSDK-2676)

  • Reduced connection times by removing a round trip during the initial handshake with Twilio's signaling server. (JSDK-2777)

  • The CancelablePromise returned by connect() will now be rejected with a SignalingConnectionError if the underlying WebSocket connection to Twilio's signaling server is not open in 15 seconds. (JSDK-2684)

Bug Fixes

  • Fixed a bug where isSupported was throwing an exception in a server-side rendering application. (JSDK-2818)
  • Fixed a bug where sometimes the publishing of a LocalTrack very quickly after another LocalTrack was unpublished never completed. (JSDK-2769)
  • Fixed a bug in Room.getStats() where it did not return correct values for packetsLost, roundTripTime for LocalTracks. (JSDK-2755, JSDK-2780, JSDK-2787)

2.4.0 (May 4, 2020)

New Features

  • twilio-video.js now supports faster signaling reconnections due to network disruption or handoff. (JSDK-2739)
  • twilio-video.js now supports faster media reconnections due to network disruption or handoff. (JSDK-2742)

Bug Fixes

  • Worked around this Chromium bug, which causes Android Chrome 81+ Participants to not be able to subscribe to H264 RemoteVideoTracks in a Group or Small Group Room. (JSDK-2779)
  • Fixed a bug where Video.isSupported was returning true for some browsers that are not officially supported by twilio-video.js. (JSDK-2756)

2.3.0 (March 19, 2020)

New Features

  • reconnecting and reconnected events on Room and LocalParticipant are now fired asynchronously. (JSDK-2696)
  • twilio-video.js now raises connect() errors due to network disruptions quicker by not retrying after the first connection attempt fails. (JSDK-2682)
  • twilio-video.js attempts to reconnect to a Room only while the Participant's session is valid (typically 30 seconds after the reconnecting event) instead of using a fixed number of retries. (JSDK-2683)
  • A LocalParticipant will now have an additional signalingRegion property which contains the geographical region of the signaling edge LocalParticipant is connected to. (JSDK-2687)
  • A Room will now have an additional mediaRegion property which is where media is being processed. This property is not set for Peer-to-Peer Rooms because they do not use a central media server for routing and/or recording. (JSDK-2685)

Bug Fixes

  • Fixed a bug where calling setPriority on RemoteVideoTracks of RemoteParticipants that joined after the LocalParticipant had no effect. (JSDK-2707)

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)

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 (January 21, 2020)

New Features

  • Video.isSupported now returns true for Chromium-based Edge. (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 (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 (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)

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)

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)

2.0.0-beta13 (August 29, 2019)

New Features

  • You can now enable DSCP tagging for media packets by setting a new ConnectOptions property enableDscp to true. DSCP tagging allows you to request enhanced QoS treatment for media packets from any firewall/routers that support this feature. Setting this option to true will request DSCP tagging for media packets on supported browsers (only Chrome supports this as of now). Audio packets will be sent with DSCP header value set to 0xb8 which corresponds to EF = Expedited Forwarding. Video packets will be sent with DSCP header value set to 0x88 which corresponds to AF41 = Assured Forwarding. (JSDK-2456)

    const { connect } = require('twilio-video');
const room = await connect(token, {
  enableDscp: true
});

  • The ConnectOptions flag dscpTagging which was introduced in 1.19.0 has now been renamed to enableDscp. Using the old name still works, but is deprecated and scheduled for removal. (JSDK-2492)

  • Setting bandwidth limits for media using LocalParticipant.setParameters() will now no longer require a round of negotiation with the remote peer and will take effect instantaneously. (JSDK-2460)

Bug Fixes

  • Worked around a minor interop issue between Chrome/Safari Participants and Firefox 68+ Participants in a Peer-to-Peer Room. Although this issue does no affect the normal functioning of the Room, it resulted in the Chrome/Safari Participants logging cryptic Error messages to the JavaScript console. Now, twilio-video.js will log warning messages until Chrome (bug) and Safari fix this issue. (JSDK-2412)
  • Fixed a bug where connecting to a Room with a region containing special characters in ConnectOptions failed with an Error other than SignalingConnectionError. (JSDK-2400)

2.0.0-beta12 (July 12, 2019)

New Features

  • By default, you will subscribe to all RemoteTracks shared by other Participants in a Room. You can now override this behavior through a new ConnectOptions flag automaticSubscription. Setting it to false will make sure that you will not subscribe to any RemoteTrack in a Group or Small Group Room. Setting it to true, or not setting it at all preserves the default behavior. This flag does not have any effect in a Peer-to-Peer Room. (JSDK-2395)

      const { connect } = require('twilio-video');
  const room = await connect(token, {
    automaticSubscription: false
  });

  • twilio-video.js will now detect and attempt to recover from media disruptions quicker than before thereby improving the performance of the Network Reconnection API. (JSDK-2337)

Bug Fixes

  • Fixed a bug where Participants in a Group or Small Group Room stopped receiving Dominant Speaker and Network Quality updates when the media server recovered from a failover. (JSDK-2307)
  • Fixed a bug where, the local and remote AudioTracks' audioLevels returned by Room.getStats() were not in the range [0-32767]. (JSDK-2303)
  • Fixed a bug where Chrome and Safari Participants were enabling simulcast for H264 LocalVideoTracks when VP8 simulcast was enabled. (JSDK-2321)

Developer Notes

  • On October 12, 2018, the specification for the JavaScript Session Establishment Protocol (JSEP) was updated to remove MediaStreamTrack IDs from Unified Plan SDPs (Media Session Descriptions). twilio-video.js depends on MediaStreamTrack IDs to map WebRTC MediaStreamTracks to the corresponding RemoteAudioTracks and RemoteVideoTracks. With this release of twilio-video.js, we have added support for the updated JSEP specification for Firefox and Safari (twilio-video.js uses Plan B SDPs on Chrome). We highly recommend that you upgrade to this version so your application continues to work on Firefox and Safari even after they support the updated JSEP specification. We will provide a detailed advisory once we have more information about when they are planning to support the updated JSEP specification. (JSDK-2385)

2.0.0-beta11 (June 12, 2019)

New Features

  • By default, twilio-video.js connects to your nearest signaling server, as determined by latency based routing. You can now override this behavior by using a new ConnectOptions flag called region. This will make sure that your signaling traffic will terminate in the specified region. (JSDK-2338)

    const { connect } = require('twilio-video');
const room = await connect(token, {
  region: 'de1'
});

    This will guarantee that your signaling traffic will terminate in Germany. For other possible values for region, please refer to this table. If you specify an invalid value for region, connect will raise a SignalingConnectionError:

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

try {
  const room = await connect(token, {
    region: 'foo'
  });
} catch (error) {
  assert.equal(error.code, 53000);
  assert.equal(error.message, 'Signaling connection error');
}

Bug Fixes

  • Fixed a bug where Firefox Participants were not able to publish more than one LocalDataTrack after joining a Group Room. (JSDK-2274)
  • Fixed a bug where Firefox Participants sometimes lost their media connections when they tried to publish a LocalDataTrack in a Group Room. (JSDK-2256)

2.0.0-beta10 (June 6, 2019)

Bug Fixes

  • Fixed a bug where Participants on Firefox 68 or above were unable to publish LocalAudioTracks or LocalVideoTracks. (JSDK-2381)

2.0.0-beta9 (May 2, 2019)

New Features

  • Network reconnection, which was introduced as an opt-in feature in [email protected], is now enabled by default. The temporary ConnectOptions flag _useTwilioConnection has been removed. If this flag is present in ConnectOptions, it will be ignored. (JSDK-2335)

2.0.0-beta8 (April 23, 2019)

New Features

  • You can now use the Network Quality API to receive Network Quality levels for RemoteParticipants in a Group Room. You can also control the verbosity of the network quality information that is reported. A Participant will now have an additional property networkQualityStats which contains the network quality statistics used to calculate the networkQualityLevel. (JSDK-2255)

    You can specify the verbosity levels of the network quality information in ConnectOptions while joining the Room:

    const { connect } = require('twilio-video');
const room = await connect(token, {
  networkQuality: {
    local: 1, // Verbosity level for LocalParticipant [1 - 3]
    remote: 2 // Verbosity level for RemoteParticipants [0 - 3]
  }
});

// Set up reporting of network quality statistics for the LocalParticipant.
setupNetworkQualityStats(room.localParticipant);

// Set up reporting of network quality statistics for RemoteParticipants in the Group Room.
room.participants.forEach(setupNetworkQualityStats);

// Set up reporting of network quality statistics for RemoteParticipants that will join the Group Room.
room.on('participantConnected', setupNetworkQualityStats);

function logNetworkQualityStats(participant, networkQualityLevel, networkQualityStats) {
  console.log(`Network quality level for ${participant.identity}:`, networkQualityLevel);
  if (networkQualityStats) {
    // Verbosity is in the range [2 - 3].
    console.log('Network quality statistics used to compute the level:', networkQualityStats);
  }
}

function setupNetworkQualityStats(participant) {
  // Log current network quality statistics of the Participant.
  logNetworkQualityStats(participant, participant.networkQualityLevel, participant.networkQualityStats);
  // Listen to changes in the Participant's network quality level.
  participant.on('networkQualityLevelChanged', (networkQualityLevel, networkQualityStats) => {
    logNetworkQualityStats(participant, networkQualityLevel, networkQualityStats);
  });
}

    You can also change the verbosity levels of the network quality information after joining the Room:

    room.localParticipant.setNetworkQualityConfiguration({
  local: 3,
  remote: 1
});

2.0.0-beta7 (April 1, 2019)

New Features

  • Added VP8 simulcast support for Safari 12.1 and above, which now supports VP8 along with H264. You will now be able to play back VP8 VideoTracks from Chrome and Firefox Participants in a Group Room. For more details, refer to these guides: Developing for Safari and Working with VP8 Simulcast. (JSDK-2315)

2.0.0-beta6 (March 15, 2019)

New Features

  • Dominant Speaker and Network Quality APIs are now generally available.

  • twilio-video.js now supports versions of Safari that enable Unified Plan as the default SDP format. As of now, Unified Plan is enabled by default in the latest Safari Technology Preview. (JSDK-2306)

  • Network reconnection is now supported as an opt-in feature. Previously, Participants would be disconnected from the Room during network disruptions or handoffs. This feature allows Participants to remain connected to the Room.

    To try this new feature in your application you must perform the following steps:

    1. Set the Time-To-Live (TTL) of your AccessToken to the maximum allowed session duration, currently 14400 seconds (4 hours). This ensures that when a network loss occurs the client will be able to re-authenticate the reconnection. Note, a reconnection attempt with an expired AccessToken will result in an AccessTokenExpiredError.

    2. Ensure that the AccessToken does not contain a configuration profile sid. Configuration profiles were deprecated when we announced the general availability of [email protected]. Configuration profiles are not supported when using this feature.

    3. Enable the feature using the temporary flag _useTwilioConnection as follows:

      const { connect } = require('twilio-video');
const room = await connect(token, {
  _useTwilioConnection: true
});

    4. The reconnecting event will now raise a SignalingConnectionDisconnectedError when a signaling connection network disruption occurs. Previously, the reconnecting event only raised a MediaConnectionError. You can differentiate between errors in the handler as follows:

      room.on('reconnecting', error => {
  if (error.code === 53001) {
    console.log('Reconnecting your signaling connection!', error.message);
  } else if (error.code === 53405) {
    console.log('Reconnecting your media connection!', error.message);
  }
});

    5. When a Participant closes the tab/browser or navigates away from your application, we recommend that you disconnect from the Room so that other Participants are immediately notified. You can achieve this as follows:

      window.addEventListener('beforeunload', () => {
  room.disconnect();
});

    6. If the reconnect attempt takes too long to complete due to network loss or latency issues, then you will be disconnected from the Room with a ParticipantNotFoundError.

    After [email protected] is generally available, we plan to make this an opt-out feature in [email protected], followed by removing our existing SIP-based signaling transport altogether in [email protected].

Bug Fixes

  • Fixed a bug where Room.getStats was throwing a TypeError in Electron 3.x. (JSDK-2267)
  • Fixed a bug where the LocalParticipant sometimes failed to publish a LocalTrack to a group Room due to media negotiation failure. (JSDK-2219)
  • Removed workaround for this Firefox bug on Firefox 65 and above. (JSDK-2280)
  • Fixed a bug where passing invalid RTCIceServer urls in ConnectOptions did not raise a MediaConnectionError. (JSDK-2279)

2.0.0-beta5 (January 7, 2019)

New Features

  • Room.getStats on Firefox will now consume the spec-compliant RTCIceCandidateStats available in versions 65 and above. (JSDK-2235)
  • Participants will now be able to stay in the Room and recover their media connections if the media server becomes unresponsive, instead of being disconnected. (JSDK-2245)
  • Room.getStats is now supported on versions of Safari that enable Unified Plan as the default SDP format. It is not supported on earlier versions due to this Safari bug. We have updated the documentation to reflect this behavior. (JSDK-2201)
  • Room.getStats on Chrome now uses the WebRTC 1.0 compliant version of the RTCPeerConnection's getStats API. (JSDK-2182)
  • Worked around Firefox 63's deprecation of the isRemote property in RTCInboundRTPStreamStats and RTCOutboundRTPStreamStats. (JSDK-2222)

2.0.0-beta4 (November 29, 2018)

Bug Fixes

  • Fixed a bug where, when a Safari Participant joins a Room after a Firefox Participant, it did not receive video frames for VideoTracks published by the Firefox Participant. (JSDK-2224)

2.0.0-beta3 (November 20, 2018)

Bug Fixes

  • Fixed a bug where unpublishing a LocalTrack from within one of its event listeners that have been added before publishing it to the Room throws a TypeError. (JSDK-2212)

Note for Electron developers

  • twilio-video.js will no longer be usable on Electron 2.x or below. Please upgrade to Electron 3.x or higher.

2.0.0-beta2 (October 1, 2018)

Bug Fixes

  • Fixed a bug where calling a LocalVideoTrack's stop method did not stop the video capture, and thereby did not turn the camera light off. (JSDK-2156)
  • Fixed a bug where calling LocalParticipant's unpublishTrack on a LocalTrack that was being published to a Room also stopped the LocalTrack. (JSDK-2169)

2.0.0-beta1 (August 10, 2018)

Breaking Changes

  • Google Chrome, starting from version 72, will enable Unified Plan as the default SDP format. This version of twilio-video.js will choose Plan B as the SDP format in order to continue supporting Google Chrome versions 72 and above until Unified Plan support is added. For more details, please refer to this advisory.
  • RemoteParticipant no longer emits the deprecated "trackAdded" and "trackRemoved" events. Use the "trackSubscribed" and "trackUnsubscribed" events instead.
  • LocalParticipant no longer contains the deprecated addTrack, addTracks, removeTrack and removeTracks methods. Use publishTrack, publishTracks, unpublishTrack, and unpublishTracks instead.
  • RemoteTrack no longer has the deprecated id property. Use the sid or name properties instead.
  • RemoteTrack no longer has the deprecated isSubscribed property. Use the corresponding RemoteTrackPublication's isSubscribed property instead.
  • RemoteTrack no longer emits the deprecated "unsubscribed" event. Use the corresponding RemoteTrackPublication's "unsubscribed" event instead.
  • Participant's trackPublications collection is now renamed to tracks. Similarly, audioTrackPublications is now renamed to audioTracks, dataTrackPublications is now renamed to dataTracks, and videoTrackPublications is now renamed to videoTracks. Participant no longer maintains the deprecated Track-based collections.
  • We removed support for Bower.