You can try the file version as set via this builtin default file:

• chrome://global/content/gmp-sources/openh264.json

Thanks for the fast reply. I opened up the json, found the download URL in it for my platform (WINNT_x86_64-msvc) and downloaded the zip package from it. The json states to expect version 1.6. Then figured out the location for the unzipped files (gmpopenh264.dll and gmpopenh264.info) should be C:\Users\<my_name>\AppData\Roaming\Mozilla\Firefox\Profiles\yrhii4yv.default\gmp-gmpopenh264\1.6\, so I copied them there and removed the whole directory \1.7.1\, which contained the newest but Circuit incompatible plugin. Restarted FF but Circuit still doesn't work, same error as yesterday ("communication error"). In FF > Addon Manager > Plugins I see "OpenH264 Video Codec" is present but there's also a notice saying "OpenH264 Video Codec provided by Cisco Systems, Inc. will be installed shortly". This never happens although. about:config shows no more entries starting with "gmpopenh". Is there a way to install the plugin better than just copying the 2 files into AppData\.. or force the installation to really happen shortly?

As an aside, the internal file date on the 1.7.1 DLL is Dec. 9, 2017, so it's strange that you would just be getting it 11 months later unless you have been blocking it in some manner. It's also strange that the .json file has file paths to older version 1.6 zip files. Hmm...

Try updating the version number in the preference you'll see here:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.

(2) In the search box above the list, type or paste openh and pause while the list is filtered

(3) Double-click the media.gmp-gmpopenh264.version preference and edit the value to match the name of the folder you created

Hopefully then Firefox will be able to find it.

Did you modify this pref on the about:config page?

• media.gmp-gmpopenh264.version -= 1.6

You probably need to disable the GMP update URL to prevent Firefox from updating to 1.7.1

See also:

• https://github.com/cisco/openh264/releases

@cor-el: I didn't modify any settings in about:config but all settings concerning "gmpopenh264" disappeared as soon as I deleted the "1.7.1" subdirectory under AppData\Roaming\Mozilla\Firefox\Profiles\yrhii4yv.default\gmp-gmpopenh264\.

@jscher2000: Thank you for your comment. Manually readding the config preference "media.gmp-gmpopenh264.version" and setting it to the string "1.6" helped FF to find the plugin. At least I think, because in FF > Addon Manager > Plugins the notice saying "OpenH264 Video Codec provided by Cisco Systems, Inc. will be installed shortly" disappeared. The plugin name in the plugin detail view now contains the version 1.6. However it still can't transfer sound/video in Circuit, only text messages.

Did you check the Web Console for WebRTC related messages?

• "3-bar" menu button or Tools -> Web Developer
• https://developer.mozilla.org/en-US/Tools/Web_Console

No WebRTC related messages, only two warnings (exclamation mark "!" in yellow triangle in front of them) :

• HTTP “Content-Type” of “text/html” is not supported. Load of media resource https://circuit.my_company.com/ failed.
• Cannot play media. No decoders for requested formats: text/html, text/html.

I guess they aren't relevant here because texting works also for me and other collegues can talk, i.e the company server/website is not messed up.

Hmm, those messages could be relevant if a video you expect to load isn't loading. Getting an HTML response to a request for a media file or stream can indicate a problem with the address or some other issue like lack of authentication. You could try viewing the HTML response using the Network Monitor panel.

To open the Network Monitor it the lower part of the tab, you can use either:

• "3-bar" menu button > Web Developer > Network
• (menu bar) Tools > Web Developer > Network
• (Windows) Ctrl+Shift+e

When you click the reload button (or use Ctrl+r), Firefox should start listing all the files it is requesting, along with information about whether the request was successful. If you spot the media request that gets an HTML response, you can click it, and then check the Response pane on the right to see its contents.

Seems you've hit the point with those HTML responses to media requests, see the attached screen shots.

There are a few <media> tags sending requests with "Accept" headers stating expected media types of "video/*" and "audio/*". Unluckily the request URL only contains the domain host, no further parts indicate what is requested precisely. Though the response is HTTP 200 OK, but it contains "text/html" instead of some media content. The HTML page returned has a ton of JS in its head and an empty body with some attributes only.

Why this response comes remains unclear for me. It's definitely not access rights related because I'm logged in and can chat via text messages. I see no point in trying to start debugging our company Circuit server since others using the Circuit supplied desktop client (needs installation) or chrome (big brother watching) don't have this problem. Neither did I have it till yesterday.

Auto updates have always been on, both for FF itself and for all two plug ins I have - why did the update happened just yesterday and not before I have no clue. FF updated itself a few times in the past months I definitely remember.

I'm afraid I can only try a FF reinstall and if it doesn't help use one of the above programs until FF is fixed to work with Circuit again. I need my client by tomorrow. Thank you for all the help so far.

Any idea why the media request is to the / (home) page of the domain? That seems unusual for a media server. Maybe there is a problem with Firefox requesting media from the wrong path for some reason. If you compare the Network panel in the developer tools in a working browser, does that look like it might be the issue?

To diagnose whether this is a setting issue and we just haven't hit on what it is yet, you could try:

New Profile Test

This takes about 3 minutes, plus the time to test your problem site(s).

Inside Firefox, type or paste about:profiles in the address bar and press Enter/Return to load it.

Click the Create a New Profile button, then click Next. Assign a name like Nov2018, ignore the option to relocate the profile folder, and click the Finish button.

After creating the profile, scroll down to it and click the Set as default profile button below that profile, then scroll back up and click the Restart normally button. (There are some other buttons, but please ignore them.)

Firefox should exit and then start up using the new profile, which will just look brand new. Please ignore any tabs enticing you to connect to a Sync account or to activate extensions found on your system so we can get a clean test.

Do your problem site(s) work any better in the new profile?

When you are done with the experiment, open the about:profiles page again, click the Set as default profile button for your normal profile, then click the Restart normally button to get back to it.

If you decide to work with the new profile, this article describes the most valuable files you might want to migrate between your profile folders. Please make a backup first just in case a file is copied the wrong way...

• Recovering important data from an old profile
• Back up and restore information in Firefox profiles

Created a new profile as you suggested. It automatically recreated all my lost "gmpopenh264" preferences in about:config and reinstalled the newest 1.7.1 version of the "OpenH264 Video Codec" plugin. In Circuit it leads to the same communication error as originally and as with the manually restored 1.6 version yesterday. The networking details are also the same as posted above.

A clean reinstall of FF didn't help either.

Installed chrome and it works. Now waiting for an FF update to fix this and let me leave chrome ...

Thanks for the update. Are your colleagues still able to use the site with Firefox, or is the problem limited to your computer?

All my colleagues use either the desktop application from Circuit or chrome, I was the only one with FF around.

Now obliged to chrome I inspected its network traffic (screenshot attached). The main difference I notice is that it doesn't send its requests to the domain root url (/) as FF did but to a specific resource. The "Accept" header looks a bit different, but mostly complying. The response to this full request url is an audio file - as expected - and not text/html as in case of my FF was.