Setting up video conferences in Bitrix24: limits, capabilities, and configuration

Setting up Bitrix24 video conferences: where the connection breaks

A conference on the portal starts in one click from the meeting card, so it seems that setting up Bitrix24 video conferences ends with the "enable" checkbox.

In reality, stability consists of three independent links: the portal's server side, the office-side bandwidth, and the channel quality for each participant. A failure does not manifest as "everything went down," but as gradual degradation — first jitter, then desync.

The first typical failure is a drop in video quality under peak load. In the morning, reports, stand-ups, and client calls start simultaneously; the outbound channel hits its ceiling, this is communication channel overload, and the server begins compressing the video stream.

Participants' video breaks up, slides and diagrams become unreadable, while audio is fine — so the problem is noticed late.

The second scenario is connection dropouts during meetings for remote participants. Home Wi-Fi, mobile internet, and corporate proxies break the connection, and the person drops out of the meeting for 20–40 seconds, losing the context of the discussion.

A separate problem is audio-video desync: buffers accumulate, the voice does not match lip movement, and the meeting has to be restarted.

The cost of these failures is cumulative. A ruined demo, repeated questions, a repeat call with the same people — and instead of half an hour, the work takes an hour.

It is worse when the failure happens during a project defense or interview: what spoils the impression is not the content, but the connection. Next, we break down how this is addressed by configuration — from the quality profile and channel redundancy to server-side parameters.

What managed conferencing within the company perimeter provides

The effect of managed conferencing is measured not by the number of features, but by how many meetings take place without losses. Below is what actually changes after configuration: resilience at peaks, uniform rules for all locations, and an eliminated class of failures.

Resilience under peak load

The conference is served by a dedicated node, not the host's device, so dozens of participants joining at once does not turn into a crumbling picture. The server balances streams to each person's channel: a weak connection for one does not degrade quality for the others.

Morning stand-ups and all-hands meetings run without reconnects, and the share of meetings disrupted by connection issues drops to isolated cases.

Uniform communication rules for offices and remote employees

Scenarios — rooms, permissions, recording, invitations — are set at the portal level and work the same in a meeting room and from home. A remote employee gets access by group, not by an instruction in chat, and connects on the first try. An administrator changes a rule in one place, and it immediately applies to all offices.

Reduced downtime

So that stable video communication does not depend on luck, typical failures are addressed at the configuration stage: permissions, audio, channels, and recording are checked.

Starting a meeting comes down to one action, and the number of communication-related requests drops severalfold — most reasons simply do not arise.

Video conferencing connection options: comparison of modes

The connection scheme is chosen not by the number of participants, but by two questions: where people come from and where meeting recordings remain.

While meetings take place only between employees, the portal's built-in conferences are enough — they are already linked to the calendar and employee cards, and no separate configuration is needed.

As soon as external participants appear in a call, requirements are added for access and for how a guest gets into your network. An internal communication perimeter gives full control over traffic and recording storage, but requires maintenance.

A hybrid scheme keeps the team's core inside the company and routes external participants through a separate node.

The choice is fixed in access rights: for a hybrid scheme, we separately describe which external participants get permanent access and which get only a link to a specific meeting. This also determines how diagnostics proceed when one of the parties loses connection.

Implementation procedure: from network audit to handover to support

Implementing video conferencing is not installing an app on the portal, but a project with a verifiable result: communication must withstand peak meetings and not fall apart when the channel weakens.

The work procedure is the same for a cloud perimeter and for a scheme with your own server — only the set of settings changes. Below are six stages by which we run the project from the first measurement to the support policy.

1. Network and scenario audit. We take a traffic profile during working hours: bandwidth headroom, losses, and delay jitter at each segment, separately for meeting rooms and home connections.

   In parallel, we collect real scenarios: number of participants, external guests, recording, broadcasting, mobile devices.

2. Scheme design. We decide what remains on the portal service side and what requires a separate node, how roles, permissions, and recording storage are distributed. The output is a scheme with failure points and a rule of action for channel degradation.

3. Configuration. We set up rooms and access rules, restrictions on external connections, recording and storage policies, and integration with the calendar and tasks. Separately, we set traffic priority for meetings so communication does not compete with file exchange.

4. Load testing. We run sessions with the estimated number of participants on the peak profile, measure latency and loss rate, and check recording and broadcasting. We record the threshold beyond which quality drops and the conditions under which a backup channel is needed.

5. Training. We go over typical situations with employees and meeting room owners: connect a guest, switch to a backup channel, report a failure. We keep instructions to one page — they are read at the moment of a problem, not in advance.

6. Handover to support. We hand over configurations, the scheme, access details, and integration points, and a response policy with escalation levels.

   Plus a set of communication quality metrics that make the perimeter's state visible at any moment, not only from participant complaints.

Set of documents and settings after communication implementation

The implementation of video communication is considered complete not when the first call takes place, but when the customer's team has a package according to which the system can be operated, developed, and handed over to another administrator.

Therefore, delivery is not a demonstration of a working room, but a set of artifacts, each of which is verified on a live system.

