All Media Servers Fail to Start after ~ July 25, 2025 @ 7 AM PST

LiveSwitch has the following bug: At startup, the server attempts to download the h264 dll/driver from http://ciscobinary.openh264.org/openh264-1.7.0-win64.dll.bz2 (for Windows, and Linux equivalent)

A download invoked on startup changed that the LiveSwitch code / .NET core cannot currently handle in version 1.34.3. As a result the download is not properly recognized, which causes the the server not to start. No LiveSwitch servers have started since July 25, 2025 @ 7 AM PST with exceptions such as those on closed networks and those that have cached the older download and invoke it on startup rather than a fresh download.

The workaround (until a full fix is available) to make sure this does not happen is to block the DNS entry so the download fails cleanly, which then allows the server to start.

Here are the workaround instructions for non-AWS:

To force download failures from ciscobinary.openh264.org outside of AWS, add a hosts file entry that redirects that domain to localhost. The attempt to download from localhost will fail and the Media Server will start.

For Linux systems: echo “127.0.0.1 ciscobinary.openh264.org” | sudo tee -a /etc/hosts

Here are the workaround instructions for AWS:

1. Create Rule Group
2. AWS Console → VPC → DNS Firewall → Rule groups
3. Click Create rule group
4. Name it (e.g., “block-cisco-openh264”)
5. 2. Add Blocking Rule
6. Custom domain list
7. Create new domain list
8. Enter list name (e.g., “block-cisco-openh264”)
9. Add domain to block (e.g., *.openh264.org)
10. Action: BLOCK
11. Response: NODATA
12. Click Add rule
13. 3. Apply to VPC
14. VPC associations → Associate VPC
15. Select your VPC
16. Click Associate
17. 4. SSH onto an EC2 instance on that VPC and test that it the domain is now blocked:
18. nslookup ciscobinary.openh264.org
19. Should fail – no DNS resolution

Note: This is what the error triggers in the logs; a media server has this line:
OpenH264 v1.7 library missing. Downloading now from
but NOT followed by this line:
Application started. Press Ctrl+C to shut down.

The root cause details are as follows:

• The Content-Type response header is naturally used in the server code to determine if downloaded content is binary or text.
• The Content-Type for the openh264 URL was likely previously “application/x-bzip2” and treated as binary.
• It is currently “binary/octet-stream” which is handled incorrectly in the server code and treated as text.
• This was causing an uncaught exception during decompression that halted server startup.

Tests to confirm this issue:

1. Checked the Content-Type header. It is still “binary/octet-stream”.
2. LiveSwitch also tested starting a new Media Server running 1.24.3 and it failed to start.

Note: Depending on your configuration, you might have a copy of this file cached from a prior download during a prior start up. For example, if you are running directly on Linux and started a server prior to this issue, a restart of the process may use a cached copy instead of attempting to download again.