- sg16-avd - lists.packetizer.com

FW: Possible error in ITU-T H.224 (Figure 3)
by Patrick Luthi 04 Jun '07

04 Jun '07

Dear experts, I have been made aware of a possible error in H.224 when supporting more than one client. Most of the implementations I know about only support 1 client (H.281 FECC), but there some implementations that also support T.140 and non-standards clients. After consulting with the H.224 editor, we concluded that a typographical error was likely introduced in figure 3 in the first version of H.224. In the earliest complete draft of H.224 that we could find (dated 9 September 1993 see attached), Figure 3 is already present, and clearly the "number of clients" field is NOT supposed to be repeated. In order to correct this, I would like to receive feedback from manufacturers that have implemented more than one (1) H.224 client to understand if implementations follow: 1) the more logical method of the attached MS-HDLL document (bracket does NOT include the "number of clients" field) or, 2) the published Figure 3/H.224 method (bracket includes the "number of clients" field). Once I understand the backward compatibility impacts of a possible correction, I will submit a proposed corrigendum document to the upcoming meeting of SG16 (26 June-6 July). Thank you and best regards, Patrick Luthi Rapporteur for Q.1/16 > This mail has been sent from the ITU web site to itumail : > >Subject > >ITU Website feedback > > >UserLanguage > >English > >MessageType > >Problem > >Name > >Daniele Paccaloni > >Subject > >Possible error in ITU-T H.224 (Figure 3). > >Comments > >Hello, > >We would like to report a possible error in H.224 which could cause >severe incompatibilities between terminals supporting more than one Client. > >The possible error is in Figure 3/H.224 (all revision up to the latest): >We think that the \"number of clients\" byte should NOT be repeated >\"For each client\". >Since the \"number of clients\" byte indicates how many entries are >in the following client list, we believe it should not be repeated >for each client entry in the list. > >Note that this problem may have remained undetected for years since >most terminals only support 1 client (H.281 FECC). > >Please let us know if you plan to correct this, or not (for backward >compatibility reasons). > >Thank you, > >.daniele _____________________________ Patrick Luthi Manager, Technical Standards Rapporteur (chairman) for the ITU-T multimedia systems, terminals and data-conferencing Experts group (Question 1/16) TANDBERG N-1366 Lysaker, Norway Phone: + 47 67 125 125 Direct: +41 21 801 8420 e-mail: patrick.luthi(a)tandberg.com <http://www.tandberg.com/> http://www.tandberg.com

1 0

[itu-sg16] FW: FCC Press Release on Order requiring use of CAP
by simao.campos＠itu.int 01 Jun '07

01 Jun '07

Dear all, for info. Simão -----Original Message----- From: Eliot Christian [mailto:echristian@usgs.gov] Sent: 01 June 2007 16:02 To: Eliot Christian Subject: FCC Press Release on Order requiring use of CAP Yesterday, the U.S. Federal Communications Commission (FCC) issued a press release on its Order requiring use of the Common Alerting Protocol (CAP). Below are a few excerpts from the full press release (attached). I'd like join Tony Rutkowski in "Congratulations!" to Art Botterell for his tireless work over many years on developing and promoting CAP as the standard format for all-media, all-hazards public warning. Please forward this note to persons or discussion lists that may have an interest in all-hazards, all-media public warning. Thanks! Eliot Christian ---------------------------------------------- NEWS Federal Communications Commission May 31, 2007 FCC TAKES ACTION TO FURTHER STRENGTHEN NATION'S EMERGENCY ALERT SYSTEM Order to Ensure Efficient, Rapid Transmission of Emergency Information to the Public Washington, D.C. - The Federal Communications Commission today adopted [an Order that] promotes the development of fully digital Next Generation technologies and delivery systems that will better serve the American public. The Order requires [Emergency Alert System (EAS)] participants to accept messages using Common Alerting Protocol (CAP), the groundwork for Next Generation EAS delivery systems [...] The use of CAP will help to ensure the efficient and rapid transmission of EAS alerts to the American public in a variety of formats (including text, audio and video) and via different means (broadcast, cable, satellite, and other networks) and to promote the development of Next Generation EAS. [...] The Order also requires terrestrial EAS participants to transmit state and locally targeted EAS alerts that are originated by governors or their designees. [...] In addition, the Order expands the EAS system by requiring participation by wireline video providers. ----------------------------------------------

1 0

[itu-sg16] FW: Instant Messaging in H.323 & Common Alerting Protocol (CAP)
by simao.campos＠itu.int 31 May '07

31 May '07

Forwarded on behalf of Eliot. Simão -----Original Message----- From: Eliot Christian [mailto:echristian@usgs.gov] Sent: 31 May 2007 10:58 To: Christian Groves Cc: Paul E. Jones; Campos, Simao; itu-sg16(a)lists.packetizer.com; Art Botterell; Tony Rutkowski; Stephen.Perschau(a)dhs.gov Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP) At 09:07 PM 5/30/2007, Christian Groves wrote: >Hello Eliot, > >Thanks for the clarifications. Do you know of (or have a reference to) any architecture or requirements documents regarding CAP and public warning communications that have been produced in other groups that people could read as a background for discussion in SG16? For background about CAP, see ITU-D SG2 Q.22 Document 26, revision 1 (attached or at http://www.itu.int/md/D06-RGQ22.2-C-0026/en ). Eliot << D06-RGQ22.2-C-0026!R1!MSW-E.doc >>

1 0

RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)
by Eliot Christian 31 May '07

31 May '07

