ONVIF discovery
ONVIF Discovery Port 3702
ONVIF discovery uses WS-Discovery. An IPv4 scan sends a Probe to multicast address 239.255.255.250 on UDP port 3702; a camera answers with the address of its ONVIF device service.
Protocol references checked: July 22, 2026
Quick answer
IPv4 multicast: 239.255.255.250
Discovery port: 3702
Protocol: WS-Discovery / SOAP-over-UDP
IPv6 multicast: FF02::C
Scope: local link by default
Port 3702 is only the discovery transport. It is not automatically the camera's ONVIF web-service port and it is not the RTSP media port. A ProbeMatch can point to an HTTP or HTTPS device-service address on another port; the resulting media profile can then return an RTSP URL, commonly on port 554.
What SmartRTSP does during ONVIF scan
When you tap Scan, SmartRTSP sends a WS-Discovery Probe, reads each ProbeMatch device-service address, then uses the selected camera account to request media profiles and a stream URI. Discovery itself happens before camera authentication, so appearing in a scan does not prove that the username, password or media profile will work.
Why all-subnet ONVIF discovery often fails
WS-Discovery multicast is local-link traffic. Routers normally do not forward it between subnets, and guest Wi-Fi, mesh client isolation, VLAN ACLs or a VPN can block either the Probe or the reply.
- Give SmartRTSP local-network permission in the Apple device's privacy settings.
- Put the iPhone, iPad, Mac or Apple TV on the same LAN/VLAN as the camera for the first scan.
- Disable guest-network or AP client isolation while testing.
- Allow outbound WS-Discovery multicast and return UDP traffic for the requesting app. Do not require the viewer to use 3702 as its source port.
- Allow the device-service HTTP/HTTPS port and RTSP media port after discovery.
- If the camera is intentionally on another subnet, add it manually by IP/RTSP or configure routing and multicast policy deliberately.
Troubleshooting by result
| What you see | What it proves | Next check |
|---|---|---|
| No camera appears | The Probe or ProbeMatch did not complete | Local-network permission, same VLAN, ONVIF enabled, AP isolation, VPN and multicast firewall policy |
| Camera appears but login fails | Discovery works; authentication does not | Use the camera's local/ONVIF account, not a cloud account; create a separate ONVIF user when required |
| Login works but no profiles appear | The device service is reachable | ONVIF media-service support, permissions, firmware and Profile S/T conformance |
| A profile appears but video fails | Discovery and GetProfiles worked | GetStreamUri result, RTSP port, codec, transport, credentials and camera stream settings |
| Some NVR cameras are missing | The recorder may expose channels rather than each camera as a device | Use the NVR's media profiles or a model-specific NVR RTSP channel URL |
Check the network packet path
On a Mac, a packet capture can separate a network problem from an account or codec problem. In Wireshark, use udp.port == 3702. A Probe with no ProbeMatch points to multicast, VLAN, isolation or device-discovery settings. A ProbeMatch followed by an HTTP or RTSP failure means discovery worked and the next service is failing.
Use ONVIF discovery in SmartRTSP
SmartRTSP can discover compatible ONVIF cameras on the local network and request their media profiles, so you do not need to guess a brand-specific RTSP path. After adding cameras, you can view up to eight simultaneously on iPhone, iPad and Mac; Apple TV Monitor offers 4-, 6- or 9-tile layouts.
Official references
These standards and conformance documents define the discovery exchange, multicast addresses and current ONVIF device tests.