• Connection diagrams — how the conference server, portal, external channels, and PSTN gateway are connected: what is routed where, where the media stream passes, which nodes are failure points, and what degrades first under overload.
• Working configurations — recording parameters, stream quality, and profiles for internal and external participants are moved into configuration files, rather than left "configured in the interface and forgotten"; next to them is a description of which parameter is responsible for what.
• Access policies — who is allowed to create rooms and invite external guests, who can access recording and exporting it, who administers nodes; rights are granted by directory groups rather than individually, so a new employee automatically receives the required set.
• Usage policy — rules for holding meetings: when recording is enabled, how long recordings are kept, what to do when the channel degrades, whom to contact in case of failure, and in what escalation order.
• Instructions for employees — separate short guides for the meeting organizer, regular participant, and administrator: typical actions, common mistakes, and the procedure for checking microphone and camera before the call starts.
• Video communication documentation — system datasheet: node composition, limits on the number of simultaneous participants and rooms, update procedure, known limitations, and workarounds for them.
• Change log and rollback plan — what edits were made and why, how to return to the previous state if an update disrupted communication.

Documents are not written "for a checkmark": before delivery, we go through each item together with your administrator and verify that the instruction matches the actual behavior of the system.

If an employee can start a meeting without asking us questions, the package has been assembled correctly.

Case: distributed team and communication channel overload

A distributed team — forty people across three time zones: sales, development, support. Meetings happened across all channels at once: some in shared rooms, some in personal calls, some entirely as text in chat.

In a week, out of thirty scheduled calls, three or four were disrupted, and the rest began with a ten-minute squabble of "I can't hear you."

Measurements before implementation: 12% of meetings did not take place or were rescheduled due to connection issues, and the average time to start was eight minutes for connecting, checking the microphone, and manually sending the link.

Every fifth participant dropped out at least once per meeting due to audio, and the discussion had to start over.

What was changed

We separated scenarios by type: permanent rooms for stand-ups and separate ones for client demos and interviews, each with its own set of permissions and its own participant list.

In Bitrix24, connection was tied to the calendar — one-click entry, an automatic reminder ten minutes before, noise suppression, and automatic recording enabled by default for external meetings.

We added a backup perimeter: a separate room with reduced channel requirements, where a participant is switched if their video consistently fails to hold. The schedule was rebuilt so that time zone overlaps did not consume entire working hours.

Result: the share of disrupted meetings fell from 12% to 2%, and call preparation was reduced from eight minutes to one or two.

Recordings are automatically attached to the deal or task card, so those who could not connect read the summary instead of asking colleagues again for the next twenty-four hours.

How does external conferencing differ from internal?

The difference between the modes is not in the start button, but in where the media stream passes and how the participant's rights are verified.

Internal conferencing lives within the Bitrix24 perimeter: login by account, participant composition from the company structure, recordings are placed on the shared drive and inherit the same access policies as other files.

External conferencing is needed for contractors, clients, and candidates: the organizer issues a link, the guest does not need an account — but access rules have to be described anew.

Channel requirements diverge more strongly. In internal mode, participants are on the same company network, and quality depends only on the load on the portal.

In external mode, half join from home and mobile networks, behind proxies and corporate restrictions — this is not managed from the portal side, so the policy includes headroom for the number of simultaneous connections and a restriction on recording.

On a deployed portal, the modes do not conflict, but they share settings: separate access groups, guest link lifetime, recording rights, and the list of domains from which login is allowed.

Internal meetings are kept closed, external ones are exposed through guest invitations — both schemes are described by the portal policy, otherwise guest access opens the calendar and files more widely than planned.

Common technical questions about conferencing

Some questions about video conferencing arise not at launch, but in operation: participants hit a limit, a meeting recording cannot be found, and after a portal update the invitation of external colleagues breaks. Below are answers to technical doubts that we resolve before work starts.

Where are meeting recordings stored, and how are they managed?

The recording is placed on the portal drive or in external storage; in the first case, it quickly takes up space and requires a storage policy.

We configure auto-cleanup by term and meeting type, and tie access to groups — a recording of a management meeting should not be opened via a direct link.

What happens to conferencing when the portal is updated?

Module settings are carried over by the update, but local edits to templates and scenarios may be rolled back. Before updating, we take a configuration snapshot and run the full cycle on a portal copy: creating a meeting, inviting external participants, recording, notifications. If something breaks, returning to the previous snapshot takes minutes, not a working day.

Who supports the portal after handover?

We hand over configurations, diagrams, and instructions for the administrator, so your team handles typical tasks on its own. Portal support on our side includes failure on-call duty, module updates, monitoring conference limits, and refining scenarios for new meeting formats.

Let's discuss your conferencing task

To come back with an estimate and work plan rather than generalities, we need to break down your conferencing scenario: how many meetings and participants at the same time, whether there are external connections, whether recording is needed, and how long to store it.

Then we look at how this fits the current portal — its edition, department structure, access rights, and employee calendars.

Based on the review, you receive:

• a connection scheme for scenarios — scheduled meetings, webinars for an external audience, conferences from mobile devices;
• a list of portal settings that need to be changed, indicating what affects existing users and what does not;
• access and role rules: who creates meetings, who moderates, who can record and download materials;
• recording storage policy — retention period, location, procedure for export and deletion;
• the procedure for integrating conferences with the calendar, tasks, and client cards so that a meeting link is not created manually;
• an estimate and work plan with stages, timelines, and points where your decision is needed;
• a handover policy for video conferencing support: who responds, how quickly, what is considered an incident, and what is routine configuration.

Describe your conferencing task — with the number of participants, scenarios, and current difficulties.

We will come back with an estimate and work plan, and after configuration is complete we will stay on video conferencing support: we monitor load and communication quality, update settings as the team grows, and connect new scenarios.