Opened a bug report here: https://bugzilla.mozilla.org/show_bug.cgi?id=986348
No pcap needed as the about:webrtc is quite verbose anyways (thanks for the hint, didn't know about this little gem)! Andreas On Friday, March 21, 2014 8:45:54 AM UTC+1, Andreas Granig wrote: > 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
