- sg16-avd - lists.packetizer.com

Re: Two documents at /0105_Por
by OKUBO Sakae 26 Apr '01

26 Apr '01

Dear Mr. Sayre, > > 2) WhitePaperMMGateway.zip -- "Multimedia Support Using the > > Decomposed $B!! (BGateway Architecture" by Mr. Clifford Sayre et al > >I just wanted to clarify the status and intent of item #2. I do intend to >present this document at the Porto Seguro meeting. It will be a Delay >Contribution with a source of Lucent Tech. Lucent needs to have this >approved by the US government process (SGD) for approving company >contributions to ITU SG 16 meetings and I am working this process in >conjunction with Terry Anderson (the lead Lucent delegate). > >The purpose of the document is to answer some delegate questions and >issues raised in the Launceston meeting on contribution AVD-2057. Thus it >is for discussion and the text will not go directly into the draft H.248 >annex that I am working on. Sorry about using the term "white paper". I >realized after reading your email that the term white paper has had a >different meaning in the context of SG 16 documents. Thank you for your clarification. When your delayed contribution is provided, I will replace WhitePaperMMGateway.zip with that. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

silenceSuppression in h2250LogicalChannelParameters
by Frank Derks 25 Apr '01

25 Apr '01

Can any one explain what the meaning of the silenceSuppression element in h2250LogicalChannelParameters is? If set to TRUE, does this indicate that silence suppression is supported on the channel, but that this is actually dependent on the support of this functionality by the codec? So why duplicate the information? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

potential change to SCTP
by Glen Freundlich 25 Apr '01

25 Apr '01

Dear Colleagues, There are apparently are some problems with the checksum mechanism defined in SCTP. If a new mechanism is deemed necessary, a new RFC could be issued and it would likely not be backward compatible with RFC 2960. This may effect any work in SG16 that references SCTP. Discussions of SCTP are taking place over either the sigtran mailing list or the tsv mailing list. Check the IETF site to find contact info on these working groups. Regards, Glen

1 0

Message from Mr. Bigi
by OKUBO Sakae 25 Apr '01

25 Apr '01

Dear SG16 experts, We have been advised as follows: >Dear Colleagues, > >I am leaving for Study Group 13 meeting in Caracas on 11 May. I would >appreciate if you could send your documents, if possible, by 10 May. I >would also be thankful if you could let the editors and other participants >know. > >Best regards > >Fabio Bigi >TSB, Senior Counsellor Your kind cooperation is requested. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.MMS.3: Presence and IM for H.323 Mobile systems.
by SAMOU Jean-claude FTRD/DAC/ISS 24 Apr '01

24 Apr '01

Hi, Folks: I fully support what Roy is saying here. I assume that H.MMS.3 as well as H.MMS.2 will be based on H.MMS.1 protocol extensions. My understanding is that this 'new' H.MMS.1 protocol should be designed in a way that it is applicable not only to H.323 but to other applications protocols (e.g., H.234, H.310) as well. This will give more flexibility since it will not be specific to a particular application (i.e. no need of having a specific mobility management protocol for H.323, another one for H.324, etc.). Therefore, this 'new' protocol should be made independent as much as possible of others and not be called as H.225.0 annex G or its extension. Please also see an earlier message sent by François Bougant which gives more clarification on these issues. I appreciate this good start of Q5/16 work. Best regards, Jean-Claude Samou FTR&D -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 17 avril 2001 15:25 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi, Manoj: I am providing a very quick comment. It is a good proposal and you are assuming that H.MMS.1 will be the base protocol to be used. With respect to H.MMS.1 protocol, I like to mention that the mobility management part of H.MMS.1 will be "called" a NEW protocol and will NOT be called as "H.225.0 Annex G or its extension." Based on this assumption, probably you can start your work. As time goes on, more comments will be provided. I appreciate your work. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Monday, April 16, 2001 10:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi All, The purpose of this mail is to initiate work on H.MMS.3 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address Presence and Instant Messaging services in H.323 Mobility multimedia systems. H.MMS.3 standard shall address the architecture, procedures and new message/ information elements to enable H.323 as the transport protocol for Presence and Instant Messaging in mobile environment. As editor of H.MMS.3 document, I solicit contributions and discussions to begin work in this area. Enclosed is the Scope and Terms of Reference document that was presented in SG16 Launceston meeting for H.MMS.3. thanks Manoj Paul. Trillium Digital Systems, (an Intel company). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

Re: H.MMS.3: Presence and IM for H.323 Mobile systems.
by Paul, Manoj 22 Apr '01

22 Apr '01

