Document direct-transfer browser support and network troubleshooting

README.md

@@ -30,3 +30,32 @@ memory and bigger ones use the relay.
 Server logs report how each direct session ended (`RTC session ... closed:
 done|timeout|...`), which tells you how often the direct path actually works.
 
+### Browser support and why the direct path may not activate
+
+Browsers only advertise their LAN address as an mDNS `.local` name, so a direct
+transfer needs both sides to *resolve* mDNS. Verified on a UniFi home network:
+
+| sender \ receiver | Chrome / Safari (desktop, Android, iOS) | Firefox desktop | Firefox Android |
+|---|---|---|---|
+| Chrome / Safari / Firefox desktop | direct | direct | **relay** |
+| Firefox Android | **relay** | **relay** | **relay** |
+
+Firefox Android does not resolve mDNS candidates (no Android multicast lock),
+so any transfer involving it falls back to the relay within a second. This is
+a browser limitation; the only workarounds (a STUN server, or camera
+permission to expose raw IPs) were deliberately rejected.
+
+If a Chrome/Safari pair still uses the relay, check the network:
+
+- **Client isolation** on the Wi-Fi (UniFi: *Client Device Isolation*):
+  `ping <other device>` fails → no direct traffic is possible at all.
+- **Multicast blocked** (UniFi: *Block LAN to WLAN Multicast and Broadcast
+  Data*, or mDNS not reflected across VLANs): `ping` works but
+  `dns-sd -B _services._dns-sd._udp` (macOS) lists no other device → mDNS
+  can't resolve. Enable *Multicast DNS* / stop blocking multicast on that SSID.
+- **VPN or firewall** on one device swallowing multicast or inbound UDP.
+
+The browser console shows the outcome of every attempt
+(`rtc receiver session ended: done|timeout|ice-failed (...)`) with the
+candidates exchanged, which pinpoints which side failed.
+