This information is displayed when you click the Properties button while the participant’s status is active. See the article «Participant List (+DTMF)».
If a FullHD participant lacks 2.5 free licenses, they will connect in HD and consume one license. If only 0.5 license remains, they will connect in VGA and consume these 0.5 licenses. This logic applies to the tiered licensing system, not to port-based licensing. (The distributed package uses port-based licensing by default.)
When using port-based licensing, if FHD licenses are insufficient but HD, VGA, and audio licenses are available, video licenses are selected first, then audio-only licenses. If all license types are insufficient, the server denies conference access to the subscriber by rejecting the call both from and to the conference. If the call is made from the conference, this event is recorded in that conference’s log; if the call is incoming, it is recorded in Logs under Reports on the server.
GPU — up to 90%, CPU — 70%.
Recording will not start if all available licenses on the server have already been used. The conference log will show the message Participant monitor disconnected self moveto= cause=-1. If possible, enable recording in advance when starting the conference. Active recording will begin automatically when there is at least one participant in the conference. It will consume its own license and will not stop unless you disable it manually, until all participants leave the conference. The conference log will show the corresponding messages — Conference recording was enabled and Participant monitor connected successfully.
Matches (case-sensitive) are searched in the Number, Name, and IP fields.
The higher the frame rate, the greater the requirements for the server, client endpoint equipment, and communication channels. If better meeting quality is required and the equipment supports it, then it makes sense.
Recommended minimum ratios
| Resolution | Minimum speed | Recommended speed |
|---|---|---|
| 360p | 384k | 512k |
| 720p | 1M | 2M |
| 1080p | 2M | 4M |
For the Vinteo Desktop application and the web client, the subscriber type is WS. For SIP connections, the subscriber type is SIP; for H323, it is H323 respectively.
A PIN code is automatically generated when a room is created. Conference participant subscribers can connect without entering a PIN code if they call the conference number.
If a subscriber knows the number of an open conference and calls that number, the server will not request a PIN code, even if the connection is anonymous, and will connect them to the conference.
Each client (hardware codec) has its own address book, which is created and managed locally on the terminal. Vinteo Desktop has its own address book for each WS-type subscriber. When a subscriber logs in to Vinteo Desktop, the address book is synchronized with the server. This way, a subscriber can have the same address book when moving to a different workstation.
In Vinteo, the WebRTC connection mechanism is fully implemented in accordance with the standard. The standard provides for encryption of the signaling stream (websocket) via TLS (v1.2) and media streams via DTLS SRTP. You can read more in this Habr article: https://habr.com/ru/company/Voximplant/blog/413165/
An advantage of our solution is that it does not violate end-to-end encryption principles, which is inherent in video conferencing solutions based on proxying participant video streams.
Yes, this is supported in version 26.0.7. You can create multiple administrator accounts in the Users section.
Any subscriber who has authenticated on the server can also create and schedule conferences, as well as moderate their own conferences and conferences where they have been assigned as a moderator by other moderators or an administrator. The differences between a moderator and an administrator are that a moderator does not have access to server settings, conference recordings (except those where they are a moderator), uploading videos to the server, editing the subscriber list, creating permanently existing conference templates and adding or removing themselves as a moderator from them, or server diagnostic information. Otherwise, a subscriber in a conference where they are assigned as a moderator has the same rights as an administrator.
IP addresses configured for server subscribers or gateways are not added to the block list. Therefore, you can either create a subscriber with the required IP address or create a gateway and specify that incoming connections are allowed.
For stable operation, the connection must meet the following parameters:
• connection speed in both directions must be at least the minimum value for the resolution in use. See What is the optimal bandwidth-to-resolution ratio for client configuration?;
• no packet loss (if there is loss, no more than 1%);
• low jitter (≤ 30 ms);
• packet round-trip time (RTT) ≤ 850 ms.
Situations where a participant disconnects during a conference are quite common, and it is necessary to determine the cause of such disconnection.
The causes may vary:
• network problems;
• disconnection by an administrator or moderator;
• the participant initiated disconnection themselves.
To determine the cause, refer to the conference log. If the conference is currently running, its log can be viewed by clicking the Conference Log button in the upper right part of the screen.
After the conference ends, to obtain a report, open the Reports section list and go to the Logs page, where you can select the required log entry.
The following actions are available for logs:
• viewing the log;
• saving to the administrator’s workstation for further analysis.
The conference log looks like this:
At the moment of connection loss, a line containing disconnected appears in the log, indicating the disconnection initiator: system or self.
Self indicates that the disconnection was initiated by the participant’s device or software. If the connection was over H.323, the disconnect code can most accurately determine what caused the disconnection.
To determine response codes (Cause code), you can use this article: https://ru.wikipedia.org/wiki/Q.931
For SIP and WebRTC connections, there is only one informative disconnect code: 130, which means a media traffic receive timeout, i.e. some network problem. Code 200 means the disconnection was initiated by the client for an unknown reason.
If system is indicated after disconnected, this means the server initiated the disconnection. In this case, to understand the cause, study the log below the disconnection message.
When an administrator disconnects a conference participant from the web conference management interface, the logs will show a message with the system parameter and code 200 if the participant was connected via WebRTC or SIP.
Code -1 (i.e. no code) if the participant was connected via H.323.
To have participants’ microphones turned off when the conference starts, do the following:
- before starting the conference, on the conference management page go to the Settings tab;
- enable the Microphone off on connect toggle;
- click the Save button at the bottom of the page.
When connecting to a conference as a participant via a link, you can turn off your own microphone by clicking the button at the bottom of the screen. The microphone will be inactive.
For HLS streaming, system characteristics are not decisive, since operationally this amounts to one additional connection to the conference that collects and processes video, splits it into segments (chunks), and stores them on the server’s RAM disk. Each viewer randomly accesses the server over TCP and downloads video segments at the maximum available speed as they watch.
Therefore, the most important factor is the channel bandwidth from the viewer to the server, including on endpoint interfaces. For example, with a 1000 MB bandwidth, if 100 viewers connect simultaneously and download chunks at 10 MB each, they will fully load the channel (depending on HLS settings). However, as a rule, the load is distributed evenly as viewers connect. On a dedicated channel, streaming will proceed without problems for conference participants.
In HLS streaming parameters, you can set the resolution, bitrate of each HLS stream, segment length and size, and try to calculate in tests the total channel capacity required for the necessary number of stream viewers (Server streaming configuration).
An alternative is to stream the conference via RTMP/RTMPS to CDN (Content Delivery Network) resources. In this case, channel load is expressed as one additional stream sending traffic to the CDN. Viewers connect and receive the stream from there without affecting server operation. CDN resources include, for example, VK, YouTube, and Telegram.
Therefore, we recommend providing sufficient bandwidth and dedicating a separate interface on the server for web streaming, or streaming the conference via RTMP/RTMPS to CDN resources (VK, YouTube, Telegram — Streaming a conference to a VK profile).