Hi Chern, According to my understanding, when you say "Context Transfer", it refers to some protocol having procedures and methods to trasfer the "Context". And in IM and Presence, this context is the relevant IM and Presence information. Is that understanding correct? If yes, then the H.MMS.3 will define the methods and procedures in H.323 protocol to enable H.323 to act as a "Context Transfer" protocol.(Like SIP defines new methods SUBSCRIBE etc. to act as transport protocol for IM and Presence). I think the concept of IM and Presence shall be derived from IETF IMPP, but work needs to be done to define their mapping in context of H.323 signalling. Could you elaborate when you said "Hopefully some meaningful protocol name would be link to it.Example (M.RCTP - Robust Context Transfer Protocol)". thanks Manoj. -----Original Message----- From: cny [mailto:cny@DCS.SHEF.AC.UK] Sent: Saturday, April 21, 2001 12:58 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi all, May I know how much this thing will link to IETF BXXP (Blocks Extensible Exchange Protocol), and IETF IMPP (Instant Messaging and Presence Protocol) ????? As for the new protocol mentioned below, I suppose what is normally involved is known as Context Transfer, Hopefully some meaningful protocol name would be link to it. Example (M.RCTP - Robust Context Transfer Protocol) When is the dead line for the Brazil Meeting, I am still rushing out some spec of this new protocol. Cheers Chern Nam Yap ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, April 17, 2001 3:24 PM Subject: Re: H.MMS.3: Presence and IM for H.323 Mobile systems. > Hi, Manoj: > > I am providing a very quick comment. It is a good proposal and you are > assuming that H.MMS.1 will be the base protocol to be used. > > With respect to H.MMS.1 protocol, I like to mention that the mobility > management part of H.MMS.1 will be "called" a NEW protocol and will NOT be > called as "H.225.0 Annex G or its extension." > > Based on this assumption, probably you can start your work. > > As time goes on, more comments will be provided. > > I appreciate your work. > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] > Sent: Monday, April 16, 2001 10:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.MMS.3: Presence and IM for H.323 Mobile systems. > > > Hi All, > The purpose of this mail is to initiate work on H.MMS.3 standard, which > is > a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address > Presence > and Instant Messaging services in H.323 Mobility multimedia systems. > H.MMS.3 standard shall address the architecture, procedures and new > message/ > information elements to enable H.323 as the transport protocol for Presence > and > Instant Messaging in mobile environment. > As editor of H.MMS.3 document, I solicit contributions and discussions > to > begin work in this area. Enclosed is the Scope and Terms of Reference > document > that was presented in SG16 Launceston meeting for H.MMS.3. > > thanks > Manoj Paul. > Trillium Digital Systems, (an Intel company). > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Two documents at /0105_Por
by OKUBO Sakae 21 Apr '01

21 Apr '01

Dear SG16 experts, I have placed the following two documents at the Porto Seguro meeting directory http://standard.pictel.com/ftp/avc-site/0105_Por/, 1) H323_AnnexQ.zip -- Draft H.323 Annex Q "Far End Camera Control and H.281 / H.224" by Editor Roni Even 2) WhitePaperMMGateway.zip -- "Multimedia Support Using the Decomposed Gateway Architecture" by Mr. Clifford Sayre et al I wonder if 2) has been, or will be submitted for the Porto Seguro meeting as "white contribution" or is an informational document for the study of experts on the mailing list. For safety, I have dealt it as above. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.MMS.3: Presence and IM for H.323 Mobile systems.
by Roy, Radhika R, ALCOO 21 Apr '01

21 Apr '01

Hi, Manoj: I am providing a very quick comment. It is a good proposal and you are assuming that H.MMS.1 will be the base protocol to be used. With respect to H.MMS.1 protocol, I like to mention that the mobility management part of H.MMS.1 will be "called" a NEW protocol and will NOT be called as "H.225.0 Annex G or its extension." Based on this assumption, probably you can start your work. As time goes on, more comments will be provided. I appreciate your work. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Monday, April 16, 2001 10:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi All, The purpose of this mail is to initiate work on H.MMS.3 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address Presence and Instant Messaging services in H.323 Mobility multimedia systems. H.MMS.3 standard shall address the architecture, procedures and new message/ information elements to enable H.323 as the transport protocol for Presence and Instant Messaging in mobile environment. As editor of H.MMS.3 document, I solicit contributions and discussions to begin work in this area. Enclosed is the Scope and Terms of Reference document that was presented in SG16 Launceston meeting for H.MMS.3. thanks Manoj Paul. Trillium Digital Systems, (an Intel company). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Architectures for Multimedia Gateways
by Sayre, Clifford L, III (Clifford) 20 Apr '01

20 Apr '01

Dear SG 16 Experts, At the Launceston meeting two contributions, AVD-2057 & AVD-2056, were presented proposing enhancements to support interworking for H.324 Annex C terminals and multimedia gateways. AVD-2057 describes several H.248 packages that can be used in a decomposed gateway with an MGC and MG to support this type of multimedia interworking. The delegates in Launceston requested additional information on the background behind these packages; consequently, we have prepared the attached white paper. The white paper describes some of the issues behind supporting multimedia interworking gateways for H.324 & H.323 and thus the rationale for the work behind AVD-2057. <<WhitePaperMultimediaGateways.zip>> Comments are welcome. The co-authors of the white paper are listed on the footer of the paper. Regards, Cliff Sayre Clifford Sayre Lucent Technologies Phone (732) 332-6060 clsayre(a)lucent.com

1 0

