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.
Please add the following collaborators to this case:
Reason:
I inquired via chat whether it would be possible to configure case notifications to be sent to people other than the original inquirer.
I was advised that this could be arranged by mentioning the request in the case comments or case description for each case.
Note:
Both individuals already have Milestone accounts.
I cannot do this as an admin. Please advise the two:
-
Login on the forum
-
Open the topic (you can share the link to them)
-
Scroll to the bottom (right side of the timeline)
-
Click the
bell icon -
Choose Watching or Tracking
I’m posting this on behalf of Matsuyama-san.
The issue has been resolved, so I wanted to provide an update.
The root cause was a firewall configuration oversight. Adding the following rule resolved the video playback issue:
Firewall Rule Added:
-
Protocol: UDP
-
Local Ports: 49152-65535
-
Program: IIS (w3wp.exe)
Background: In our environment, the client PC has both a wired NIC and a WiFi NIC connected. During WebRTC ICE candidate gathering (onicecandidate), only the WiFi IP address was being offered as a candidate. However, the actual communication path to the XProtect server uses the wired NIC (same network segment), requiring the server to accept UDP packets from an IP address not present in the signaled candidate list (peer reflexive candidate).
Issue Details: The Windows Firewall on the XProtect server was creating an allow-list based on the candidates exchanged during WebRTC signaling (WiFi IP). As a result, UDP packets from the actual source IP (wired NIC) were being blocked.
Attempted Solutions: We tried multiple approaches on the client side to include the wired NIC in the candidate list, including adjusting network interface metrics and Chrome launch parameters. However, due to environmental constraints, we were unable to force the wired NIC to be included in the signaled candidates.
Final Resolution: By explicitly allowing UDP inbound traffic for IIS (w3wp.exe) via a Windows Firewall rule on the XProtect server, the server can now accept connections from IP addresses not in the candidate list (peer reflexive candidates), which resolved the issue.
Thank you for your assistance.
2 Likes
Nice to hear that you found a solution and thanks for sharing it!