Please forgive me diving into the middle of this discussion. I would like to make a distinction here: a CAP message is a special case of emergency messages generally. We all know that just about any medium can be used to communicate emergency messages: sirens, police with bullhorns, voice over radio or telephone, text over news wire, text crawl over television, fax, e-mail, and so on. I would say that the underlying source of any emergency message may include, but is not limited to, a CAP message. I'd also note that CAP only standardizes the information content of emergency messages as they are being communicated digitally and electronically. A CAP message must be delivered entirely and without corruption, and in its specific structured format (transformable to the prescribed XML or ASN.1 syntax and encodings). Human receivers of emergency messages rarely deal directly with underlying CAP messages. A person who hears a siren blaring does not know or care if the siren is a TCP/IP device programmed to process CAP messages. The same is true of a warning given by a policeman based on a CAP message to his squad car, or a warning given by a radio announcer reading a CAP message off of a news wire service. Yet, the relaying, filtering, and routing of CAP messages is a very important aspect as CAP messages do traverse a wide range of communications paths. From a communications architecture perspective, our key consideration is whether traversal of a given path segment preserves the content and structural integrity of the CAP message and any associated authority, authenticity and security assertions. Where such integrity is not preserved, we should say that delivery of the CAP message is finished although the emergency message itself may continue to be relayed. For example, let's say the National Weather Service sends out a CAP message for a tornado alert. This CAP message is then picked up by the Weather Channel and inserted into television news. Seeing that message on television, local police trigger the public address system at a shopping mall in the threatened area. Here, a complex relay of the emergency message is occurring. The emergency messages were triggered by the original CAP message but the derivative emergency messages are not preserving the full integrity of the underlying CAP message. Expanding on the example, it is also possible for a local police system to pick up the CAP message directly from the National Weather Service. The police system can then automatically relay that message to an automated system at the shopping mall, programmed to process the CAP alert directly. In a similar vein, commercial wireless service providers in the U.S. will soon be required to process CAP messages and send such a tornado alert directly to their subscribers. Because these more automated communications paths can be much quicker and less error-prone, we look forward to deeper penetration of CAP-enabled communications over time. But, multiple communications paths for emergency messages will be commonplace for the foreseeable future. Eliot

3 5

[itu-sg16] Toward the upcoming SG16 meeting
by OKUBO Sakae 30 May '07

30 May '07

*** Apology for duplicated posting *** Dear WP2/16 experts, I would like to ask you the following for the preparation of the SG16 meeting that will be held in Geneva during 26 June - 6 July 2007: 1/ Contributions Since this is a formal study group meeting, all the contributions must be submitted to TSB according to TSB Collective Letter 7/16 <http://www.itu.int/md/T05-SG16-COL/en>. The submission should not be later than 15 June 2007 after going through your national procedures. It is appreciated if you could advise relevant Rapporteur(s) of your submission intention to help their planning. I would encourage you to send the submitted contributions to me <e-mail: okubo(a)aoni.waseda.jp> as well so that they are posted at the avc-site <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/> to facilitate advance review by the experts. Editors and Rapporteurs are also encouraged to send their TDs to me after having submitted them to TSB. 2/ Support for the new Question on Advanced Multimedia System Our Shenzhen meeting last March produced a draft text as attached after my signature. The next SG16 meeting will review this and if agreed this Question will start. To make this happen, ITU-T Resolution 1 (October 2004) requires the following: "7.2.2 New or revised Questions may be approved by a study group if consensus at the study group meeting is achieved. In addition, some Member States and Sector Members (normally at least four) have to commit themselves to support the work, e.g. by contributions, provision of rapporteurs or editors and/or hosting of meetings. The names of the supporting Sector Member organizations should be recorded in the meeting report." Your indication of "commitment" is requested at the meeting. 3/ Interim Rapporteur meeting(s) Between the two SG16 meetings in June-July 2006 and April 2008, we plan one or two Rapporteur meetings. Hosts of the meeting are solicited and advice of any possibility is welcome to ease the future planning at the upcoming SG16 meeting. -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** Annex 4 to the report of Shenzhen meeting AVD-3098 (TD 428/WP2) Proposed New Question X/16 ミ Advanced Multimedia System for Next Generation and Other Packet-Switched Networks <Background and Justification> As the lead Study Group on multimedia terminals, systems, and applications, SG16 strives to make advances in multimedia communication systems that take advantage of emerging technologies, as well as advances in and deeper understanding of existing technologies, in an effort to enable new and better forms of communication capabilities (ubiquitous services and applications e.g. any devices, any time and anywhere) for end users. The ITU-T has a long history of delivering successful multimedia systems that have enriched everyone’s lives. One of the most widely deployed and successful videoconferencing systems produced by the ITU is H.320. It is recognized by ITU-T SG16 as a first generation system and took advantage of the then newly-developed ISDN. In the mid-1990s, the ITU began work on H.323, which essentially leveraged the knowledge gained through the development of H.320 and applied that knowledge to packet-switched networks, including LANs, WANs, and the Internet. H.323 quickly became the dominant protocol for LAN-based videoconferencing, as well as a protocol used for transporting voice calls around the world. H.323 was developed in parallel with the IETF’s Session Initiation Protocol, and was effective in facilitating a migration from circuit-switched networks to packet-switched networks. Sharing similar capabilities and similar design philosophies and being produced in the same time period, H.323 and SIP are classified as second generation systems. Now, more than 11 years since the introduction of second generation systems, ITU-T SG16 is again looking toward the future of multimedia systems as the ITU-T also undertakes a study to introduce the Next Generation Network (NGN). The NGN holds the promise of revolutionizing communication as we know it and multimedia will be an important part of any new network technology. By building on the knowledge gained through the development of voice and video technologies that were the core part of H.320 and H.323, as well as the data conferencing technologies introduced in the T.120 series standards, ITU-T SG16 aims to introduce a third-generation system that truly enables users to utilize multiple modes of communication. <Study Items> The work on the third generation multimedia system will entail the creation of multiple new ITU-T Recommendations that will specify system architecture, system components, and one or more protocols at the service and application layer. The primary objective is to deliver a new multimedia system that is optimized for the NGN, but it must also operate on non-NGN packet-switched networks. The Experts will examine technologies such as various IP technologies, wireless technologies, and distributed computing capabilities in order to realize a system that will enable users to communicate using, as examples, voice and audio, video, electronic whiteboard, application sharing, real-time text, and file transfer across one or more communicating devices (e.g. smart phones, TV set-top boxes, game consoles, handheld game/entertainment machines, digital cameras, Internet “appliances”). Unlike previous generation systems, this new system will enable independent application developers to create system components that are able to seamlessly interface with the H.325 system in order to deliver any one or more of the aforementioned modes of communication. There is a strong desire to move away from the “monolithic applications” that were distinctive of second generation systems, to a system that enables components to “plug in” to the system, either locally or remotely, either using fixed wires or various wireless technologies, to deliver a whole new user experience. To meet that objective, SG16 will study the various interfaces between these components and the technologies that might be used to tie them together. The study includes among others: ・ Downloadable codecs ・ System decomposition ・ Discovery of services ・ Support for transcoding functionality (e.g. text to speech) ・ Dynamic device discovery ・ Application plug in ・ Consideration of different business models ・ Integrated QoS, security and mobility functionality <Specific Tasks and Deadlines> ・ Identification of Requirements (until Q1/2008) ・ Basic Architecture (until Q1/2009) ・ Complete System Specification (depends on progress) <Relationships> Virtually all other questions within SG 16, especially WP 2/16 and audio/video coding questions ・ ITU-T SG 11, SG 13, others TBD ・ IETF ・ ETSI TISPAN ・ 3GPP ・ Others TBD _____

