Connection Quality Indicator

Introduction

When you create a client application based on the SDK you can implement connection quality callbacks. During a call the application can receive callbacks on the quality of the network.
The Call object has a new method to support this:

/**
* Callback for when the quality of the connection from the remote end
* of the call changes.
*
* @param connectionQuality a number between 0 and 100 representing the
* current connection quality, where 100 is perfect
*/
onConnectionQualityChanged: function(connectionQuality) {
console.log("onConnectionQualityChanged: The remote stream
quality is now: " + connectionQuality);
}

Mechanism

  • The connection quality call-back returns a computed quality score out of 100.
  • Currently connection-quality is computed using the measured packet-loss on the received audio stream:
  • Calculation is based on standard E-model quality measure.

R=||100.0 - 95.0xloss/loss+10||

  • The SDK starts collecting metrics as soon as the remote media stream is received. The metrics are collected every 5s, so the 1st quality callback will fire roughly 5s after the remote media stream callback has been established.
  • The callback will then be fired every time a different quality value is calculated, so if the quality is perfect then there will be an initial quality callback with a value of 100 (after 5s), and then no further callback until the quality degrades.
  • Audio Quality is non-linear: 2% more loss does not mean audio is 2% worse
  • Summary of our testing:
  • Loss = 0% --- R = 100 (best it can be)
  • Loss = 4% --- R = 73 (poor but serviceable audio)
  • Loss = 8% --- R = 58 (audio unserviceable)

 

Examples

Following sample application tests completed with 512kbs-1 & 640x480

  • At 0% measured loss
  • NQI indicates a quality of 100

  

  • At 4% measured loss
  • NQI indicates a quality of 73
  • Users may experience audio impairments

 

  • At 8% measured loss
  • NQI indicates a quality of 58
  • Audio unserviceable

  

  • At 15% measured loss
  • NQI indicates a quality of 43
  • Audio unserviceable
  • Users may experience video impairments

  • At 20% measured loss
  • NQI indicates a quality of 43
  • Audio unserviceable
  • Video impairments more noticeable

 

 

 

 

 

 

 

 

Comments are disabled on these articles if you require help contact support@cafex.com.

Have more questions? Submit a request

Comments

  • Avatar
    Curley, Wayne

    Is this measurement for audio only or is it a good tool to use for video as well? Based on the notes above at 43 the audio is unservicable. Does that mean that folks will not be able to hear you but can still see you? It seems based on this you lose audio first then video? Is that true

  • Avatar
    Thomas Hill

    Both Video and Audio are considered when measuring the quality of the network. The RTCP, alongside the video steam, utilize packet loss mechanisms such as NACK and PLI. Most Audio codecs do not use these feedback mechanisms. As a result video can sustain higher levels of packet loss and correct for them. Thus, as packet loss increases, the video will be serviceable for longer than audio.

    Adaptive Rate Control is not being applied in the scenario above; if bandwidth is constrained then the video bitrate will fall, leaving more room for the audio.

    It is very possible that a WEBRTC client will have less bandwidth than the allocated minimum video bandwidth as a result loss will likely be induced. It is generally recommended to disable or mute video if the NQI goes below 60% for a long period of time. This is dependent on the specific application and left to the application developer to invoke.

Powered by Zendesk