zhuguoqiang / rfc5766-turn-server

Automatically exported from code.google.com/p/rfc5766-turn-server
0 stars 0 forks source link

UDP Blocked by FW #6

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Use Google Chrome to establish WebRTC session
2. Use the "?transport=tcp" flag while configuring the TURN Server in the 
client JS

What is the expected output? What do you see instead?
1. Communication from the client (google chrome [v. 25.0.1364.172 m] should be 
in TCP and not in UDP
2. I see that the communication is still in UDP.
The main issue is that if OUTBOUND UDP is blocked, there is no way to establish 
WebRTC communication between peers (no STUN RESOLUTION). We need to have a TCP 
fallback.

What version of the product are you using? On what operating system?
win 7, Google chrome 25. turn server 1.6.0.1

Please provide any additional information below.

Original issue reported on code.google.com by tadj...@comeet.co on 19 Mar 2013 at 4:31

GoogleCodeExporter commented 8 years ago
We have no control over the protocol that Chrome is using. If Chrome continues 
sending UDP traffic, then this is Chrome's problem. Please attach or send to me 
the wireshark pcap file for further investigation.

Original comment by mom040...@gmail.com on 19 Mar 2013 at 4:36

GoogleCodeExporter commented 8 years ago
This is a Chrome 25 bug, hopefully fixed in subsequent builds.

Original comment by mom040...@gmail.com on 19 Mar 2013 at 5:16

GoogleCodeExporter commented 8 years ago
Well I am also facing the same issue. I have used the "?transport=tcp" flag in 
the client.js file. Still I am seeing the communication in UDP. 

I have used Chrome during my debug. Is it a problem with Chrome? 

Anything else I need to force the communication to be in TCP instead of UDP?

Original comment by tapasmis...@gmail.com on 1 Dec 2014 at 12:03

GoogleCodeExporter commented 8 years ago
I d suggest asking that same question in webrtc forum.

Original comment by mom040...@gmail.com on 1 Dec 2014 at 2:05