In some network configurations, a TURN allocation on the go2rtc side is not sufficient. The browser also needs its own relay candidate.
The current card creates RTCPeerConnection with only the hardcoded Google STUN server.
Observed behavior
- go2rtc successfully allocates a TURN relay candidate;
- the remote relay candidate appears in
chrome://webrtc-internals;
- ICE remains in
checking;
- no video is displayed.
When the same TURN server is added to the browser-side RTCPeerConnection, ICE transitions to connected and the video starts working.
Tested scenarios
- an external Wi-Fi network;
- a network where the direct local route to go2rtc is unavailable.
Would you accept a PR adding an optional ice_servers card setting?
The setting would use the standard RTCIceServer structure and the existing behavior would remain unchanged when it is omitted.
Example:
type: custom:webrtc-camera
url: doorbell
ice_servers:
- urls:
- stun:stun.l.google.com:19302
- urls:
- turn:turn.example.org:3478?transport=udp
username: rtc
credential: password
In some network configurations, a TURN allocation on the go2rtc side is not sufficient. The browser also needs its own relay candidate.
The current card creates
RTCPeerConnectionwith only the hardcoded Google STUN server.Observed behavior
chrome://webrtc-internals;checking;When the same TURN server is added to the browser-side
RTCPeerConnection, ICE transitions toconnectedand the video starts working.Tested scenarios
Would you accept a PR adding an optional
ice_serverscard setting?The setting would use the standard
RTCIceServerstructure and the existing behavior would remain unchanged when it is omitted.Example: