On Fri, Mar 21, 2014 at 12:45 AM, Andreas Granig <[email protected]> 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. > OK, let's stop here. If you're not getting ICE candidates from the other side, then it's actually fairly unlikely things are going to work. So, let's try to figure out why that's happening first. Looking at the SDP, I just see host candidates from the other side, though they may (or may not) be NATed. Are there other candidates I'm not seeing? Incidentally, what is the other side in this trace? Is it Chrome but with the SDP coalesced? I also don't understand what you mean by "the server's ICE candidates". I thought you were calling a phone 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. > If you are the controlled side, you shouldn't be sending USE-CANDIDATE. That's the other side's job. That's the difference between controlled and controlling. -Ekr > 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 > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
