February 2003 - sg16-avd - lists.packetizer.com

Re: Use of RTCP statistics for estimating QoS of VoIP
by frank.derks＠PHILIPS.COM 16 Apr '03

16 Apr '03

Alan, I have just had a look at the final version sof H.460.9 and I could not find any text that explains the real value of the QoS information that can be transported (not including future extensions of course). This is a real pity, because I do agree that many implementors will not be well informed enough to determine the value of the information from the standard RTCP packets. Regards, Frank Alan Clark <alan(a)TELCHEMY.COM> Sent by: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)echo.jf.INTEL.COM> 2002-11-08 18:29 Please respond to alan To: ITU-SG16(a)echo.jf.INTEL.COM cc: (bcc: Frank Derks/HVS/BE/PHILIPS) Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Classification: Frank I did suggest (via Mike Buckley) that the following be added to H.460.9 however don't know if it was actually included. " It should be noted that RTCP reports were not originally intended to provide accurate QoS metrics but for informative exchanges between endpoints to support possible dynamic configuration. According to RFC1889 (a) received packet count may include duplicate packets and hence it is possible to report negative packet loss (b) reported mean packet-to-packet delay variation (jitter) is averaged over the last 16 received packets and hence provides information only on the 160-480mS period immediately preceding transmission of the RTCP report." I do agree with you that potential implementors may well feel uncomfortable that the Recommendation in its initial form contains information that has little or no value. I am even more concerned that less well informed implementors may accept what is in the Recommendation as being "sufficient" and hence attempt to manage VoIP services with metrics that can be quite misleading. Regards Alan -----Original Message----- From: frank.derks(a)philips.com [mailto:frank.derks@philips.com] Sent: Friday, November 08, 2002 2:46 AM To: alan(a)TELCHEMY.COM Cc: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Alan, I certainly agree that, if the main body of the Recommendation covers metrics that are of little practical use of the recipient of these metrics, the Recommendation can be misleading. Only with the proper background information will the reader be able to distinguish the real value in the particular metrics. I feel somewhat uncomfortable when the main body of a Recommendation provides me with something that is of little value, but which can be extended to include more useful information. A possible way "out of this", is to include some text that clearly explains the situation and that reflects the concerns that were raised and agreed upon. Regards, Frank Bob I appreciate that a mechanism was provided to permit extension of H.460.9 and that it was agreed to incorporate the RTCP Extensions, once standardized. This does make a lot of sense and would definitely accomodate the new metrics when available. The reason behind my email yesterday was that we often find that equipment manufacturers, service providers and network managers don't understand this area as well as those who are actively conducting R&D in this area, and hence in this case they may assume that RFC1889 metrics are "good" for monitoring VoIP QoS since they are contained in H.460.9. This is already a continual re-education process with the metrics in RFC1889 .. their inclusion in H.460.9 will make the task even more difficult. People within the industry have great respect for the ITU, understand that there is an extensive process of technical discussion and review that is part of the process of developing ITU standards, and hence place considerable faith in the technical content of ITU Recommendations. In this specific case H.460.9 contains metrics which are known to be inadequate for the purpose of measuring VoIP QoS and hence there is a risk of deployment of an incorrect or inappropriate element due to its incorporation in an ITU Recommendation. I am not trying to be "difficult" but tried to input essentially the same viewpoints prior to the SG16 meeting and am genuinely concerned over the outcome. Regards Alan Clark -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Robert R. Gilman Sent: Wednesday, November 06, 2002 8:13 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Alan- Mike Buckley brought up the same questions you raise at the last SG16 meeting. I don't believe anyone objects to your arguments, and, in fact, the resulting work, H.460.9, was modified to permit extension to other measures and the exclusion of the current, IETF-standardized, measures. Once the IETF draft you reference becomes a standard, it will be easy to refer to the resulting RFC and to incorporate the resulting measures as appropriate. In the meantime, you have the option to use the existing measures and, through the definition of non-standard elements, any other measures you wish to implement on a permanent or trial basis. It seemed better to set the framework now, so that implementation and use can begin, and to do so in such a way that future improvements may be incorporated quickly and easily. Does this make sense? -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 Alan Clark wrote: > > Paul > > I am responding to the recent SG16 email that encouraged direct input from > those not participating directly in the work of the Study Group. > > One particular recent issue relates to the recent addition of QoS reporting > based on RTCP statistics. We have spent the last three years analyzing and > modeling the effects of IP network impairments on VoIP and would like to > share our experience on this issue. > > RTCP statistics were intended to provide a "rough" real time feedback > between endpoints to give some sense of network quality and facilitate > potential adaptation. IP network impairments are transient in nature and > the "averaged" metrics that RFC1889 produces are as a result very > misleading. The addition of QoS reporting based on RFC1889 metrics is, in > our opinion, a backward step as it infers that these statistics are useful > for VoIP quality estimation whereas they are in fact almost meaningless. > > (i) Packet Loss - counts > RFC1889 counts of loss are not compensated for duplicate packets, hence it > is possible to have incorrect and even negative (!!) loss counts. > > (ii) Packet Loss- distribution > Voice quality is very sensitive to the distribution of packet loss - if 2% > loss occurs but the losses are spread out evenly then with PLC quality would > be affected only marginally, if 1% loss occurs but losses occur during short > intervals (typically the case) then quality can be affected quite > significantly. > RFC1889 does not consider the distribution of lost packets and hence packet > loss numbers can only grossly be equated to call quality (i.e. loss rate of > 20% is bad but you couldn't say for sure if 2% was bad or not) > > (iii) Jitter - metric > The average packet-to-packet delay variation used in RFC1889 does not > properly reflect the effects of congestion related delay changes. For > example > (a) if congesion occurs and a queue starts to fill then delay increases > however the packet-to-packet delay change may be small however the increase > in delay may cause the jitter buffer to resynchronize at some stage. > (b) LAN congestion can cause short term spikes in delay, and hence may lead > to packet discards. The average packet-to-packet delay variation will not > reflect this due to the smoothing effect of the averaging algorithm. > > (iv) Jitter - reporting interval > As jitter is reported as a running average with a scaling factor of 16, an > RTCP report only describes the jitter level during the 200mS or so prior to > the report being generated and says nothing about the jitter level during > the much larger period between reports. > > We have spoken to, and worked with, people in the industry that have been > looking at this issue in detail and have found general agreement with the > comments above. Unfortunately, there are also a fair number of people that > blindly accept that something must be "ok" because it is "in a standard" .. > this obviously raised the concern that incorporating these metrics into the > H series of standards further proliferates this viewpoint. > > Within the IETF AVT group this issue was discussed almost a year ago, and > the group agreed to develop a set of metrics that were more accurate and > appropriate for VoIP QoS reporting purposes. These include measures of > packet loss, packets discarded due to jitter, length and density of bursts > and gaps (of combined loss and discard), delay, call quality metrics... > This is contained in the following:- > > draft-ietf-avt-rtcp-report-extns-01.txt > > I would very much appreciate understanding the technical rationale behind > incorporating RFC1889 based metrics into VoIP QoS reports, given the > comments above. > > Regards > > Alan Clark > Telchemy > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

