[itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)
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 et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 - Text chat in data conferencing T.140 - Protocol for multimedia application text conversation V.18 - Text telephony Best Regards, Gary Sullivan ________________________________ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) 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
Gary, T.134 is an application protocol entity for sending text messages within the context of a T.120 conference. So, it's not usable within H.323. T.140 is a character presentation format and is used by H.323 Annex G for delivering real-time text. However, real-time text and Instant Message are not the same (so I'm getting closer to answering your question). V.18 is a protocol for sending text over a PSTN circuit using modulated signals (modem), so that's far away from what we're doing in H.323 (or IP networks in general). So what is the difference between H.323 Annex G (real-time text) and Instant Messaging? The difference is how messages are composed, transmitted, and delivered. With H.323 Annex G, characters are collected and transmitted as they are entered by the user and then displayed on the remote device "character at a time" (or as close to that as possible). With Instant Messaging (IM), entire sentences or paragraphs are entered and then transmitted as a single message block. The latter is what we see with MSN Messenger, Yahoo Messenger, Sametime, Jabber / XMPP / Google Talk, AIM, and other similar clients. The desire that has been expressed since at least 2000 is to support some form of IM in H.323. We've had several proposals and nothing has moved forward beyond the initial presentation (or at most the second meeting). I never understood why, but now we have a situation where we're being asked to deliver what is essentially a "text message". If we have an IM protocol in place, it would become trivial to deliver that capability. Thus, I'd like to see hastened forward progress on the IM work we've been debating for so many years. I hope that helps. Paul From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Tuesday, May 22, 2007 4:14 PM To: Paul E. Jones; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) Paul et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 - Text chat in data conferencing T.140 - Protocol for multimedia application text conversation V.18 - Text telephony Best Regards, Gary Sullivan _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) 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, I understand the request for emergency message protocol but I am wondering if it will help to have it as part of a general H.323 IM protocol or as a standalone solution. My concern is that we have not succeeded in defining a general IM protocol for H.323 was probably because of lack of real market requirements and trying to define it now may cause us to define an IM solution which is not optimal ( and difficult to interact with XMPP and SIMPLE based IM solutions) while the only real requirement is for the emergency message protocol. Roni Even ________________________________ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 11:36 PM To: 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Gary, T.134 is an application protocol entity for sending text messages within the context of a T.120 conference. So, it's not usable within H.323. T.140 is a character presentation format and is used by H.323 Annex G for delivering real-time text. However, real-time text and Instant Message are not the same (so I'm getting closer to answering your question). V.18 is a protocol for sending text over a PSTN circuit using modulated signals (modem), so that's far away from what we're doing in H.323 (or IP networks in general). So what is the difference between H.323 Annex G (real-time text) and Instant Messaging? The difference is how messages are composed, transmitted, and delivered. With H.323 Annex G, characters are collected and transmitted as they are entered by the user and then displayed on the remote device "character at a time" (or as close to that as possible). With Instant Messaging (IM), entire sentences or paragraphs are entered and then transmitted as a single message block. The latter is what we see with MSN Messenger, Yahoo Messenger, Sametime, Jabber / XMPP / Google Talk, AIM, and other similar clients. The desire that has been expressed since at least 2000 is to support some form of IM in H.323. We've had several proposals and nothing has moved forward beyond the initial presentation (or at most the second meeting). I never understood why, but now we have a situation where we're being asked to deliver what is essentially a "text message". If we have an IM protocol in place, it would become trivial to deliver that capability. Thus, I'd like to see hastened forward progress on the IM work we've been debating for so many years. I hope that helps. Paul From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Tuesday, May 22, 2007 4:14 PM To: Paul E. Jones; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) Paul et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 - Text chat in data conferencing T.140 - Protocol for multimedia application text conversation V.18 - Text telephony Best Regards, Gary Sullivan ________________________________ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) 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
Roni, I believe there is an interest in the market. I've been asked many times over the years, we've seen many proposals, etc., but inevitably somebody kills every proposal before we are able to make any real progress. I will argue that, yes, we need IM within H.323. Does it need to interoperate with SIMPLE or XMPP? Not directly: that's what an SBC can handle for us, just as it does everything else. Do we want to make it as interoperable as possible? No objections: we're not consenting text at this meeting and we have time to work out issues. The way I view it, we need something. I've seen people doing things ranging from using the user-data field to nonStandardData field, to H.460.x-style extensions. I'd prefer to start with something and then we solicit contributions and comments against it. I really want forward progress on this long-standing open work item. Paul From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, May 22, 2007 4:56 PM To: Paul E. Jones; Gary Sullivan; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Paul, I understand the request for emergency message protocol but I am wondering if it will help to have it as part of a general H.323 IM protocol or as a standalone solution. My concern is that we have not succeeded in defining a general IM protocol for H.323 was probably because of lack of real market requirements and trying to define it now may cause us to define an IM solution which is not optimal ( and difficult to interact with XMPP and SIMPLE based IM solutions) while the only real requirement is for the emergency message protocol. Roni Even _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 11:36 PM To: 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Gary, T.134 is an application protocol entity for sending text messages within the context of a T.120 conference. So, it's not usable within H.323. T.140 is a character presentation format and is used by H.323 Annex G for delivering real-time text. However, real-time text and Instant Message are not the same (so I'm getting closer to answering your question). V.18 is a protocol for sending text over a PSTN circuit using modulated signals (modem), so that's far away from what we're doing in H.323 (or IP networks in general). So what is the difference between H.323 Annex G (real-time text) and Instant Messaging? The difference is how messages are composed, transmitted, and delivered. With H.323 Annex G, characters are collected and transmitted as they are entered by the user and then displayed on the remote device "character at a time" (or as close to that as possible). With Instant Messaging (IM), entire sentences or paragraphs are entered and then transmitted as a single message block. The latter is what we see with MSN Messenger, Yahoo Messenger, Sametime, Jabber / XMPP / Google Talk, AIM, and other similar clients. The desire that has been expressed since at least 2000 is to support some form of IM in H.323. We've had several proposals and nothing has moved forward beyond the initial presentation (or at most the second meeting). I never understood why, but now we have a situation where we're being asked to deliver what is essentially a "text message". If we have an IM protocol in place, it would become trivial to deliver that capability. Thus, I'd like to see hastened forward progress on the IM work we've been debating for so many years. I hope that helps. Paul From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Tuesday, May 22, 2007 4:14 PM To: Paul E. Jones; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) Paul et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 - Text chat in data conferencing T.140 - Protocol for multimedia application text conversation V.18 - Text telephony Best Regards, Gary Sullivan _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) 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
Another appoach would be to use XMPP and/or SIMPLE directly (as a separate session). You would bootstrap the XMPP session from the H.323 session by each side providing the URI for the IM. There are a number of clients out there that use SIP for voice/video session setup but XMPP for IM. The same could be done with H.323. ________________________________ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 14:48 To: 'Even, Roni'; 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Roni, I believe there is an interest in the market. I've been asked many times over the years, we've seen many proposals, etc., but inevitably somebody kills every proposal before we are able to make any real progress. I will argue that, yes, we need IM within H.323. Does it need to interoperate with SIMPLE or XMPP? Not directly: that's what an SBC can handle for us, just as it does everything else. Do we want to make it as interoperable as possible? No objections: we're not consenting text at this meeting and we have time to work out issues. The way I view it, we need something. I've seen people doing things ranging from using the user-data field to nonStandardData field, to H.460.x-style extensions. I'd prefer to start with something and then we solicit contributions and comments against it. I really want forward progress on this long-standing open work item. Paul From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, May 22, 2007 4:56 PM To: Paul E. Jones; Gary Sullivan; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Paul, I understand the request for emergency message protocol but I am wondering if it will help to have it as part of a general H.323 IM protocol or as a standalone solution. My concern is that we have not succeeded in defining a general IM protocol for H.323 was probably because of lack of real market requirements and trying to define it now may cause us to define an IM solution which is not optimal ( and difficult to interact with XMPP and SIMPLE based IM solutions) while the only real requirement is for the emergency message protocol. Roni Even ________________________________ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 11:36 PM To: 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Gary, T.134 is an application protocol entity for sending text messages within the context of a T.120 conference. So, it's not usable within H.323. T.140 is a character presentation format and is used by H.323 Annex G for delivering real-time text. However, real-time text and Instant Message are not the same (so I'm getting closer to answering your question). V.18 is a protocol for sending text over a PSTN circuit using modulated signals (modem), so that's far away from what we're doing in H.323 (or IP networks in general). So what is the difference between H.323 Annex G (real-time text) and Instant Messaging? The difference is how messages are composed, transmitted, and delivered. With H.323 Annex G, characters are collected and transmitted as they are entered by the user and then displayed on the remote device "character at a time" (or as close to that as possible). With Instant Messaging (IM), entire sentences or paragraphs are entered and then transmitted as a single message block. The latter is what we see with MSN Messenger, Yahoo Messenger, Sametime, Jabber / XMPP / Google Talk, AIM, and other similar clients. The desire that has been expressed since at least 2000 is to support some form of IM in H.323. We've had several proposals and nothing has moved forward beyond the initial presentation (or at most the second meeting). I never understood why, but now we have a situation where we're being asked to deliver what is essentially a "text message". If we have an IM protocol in place, it would become trivial to deliver that capability. Thus, I'd like to see hastened forward progress on the IM work we've been debating for so many years. I hope that helps. Paul From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Tuesday, May 22, 2007 4:14 PM To: Paul E. Jones; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) Paul et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 - Text chat in data conferencing T.140 - Protocol for multimedia application text conversation V.18 - Text telephony Best Regards, Gary Sullivan ________________________________ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) 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
Francois, That's precisely what Paul Reddy (Intel) had proposed back in 2000. Doing that increases the complexity for the user, as they then have to be logged into two different networks. It also means we need to define an interface between the XMPP client and the H.323 endpoint. In theory, it would work quite well. (I use XMPP and it impresses me how we are able to have a completely federated IM system. it's probably one of the world's best-kept secrets, in spite of Jabber's very hard work trying to enlighten the world.) I have no objection to that if that's what we want to do to deliver IM functionality, but if we do that then we definitely need to consider CAP separately, as the requirement we have is to send CAP messages to H.323 devices. So, do we want to reconsider XMPP/H.323 association? You know, Jungle was created precisely because marrying SIP and XMPP was viewed as complicated. (Perhaps that and the fact that the SIP WG wanted to have native methods and would consider no less.) Paul From: Francois Audet [mailto:audet@nortel.com] Sent: Tuesday, May 22, 2007 6:04 PM To: Paul E. Jones; Even, Roni; Gary Sullivan; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Another appoach would be to use XMPP and/or SIMPLE directly (as a separate session). You would bootstrap the XMPP session from the H.323 session by each side providing the URI for the IM. There are a number of clients out there that use SIP for voice/video session setup but XMPP for IM. The same could be done with H.323. _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 14:48 To: 'Even, Roni'; 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Roni, I believe there is an interest in the market. I've been asked many times over the years, we've seen many proposals, etc., but inevitably somebody kills every proposal before we are able to make any real progress. I will argue that, yes, we need IM within H.323. Does it need to interoperate with SIMPLE or XMPP? Not directly: that's what an SBC can handle for us, just as it does everything else. Do we want to make it as interoperable as possible? No objections: we're not consenting text at this meeting and we have time to work out issues. The way I view it, we need something. I've seen people doing things ranging from using the user-data field to nonStandardData field, to H.460.x-style extensions. I'd prefer to start with something and then we solicit contributions and comments against it. I really want forward progress on this long-standing open work item. Paul From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, May 22, 2007 4:56 PM To: Paul E. Jones; Gary Sullivan; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Paul, I understand the request for emergency message protocol but I am wondering if it will help to have it as part of a general H.323 IM protocol or as a standalone solution. My concern is that we have not succeeded in defining a general IM protocol for H.323 was probably because of lack of real market requirements and trying to define it now may cause us to define an IM solution which is not optimal ( and difficult to interact with XMPP and SIMPLE based IM solutions) while the only real requirement is for the emergency message protocol. Roni Even _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 11:36 PM To: 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Gary, T.134 is an application protocol entity for sending text messages within the context of a T.120 conference. So, it's not usable within H.323. T.140 is a character presentation format and is used by H.323 Annex G for delivering real-time text. However, real-time text and Instant Message are not the same (so I'm getting closer to answering your question). V.18 is a protocol for sending text over a PSTN circuit using modulated signals (modem), so that's far away from what we're doing in H.323 (or IP networks in general). So what is the difference between H.323 Annex G (real-time text) and Instant Messaging? The difference is how messages are composed, transmitted, and delivered. With H.323 Annex G, characters are collected and transmitted as they are entered by the user and then displayed on the remote device "character at a time" (or as close to that as possible). With Instant Messaging (IM), entire sentences or paragraphs are entered and then transmitted as a single message block. The latter is what we see with MSN Messenger, Yahoo Messenger, Sametime, Jabber / XMPP / Google Talk, AIM, and other similar clients. The desire that has been expressed since at least 2000 is to support some form of IM in H.323. We've had several proposals and nothing has moved forward beyond the initial presentation (or at most the second meeting). I never understood why, but now we have a situation where we're being asked to deliver what is essentially a "text message". If we have an IM protocol in place, it would become trivial to deliver that capability. Thus, I'd like to see hastened forward progress on the IM work we've been debating for so many years. I hope that helps. Paul From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Tuesday, May 22, 2007 4:14 PM To: Paul E. Jones; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) Paul et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 - Text chat in data conferencing T.140 - Protocol for multimedia application text conversation V.18 - Text telephony Best Regards, Gary Sullivan _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) 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
Jungle should have been "Jingle" :-) Perhaps it is a Jungle. I don't know. Paul From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 6:18 PM To: 'Francois Audet'; 'Even, Roni'; 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Francois, That's precisely what Paul Reddy (Intel) had proposed back in 2000. Doing that increases the complexity for the user, as they then have to be logged into two different networks. It also means we need to define an interface between the XMPP client and the H.323 endpoint. In theory, it would work quite well. (I use XMPP and it impresses me how we are able to have a completely federated IM system. it's probably one of the world's best-kept secrets, in spite of Jabber's very hard work trying to enlighten the world.) I have no objection to that if that's what we want to do to deliver IM functionality, but if we do that then we definitely need to consider CAP separately, as the requirement we have is to send CAP messages to H.323 devices. So, do we want to reconsider XMPP/H.323 association? You know, Jungle was created precisely because marrying SIP and XMPP was viewed as complicated. (Perhaps that and the fact that the SIP WG wanted to have native methods and would consider no less.) Paul From: Francois Audet [mailto:audet@nortel.com] Sent: Tuesday, May 22, 2007 6:04 PM To: Paul E. Jones; Even, Roni; Gary Sullivan; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Another appoach would be to use XMPP and/or SIMPLE directly (as a separate session). You would bootstrap the XMPP session from the H.323 session by each side providing the URI for the IM. There are a number of clients out there that use SIP for voice/video session setup but XMPP for IM. The same could be done with H.323. _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 14:48 To: 'Even, Roni'; 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Roni, I believe there is an interest in the market. I've been asked many times over the years, we've seen many proposals, etc., but inevitably somebody kills every proposal before we are able to make any real progress. I will argue that, yes, we need IM within H.323. Does it need to interoperate with SIMPLE or XMPP? Not directly: that's what an SBC can handle for us, just as it does everything else. Do we want to make it as interoperable as possible? No objections: we're not consenting text at this meeting and we have time to work out issues. The way I view it, we need something. I've seen people doing things ranging from using the user-data field to nonStandardData field, to H.460.x-style extensions. I'd prefer to start with something and then we solicit contributions and comments against it. I really want forward progress on this long-standing open work item. Paul From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, May 22, 2007 4:56 PM To: Paul E. Jones; Gary Sullivan; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Paul, I understand the request for emergency message protocol but I am wondering if it will help to have it as part of a general H.323 IM protocol or as a standalone solution. My concern is that we have not succeeded in defining a general IM protocol for H.323 was probably because of lack of real market requirements and trying to define it now may cause us to define an IM solution which is not optimal ( and difficult to interact with XMPP and SIMPLE based IM solutions) while the only real requirement is for the emergency message protocol. Roni Even _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Tuesday, May 22, 2007 11:36 PM To: 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Gary, T.134 is an application protocol entity for sending text messages within the context of a T.120 conference. So, it's not usable within H.323. T.140 is a character presentation format and is used by H.323 Annex G for delivering real-time text. However, real-time text and Instant Message are not the same (so I'm getting closer to answering your question). V.18 is a protocol for sending text over a PSTN circuit using modulated signals (modem), so that's far away from what we're doing in H.323 (or IP networks in general). So what is the difference between H.323 Annex G (real-time text) and Instant Messaging? The difference is how messages are composed, transmitted, and delivered. With H.323 Annex G, characters are collected and transmitted as they are entered by the user and then displayed on the remote device "character at a time" (or as close to that as possible). With Instant Messaging (IM), entire sentences or paragraphs are entered and then transmitted as a single message block. The latter is what we see with MSN Messenger, Yahoo Messenger, Sametime, Jabber / XMPP / Google Talk, AIM, and other similar clients. The desire that has been expressed since at least 2000 is to support some form of IM in H.323. We've had several proposals and nothing has moved forward beyond the initial presentation (or at most the second meeting). I never understood why, but now we have a situation where we're being asked to deliver what is essentially a "text message". If we have an IM protocol in place, it would become trivial to deliver that capability. Thus, I'd like to see hastened forward progress on the IM work we've been debating for so many years. I hope that helps. Paul From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Tuesday, May 22, 2007 4:14 PM To: Paul E. Jones; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) Paul et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 - Text chat in data conferencing T.140 - Protocol for multimedia application text conversation V.18 - Text telephony Best Regards, Gary Sullivan _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) 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, I work for the Welsh Video Network in the UK, supporting a large distance learning and educational user group that uses H.323 VC endpoints. While it may be off-topic for this mail-group (and I apologise for that), I would be interested to know what sort of usage scenarios you envisage, as we are pro-active in seeking feedback on the service but I have not heard this as a user requirement before. We have networked Data PC's in all VC studios and have used parrallel (data only) NetMeeting text tool sessions to exchange control and chair messages during large videoconferences. Our requirement there is that the VC end-user does not see them. These are used by the session's technical support personel. We have also piloted server-based networked "hand-raising" software for queing attempts to catch the chair-person's eye, or indicating to the chair that your site wishes to have the floor (sometimes difficult in large voice-switched sessions). Is this the kind of thing you have in mind? thank you, Geoff Constable www.wvn.ac.uk ................................ Paul E. Jones wrote:
Roni,
I believe there is an interest in the market. I’ve been asked many times over the years, we’ve seen many proposals, etc., but inevitably somebody kills every proposal before we are able to make any real progress. I will argue that, yes, we need IM within H.323.
Hi, I assume the VC endpoints are room system appliances that do not have keyboard and you are using a separate PC for the netmeeting chat. Is this a point to point session or do you want the users to be able to chat in a side conference. If this is your scenario than using a Jabber (XMPP) based chat session will work. Currently Paul is talking about adding instant message to the VC user H.323 session for point to point calls or in the case of multipoint to use some bridge to do multi unicast to all users. Roni Even
-----Original Message----- From: Geoff Constable [mailto:ccc@aber.ac.uk] Sent: Wednesday, May 23, 2007 3:54 PM To: Paul E. Jones Cc: Even, Roni; 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP)
Paul, I work for the Welsh Video Network in the UK, supporting a large distance learning and educational user group that uses H.323 VC endpoints. While it may be off-topic for this mail-group (and I apologise for that), I would be interested to know what sort of usage scenarios you envisage, as we are pro-active in seeking feedback on the service but I have not heard this as a user requirement before.
We have networked Data PC's in all VC studios and have used parrallel (data only) NetMeeting text tool sessions to exchange control and chair messages during large videoconferences. Our requirement there is that the VC end-user does not see them. These are used by the session's technical support personel.
We have also piloted server-based networked "hand-raising" software for queing attempts to catch the chair-person's eye, or indicating to the chair that your site wishes to have the floor (sometimes difficult in large voice-switched sessions).
Is this the kind of thing you have in mind?
thank you,
Geoff Constable www.wvn.ac.uk ................................ Paul E. Jones wrote:
Roni,
I believe there is an interest in the market. I’ve been asked many times over the years, we’ve seen many proposals, etc., but inevitably somebody kills every proposal before we are able to make any real progress. I will argue that, yes, we need IM within H.323.
Geoff, This is not precisely what I've seen as the usage of IM messages. Essentially, what I've seen requested are two things: 1) To be able to call a person point-to-point and send an IM as part of the conversation to convey textual information (e.g., "Here's the address to Jane's house: ....") 2) To be able to do the same kind of thing outside the context of a call, similar to what SMS systems do for GSM (except that messages are delivered instantly, rather than queued by a message server) Multipoint conferencing raises some questions in my mind, but I think the protocol would be the same. For such an environment, would we want to send an IM message to all participants or to a single participant? Since it's IP, it is actually very easy to establish a new "call" to send IM directly to a particular participant, so perhaps any IM sent into a conference would be seen by all conference participants (like a "chat room"). This places a requirement on the MC to receive any such messages and then forward them to all other conference participants. But, perhaps there is a desire to have the MC process the message and make some intelligent decision as to how to treat the message. Perhaps there is a desire to allow any one user to send a message to any other single user via the MC? Honestly, I've just not explored the use cases in multipoint VC environments, nor have I heard a request for this capability. But, it seems interesting, nonetheless. Paul
-----Original Message----- From: Geoff Constable [mailto:ccc@aber.ac.uk] Sent: Wednesday, May 23, 2007 8:54 AM To: Paul E. Jones Cc: 'Even, Roni'; 'Gary Sullivan'; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP)
Paul, I work for the Welsh Video Network in the UK, supporting a large distance learning and educational user group that uses H.323 VC endpoints. While it may be off-topic for this mail-group (and I apologise for that), I would be interested to know what sort of usage scenarios you envisage, as we are pro-active in seeking feedback on the service but I have not heard this as a user requirement before.
We have networked Data PC's in all VC studios and have used parrallel (data only) NetMeeting text tool sessions to exchange control and chair messages during large videoconferences. Our requirement there is that the VC end-user does not see them. These are used by the session's technical support personel.
We have also piloted server-based networked "hand-raising" software for queing attempts to catch the chair-person's eye, or indicating to the chair that your site wishes to have the floor (sometimes difficult in large voice-switched sessions).
Is this the kind of thing you have in mind?
thank you,
Geoff Constable www.wvn.ac.uk ................................ Paul E. Jones wrote:
Roni,
I believe there is an interest in the market. I've been asked many times over the years, we've seen many proposals, etc., but inevitably somebody kills every proposal before we are able to make any real progress. I will argue that, yes, we need IM within H.323.
What we called text chat in T.120 is nowadays called real-time text. It is text used mainly for conversation. Sent time-sampled in e.g. 300 ms sample intervals, so that the users get a good feeling of contact. In ITU, it is supported by the T.134 application in the T.120 family, By H.323 Annex G And by H.248.2 It is only defined for usage during a session. IM is traditionally not sent until the user makes a send request. A RETURN or ckicking a send button. I do not see any favour of that tradition compared to real-time text during sessions. So, for use during sessions, I think we are done. There are IM protocols that can be used outside a session. That may be handy. Gunnar ------------------------------------------------------------------- Gunnar Hellström Omnitor <mailto:gunnar.hellstrom@omnitor.se> gunnar.hellstrom@omnitor.se Tel: +46708204288 <http://www.omnitor.se> www.omnitor.se _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Gary Sullivan Sent: Tuesday, May 22, 2007 10:14 PM To: Paul E. Jones; itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol(CAP) Paul et al, What is the difference between "IM" and "text chat"? And how do these efforts relate to the following?: T.134 Text chat in data conferencing T.140 Protocol for multimedia application text conversation V.18 Text telephony Best Regards, Gary Sullivan _____ From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Monday, May 21, 2007 9:23 PM To: itu-sg16@lists.packetizer.com Subject: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol(CAP) Folks, We have debated the introduction of a method of sending IMs within H.323 for years. Its 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 weve 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 users 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: lets 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 companys name. Is that agreeable and are there any volunteers? Do you have another idea for how we can support X.1303 (CAP)? Thanks, Paul __________ NOD32 2283 (20070521) Information __________ Detta meddelande är genomsökt av NOD32 Antivirus. http://www.nod32.com
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, 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@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
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
be 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
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
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
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
Simao,
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").
We could actually take one of two approaches with something similar to H.450.7: 1) We can "alert" the user to an urgent message 2) We can deliver the message, rather than simply indicate it's presence Both options require either an extension to H.450.7 or something new entirely, but perhaps similar in structure to H.450.7.
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.
On phones that have a web browser, that could be accommodated by the phone, but for those that merely display text, that certainly presents a problem. Hmmm...
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).
You're hinting toward what I assumed CAP would actually do: something entirely outside of H.323 itself. I assumed there would be some kind of back-end CAP system that would take the contents and then create audio, video, and/or text, as necessary, and then instruct a special "warning" device that would use H.323 to deliver the message in a human usable form. Carrying CAP within H.323 certainly raises a lot of questions. It's easy to do, but what does a terminal do with it? PSTN gateway devices could not do anything with CAP, so we would still need the network-based warning system to deliver audio messages. (Unless we out a TTS system in every GW, which I think is quite unlikely to happen.) Terminals with display capability are the only devices that can reasonable accommodate reception of CAP messages directly.
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.
I certainly look forward to some further discussion on this. I'm hesitant to make a submission to this meeting on the topic, but I hope we have some good discussion at this next meeting and come out of the meeting with a plan.
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
As a? You're out of words? ;-) Paul
Paul, using snippets from your reply: [begin snippet]
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).
You're hinting toward what I assumed CAP would actually do: something entirely outside of H.323 itself. I assumed there would be some kind of back-end CAP system that would take the contents and then create audio, video, and/or text, as necessary, and then instruct a special "warning" device that would use H.323 to deliver the message in a human usable form. Carrying CAP within H.323 certainly raises a lot of questions. It's easy to do, but what does a terminal do with it? PSTN gateway devices could not do anything with CAP, so we would still need the network-based warning system to deliver audio messages. (Unless we out a TTS system in every GW, which I think is quite unlikely to happen.) Terminals with display capability are the only devices that can reasonable accommodate reception of CAP messages directly. [end snippet] I wonder, would make sense to think of defining a new entity e.g. a "multimedia alert gateway", where we would state what the conversion requirements would be and then we go on to say how it would be handled within H.323? This maybe as an add on to H.323, or perhaps as something that could be used for H.32x (now putting Q1 in the discussion :-) ) and H.248 as well? ... [begin snippet]
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
As a? You're out of words? ;-) [end snippet] That's what happens I swap between tasks... if I can remember what I wanted to say, something to the intent of maybe disconnecting the two issues and that work in IM for H.323 should go ahead as it is indeed strategic feature for H.323 from use case and user expectations perspective. Whether that could be a non-real time case of Annex G (as Gary hinted, if I understood it right), XMPP or something else, that remains to be discussed :-) [trying to reply to the message in just one sit] Thanks Simão
Simao,
I wonder, would make sense to think of defining a new entity e.g. a "multimedia alert gateway", where we would state what the conversion requirements would be and then we go on to say how it would be handled within H.323? This maybe as an add on to H.323, or perhaps as something that could be used for H.32x (now putting Q1 in the discussion :-) ) and H.248 as well?
My thinking was that the emergency broadcast center was the "gateway", so to speak. I have envisaged that there would be devices that knew where to send H.460.21 broadcasts, as well as devices that knew how to place serial and parallel calls. So, I did expect such an gateway, but do we need a new standardized signaling element for this? It seems like these devices would still be standard H.323 entities, but performing a more specific task. Most of the intelligence relating to when to use what method would be outside of H.323. Paul
Christian,
As an aside, do you know if there's any work in the IETF around CAP?
Honestly, I don't know. In theory, CAP could be carried as a MIME part in a SIP message. Most SIP implementations do not properly support MIME, so that might present some problem. Even so, it should be easily specified as an attachment to (or even serve as the main body of) an INVITE. Re: H.460.21
[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".
This is a good idea. Given the informative nature, then it might be best as an Appendix or even a H-series supplement. Perhaps we can do the latter and address all H-series devices? Re: carrying CAP natively in H.323.
[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.
I've heard no user request this. The only requests we had for consideration of this was this liaison at the Shenzhen meeting and also TD-365/WP2 at the last meeting in Geneva. In TD-365, there was this action item: "Join efforts in increasing support of the CAP standard in various communications systems (in particular those defined by ITU-T, e.g. H.323, IP Cablecom and NGN)." I read this to mean that there is a desire to transport CAP within H.323 systems, not merely that an H.323 system might be able to deliver a voice message in response to some serve outside H.323 having received a CAP message. If it were the latter, then H.323 would need no work to "support CAP". I might have also made this assumption, since Simao had mentioned to me in passing before the last meeting in Geneva that CAP looked relevant to H.460.tm (but don't blame Simao if I read more into his "heads up" than he intended). So, what shall we do? Should H.323 "support" CAP and how? If support means it does not need to transport CAP, we're done. But, I am of the opinion that the *intent* was that support meant we can transport a CAP message. There was certainly no hint that the interpretation expressed in our liaison was misguided, either. Perhaps we need to sync up with OASIS?
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.
The problem is that the other solutions are external to H.323 and not well integrated. To borrow words from the Jingle spec: "Because dual-stack XMPP+SIP clients are difficult to build, given that they essentially have two centers of program control, [5] we have designed Jingle as a pure XMPP signalling protocol." The same could be said of H.323+XMPP. The H.323 device registers with the H.323 network. The XMPP client with the XMPP network. There are two centers of control and no good coordination.
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.
And I doubt we'll get an unbiased perspective. Ask Average Joe and he'll ask, "what?" Ask OASIS and they'll say it needed to be done yesterday. :-) So, I think we need to deliver the tools and let people use what is appropriate. If we can carry CAP within the context of H.460.tm, I think we should. The standing question is whether we want to move forward with H.460.tm. I suggest we move forward, as I know there are several who want a native IM-type solution for H.323 where messages can be delivered within and outside the context of a call. I just need to convince a few people to jump on the bandwagon without fear of being volunteered for the editor job ;-) Paul
All, for your info, we have invited Mr Eliot Christian from the US Geological Service to make a presentation on CAP on Thu or Fri during the first week of SG 16. He'll be arriving on Thu lunch time from the US so I guess Friday would be a convenient day. He was very active in its development and is active in its promotion and advocacy. It'll be a good opportunity for us to become more familiar with the standard. Re CAP in the IETF, the only relevat thing I found was not really IETF but XMPP, http://www.xmpp.org/extensions/xep-0127.html I found http://www.watersprings.org/pub/id/draft-baker-alert-system-00.txt (International Alert System) which is expired and still refers to an outdated version of CAP. So probably an answer to Christian is "not yet"... Cheers, Simão -----Original Message----- From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Christian Groves Sent: 24 May 2007 02:50 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, Please my comments below CNG. As an aside, do you know if there's any work in the IETF around CAP? Regards, Christian ...
Simao, To support your findings, I asked one of the folks I work with on emergency-related activities & SIP and he said it has not been a topic of discussion in any of his meetings, either. Paul
-----Original Message----- From: simao.campos@itu.int [mailto:simao.campos@itu.int] Sent: Friday, May 25, 2007 7:14 AM To: Christian.Groves@nteczone.com; paulej@packetizer.com Cc: itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)
All,
for your info, we have invited Mr Eliot Christian from the US Geological Service to make a presentation on CAP on Thu or Fri during the first week of SG 16. He'll be arriving on Thu lunch time from the US so I guess Friday would be a convenient day.
He was very active in its development and is active in its promotion and advocacy. It'll be a good opportunity for us to become more familiar with the standard.
Re CAP in the IETF, the only relevat thing I found was not really IETF but XMPP, http://www.xmpp.org/extensions/xep-0127.html
I found http://www.watersprings.org/pub/id/draft-baker-alert-system- 00.txt (International Alert System) which is expired and still refers to an outdated version of CAP.
So probably an answer to Christian is "not yet"...
Cheers, Simão
-----Original Message----- From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16- bounces@lists.packetizer.com] On Behalf Of Christian Groves Sent: 24 May 2007 02:50 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,
Please my comments below CNG.
As an aside, do you know if there's any work in the IETF around CAP?
Regards, Christian
...
(2nd attempt to send - previously blocked, apparently due to anti-spam reflector settings). Paul, Thanks for the extra information. If you will tolerate some additional naive questioning, I have a further question about your characterization of the H.323 Annex G operation as a one-character-at-a-time-as-you-type model. It seems to me that the decision about when to send the characters is a user-interface issue involving only the sending terminal, not an interoperability specification issue. Thus if a terminal chose to "batch up" a paragraph of characters before choosing to send them, this batch-mode character acquisition process could be invisible to the protocol standards that specify how to send the characters once the sender is ready to send them. Presumably the sending terminal could also decide to somewhat alter its input before sending it as well -- for example by prefixing each paragraph with a sender-identifying string or something like that (e.g., "Cindy says: LoL, CU later."). I suppose the result of such a "pseudo-IM" emulation might not be ideal (e.g., in terms of the quantity of protocol overhead associated with sending a paragraph of characters or the speed at which the receiving terminal would obtain the transmitted paragraph), but it seems like the basic function can be achieved (without the need for new interop specifications customized to the "batch mode" text transfer approach). Perhaps, of course, I am missing something. I am just trying to satisfy my own curiosity here. Best Regards, Gary Sullivan -----Original Message----- From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Friday, May 25, 2007 1:06 PM To: simao.campos@itu.int; Christian.Groves@nteczone.com Cc: itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol (CAP) Simao, To support your findings, I asked one of the folks I work with on emergency-related activities & SIP and he said it has not been a topic of discussion in any of his meetings, either. Paul
-----Original Message----- From: simao.campos@itu.int [mailto:simao.campos@itu.int] Sent: Friday, May 25, 2007 7:14 AM To: Christian.Groves@nteczone.com; paulej@packetizer.com Cc: itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)
All,
for your info, we have invited Mr Eliot Christian from the US Geological Service to make a presentation on CAP on Thu or Fri during the first week of SG 16. He'll be arriving on Thu lunch time from the US so I guess Friday would be a convenient day.
He was very active in its development and is active in its promotion and advocacy. It'll be a good opportunity for us to become more familiar with the standard.
Re CAP in the IETF, the only relevat thing I found was not really IETF but XMPP, http://www.xmpp.org/extensions/xep-0127.html
I found http://www.watersprings.org/pub/id/draft-baker-alert-system- 00.txt (International Alert System) which is expired and still refers to an outdated version of CAP.
So probably an answer to Christian is "not yet"...
Cheers, Simão
-----Original Message----- From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16- bounces@lists.packetizer.com] On Behalf Of Christian Groves Sent: 24 May 2007 02:50 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,
Please my comments below CNG.
As an aside, do you know if there's any work in the IETF around CAP?
Regards, Christian
...
Gary, Your understanding of Annex G is correct. It could be used for IM-type services, but it really is different and would be a poor candidate for IM, in my opinion. Both modes have their place. Perhaps more important is this: do we deliver CAP as CAP messages, or do we deliver the human-readable contents of CAP messages? Do any H.323 systems exchange CAP messages? (We assumed so, but that's now pulled into question.) If we are to send CAP messages as CAP messages (i.e., not "decoded"), then we need something and Annex G is definitely not appropriate for that, but what is? An IM system designed to carry "typed" messages or some other facility in H.323 (e.g., something like H.450.7)? Paul
-----Original Message----- From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Friday, May 25, 2007 4:21 PM To: Paul E. Jones; simao.campos@itu.int; Christian.Groves@nteczone.com Cc: itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol (CAP)
(2nd attempt to send - previously blocked, apparently due to anti-spam reflector settings).
Paul,
Thanks for the extra information. If you will tolerate some additional naive questioning, I have a further question about your characterization of the H.323 Annex G operation as a one-character-at- a-time-as-you-type model. It seems to me that the decision about when to send the characters is a user-interface issue involving only the sending terminal, not an interoperability specification issue. Thus if a terminal chose to "batch up" a paragraph of characters before choosing to send them, this batch-mode character acquisition process could be invisible to the protocol standards that specify how to send the characters once the sender is ready to send them. Presumably the sending terminal could also decide to somewhat alter its input before sending it as well -- for example by prefixing each paragraph with a sender-identifying string or something like that (e.g., "Cindy says: LoL, CU later."). I suppose the result of such a "pseudo-IM" emulation might not be ideal (e.g., in terms of the quantity of protocol overhead associated with sending a paragraph of characters or the speed at which the receiving terminal would obtain the transmitted paragraph), but it seems like the basic function can be achieved (without the need for new interop specifications customized to the "batch mode" text transfer approach). Perhaps, of course, I am missing something. I am just trying to satisfy my own curiosity here.
Best Regards,
Gary Sullivan
-----Original Message----- From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16- bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Friday, May 25, 2007 1:06 PM To: simao.campos@itu.int; Christian.Groves@nteczone.com Cc: itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol (CAP)
Simao,
To support your findings, I asked one of the folks I work with on emergency-related activities & SIP and he said it has not been a topic of discussion in any of his meetings, either.
Paul
-----Original Message----- From: simao.campos@itu.int [mailto:simao.campos@itu.int] Sent: Friday, May 25, 2007 7:14 AM To: Christian.Groves@nteczone.com; paulej@packetizer.com Cc: itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)
All,
for your info, we have invited Mr Eliot Christian from the US Geological Service to make a presentation on CAP on Thu or Fri during the first week of SG 16. He'll be arriving on Thu lunch time from the US so I guess Friday would be a convenient day.
He was very active in its development and is active in its promotion and advocacy. It'll be a good opportunity for us to become more familiar with the standard.
Re CAP in the IETF, the only relevat thing I found was not really IETF but XMPP, http://www.xmpp.org/extensions/xep-0127.html
I found http://www.watersprings.org/pub/id/draft-baker-alert-system- 00.txt (International Alert System) which is expired and still refers to an outdated version of CAP.
So probably an answer to Christian is "not yet"...
Cheers, Simão
-----Original Message----- From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16- bounces@lists.packetizer.com] On Behalf Of Christian Groves Sent: 24 May 2007 02:50 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,
Please my comments below CNG.
As an aside, do you know if there's any work in the IETF around CAP?
Regards, Christian
...
Oh, should have commented: Plenipot Res.136 (2006) in its "resolves" 3+4 asks us to do that ("The use of telecommunications/information and communication technologies for monitoring and management in emergency and disaster situations for early warning, prevention, mitigation and relief"), albeit in a veiled manner: "international content standard for all-media public warning" = CAP. Definitely involving a users perspective will be useful, and bringing in Eliot will be useful from that perspective. Simão << PP06-Res.136.doc >> -----Original Message----- From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Christian Groves Sent: 24 May 2007 02:50 To: Paul E. Jones Cc: itu-sg16@lists.packetizer.com Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP) ...
... 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. ...
participants (9)
-
Christian Groves -
Even, Roni -
Francois Audet -
Gary Sullivan -
Geoff Constable -
Gunnar Hellström -
Paul E. Jones -
simao.campos＠itu.int -
Simon Horne