Centralised CCTV Monitoring.

A multi-branch estate is almost never a single system. Site A has one brand of cameras on an NVR bought at fit-out, Site B has another brand from a later refit, Site C inherited whatever the landlord left. Head office wants one screen. What is genuinely achievable depends on facts that can only be established by survey: what each recorder exposes over the network, which codec each camera is actually encoding in and whether the recorder can transcode, whether a usable sub-stream exists alongside the main stream, how many concurrent outbound sessions the recorder will serve before it starts refusing them, which authentication method the firmware supports, and how old that firmware is. We record all of this per site before proposing a central layer, because a design written from a brand list rather than a capability list breaks at the third branch.

The bandwidth constraint runs the opposite way to most people's intuition. What matters is not the download capacity at head office but the upload capacity at each branch — ordinary business broadband is asymmetric, and the branch link is where the video has to leave from. The architecture that follows is a deliberate one: the full-resolution main stream is recorded and retained locally at the branch, while the central layer pulls the lower-bitrate sub-stream for live view. Operators at head office watch sub-streams; the main-stream footage crosses the link only for a specific export, for a defined time window, on request. Concurrent live views multiply the load, so the budget is set against how many panes an operator realistically opens at once, and against the export traffic that follows an incident, rather than against a camera count on a schedule.

The second real fork is federation versus a central VMS. Federation loosely joins the recorders you already own — the central client logs into each site's recorder and presents them in one tree. It preserves the existing investment and keeps each site autonomous, but the join is only as good as what each recorder exposes. Mixed brands federate unevenly: you commonly get live view and playback, and commonly lose that vendor's own analytics events, metadata search, and the finer PTZ behaviours such as preset recall and tour control. A central VMS replaces the management layer with one platform that treats every site as part of a single system, which buys consistent search, consistent user handling and consistent event routing — at the cost of a heavier server layer, per-channel licensing and, usually, replacement of devices too old to meet it. Neither is the right answer in the abstract. We test the actual devices, write down what survived the join and what did not, and recommend against the estate in front of us. Our NVR-versus-enterprise-VMS comparison sets out that fork in more detail.

Two things are designed in from the start rather than bolted on. The first is who can see what: a branch manager viewing their own site, a regional manager viewing a cluster, a control-room operator holding export rights, and an audit trail recording who viewed which camera and who exported which clip, with timestamps. For a bank, a hospital or anything carrying a privacy obligation, that trail is the difference between a system that can answer a complaint and one that cannot. The second is cyber posture: cameras and recorders are network devices with an operating system, a web server and a default password. They belong on their own segment, reached through a site-to-site VPN rather than a port forwarded to the open internet, with per-user credentials instead of one shared login and a firmware calendar that somebody owns after handover. A camera estate that is never patched becomes the softest route into the branch network.