Optimizing the Experience When Using Video Software Clients

The My Meeting Video (MMV) Desktop and Web (browser-based WebRTC) software clients from Pexip Cloud are robust and will almost always connect due to their ability to tunnel through even the most secure networking environments.  Even though the video call connects however, the experience may in a few cases not be optimal.  The video and audio may appear to have a sluggish response, there may be motion and audio synchronization problems, and content sharing may be delayed.  This article explains some common equipment and environment elements to consider to ensure the best possible video calling experience when using MMV Desktop/Web softclients on the Pexip Cloud Video Service.

1. For the End User

a) Sufficient Computing Resources

The more the computing horsepower available on the device, the better.  A current or newer computer with greater CPU and graphics capabilities is strongly recommended, as the processing of real-time video and audio can be computationally expensive.  Most computers within 2-3 years of age are likely powerful enough; anything older may have difficulties with processing power for the real-time media.  Cameras capable of off-loading computational work away from the device CPU are a benefit, when available.

b) Wired Network Connection

Wired LAN connectivity is better than WiFi connectivity, as the quality and reliability of WiFi connectivity may vary considerably over a coverage area.  It is a reliability and signal strength consideration when WiFi connectivity is used.  If your device location is in a poor signal area, your video call quality may be poor and have jerky responsiveness.

c) Choosing a Web Browser Standard

Pexip's recommendation is for the organization to use and standardize on a WebRTC-capable web browser, as opposed to a browser which does not natively support WebRTC and which requires a Plug-in to be downloaded and installed.  The preferred browser types are Google Chrome and Mozilla Firefox, as these two browsers have built-in WebRTC technology and are frequently updated with enhancements and security fixes.  Google Chrome still requires a small Plug-in to enable content share initiation.  The latest releases of Mozilla Firefox (Quantum) however, completely remove the need for any Plug-ins to be downloaded and installed -- you can get video/audio/content share initiation just by using the browser alone.

d) Microphone, Speaker, and Camera

Pexip recommends using good quality microphone, speaker, and camera devices for the richest video experience.  To combat the possibility of echo, the use of external peripherals which have built-in echo cancellation technology is recommended, or to use a headset.  If no external peripherals are being employed and the PC microphone is used, use earbuds so that PC speaker output will not be picked up and fed back in via the microphone.


2. For the IT/Network Administrator (and Advanced Users)

a) Sufficient Bandwidth

Some users use tools like Ookla’s SpeedTest (http://www.speedtest.net/) to measure their Internet connection’s bandwidth availability.  This measure of bandwidth availability gives one a measure of the peak transmit and receive rates encountered during the test, but this may give false confidence that there is ample bandwidth.  What is more meaningful is the smoothness of the bandwidth profile as a function of time.  If the bandwidth access is highly variable and goes between 64 kbps to 50 Mbps, SpeedTest will still just report that the bandwidth availability is up to 50 Mbps.  If during the testing the bandwidth profile is smooth at 48 Mbps and has peaked at 50 Mbps for a brief time, it is much better that the profile was smooth and you can generally count on having access to 48 Mbps at any time.
To test the quality of the connectivity one can use the Network Assessment Tool at https://pexip.me/test to run a bandwidth test which will send out UDP/RTP media at a few different rates consistent with video traffic at Standard Definition quality, 720p quality, and 1080p quality.  These tests will tell the user what the quality of the connection is at these bandwidth costs for a video call, in terms of measured packet loss, jitter, and delay.  A report will be generated providing a quality score, which the user can save as a text file so it can be reviewed with IT staff if necessary.
In order to have a good video calling experience, we recommend that at least 1 Mbps of bandwidth be available for the call itself, on top of other traffic competing for access to the Internet.  1 Mbps of bandwidth equates to a Standard Definition video experience using the "Medium Quality" setting on either My Meeting Video (MMV) Desktop or Web software clients.  The "High Quality" setting should be used along with 1.5 Mbps or better to achieve a 720p video call.

b) Avoid or Accommodate for VPN Connections

If VPN is being used to connect to a corporate site, sending real-time traffic over a VPN tunnel could result in a degraded video call experience.  Sending video, audio, and content share traffic over a VPN tunnel adds delay, additional computational requirements, and may send the traffic over a suboptimal path before reaching the resources in the Cloud Video Service.  The best VPN policy is to use split-tunneling where traffic bound for the corporation goes over the VPN tunnel, while traffic bound for the Cloud Video Service bypasses the VPN tunnel and is routed over local Internet connectivity.  The IT Department will likely need to be engaged to configure split-tunneling routing policies; they will wish to create routing policies based on the list of traffic types, port ranges. and source/destination IP address ranges listed at https://pexip.me/test/firewall .

c) Open up for UDP/RTP

Real-time media typically uses UDP as a protocol, as it is not connection-oriented and does not need acknowledgement from the far-end for each packet sent.  UDP-based media is "best effort", and the far-end can utilize error-correction technologies to interpolate and conceal missing packets.  On the other hand, TCP can also be used for media transfer but this is not optimal as each packet sent needs acknowledgment from the far-end to determine if it needs to be re-sent.  TCP-based media is connection-oriented and the requirement for acknowledging each packet can lead to poor performance in lossy network environments where re-transmissions result in extra computational effort and sluggish response.

Determine if UDP/RTP traffic is being blocked on the network.  The UDP port requirements for the Cloud Video Service are listed at https://pexip.me/test/firewall.  The My Meeting Video Desktop/Web softclient uses UDP/RTP for media normally, as this is the optimal protocol traffic type for real-time traffic.  In the case where it is detected that UDP/RTP is being blocked however, both MMV Desktop/Web software clients fall back to using TCP for media and combining signaling and media traffic together over TCP 443 (HTTPS).  It is very often the case that TCP media will lead to noticeable delay and synchronization issues between audio and motion, as well as to delay content share streams.  It's always better to have media as UDP/RTP traffic; the TCP tunneling fallback is there mostly to allow the communication to take place so there's at least a successful communication, albeit not optimal.

d) Network Appliances Manipulating Packets

Consider if there are security appliances at the network edge which could be delaying the transfer of media traffic.  Is there deep packet inspection that is adding delay?  Such packet inspection policies will lead to sluggish video call behavior.

Last updated: 2019-06-11

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.