[EAS] Part 11 / Local CAP Relay Networks

[Harold Price]

Eric,

Yes, CAP does have a method of duplicate detection, a combination of 
three fields, sender (Guaranteed by assigner to be unique globally), 
identifier (unique message id from that sender), and sent (time 
stamp, not unique).  It is therefore possible to send a CAP message 
through a variety of means, and have the CAP receiver avoid 
processing the CAP message more than once.

** Warning - long winded digression follows **

Once a CAP message jumps from the CAP domain to the EAS domain, 
however, there is no longer any way to track CAP duplicates. 
Duplicate EAS messages are weeded out at the EAS level, using 
originator, event, locations, start time, and duration.

So, it should not be possible to have two different CAP messages 
issued by the same or a different sender that appear to be 
duplicates, though this depends on the originator (that is, the 
originator's software).  Some originators are using a GUID - best 
practice, I think; some are using a combination of date and 
time.  That is risky, but since the time includes seconds, probably 
ok as a practical matter.

Is is possible to have a false duplicate in the EAS domain, however, 
that is, two CAP messages that are not duplicates can contain 
unintentionally duplicate EAS messages.  This is because EAS times do 
not include seconds or specific sender information.  For example, if 
a message is issued at 12:01:05 (hh:mm:ss), and another with the same 
orig code, event code, location list, and duration is issued at 
12:01:35, then they will appear to an EAS system as both being issued 
as 12:01, and the 2nd will be ignored.

There is no "fix" to this without changing the basic EAS protocol 
itself. It has always been this way.

The EAS-CAP Industry group worked hard to make sure that a single CAP 
message would always generate the exact same EAS message, no matter 
which vendor rendered the CAP message into EAS.  Otherwise, you could 
have a single CAP message generating one EAS message from vendor A, 
and another from vendor B, so the broadcaster relaying EAS alerts 
would send an RMT twice.  This could and did happen back in 2008, 
that particular issue was a different ordering of multiple FIPS codes.

** end of long winded digression **

Harold

At 01:59 PM 5/20/2011, Eric Adler wrote:
>I use the mikrotik routerboard products here for a lot of things) so 
>that they all reach the CAP/EAS box and the CAP/EAS box can check 
>message/event IDs to see if it is a duplicate or not (sorry, I'm not 
>fully up-to-date on CAP/IPAWS standards but I'd hope each message 
>has a globally unique identifier [GUID] that follows it along all 
>paths, including EAS).