Davidr99 this says that the video stream connection timed out before opening
we dont stream video directly but use WebRTC, which depending on network setup, goes directly or trough intermediary server
in this case, what you observe is that the initial connection opening phase is taking too long ( collecting possible connection options ) and it times out
I have looked at my firewall and I do not see any blocks from the robot's IP. Any ports/IP's I could use to verify?
https://docs-beta.luxonis.com/deploy/robothub/network-firewall
I did find that link but again nothing is blocked from that.
Thanks.
So to give a little more information I use OpnSense router. I just tested this on a different router to see if it would work and it dose. So I am guessing something is blocking a UDP packet, but I am just not seeing anything being blocked.
Davidr99 we had one customer who uses similar FW/router and they needed to explicitly allow
TCP/UDP 3478 for these two IPs
5.161.83.56, 128.140.86.248
I did make that change and still having no luck.
So I have tried many things I even changed my router from OpnSense to pfSense to see if that helped, it did not. So I set up my old Asus Router, at another location they had an Asus router and it worked, but even with that change no luck. If anyone has any other suggestions that would be great. I did some packet captures and found that it looks like the packets are all going though, I could not see any rejected packets and the STUN looked to be working correctly.
I will say that at times if I wait long enough on the page (10 mins) it will start working.
Thanks.
Davidr99 Appreciate your effort to understand and resolve the issue. The thing is that the blocking can be happening upstream (ISP).
I did some packet captures and found that it looks like the packets are all going though, I could not see any rejected packets and the STUN looked to be working correctly.
Can you share with us those? Where are you capturing these packets? On RAE or on the router?
Based on what you judge STUN is working correctly?
As for why it works if you wait long enough -> that comes down to our less-than-fortunate implementation (which we aim to change, but not easy to do). Where we wait until all possible connection options are collected. This is not needed for the local network and rather than presenting timeout (as we do now) we could just use whatever options we were able to collect in the time.
Thus waiting long enough means that the collection process eventually finishes and you get your candidates transferred over to the frontend.
So I kind of walked away from this for a little bit and came back still having the same issues. I did find when it worked it is using UDP broadcasts. I do not see any blocks on the router, but I can say that using an off the self router dose work, so I was wondering if anyone has figured out a fix for this?
Here is a packet capture from my router:
So after a long battle I found the issue. It was looking up the us-east.turn.robothub.cloud and eu-central.turn.robothub.cloud to their IPv6 addresses, and trying to use IPv6. My ISP dose not use IPv6 so this causes it to timeout.
