We are using stable jitsi-meet_5142 with some modification in the UI side.
Normally we don’t suffer any problems regarding audio but sometimes we are suffering audio hearing problem like I can even see the video but can’t hear his voice, this problem is for the opposite person too. We couldn’t track/regenerate the root cause of the problem but suspected that the low bandwidth entry or up/down in bandwidth can cause them though bandwidth was not that bad and moreover I was able to see the video…!
And in JVB log we found a SEVERE issue : "IceTransport.send#225: Error sending packet java.io.IOException: No active socket."
Edit : most of the participants was using our desktop app which’s version is Chrome/83.0.4103.119 Electron/9.0.5 Safari/537.36
is there any possibility to have audio bug in the version?
Full Log
2021-03-07 21:20:20.228 WARNING: [18355] CountingErrorHandler.packetHandlingFailed#62: Failed to handle packet:
java.lang.RuntimeException
at org.jitsi.videobridge.transport.ice.IceTransport.send(IceTransport.kt:226)
at org.jitsi.videobridge.Endpoint.doSendSrtp(Endpoint.java:427)
at org.jitsi.nlj.util.PacketInfoQueue$sam$org_jitsi_utils_queue_PacketQueue_PacketHandler$0.handlePacket(PacketInfoQueue.kt)
at org.jitsi.utils.queue.PacketQueue$HandlerAdapter.handleItem(PacketQueue.java:575)
at org.jitsi.utils.queue.AsyncQueueHandler$1.run(AsyncQueueHandler.java:141)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2021-03-07 21:20:20.228 SEVERE: [18355] [confId=f2d99bed24eec02e epId=b1f22121 local_ufrag=ko9i1f084ejhb gid=84306 stats_id=Rossie-QXq conf_name=user@conference.dummyCon.com] IceTransport.send#225: Error sending packet
java.io.IOException: No active socket.
at org.ice4j.socket.MergingDatagramSocket.send(MergingDatagramSocket.java:202)
at org.ice4j.socket.DelegatingDatagramSocket.send(DelegatingDatagramSocket.java:776)
at org.jitsi.videobridge.transport.ice.IceTransport.send(IceTransport.kt:222)
at org.jitsi.videobridge.Endpoint.doSendSrtp(Endpoint.java:427)
at org.jitsi.nlj.util.PacketInfoQueue$sam$org_jitsi_utils_queue_PacketQueue_PacketHandler$0.handlePacket(PacketInfoQueue.kt)
at org.jitsi.utils.queue.PacketQueue$HandlerAdapter.handleItem(PacketQueue.java:575)
at org.jitsi.utils.queue.AsyncQueueHandler$1.run(AsyncQueueHandler.java:141)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Anyone have experienced this or have any idea why is this happening?
Thanks in advance
mm unfortunately the problem was from client so we could not collect that info’s.
One our man was in the conference but he didn’t check. This specially happen’s when 1 special client host the meeting. The problem is we couldn’t regenarate the environment and thats why we are struggling to find the cause. can u make any guess?
Ah, so it’s a specific user. It’s hard to tell because clearly it’s something in the user’s environment that’s responsible. As you noted, I don’t think it’s a bandwidth thing if video is going through. Perhaps it’s a hardware issue on the user’s end?
yeah it can be possible. and it is also possible that sometimes his audio input/output starts being inactive. But the thing is , zoom meetings doesn’t have these issues wile being host in that pc. Can this be any antivirus actions? because we has a issue where a antivirus was suspecting virus and stopped network packet going/incoming.
Yes, it could also be due to an antivirus.
You really shouldn’t make comparisons with Zoom though because these two operate differently. Apart from the obvious technological differences, remember that most people often end up using Zoom’s desktop client instead of the browser, so it’s often a more-controlled environment.
we just checked with one with the same antivirus but no issues… it can be hardware problem but I also suspect there might be something which we can fix, we just need to regenarate
we are not sure yet as we have some changes in UI. It could be some configs that specially affect that user’r environment or there was a issue in lib-jitsi-meet prev version.just may be… but what these log means actually?
2021-03-07 21:20:20.228 WARNING: [18355] CountingErrorHandler.packetHandlingFailed#62: Failed to handle packet: java.lang.RuntimeException at org.jitsi.videobridge.transport.ice.IceTransport.send(IceTransport.kt:226) at org.jitsi.videobridge.Endpoint.doSendSrtp(Endpoint.java:427) at org.jitsi.nlj.util.PacketInfoQueue$sam$org_jitsi_utils_queue_PacketQueue_PacketHandler$0.handlePacket(PacketInfoQueue.kt) at org.jitsi.utils.queue.PacketQueue$HandlerAdapter.handleItem(PacketQueue.java:575) at org.jitsi.utils.queue.AsyncQueueHandler$1.run(AsyncQueueHandler.java:141) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 2021-03-07 21:20:20.228 SEVERE: [18355] [confId=f2d99bed24eec02e epId=b1f22121 local_ufrag=ko9i1f084ejhb gid=84306 stats_id=Rossie-QXq conf_name=user@conference.dummyCon.com] IceTransport.send#225: Error sending packet java.io.IOException: No active socket. at org.ice4j.socket.MergingDatagramSocket.send(MergingDatagramSocket.java:202) at org.ice4j.socket.DelegatingDatagramSocket.send(DelegatingDatagramSocket.java:776) at org.jitsi.videobridge.transport.ice.IceTransport.send(IceTransport.kt:222) at org.jitsi.videobridge.Endpoint.doSendSrtp(Endpoint.java:427) at org.jitsi.nlj.util.PacketInfoQueue$sam$org_jitsi_utils_queue_PacketQueue_PacketHandler$0.handlePacket(PacketInfoQueue.kt) at org.jitsi.utils.queue.PacketQueue$HandlerAdapter.handleItem(PacketQueue.java:575) at org.jitsi.utils.queue.AsyncQueueHandler$1.run(AsyncQueueHandler.java:141) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
This just proves that audio is not being received (usually when the user has left the conference). So that person was probably disconnected. Do you have prosody smacks deployed? Not sure if that could account for video still showing, even though the user had been disconnected. Just a thought…
does this mean audio packet specifically? or audio/video
and as there were videos, can it be like, when that user gets connected again after short time disconnection, video stream got restored properly but audio couldn’t?
Both I and another friend have separately experienced this, each of us communicating with other parties, in the last couple of weeks or so on meet.jit.si. The problem has not recurred for me recently, but my friend who uses Jitsi regularly each week has begun to report the same problem.
Symptoms are (iirc) that audio drops out without warning in one direction (either one, but not at the same time); there may be some corresponding bandwidth indicator change. Logging out and logging back in seems to fix the problem. It may be associated with setting up a new, previously unnamed room, my friend reports (although this may just be a time dependent coincidence).
I will watch for it and gather more information at the next opportunity
Thanx for sharing… plz let me know if there is any other thing we (our client) have in common so that we can inspect the root cause. this is the most sad part that we can’t regenarate the issue willfully and find the cause, it happens randomly
well, it’s not all a matter of bandwidth. You can have good bandwidth, say 20mbits/s and still get problems. When an ISP announce 20Mbits/s, it’s a bandwidth tailored for the web, that is, an average bandwidth, not real time. If in one minute you can transfer 150Mbytes of data you have 20Mbits/s. However if this done with constant 20Mbits/s for every second in the minute, or with lots of spikes at 24Mbits/s and lots of blanks with 0Mbits/s for whatever raison, it’s the same for the ISP and on a web browsing experience you hardly notice it.
However for sound it’s not the same because people are extremely perceptive of small changes in the sound quality, if the software compensates by adding same sample of sound or chopping it’s very hard for users.
With video it’s much less troubling, if the image freeze for 1/10 s you hardly notice it. With sound you don’t understand well what the other is saying.
That’s why WebRTC has a parameter for enhancing sound buffering, sending multiple copies of the same data to ensure better redundancy in case of not available packets. This is configurable in Jitsi with
// Enables support for opus-red (redundancy for Opus).
enableOpusRed: true,
it’s defaulted at false because at the moment enabling it can lead to significantly lower bandwidth ;-), so reducing video quality in edge cases. However when sound quality is very important it can be useful (and as it’s a config.js parameter it can be used on a per-user basis).
** edit: as Jitsi–meet is a SFU, I’m not sure that enabling it on a per-user basis will bring much.
Note that it’s a somewhat recent parameter, it has been enabled about mid-2020 so you may not have it in your config.js if install predates it.
Also as usual with Jitsi-meet, you can be sure that Chrome-ish browsers will support it, for the rest your mileage may vary.
Thanx a lot for replying. I wasn’t sure about opusRed parameter that what it can do. Actually I think there are more people like me who don’t understand many important parameter in config.js which have significant effect in conference and the commented documentation is not enough there. If some expert guy take the responsibility in detailing it would be really greatful for all of us.
apart from that, then how much more bandwidth opusRed can consume and why dont we enable it by default. I dont even see this config (not even maxOpusBitrate) in current jitsi meet official deployment but my deployment has this. is this juts like sending extra packets/ redundant audio packets so if some packets is lost it won’t effect much to the audio quality?
you can read more background info here. In few words it’s a tradeoff if you use 1 Mbits/s for video it may not be a problem to use 90kb for audio instead of 30kb. For most meeting usage where good speech understanding is a must it’s not a question, the real problem however is client support, it’s certainly why it’s not enabled on meet.jit.si. If all your clients use Chrom-ish browsers and you can enable it for all, it may be an interesting idea.
