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

25 May 2007


      Roni,
RAS might work, but that assumes the GK is somehow able to get the CAP
message and then forward it on behalf of the upstream sender.  This is a new
use for RAS, but I can see that falling into line with some kind of
SUBSCRIBE/NOTIFY type of capability in H.323.  A GK could, for example, send
an LRQ message to an emergency broadcast center to "subscribe" to the CAP
service (acknowledge with LCF).  Then, subsequent CAP messages could be
delivered with SCI messages.  (For technical reasons, as odd as it sounds,
an LRQ would be better for initiating subscriptions that I'll explain more
fully if you're interested.)  In any case, this means we need a
subscribe/notify framework in H.323.  Interesting to consider.
As you point out, this still requires something for devices that can only
play audio.
XMPP is certainly not off the list, but the concern I have is that it's a
separate system that requires its own servers (or services), association
with the same H.323 user, etc.  I don't think that's necessarily so trivial
to do.  But, it would definitely be worth having a good discussion on this
with some ideas for how we might bring the two together. As I said, I'm a
fan of XMPP and definitely would like us to explore this further.
Paul
...
-----Original Message-----
From: Even, Roni [mailto:roni.even@polycom.co.il]
Sent: Friday, May 25, 2007 9:37 AM
To: simao.campos@itu.int; s.horne@packetizer.com;
Christian.Groves@nteczone.com; paulej@packetizer.com
Cc: itu-sg16@lists.packetizer.com
Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common
AlertingProtocol (CAP)
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@lists.packetizer.com [mailto:itu-sg16-
bounces@lists.packetizer.com] On Behalf Of simao.campos@itu.int
Sent: Friday, May 25, 2007 4:13 PM
To: s.horne@packetizer.com; Christian.Groves@nteczone.com;
paulej@packetizer.com
Cc: itu-sg16@lists.packetizer.com; echristian@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@lists.packetizer.com [mailto:itu-sg16-
bounces@lists.packetizer.com] On Behalf Of Simon Horne
Sent: 24 May 2007 03:55
To: Christian Groves; Paul E. Jones
Cc: itu-sg16@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@nteczone.com]
Sent: Tuesday, May 22, 2007 8:05 PM
To: Paul E. Jones
Cc: itu-sg16@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

Paul E. Jones

tags (0)

participants (1)