This message was deleted.

Locally everything works fine as well.

My guess is how your server is configured.. Go SDK probably isn't able to connect due to configuration

Thanks for your reply @dry-elephant-14928! Interesting 🤔 I wonder why lower resolution video tracks and audio are received just fine in that case. Is there something that can throttle certain clients? I tried disabling congestion control without results.

Ah, maybe I've misunderstood what you meant. If it does connect and then stops receiving.. something seems wrong. I don't recall ever seeing that happen in the past. How does your Go receiver code work?

Indeed, interesting case. The same code with the SDK works perfectly fine when running on my local machine so I guess it has to do something with connectivity between server and the process running the SDK. I just don't understand enough about webrtc to be able to debug this 🫠 Here is the code that records tracks. Sorry for a complex example. I'm working on isolating a simpler one. It hangs here on

packet, _, err := track.ReadRTP()

after receiving a handful of RTPs and just sends out PLIs until the track ends.

hmm, interesting. Do you have any logs indicating connection disruption? You might need to set up the SDK logger in order to see them. typically if the read has failed, it'll timeout and return an error. The other thing to check is if the connection is made via TCP or UDP. (the server logs should print

selected ice candidate

). It's possible for it to hang if it was TCP (due to some nuances of how the stack is implemented).

Good leads! Thank you, I will try those steps 🙇

it shouldn't be. some of our cloud regions run on DigitalOcean

The tracks are published from the browser. Here is the code for reference. I'll come back after testing your suggestions in a few days :)