- sg16-avd - lists.packetizer.com

Re: Status of "AAP" approved standards ?
by Sebestyen Istvan ICN M SR 3 17 Jan '01

17 Jan '01

No, unfortunately the interpretation is not correct. The introduction of AAP has been approved by the WTSA, but is just under implementation now. So, up to now no real AAP voting was sent out. I don't know when the actual start would be launched. Maybe in 4-6 more weeks? This is a guess only... Regards, Istvan -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M SR 3, Hofmannstr. 51, D-81359 Munich, Germany Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://intranet.icn.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/ ---------------------------------------------------------------------------- ---------------- > ---------- > From: Klaghofer Karl ICN EN HC SE 81 > Reply To: Klaghofer Karl ICN EN HC SE 81 > Sent: Wednesday, January 17, 2001 11:48 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Status of "AAP" approved standards ? > > Dear all, > > What is the status of the documents that had been approved in the November > SG16 Meeting in Geneva "based on consent", i.e. approved according to the > new Alternative Approval Process (AAP) - like e.g. H.450.10, H.450.11, > H.323 > Annex L,... > > Since AAP approval is now two months ago (and I did not see any > discussions/objections on those documents at least on this mailing list), > they should now be official ITU-T standards ? Can anyone (maybe the > Rapporteurs) confirm my interpretation ? > > Thanks, > Karl Klaghofer > Siemens AG > karl.klaghofer(a)icn.siemens.de > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Status of "AAP" approved standards ?
by Klaghofer Karl ICN EN HC SE 81 17 Jan '01

17 Jan '01

Dear all, What is the status of the documents that had been approved in the November SG16 Meeting in Geneva "based on consent", i.e. approved according to the new Alternative Approval Process (AAP) - like e.g. H.450.10, H.450.11, H.323 Annex L,... Since AAP approval is now two months ago (and I did not see any discussions/objections on those documents at least on this mailing list), they should now be official ITU-T standards ? Can anyone (maybe the Rapporteurs) confirm my interpretation ? Thanks, Karl Klaghofer Siemens AG karl.klaghofer(a)icn.siemens.de ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Corrections to Mobile-UIM
by Paul E. Jones 17 Jan '01

17 Jan '01

Folks, In the past week or so, the specifications of the mobile number definitions-- particularly for GSM-UIM-- were discussed and changes were deemed necessary. I have made changes as recommended by the Annex H and Annex E/H.246 editors. Please find the attached document with the list of corrections for H.323v4 and H.225.0v4. In particular, the first GSM-UIM type in section 2.5 has been modified since the last time I e-mailed this draft. Please review the changes and any other relevant ASN.1 changes. Thanks, Paul

1 0

RE: H.225- CRV
by Nehru, Archana 17 Jan '01

17 Jan '01

