eyeson is a WebRTC / SIP / WebSocket based system and the eyeson communication clients – web browsers and mobile apps – connect to the eyeson server and cloud infrastructure and establish different connections on different ports and protocols for registration, call signaling and real time audio / video streaming.

The eyeson core video technology provides a Single Stream transcoding multi speaker video streaming unit (eyeson cloud MCU) which is a virtual meeting room instance started in the cloud on demand when a meeting is started. 

Environment requirements for the use of eyeson

For each communication client a minimum bandwidth of 1.5 Mbit/s for upload and 1.5 Mbit/s for download is required. The bandwidth required needs to be multiplied by the number of simultaneously active clients in the same network.

Note: If 2 clients are connected to the same network at the same time, the needed minimum bandwidth is 3 Mbit/s upload and 3 Mbit/s download. It is recommended to allow preferred traffic for real-time communication connections.

Packet loss in the network connection during active communication between the communication clients has to be less than 2%.

Note: Higher packet loss than 2% can cause pixel errors, frozen video images and in worst case connection loss. Video connection algorithms additionally use packet loss information to downsize video quality in order to keep the video connection active with lower bitrates and resolutions running with lower quality.

Jitter in the network connection during active communication shall be less than 400ms.

The CPU usage of the used hardware platform shall be less than 80% (maximum) during an active connection. Make sure that you close other applications for the case that your hardware does not provide sufficient processing power.

Note: Higher CPU usage than 80% can cause pixel errors, frozen video images and in worst case connection loss. Video connection algorithms use CPU usage values also to downsize video quality in order to reduce CPU usage with lower rates and resolutions running with lower quality.

The Internet connection shall allow direct UDP communication between all real-time streaming system components.

The network environment shall be configured in a way that a TCP proxy connection is NOT needed. The eyeson communication software additionally supports TCP and UDP TURN relay streaming connections, but this causes a deviation from ideal real-time communication conditions. For this reason, the requirement is that TCP and UDP TURN RELAY connections shall be avoided by network and firewall configuration as far as possible.

(TCP option*) Is not recommended, but possible for networks that do not allow UDP communication in general.

Minimum required setup (**)

(**) All active media streams connect via defined secure eyeson STUN/TURN Media proxy service. The service domains may resolve to one or more IP addresses, which need to be configured (e.g. use nslookup api.eyeson.team).

Optional setup extension for optimum streaming conditions (***)

(***) All connections go directly between eyeson clients and cloud conference servers, STUN/TURN Media Proxy not used in active stream.

How much bandwidth do I need?

One of the advantages of the single stream technology in terms of bandwidth usage is, that each client only sends and only receives one stream – independent of the number of participants in a conference.

So the conference connection is reduced to a P2P call from the clients point of view. Each client has only one upstream and one downstream.

The connection for up- and downstream of each client automatically adjusts with the real time streaming capabilities of the network the client is located in. Possible adjustments:

  • 960p @ 20fps --> approx. 1.5 Mbit/s
  • VGA @ 20fps --> approx. 0.8 Mbit/s
  • QVGA @ 20fps --> approx. 0.4 Mbit/s
  • QQVGA @20fps --> approx. 0.1 Mbit/s

So the bandwidth usage range for an eyeson connection is between 0.1 - 1.5 Mbit/s per client.

Please note that the quality of the video will be reduced by automatically adjusting to networks not fulfilling the network requirements described in this article.

We hope everything is clear so far ;)

Did this answer your question?