- All traffic is encrypted for client to control server communications (control traffic / passwords / etc.).
- Vibe scrambles data packets using a proprietary encapsulation mechanism.
- Vibe can optionally secure control traffic and RTP packet transmission (client to USHI) with AES 128.
SSL is used from API server to USHI server
The USHI server is connected to the API server and gets commands using SSL from API server. Typical commands are start/stop/edit the meeting. The API server is api.ezuce.com.
USHI connection to MonALISA
Information which is sent to the MonALISA main servers includes:
- USHI activity (# of participants, video and audio channels)
- meeting activity (# of participants, video and audio channels in each meeting)
- users activity technical info (OS, java version, connection type, which IP (UDP or TCP) protocol was used, and Port that was used)
- users activity personal info (nickname, IP address, meeting ID connected to, mac address).
- Connection quality info is also sent out e.g. packet losses per connection.
All this info is stored in our eZuce Viewme database, which is also beyond any partners/service providers control.
Vibe Client Privacy
From a privacy point of view, for guest users eZuce does not store any emails, etc. Just the nickname, IP address and mac address of the client who accessed and joined a meeting. For registered users we do also maintain the user's email address and their password (hashed) if not using Single Sign On.
Video and Audio Encryption
- All data is encapsulated so there are no standard RTP packets traversing the network between Vibe/Viewme client and servers.
- In meetings SRTP encryption of Audio and/or Video with Vibe/Viewme client can be optionally enabled (it is not by default). This is for performance reasons. There is no interface or API to set these options however. This is not used frequently. The big drawback when enabled is the additional CPU cycles required by the clients and the servers to encrypt and decrypt everything.
- WebRTC connections always utilize HTTPS and SRTP, that is mandatory. So packets are encrypted from the client to the WebRTC server and then utilize the encapsulation mentioned before from there, unless the media is set to be SRTP encrypted as explained above.
- For H.323/SIP, we don't connect in secure TLS/SRTP mode so no encryption is used. RTP from the SIP/H.323 client are not encrypted before reaching the server and then depending of the setting (above) could be encrypted or not.