1257052 - UDP does not work well in firefox 45 if no STUN in WebRTC

Status: RESOLVED DUPLICATE of bug 1259842

(Core :: WebRTC: Networking, defect)

Description

[Rain]

Attachment: tcp-no-stun.pcapng

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

Steps to reproduce:

This is a regression issue in firefox 45.

Case 1 - 

1. use firefox 45 to make a webrtc call
2. specify below configuration for RTCPeerConnection, I only specify the TURN server to support TCP

var pcConfig = { iceServers: [
  {"urls":["turn:mpj2mcs501-ms-vip.eng.webex.com:80?transport=tcp"], "username":"ciscoThinClient", "credential":"1234abcd"}
]}

3. make webrtc call

Expected result: firefox 45 should try UDP first

Actual result: firefox does not try UDP, it does not send any STUN request, it just make TCP connection, refer tcp-no-stun.pcapng

Case 2 - 

if I specify below configuration:

var pcConfig = { iceServers: [
  {"urls":["stun:mpj2mcs501-ms-vip.eng.webex.com:9000?transport=udp"]},
  {"urls":["turn:mpj2mcs501-ms-vip.eng.webex.com:80?transport=tcp"],"username":"ciscoThinClient","credential":"1234abcd"}
]}

Expected result: firefox should send correct STUN bind request

Actual result: firefox send the STUN bind request, but no username in the request, so UDP connection cannot be made successfully, refer  stun-no-username.pcapng

Comment 1

[Rain]

Attachment: stun-no-username.pcapng

Comment 2

[Nils Ohlmeier [:drno]]

Case 1:

If you specify transport=tcp then the STUN client can only use that protocol. And in the provided pcap file I see clearly that STUN requests and responses getting exchanged over the TCP connections to port 80. E.g. packet 258 in tcp-no-stun.pcapng contains an ALLOCATE request, responded to by the server with a unauthorized in packet 354, and then the client retries the ALLOCATE request with the ciscoThinClient credential in packet 356, which the server then replies to in packet 360. Followed by a create permission request in packet 362 and so on.
I see several more TCP connections being made and these also appear to have ALLOCATE requests getting exchanged. Firefox seems to not use the other allocations for whatever reason.

So I don't see where the problem is here. Are you saying Firefox behaved differently in version 44?

Case 2:
You only provided credentials for the TURN TCP iceServer. Without credentials for the TURN UDP Firefox will not be able to authenticate itself towards the TURN server. Because there are no credentials for the UDP TURN URL Firefox uses the TURN server only as a STUN server to figure out its server reflexive address. Which apparently your implementation is not able or willing to do as it responds with 400 replies. Every TURN server is required to also act as a STUN server without credentials (as you don't need credentials to use a STUN server).

So in my opinion case 1 and 2 both work as designed.

Comment 3

[duanpei]

For case 1, we specified TURN server only in peerConnection through iceServer configuration. FireFox behaved correctly on TURN. In the SDP Offer/Answer, we also received UDP port for STUN. Here is the received message for ICE candidates,

a=setup:passive
a=rtcp-mux
a=ice-lite
a=candidate:1 1 udp 2130706431 172.24.93.220 9000 typ host
a=candidate:2 1 tcp 2120220671 172.24.93.220 80 typ host tcptype passive

In the early version before 45, such as 44/43/42, Firefox will first pair with UDP port 9000 to talk to the remote endpoint to setup an ICE session. And at the same time, it will also use the TURN parameters provided in iceServer to establish the TURN session. However, in 45 and later version, what we observed is the TURN session only. We do not see any STUN messages carried over UDP.

For case 2, we add STUN server to peerConnection. This time, we saw both UDP STUN messages and TURN messages. The TURN session is established correctly. We also saw the UDP STUN binding request messages over port 9000. However, these messages contain no "USERNAME" attribute which is required according to the STUN spec. According to the spec, the remote site simply responds with 400 bad request. And the UDP STUN session is never established.

BTW, we also checked WebRTC log through about:webrtc. we saw no errors regarding the connections for what I can interpret.

Comment 4

[Byron Campen [:bwc]]

(In reply to duanpei from comment #3)
> For case 1, we specified TURN server only in peerConnection through
> iceServer configuration. FireFox behaved correctly on TURN. In the SDP
> Offer/Answer, we also received UDP port for STUN. Here is the received
> message for ICE candidates,
> 
> a=setup:passive
> a=rtcp-mux
> a=ice-lite
> a=candidate:1 1 udp 2130706431 172.24.93.220 9000 typ host
> a=candidate:2 1 tcp 2120220671 172.24.93.220 80 typ host tcptype passive
> 

> var pcConfig = { iceServers: [
>   {"urls":["stun:mpj2mcs501-ms-vip.eng.webex.com:9000?transport=udp"]},
>   {"urls":["turn:mpj2mcs501-ms-vip.eng.webex.com:80?transport=tcp"],"username":"ciscoThinClient","credential":"1234abcd"}
> ]}


   Are the candidates and the iceServers pointing to the same things? You cannot run a STUN/TURN server and an ICE agent on the same port. The handling of binding requests is too different. This would definitely cause what you're seeing in case 2. As for case 1, I would need to see some logs. We could start with the logs on about:webrtc. Please use the "Save Page" button at the top, and attach the result here.

Comment 5

[duanpei]

For case 1, we have iceServer configured with TURN server only (no STUN server configured). In this case, we cannot see any STUN over UDP.

For case 2, it is to test if STUN server configured to iceServer will to make the STUN over UDP work. It does not. It is not what we will use but to test it. we will use the case 1 configuration.

Comment 6

[Rain]

Attachment: aboutWebrtc-case1.html

Comment 7

[Rain]

Attachment: aboutWebrtc-case2.html

Comment 8

[Byron Campen [:bwc]]

In aboutWebrtc-case1.html, which PeerConnection did you want me to look at? The first several seem to be sending UDP checks.

Comment 9

[Rain]

(In reply to Byron Campen [:bwc] from comment #8)
> In aboutWebrtc-case1.html, which PeerConnection did you want me to look at?
> The first several seem to be sending UDP checks.

Hi Byron,

In the attachment 8736533 [details], please check peer connection with peer ID 1459385773062001 and in the attachment 8736534 [details], please check logs for peer ID 1459385476064042.

Comment 10

[Byron Campen [:bwc]]

Ok, I know what is going on here. The expected UDP host/host candidate pair is not being created because both ends are on different private subnets.