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
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