Question for the original reporter - with the same client setup (i.e. "two Chrome Browsers in 2 private Networks with symmetric NAT"), are you able to establish a call using https://appr.tc/? I ask because that application also uses TURN (though not the "innovaphone TURN server"), and I haven't seen similar reports from appr.tc users.

I tested appr.tc in my network environment and it works, but it uses TURN over UDP. We are using TURN over TCP.

Could you try with our TURN:

turn.innovaphone.com
User: chromium
Password: innovaphone

The TURN server support UDP and TCP on the well-known ports. We experience the problem with TCP, but we have not tested UDP.

Could you give me access to another TURN server, which supports TCP, I could try with our applications

I believe AppRTC filters out TCP candidates over TURN as it yields bad performance.

https://github.com/webrtc/apprtc/blob/master/src/web_app/js/peerconnectionclient.js#L333

gd: Just FYI: since you in your comment #4 you provided this information publicly, many users can now use this account (but I guess you can just disable it if the traffic runs high).
I'm not clear if the credentials you provided means that turn server instance will provide both UDP and TCP turn or only TCP?

UDP is essential for low latency and TCP should only be a worst-case fallback, although WebRTC should support it. Your TURN server should ideally support both.

Can you provide us with login credentials to your "WebRTC application" as well so we can try it out? Feel free to e-mail the recipients CCed to this bug directly instead of posting here.

Yes, we use TCP as fallback, because most company firewalls block UDP traffic. I monitor our TURN an disable the account if traffic is high.
Our TURN server support TCP and UDP.
I will send you accounts for our application in seperate mail.

Honghai, can you look at this?

And can we get a native log? That would help a lot.

FYI about #5:  Even if TCP is used to the TURN server to the side doing the allocation, it can still appear as a non-TCP candidate as well.

to #9 Yes we only support UDP candidates. Only the TURN protocol to the TURN server uses TCP. So we can use TCP to tunnel the RTP to the TURN server and the TURN server does UDP to the far side.

FYI, if both sides are behind UDP-blocking firewalls and you only use UDP candidates, then only TURN-TURN candidate pairs can work, and they won't work if there's anything blocking traffic between the TURN servers (or if it's the same TURN server, preventing it from sending traffic to itself). 

A native log would help a lot.

I attached the debug logs from both sides of the communication, because they are different on one side a channel_bind is performed and on the other side not. Which side seems to be random.

Deleted: chrome_debug2.log 1.1 MB

chrome_debug2.log 1.1 MB View Download

Thank you for providing more feedback. Assigning to requester "tnakamura@chromium.org" for another review.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

I looked at the provided log. 
TURN allocate and permission requests are made successfully. 
Both sides established a writable connection but then soon disconnected after a few seconds because stun ping did not go through. 
It is likely that the TURN server have some issues with the lifetime of permissions or allocation requests. 
 
By the way, AppRTC used TCP TURN server as well. If it worked while your app did not work in environments where UDP traffic were blocked, it is likely that your app or your TURN server had something wrong. 

I didn't come to the same conclusion looking at the logs from comments #15/#16. Packets seem to be going through the entire time, but the DTLS packets sent by client 1 aren't received properly:

[6852:3256:0309/081532:ERROR:dtlstransportchannel.cc(483)] Jingle:Channel[audio|1|__]: Failed to handle DTLS packet.

As a result, client 1 times out and tears down the connection. Then client 2 times out as well.

A packet capture may be useful for figuring out why this is happening. It seems likely to be an issue with how the TURN server processes the ChannelData packets.

Archiving since no feedback was provided for more than 3 months. Re-open if new information is available.