[EAS] Duplicate CAP alert criteria

Botterell, Arthur@CalOES Arthur.Botterell at CalOES.ca.gov
Wed Feb 14 14:31:10 CST 2018


Dave,

One of my big concerns right now has to do with the usability of IPAWS alert-authoring tools.  We're seeing multiple-try events happening way too often.

That said... what you describe is a hard case to solve automatically, especially as the third instance was even substantially different in content.  An individual CAP alert can be uniquely identified by the concatenation of the sender ID, the user-assigned message identifier, and the time sent.  (If we were doing it again I'd suggest making the use of a universally-unique identifier (UUID) as the message ID mandatory, as that would address the whole problem, but that ship has sailed.)

Unfortunately, in your case where there were three different alerts sent, neither the built-up identifier nor a UUID would allow those messages to be disambiguated.  Arguably, perhaps, it might have made sense to send the two follow-on messages as updates to the original, but I think the real fix needs to be not to have alerts fail in some distribution channels but not in others.

You don't specify what precisely was the problem with your original message(s), but in a more-nearly -perfect world your authoring tool would have kept you from sending an alert that wouldn't work.  I guess it might be possible to only route your second- and third-try messages to the particular distribution system that failed, but that demands that the alert originator have a lot more technical knowledge than should really be necessary.  Anyway, none of that helps much if you have a non-compliant dissemination tool in the mix.  

Maybe you should tell FEMA that something got past their certification testing on whatever product that was.

Art

-----Original Message-----
From: EAS [mailto:eas-bounces at radiolists.net] On Behalf Of Dave Turnmire

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). https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Feas.radiolists.net&data=02%7C01%7Carthur.botterell%40caloes.ca.gov%7C4f3f923e200e47d49e5f08d573e740d1%7Cebf268ae303647149f69c9fd0e9dc6b9%7C0%7C0%7C636542359412991277&sdata=Siz0q0KBEqAVmOaIyitaVW5CcxOdfoZhWoefWz524Ik%3D&reserved=0
Please invite your friends to join our Forum! The sign up is at: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.radiolists.net%2Fmailman%2Flistinfo%2Feas&data=02%7C01%7Carthur.botterell%40caloes.ca.gov%7C4f3f923e200e47d49e5f08d573e740d1%7Cebf268ae303647149f69c9fd0e9dc6b9%7C0%7C0%7C636542359412991277&sdata=ZQnejx67TPKJnjAG08MEeWAomo%2FKFL1kiBbqV4OuChc%3D&reserved=0
___________________________________________________________



More information about the EAS mailing list