6 10

Reminder of Q.H/16 Accessibility Rapporteur Meeting. Cutoff date Feb. 26!!
by Gunnar Hellström 25 Feb '03

25 Feb '03

To Experts of ITU-T SG16 Question H: Accessibility to Multimedia Systems and services Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. M. Matsumoto, WP 1/16 Chairman <matsumoto(a)giti.waseda.ac.jp> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> >From G Hellstrom Rapporteur for Q.H/16 <gunnar.hellstrom(a)omnitor.se> ------------------------------------------------------------------- Subject: Reminder of Joint Rapporteur Meeting in Streatley, Berkshire, UK Date: March 18-19 2003 ------------------------------------------------------------------- Dear experts of ITU-T Question H/16. A Rapporteur meeting for ITU-T Q.H/16 Experts will be held in Streatley, Berkshire, UK on March 18-19. The meeting is co-located with a meeting of Q.11/16 in order to get an opportunity to discuss joint matters in the Text over IP area. The cutoff date for booking in the selected hotel, and announcement of your intention to participate is February 26, 18.00 GMT. Details of the meeting can be found in the attached document. Best regards ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Text over IP existing standards- requirements - use cases - solutions
by Gunnar Hellström 21 Feb '03

21 Feb '03

Dear all, The discussion about solutions for text over IP is moving on. One goal for Q.H/16 is to have a requirement spec agreed from the rapporteurs meeting March 18-19 in UK. I have collected some material belonging to this work in www.totalconversation.org - An overview presentation over standards and solutions made for the ATIS seminar on Jan.13. - A small discussion presentation around the proposed requirement spec, a proposed division in use cases and one brief solution. - A draft requirement spec, intended to go as a contribution to the Q.H meeting. Please review the draft requirement spec, and comment directly to me or as contributions to the Q.H meeting. Please also remember to sign up for the announced Q.H/16 rapporteurs meeting not later than Feb. 26. I have noticed that it is good to have a list of already approved standards at hand when discussiong this topic. So: Already approved from standards groups of importance in the TVoIP discussion: -------------------------------------------------------------------------- - ITU-T F.700 Multimedia framework. Appendix 3, Defines media, among them Conversational text in two quality levels T1 and T2. T1 alows 1% errors. T2 allows 0.2 % error rate. - ITU-T F.703 Multimedia Conversation Service Description. Defines among other services Text Telephony and Total Conversation, and gives basic characteristics and requirements. This should be the starting point for the current work. - ITU-T V.18, an automoding text telephony standard including Baudot TTY. When it is specified "V.18 or any of its legacy submodes", it can be interpreted "Baudot TTY" in USA if you want. - ITU-T T.140, a presentation level text conversation protocol based on Unicode. Used in all multimedia environments to add a simple text dialogue to it. The natural choice for any effort to make TTY-like text conversations in other networks. - ITU-T H.323 Annex G Text Conversation and Text SET. Both the text telephone for H.323 VoIP networks, and the text component to add to H.323 Multimedia environment. - IETF RFC 2793, RTP Packetization for T.140. A description of how to pack T.140 text in packets for transmission with the RTP protocol, commonly used for media transmission in both H.323 and SIP multimedia and VoIP. Includes a standardised method for repeating information in sequential packets for increasing reliability. Includes also the MIME registration so that text/t140 can be started in a SIP textphone or multimedia phone. - ITU-T H.248.2 Text and Fax and call discrimination packages for the H.248 gateway protocol. Makes use of V.18, and other standards for discrimination between voice fax and and text telephony on PSTN lines, and has methods for establishing and transmitting text over the IP network with T.140 and RFC 2793. The application of V.18 principles in H.248.2 allows configuration to only support one or a few text telephone types ( e.g. Baudot and native V.18 ) H.248 is one of the dominating gateway architectures for VoIP. - 3GPP 26.235, 22.226, 23.226 reuses T.140 with RFC2793 in SIP connections with text in 3G wireless environments and gatewayes with H.248.2 to TTY and other textphones. - 3GPP 26.226 CTM describes a robust method to transport T.140 text over a voice channel, with possible conversion in both ends to other forms of text telephony, e.g. V.18 or Baudot TTY. Used in GSM wireless networks. These standards form a good base when now defining the application in ToIP. Regards Gunnar ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Presence in LDAP
by Anatoli Levine 19 Feb '03

