Log warning when using default ICE servers

[dulnan]

I‘ve seen quite a few issues here and people asking online why their connection doesn‘t seem to go past signaling and fails. Oftentimes under specific circumstances, like only with one browser or one network.

I had the same issue over the weekend with the combination Firefox <-> iOS Safari, both in a local network and via internet in various combinations. I was debugging for hours until I found the solution: You have to use your own ICE servers.
In hindsight this seems so obvious, since the default values for iceServers are servers that aren‘t really public. What makes it worse is that it does seem to work sometimes. In the case of the server hosted by Google it was only working when at least one of the devices was Chrome.

Signing up at Twilio and generating a few URLs with credentials for their STUN/TURN servers took me less than 10 minutes and suddenly I was able to connect any device in any configuration in any network.

I just thought I‘d put this here for others experiencing the same issue. And I was wondering, maybe it would make sense to highlight this fact a bit more in the readme?
It was not directly obvious to me, only after I read a bit more about WebRTC in general. It‘s a classic case of RTFM, but it seems the "M" here is a bit scattered around the internet :)

[t-mullen]

It might be worth it to draft a troubleshooting guide with some of this information. The only issue is that there is so many of these small WebRTC details, such a guide might end up being an enormous pre-flight checklist that is only useful to a very dedicated debugger. There's still value in that though.

Another idea is to make a "development mode" for simple-peer that will provide warnings when you are doing things that are potentially unsafe. eg)
You are using the default STUN servers. This may cause connection issues.
You have added a new track to a peer that had no tracks, did you renegotiate constraints?
replaceTrack has limited browser compatibility. Consider using removeTrack with addTrack.

These warnings could be disabled with an option. What do you think?

[dulnan]

Oh yes, I absolutely agree that simple-peer shouldn‘t become an encyclopedia about WebRTC and all its "hidden features" :)

I really like your idea of a development/debug mode. In my specific scenario this would have been quite useful and I can imagine it would prove to be useful in many other cases too.

[omar94f]

Has this been done? Because I think Im currently facing an issue because Im using the default TURN server. Sometimes the connection just doesnt work

I think the Readme is very sparse right now it can use these details.