Implementation considerations

In the scenarios where recordings are played back directly from the remote site or retrieved to the central XProtect Corporate site, there are several things to consider for optimal performance and user experience.

Retrieve recordings from remote sites when bandwidth in certain periods is reserved for other data

As an example, a retail chain has several shops that record video in each shop’s local VMS. To provide the VMS users in the retail chain’s headquarters access to investigate incidents and internal fraud in the shops, the local VMS in the shops are interconnected to the HQ site. However, during the shops’ opening hours, the network connection between the shops and HQ is reserved for business-related data. Therefore, in these periods, the bandwidth should not be used to transfer video recordings from the shops. Live viewing is permitted, but only if something critical happens.

With such a configuration, the challenges are:

Limit the bandwidth use from the interconnected site to when nobody views the cameras
Limit the CPU load on the central HQ site’s recording server when live video is viewed
Limit when recordings can be transferred from the shops to HQ
Ensure enough time and bandwidth to retrieve the recordings in a timely fashion

To address these concerns, the following is recommended:

Disable the live-feed rule for the interconnected cameras in the central XProtect Corporate site. If this is not done, the central XProtect Corporate site will automatically connect to the interconnected sites and continuously retrieve a live video stream, using bandwidth for no reason
If users in the central XProtect Corporate site need to view live video from the interconnected cameras, a new rule can be created to start the live video feed when a user in a client requests live video
In the central XProtect Corporate system, disable motion detection for the interconnected cameras to reduce CPU load when users view live video
Disable recording rules for the interconnected cameras to minimize disk load when users view live video
Configure the period in which recordings can be retrieved from the shops – for instance, outside business hours
Ensure the retrieval bandwidth limit and retrieval period for the interconnected sites are configured with enough bandwidth and a long enough period to allow the remote recordings to be retrieved in a proper timeframe.
- If too little time and bandwidth are allocated, there is a risk that retrieval jobs will queue up with a risk of recordings being deleted before they are transferred. Users will also experience that it takes a very long time before the requested recordings are available
- Note: A remote recordings retrieval job that has started will continue until it is completed, even if it goes beyond the configured period allowed for retrieving the recording. If these jobs mustn’t continue into a period where the bandwidth is needed for other traffic (for instance, no more retrieval after 8.00 am), the retrieval time window should be set so that any active jobs for certain can be completed before this time (for instance, end the retrieve time window at 6.00 am – allowing 2 hours for completing ongoing jobs)
In the central XProtect Corporate site, the recording retention on the interconnected cameras must be set long enough to allow further playback or investigation.
- To avoid concerns about disk usage combined with keeping the retrieved recordings for as long as possible, the storage container can be set to 365 days (or more), but limited in size. In this way, the VMS will try to keep the recordings for at least a year, but still automatically delete the oldest recordings if the storage limit is reached.

Following these recommendations, the recording server requirements on the central HQ site can be kept low, requiring only enough CPU and network bandwidth to act as a gateway for live viewing and retrieving recordings from the interconnected site.

Retrieve recordings from remote sites without a permanent network connection

In a transportation scenario where a vehicle, for instance a train, is temporarily out of network reach for the duration of a trip, and there is a wish to transfer all recordings from the train to a central site, once the train is again within network reach (for instance at a terminal or depot), it can be a challenge to:

Limit the bandwidth used for streaming live video, audio, and metadata from the VMS in the train to the central site during periods when the train is within the network connection
Ensure that there is enough time and bandwidth to retrieve recordings in a timely fashion when the train has a network connection to the central site
Ensure the recordings in the train are not deleted before there has been enough time to be retrieved by the central site

To address these concerns, the following is recommended:

