[itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)

[Eliot Christian]

Paul,

At 08:52 PM 5/28/2007, Paul E. Jones wrote:
>[...] For example, assume that the NWS detects the tornado.  By what 
>means is it expecting to send the CAP message to the Weather Channel? 
>If H.323 had the facility, would the NWS perhaps send the CAP message 
>directly to a receive using H.323?  (This is akin to placing a phone 
>call, but rather than delivering a voice message, the system delivers 
>a text message and gets acknowledgement of receipt.)

Alerting authorities around the world, like NWS and USGS, use a wide 
range of communications mechanisms. Essentially, they'll use whatever 
it takes to reach their target audience of emergency managers and/or 
the public. If H.323 is in broad use and provides for delivery of an 
XML (structured text) message, I anticipate that alerting authorities 
somewhere will use that facility to send CAP messages.

>Or, is it expected that the Weather Channel would fetch these CAP 
>messages through other means?

Anyone can pull CAP messages at any time from a public news feed 
at NWS ( http://www.weather.gov/alerts ). For publishers who need 
to fetch alerts at high volume (including fast update frequency), 
alerting authorities will make special arrangements--typically a 
dedicated, high-bandwidth, secure, redundant communications path. 

A direct answer to your question is that Weather Channel already 
has other means for getting CAP messages from NWS. But, they'll 
need other mechanisms for picking up relevant alerts from other 
alerting authorities. For instance, the Weather Channel inserts 
reports of local conditions country by country around the world. 
They'll need to get weather, air quality, ultraviolet and many 
other kinds of alerts from all kinds of local alerting authorities.  
So, designers should not foreclose any communications mechanism.

>I don't expect to see H.323-enabled sirens and such, so let's 
>consider a user's PC-based softphone or IP phone: would you 
>expect the NWS or Weather Channel or other entity to transmit 
>the CAP message directly to the end user of such devices? 

Yes. We envision apps for CAP alerts in any and all devices 
that are location-aware. Even if the device does not have GPS, 
any device on the public Internet can get the location of its 
connection point--probably precise enough for most threats.

We are anticipating that the makers of chipsets for cell phones 
will ship CAP-aware software at some point. I understand that 
most cell phones already have a second processor for general 
purpose computing applications. In that case, the processing 
of a CAP alert need not be handled by the communications chip. 

There is a potentially huge market for people to receive CAP 
alerts. In addition to being warned of threats at their current 
position, people would like to be warned of threats occurring 
wherever their loved ones are: a child at home or away at school; 
a grandparent in a nursing home, etc. After the Virginia Tech 
tragedy, universities are looking for ways to reach everyone 
on campus in an emergency. Hotel chains found the same demand 
after the tsunami of 2004. As noted above, when the need is 
reach everyone, alerting authorities use all possible media.   

> Or, would you expect the CAP message to be translated in
>the network into something that is "human decipherable" (e.g., 
>a formatted text message, video message, or voice message) 
>that gets "played" to the user?  In that case, the user's 
>equipment would never see or process a CAP message.

Certainly this mode of public warning communications is common 
and will remain so. But, processing of actual CAP messages by 
end devices is much to be preferred. The user can then filter 
messages according to his/her personal needs (e.g., I need 
higher sensitivity for any alerts affecting my blind brother).

Eliot


>> -----Original Message-----
>> From: Eliot Christian [mailto:echristian at usgs.gov]
>> Sent: Monday, May 28, 2007 9:56 AM
>> To: simao.campos at itu.int; paulej at packetizer.com;
>> s.horne at packetizer.com; Christian.Groves at nteczone.com
>> Cc: itu-sg16 at lists.packetizer.com; Art Botterell
>> Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting
>> Protocol (CAP)
>> 
>> Please forgive me diving into the middle of this discussion.
>> 
>> I would like to make a distinction here: a CAP message is a special
>> case of emergency messages generally. We all know that just about any
>> medium can be used to communicate emergency messages: sirens, police
>> with bullhorns, voice over radio or telephone, text over news wire,
>> text crawl over television, fax, e-mail, and so on. I would say that
>> the underlying source of any emergency message may include, but is not
>> limited to, a CAP message.
>> 
>> I'd also note that CAP only standardizes the information content of
>> emergency messages as they are being communicated digitally and
>> electronically. A CAP message must be delivered entirely and without
>> corruption, and in its specific structured format (transformable to the
>> prescribed XML or ASN.1 syntax and encodings).
>> 
>> Human receivers of emergency messages rarely deal directly with
>> underlying CAP messages. A person who hears a siren blaring does not
>> know or care if the siren is a TCP/IP device programmed to process CAP
>> messages. The same is true of a warning given by a policeman based on a
>> CAP message to his squad car, or a warning given by a radio announcer
>> reading a CAP message off of a news wire service.
>> 
>> Yet, the relaying, filtering, and routing of CAP messages is a very
>> important aspect as CAP messages do traverse a wide range of
>> communications paths. From a communications architecture perspective,
>> our key consideration is whether traversal of a given path segment
>> preserves the content and structural integrity of the CAP message and
>> any associated authority, authenticity and security assertions. Where
>> such integrity is not preserved, we should say that delivery of the CAP
>> message is finished although the emergency message itself may continue
>> to be relayed.
>> 
>> For example, let's say the National Weather Service sends out a CAP
>> message for a tornado alert. This CAP message is then picked up by the
>> Weather Channel and inserted into television news. Seeing that message
>> on television, local police trigger the public address system at a
>> shopping mall in the threatened area. Here, a complex relay of the
>> emergency message is occurring. The emergency messages were triggered
>> by the original CAP message but the derivative emergency messages are
>> not preserving the full integrity of the underlying CAP message.
>> 
>> Expanding on the example, it is also possible for a local police system
>> to pick up the CAP message directly from the National Weather Service.
>> The police system can then automatically relay that message to an
>> automated system at the shopping mall, programmed to process the CAP
>> alert directly. In a similar vein, commercial wireless service
>> providers in the U.S. will soon be required to process CAP messages and
>> send such a tornado alert directly to their subscribers. Because these
>> more automated communications paths can be much quicker and less error-
>> prone, we look forward to deeper penetration of CAP-enabled
>> communications over time. But, multiple communications paths for
>> emergency messages will be commonplace for the foreseeable future.
>> 
>> Eliot