19 Feb '03

FYI -----Original Message----- From: Tyler Miller Johnson [mailto:trjohns1@email.unc.edu] Sent: Wednesday, February 19, 2003 11:37 AM To: h323forum Subject: [h323forum] Presence in LDAP Dear H323Forum User, I have been following the recent discussions about presence and instant messaging in H.323. I am the editor of a proposed new series of recommendations from ITU-T Study Group 16 on directory services architectures for multimedia conferencing. The architecture has been under review in SG16 for sometime, and we are hoping for ratification in May of this year if all goes well. The architecture is LDAP based and provides a way for users to be listed in directories in a standardized way, allowing searching of enterprise directories, and even searching of directory portals which can find users across the Internet. The architecture also supports the management of users through LDAP, rather than through closed databases associated with gatekeepers or SIP proxies. Early on it became evident that we could easily support presence through this architecture through the addition of a simple attribute. However, we chose not to add that because there already seemed to be confusion in the presence space with competing protocols. We did not want to cloud the issue. In some ways, the LDAP approach to presence is perhaps more scalable as it addresses security and large scale federation (i.e. inter-institutional) dynamics more directly. My question is, should SG16 re-visit this issue in regards to LDAP, or leave it out as it currently stands? Regards, Tyler Johnson Editor, H.LDAP --- You are currently subscribed to h323forum as: alevine(a)radvision.com To unsubscribe send a blank email to leave-h323forum-27275U(a)mail.imtc.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Recommendations from the FS-VDSL Focus Group
by OKUBO Sakae 16 Feb '03

16 Feb '03

