Platform Security


MIVNET.COM Security scan 12/10/2020

Click to expand



Security highlights:

  • All traffic is encrypted for the client to control server communications (control traffic/passwords / etc.).
  • Connect scrambles data packets using a proprietary encapsulation mechanism.
  • Connect 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 the API server. Typical commands are start/stop/edit the meeting. The API server is


USHI connection to MonALISA

USHI server is sending MonALISA monitoring information to MonALISA servers which are also in the Connect Cloud. The main MonAlisa servers are and

The 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 MIVNET Connect database, which is also beyond any partners/service provider's control.


Connect Client Privacy

From a privacy point of view, for guest users, MIVNET 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 Connect/Connect client and servers.
  • In meetings, SRTP encryption of Audio and/or Video with Connect/Connect 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, which 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 is not encrypted before reaching the server and then depending of the setting (above) could be encrypted or not.
Customer Support