986348 - No USE-CANDIDATE in STUN requests after checking peer candidates for WebRTC

Status: RESOLVED DUPLICATE of bug 942188

(Core :: WebRTC, defect)

Description

[agranig]

Attachment: the about:webrtc output plus the received and sent SDP

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36

Steps to reproduce:

I'm using tryit.jssip.net with a SIP-over-Websocket server on the other side. What's worth noting is that it really doesn't matter what the caller is using (Chrome, another FF, or a plain SIP client), because the receiving FF is only seeing the server's ICE candidates in the SDP, no matter what's on the other side. 

So what's basically happening is this (please correct me if I'm misunderstanding something): 

1. FF receives an inbound call, and jssip is asking for permissions to access media. 
2. FF starts sending out "normal" STUN requests to the STUN server configured in the javascript app. 
3. FF now sends STUN binding requests with the "ICE-CONTROLLED" attribute to the candidates in the SDP. 
4. FF receives STUN binding responses from these candidates. That way, FF now knows it can happily reach some of the candidates. 


Actual results:

5. What I would expect from FF now (and this is also what Chrome is doing) is a STUN request with a set USE-CANDIDATE attribute being sent to one of the candidates, to tell the other side which address to use. However, I don't see any such request. 
6. So as a consequence, the other side starts sending UDP packets for DTLS negotiation to the address defined by FF in the c=/m= lines of the answer, but they never reach FF through the NAT. 

The reason why outbound calls from FF work is that compared to the inbound scenario, FF starts sending UDP packets to the other side, which learns from the source address of these packets where to send responses to. In the inbound scenario, FF doesn't send any packets but seems to wait for the other side to start sending UDP (which it does, but to the wrong address due to the missing USE-CANDIDATE, and therefore to the wrong address). 


Expected results:

I would expect one STUN request with a USE-CANDIDATE attribute set for each of the media streams, to let the other side know where to send media to.

I've attached the about:webrtc output, the received and the sent SDP.

Comment 1

[Eric Rescorla (:ekr)]

I wonder if this is:
https://bugzilla.mozilla.org/show_bug.cgi?id=942188

Comment 2

[agranig]

In my opinion exactly what https://bugzilla.mozilla.org/show_bug.cgi?id=942188 is reporting, right.