Re: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 20 Apr '01

20 Apr '01

Hi, Mike and all: It is good that we have got Question F/16 in SG16 to address end-to-end QOS of multimedia systems. We are now in a position to define the scope of Q.F/16 and then divide the work according to the scope. We have very good insights, as Mike pointed out, after looking into all QOS works across all different ITU-T SGs (e.g., SG16, SG12, SG13), IETF, TIPHON, and other fora. Let us bring contributions in accordance to the charter of Q.F/16 (not just generic contributions) customized per Q.F/16's needs without giving or citing preferences for any particular groups. In this context, H.323 QOS will be a subset of the overall QOS protocol that will used by all multimedia applications. So, the important mind set is that Q.F/16 will develop the end-to-end QOS standards that will be used by all multimedia applications/systems including H.323 (not just only for H.323, IP, or for a particular medium). Let us bring contributions customizing per Q.F/16's needs. Hope this will clarify the things. Best regards, Radhika R. Roy -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, April 20, 2001 8:57 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Gary, Radhika, Tom, Sorry to be a little slow in joining to this interesting thread - I have been out of email contact over the last couple of days. I think we all agree there are two distinct issues here: 1. The Quality of the media stream (this is what we usually refer to when we talk of QoS) 2. The Grade of Service - that is the probability that the call will connect successfully. This is a concept well understood in the circuit switched world but which now needs reinterpreting for IP telephony. I think Gary's comments are correct in that the issue of emergency services is primarily a grade of service issue rather than an issue of the quality of the media stream. As Radhika points out I hope Q.F will qive some guidance on the classification system to be adopted for media stream QoS. The TIPHON categories are a good starting point for speech. So far though TIPHON has not addressed Multimedia and is only just beginning to look at this. Work is also underway in this area in SG12 and SG13 (the latter group from a network perspective). Another important group interested in multimedia classification is 3GPP. So we need to co-ordinate the work of Q.F wilth all these groups which will take a little time. The idea of maybe referring to media classes by number to start with until we can define what these numbers mean is probably a good starting point. Radhika and I were planning to propose a new work item on multimedia classification Q.class at the next Sg16 meeting. The GoS issue is really one of priority in resource reservation within the transport network. Once the resource is committed then the QoS class chosen not the GoS class will determine network performance. Gary's idea of signalling the priority of the call between the User and Service Provider seems a good approach. Within the service provider's domain this request will need to translated to an indication of priority associated with a request for resource reservation to the transport domain at the time of media stream establishment. In a multi domain environment which is very much part of the terms of reference for the work in Q.F) this will involve signalling between service domains and transport domains and possibly between transport domains, and we will need to ensure mechanisms for SD to SD as well as SD to TD. TD to TD is very much the role of the IETF so co-ordination will also be needed here. Again I was planning to start work on defining these signalling require! ments in Q.F. Finally, I agree work has got off to a slow start on Q.F since Geneva. Lack of time to discuss QoS at the last two WG2 meetings has not helped, also my inability to attend the Launceston meeting and the lack of contributions in this area. We will be holding a Q.F session in Brazil though and I hope then to start work on two or three new work items. Hopefully we can make some progress on these and Annex N. All contributions would be very welcome. Mike -----Original Message----- From: Roy, Radhika R, ALCOO [SMTP:rrroy@ATT.COM] Sent: Wednesday, April 18, 2001 6:34 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Hi, Tom and All: I have few comments on: 1. Priority Class, 2. Quality/QOS Class, and 3. Dependency between Priority and Quality 1. Priority Class of a Call Let us define priority classes for a call across all ITU SGs (not ONLY in SG16). If the SG16 is allowed to do define the priority class that will be followed by other SGs, we may then define this in this SG and will be sending liaison to other SGs (because the emergency services standard works span multiple SGs. In addition, there are other areas that we need to look into. For example, the present ISDN standard also defines MLPP where several kinds of priority are offered. (Recently, contributions have also been presented to define priority is SIP in accordance to the MLPP.) 2. Quality/QOS Class of a Call To define quality of a call is being undertaken in Q.F/16. It will take time to define QOS classes or anything like this in Q.F because the definitions of QOS provided in various cases (e.g., SG 13 [Q.4], BICC, TIPHON, IETF, etc) are problematic at the application layer because they are often tied to the network layer. Suggestions are also there whether best, high, medium, or best-effort will mean anything unless we call guaranteed, controlled, or best-effort. The point is that let us continue the discussion of quality in Q.F/16 so that we agree on this. By the way, in Q.F/16, we are considering the quality at the medium level as opposed the per call level. (At one point, we found that classes are becoming problematic. So, we have started to use a matrix where a user will define how each medium will be treated - a kind of preferences [e.g., guaranteed, controlled, or best-effort] without defining explicit classes.) 3. Dependency between Priority and Quality I do not clearly whether there will be any dependency between the priority and quality of a call. Hope this helps. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Wednesday, April 18, 2001 12:41 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Emergency Services and Service classes I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. I would like to propose the following Service Class parameter. ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } } The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0