Thanks for the replays. It is really surprising that some companies are blocking Twilio servers. I will try to update the tread with our findings as well, but as I said we can’t really retest on a problematic network. The thing is, that these issues happens on demo session (with prospect clients) and if the session not goes well, there is rarely another session with the same compnay. Also such demo sessions are not so often, so I do not expect to have any update soon. Basically we will try to collect more stats and identify what is blocked (UDP, TURN servers, ports). And only after we have more clear understanding on the problems we will try to implement some additional TURN servers.
I have couple of follow up questions though:
- Do you have any guidlines how to identify what is blocked (UDP, TURN servers, ports)? At this point we will try using webrtc stats, but for now it doesn’t seem so straightforward.
- If the UDP communication is blocked on the client network and the mediasoup transport is created with
enableUdp
,enableTcp
,preferUdp
all set to true - does this mean the streams will go through the mediasoup server and we won’t use TURN? - Also if in the same room (router) we have part of the peers using UDP and other using TCP (in mediasoup only, no TURN invoved) should we expect some issues (for example peers using TCP doesn’t see peers using UDP or vice versa)? Currently we see some strange warnings and errors in the mediasoup server logs (similar to ERROR:Worker worker process died unexpectedly). So if you can clear it up a bit what exactly
enableUdp
,enableTcp
,preferUdp
are meant to do it might help.
Thanks.