Paul, Since we agree that CRVs should be unique between two endpoints, what is the ideal behavior in the following case? Let us say there are two endpoints running on the same machine..which means that they have the same source IP address. Since the two endpoints are independent entities, they will generate CRVs independently. Now let us say both the endpoints make a call to another endpoint/GK with the same CRV. So at the receiver's side, we see two incoming calls with exactly the same CRV and exactly same "source" IP address. Is this a valid configuration? How is a receiver supposed to handle these incoming calls, particularly is there is no "callId"? Thanks -Archana >-----Original Message----- >From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] >Sent: Tuesday, January 16, 2001 12:40 PM >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: Re: H.225- CRV > > >Chris, > >Considering that V1 only allowed a single call over a single >TCP connection, >what would have been the point of a CRV in the Setup message? >If they could >all be the same, it makes them worthless. (Of course, I've >found CRVs in >packet-switched systems mostly worthless, but not entirely.) > >From H.323: >``One CRV is used to associate the call signalling messages. >This CRV shall >be used in all call signalling messages between two entities >(endpoint to >Gatekeeper, endpoint-to-endpoint, etc.) related to the same call.'' > >Note the text that says "between two entities". If the intent was that >these values were only unique "per connection", it would say >so. The CRVs >are unique between two entities. > >From H.225.0: >``Note that the CRV is only unique on a particular part of a call, e.g. >between two terminals, or between a terminal and a gatekeeper. >If a given >terminal has two calls in the same conference, each shall have the same >conference ID but different CRVs.'' > >The latter sentence is more important: when communicating between two >entities, it states clearly that there must be different CRVs. > Again, with >V1 those two calls would have been using different TCP >connections, yet the >text clearly says the CRVs must be different. > >Now, I may be wrong-- this is just my interpretation of the >text. I'd like >to hear other comments. > >Paul > >----- Original Message ----- >From: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk> >To: "Paul E. Jones" <paulej(a)packetizer.com> >Cc: <ITU-SG16(a)mailbag.cps.intel.com> >Sent: Tuesday, January 16, 2001 5:16 AM >Subject: Re: H.225- CRV > > >> Paul, >> >> I disagree. CRV is surely unique per connection. >> One may be well advised to keep it more unique than that, because in >> gatekeepered environments you're liable to end up with >problems if you're >not >> careful because of your note 1 - but if I receive Q.931 messages on >separate >> TCP connections giving the same CRV I shouldn't expect them >to refer to >the >> same call. I argue that this is rooted in the principal of >TransportAddress >> throughout the H.323 standards including the SAPI (IP port >number) as well >as >> actual address. >> >> Regards, >> Chris >> >> "Paul E. Jones" wrote: >> > >> > Archana, >> > >> > (a) is closer to the way things actually work. >> > >> > Essentially, you can use whatever values you wish so long >as you never >place >> > two calls to the same endpoint using the same CRV value. >So, whether >two >> > calls to an endpoint use the same TCP connection or different >connections, >> > the CRV must be unique. >> > >> > You should also consider the possibility that an endpoint >may have two >call >> > signaling addresses. How would you know if this were the >case? The >safest >> > thing to do is never have two calls with the same CRV at >the same time. >> > However, if you know that the destination endpoints are unique, you >could >> > re-use the CRV value.. at least when a Gatekeeper is not >being used. >> > >> > There are also so other properties of CRVs: >> > 1) The CRV sent in an ARQ to place a call shall be the >same as the >> > CRV in the resulting Setup message >> > 2) The CRV sent in an ARQ to accept a call should *not* be taken >> > from the incoming Setup message-- it should be >locally generated so >> > that it is a unique between the endpoint and the GK >> > >> > Paul >> > >> > ----- Original Message ----- >> > From: "Nehru, Archana" <archie(a)trillium.com> >> > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM> >> > Cc: <ITU-SG16(a)mailbag.cps.intel.com> >> > Sent: Monday, January 15, 2001 10:28 PM >> > Subject: H.225- CRV >> > >> > > hi all, >> > > >> > > I have a question about H.323 -CRV values. Q.931 specs >says that a CRV >> > value >> > > should be unique per D-channel layer 2 logical link. >> > > >> > > In H.225 context, does the above mean that: >> > > >> > > a) CRV values should be unique across all outgoing H.225 >calls that >have >> > the >> > > same "destination" IP address ? >> > > >> > > b) CRV value only needs to be unique across all H.225 connections >using >> > the >> > > same TCP connection? In other words, if an endpoint A makes two >> > simultaneous >> > > calls to endpoint B, then the same CRV can be used on >both the calls, >as >> > > long as they use different TCP connections? >> > > >> > > I would appreciate any help on this. >> > > >> > > Regards >> > > Archana >> > > >> > > >> > > >> > >> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > For help on this mail list, send "HELP ITU-SG16" in a message to >> > listserv(a)mailbag.intel.com >> >> -- >> Dr Chris Purvis -- Development Manager >> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road >> Winkfield Row, Berkshire. RG42 6LY ENGLAND >> Phone: +44 1344 899 007 >> Fax: +44 1344 899 001 >> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.intel.com >

2 1

Please Review corrections for H.225.0v4 and H.323v4
by Paul E. Jones 16 Jan '01

16 Jan '01

Experts, As you know, I have posted a document to this list a number of times seeking comments on corrections that need to be applied to H.323v4 and H.225.0v4. I was given permission by the TSB to make these changes, but before such changes are made, I want to give you one last opportunity to comment. To this date, every comment that I have received has been one of agreement-- I have heard no objections. The ASN.1 found in this document is the same as that which has been posted to the Packetizer web-site and I know that several companies have already grabbed that ASN.1 for implementation purposes. I don't believe there should be any contentious issues in this document, but I wanted to give you one last opportunity to review and comment. Please send comments directly to me and/or post them to this list. If I hear no objections, I will forward this document to the TSB for inclusion in the final published H.225.0v4 and H.323v4. Thanks, Paul

2 2

Re: Final Revision of Changes for H.225.0v4 and H.323v4
by Paul E. Jones 16 Jan '01

16 Jan '01