Disable the live-feed rule for the interconnected cameras in the central XProtect Corporate site. If this is not done, the central XProtect Corporate site will connect to the interconnected site as soon as there is a network connection and retrieve a live video stream from the remote site, using bandwidth unnecessarily
In the central XProtect Corporate site, the recording retention on the interconnected cameras must be set long enough to allow further playback or investigation. To avoid concerns about disk usage combined with keeping the retrieved recordings as long as possible, the recording storage container can be set to 365 days (or more) but limited in size. In this way, the VMS will try to keep the recordings for at least a year, but still automatically delete the oldest recordings if the storage limit is reached
The retention settings and available storage space in the train’s VMS must be sufficient to store recordings for a long enough period to ensure that requested recordings can be transferred to the central site before they are deleted in the train’s VMS
- For example, if recordings in a train can only be stored for one day, there is a risk that the recordings will be deleted before they have been retrieved by the central XProtect Corporate site
It should be ensured that enough time and bandwidth are available to transfer requested recordings from the train to the central site when the train is connected to the network – for instance at terminals or depot
- If too little time or bandwidth is available, the retrieval jobs will simply queue up and at some point, the train’s VMS will start deleting recordings before they are retrieved

Following these recommendations will ensure that requested recordings can be transferred from the trains to the central site before they are deleted in the trains.

Retrieve recordings from remote sites over a network connection with plenty of bandwidth

Continuing the example with trains that for periods are out of network reach, but this time have plenty of bandwidth available when connected to the network, for instance at terminals or depots. It can be experienced that when transferring the recordings from the VMS in the train to the central site, the bandwidth available on the network is not utilized fully, causing the transfer to take too long time.

In this case, it is recommended that the number of parallel transmissions for the interconnected site are raised from the default eight to, for instance, sixteen. This will cause the bandwidth to be utilized better, ensuring a faster transmission of recordings. This, however, comes with the price of a higher load on the storage system of both the remote and central sites. If the storage system is not fast enough to handle this extra load, there is a risk that live video from the cameras on both sites will not be recorded with the desired framerate.

To address this the following is recommended:

Ensure that the disk performance in both ends can cope with this higher transfer load
Split the storage definition and recording in the central site over more disks and storage containers so that:
- One storage container/disk in the recording server is used for the live recording of standard, directly connected cameras
- Another storage container/disk is used for the remote interconnected cameras.
  
  Note: for this recommendation to be valid, it requires that the remote cameras are not also recorded in the central site, but only have recordings transferred from the remote sites
Find a balance between utilizing the network bandwidth and loading the storage system, by reducing the number of devices retrieved in parallel, or by reducing the allowed bandwidth to ensure that all video is recorded

While the recording of new media from the cameras connected to the central site might be at stake if the storage system is overloaded, there is no risk of losing any of the retrieved recordings, because more recordings are not transferred until the retrieved recordings are successfully stored in the media database.

Play back recordings directly from interconnected remote sites

In a city surveillance scenario where several sites are interconnected to the city’s central site and configured for direct playback of the recordings on the remote sites, the challenges are:

Ensuring there is enough bandwidth to play back the recordings directly from the remote sites
Limit and distribute the network and CPU load across multiple recording servers
Limit the disk requirements for the recording servers in the city’s central XProtect Corporate site

To address these concerns, the following is recommended:

Disable motion detection in the central XProtect Corporate site’s recording servers to reduce CPU load when viewing live video
Ensure there is enough upstream bandwidth available on the remote interconnected site, and enough downstream bandwidth available on the central XProtect Corporate site for simultaneously viewing the desired number of interconnected cameras – for instance viewing six cameras at the same time in live or playback
If interconnecting many remote sites to the central site and having many users on the central site viewing cameras at the same time, it can be beneficial to add the remote sites across several recording servers, because this will distribute the network and CPU load across more servers
There is no need for high-performance recording disks in the central site’s recording servers because the remote interconnected cameras are recorded on and played back directly from the remote sites. If the central site’s recording servers are not used for recording any cameras at all, the OS’ system disk can be configured as the default-recording disk for the recording server because nothing will be recorded on it.

Following these recommendations will ensure the central site’s recording server requirements are kept to a bare minimum, requiring only enough CPU and network bandwidth to act as a gateway for live viewing and playback of recordings from the interconnected sites.

Recording interconnected cameras in the central XProtect Corporate site

If the central XProtect Corporate site is configured to record interconnected cameras in its recording servers, the same recording server requirements and configuration guidelines apply like when recording standard cameras.