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

Paul E. Jones paulej at packetizer.com
Tue May 22 20:20:55 EDT 2007


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.

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.

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.

So, does that help your thinking?  Or, did I muddy the water?

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