Alarms moves to CloudSurgard in 7 days with no loss of signals or outages
The account is generated in CloudSurgard with a geographical number of tests so that calls can be sent from test panels or even real traffic and we can check that all the signals arrive correctly and that the configuration is correct.
The installation of an SSL tunnel between the Alarm Monitoring Software and CoudSurgard allows sending the encrypted signals and perform receiver authentication.
This installation is very simple and does not require modifications in the Alarm Monitoring Software, They can be installed at various points to have more connection paths in case of internet failure.
After this step we check that the signals enter the Alarm Monitoring Software correctly and that the receiver and line numbers, as well as the frame format, are correctly configured.
Cloudsurgard is tested with millions of signals every month and hundreds of thousands of different panels, but it is necessary to send signals before porting to check that everything is correct.
It is ideal to send signals from various panel models and formats that are available, to ensure that everything is receivable. It is at this moment when peculiarities are detected such as: Caller-Id format, behavior when 0 or A digits in Contact Id or in SIA, supported account lengths, etc.
Ee issue the number portability orders of the numbers programmed in the panels so that these numbers switch to the network of Peoplecall, the telecom operator behind CloudSurgard.
Portability is set for a specific day and time.
We remind you that due to the conditions of the CloudSurgard contract, number diversions are not allowed, so ALL the numbers programmed in the panels memory, that is, the numbers that the panels dial, they must be ported to Peoplecall and not translated numbers or diversion numbers.
It is much safer and more reliable for panel calls to go directly into Peoplecall without concentrating on any bottleneck or intermediate hub.
In approximately 7 days and in the set time window, the traffic will begin to enter through CloudSurgard and will gradually stop entering the previous receivers, until all calls enter through CloudSurgard This process usually takes about two hours.
Because the configuration is pre-tested, the ARC operators will not notice the rerouting.
It may happen that after the migration there is a panel that CloudSurgard cannot decode, either because it has a unknown protocol or due to some incompatibility, in this case the “spy mode” can be enabled
In this mode, when this panel calls again, we forward the call to a recipient of the above, that they correctly received the signals from this panel so that their signals are not lost.
While the spy mode is activated, the conversation between the panel and the previous receiver is recorded in CloudSurgard, allowing debugging and understanding what exactly happens to improve or adapt our decoders and be able to receive those signals later.
Calls that occur in spy mode are recorded in CloudSurgard and can be retrieved and listened to in the web interface, they are marked with the type SPIED
For a few days we will check that the received and processed signals adjust to the parameters normal reception of calls, trying to detect problems that could occur.
Each company is different, but the change process can take from 10 to 15 days, although in case it is necessary to make adaptations of new protocols or new functionalities, the process can be greater.
To better study your case, get in contact with us for a personalized plan.