New issue
Advanced search Search tips
Starred by 8 users

Issue metadata

Status: WontFix
Closed: Aug 2014
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Issue 2985: googTransportType always reported as UDP

Reported by, Feb 28 2014

Issue description

What steps will reproduce the problem?
1. block udp traffic
2. Open in one tab
3. Open in another tab
4. Open chrome://webrtc-internals and check the googTransportType

What is the expected result?
The transport type should be tcp since udp is blocked.

What do you see instead?
transport type is udp

What version of the product are you using? On what operating system?
33.0.1750.117 on OS X 10.9.2

Please provide any additional information below.
I'm blocking udp traffic with sudo ipfw add deny udp from any to any 1028-65535 out

Comment 1 by, Mar 3 2014

Project Member
Could you please attach the dump of webrtc-internals? And from wireshark capture, is tcp packets out?

Comment 2 by, May 12 2014

Just saw the same issue... 
search for Conn-audio-1-0-googTransportType in the attached log. Traffic is running on TURN/TCP port 80, do you want to look at a pcap as well?

Seems to be caused by
-- this looks like it takes the ice candidate's protocol field instead of the protocol used to connect to the TURN server. Not sure what the expected behaviour should be.
411 KB Download

Comment 3 by, May 12 2014

otoh, this may be just the intended behaviour of googTransportType. In which case there should still be a way to associate a candidate pair with the iceServer used to create it.

Comment 4 by, May 14 2014 answers this basically. Works as intended.

Comment 5 by, Jun 27 2014

I don't understand A) how this "works as intended" or B) what the point is in outputting a state that (as far as I can see) never changes.  No matter what I do to my network connection with ipfw, this always seems to output udp.

I need to answer this exact question: did we connect over TURN or something else.    For a while I thought I had a an answer in googLocalCandidateType, but that doesn't work if you have UDP TURN servers.  For example is it UDP or TCP TURN?  If it's the latter, then I want to show a message to my users to let them know their network is heavy-handed.

Comment 6 by, Jun 28 2014

#5: you will get that information from the serverUrl parameter in the stats once it's there. 

@braveyao: maybe cc hta and make this bug about adding that serverUrl (unless there is a different one for that already)

Comment 7 by, Jun 30 2014

Project Member
@hta, please help to comment on this!

Comment 8 by, Jun 30 2014

Project Member
@hta, please help to comment on this!

Comment 9 by, Jun 30 2014

The working not-quite-draft of the stats spec is here:

The "transport" (udp or tcp) refers to the transport between the sender's domain and the receiver's domain - when a TURN server is in use on the sender's side, this is the transport from the sender's TURN server to the receiver; if both parties are using TURN servers, it will be the transport used between the TURN servers.

Once we have implemented the addressSourceURL, this will be empty for host addresses, and be the TURN URL for TURN addresses.

At the moment, we have no way to expose this information.

Comment 10 by, Aug 4 2014

Project Member
Status: WontFix
Close this issue according to comment#9.

Comment 11 by, Sep 4 2014

incidentally, just saw this go to "tcp" for ice-tcp, so that works as expected even.

Comment 12 by, Sep 4 2014

Phillip, could you please point me to where you are seeing it?


Comment 13 by, Jul 17 2015

Project Member
 Issue 4851  has been merged into this issue.

Sign in to add a comment