Hello, 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. 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). I will open a bug report with a pcap of the STUN traffic attached, but maybe someone here knows whether this is intended behavior or whether it might be a real issue. Andreas On Thursday, March 20, 2014 8:09:28 PM UTC+1, Randell Jesup wrote: > On 3/20/2014 2:18 PM, Eric Rescorla wrote: > > > On Thu, Mar 20, 2014 at 10:40 AM, <[email protected]> wrote: > > > > > >> Calling from FF 32 (nightly) to Chrome works fine, however calling from > > >> Chrome to FF fails. > > >> > > >> What I can see is FF sending a couple of STUN bind requests to the server, > > >> but it never puts the USE-CANDIDATE into any of them. Any idea why this > > >> could be the case? > > > To the server? Or to Chrome? > > > > > > In any case, please file a bug with supply the about:webrtc logs > > > from Firefox and the Chrome logs (webrtc:internal, perhaps?) > > > > Also, what webpage/service are you using to set up the call? > > > > -- > > Randell Jesup, Mozilla _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