*** Forwarded to WP2/16 members. I have failed to take this up *** *** at the San Jose meeting - Sakae OKUBO (WP2/16 chairman) *** At 10:51 +0000 03/02/12, John Magill wrote: >Gentlemen, > >During your Rapporteur meetings this week, I would be grateful if >you would remind the WP2 delegates present of the new SG16 work on >Recommendations for Full Service VDSL. These are: >H.fsv-arch - Full Service VDSL - service architecture and CPE >H.fsv-oamp - Full Service VDSL - Operations, Administration, >Maintenance and Provisioning. >It is intended that these Recommendations will be proposed for >Consent at the May 2003 meeting of SG16, and they will be discussed >at the Focus Group meeting and potential Rapporteur meetings >(subject to interest) in Toronto 4-6 March. > >The latest drafts are available at the ftp site: >ftp://ftp3.itu.int/fsvdsl/ >For information on how to get access to the ftp site and subscribe >to the email reflector, see: >http://www.itu.int/ITU-T/studygroups/com16/fs-vdsl/edh-info.html > >The Associate Rapporteurs for this work are: >Associate Rapporteur for architecture Recommendation (Q.B) - Stephane >Py <stephane.py(a)rd.francetelecom.com> >Associate Rapporteur for OAM&P Recommendation (Q.C) - Peter Adams ><p.f.adams(a)btopenworld.com> > >Comments or questions on the drafts should be sent to the Associate >Rapporteurs, or to the reflector <fsvdsl-fg(a)itu.int>. > >I am also happy to take comments and general questions. > >Thanks for your help. I hope you are having a productive meeting. > >Best regards > >John > > > >----------------------------------------------------- >John Magill >Tel: +44 1666 510105 >Fax: +44 8700 527645 >Email: johnmagill(a)probecom.co.uk >----------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Outcome of the San Jose meeting
by OKUBO Sakae 15 Feb '03

15 Feb '03

Dear SG16 experts, The meeting reports of the just finished Q.D,F,G,2-5/16 meeting in San Jose are found at the following place: http://standard.pictel.com/ftp/avc-site/0302_San/TD-11.zip Q.F http://standard.pictel.com/ftp/avc-site/0302_San/TD-12a.zip Q.G http://standard.pictel.com/ftp/avc-site/0302_San/TD-13c.zip Q.2 http://standard.pictel.com/ftp/avc-site/0302_San/TD-14b.zip Q.3 http://standard.pictel.com/ftp/avc-site/0302_San/TD-15a.zip Q.4 -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) 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 GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

New ITU-T templates for documents
by OKUBO Sakae 13 Feb '03

13 Feb '03

