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

[Christian Groves]

Hello Eliot,

Thanks for the clarifications. Do you know of (or have a reference to) 
any architecture or requirements documents regarding CAP and public 
warning communications that have been produced in other groups that 
people could read as a background for discussion in SG16?

Regards, Christian

Eliot Christian wrote:
> 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
>>>       
>
>
>
>
>