1 0

Toward the upcoming SG16 meeting
by OKUBO Sakae 30 May '07

30 May '07

Dear WP2/16 experts, I would like to ask you the following for the preparation of the SG16 meeting that will be held in Geneva during 26 June - 6 July 2007: 1/ Contributions Since this is a formal study group meeting, all the contributions must be submitted to TSB according to TSB Collective Letter 7/16 <http://www.itu.int/md/T05-SG16-COL/en>. The submission should not be later than 15 June 2007 after going through your national procedures. It is appreciated if you could advise relevant Rapporteur(s) of your submission intention to help their planning. I would encourage you to send the submitted contributions to me <e-mail: okubo(a)aoni.waseda.jp> as well so that they are posted at the avc-site <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/> to facilitate advance review by the experts. Editors and Rapporteurs are also encouraged to send their TDs to me after having submitted them to TSB. 2/ Support for the new Question on Advanced Multimedia System Our Shenzhen meeting last March produced a draft text as attached after my signature. The next SG16 meeting will review this and if agreed this Question will start. To make this happen, ITU-T Resolution 1 (October 2004) requires the following: "7.2.2 New or revised Questions may be approved by a study group if consensus at the study group meeting is achieved. In addition, some Member States and Sector Members (normally at least four) have to commit themselves to support the work, e.g. by contributions, provision of rapporteurs or editors and/or hosting of meetings. The names of the supporting Sector Member organizations should be recorded in the meeting report." Your indication of "commitment" is requested at the meeting. 3/ Interim Rapporteur meeting(s) Between the two SG16 meetings in June-July 2006 and April 2008, we plan one or two Rapporteur meetings. Hosts of the meeting are solicited and advice of any possibility is welcome to ease the future planning at the upcoming SG16 meeting. -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** Annex 4 to the report of Shenzhen meeting AVD-3098 (TD 428/WP2) Proposed New Question X/16 ミ Advanced Multimedia System for Next Generation and Other Packet-Switched Networks <Background and Justification> As the lead Study Group on multimedia terminals, systems, and applications, SG16 strives to make advances in multimedia communication systems that take advantage of emerging technologies, as well as advances in and deeper understanding of existing technologies, in an effort to enable new and better forms of communication capabilities (ubiquitous services and applications e.g. any devices, any time and anywhere) for end users. The ITU-T has a long history of delivering successful multimedia systems that have enriched everyone’s lives. One of the most widely deployed and successful videoconferencing systems produced by the ITU is H.320. It is recognized by ITU-T SG16 as a first generation system and took advantage of the then newly-developed ISDN. In the mid-1990s, the ITU began work on H.323, which essentially leveraged the knowledge gained through the development of H.320 and applied that knowledge to packet-switched networks, including LANs, WANs, and the Internet. H.323 quickly became the dominant protocol for LAN-based videoconferencing, as well as a protocol used for transporting voice calls around the world. H.323 was developed in parallel with the IETF’s Session Initiation Protocol, and was effective in facilitating a migration from circuit-switched networks to packet-switched networks. Sharing similar capabilities and similar design philosophies and being produced in the same time period, H.323 and SIP are classified as second generation systems. Now, more than 11 years since the introduction of second generation systems, ITU-T SG16 is again looking toward the future of multimedia systems as the ITU-T also undertakes a study to introduce the Next Generation Network (NGN). The NGN holds the promise of revolutionizing communication as we know it and multimedia will be an important part of any new network technology. By building on the knowledge gained through the development of voice and video technologies that were the core part of H.320 and H.323, as well as the data conferencing technologies introduced in the T.120 series standards, ITU-T SG16 aims to introduce a third-generation system that truly enables users to utilize multiple modes of communication. <Study Items> The work on the third generation multimedia system will entail the creation of multiple new ITU-T Recommendations that will specify system architecture, system components, and one or more protocols at the service and application layer. The primary objective is to deliver a new multimedia system that is optimized for the NGN, but it must also operate on non-NGN packet-switched networks. The Experts will examine technologies such as various IP technologies, wireless technologies, and distributed computing capabilities in order to realize a system that will enable users to communicate using, as examples, voice and audio, video, electronic whiteboard, application sharing, real-time text, and file transfer across one or more communicating devices (e.g. smart phones, TV set-top boxes, game consoles, handheld game/entertainment machines, digital cameras, Internet “appliances”). Unlike previous generation systems, this new system will enable independent application developers to create system components that are able to seamlessly interface with the H.325 system in order to deliver any one or more of the aforementioned modes of communication. There is a strong desire to move away from the “monolithic applications” that were distinctive of second generation systems, to a system that enables components to “plug in” to the system, either locally or remotely, either using fixed wires or various wireless technologies, to deliver a whole new user experience. To meet that objective, SG16 will study the various interfaces between these components and the technologies that might be used to tie them together. The study includes among others: ・ Downloadable codecs ・ System decomposition ・ Discovery of services ・ Support for transcoding functionality (e.g. text to speech) ・ Dynamic device discovery ・ Application plug in ・ Consideration of different business models ・ Integrated QoS, security and mobility functionality <Specific Tasks and Deadlines> ・ Identification of Requirements (until Q1/2008) ・ Basic Architecture (until Q1/2009) ・ Complete System Specification (depends on progress) <Relationships> Virtually all other questions within SG 16, especially WP 2/16 and audio/video coding questions ・ ITU-T SG 11, SG 13, others TBD ・ IETF ・ ETSI TISPAN ・ 3GPP ・ Others TBD _____

1 0

Toward the upcoming SG16 meeting
by OKUBO Sakae 30 May '07

30 May '07

