Our team is developing a web application that plays back recorded video stored in XProtect 2024 R2 using the WebRTC API.
We are establishing the WebRTC connection within a local network.
On one display PC, video playback via WebRTC worked when using a wired NIC. However, after adding a Wi‑Fi NIC to that PC and enabling it, WebRTC video playback appears to no longer work.
Have you seen any similar cases, or is there any plausible explanation for this behavior?
For example, is it possible that WebRTC prioritizes the Wi‑Fi interface IP address as an ICE candidate?
It is not something we experienced before and the decision of which NiC to use should be handled by windows.
Could you try and enable debug in the API Gateway (create a appsettings.production.json with debug logging) and send us the log. We should be able to see which IceCandidate are exchanged.
gateway.log (83.3 KB)
Thank you for your response.
When I turned off the WiFi NIC, I confirmed that video playback works normally.
Please review the attached XProtect API Gateway logs.
In the logs, the timestamp at 17:03 shows successful video playback with the WiFi NIC turned off, while at 17:05 and later, the issue occurs with the WiFi NIC turned on.
From my investigation of the logs:
When the WiFi NIC is OFF, the ICE candidates resolve to IPs 192.168.1.181/182 and connection succeeds:
2026-02-12 17:03:12.863+09:00 [ 22] DEBUG - Resolved mDNS address 33f30c08-bfc1-4878-8a51-9401a8c9ab78.local to 192.168.1.182
2026-02-12 17:03:12.863+09:00 [ 22] DEBUG - IceConnectionStateChanged sessionId: 4bd47b53-0d03-4154-b169-c95fb55c3991, connected
When the WiFi NIC is ON, the mDNS resolves to 192.168.106.175 (the WiFi IP), and the connection fails as ICE cannot reach this path:
2026-02-12 17:05:54.135+09:00 [ 31] DEBUG - Resolved mDNS address 4f3fe861-9c7d-4d0d-ab85-10fb66aa8945.local to 192.168.106.175
2026-02-12 17:06:10.183+09:00 [ 12] DEBUG - IceConnectionStateChanged sessionId: 36e955cc-4db5-4f87-8d96-9ca058089a2e, failed
It appears that the system is incorrectly selecting I/F candidates, resulting in this issue.
However, I don’t understand why the WiFi interface (metric 291) is chosen as a candidate despite having a higher metric than the wired LAN (metric 281).
Please advise on the cause and solution.
Best Regards.
Milestone Development will start an investigation. I will keep you updated here in the forum.
1 Like
To troubleshoot, we would like to ask about how ICE candidates are selected and advertised in SDP.
- When multiple NICs are present on the endpoint (e.g., Ethernet + Wi‑Fi), what criteria / priority does XProtect (WebRTC side) use to select which ICE candidates to include in the SDP?
(e.g., host vs srflx vs relay, interface preference, any metric-based selection) - During candidate gathering/selection, does the implementation consider the OS routing table, interface metrics, and IPv4/IPv6 preference?
- Is there any configuration or recommended workaround to prefer or exclude candidates from a specific interface (e.g., Wi‑Fi)?
The main criteria for selection is when a connection is made and the latency of that connection.
We don’t know, this would have to be investigated in the used components.
We have not seen this issue before and have no workaround besides disabling the unwanted interface.
Hey Kouzou
Sorry we read your initial message wrong. We read it as if it was the server which had a wifi and a ethernet and had issues. Client side we have a hard time helping you out as we don’t control the client.
As your logs show, we receive 4 ice candidates from your client. And depending on how the client is configured the 4 candidates either include the ethernet or the WIFI. If you can configure your client to send ICE candidates for both ethernet and WIFI, then our WebRTC connection would try all ICE Candidates and make a connection with the ethernet.