Krish, I believe Pete may be the better person to answer this question. Essentially, if the Gatekeeper provides the needed feature-- that's great. If it does not, it needs to ensure that the LRQ contains the needed feature information so that the destination Gatekeeper can locate an entity that can provide the features. I believe this logic applies regardless of whether the call is routed or not. Paul ----- Original Message ----- From: "Sudharsana krishnan P" <pskrish(a)miel.mot.com> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; "'H323implementors(a)Imtc.Org' (E-mail)" <h323implementors(a)imtc.org> Cc: <pskrish(a)miel.mot.com> Sent: Monday, January 15, 2001 11:36 PM Subject: RE: Final Revision of Changes for H.225.0v4 and H.323v4 > Hello Paul > I was reviewing this document and had a slight doubt related to the following > Section 1.6 > ------------ > If the responding entity is a Gatekeeper that sends an LRQ in response to receiving an ARQ, the Gatekeeper shall copy any features that are not provided by the Gatekeeper into the LRQ. In trying to determine whether the necessary set of features are supported, the Gatekeeper shall examine the supported features of the endpoint to which the ARQ may resolve, either locally or in response to an LCF, and the features supported by the Gatekeeper. > ------------------- > > Case 1: GK routed model should read. > > If the responding entity is a Gatekeeper that sends an LRQ in response to receiving an ARQ, the Gatekeeper shall NOT copy any features that are not provided by the Gatekeeper into the LRQ. In trying to determine whether the necessary set of features are supported, the Gatekeeper shall examine the supported features of the endpoint to which the ARQ may resolve, either locally or in response to an LCF, and the features supported by the Gatekeeper. > > Case 2: Direct routed model should read. > > If the responding entity is a Gatekeeper that sends an LRQ in response to receiving an ARQ, the Gatekeeper SHALL copy any features EVEN IF NOT provided by the Gatekeeper into the LRQ. In trying to determine whether the necessary set of features are supported, the Gatekeeper shall examine the supported features of the endpoint to which the ARQ may resolve, either locally or in response to an LCF. > > Did I miss something here > ------------------- > > Regards > krish > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Paul E. Jones > Sent: Monday, January 15, 2001 8:27 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Final Revision of Changes for H.225.0v4 and H.323v4 > > > Folks, > > I have attached what I hope is the final revision of the changes to > H.225.0v4 and H.323v4. The additional changes are in response to e-mails I > have received. > > The changes from the last revision include new sections 1.5, 1.9, and 2.2. > There are no additional ASN.1 changes. > > These changes were necessary in order to align the text between H.323v4 and > H.225.0v4. > > Please give me any comments by the end of the business day Tuesday. > > Thanks, > Paul E. Jones > Q.2/16 Rapporteur > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[Fwd: Maximum and Current Call Capacities ASN.1 in H225.0v4]
by Logan Modahala 12 Jan '01

12 Jan '01

Resending to get the attention of interested parties. - Logan

1 0

New Question 1/16
by Patrick_Luthi＠PICTEL.COM 11 Jan '01

11 Jan '01