---< Message from ITU-TSB >--- Dear all, As it was kindly pointed out to us, although you were informed about the existance of new templates (http://www.itu.int/ITU-T/studygroups/templates), there was no follow-up about their use. You may notice that the "Author's template" is just a plain table requesting to input certain information and later the text of the document. All documents (white, delayed, TDs) will be based on this same template. When they reach the TSB, a macro is applied in order to "transform" it into the appropriate type of document (only after this the ITU logo, headers, etc of the final published document will appear). This was implemented in order to avoid any changes that the document might have suffered when the TSB template was used. Please note that the aforementioned macro is *internal* to the TSB, they are not available to you, as many delegates expressed strong reservations against documents that have embedded macros. In a nutsheel, what is required of the authors is that you fill in (or fill out :-) the simple Winword table as provided in the template, and we will take care of the rest. Please, do not change its format (no more, no less rows or columns!). If you have any questions please feel free to contact me. Best regards Ms. Leslie Jones, Assistant ITU-T Study Group 16 International Telecommunication Union Place des Nations 1211 Geneva 20 Switzerland Tel: +41 22 730 5808 Fax: +41 22 730 5853 e-mail: leslie.jones(a)itu.int Study Group 16 e-mail: tsbsg16(a)itu.int ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: H323 for Instant Message and Presence information suppo rt?
by Ahmar Ghaffar 13 Feb '03

13 Feb '03

Markku, I gave some thought to this idea and i discussed this with Paul too a couple of months ago. My opinion is that Instant Messaging would be a bit too shall we say "heavy" on the H.323 protocol. Besides i think the scope of IM and SMS is quite different. Of course you can incorporate IM in H.323 but the question is, is this service really needed in H.323? What do you think? . The reason i took up SMS was that this service is already quite popular (also MMS now) and other signalling protocols are supporting somewhat similar services. If H.323 is to survive then it has to have a similar service. Another reason was that many vendors are supporting SMS in their own proprietary ways, so i thought why not define a standard which everybody can use. So in my opinion IM is not really so important from H.323 perspective. However i would give some serious thought to Presence Notification. Because this would be a really useful service. Maybe i can take this up when we are done with the SMS spec. :-) Regards Ahmar ----- Original Message ----- From: "Markku Korpi" <korpim(a)cosini.com> To: "Ahmar Ghaffar" <ghaffar(a)snom.de> Sent: Thursday, February 13, 2003 1:35 PM Subject: FW: H323 for Instant Message and Presence information suppo rt? > Ahmar, > > this email appeared on the ITU-T SG16 reflector just a couple of minutes > ago, after I sent out the previous email. > IM is diferent than SMS, of course, but what would it mean if we would > defiem IM over H.323 and use it also for SMS? > Could it be used for interworking with SMS, too? > > Markku > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Anatoli Levine > Sent: Tuesday, February 11, 2003 8:50 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: FW: [HvS] H323 for Instant Message and Presence information > suppo rt? > > > Interesting question - anyone wants to take a stub at it? > > Thanks, > Anatoli > > -----Original Message----- > From: Xiaotao Wu [mailto:xiaotaow@hotmail.com] > Sent: Tuesday, February 11, 2003 11:41 AM > To: Hvs(a)packetizer.com > Subject: [HvS] H323 for Instant Message and Presence information > support? > > > In the article "H.323 versus SIP: A Comparison", seems a very important > aspect of Internet Telephony prodcut (NOTE: not Telephony product) is missed > > -- how easily to integrate the H323 or SIP products with the other Internet > services? > > Is there any effort in H323 on supporting Instant Message and presence > information -- an important and convinient service over the Internet? > Or we have to say that any H323 terminal has to have a separate messenger > with it for IM and presence information, and any H323 proxy has to have a > separate presence agent with it. For SIP, with the effort in SIMPLE working > group, this can be easily solved, and it's easy to add a presence agent to a > > SIP proxy server. > > Thanks! > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > _______________________________________________ > H.323-versus-SIP mailing list (hvs(a)packetizer.com) > http://host4.imagelinkusa.net/mailman/listinfo/hvs_packetizer.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

New ITU-T templates for documents
by Campos, Simao 13 Feb '03

13 Feb '03

Dear all, As it was kindly pointed out to us, although you were informed about the existance of new templates (http://www.itu.int/ITU-T/studygroups/templates), there was no follow-up about their use. You may notice that the "Author's template" is just a plain table requesting to input certain information and later the text of the document. All documents (white, delayed, TDs) will be based on this same template. When they reach the TSB, a macro is applied in order to "transform" it into the appropriate type of document (only after this the ITU logo, headers, etc of the final published document will appear). This was implemented in order to avoid any changes that the document might have suffered when the TSB template was used. Please note that the aforementioned macro is *internal* to the TSB, they are not available to you, as many delegates expressed strong reservations against documents that have embedded macros. In a nutsheel, what is required of the authors is that you fill in (or fill out :-) the simple Winword table as provided in the template, and we will take care of the rest. Please, do not change its format (no more, no less rows or columns!). If you have any questions please feel free to contact me. Best regards Ms. Leslie Jones, Assistant ITU-T Study Group 16 International Telecommunication Union Place des Nations 1211 Geneva 20 Switzerland Tel: +41 22 730 5808 Fax: +41 22 730 5853 e-mail: leslie.jones(a)itu.int Study Group 16 e-mail: tsbsg16(a)itu.int ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Notice of Q.H/16 Accessibility Rapporteur Meeting
by Gunnar Hellström 12 Feb '03

12 Feb '03

To Experts of ITU-T SG16 Question H: Accessibility to Multimedia Systems and services Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. M. Matsumoto, WP 1/16 Chairman <matsumoto(a)giti.waseda.ac.jp> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> >From G Hellstrom Rapporteur for Q.H/16 <gunnar.hellstrom(a)omnitor.se> ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Streatley, Berkshire, UK Date: March 18-19 2003 ------------------------------------------------------------------- Dear experts of ITU-T Question H/16. A Rapporteur meeting for ITU-T Q.H/16 Experts will be held in Streatley, Berkshire, UK on March 18-19. The meeting is co-located with a meeting of Q.11/16 in order to get an opportunity to discuss joint matters in the Text over IP area. Details of the meeting can be found in the attached document. Best regards ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0