[EAS] Duplicate CAP alert criteria

[Harold Price]

Dave,

Further to what Ed and Art have already said.  There was another 
interesting thing about these alerts.

Summary of my comments below:  The third repeat of the message was 
not detected as an EAS duplicate because the location codes were in a 
different order.

Details:

As Art said, CAP messages are duplicates if sender, identifier, and 
sent(time) are all the same.  In this case, the identifier was 
different for each, sent was different for each, and sender was 
different on one.  None of these were CAP duplicates.

As Ed said, EAS uses originator, event, locations, send time, and 
duration.  If all of these are the same, then the alert is a 
duplicate.  Because EAS does not use seconds, the sent times of 
23:40:06, 23:40:31, and 23:40:47 all look the same to EAS - 23:40.

The EAS times were the same for all three. Why then did EAS recognize 
the first two EAS messages as duplicates, but not the third?  Because 
the CAP message has the geocodes in a different order.

Part 11 says 11.33(a)(10)  "Message Validity. An EAS Decoder must 
provide error detection and validation of the header codes of each 
message to ascertain if the message is valid. Header code comparisons 
may be accomplished through the use of a bit-by-bit compare or any 
other error detection and validation protocol. A header code must 
only be considered valid when two of the three headers match exactly. 
Duplicate messages must not be relayed automatically."

The method of duplicate detection is not spelled out in detail, but 
it in a section otherwise discussing bit by bit comparisons. To clear 
up the possible ambiguity in detection of duplicate EAS messages, the 
ECIG implementation guide says about converting CAP to EAS: 3.4.1.3 
"...At least one <geocode> must be present, and only the first 31 
geocodes SHALL be placed in the order that they are encountered in 
the CAP message. The ordering preservation is required to allow 
duplicate EAS messages to be detected by direct comparison of the ZCZC string.

and 3.11(2) "If an EAS message is identical to another EAS message, 
as determined by a byte-wise comparison of the ZCZC strings (not 
including the LLLLLLLL field), it is a duplicate message in the EAS 
domain. Note that two messages with the same locations in different 
orders are different messages."

Apologies if someone else has already pointed this out.

Harold

At 02:51 PM 2/14/2018, Dave Turnmire wrote:
>I have long been familiar with the criteria used by decoders to 
>identify "duplicate" S.A.M.E. alerts.  But... a recent event caused 
>me to wonder about what the criteria is for recognizing duplicate CAP alerts.
>
>Last week a bug in the software used in our state caused the user to 
>be told "message not sent" after they pressed the Send button. So... 
>they tried again.  And then another staffer sent a third. Well... 
>fortunately it didn't involve ICBMs... but it was three RMTs sent in 
>a row to much of the state and you know how broadcasters like that.
>
>In the rush to get the RMT out "on schedule" the third one used 
>another template than used for the first two.  The ONLY difference 
>was what the text and audio indicated the originating party was (we 
>have a primary and backup CAC).  And... they immediately realized 
>they had used the wrong template so then issued a "cancel" message. 
>All of this via IPAWS.  Well... I just discovered there was one more 
>difference in the third case... there was a typo in the template for 
>the third RMT such that it's "title" was "Required Weekly Test" 
>rather than the correct "Required Monthly Test" (since corrected).
>
>So... setting aside WHY all of the above happened (we're addressing 
>that) is the question of WHY decoders behaved as they did.  And to 
>what extent that response is consistent between manufacturers.  What 
>happened on my DASDEC is it recognized the second RMT as a duplicate 
>and didn't forward it.  But... it didn't recognize the third one as 
>a duplicate and DID forward it.  I think at least some SAGE boxes 
>behaved similarly, but I'm not sure.
>
>All three of these alerts were sent within a 41 second time span. At 
>least in some cases, the second one was considered a duplicate. All 
>three had DIFFERENT "Message Identifiers".  As far as I can tell, 
>the first two were identical in all other ways.  The third had a 
>different audio URL and "Description" text.  And what ever CAP calls 
>the "title".    Which of those three differences (if any) would 
>cause the decoders to identify it as a unique message?  And what 
>needs to be different to have caused the first two messages to be 
>considered unique?  Obviously the message identifier wasn't 
>enough... at least in some cases.
>
>Any input Ed?  Harold?
>
>Dave
>
>__________________________________________________________
>The EAS Forum Discussion List is hosted by the BWWG (Broadcast 
>Warning Working Group). http://eas.radiolists.net
>Please invite your friends to join our Forum! The sign up is at: 
>https://lists.radiolists.net/mailman/listinfo/eas
>___________________________________________________________