Dear experts, If you receive this mail, it is because you were at some point involved in the standardization activities of the former Study Group 16 Questions 3, 11, or 12. With the new Study Period starting, the work of Q3, 11, and 12 has been consolidated in a new Q1 (Multimedia systems, terminals, and data conferencing). Q1 will cover the following recommendations: H.221, H.222.0, H.222.1, H.223, H.224, H.226, H.230, H.231, H.242, H.243, H.244, H.247, H.281, H.283, H.310, H.320, H.321, H.322, H.324, H.331, T.120 through T.128, T.134, T.135, T.140 and related annexes and appendices. Question 1 will be using the official mailing list provided by the ITU. For matters covering more than just Q1 issues, the more general SG16 mailing list maintained by Intel will also be used. If you are interested in keeping up with Q1 activities and meetings, you should join the Q1 mailing list "tsg16q1(a)itu.int" (http://www.itu.int/ITU-T/com16/edh/subscribe.html). The ITU hosted mailing list will be open to all ITU-T members. Additional non ITU-T experts may also participate if invited by the rapporteur. The rapporteur of Q.1 does not wish to exclude anyone who could be a valuable contributor to the work. Therefore, an electronic mail sent to the rapporteur (patrick.luthi(a)ties.itu.ch) is the suggested method of contact for non-ITU experts in order to be included on every Q1 related correspondence (be sure to include your contact phone, fax, address and email information). The first meeting of Q1, co-located with Questions D, F, G, 2, 3, and 4, will take place in Australia March 5-9, 2001. Confirmation and details on the logistics of the meeting will be sent out to the mailing lists later. Also, attached to this e-mail message, is a document from the WP2 Rapporteurs describing the organization of the new SG16 questions over the 2001-2004 Study Period. (See attached file: q1a04.doc) I am looking forward to seeing you at an upcoming Study Group or Rapporteur meeting. Best regards Patrick Luthi Rapporteur for Q1/16 - Multimedia systems, terminals, and data conferencing Experts Group (MSEG) P.S. To subscribe to the SG16/Intel reflector: send a message to listserv(a)mailbag.intel.com with "subscribe itu-sg16 <your email address> <your name>" in the body of the message. _________________________________ Patrick Luthi PictureTel Corporation Andover, Massachusetts, USA tel: +1 978 292-4354 e-mail: luthip(a)pictel.com

1 0

Directory changes of the avc-site
by OKUBO Sakae 11 Jan '01

11 Jan '01

Dear SG16 experts, Please note that all the directories and their files produced during August 1996 and December 2000 have been moved to one layer lower place as part of the clean-up of the PictureTel ftp site: http://standard.pictel.com/ftp/avc-site/till_0012/ Please update your web page having links to the documents moved to the above directory. You may also need some actions if you are mirroring this site. Apologies for your inconvenience that happens once in four years. A directory for the March meeting (0103_???) will be created under /avc-site as soon as the meeting place has been fixed. Best regards, OKUBO Sakae *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Organization of day-to-day activities in WP2/16 Questions
by OKUBO Sakae 10 Jan '01

10 Jan '01

Source: Rapporteurs for Question D, F, G, 1, 2, 3, 4 Title : Organization of day-to-day activities in WP2/16 Questions Purpose: Information and request for inputs Date : 10 January 2001 This document describes how to organize day-to-day activities of Rapporteur groups for the new study period 2001-2004 based on the e-mail discussion among relevant Rapporteurs. It also requests inputs from members for establishing each Question's workplan consisting of work items, their priorities and target timeframe. 1. Relevant Questions and Rapporteurs D/16 T Taylor <taylor(a)nortel.com> Interoperability of Multimedia Systems and Services F/16 M Buckley <mikebuckley(a)44comms.com> Quality of Service and End-to-end Performance in Multimedia Systems G/16 M Euchner <Martin.Euchner(a)icn.siemens.de> Security of Multimedia Systems and Services 1/16 P Luthi <Patrick_Luthi(a)pictel.com> Multimedia systems, terminals and data conferencing 2/16 P Jones <paulej(a)packetizer.com> Multimedia over packet networks using H.323 systems 3/16 G Freundlich <ggf(a)avaya.com> Infrastructure and interoperability for Multimedia over packet networks 4/16 S Okubo <okubo(a)giti.waseda.ac.jp> Video and data conferencing using Internet-supported services 5/16 to be appointed Mobility for Multimedia Systems and Services For your information, the description of relevant Questions is attached. See http://www.itu.int/ITU-T/com16/questions.html for the whole SG16 Questions. 2. Rapporteur group We start with two groups: - Q1 group: Question 1 - AVD group: Questions D, F, G, 2, 3, 4, 5 (see Item 6 for "AVD") 3. Rapporteur meeting We start with a joint WP2/16 Rapporteur meeting among all the above Questions under WP2/16. We may use any other arrangement when such necessity is recognized. The meeting will be a combination of serial and parallel sessions. Rapporteurs will produce a timetable indicating when a particular topic is going to be discussed during the meeting. 4. Mailing list - Q1 group: Q1 e-mail reflector <tsg16q1(a)itu.int> provided by ITU - AVD group: <ITU-SG16(a)MAILBAG.INTEL.COM> kindly administered by Greg Meyer, Intel <itu-sg16-request(a)mailbag.intel.com> Use of "inband singnalling" is encouraged for posting on particular topics, like [MMQoS], [MMSecurity], [MMMobility]. 5. FTP site - Q1 group: http://standard.pictel.com/ftp/lbc-site/ - AVD group: http://standard.pictel.com/ftp/avc-site/ Both are kindly administered by Patrick Luthi, PictureTel <Patrick_Luthi(a)pictel.com>. The directory names "lbc-site" and "avc-site" are unchanged because of their well-known nature. Each meeting will have its directory according to the current convention: YYMM_Xyz... where YY is the last two digits of the year, MM is the month of the meeting, and Xyz... is derived from the meeting town, full characters for lbc-site, first three characters for avc-site. We may use other directories when such necessity is recognized. 6. Document prefix and numbering - Q1 group: q1x where x represents the meeting number - AVD group: The new prefix is "AVD" standing for Audio, Video and Data. The number starts with AVD-2032 following the last number APC-2031 of the previous study period. 7. Meeting organizer - Q1 group: P Luthi Note that Q1 group meetings will be co-located with AVD meetings. - AVD group A Rapporteur in turn undertakes to organize a Rapporteur meeting. His/her tasks are: * negotiate with the meeting host * issue meeting notice * get approval of the SG16 management for holding the Rapporteur meeting * produce meeting report integrating parts from Questions (issuing a report of each Question separately plus a short general report by the meeting organizer may be the choice?) * send the meeting report to the SG16 management. S Okubo is in charge of the March 2001 meeting. G Freundlich next. 8. Document manager - Q1 group: P Luthi - AVD group Three Rapporteurs (P Jones, G Freundlich, S. Okubo) in turn undertake to manage the input/output documents to/from the meeting. Their tasks are: * register input contributions by assigning AVD or TD numbers * scan viruses of the incoming documents at the ftp site, then move them to the meeting directory after zipping. * produce a list of contributions before the meeting * assign TD numbers during the meeting * organize to dispatch outgoing liaison statements to their destinations P Jones is in charge of the March 2001 meeting. S Okubo next. 9. Advance planning Mr. Freundlich advises the following: We each need to think about where our respective questions should go over the next couple years, the relationships with other questions, etc. The text for the new questions is a good starting point, but at some point it might help to share our thoughts with others involved in the standardization efforts in SG16 (preferably soon so that others can plan their work). Rapporteurs solicit proposals from the SG16 experts to set up the work direction and goals in form of contributions to the March 2001 meeting or posting at the reflectors or both. -------------------- Attachment ----------------------< Question D/16 >---------------------- Question D/16 - Interoperability of Multimedia Systems and Services Background and justification As work on interoperability in the GII demonstrated, the topic of interoperability has several aspects. Three of these may logically be addressed within the context of Mediacom 2004 activity: - interoperability of services, to the extent that they contain equivalent functional elements. For example, the service of "multimedia call transfer" should be fully interoperable with "call transfer" in the legacy telephone network in the degenerate case of an audio-only call; - interoperability of multimedia systems with each other and with the legacy telecommunications network, to the extent to which they provide equivalent services; - measures to enhance interoperability of different implementations of the same multimedia system or service. Other bodies besides ITU-T are developing standards relating to multimedia systems and services. To the extent that the market demands it, methods of interoperation between ITU-T-developed and other standards must be themselves standardized. It is desirable that this work be assigned to a common Question. Study items This Question shall have the following responsibilities: - coordinating with the Question on Multimedia Applications and Services to ensure that the definition of multimedia services and of the services to be provided by new multimedia systems preserves as much consistency as possible with corresponding elements of the services provided by existing multimedia systems and the legacy telephone network; - standardizing the means for interworking between different multimedia systems and between such systems and the legacy telephone network, through additions to Recommendation H.246 and other Recommendations as necessary. Question D/16 has primary and residual responsibility for Recommendation H.246, but may delegate the development of sections of Recommendations dealing with their respective systems to individual questions; - influencing the development of signalling protocols to further the objective of multimedia service interworking across different systems and networks; - coordinating with the Question on Multimedia Architecture to ensure that the architectural framework minimizes the effort required to achieve system interoperability; - investigating methods and developing tools for improving the prospects of interoperability between different implementations of the same multimedia system or service, by means such as the generation of conformance statements or the creation of reference code in the period between determination and decision. Specific task objectives with expected time-frame of completion - Completion of work on interworking between H.323 and H.320, taking into account the possibility of MCU decomposition: late 2001. This task has a dependency on the architectural work item in Question B/16 on review of the H.245 architecture. - Completion of proposals for improving the interoperability of different implementations of systems and services developed under Mediacom 2004: late 2001. - Implementation of these proposals: 2002. Relationships - Work on multimedia systems and services in other Questions of this Study Group, Study Groups 8 and 9, and ITU-R. - Study Groups 2 and 11, for service definitions. - Study Group 11, for signalling. - Related groups in the IETF (particularly including the IPTEL, SIP, SIGTRAN and MEGACO Working Groups). - IMTC, for interoperability testing. - ISO SC 29 MPEG. - ETSI TIPHON. ----------------------< Question F/16 >---------------------- Question F/16 - Quality of Service (QoS) and End-to-End Performance in Multimedia Systems Background and justification ITU-T Study Group 16 has focused on the H.300-series standardization of tele-time audiovisual conversational services and systems, such as videoconferencing and video telephony, over various types of networks. In past work, either a high level of QoS was assumed to be provided by the network (H.320/ISDN) or the network was assumed to have no ability to provide QoS (H.323 V1/LANs). Looking forward, MM will be most frequently operated over packet networks that support various types of QoS features, including but not limited to ATM QoS services and IP QoS services. The general topic of how MM systems and coders interact with and request QoS from the network and how this relates to end-to-end performance requires further study. Study Items - QoS needs of MM systems and coders. - Preferred signalling methods for QoS in MM systems. - Study of methods to provide better QoS in lossy networks, including routed packet networks and mobile networks. - Common API or interfaces to different QoS signalling methods. - End-to-end latency and QoS. - Other aspects of end-to-end performance as perceived by the user. - Alignment with goals related to Mediacom 2004, IP, GII. Specific task objectives with expected time-frame of completion - Enhanced QoS signalling in H.323/H.225.0 V4. - QoS signalling in possible future terminals (2002+). - Input to terms of reference for audio and video coders that maximize QoS in lossy networks (2000). - Input to ATM Forum, IETF, IMT-2000, and SG 11 on MM QoS needs (2000). Relationships - All project Questions in SG 16. - IETF for Internet QoS RFCs. - ATM Forum and SG 11 for ATM QoS. - SG 16 on Mediacom 2004 project. - SG 13 on IP and GII projects. - SG 12 on performance. - ETSI TIPHON. ----------------------< Question G/16 >---------------------- Question G/16 - Security of Multimedia Systems and Services Background and justification Users, operators, and vendors have always had expectations for the security of telecommunications services and systems. Users have requirements for confidentiality and integrity of their communications and may require authentication of other parties in a session and non-repudiation of transactions undertaken with those other parties. Operators require authentication of users and authorization of their activities in order to carry out proper billing and control of usage of resources. All parties have a stake in correct and reliable operation, even in the face of malicious attacks on system or network integrity. At the same time, security is subject to regulation in the various legal jurisdictions, both to ensure that minimum standards are met and to support enforcement of criminal and other laws. Two factors make security an even more complex issue within the context of Mediacom 2004 than it is elsewhere: the specific nature of multimedia communications (diverse media, multiple streams within one communication), and the use of multimedia communications in the course of e-commerce. While e-commerce puts even greater emphasis on the objectives of confidentiality, integrity, and non-repudiation of communications, it also raises new issues of protection of intellectual property distributed over the telecommunications network. Traditionally, vendors (and the standards from which they work) provide mechanisms for the provision of security. Operators and users are responsible for the development and enforcement of policies which make use of these mechanisms to achieve their respective security objectives. The IETF has a well-developed process for ensuring that the foundations of this division of effort are properly laid: every project within the IETF must consider and explicitly document the security requirements associated with the end-product, ensure that the necessary mechanisms are put into place, and provide advice on the use of those mechanisms and other policy issues associated with the use of the end-product. ITU-T can learn from this process, in order better to serve the needs of the world community. This Question provides a focal point for the introduction of improvements in work on security as reflected in the content of Recommendations produced under Mediacom 2004. At the same time, security is a specialized topic involving a considerable body of specialized knowledge. Even more knowledge is required to ensure security in multimedia communications. This Question serves as a central point from which this special expertise may be applied as needed to individual projects. Study items This Question shall have the following responsibilities: - assisting in the threat analysis of existing and proposed multimedia systems and services; - maintaining Recommendation H.235 as a security framework providing the mechanisms needed to protect multimedia systems and services from identified threats; - maintaining Recommendations H.233, H.234 and T.135; - encouraging the development of documentation within Recommendations on multimedia systems and services, providing guidance on potential threats to security, the mechanisms provided to counter those threats, and the policies which system operators should put in place to use those mechanisms for their intended purpose; - contributing to the work of the Question on Multimedia Architecture to ensure that the architectural framework includes due consideration of functions associated with security; - providing advice on the application of the security framework in specific cases of system design. Specific work items To be completed. Relationships - The team of experts working on this Question will cooperate with and advise the other Questions of this Study Group and multimedia-related Questions of other study groups. They will coordinate with experts working in the area of security in other study groups, and the experts of the Security Area of the IETF. - ETSI TC SEC. ----------------------< Question 1/16 >---------------------- Question 1/16 - Multimedia Systems, Terminals and Data Conferencing (Continuation of parts of Questions 3, 11 and 12/16) Background and justification Since the first set of Recommendations for audiovisual communication systems for N-ISDN environments (H.320) were established in 1990, additional audiovisual communications systems have been developed including the H.324-series of Recommendations for audiovisual communications over the fixed and mobile (wireless) telephone networks and the H.310-series of Recommendations for point-to-point and multipoint on B-ISDN networks. For data sharing in point-to-point and multipoint environments, the T.120-series of recommendations have been developed. Following this, several enhancements with respect to multipoint communication, use of new audio and video coding, security features and use of data conferencing and control continue to be developed in the form of new Recommendations or revision of existing Recommendations. To respond to the market needs, these enhancements (with particular attention to the support of advanced coding technologies, interworking with other terminals accommodated in different networks and enhancements to cover other services) may want to be included in existing audiovisual communications systems Recommendations to assure these existing systems remain competitive in the market place. Study items - Improvements in quality aspects; audio quality, picture quality, delay, hypothetical reference connection and performance objectives, taking account of the studies in relevant SGs. (NOTE - Scope of this question does not include studies of performance measurement.) - Enhancement by use of optional advanced audio and visual coding (e.g. H.26L). - Continued enhancements relative to error protection for use in error-prone environments such as mobile networks. - Specifications necessary for accommodating new services other than conversational services, such as retrieval, messaging, distribution services applicable to the supported Recommendations. - Establishment of Recommendations to support channel aggregation in mobile terminals (H.mml). - Enhancement of existing H-series Recommendations. - Possibility of new multimedia terminal system for all networks. Specific task objectives with expected time-frame of completion - Responsibility of this Question includes: definition of corrigenda or revisions and creation or revision of Implementor Guides for Recommendations H.221, H.222.0, H.222.1, H.223, H.224, H.226, H.230, H.231, H.242, H.243, H.244, H.247, H.281, H.283, H.310, H.320, H.321, H.322, H.324, H.331, T.120 through T.128, T.134, T.135, T.140 and related annexes and appendices. This work will be ongoing throughout the study period. Relationships - Other Questions of SG 16. - ITU-T SG 2 for service aspects and human factors. - ITU-T SG 8 for Telematic aspects. - ITU-T SG 12 for Quality aspects. - ITU-R SG 8 for IMT-2000 aspects. - ISO/IEC SG 29/WG 11 for MPEG aspects. - IMTC. ----------------------< Question 2/16 >---------------------- Question 2/16 - Multimedia over Packet Networks using H.323 Systems (Continuation of Q.13/16) Background and justification ITU-T Study Group 16 has created in H.323 a widely-used system of protocols for MM conferencing and video/Internet telephony over packet networks, including the Internet and LANs. This work is ongoing, and currently focuses on mobility, interactions with SIS/IN, and stimulus-based call signalling in H.323 combined with network control of terminating call services. Study Items This question will cover ongoing work in: 1) H.323; 2) H.225.0; 3) H.450.x; 4) H.332. Other items to be covered include: - Alignment with goals related to Mediacom 2004, IP, GII. - Operation of H.323 systems over all kind of physical layers (cable, xDSL, mobile, etc.). - Negotiation for optimal transport mechanisms, such as H.223 or H.323 Annex C. - Operation in the same fashion in both public and private networks. - Support of Accessibility. - System robustness. - Possibility of new multimedia terminal system for all networks. Specific task objectives with expected time-frame of completion To be completed. Relationships - All framework questions in SG 16 on high rate systems. - IETF for Internet matters. - ATM Forum and SG 11 for ATM QoS. - SG 16 on Mediacom 2004 Project. - SG 13 on IP and GII Projects. - IMTC for interoperability. - TIPHON on requirements and architecture. - TIA. - Audio/Video questions B, C, and D. - SG 15 for xDSL. ----------------------< Question 3/16 >---------------------- Question 3/16 - Infrastructure and Interoperability for Multimedia over Packet Network Systems (Continuation of parts of Q.14/16) Background and justification ITU-T Study Group 16 has created in H.323 a widely-used system of protocols for MM conferencing and video telephony over packet networks, including the Internet and LANs. This work is ongoing, and currently focuses on mobility, interactions with SS7/IN/H.450, and stimulus-based call signalling in H.323 combined with network control of terminating call services. These systems require a supporting infrastructure of MCUs, Gatekeepers, Gateways, MIBs (management information bases), and management tools and methods. Possible future terminals will also make use of this infrastructure, or an extension of it. In addition, H.248 decomposes an H.246 gateway into a Media Gateway Controller and a Media Gateway to facilitate interfacing system to SS7/IN networks, and also for other purposes. The ongoing development of H.248 will be a major work area in ITU-T in the future study period. This work is being done in cooperation with the IETF. Study Items This question considers protocol infrastructure for H.323 and for possible future terminals, including: 1) MCUs; 2) GKs; 3) GWs, including H.248; 4) annexes of H.246 that related to SS7/IN interoperability; 5) annexes of H.246 that relate to H.323 to PSTN interoperability; 6) H.323 to H.323 gateways; 7) MIBs, including H.341; 8) management tools and methods related to H.341; 9) H.245. Specific task objectives with expected time-frame of completion - Updates to H.245. - H.248 V2 and related annexes. - Annexes to H.246. Relationships - All framework questions in SG 16 on high rate systems. - Question 2/16 on H.323. - IETF for Internet matters including MEGACO and IPTEL working groups. - ATM Forum and SG 11 for ATM QoS. - SG 16 on Mediacom 2004 Project. - SG 13 on IP and GII Projects. ----------------------< Question 4/16 >---------------------- Question 4/16 - Video and data conferencing using Internet supported services Background and justification ITU-T Study Group 16 has focused on the H.300- and T.120-series standardization of real-time audiovisual conversational services and systems, such as videoconferencing, videophone and data conferencing, over various types of network. As a platform of those systems, the personal computer (PC) is used more and more to implement not only control functions but also audiovisual coding and presentation. PC is also capable to access rich Internet supported services such as hypertext multimedia data retrieval, e-mail, multimedia file transfer which are becoming widely accepted to make business activities more efficient. The network infrastructure to support the video and data conferencing service is converging to the IP-based one which has been developed to provide Internet services. This Question addresses how to enhance video and data conferencing systems by use of Internet supported services in business situations like conferencing, distance learning and telemedicine. Study Items - Architecture to integrate video and data conferencing functions with Internet supported service functions. - Protocols to implement the above integration. - Mechanism of synchronization between audiovisual and other service presentations. - Multipoint aspects of the integrated systems. - Verification tests for interoperability. - Alignment with goals related to Mediacom 2004, IP, GII Projects. Specific task objectives with expected time-frame of completion - Definition of the service and requirements capture: 2001. - Protocol specifications: 2002. - Interoperability tests: 2003. Relationships - Questions 1/16 and 2/16 for H.300-series systems. - IETF for Internet supported services. - SG 16 on Mediacom 2004 Project. - SG 13 on IP and GII Projects. ----------------------< Question 5/16 >---------------------- Question 5/16 - Mobility for Multimedia Systems and Services Background and justification ITU-T Study Group 16 has created in H.320, H.321, H.322, H.310, H.324 and H.323 a widely-used set of system specifications. Each is specialized to a particular network transport, such as N-ISDN, ATM, packet networks, ISO-ethernet, the GSTN, etc. Increasingly, MM is being used in mobile networks. Substantial work has been done to create a mobile version of H.324, and mobile annexes to H.323 are being developed. Study Items The goal of this question is to: 1) further develop mobility for H.323 and H.324 as needed; 2) ensure that a possible future terminal in its initial version supports mobility; 3) consider protocol support for MM mobility for both user, terminal and service mobility; 4) coordinate with IMT-2000 to avoid duplication of effort; 5) standardize interfaces between an MM terminal, keyboard and display when all are connected by some kind of wireless network, and related protocol support. It should be noted that it is not a goal of this work to create an alternative wireless system to IMT-2000, nor to duplicate IETF IP mobility work. Specific task objectives with expected time-frame of completion - Input to H.323 mobile Annexes. - Input to H.FutureTerminal mobile text or annexes. - Input to H.324 mobile work. - A recommendation for MM interworking between a terminal, keyboard and display. Relationships - All framework questions in SG 16 on high rate systems. - Question 2/16 on H.323. - Question 1/16 on H.324 mobility. - IMT-2000 and other wireless groups and consortiums. - IETF for IP mobility. - SG 16 on Mediacom 2004 Project. - 3GPP and related consortia. -------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0