User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141027150301 Steps to reproduce: Use FF to navigate to the FreeSWITCH's mod_verto test page and try to call somewhere. You can use the following link for a test: https://webrtc.freeswitch.org/verto/index.html#page-main (there's a list of numbers to try to dial at the bottom of the page). Actual results: Call is established, but nothing can be heard in the headphones. Expected results: Call is established, and I can hear something from the remote party. This used to be working fine in FF33, but is now broken in the latest beta. It also works fine in Chrome if that matters.

Bugzilla picks up the details of the browser I use to submit the bug. That's different from the buggy one. The buggy browser details are: User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141103144234

2014-08-28-03-02-05-mozilla-central/firefox-34.0a1.en-US.win32.zip: Works fine. 2014-08-29-03-02-04-mozilla-central/firefox-34.0a1.en-US.win32.zip: Works fine during the call, but as soon as call end it starts generating noise which can only be stopped by exiting from FF (closing the tab or window is not enough). 2014-08-30-03-02-04-mozilla-central/firefox-34.0a1.en-US.win32.zip: Starting from this version it does not work anymore.

I got a similar regression range like you: good=2014-08-27 bad=2014-08-28 I just called 5000 (Demo IVR) to hear the female voice (it's simple to test). Is there a better number to call (without needing a real human on the other side) with your testcase to reproduce the issue with 08-28 and 08-29 builds?

Ok, sorry for the previous message, I tried mozregression a 2nd time and, indeed, build 08-28 is good and 08-29 starts to be buggy with noise after ending the call. Reg range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3be45b58fc47&tochange=d697d649c765

noise after the end of a call is a known/fixed bug 1061702 due to bug 848954 - a major refactor of MediaStreamGraph to be driven off audio callbacks instead of an internal timer.

Try a debug build (like http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-11-13-mozilla-central-debug/) and set NSPR_LOG_MODULES=mediastreamgraph:5,mediamanager:5,signaling:5 and NSPR_LOG_FILE=some temp file and do your test (generates a lot of logs, so don't test for long - 10-30 seconds showing the problem is good). compress and upload the logfile. Thanks!

Archive with debug log files attached. PS. For regular nightly builds you produce both installers and zip archives. For debug builds, however, only installers are produced. Isn't a bit... illogical? I'd rather expect the opposite.

Tracking 34. Note that that doesn't necessarily mean that we're going to take a fix in 34. It means that I want to follow up to ensure we understand this issue as much as possible before releasing.

Please compare about:webrtc in 33 (where it works) and newer versions (nightly, which has a nicer UI for it. In nightly, I see no nominated or selection candidates. In the SDP, I see a single candidate for Remote. for ICE stats I see one failed, a second frozen., and the rest don't even have an ice state. We switched in 34 to all-trickle-ICE per the WG decisions and did a bunch of signaling rewrites that changed timings. Please make sure all ICE candidates are getting processed, forwarded and installed! FYI, my test was load https://webrtc.freeswitch.org/verto/index.html#page-main, call 5000. A few seconds later on 33 I hear a recorded message, and hitting 2 will connect me to a loopback. On Nightly I never hear anything, and it appears to never connect the mediastreams. CCing byron lmandel: I strongly suspect this is not a bug in our code now

(In reply to Randell Jesup [:jesup] from comment #9) > lmandel: I strongly suspect this is not a bug in our code now Our final Beta build in the 34 cycle goes to build on Thu, Nov 20. Is there any way to confirm that this is not a bug in our code?

I just tested this with FF 33, 34 and 35 and traced with wireshark. FF 34 and 35 send out STUN binding requests to the server at 209.105.235.10, but they never get any STUN response. FF 33 also sends out STUN bindings request, but they get answered from the server. So "actual result" in the original report I think it wrong: with FF >= 34 the call never gets established, because the server never answers the STUN requests from FF properly. As we have not changed anything drastically in the STUN protocol itself I'm suspecting the Randel is right and this is probably a trickle ICE interop issue on the server side or with the JS code. Andriy as you say it works fine for Chrome do you know if the trickle ICE code in your JS code only gets activated if it detects Chrome as the browser? If your trickle ICE code should work on Firefox and Chrome my next best guess is: with FF you need to watch when you add ICE candidates. FF allows you only to add ICE candidates after setRemoteDescription has been called successfully. I believe in Chrome you can call addIceCandidate any time.

lmandel: I would state this is not blocking for 34 per my and nils' evaluation.

Guys, thank you all for looking into the issue. Several points. First, that JS code is not mine, it's from the FreeSWITCH project. I'm not part of it, just following the development progress for my own reasons. Second, I don't think the issue is anyhow related to STUN per se. It works fine in FF33 with STUN checkbox either checked or unchecked (and similarly does not work in FF34 no matter if STUN checkbox is checked or not). And yes, I'm always behind NAT while testing. It works fine in the latest Chrome, and even supports stereo (just checked). I have no idea what "trickle ICE" is, but I'll try to google for it. For now, I just tried to search through the JS code. There's lots of places where "ICE" is mentioned, but "trickle" isn't mentioned anywhere. Though, there seems to be some browser-specific code in there, indeed.

I'm untracking this issue as it's unclear that this is a Firefox issue. Should this be resolved as invalid based on comment 11?

This appears to have been fixed by FreeSWITCH devs some time ago. Looks like this is not a FF bug, indeed.