Dear WP2/16 experts, I would like to ask you the following for the preparation of the SG16 meeting that will be held in Geneva during 26 June - 6 July 2007: 1/ Contributions Since this is a formal study group meeting, all the contributions must be submitted to TSB according to TSB Collective Letter 7/16 <http://www.itu.int/md/T05-SG16-COL/en>. The submission should not be later than 15 June 2007 after going through your national procedures. It is appreciated if you could advise relevant Rapporteur(s) of your submission intention to help their planning. I would encourage you to send the submitted contributions to me <e-mail: okubo(a)aoni.waseda.jp> as well so that they are posted at the avc-site <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/> to facilitate advance review by the experts. Editors and Rapporteurs are also encouraged to send their TDs to me after having submitted them to TSB. 2/ Support for the new Question on Advanced Multimedia System Our Shenzhen meeting last March produced a draft text as attached after my signature. The next SG16 meeting will review this and if agreed this Question will start. To make this happen, ITU-T Resolution 1 (October 2004) requires the following: "7.2.2 New or revised Questions may be approved by a study group if consensus at the study group meeting is achieved. In addition, some Member States and Sector Members (normally at least four) have to commit themselves to support the work, e.g. by contributions, provision of rapporteurs or editors and/or hosting of meetings. The names of the supporting Sector Member organizations should be recorded in the meeting report." Your indication of "commitment" is requested at the meeting. 3/ Interim Rapporteur meeting(s) Between the two SG16 meetings in June-July 2006 and April 2008, we plan one or two Rapporteur meetings. Hosts of the meeting are solicited and advice of any possibility is welcome to ease the future planning at the upcoming SG16 meeting. -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** Annex 4 to the report of Shenzhen meeting AVD-3098 (TD 428/WP2) Proposed New Question X/16 ミ Advanced Multimedia System for Next Generation and Other Packet-Switched Networks <Background and Justification> As the lead Study Group on multimedia terminals, systems, and applications, SG16 strives to make advances in multimedia communication systems that take advantage of emerging technologies, as well as advances in and deeper understanding of existing technologies, in an effort to enable new and better forms of communication capabilities (ubiquitous services and applications e.g. any devices, any time and anywhere) for end users. The ITU-T has a long history of delivering successful multimedia systems that have enriched everyone’s lives. One of the most widely deployed and successful videoconferencing systems produced by the ITU is H.320. It is recognized by ITU-T SG16 as a first generation system and took advantage of the then newly-developed ISDN. In the mid-1990s, the ITU began work on H.323, which essentially leveraged the knowledge gained through the development of H.320 and applied that knowledge to packet-switched networks, including LANs, WANs, and the Internet. H.323 quickly became the dominant protocol for LAN-based videoconferencing, as well as a protocol used for transporting voice calls around the world. H.323 was developed in parallel with the IETF’s Session Initiation Protocol, and was effective in facilitating a migration from circuit-switched networks to packet-switched networks. Sharing similar capabilities and similar design philosophies and being produced in the same time period, H.323 and SIP are classified as second generation systems. Now, more than 11 years since the introduction of second generation systems, ITU-T SG16 is again looking toward the future of multimedia systems as the ITU-T also undertakes a study to introduce the Next Generation Network (NGN). The NGN holds the promise of revolutionizing communication as we know it and multimedia will be an important part of any new network technology. By building on the knowledge gained through the development of voice and video technologies that were the core part of H.320 and H.323, as well as the data conferencing technologies introduced in the T.120 series standards, ITU-T SG16 aims to introduce a third-generation system that truly enables users to utilize multiple modes of communication. <Study Items> The work on the third generation multimedia system will entail the creation of multiple new ITU-T Recommendations that will specify system architecture, system components, and one or more protocols at the service and application layer. The primary objective is to deliver a new multimedia system that is optimized for the NGN, but it must also operate on non-NGN packet-switched networks. The Experts will examine technologies such as various IP technologies, wireless technologies, and distributed computing capabilities in order to realize a system that will enable users to communicate using, as examples, voice and audio, video, electronic whiteboard, application sharing, real-time text, and file transfer across one or more communicating devices (e.g. smart phones, TV set-top boxes, game consoles, handheld game/entertainment machines, digital cameras, Internet “appliances”). Unlike previous generation systems, this new system will enable independent application developers to create system components that are able to seamlessly interface with the H.325 system in order to deliver any one or more of the aforementioned modes of communication. There is a strong desire to move away from the “monolithic applications” that were distinctive of second generation systems, to a system that enables components to “plug in” to the system, either locally or remotely, either using fixed wires or various wireless technologies, to deliver a whole new user experience. To meet that objective, SG16 will study the various interfaces between these components and the technologies that might be used to tie them together. The study includes among others: ・ Downloadable codecs ・ System decomposition ・ Discovery of services ・ Support for transcoding functionality (e.g. text to speech) ・ Dynamic device discovery ・ Application plug in ・ Consideration of different business models ・ Integrated QoS, security and mobility functionality <Specific Tasks and Deadlines> ・ Identification of Requirements (until Q1/2008) ・ Basic Architecture (until Q1/2009) ・ Complete System Specification (depends on progress) <Relationships> Virtually all other questions within SG 16, especially WP 2/16 and audio/video coding questions ・ ITU-T SG 11, SG 13, others TBD ・ IETF ・ ETSI TISPAN ・ 3GPP ・ Others TBD _____

1 0

[itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)
by Paul E. Jones 28 May '07

28 May '07

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

9 25

Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol (CAP)
by Christian Groves 28 May '07

28 May '07

