Hi guys,
we have trouble with delayed/dropped audio connections from/to Jabber Clients after answering the call.
It takes sometimes 1 sec. up to 3-4 seconds to hear the other party.
The first audio packets are dropped and after this, the audio stream is in sync between the two call parties.
Jabber PRT, Jabber audio dumps, Wireshark packet captures on clients and CUCM logs are showing, that from the audio device the voice stream is not received by Jabber to send RTP packet to the other call party in this first seconds.
Clients are running on Windows 10 and also some on 11.
Drivers are updated and other software is deinstalled or disabled.
Bluetooth headsets, usb headsets or built in mic and speaker from notebooks, it doesn't make a difference.
Clients for testing are connected to the same switch, no WAN link between, no transcoding or MTP source is used.
One software component could cause this problem.
There is Forti-Client used as VPN client and firewall etc..
After installing this software the problem occures and after deinstalling there is no problem.
So it's reported by the customer.
Used Versions:
CUCM 14SU3
Jabber 14.3.1
Forti-Client 7.0.10
Here some findings by Cisco TAC regarding gstreamer audio not fast enough:
2024-02-29 09:00:06,437 WARN [0x00002a1c] [PME(0) ] [pme] [<GStreamer>] - grabber_audio_src [gstbaseaudiosrc.c(911), gst_base_audio_src_create()]-> create DISCONT of 25920 samples at sample 31200
2024-02-29 09:00:06,437 WARN [0x00002a1c] [PME(0) ] [pme] [<GStreamer>] - grabber_audio_src [gstbaseaudiosrc.c(916), gst_base_audio_src_create()]-> warning: Can't record audio fast enough
2024-02-29 09:00:06,437 WARN [0x00002a1c] [PME(0) ] [pme] [<GStreamer>] - grabber_audio_src [gstbaseaudiosrc.c(916), gst_base_audio_src_create()]-> warning: Dropped 25920 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
2024-02-29 09:00:06,437 DEBUG [0x000007b0] [PME(0) ] [pme] [<PME>] - grabber_audio_src: gst_warning: Can't record audio fast enough (d:\Folder1\workspace\build_windows_vs2015_branch_3.31\source\movi\src\tetris\external\gstreamer\gst-plugins-base\gst-libs\gst\audio\gstbaseaudiosrc.c(916): gst_base_audio_src_create (): /GstPipeline:pipeline0/GstBin:grabber_bin_grabber_audio_main_5/GstDuplexAudioSrc:grabber_audio_src:
Dropped 25920 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.)
And here is some errors with audio driver:
2024-02-29 08:56:33,740 INFO [0x000015a0] [c\accessory\AccessoriesManager.cpp(4229)] [csf.accessory.logi.ucplugin] [logMessage] - [08:56:33.740145] [DisplayController] Handling accessory change: Unknown
2024-02-29 08:56:33,740 ERROR [0x000015a0] [c\accessory\AccessoriesManager.cpp(4249)] [csf.accessory.logi.ucplugin] [logMessage] - [08:56:33.740145] Error: An error occurred while handling the accessory change
2024-02-29 08:56:33,740 INFO [0x000015a0] [c\accessory\AccessoriesManager.cpp(4229)] [csf.accessory.logi.ucplugin] [logMessage] - [08:56:33.740145] [DisplayController] Handling display event: AudioPath
2024-02-29 08:56:33,740 DEBUG [0x000015a0] [c\accessory\AccessoriesManager.cpp(4293)] [csf.accessory.event] [csf::accessory::AccessoriesManager::getFirstControlableCall] - No active device
2024-02-29 08:56:33,740 WARN [0x000015a0] [c\accessory\AccessoriesManager.cpp(3918)] [csf.accessory.api] [csf::accessory::AccessoriesManager::processOnActiveDeviceChanged] - No Connected Call available to check Mute Status
Has anybody hitting a similar problem with delayed and dropped audio at beginning of a call?
What could be the problem with Forti-Client, that it is dropping audio packets?
Customer also opened a ticket on Fortinet side to get support.
KR
Dirk
