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@usgs.gov] Sent: Monday, May 28, 2007 9:56 AM To: simao.campos@itu.int; paulej@packetizer.com; s.horne@packetizer.com; Christian.Groves@nteczone.com Cc: itu-sg16@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

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@usgs.gov] Sent: Monday, May 28, 2007 9:56 AM To: simao.campos@itu.int; paulej@packetizer.com; s.horne@packetizer.com; Christian.Groves@nteczone.com Cc: itu-sg16@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