G'Day Paul, I think Roni's suggestion of a requirement and architecture document as a first step is a good one. Simao's questions are also relevant. For me there seems to be several "users" of this CAP information each having different requirements and perhaps needing different solutions. To me the basic functions are: a collection of information phase, correlation of this information and then an information sharing phase. E.g. a very simplified view: [Information Gatherer #1] <-----1--+ +--> End User 1 | | [Information <--------+---->[Information <---2--->[Emergency--3-+--> End User 2 Gatherer #2] aggregation Centre] | centre] | +-->End User 3 On interface 1 the Information gatherer may use any type of communication. E.g. text message, radio message, PSTN and H.323 as an option. What is the assumption on CAP? Would it be used on this interface? Would it be a partial CAP? How would H.323 be used in this role? Are existing capabilities enough? At the Information aggregation point(s) I assume there is a co-ordination centre that takes information from various sources and actually creates a CAP description. On interface 2 the CAP protocol communicated between the Inf. Aggregation Centre and the emergency centre. Again there may be several methods to do this. One way is H.323. I think this has been the focus of your additions. At the Emergency centre this CAP protocol description is then used to generate warnings/information to the end users (public) over interface 3. Again this could be using various methods. Again one of which may be H.323. Again is using CAP appropriate here? I think having Eliot being part of the discussions will help us come up with an architecture and use the right terminology (I'm sure I'm not using the right terms) where we be talking about the same functions and requirements. Regards, Christian Even, Roni wrote: > Hi, > I am not too familiar with the requirements but from what I saw so far on the list it looks to me that this is some sort of a message that must be displayed or played to the user without relation to a specific call. > I assume that it should not require too much from the EP in term of supported functionality. > An H.323 EP who is not registered to a GK is not known in the network. If registered to a GK it can get RAS messages without being in a call or even during the call. So to me the logical place for such an alert will be in RAS. > As for audio announcement, this will require a call from an announcement server to the user but this does not scale. > > I think that before jumping to a solution, there need to be a requirement and architecture document. > I also noticed the XMPP solution which may be another direction for a solution since XMPP does also include registration to a presence server, but it also does not address voice messages, not through content indirection. > > Roni > > >> -----Original Message----- >> From: itu-sg16-bounces(a)lists.packetizer.com [mailto:itu-sg16- >> bounces(a)lists.packetizer.com] On Behalf Of simao.campos(a)itu.int >> Sent: Friday, May 25, 2007 4:13 PM >> To: s.horne(a)packetizer.com; Christian.Groves(a)nteczone.com; >> paulej(a)packetizer.com >> Cc: itu-sg16(a)lists.packetizer.com; echristian(a)usgs.gov >> Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common >> AlertingProtocol (CAP) >> >> All, >> >> Becareful as SMS are bound to create system overload/congestions and >> mechanisms akin to cell broadcast would be more scalable. While in the >> mobile industry there is a somewhat heated debate on the support of cell >> broadcast, there is no reason why we don't do it right from the start here >> [If we can just figure out what "right" means :-) ] >> >> I see the delivery of CAP alerts (which can be at various levels: >> authority to authority, authority to citizen but also citizen to citizen) >> as a multi-faceted issue and not necessarily one tied only to IM in H.323, >> as this should not exclude H.460.21 message broadcast's functionality. The >> H.450.7 approach seems part of the solution, even though (correct me if I >> am mistaken) it would only cover the sinalization that there is an urgent >> message, not what the message is (basically telling the users to "go and >> fetch it"). >> >> One aspect we need to be aware is that a CAP message can be multilingual >> and contain a URI to some other content, e.g. a recorded message. >> >> Opening a different can of worms: in the architecture, it is not clear to >> me who is the gateway for the incoming CAP messages and be able to perform >> some content translations. For example, beyond the XML to ASN.1 >> conversion, to do a text-to-speech for audio-only H.323 terminals for >> delivery of the warning. Or, a distribution node near the end delivery >> point can perform a de-referencing of an URI inside the CAP message to an >> A/V content (e.g. for a digital TV distribution). >> >> I find this development really exciting and seems that if we do a good >> work here we will get a lot of attention for H.323 also in developing >> countries as public warning / disaster response is a very hot topic today. >> >> Please do not see this as a discouragement to work on IM, I believe as >> Paul that this is necessary for H.323's continuation as a >> >> Cheers, >> Simão >> >> -----Original Message----- >> From: itu-sg16-bounces(a)lists.packetizer.com [mailto:itu-sg16- >> bounces(a)lists.packetizer.com] On Behalf Of Simon Horne >> Sent: 24 May 2007 03:55 >> To: Christian Groves; Paul E. Jones >> Cc: itu-sg16(a)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(a)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 >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >> > > > >

2 1

[itu-sg16] FW: Instant Messaging in H.323 & Common Alerting Protocol (CAP)
by simao.campos＠itu.int 28 May '07

28 May '07

Forwarded on behalf of Eliot Christian. Please copy him on any reply to this message. Cheers, Simão -----Original Message----- From: Eliot Christian [mailto:echristian@usgs.gov] Sent: 28 May 2007 15:56 To: Campos, Simao; paulej(a)packetizer.com; s.horne(a)packetizer.com; Christian.Groves(a)nteczone.com Cc: itu-sg16(a)lists.packetizer.com; Art Botterell Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP) Please forgive me diving into the middle of this discussion. I would like to make a distinction here: a CAP message is a special case of emergency messages generally. We all know that just about any medium can be used to communicate emergency messages: sirens, police with bullhorns, voice over radio or telephone, text over news wire, text crawl over television, fax, e-mail, and so on. I would say that the underlying source of any emergency message may include, but is not limited to, a CAP message. I'd also note that CAP only standardizes the information content of emergency messages as they are being communicated digitally and electronically. A CAP message must be delivered entirely and without corruption, and in its specific structured format (transformable to the prescribed XML or ASN.1 syntax and encodings). Human receivers of emergency messages rarely deal directly with underlying CAP messages. A person who hears a siren blaring does not know or care if the siren is a TCP/IP device programmed to process CAP messages. The same is true of a warning given by a policeman based on a CAP message to his squad car, or a warning given by a radio announcer reading a CAP message off of a news wire service. Yet, the relaying, filtering, and routing of CAP messages is a very important aspect as CAP messages do traverse a wide range of communications paths. From a communications architecture perspective, our key consideration is whether traversal of a given path segment preserves the content and structural integrity of the CAP message and any associated authority, authenticity and security assertions. Where such integrity is not preserved, we should say that delivery of the CAP message is finished although the emergency message itself may continue to be relayed. For example, let's say the National Weather Service sends out a CAP message for a tornado alert. This CAP message is then picked up by the Weather Channel and inserted into television news. Seeing that message on television, local police trigger the public address system at a shopping mall in the threatened area. Here, a complex relay of the emergency message is occurring. The emergency messages were triggered by the original CAP message but the derivative emergency messages are not preserving the full integrity of the underlying CAP message. Expanding on the example, it is also possible for a local police system to pick up the CAP message directly from the National Weather Service. The police system can then automatically relay that message to an automated system at the shopping mall, programmed to process the CAP alert directly. In a similar vein, commercial wireless service providers in the U.S. will soon be required to process CAP messages and send such a tornado alert directly to their subscribers. Because these more automated communications paths can be much quicker and less error-prone, we look forward to deeper penetration of CAP-enabled communications over time. But, multiple communications paths for emergency messages will be commonplace for the foreseeable future. Eliot

1 0

[itu-sg16] Spam control mechanisms
by Paul E. Jones 26 May '07

26 May '07

