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

Paul E. Jones paulej at packetizer.com
Mon May 28 20:32:54 EDT 2007


Christian,

Initially, I thought (and I believe Simao was thinking the same) that CAP
would be used much as you have it, but H.323 would only be a part of
Interface 3.  (If it were used on an earlier interface, then it would have
been no different than a PSTN line: at least H.323 would not be carrying
CAP.)  The thinking was that the emergency center could either place a bunch
of callers serially or in parallel, or use H.460.21 (whatever made sense).

Then most recently, I was under the impression that what folks are looking
for is to send CAP as-is over Interface 3 to the user's terminal for
rendering.  Interface 2 might be used between the gathering locations and
emergency center, too, though what the difference would be in terms of
requirements, I have no idea.

In any case, I fully agree that having a key person there to help explain
the intentions will help us tremendously as we think about this.

Paul

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves at nteczone.com]
> Sent: Sunday, May 27, 2007 10:35 PM
> To: paulej at packetizer.com
> Cc: Even, Roni; simao.campos at itu.int; s.horne at packetizer.com; itu-
> sg16 at lists.packetizer.com
> Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common
> AlertingProtocol (CAP)
> 
> G'Day Paul,
> 
> I think Roni's suggestion of a requirement and architecture document as
> a first step is a good one. Simao's questions are also relevant.
> 
> For me there seems to be several "users" of this CAP information each
> having different requirements and perhaps needing different solutions.
> To me the basic functions are: a collection of information phase,
> correlation of this information and then an information sharing phase.
> E.g. a very simplified view:
> 
> [Information
>  Gatherer #1]  <-----1--+                                         +-->
> End User 1
>                         |                                         |
> [Information   <--------+---->[Information <---2--->[Emergency--3-+-->
> End User 2
>  Gatherer #2]                 aggregation            Centre]      |
>                               centre]                             |
> 
> +-->End User 3
> 
> On interface 1 the Information gatherer may use any type of
> communication. E.g. text message, radio message, PSTN and H.323 as an
> option. What is the assumption on CAP? Would it be used on this
> interface? Would it be a partial CAP? How would H.323 be used in this
> role? Are existing capabilities enough?
> 
> At the Information aggregation point(s) I assume there is a
> co-ordination centre that takes information from various sources and
> actually creates a CAP description.
> 
> On interface 2 the CAP protocol communicated between the Inf.
> Aggregation Centre and the emergency centre. Again there may be several
> methods to do this. One way is H.323. I think this has been the focus
> of
> your additions.
> 
> At the Emergency centre this CAP protocol description is then used to
> generate warnings/information to the end users (public) over interface
> 3. Again this could be using various methods. Again one of which may be
> H.323. Again is using CAP appropriate here?
> 
> I think having Eliot being part of the discussions will help us come up
> with an architecture and use the right terminology (I'm sure I'm not
> using the right terms) where we be talking about the same functions and
> requirements.
> 
> Regards, Christian
> 
> Even, Roni wrote:
> > Hi,
> > I am not too familiar with the requirements but from what I saw so
> far on the list it looks to me that this is some sort of a message that
> must be displayed or played to the user without relation to a specific
> call.
> > I assume that it should not require too much from the EP in term of
> supported functionality.
> > An H.323 EP who is not registered to a GK is not known in the
> network. If registered to a GK it can get RAS messages without being in
> a call or even during the call. So to me the logical place for such an
> alert will be in RAS.
> > As for audio announcement, this will require a call from an
> announcement server to the user but this does not scale.
> >
> > I think that before jumping to a solution, there need to be a
> requirement and architecture document.
> > I also noticed the XMPP solution which may be another direction for a
> solution since XMPP does also include registration to a presence
> server, but it also does not address voice messages, not through
> content indirection.
> >
> > Roni
> >
> >
> >> -----Original Message-----
> >> From: itu-sg16-bounces at lists.packetizer.com [mailto:itu-sg16-
> >> bounces at lists.packetizer.com] On Behalf Of simao.campos at itu.int
> >> Sent: Friday, May 25, 2007 4:13 PM
> >> To: s.horne at packetizer.com; Christian.Groves at nteczone.com;
> >> paulej at packetizer.com
> >> Cc: itu-sg16 at lists.packetizer.com; echristian at usgs.gov
> >> Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common
> >> AlertingProtocol (CAP)
> >>
> >> All,
> >>
> >> Becareful as SMS are bound to create system overload/congestions and
> >> mechanisms akin to cell broadcast would be more scalable. While in
> the
> >> mobile industry there is a somewhat heated debate on the support of
> cell
> >> broadcast, there is no reason why we don't do it right from the
> start here
> >> [If we can just figure out what "right" means :-) ]
> >>
> >> I see the delivery of CAP alerts (which can be at various levels:
> >> authority to authority, authority to citizen but also citizen to
> citizen)
> >> as a multi-faceted issue and not necessarily one tied only to IM in
> H.323,
> >> as this should not exclude H.460.21 message broadcast's
> functionality. The
> >> H.450.7 approach seems part of the solution, even though (correct me
> if I
> >> am mistaken) it would only cover the sinalization that there is an
> urgent
> >> message, not what the message is (basically telling the users to "go
> and
> >> fetch it").
> >>
> >> One aspect we need to be aware is that a CAP message can be
> multilingual
> >> and contain a URI to some other content, e.g. a recorded message.
> >>
> >> Opening a different can of worms: in the architecture, it is not
> clear to
> >> me who is the gateway for the incoming CAP messages and be able to
> perform
> >> some content translations. For example, beyond the XML to ASN.1
> >> conversion, to do a text-to-speech for audio-only H.323 terminals
> for
> >> delivery of the warning. Or, a distribution node near the end
> delivery
> >> point can perform a de-referencing of an URI inside the CAP message
> to an
> >> A/V content (e.g. for a digital TV distribution).
> >>
> >> I find this development really exciting and seems that if we do a
> good
> >> work here we will get a lot of attention for H.323 also in
> developing
> >> countries as public warning / disaster response is a very hot topic
> today.
> >>
> >> Please do not see this as a discouragement to work on IM, I believe
> as
> >> Paul that this is necessary for H.323's continuation as a
> >>
> >> Cheers,
> >> Simão
> >>
> >> -----Original Message-----
> >> From: itu-sg16-bounces at lists.packetizer.com [mailto:itu-sg16-
> >> bounces at lists.packetizer.com] On Behalf Of Simon Horne
> >> Sent: 24 May 2007 03:55
> >> To: Christian Groves; Paul E. Jones
> >> Cc: itu-sg16 at lists.packetizer.com
> >> Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common Alerting
> >> Protocol (CAP)
> >>
> >>
> >> Hi
> >>
> >> Just like to chime in, as the author of the Text Messaging proposal
> for
> >> H.323.
> >>
> >> How would we do CAP in the real world (outside VoIP or the internet)
> ?
> >> The easiest and most efficient method is to broadcast an SMS on the
> mobile
> >> phone to everyone. That is exactly what is being used in Indonesia
> today
> >> to advise the citizens of impending trouble. They have used it
> several
> >> times over the last couple of years with some success (luckily with
> little
> >> fatalities). SMS really works for this type of thing.
> >>
> >> The short messaging outside the context of a call (can also be done
> in a
> >> call) in the IM proposal for H.323 has exactly the same function as
> SMS. A
> >> message is sent (using a lightweight call setup) and appears on the
> users
> >> computer or hardware device. It is very simple and efficient as it
> doesn't
> >> need to establish any media streams. We can assign CAP messages a
> priority
> >> field so the user's device will react in a different way to alert
> the user
> >> this is an important message.
> >>
> >> Simon
> >>
> >> At 08:50 AM 24/05/2007, Christian Groves wrote:
> >>
> >>> G'Day Paul,
> >>>
> >>> Please my comments below CNG.
> >>>
> >>> As an aside, do you know if there's any work in the IETF around
> CAP?
> >>>
> >>> Regards, Christian
> >>>
> >>> Paul E. Jones wrote:
> >>>
> >>>> Christian,
> >>>>
> >>>> We already do have a means in H.323 doing a wide-spread "message
> >>>>
> >> broadcast"
> >>
> >>>> in H.323 (H.460.21), which would accommodate recorded messages
> (audio,
> >>>> video, or real-time text).  My initial thinking for CAP was that
> the
> >>>> emergency message would be delivered to the broadcast center,
> translated
> >>>>
> >>> >from CAP into one of the above mentioned forms, and then broadcast
> via
> >>>
> >>>> H.460.21 to the H.323 terminals within range.
> >>>>
> >>>>
> >>> [CNG] I know we have this capacity that's why I think it would be
> >>> worthwhile to describe in a Annex/Appendix titled something like
> "CAP
> >>> usage in H.323 systems".
> >>>
> >>>> However, it seems that another request is to use H.323 in order to
> >>>>
> >> actually
> >>
> >>>> transmit the CAP message as-is between communicating H.323
> devices.
> >>>>
> >> Perhaps
> >>
> >>>> this might only be used between broadcast centers, or perhaps it
> might
> >>>>
> >> be
> >>
> >>>> the form of communication sent to all terminals (as opposed to
> sending
> >>>>
> >> the
> >>
> >>>> audio/video/text stream).  In any case, the request before us is
> to
> >>>>
> >> define a
> >>
> >>>> means of conveying CAP messages between H.323 terminals.
> >>>>
> >>>>
> >>> [CNG] With regards to the request, are you referring to a liaison
> or a
> >>> request by some end user? At least for me it would be good to have
> a
> >>> submission by an end user into this discussion. Do you know anybody
> (or
> >>> anybody on the list) who would be using or implementing this
> service?
> >>> Having their input would help the discussion in SG16.
> >>>
> >>>
> >>>> So, the question then is "how"?  Do we use an IM mechanism that is
> >>>>
> >> capable
> >>
> >>>> of delivering any kind of "text" (including human-entered, CAP
> message,
> >>>>
> >> a
> >>
> >>>> emoticon, a sound bit, or other), or do we create something
> special just
> >>>>
> >> for
> >>
> >>>> CAP?  I would prefer to avoid the latter, personally.
> >>>>
> >>>>
> >>> [CNG] I'm usually for "generic" type mechanisms that can be re-
> used. From
> >>> the other emails from what I'm reading is that why re-
> invent/implement
> >>> something where there's an existing solution.
> >>>
> >>>> So, does that help your thinking?  Or, did I muddy the water?
> >>>>
> >>>>
> >>> [CNG] I agree with you on the 2 usages of the CAP as you described
> above.
> >>> Given that CAP could be a rather important tool in the future I'd
> like to
> >>> see that whatever solution we chose meets the requirements of those
> using
> >>> it. That's why I think it would be good to have an end user
> perspective
> >>>
> >> of it.
> >>
> >>>> Paul
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Christian Groves [mailto:Christian.Groves at nteczone.com]
> >>>>> Sent: Tuesday, May 22, 2007 8:05 PM
> >>>>> To: Paul E. Jones
> >>>>> Cc: itu-sg16 at lists.packetizer.com
> >>>>> Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common
> Alerting
> >>>>> Protocol (CAP)
> >>>>>
> >>>>> G'Day Paul,
> >>>>>
> >>>>> Before drawing a conclusion that sending IMs within a the context
> of a
> >>>>> call is the answer for CAP should we perhaps look at the
> requirements
> >>>>> that are implied by CAP? From my reading of CAP the ASN.1 is a
> >>>>> description of the information that is associated with the
> emergency.
> >>>>> This information is used by emergency agencies to take action. As
> a
> >>>>> result of this information various actions can be triggered
> across
> >>>>> communications networks. E.g. phones rung and an announcement
> played, a
> >>>>> guy on a motorbike sent out to scream "run for your lives". If we
> look
> >>>>> at the information in the CAP perhaps the ASN.1 description of
> CAP
> >>>>> maybe
> >>>>> more effectively rendered for use by emergency by a web type
> interface
> >>>>> that shows the co-ordinates from the ASN.1 in a graphical format.
> So
> >>>>> perhaps there is a need for an IM to say "Emergency look at URL
> xxx for
> >>>>> CAP" but does this necessarily have to be H.323 based?
> >>>>>
> >>>>> In terms of H.323 I see some sort of multi-cast announcement
> service
> >>>>> where elements of the CAP information are sent to H.323 end
> points via
> >>>>> audio, video, stills, text and how this relates to priority
> handling is
> >>>>> something that would be more appropriate to describe.
> >>>>>
> >>>>> I don't have any particular objection if someone wants to start
> work on
> >>>>> IM in H.323 but I'm not sure that CAP alone justifies it.
> >>>>>
> >>>>> Regards, Christian
> >>>>>
> >>>>> Paul E. Jones wrote:
> >>>>>
> >>>>>
> >>>>>> Folks,
> >>>>>>
> >>>>>> We have debated the introduction of a method of sending IMs
> within
> >>>>>> H.323 for years. It's unfortunate, especially considering how
> the
> >>>>>> H.323 infrastructure so easily lends itself to such
> functionality.
> >>>>>> There was a renewed hope with some documents introduced during
> the
> >>>>>> Shenzhen meeting that suggested a means of sending IM within the
> >>>>>> context of a call, as well as outside the context of a call.
> >>>>>>
> >>>>>> One of the other matters we were asked to consider within the
> context
> >>>>>> of H.323 and H.248 is the transmission of emergency messages
> using a
> >>>>>> format called the "Common Alerting Protocol". During the
> Shenzhen
> >>>>>> meeting, we sent a liaison to SG17 urging them to consider the
> >>>>>> creation of an ASN.1 specification that would more readily
> transport
> >>>>>> within H.323 networks. I can report that, not only did they do
> that,
> >>>>>> it has been put forward for consent already. The standard will
> be
> >>>>>>
> >>>>>>
> >>>>> X.1303.
> >>>>>
> >>>>>
> >>>>>> So, the next step is to define procedures for transporting
> X.1303
> >>>>>> (CAP) messages within H.323. Initially, I considered creating an
> >>>>>> H.460.x extension, but then I thought that a better solution
> might be
> >>>>>> to use something like H.450.7 (Message Waiting Indicator). But,
> as I
> >>>>>> thought about this, perhaps the best way is to marry this with
> the
> >>>>>> Instant Messaging proposals we've seen before.
> >>>>>>
> >>>>>> If we were to standardize the ability to send instant messages
> within
> >>>>>> H.323, both within and outside the context of a call, then it
> would
> >>>>>>
> >>>>>>
> >>>>> be
> >>>>>
> >>>>>
> >>>>>> possible to send X.1303 messages as an "instant message". This
> does
> >>>>>> introduce a new requirement, though, in that we ought to "tag"
> the
> >>>>>> type of message so that it is properly treated. Instant Messages
> >>>>>>
> >>>>>>
> >>>>> might
> >>>>>
> >>>>>
> >>>>>> appear unprocessed on the user's screen, whereas X.1303 messages
> must
> >>>>>> be decoded and formatted for human readability.
> >>>>>>
> >>>>>> So, I would like to draft a proposal for this upcoming SG16
> meeting
> >>>>>>
> >>>>>>
> >>>>> to
> >>>>>
> >>>>>
> >>>>>> do precisely what I said: let's move forward on the work of
> sending
> >>>>>>
> >>>>>>
> >>>>> IM
> >>>>>
> >>>>>
> >>>>>> messages within H.323, adding a tag that indicates the type of
> >>>>>> message. We can also utilize the call priority procedures in
> H.460.4
> >>>>>> in order to ensure that an emergency CAP message gets higher
> priority
> >>>>>> through the network.
> >>>>>>
> >>>>>> Does this sound reasonable and acceptable? Do others have other
> >>>>>>
> >>>>>>
> >>>>> proposals?
> >>>>>
> >>>>>
> >>>>>> If it is acceptable, then I have a question of procedure. The
> >>>>>> proposals for instant messaging were /not/ accepted as new work
> items
> >>>>>> for Q2, though they were not rejected: the request was for
> further
> >>>>>> progress. Unfortunately, the contributor is not a member of the
> ITU,
> >>>>>> which leaves us in a difficult situation. As a possible means
> forward
> >>>>>> somebody might volunteer to submit these documents as formal
> >>>>>> contributions to this SG16 meeting under their company's name.
> Is
> >>>>>>
> >>>>>>
> >>>>> that
> >>>>>
> >>>>>
> >>>>>> agreeable and are there any volunteers?
> >>>>>>
> >>>>>> Do you have another idea for how we can support X.1303 (CAP)?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Paul
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >
> >
> >
> >
> 








More information about the sg16-avd mailing list