[EAS] Decoder handling of non-EAS CAP messages

[Ed Czarnecki]

I am traveling right now and don't have all the documentation at my fingertips.  Cat originator enter a block channel parameter to instruct the IPAWS aggregator what paths to disseminate the message (WEA, EAS. ..).
To my recollection the block channel for a meter is not a filtering criteria for XAO EAS devices.  That is it's not in the IPAWS or ECIG specifications for EAS devices. 
Put very simply, CAP EAS devices nearly all the IPAWS CAP EAS feed.  If the alert is present in the feed, it's supposed to be there.  The WEA feed is a completely separate messaging path that EAS devices do not have access to.

On Jul 20, 2015, at 2:48 PM, Dave Turnmire <EASsbeList at cableone.net> wrote:

>We had an interesting experience this last weekend that we are still
>trying to fully understand what happened.  We have been issuing CAP
>alerts for quite some time, but only recently started distributing via
>IPAWS.  Along with the latter, came our ability to generate WEA alerts.
>Saturday was the first occasion we had to initiate an alert that was NOT
>intended to be distributed via EAS... just WEA.

>Yet... even though the CAP message clearly identified it as for WEA
>only... it was in fact distributed to broadcasters.  And then forwarded
>to the public.  That was made worse by the fact that since it hadn't
>been intended to go to broadcasters, there wasn't any accompanying
>audio, and no "description" field for TV stations or Text-to-speech
>processing by decoders.  So, the residents of this particular county
>were advised there was a "Law Enforcement Emergency", but with no
>further info.  You can imagine some might
>be distressed by that.

>For those not familiar with the "under the hood" stuff, here is the
>relevant section of XML code from this message:

>    <parameter>
>      <valueName>BLOCKCHANNEL</valueName>
>      <value>EAS</value>
>      </parameter>
>    <parameter>
>      <valueName>CMAMtext</valueName>
>      <value>Endangered male w/ health issues. XXXXX in Grand View area
>    contact YYYY Sheriff
>      </value>
>      </parameter>
>    <parameter>
>      <valueName>BLOCKCHANNEL</valueName>
>      <value>NWEM</value>
>      </parameter>

>As I understand it, there are three possible "channels" of alerts via
>IPAWS, the "EAS" channel that we use, the "CMAS" (aka WEA) channel, and
>the "NWEM" channel (not yet implemented by NOAA Weather).  An alert can
>theoretically be sent by all three of these channels, albeit with

>somewhat different restrictions.

>To my way of thinking, our Saturday alert indicated TWO flaws.  One, our
>vendor for distributing CAP messages shouldn't have sent the alert
>direct to broadcasters and cable companies.  And second... the EAS
>decoders shouldn't have forwarded a CAP alert that wasn't marked for EAS
>distribution.

>So... my question for the group... especially decoder manufacturers...
>am I interpreting this situation correctly?  In the specific case of EAS
>decoders, shouldn't they be designed to ignore... or at the least not
>forward... CAP messages that indicate the EAS channel is blocked?

>Thanks

>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: http://lists.radiolists.net/mailman/listinfo/eas