Folks, Gary mentioned in his last message that he had trouble sending e-mail due to anti-spam settings. Indeed, I have a few things in place to reduce spam on this mailing list which I hope you can generally appreciate. One of the mechanisms employed is something called SPF (http://en.wikipedia.org/wiki/Sender_Policy_Framework) as specified in RFC 4408. As noted in the RFC, it is experimental and not strongly endorsed by the IETF for one reason (as far as I can tell): you cannot forward mail from one account to another if SPF is used on the receiving server, as it will assume the message is in violation of the SPF rules. Even so, I've observed that industry adoption for SPF is significant. I thought I would bring this to your attention. If you get SPF rejection messages when sending e-mail to this server, then it means that you are transmitting e-mail from an IP address that is not authorized by your domain owner. Hopefully, this is not an issue for folks, but it might be if you send mail through a server which you do not normally send mail through. I can disable SPF checking if it presents unavoidable problems for anybody. I would prefer to not do that, because the extensive testing I have done shows that it reduces my own personal spam by 28%. That's substantial considering the quantity of the fine quality product and service offerings I get each day ;-) Paul

2 2

Re: [itu-sg16] Instant Messaging in H.323 & Common AlertingProtocol (CAP)
by Paul E. Jones 25 May '07

25 May '07

Roni, RAS might work, but that assumes the GK is somehow able to get the CAP message and then forward it on behalf of the upstream sender. This is a new use for RAS, but I can see that falling into line with some kind of SUBSCRIBE/NOTIFY type of capability in H.323. A GK could, for example, send an LRQ message to an emergency broadcast center to "subscribe" to the CAP service (acknowledge with LCF). Then, subsequent CAP messages could be delivered with SCI messages. (For technical reasons, as odd as it sounds, an LRQ would be better for initiating subscriptions that I'll explain more fully if you're interested.) In any case, this means we need a subscribe/notify framework in H.323. Interesting to consider. As you point out, this still requires something for devices that can only play audio. XMPP is certainly not off the list, but the concern I have is that it's a separate system that requires its own servers (or services), association with the same H.323 user, etc. I don't think that's necessarily so trivial to do. But, it would definitely be worth having a good discussion on this with some ideas for how we might bring the two together. As I said, I'm a fan of XMPP and definitely would like us to explore this further. Paul > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Friday, May 25, 2007 9:37 AM > To: simao.campos(a)itu.int; s.horne(a)packetizer.com; > Christian.Groves(a)nteczone.com; paulej(a)packetizer.com > Cc: itu-sg16(a)lists.packetizer.com > Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common > AlertingProtocol (CAP) > > Hi, > I am not too familiar with the requirements but from what I saw so far > on the list it looks to me that this is some sort of a message that > must be displayed or played to the user without relation to a specific > call. > I assume that it should not require too much from the EP in term of > supported functionality. > An H.323 EP who is not registered to a GK is not known in the network. > If registered to a GK it can get RAS messages without being in a call > or even during the call. So to me the logical place for such an alert > will be in RAS. > As for audio announcement, this will require a call from an > announcement server to the user but this does not scale. > > I think that before jumping to a solution, there need to be a > requirement and architecture document. > I also noticed the XMPP solution which may be another direction for a > solution since XMPP does also include registration to a presence > server, but it also does not address voice messages, not through > content indirection. > > Roni > > > -----Original Message----- > > From: itu-sg16-bounces(a)lists.packetizer.com [mailto:itu-sg16- > > bounces(a)lists.packetizer.com] On Behalf Of simao.campos(a)itu.int > > Sent: Friday, May 25, 2007 4:13 PM > > To: s.horne(a)packetizer.com; Christian.Groves(a)nteczone.com; > > paulej(a)packetizer.com > > Cc: itu-sg16(a)lists.packetizer.com; echristian(a)usgs.gov > > Subject: Re: [itu-sg16] Instant Messaging in H.323 & Common > > AlertingProtocol (CAP) > > > > All, > > > > Becareful as SMS are bound to create system overload/congestions and > > mechanisms akin to cell broadcast would be more scalable. While in > the > > mobile industry there is a somewhat heated debate on the support of > cell > > broadcast, there is no reason why we don't do it right from the start > here > > [If we can just figure out what "right" means :-) ] > > > > I see the delivery of CAP alerts (which can be at various levels: > > authority to authority, authority to citizen but also citizen to > citizen) > > as a multi-faceted issue and not necessarily one tied only to IM in > H.323, > > as this should not exclude H.460.21 message broadcast's > functionality. The > > H.450.7 approach seems part of the solution, even though (correct me > if I > > am mistaken) it would only cover the sinalization that there is an > urgent > > message, not what the message is (basically telling the users to "go > and > > fetch it"). > > > > One aspect we need to be aware is that a CAP message can be > multilingual > > and contain a URI to some other content, e.g. a recorded message. > > > > Opening a different can of worms: in the architecture, it is not > clear to > > me who is the gateway for the incoming CAP messages and be able to > perform > > some content translations. For example, beyond the XML to ASN.1 > > conversion, to do a text-to-speech for audio-only H.323 terminals for > > delivery of the warning. Or, a distribution node near the end > delivery > > point can perform a de-referencing of an URI inside the CAP message > to an > > A/V content (e.g. for a digital TV distribution). > > > > I find this development really exciting and seems that if we do a > good > > work here we will get a lot of attention for H.323 also in developing > > countries as public warning / disaster response is a very hot topic > today. > > > > Please do not see this as a discouragement to work on IM, I believe > as > > Paul that this is necessary for H.323's continuation as a > > > > Cheers, > > Simão > > > > -----Original Message----- > > From: itu-sg16-bounces(a)lists.packetizer.com [mailto:itu-sg16- > > bounces(a)lists.packetizer.com] On Behalf Of Simon Horne > > Sent: 24 May 2007 03:55 > > To: Christian Groves; Paul E. Jones > > Cc: itu-sg16(a)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(a)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 > > >>>> > > >>>> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > >

1 0

Re: [itu-sg16] H.248.53/.54/.56; Re: H.248.51 comments; Re: H.248 Work Items
by OKUBO Sakae 22 May '07

22 May '07

Mr Schwarz and all, At 10:53 +0200 07/05/22, Albrecht.Schwarz(a)alcatel-lucent.de wrote: >fyi, three further working documents: > >Index of /av-arch/avc-site/Incoming > Name Last modified Size > > Parent Directory 21-Oct-2005 13:05 - > C-xxx_H248.53_Ed07_Editorials_20070522.doc 22-May-2007 10:51 300k > C-xxx_H248_54_Ed07_Editorials_20070522.doc 22-May-2007 10:51 105k > C-xxx_H248_56_Ed07_Editorials_20070522.doc 22-May-2007 10:51 107k > > >H.248.54 & .56 are based on comments from Christian. They have been moved to the following directory: http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/Working_Docs/C-xxx_H… http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/Working_Docs/C-xxx_H… http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/Working_Docs/C-xxx_H… -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: [itu-sg16] H.248.51 comments; Re: H.248 Work Items
by OKUBO Sakae 22 May '07

22 May '07

Mr Shcwarz and all, At 18:07 +0200 07/05/21, Albrecht.Schwarz(a)alcatel-lucent.de wrote: >Index of /av-arch/avc-site/Incoming > Name Last modified >Size > > Parent Directory 21-Oct-2005 13:05 >- > TD-70 Draft H.248.51 EditorialComments_ALU_20070521.doc 21-May-2007 18:05 >84k This has been moved to the working document directory under Gen_0706: http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/Working_Docs/TD-70_D… -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

2 1

[itu-sg16] H.248 Work Items
by Christian Groves 21 May '07

21 May '07

Hello Q3ers, In Q.3 we have quite a few work items that are scheduled for approval at the June/July SG16 meeting. The attached PDF lists the recommendations that are scheduled. In the interests of saving time at the meeting I would ask that people review the draft recommendations as soon as practical and provide editorial comments to the editors. I would then ask the editors to collate these comments for input to the meeting. Hopefully we can then avoid having to do line by line editorial reviews late into the evenings! Regards, Christian

3 2

[itu-sg16] H323 analyzer
by anu jay 17 May '07

17 May '07

Hi, I want to take the h323 informations from an h323 packet (ex. callerid). Is there any h323 parser available for this. Kindly help me. --------------------------------- Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Here's a solution!

2 2

Revised version of T.135
by Patrick Luthi 15 May '07

15 May '07

Dear T.120 experts, Following the Q.1 Rapporteur meeting in Shenzhen last March, some of the ASN.1 syntax were questioned while Q.1 was reviewing a proposed draft revised T.135. After consultation with the ASN.1 Project Group of SG17, the TSB ASN.1 Specialist and the Editor of T.135, we received some suggestions and were able to understand the small corrections still needed to allow the T.135 ASN.1 to compile without errors. We prepared what should be the final version of T.135 to be submitted as a TD. The changes from the version that you saw at the Shenzhen Rapporteur meeting are the following: - on some constraints on AcknowledgmentType, "WITH COMPONENTS" was added; - in a comment a string like "------------" shall contain an even number of "-" character. The attached draft contains change marks. Please review it and let me know if you have any comments before we submit the draft to the upcoming SG16 meeting. Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

Revised version of T.135
by Patrick Luthi 15 May '07

15 May '07

Dear T.120 experts, Following the Q.1 Rapporteur meeting in Shenzhen last March, some of the ASN.1 syntax were questioned while Q.1 was reviewing a proposed draft revised T.135. After consultation with the ASN.1 Project Group of SG17, the TSB ASN.1 Specialist and the Editor of T.135, we received some suggestions and were able to understand the small corrections still needed to allow the T.135 ASN.1 to compile without errors. We prepared what should be the final version of T.135 to be submitted as a TD. The changes from the version that you saw at the Shenzhen Rapporteur meeting are the following: - on some constraints on AcknowledgmentType, "WITH COMPONENTS" was added; - in a comment a string like "------------" shall contain an even number of "-" character. The attached draft contains change marks. Please review it and let me know if you have any comments before we submit the draft to the upcoming SG16 meeting. Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

[itu-sg16] Q17 and work on SBC definition
by Paul E. Jones 11 May '07

11 May '07

Folks, You may recall that during the Shenzhen meeting, I said that I would take an action item to "suggest" to Q17/16 that perhaps they might want to more formally define an SBC. Well, they actually are. They are not referring to it as an SBC and, given that I think the device could be used as an functional element within the service provider domain, perhaps the terminology they're using is appropriate. In any case, I thought I would bring your attention to their most recent draft text, in case you have not seen it: http://ties.itu.int/u/tsg16/sg16/xchange/wp1/Stable_Text/GIP2IP/G.IP2IP-ver- 1.6a.doc Paul

1 0

Re: [itu-sg16] SG16 meeting during 26 June - 6 July
by OKUBO Sakae 28 Apr '07

28 Apr '07

Dear Mr. Wang, At 09:22 +0800 07/04/26, wang.dong(a)zte.com.cn wrote: > About Q21/16 future work, you mentioned that: > ... > - Progress work on H.saarch, H.vsreqs (video surveillance), >H.ghna (Home network architecture) & IPTV > ... > > Here, whether H.vsreqs should be H.vsarch or not? > > Because I found that Q22/16 will discuss the H.vsreqs also >and no H.vsarch will be scheduled for discussion, so I want to >confirm whether it is not parell to F.vsreqs and F.vsarch or not. You are right. Apologies for my overlook. I have requested TSB to add this item to Q21 in the collective letter for the June-July meeting, if time allows. In any case, your contributions are appreciated according to the discussion at the Shenzhen meeting as recorded in AVD-3098. -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

2 1

[itu-sg16] SG16 meeting during 26 June - 6 July
by OKUBO Sakae 25 Apr '07

25 Apr '07

Dear WP2/16 experts, SG16 will meet just in two months. The Shenzhen meeting last month identified the following items, among others, that need further work. Your contributions are solicited. General 1 - Possible new Question on "Advanced Multimedia System for Next Generation and Other Packet-Switched Networks" - What are the business requirements that we need to consider as part of such an effort? - What functionality is missing in existing systems that prevent us from meeting those requirements? - Why is it important to consider development of a third-generation multimedia system? * Does cost and complexity of existing systems make it challenging to meet business requirements? * Is it difficult to mange and control systems and services due to the current designs? - What problems do we need to solve? - What innovative modes of communication would we like to enable that are simply impossible with existing systems? General 2 - Questions for the next study period - We need a group of good Questions that are accommodated in a Study Group as a block - How can the current Questions be reorganized? Q1/16 "Multimedia systems, terminals and data conferencing" - Incorporate results from interim meeting accordingly - Progress of H.324 topics relative to Annex K - Review of final text of H.324 Annex L (text conversation), H.324 Amd. 2 and H.222.0 Amd. 2 - Review of final text of revised T.120-series - Review of the items relative to H.320, H.324, T.120, H.310, etc. Q2/16 "Real-Time Audio, Video, and Data Communication over Packet-Switched Networks" - Review items proposed for the H.323-series Implementors' Guide - Progress work on: H.245v14, H.323 Annex I, H.460.geo, H.presence, H.460.tm - Discussion of miscellaneous and new work items Q3/16 "Multimedia Gateway Control Architectures and Protocols" - Prepare for Consent: H.248.8 Revised, H.248.9 Amendment 1, H.248.12 Amendment 2, H.248.19 Amendment 2, H.248.29 Corrigenda 1, H.248.37 Amendment 1, H.248.43 (ex. H.248.GM), H.248.47 Amendment 1, H.248.48 (ex. H.248.QHR), H.248.49 (ex. H.248.SDPVER), H.248.50 (ex. H.248.NATTT), H.248.51 (ex. H.248.TCM), H.248.52 (ex. H.248.QoS), H.248.53 (ex. H.248.TMAN), H.248.54 (ex. H.248.MPLS), H.248.55 (ex. H.248.PLM), H.248.56 (ex. H.248.VPN) - Progress work on H.248.RTCP, H.248.ETN, H.248.RTPAD, H.248.Statistics - Prepare revised IGs for H.248 Sub Series and H.248.1v2 - Revised and new H Series Supplements: 2, 7, H.Supp-H248sync - Consider new materials Q4/16 "Advanced multimedia communication service features on top of the ITU-T defined multimedia system platforms" - Progress work on H.350.8 aiming at Consent in 2007-07 - Enhancements to H.350 Sub-series - Possible new service features Q5/16 "Control of NAT and Firewall Traversal for H.300-Series Multimedia Systems" - Progress work on: H.proxy, TP.HNFT - Discussion of miscellaneous and new work items Q21/16 "Multimedia Architecture" - "H.325" Next generation multimedia terminals and systems {see also General 1 above} - Progress work on H.saarch, H.vsreqs (video surveillance), H.ghna (Home network architecture) & IPTV - Progress work on H.MID (NID triggered multimedia information delivery system architecture) Q22/16 "Multimedia applications and services" - Progress work for F.VSreqs (Requirements and services description for visual surveillance) and F.MID (Requirements and services description for NID triggered multimedia contents retrieval and delivery services) - Progress IPTV related subjects concerning definitions, requirements and scenarios (in the context of multimedia communications) Q24/16 "Quality of service and end-to-end performance in multimedia systems" - Progress work on Annexes A, B, C of H.361 (ex H.mmqos) - Progress work on H.trans.control - Discussion of miscellaneous and new work items on end-to-end QoS Q25/16 "Multimedia security in next-generation networks (NGN-MM-SEC)" - Study NGN-MM-SEC issues - Study security aspects of MM-DRM Q28/16 "Multimedia framework for e-health applications" - Review feedback on the first version of Technical Paper on the telemedicine Standardization Roadmap - Present activities carried out within the eHSCG and HTTF group - Discuss a possible structure for the Recommendation on a 'Framework for e-health applications in emergency situations' - Discuss working arrangements for future meetings Q29/16 "Mobility for multimedia systems and services" - Progress TP.mmsm (Service Mobility for new Multimedia Service Architecture) - Presence in H.3xx based systems - In-car multimedia support -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

[itu-sg16] Mailing List Has Moved
by Paul E. Jones 15 Apr '07

15 Apr '07

Folks, I have completed moving all of the mailing list subscribers from the former machine to the new machine. If you encounter any problems at all, please let me know. Cheers! Paul

2 1

Welcome to the "itu-sg16" mailing list
by itu-sg16-request＠lists.packetizer.com 14 Apr '07

14 Apr '07

Welcome to the itu-sg16(a)lists.packetizer.com mailing list! To post to this list, send your email to: itu-sg16(a)lists.packetizer.com General information about the mailing list is at: http://lists.packetizer.com/mailman/listinfo/itu-sg16 If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.packetizer.com/mailman/options/itu-sg16/paulej%40packetizer.com You can also make such adjustments via email by sending a message to: itu-sg16-request(a)lists.packetizer.com with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: unovbaaw Normally, Mailman will remind you of your lists.packetizer.com mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you.

1 0

Moving the SG16 mailing list
by Paul E. Jones 12 Apr '07

12 Apr '07

Folks, As we discussed during the last Rapporteur meeting, I will be moving the mailing list to a new machine soon-perhaps this weekend. When that happens, you will get an automated message welcoming you to the mailing list. Don't be alarmed! :-) I will keep both servers active for a period of time, just in case we encounter any technical issues, but will eventually remove the list from the current server. There is no action that you need to take. Thanks! Paul

1 0

FW: Need protocol stacks and codecs for IP & ISDN based video conferencing
by simao.campos＠ITU.INT 10 Apr '07

10 Apr '07

Maybe someone can help Mr Syed Ali? Thanks Simão ________________________________ From: syed.ali2(a)wipro.com [mailto:syed.ali2@wipro.com] Sent: 03 April 2007 11:49 To: Campos, Simao Subject: Need protocol stacks and codecs for IP & ISDN based video conferencing Hi, I am Syed from Wipro Technologies. We are developing a product which is having Video Conferencing functionality. This product is aiming the Global business market and the no.of units we are aiming is more than 1000 per year. So we are looking for a good vendor to purchase protocol stacks and codecs for Video Conference.First let me explain our requirements. Our Project is Non Medical Devices Controller. The system will control all the non medical devices like Room light, Fan , A/C, Camera and etc. Video Conferencing is one of the module. We are going to implement Video Conferencing through IP & ISDN based networks. If we are implementing video conferencing module using your Protocol Stack, it should be able to communicate world wide with the existing video conferencing systems like EyeCatcher, TANDBERG , Polycom, vcon and etc. 1) The protocols stack should support Windows XP Professional & Windows XP Embedded and drivers. 2) The protocol stack should have all the protocols to do Video Conferencing through IP & ISDN based networks. And Firewall,NAT support also. 3) If the protocol require any dependencies, then we are expecting the vendor to provide the same at the time of purchase and at the time of building our complete system. 4) We need Audio & Video codecs which are applicable to the Video Conferencing. 5) Complete Source codes, API reference documents and support. Questions:- ------------ 1) Suppose if we are going to use the protocol stack, what are all the hardware & software requirements? 2) Will the protocol stack support only a particular system or it can able to communicate with other vendor's video conferencing system also? 3) Will the stack support upgradation facility? For Ex: Let us assume we have built the video conferencing system using the protocol stack for IP & ISDN networks. If we need to use Video Conferencing in other networks say PSTN , will the vendor provide protocol stack upgradation for that? 4) Can we use the protocol stack in other Operating systems like linux ? 5) In which format the protocol stacks would be? Libraries/ Source codes? 6) Will the protocol stack package include Test/Debugging support ? Sample applications ? 7) What are all the Audio & Video codecs required to do the Video Conferencing? and what are all available with the vendor? We require, 1) Protocol stacks for IP based Video Conferencing 2) Protocol stacks for ISDN based Video Conferencing 3) Audio & Video codecs We are looking for vendors who are selling the same. Please send the details according to our requirements. Regards, M. Syed Ali, Project Engineer, Wipro Technologies, Cochin, India. Ph : +91 (0) 484 305 4439 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0