私はLinuxラップトップで作業しており、開発にドッカーコンテナを使用し、それをローカルドッカーエンジンで実行します（例：）docker compose up -d。
docker compose downビデオ通話中にこれを行うと、Google Meet通話が中断されることがわかりました。私は非常に一般的なDocker Compose設定（コンテナ2つ、ネットワーク1つ）を持っています。コンソールからの通話はほぼ毎回オーディオ/ビデオによって中断されますが、画面共有は常に終了します。
これはFirefox 121とFirefox Aurora（122.0b5）の両方で発生しますが、ChromeやChromiumでは発生しません。
私の電話はなぜ壊れたのですか？
NetworkManagerがDockerネットワークの変更に反応していると思ったので、NM設定に加えて、Docker関連のインターフェイスが常に「管理されていない」ことを確認しました。
[keyfile]
unmanaged-devices=interface-name:docker*;interface-name:veth*;interface-name:br-*
...しかし問題は残ります。
私はDebian 12、Linux 6.5、Docker 24を使用しています。
答え1
Chrome と Firefox WebRTC スタックは ICE (対話型接続設定) を異なる方法で使用します。
どちらのブラウザも通信用の「ICE候補」リストを保持します。 Chromeは、ネイティブネットワークインターフェイス（wlanまたはethアダプタインターフェイスであるプライマリルーティング用のインターフェイス）の候補のみを使用します。対照的に、Firefoxは、dockerによって生成されたbr-*インターフェースを含む基本的にすべてのインターフェースを考慮しますveth*。
FirefoxでWebRTCの問題を回避するには、デフォルト以外のインターフェイスを無視するように設定できます。特別なabout:configURLを通じて、media.peerconnection.ice.default_address_onlyに設定しますtrue。
文書はまれですが、以下で提供されます。Mozilla Wiki具体的には、候補生成に影響を与える様々なICE設定があります。
media.peerconnection.ice.default_address_only-boolean（デフォルトfalse） - ICE候補をプライマリインターフェイスに限定します。
- 一般的なルーティングに使用される基本インターフェイスを認識し、そのアドレスのみを候補生成に使用します。
注：この設定をVPNと組み合わせると、悪影響を及ぼす可能性があります。