When resolving issues with video and audio, be advised that such communication methods are based on multifactorial system having possible issues on different levels. Possible causes: telecom operator (Voixplant), networks (local and Web) and client's end user equipment and etc. Optimal method to find such issues is to check all components for this process step by step.
Note: Bitrix24 is not a telecom provider and is not liable for quality of IP telephony services.
One of analysis tools could be thelogs, maintained by Bitrix24. You can view such logs in the Log column via the link ссылке Details at the Balance and statistics page.
Note: Bitrix24 On-Premise allows logs in NGINX settings via the parameter
Below are several methods for communication elements and call-triggered workflow description.
Local network and messengers
Checking local network settings
In any case, start issue solving by checking the settings for local network, firewalls and anti-viruses. It important to remember Voximplant sends requests to check active IP addresses. This requirement periodically changes and Bitrix24 inc., monitors such changes as well. This results in the table with URLs and ports inside the Telephony section to be up-to-date at all times.
In addition to the technical issues with equipment, messenger settings may be incorrect. In this case:
- Enter messenger settings, Equipment tab.
- Directly select a needed headset and save changes.
- Or remove the flag at Auto adjust microphone parameters and save changes.
Connection quality check
How to check connection quality between two specific peers in realtime conditions
Sometimes, when investigating cases of poor videocall connection, client's equipment setup - headset, camera, installed drivers and etc are suspected. For example, client complains as follows: "with time, the sound has background rattling noises and then connection is terminated completely, with video feed intact". One of possible reasons: user headset issues. In this specific case, the client can launch Bitrix24 Desktop app in test mode with test media (that excludes effects of operational headset) and start one more communication session with the same call party. If the connection is not lost in this mode, the suspicion regarding the equipment gains credibility. If the connection is still lost, the reason is most likely is the NAT/Firewall settings, incorrect WebRTC, TURN operation and etc. Headset change is not required and won't fix the issue.
One more method to text the connection with the same participants, but with "virtual" media devices, excluding the effect of real-life media equipment, and confirm or disprove the suspicions.
To do it, launch Bitrix24.exe (desktop application) with the key
Embedded Chrome with the key will generate test video and audio. Video will show dynamically filled-in circle and counters and the audio will transmit periodic DTMF signal.
You can also organize audio and video transmission from test files with more complex media stream:
Bitrix24.exe --use-fake-device-for-media-stream --use-file-for-fake-video-capture="waterfall_cif.y4m" --use-file-for-fake-audio-capture="a2002011001-e02.wav"
Test files have special requirements: video in y4m format, audio in wav format with 44.1 khz sampling rate.
When test files are displayed and communicated properly, it means equipment issues.
SIP-phone call forwarding
In case of issues with call forwarding using SIP phone, check SIP phone itself may be the reason.
There are three participating parties in forwarding:
- Who calls transfers (Transferor)
- Who is transferred (Transferee)
- Who accepts the transfer (Transfer target)
At the moment of forwarding, Sip phone exchanges SIP messages with Voximplant telecom provider. Voximplant performs the following as the result if this exchange:
- merges Transferree and Transfer target media flows
- separates Transferree and Transfer target media flows
- sends the event
CallEvents.TransferComplete during all the stages at forwarding.
When this event is missing in the call log (and client clicks on all the correct buttons for forwarding), then:
- client's phone generates non-standard SIP commands,
- or client experiences network issues.
In this case, log for this call must be sent to Bitrix24 technical support for investigation. Only Voximplant can find out what occurred at client's phone.