search

peers / peerjs

Simple peer-to-peer with WebRTC.
https://peerjs.com
MIT License
12.48k stars 1.43k forks source link

?transport=udp on TURN server - unreliable video connections #174

Closed redannick closed 10 years ago

redannick commented 10 years ago

This may not be a peerjs issue, but it may help others who are experiencing similar problems.

I'm using peerjs with latest chrome (33) and rfc5766-turn-server for STUN/TURN and I was getting intermittent issues with peers connecting ok for data, but having intermittent issues with video links. According to all the events and callbacks there was no issue, a connection is made, however all I see is a black rectangle instead of the feed.

While trying to work around connection issues for strict firewalls I noticed that when using { url: 'turn:user@xxx.xxx.xxx.xxx:443?transport=tcp', credential: 'password' } only - so no udp option, I never saw this happen.

Any suggestions as to what is really going on with the issue? In the meantime this works around the problem just fine.

michelle commented 10 years ago

Hm, I've actually encountered this myself. What do you mean by "no UDP option"?

redannick commented 10 years ago

If specifying a turn server simply as turn:user@xxx.xxx.xxx.xxx:443 then UDP is preferred, and TCP is used where UDP fails. By only supplying tcp as an option: turn:user@xxx.xxx.xxx.xxx:443?transport=tcp UDP is never tried.

At least that's how I understand it, and my assumption is that the unreliability of UDP is somehow failing to pass some initial video data so that the decoding fails. Of course I may well be wrong ;)

Related: It seems that even if you pass your own STUN server, peerjs will still try to connect via the google STUN server first - is this intended? I expected my STUN server to override the google one.

michelle commented 10 years ago

Ah, that's a really interesting observation.

re: Related: That shouldn't happen--we default to our Google STUN configs, but if you pass one in it should override--https://github.com/peers/peerjs/blob/master/dist/peer.js#L1393

redannick commented 10 years ago

Yeah, I'm glad I noticed as this flaky behaviour was really killing my app, clients were very nervous. I'm happy that it's now not happening, but It'd be great to nail down exactly what (or where) the problem is.

Re: Related: I'm pretty sure that with no mention of google STUN in my code, [chrome://webrtc-internals/] was showing connections to the google STUN server. Maybe it's chrome doing this then?

michelle commented 10 years ago

Oh, it could be because of our compatibility checks. We check if certain features are supported when you load peer.js, and we use our defaultConfigs for those checks. If this is an issue, we can try to figure out a way to do the checks without hitting a STUN server.

Michelle

On Tue, Apr 22, 2014 at 11:19 PM, redannick notifications@github.comwrote:

Yeah, I'm glad I noticed as this flaky behaviour was really killing my app, clients were very nervous. I'm happy that it's now not happening, but It'd be great to nail down exactly what (or where) the problem is.

Re: Related: I'm pretty sure that with no mention of google STUN in my code, [chrome://webrtc-internals/] was showing connections to the google STUN server. Maybe it's chrome doing this then?

— Reply to this email directly or view it on GitHubhttps://github.com/peers/peerjs/issues/174#issuecomment-41128359 .

redannick commented 10 years ago

Ah maybe that's it then. Connections to my servers are also present.

It's not an issue, I was just confused to see it there. Thanks for your help :)

michelle commented 10 years ago

ACTION: going to add this to an FAQ section on the site.

enrique-ramirez commented 9 years ago

Sorry to bring an old issue back from the dead, but I'm encountering this issue and wanted to know if I'm getting it right:

I have a STUN and a TURN server up and running, and am getting pretty good connections all around, but some people are unable to join. Rather, I get the behaviour @redannick has been experiencing: a black square where the video should be.

So everything is working fine: websockets, the offers, the answers. All but the streaming of audio/video.

After some research, it seems that the people who have these issues are under a firewall with UDP blocked.

Solution, then, is to enable tunneling through TCP on my TURN server.

So far, so good. But I'm wondering if there's a way of leaving TCP as a last, last resource and use UDP where it works? And more importantly, is there an advantage on doing so (or rather, a disadvantage on using TCP every time my TURN is used)?

redannick commented 9 years ago

Trouble is, you're not exactly informed that UDP isn't working, at least in my experience. Everything appeared to work fine apart from the lack of video.