저는 Linux 랩톱에서 작업 중이며 개발을 위해 도커 컨테이너를 사용하고 이를 로컬 도커 엔진에서 실행합니다(예: 그냥 docker compose up -d).
docker compose down영상 통화 중에 이 작업을 수행 하면 Google Meet 통화가 중단되는 것으로 나타났습니다 . 저는 매우 일반적인 Docker Compose 설정(컨테이너 2개, 네트워크 1개)을 가지고 있습니다. 콘솔에서의 통화는 거의 매번 오디오/비디오로 인해 중단되지만 화면 공유는 항상 종료됩니다.
이는 Firefox 121과 Firefox Aurora(122.0b5) 모두에서 발생하지만 Chrome이나 Chromium에서는 발생하지 않습니다.
내 전화가 왜 끊어졌나요?
NetworkManager가 도커 네트워크 변경 사항에 반응하고 있다고 의심했기 때문에 NM 구성에 추가하여 도커 관련 인터페이스가 항상 "관리되지 않음"인지 확인했습니다.
[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.
문서는 드물지만 다음에서 제공됩니다.모질라 위키특히 후보 생성에 영향을 미치는 다양한 ICE 설정이 있습니다.
media.peerconnection.ice.default_address_only-boolean(기본값false) - ICE 후보를 기본 인터페이스로만 제한합니다.
- 일반 라우팅에 사용되는 기본 인터페이스를 인식하고 해당 주소만 후보 생성에 사용합니다...
참고: 이 설정을 VPN과 결합하면 부정적인 영향을 미칠 수 있습니다.