Quick answer: Separate login/device availability, connection, live view, playback and slow video first. Record exact NVR/firmware, supported CASE Connect platform/version, approved access path and error/time. Check recorder networking and service status where applicable, device/account permissions and representative local/remote clients. The eight checks narrow possibilities; they do not diagnose almost every call or justify enabling a service, opening ports or relaxing a firewall without an approved design.
On this page
What does “the app does not connect” actually mean? The 8 checks at a glance
Ask which function fails, for which account/device/version, when it last worked and what changed. Compare an authorized local and remote path and another supported client where permitted. A Wi-Fi/cellular pattern helps isolate tests but cannot by itself prove the recorder, app, account or firewall is healthy or faulty.
| # | Check | Actual verification |
|---|---|---|
| 1 | Recorder network path | Correct actual interfaces, approved addresses/routes/DNS and relevant reachability; filled fields alone are not a pass |
| 2 | Time basis | Actual date/zone and approved synchronization; preserve relevant evidence before changes |
| 3 | Supported remote method/service | Exact model/firmware/client path and required status; do not enable an unapproved service |
| 4 | Device identity | Current supported device identifier/binding, checked privately; QR or code is not proof of ownership |
| 5 | Accounts and roles | Approved owner/operator/service roles, actual share/binding and required live/playback permissions |
| 6 | Supported client version/platform | Official verified distribution, compatible device/OS and necessary approved permissions |
| 7 | Path comparison | Record actual local/remote/client tests and errors without treating a pattern as a final diagnosis |
| 8 | IT-controlled network/service review | Relevant logs and narrowly documented destinations/ports/rules; no blanket outbound allow or protection bypass |
Choose the next check from the actual error, impact and known architecture. Recorder, client, account, service or IT review may be needed early. Do not claim most failures are particular checklist numbers or insist on a fixed order where it delays a relevant diagnosis. Keep the supported configuration and approval boundaries intact. Use the camera offline NVR checklist when the recorder’s channel or path also needs checking.
Is the NVR actually online? Gateway, DNS and the uplink port
Confirm actual interfaces and configuration rather than assuming one universal camera subnet or uplink behavior. CS-N220 P16H-AI lists a gigabit interface plus sixteen 100 Mbps PoE interfaces; CS-N110 P8H-AI lists eight-plus-one 100 Mbps interfaces. A misplaced cable is a possibility, not a guaranteed symptom pattern. Follow the approved network and device instructions before reconnecting anything; preserve required recordings and avoid creating loops or exposing the camera network.
Verify actual address, mask, gateway/routes and approved DNS according to the supported access method. A local ping proves only that particular reachability test, not internet or service health. Use permitted device/network diagnostics and relevant logs; a router client list or populated fields do not prove correct routing, DNS or authentication. Coordinate changes with IT rather than trying public services or arbitrary DNS settings as a shortcut.
Incorrect time can affect authentication and records, but is not the sole cause of a secure-connection failure. Record date, zone/DST, sync source and offset. Preserve relevant logs/recordings before an approved correction, following the NVR time and date wrong guide. Do not infer a failed battery from the symptom alone or change the clock silently during an evidence case.
Is P2P enabled and online, and does the device code match?
Confirm which access method this exact recorder/client/version actually supports and the customer has approved. Where a P2P/platform service is used, inspect its current supported status and relevant logs. That status is one test, not proof that each client function or account path works. The CASE Connect label does not establish one universal P2P registration workflow or every network requirement.
- Use the supported exact-model information/status screen and approved configuration; note the actual remote method and service state.
- If a service is disabled or unavailable, identify why and obtain the responsible approval/design clarification before enabling it; do not assume it was an accidental switch.
- Check actual DNS/routes/time, service availability and relevant IT logs against the documented requirements; offline does not prove a firewall fault.
- Privately compare the current device identifier and authorized account/binding with the supported client workflow. After a replacement, follow documented transfer/unbinding/re-add instructions; rescanning a QR alone may not transfer ownership or revoke old access.
CASE Cloud remote NVR configuration, CASE Station desktop and CASE Connect are separate catalog names; none establishes cloud recording or feature parity. Describe CASE Connect only by the functions confirmed for the actual device and software version. Android is available; iOS is forthcoming. A web version exists, but do not publish an unverified access URL or assume feature parity. Obtain the actual supported client/access workflow before naming an exclusive viewing path or publishing an unverified web address.
Account, sharing and permissions: who owns the device?
Review account and permission questions alongside network/client/service findings, without claiming they explain most remaining failures. Confirm the actual ownership/binding and sharing process for this app/device/version, including approved company control and revocable service access. Device sharing in a catalog does not establish every account-transfer behavior. Use user roles on CASE NVRs as a recorder-side reference; app binding still needs its own checks.
- Account: verify the intended authorized login and device list without assuming a personal/company account switch restores access automatically.
- Permissions: check the supported share/role scope for the failing live/playback/export task and any expiry or revocation.
- Binding/transfer: follow the exact documented process; adding a device to a test account may fail or behave differently, and removing an app entry alone may not revoke access.
- Device credentials: where the supported integration uses them, coordinate approved credential changes securely. Do not share secrets in a ticket or bypass the owner’s control.
Use the supported process to give the approved customer organization control, recovery arrangements and necessary roles. Retain only authorized revocable installer access and verify actual device/service revocation. The CASE Connect handover guide and user roles on CASE NVRs support planning; no one rule prevents every account, binding or client failure.
App version and phone network: why does it work on Wi-Fi but not on cellular?
Compare the authorized supported client and network paths, recording exact errors and outcomes. Keep account/device/version and test conditions explicit. The pattern table offers next checks, not definitive fault assignments:
| Observed pattern | Useful next checks | Do not infer |
|---|---|---|
| Site Wi-Fi works, cellular fails | Actual local-versus-remote method, cellular path/permissions, service/account and IT logs | That the app/recorder is completely healthy or only outbound firewall is wrong |
| Both fail on two clients | Shared device/service/account/network conditions and exact errors | That the recorder alone is faulty |
| One supported client works, another fails | Version/platform, roles, permissions, network and device capability differences | That every remaining issue is a phone setting |
| Connection works but video stalls | Stream support, decoding, layout/session limits, data path/latency/loss and actual workload | That bandwidth alone is the cause or one sub-stream preset will fix it |
Confirm supported platform/version and obtain software only through the verified official route. Android is available; iOS is forthcoming, so do not give current iOS CASE Connect installation steps or assume feature parity. Confirm actual OS/app compatibility and only the permissions required for the approved workflow. Do not disable device protections, data policy or network isolation broadly; document any authorized change and verify its effect. Use the CASE Connect handover guide to record the confirmed platform and access details.
Slow video can involve codec/client support, decoding, layout/session use, latency/loss, recorder resources and site/client data paths. The eighty-Mbps output rows for CS-N220 P16H-AI and CS-N110 P8H-AI do not prove internet upload is the first limit. Trial supported streams without sacrificing the agreed recording/evidence task; sub-stream planning for 4G/LTE covers workload estimates and real client tests.
The customer’s firewall: what to ask the IT contact
Where status remains offline, consider actual configuration, device/client version, account/service state and availability, time/DNS/routes and IT policy/logs. Do not conclude the site must be blocking traffic because several fields look correct. NAT, proxies and filters need assessment against this supported architecture; two routers do not have one guaranteed P2P outcome.
- Ask the responsible IT reviewer to compare relevant logs and the exact manufacturer-documented destinations, ports/protocols and supported path.
- Keep least-privilege rules and approved segmentation intact; do not request unrestricted outbound access from the recorder.
- Identify proxy, captive portal, DNS and routing requirements without bypassing controls or moving the system to a guest/business segment casually.
- Where the approved policy excludes the proposed service, assess a supported IT-approved alternative such as an appropriate VPN design; a VPN is not automatically compatible, secure or within every installer’s authority.
Do not expose recorder management or open inbound forwarding as a troubleshooting shortcut. Use the supported approved architecture, scoped rules and documented authorization, with logging and access controls appropriate to the site. Record each permitted change and test outcome; do not claim that every forwarding rule is identical or that an owner’s signature alone makes a risky design acceptable. The remote access methods guide separates the options and their approval requirements.
What to tell your customer
We will identify which device/account/path and function is failing, then test the supported recorder, client and network workflow. Any service or firewall change will follow the approved design with the responsible IT contact. We will verify customer control and necessary access rather than promise one setting or eight checks always resolve it.
FAQ
CASE Connect works on the site Wi-Fi but not on cellular. What does that mean?
It identifies a useful difference, not a final cause. Verify actual local/remote methods, supported app/platform/version, account/roles, cellular path/permissions, service status and relevant IT logs. A populated gateway or one successful Wi-Fi view does not clear the entire recorder/app, and allowing cellular data does not exhaust every phone-side possibility.
The NVR shows P2P online but the app still says the device is offline. Why?
Confirm current supported device identity, account/binding and roles alongside service/client/network findings and exact errors. Platform online status is not proof that all paths and functions work. Check time basis and required workflow, but do not reset, rebind or expose the system without authorization and the exact supported procedure.
Should I open ports on the customer’s router to make remote viewing work?
Do not open inbound management/forwarding as a shortcut or replace a restrictive policy with blanket outbound permission. Confirm the actual supported method, documented requirements and narrowly approved IT rules. If that method is prohibited, have the responsible team assess a compatible approved alternative; customer agreement alone does not establish a secure implementation. Use the NVR hardening checklist for the wider protection review.
Who should own the device in CASE Connect, the installer or the customer?
Use the supported ownership/binding and recovery process to establish the approved customer organization’s control, with named operator roles and only agreed revocable service access. Verify actual transfer, share scopes and revocation; device-add QR scanning, an app-entry deletion or a generic sharing label is not sufficient proof.
References
- Anabon Technical Support
- Current device manuals and documents
- Canadian Cyber Centre: least-privilege remote access and protective controls
