930536 - Firefox 24 - Nightly only offering UDP ICECandidates for WebRTC

Status: RESOLVED DUPLICATE of bug 906968

(Firefox :: Untriaged, defect)

Description

[daniel.mewes]

Attachment: firefox ice candidates.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

Just start a webrtc videochat (e.g. with the apprtc demo) and take a look at the ice candidates offered by firefox.


Actual results:

Because firefox only offers ice candidates for udp, the peer-to-peer connection with webrtc will fail if one or both peers are behind a NAT. 


Expected results:

There should have been also ice candidates for tcp like in chrome so the peer-to-peer connection could be established also if udp ports are blocked or won't pass the NAT.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

TURN TCP is expected to land soon, see bug 906968

Comment 2

[Eric Rescorla (:ekr)]

Actually, there are two questions here:

1. TURN TCP, which as Jesup says is bug 906968
2. ICE-TCP, which we don't think adds a lot of value and don't intend to do in the near future because measured penetration rates of ICE-TCP are not good.

Comment 3

[daniel.mewes]

Relating to ICE-TCP:
I totally disagree that this feature doesn't add much value. In my opinion it's the totally opposite. How are users of WebRTC supposed to use webrtc if all udp-ports are blocked or a NAT is blocking the udp-requests? Chrome has ICE-TCP and therefore everything is working fine without the additional need of a TURN-server.

Comment 4

[Eric Rescorla (:ekr)]

(In reply to daniel.mewes from comment #3)
> Relating to ICE-TCP:
> I totally disagree that this feature doesn't add much value. In my opinion
> it's the totally opposite. How are users of WebRTC supposed to use webrtc if
> all udp-ports are blocked or a NAT is blocking the udp-requests?

They are supposed to use TURN, because many such environments *also*
don't succeed with the TCP simultaneous open technique.


> Chrome has
> ICE-TCP and therefore everything is working fine without the additional need
> of a TURN-server.

As I stated in c2, field measurements of ICE-TCP is that it has a very low
success rate 
(http://www.viagenie.ca/publications/draft-ietf-mmusic-ice-tcp-08.txt says
40%). The major case in which you are likely to get success is with
conference servers and the like which have public IP addresses, but
such devices can simply stand up TCP TURN servers that service their
front-end.

If you have measurements that show significantly better client-to-client
success rates than the ones indicated above, we will reconsider the
prioritization here.

Comment 5

[Adam Fineberg]

(In reply to Eric Rescorla (:ekr) from comment #4)
> (In reply to daniel.mewes from comment #3)
> > Relating to ICE-TCP:
> > I totally disagree that this feature doesn't add much value. In my opinion
> > it's the totally opposite. How are users of WebRTC supposed to use webrtc if
> > all udp-ports are blocked or a NAT is blocking the udp-requests?
> 
> They are supposed to use TURN, because many such environments *also*
> don't succeed with the TCP simultaneous open technique.

The place where there is significant value to ICE-TCP over using TURN-TCP is when connecting from behind a restrictive firewall to a terminating service such as an MCU.  It is more costly and wasteful to have to go through a turn server in that case just to speak to an MCU that is likely directly available.

Comment 6

[Eric Rescorla (:ekr)]

I'm not following the wasteful angle of this: just have the MCU act
as a TURN server itself. If done properly, this should have very
similar network characteristics to ICE-TCP, modulo the TURN framing,
which, with channels, is relatively small.

Comment 7

[tom]

ekr, I think Justin phrased the argument better on the pntaw mailing list than we have been doing: http://www.ietf.org/mail-archive/web/pntaw/current/msg00178.html

Comment 8

[Eric Rescorla (:ekr)]

Yes, I read that.

This strikes me as a fairly modest improvement.

Again, I'm not saying Mozilla won't do this, but it's not at the top of
our list for NAT traversal, so it won't be soon.

If someone were to submit a patch, that would obviously make the process
go faster.