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

[Paul E. Jones]

Eliot,

I certainly appreciate the feedback.  So, it sounds that we need something
that will carry CAP messages inside H.323, both for end user equipment to
process and also for emergency centers (e.g., NWS) to transmit to
broadcasters (e.g., Weather Channel).  The latter might be less important,
but if we can get a generic mechanism in place, then perhaps the same
mechanism might be employed for both cases.

Paul

> -----Original Message-----
> From: Eliot Christian [mailto:echristian at usgs.gov]
> Sent: Tuesday, May 29, 2007 7:29 AM
> To: Paul E. Jones; simao.campos at itu.int; Christian.Groves at nteczone.com
> Cc: itu-sg16 at lists.packetizer.com; Art Botterell; Tony Rutkowski;
> Stephen.Perschau at dhs.gov
> Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting
> Protocol (CAP)
> 
> 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
> 
>