search

jitsi / ice4j

A Java implementation of the ICE protocol
Apache License 2.0
436 stars 232 forks source link

NullPointerException in MergingDatagraSocket #222

Open astillich-igniti opened 3 years ago

astillich-igniti commented 3 years ago

Hi,

we are using Jitisi Meet Docker 5142-4. We have setup up an nginx proxy before the bridge and other components. Everything works with P2P communication. But if clients attempt to connect via the bridge, I'm running in the issue mentioned in #205:

java.lang.NullPointerException
at org.ice4j.socket.MergingDatagramSocket.initializeActive(MergingDatagramSocket.java:577)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.ComponentSocket.propertyChange(ComponentSocket.java:176)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.IceMediaStream.firePairPropertyChange(IceMediaStream.java:877)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.CandidatePair.nominate(CandidatePair.java:629)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.Agent.nominate(Agent.java:1788)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.DefaultNominator.strategyNominateFirstValid(DefaultNominator.java:144)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.DefaultNominator.propertyChange(DefaultNominator.java:120)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.IceMediaStream.firePairPropertyChange(IceMediaStream.java:877)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.CandidatePair.validate(CandidatePair.java:667)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.IceMediaStream.addToValidList(IceMediaStream.java:675)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.Agent.validatePair(Agent.java:1752)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.ConnectivityCheckClient.processSuccessResponse(ConnectivityCheckClient.java:641)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.ice.ConnectivityCheckClient.processResponse(ConnectivityCheckClient.java:405)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.stack.StunClientTransaction.handleResponse(StunClientTransaction.java:314)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.stack.StunStack.handleMessageEvent(StunStack.java:1040)
eva_jvb.1.vahxzrver0eg@node3    |   at org.ice4j.stack.MessageProcessingTask.run(MessageProcessingTask.java:196)
eva_jvb.1.vahxzrver0eg@node3    |   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
eva_jvb.1.vahxzrver0eg@node3    |   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
eva_jvb.1.vahxzrver0eg@node3    |   at java.lang.Thread.run(Thread.java:748)

The discussion mentions that setting org.ice4j.ice.harvest.BLOCKED_INTERFACES=bridge fixes the issue, but it does not help in our case.

We have set DOCKER_HOST_ADDRESS, and I tried enabling disabling STUN by commenting out the JVB_STUN_SERVERS line in the environment file. Nothing helped, I also tried setting org.ice4j.ice.harvest.ALLOWED_INTERFACES= to the interface I'm using which resulted in another exception:

eva_jvb.1.taenq2i2r7be@node3    | Jan 26, 2021 6:11:41 PM org.jitsi.utils.logging2.LoggerImpl log
eva_jvb.1.taenq2i2r7be@node3    | SEVERE: Health check failed in PT0S:
eva_jvb.1.taenq2i2r7be@node3    | java.lang.Exception: Failed to bind single-port
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.videobridge.health.JvbHealthChecker.check(JvbHealthChecker.kt:43)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.videobridge.health.JvbHealthChecker.access$check(JvbHealthChecker.kt:25)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.videobridge.health.JvbHealthChecker$healthChecker$1.invoke(JvbHealthChecker.kt:32)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.videobridge.health.JvbHealthChecker$healthChecker$1.invoke(JvbHealthChecker.kt:25)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.health.HealthChecker.run(HealthChecker.kt:144)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
eva_jvb.1.taenq2i2r7be@node3    |   at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExec

Are there any outstanding fixes which have not made it into the 5142-4 release?

astillich-igniti commented 3 years ago

We have solved the issue. It was indeed a configuration problem on our side. In our opinion, ice4j should produce a meaningful error message instead of just running into a NPE.

bgrozev commented 3 years ago

We have solved the issue. It was indeed a configuration problem on our side. In our opinion, ice4j should produce a meaningful error message instead of just running into a NPE.

I agree. I can't promise to work on it anytime soon as there are other priorities, but for the record can you describe the configuration that triggered the exception?

alucryd commented 3 years ago

@astillich-igniti I'd be very interested to learn what you changed as well because I can't for the life of me get it to work on my server.