Posting a fully-diagnosed case because the usual "check your router/Wi-Fi/firmware" replies do not apply here — I have isolated this to TP-Link's remote-access service by direct testing.

Setup
- Cameras: Tapo C530WS (HW 2.0, FW 1.3.5) + others, all on current firmware.
- Tapo app on current iOS (also reproduced on a brand-new phone with a fresh app install).
- ISP router single NAT, genuine public IPv4 (no CGNAT).

Symptoms
- Local live view (phone on home Wi-Fi): flawless, instant.
- Remote live view (phone on cellular OR a different fixed-broadband network): spins, then "tap to refresh"; or streams for ~10–15s then drops and will not re-establish; switching cameras fails.
- Motion push notifications continue to work remotely.
- Affects all cameras simultaneously. Began after an ISP router swap, but see diagnostics — the router has been positively excluded.

Diagnostics performed (each a measurement/isolation test, not inference)
1. Power-cycled cameras + router — no change.
2. ISP content filter (Broadband Shield) — confirmed disabled. Not the cause.
3. UPnP — enabled on router; portmap table empty (expected, since Tapo uses cloud P2P/relay, not UPnP). Not relevant.
4. Router firewall — outbound ALLOW all; camera→cloud control path healthy (notifications prove this).
5. Extenders excluded — a camera wired directly to the main router (no extenders) still fails remotely.
6. NAT type measured via STUN (one socket, 3 independent STUN servers): endpoint-independent and port-preserving mapping = full-cone NAT. Categorically not symmetric. P2P-friendly.
7. Path MTU verified — full 1500 passes, no fragmentation issue.
8. IPv6 disabled on LAN — no change.
9. DMZ test — camera placed in router DMZ (full inbound exposure). Tapo app remote view **still failed**. This positively excludes the user router's NAT/firewall: if it were the cause, full exposure would fix it.
10. Definitive test — direct RTSP over the WAN, bypassing TP-Link entirely: enabled the camera's Camera Account (RTSP), exposed port 554, and viewed `rtsp://<cam>:<pwd>@<public-ip>:554/stream1` in VLC from a phone on cellular. Result: flawless, stable HD video with zero intermittency. (DMZ/forward removed immediately afterward.)

Conclusion
Same camera, same home network, same router, same phone, same cellular connection. The only difference between flawless (direct RTSP) and broken (Tapo app) is that the Tapo app's remote path is brokered through TP-Link's cloud P2P/relay, whereas RTSP is not. Every user-side component (camera, router, NAT type, MTU, extenders, phone, cellular) has been positively excluded by measurement. The fault is in TP-Link's remote-access service (P2P brokering and/or the deliberately rate-limited relay described in your own FAQ 2720 / Tapo FAQ 55).

What I am asking TP-Link to do
1. Acknowledge this is a cloud-side relay/P2P brokering issue, not a user-network issue.
2. Check the relay/P2P session logs for the affected account/devices (I can supply device IDs / account on request) and explain why P2P is not establishing despite full-cone NAT on the camera side and a fully DMZ-exposed camera.
3. State clearly whether free-tier remote relay is being throttled/limited, what those limits now are, and whether they changed recently.
4. Provide a supported way to obtain reliable remote live view without third-party workarounds (VPN), given the hardware is fully capable (proven by direct RTSP).

Happy to provide logs, device IDs, the STUN/MTU/DMZ test details, and the RTSP capture privately. Please escalate beyond standard troubleshooting — the standard steps have all been completed and documented above.