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@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
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@nteczone.com] Sent: Sunday, May 27, 2007 10:35 PM To: paulej@packetizer.com Cc: Even, Roni; simao.campos@itu.int; s.horne@packetizer.com; itu- sg16@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
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
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
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
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
field so the user's device will react in a different way to alert
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
emergency message would be delivered to the broadcast center,
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
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
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
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
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
> H.323 infrastructure so easily lends itself to such functionality. > There was a renewed hope with some documents introduced during
> 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
> within H.323 networks. I can report that, not only did they do
> 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
> 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"
> 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
Even, Roni wrote: the perform little priority the user the translated like to perspective played, a points via the the transport that, the the 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 > > >
participants (2)
-
Christian Groves -
Paul E. Jones