Fire-Lite IPDACT-2 - Manual (Page 7)

IPDACT-2(UD) - Introduction
I-4
Doc.DM385-I
Rev. 4.0
backup VisorALARM, to which it will now try and send the alarms, polls, etc.
In cases where communication with this second device also fails, the
telephone line access is returned to the control panel as if the IPDACT-2(UD)
was not present. From this point on, the IPDACT-2(UD) will try to re-establish
communications both with the main Teldat VisorALARM and the backup,
communication with the main device taking priority. The moment
communications are reestablished with either of the two ARC devices, the
IPDACT-2(UD) intercepts the telephone line once more.
The supervision traffic is encrypted UDP. The Ethernet frame size does not
exceed 70 bytes. The monitoring interval, the number of retries and time
between retries are all configurable, and are values that must be carefully
considered. Normally the monitoring interval in the control panel is high as
this implies a telephone call. However, in the case of IPDACT-2(UD), this
cost is irrelevant as it is dealing with traffic which in all likeliness is running
over a flat rate connection. In addition, a high value here is not advisable in
cases where the IPDACT-2(UD) connects to Internet through a router
executing NAT, a very probable situation. This is because traffic coming from
the ARC towards the IPDACT-2(UD) reaches this thanks to the router
maintaining the entry in the NAT table active during a period of time, the entry
being refreshed with supervision traffic. If the supervision interval is greater
than the residence time for the entry in the NAT table, communications from
the ARC will not be possible. There is no rule to say how long an entry in the
NAT table must last for. In cases of the TELDAT devices, this is around 5
minutes. A low value has the problem that the traffic the VisorALARM must
process is high, the same as the bandwidth requirements. If ARC Internet
access is ADSL, you need to consider that the upstream channel is smaller
than the downstream one and that supervision traffic returned to the IPDACT-
2(UD)s is slighter larger than the incoming.
The Teldat VisorALARM received monitoring messages from the IPDACT-
2(UD)s. If these are registered, they are assumed alive and an
acknowledgement response is sent to them; if the IPDACT-2(UD)s are not
registered, they are ignored. Periodically the status of all the registered
IPDACT-2(UD)s is checked and all those which have not notified their
availability (i.e. those which have not responded since the last check) an
alarm is generated. This is a 350 code alarm from the Contact-ID protocol
(Communication trouble) which is received in SwAut.
In order to prevent the Teldat VisorALARM from sending hundreds or
thousands of communication failure alarms when faced with a situation of
general failure of IP traffic reception, the device itself monitors the network
access through echo ICMP packets (ping) to a known address: if the echo
ICMP packets (ping) towards this address fail then a code 356 alarm is
generated from the Contact-ID protocol (Loss of central polling).
Apart from the above codes, the VisorALARM also generates others related
to network backup.