- sg16-avd - lists.packetizer.com

Input documents to the SG16 meeting
by OKUBO Sakae 07 May '03

07 May '03

Dear contributors, You are kindly requested to upload your documents (Delayed Contribution, Temporary Document) to the Incoming directory of the following ftp site: ftp://standard.pictel.com/avc-site/Incoming They will be moved to http://standard.pictel.com/ftp/avc-site/0305_Gen/ when I have received your advice of uploading. This is to assist advance review of the input documents by the experts with your voluntary efforts, not to mirror the ITU formal site. Needless to say, you shall submit your documents to ITU-T according to the TSB instructions for their consideration at the SG16 meeting. Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* YRP Office 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Rapporteur for Q.3/16
by OKUBO Sakae 30 Apr '03

30 Apr '03

Dear SG16 experts, I am pleased to announce that Mr. Christian Groves, Ericsson, is going to succeed Mr. Terry Anderson as Rapporteur for Q.3/16. He will be formally appointed in this role at the coming SG16 meeting. I would like to thank Terry again for his valuable contributions to SG16. -- Best regards, OKUBO Sakae, WP2 Chair e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* YRP Office 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Info on 11th SDL Forum in Stuttgart from 01-04 July 2003
by Campos, Simao 29 Apr '03

29 Apr '03

Dear colleagues, For your information: The Working Party 3/17 Chairman, also President of the SDL Forum Society, would like you to pass the information to those experts in your Study Groups having interest in SDL (Specification and Description Language). "The SDL Forum Society that collaborates with ITU-T SG17 on languages for telecommunications applications, is holding the 11th SDL Forum in Stuttgart from 01-04 July 2003. This event will interest all users of the System Design Languages of SG17 (SDL - Z.100 series, MSC - Z.120 series, ASN.1 - X.680 series, TTCN - Z.140 series and so on). For more details see: http://www.sdl-forum.org/Events/SDL11.htm" Best regards ===================================================================== Simão Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Tel: +41-22-730-6805 Place des Nations Fax: +41-22-730-5853 Geneva CH1211 - Switzerland E-mail: simao.campos(a)itu.int On the web: www.itu.int/ITU-T/studygroups/com16 ===================================================================== ***** Practice random kindness and senseless acts of beauty ***** ===================================================================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Please remember to use the new ITU-T template (http://www.itu.int /ITU-T/studygroups/templates)
by simao.campos＠itu.int 25 Apr '03

25 Apr '03

Dear all, As you get ready to submit your delayed contributiuons (and to make Leslie's life easier :-), please remember to use the new ITU-T template for contributions that we informed you about in TD01-Plen of the last SG 16 meeting. For delegates, the template for contributions (white & delayed) is really simple to use: just cut and paste the table of the template into your document and fill the table in... that's all. The macros in Leslie's computer will adjust the other parameter (page headers, logo, etc). The template can be found on the web page on the subject of this email, or through the link from the SG 16 web page (under "Guides, Tools and Templates", "New ITU-T Templates"). It is also attached to this email. So ... no excuses :-) Thanks! Simao ===================================================================== Simão Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Tel: +41-22-730-6805 Place des Nations Fax: +41-22-730-5853 Geneva CH1211 - Switzerland E-mail: simao.campos(a)itu.int On the web: www.itu.int/ITU-T/studygroups/com16 ===================================================================== ***** Practice random kindness and senseless acts of beauty ***** =====================================================================

1 0

Fwd:Rapporteur for Q.3/16
by OKUBO Sakae 23 Apr '03

23 Apr '03

*** Posted again as I have not seen it reflected for 24 hours *** *** Apologies if distribution is duplicated *** >Date: Tue, 22 Apr 2003 19:39:30 +0900 >To: itu-sg16(a)lists.intel.com >From: OKUBO Sakae <okubo(a)mxz.mesh.ne.jp> >Subject: Rapporteur for Q.3/16 >X-Biglobe-VirusCheck: Tue, 22 Apr 2003 19:39:36 +0900 > >Dear SG16 experts, > >I am pleased to announce that Mr. Christian Groves, Ericsson, is >going to succeed Mr. Terry Anderson as Rapporteur for Q.3/16. He >will be formally appointed in this role at the coming SG16 meeting. > >I would like to thank Terry again for his valuable contributions to SG16. > >-- >Best regards, > >OKUBO Sakae, WP2 Chair >e-mail: sokubo(a)waseda.jp >Visiting Professor >Graduate School of Science and Engineering >Waseda University >******************************************************************* >YRP Office >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 >******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

FWD: RFC 3508 on H.323 Uniform Resource Locator (URL) Scheme Regi stration
by Campos, Simao 22 Apr '03

22 Apr '03

Dear colleagues, for your information, in the attached. Best regards, Simao ===================================================================== Simão Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Tel: +41-22-730-6805 Place des Nations Fax: +41-22-730-5853 Geneva CH1211 - Switzerland E-mail: simao.campos(a)itu.int On the web: www.itu.int/ITU-T/studygroups/com16 ===================================================================== ***** Practice random kindness and senseless acts of beauty ***** ===================================================================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Draft H.350-series (H.ldap)
by OKUBO Sakae 21 Apr '03

21 Apr '03

Dear SG16 experts, I have placed the following document at the avc-site: http://standard.pictel.com/ftp/avc-site/0305_Gen/Draft_H350-series_030418.z… This contains the following six drafts for your consideration: H.350 Directory Services Architecture for Multimedia Conferencing H.350.1 Directory Services Architecture H.323 H.350.2 Directory Services Architecture for H.235 H.350.3 Directory Services Architecture for H.320 H.350.4 Directory Services Architecture for SIP H.350.5 Directory Services Architecture for non-standard protocols More information on these drafts will be provided by Editor, Mr. Tyler Johnson. Our intention is to update these drafts reflecting your comments and input to the SG16 meeting in May. -- Best regards, OKUBO Sakae, Rapporteur for Q.4/16 e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* YRP Office 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Farewell
by Terry L Anderson 17 Apr '03

17 Apr '03

Many of you know that I (and my entire dept) was cut by Lucent Technologies last fall. I continued to be active in SG16 for a while at my own expense but cannot afford to continue to attend meetings and so have resigned as Rapporteur of Q.3 and will not be able to attend the Geneva meeting next month. I will keep monitoring the mailling lists for a bit, but am not likely to attend meetings in the future unless I ultimately find a job related to SG16. I just want to say good-bye to each of you. I enjoyed very much my work in SG16 over the past several years and enjoyed working with you; many of you have become good friends. I will miss attending the meetings, working with many of you and the great dinners after often late sessions. -- ------------------------------------------------------- Terry L Anderson tlatla(a)verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

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

Integrated report AVD-2345 of the San Jose Meeting
by OKUBO Sakae 03 Apr '03

03 Apr '03

Dear SG16 experts, Thanks to the effort of Mr. Paul Jones, the subject meeting report is now available at the following place: http://standard.pictel.com/ftp/avc-site/0302_San/AVD-2345.zip PS to Mr. Lindbergh, I will make sure to place it at the ITU ftp site after the transfer of avc-site. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.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

Q.H/16 Meeting notes and new Text over IP Requirements spec
by Gunnar Hellstrom 31 Mar '03

31 Mar '03

Draft meeting notes from the ITU-T Q.H/16 "Accessibility" meeting March 18-19 are now available as document number QH16-03014 in the Standards area of www.totalconversation.org An output document with draft edited ToIP requirements is available as document QH16-03013 in the same location. An overview paper on Total Conversation and Text Telephony including wireless aspects, made for a presentation in the CEN/CENELEC/ETSI conference "Accessibility for All" is available in the "White Papers" area of the same site. Best regards Gunnar Hellström ------------------------------------------- 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

Retirement and a New Career
by Folts, Harold 25 Mar '03

25 Mar '03

Greetings, I will be retiring from Government service on March 28 and entering a new career in real estate in Virginia to handle residential properties. It has been a real pleasure to work with you all over the many past years. I will always cherish the many friendships. After a 43-year career in the IT/telecommunications field, I have witnessed a dramatic revolution in technology. I have had the pleasure to work with people from all over the world and visit many countries and enjoy the many different cultures. I will keep these wonderful experiences in my memories through the oncoming years. I greatly appreciate the opportunity to work with you all. If you ever get to the Washington and Northern Virginia area, please give me a call : +1 703 281-0761 email: hal(a)catchingahome.com 400 Holloway Ct. NE Vienna, VA 22180-3545 USA I wish you all the best success in the future. Hopefully, we will see a comprehensive family of telecommunication capabilities for disaster relief become a reality. My warmest regards for all, Hal ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Corrected - Planning the SG16 meeting in May
by OKUBO Sakae 20 Mar '03

20 Mar '03

Dear all, At 18:38 +0900 03/03/20, OKUBO Sakae wrote: >[...]SG16 Chairman and TSB have finalized the framework of the >meeting for issuance of the Collective Letter that will soon be >posted at the ITU-T web site. [...] Now it is available at the following place: http://www.itu.int/md/meetingdoc.asp?type=sitems&lang=e&parent=T01-SG16-COL… -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.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

Re: T.38 potentially broken by recent Corrigendum
by Kevin Boyle 15 Mar '03

15 Mar '03

All, It is my understanding that the ellipsis was intended to be there, and that it wasn't until folks started implementing that it was noticed that it got dropped somewhere between the editor's hands and publication. There was a TD in the Feb 2000 meeting noting this typo. I can produce it if anyone wants to see it. It is also my understanding that care was taken to ensure that all known vendors were made aware of the change at the time. Kevin -----Original Message----- From: Klaghofer Karl ICN EN HS D 11 [mailto:karl.klaghofer@SIEMENS.COM] Sent: Friday, March 14, 2003 3:44 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: T.38 potentially broken by recent Corrigendum Paul, I fully agree with you, that the T.38 (1998) asn.1 and the Revision of T.38 (2002) asn.1 needs to be backwards compatible. Regards, Karl Klaghofer Siemens -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Gesendet: Montag, 3. März 2003 03:21 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: T.38 potentially broken by recent Corrigendum Folks, I just recently discovered that the ITU-T published a corrigendum to T.38 (1998) that apparently breaks backward compatibility for all T.38 devices currently deployed that follow the original 1998 specifications. The particular document in question is Corrigendum 1, which was approved in 2000 and subsequently published in May 2001. You can download the corrigendum document for free from this site: http://www.itu.int/rec/recommendation.asp?type=folders <http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC- T.38> &lang=e&parent=T-REC-T.38 The issue at hand is a change in the ASN.1 syntax found in Annex A/T.38. The particular data structure is shown here: Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end, ... }, field-data OCTET STRING (SIZE(1..65535)) OPTIONAL } The syntactical change was the addition of an ellipsis at the end of the ENUMERATED "field-type". In the published 1998 specification, this ellipsis did not exist. What I would like to know is whether this change impacts your product or not. I am aware of many deployed devices on the market today that employs the 1998 syntax without this ellipsis. I would like to find out to what extent this change is going to present problems for companies represented on various lists and, if I get sufficient support, I want to take a contribution to the ITU-T SG16 meeting in May to try to resolve this problem in such a way as to not break backward compatibility and interoperability. I am looking forward to your replies. Kindest Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

Re: T.38 potentially broken by recent Corrigendum
by Dominic Walker 14 Mar '03

14 Mar '03

FYI, we are currently discussing the issue within the Q.14 e-mail reflector, and the Q.14 experts are looking at a one possible solution that may link a version number to the support of the two ASN.1 version.With this mechanism, version 0 (and possibly version 1) would refer to the ASN.1 definition published in the 06/1998 T.38 spec, and version 2 or higher would refer to the ASN.1 definition published in the 03/2002 T.38 spec. I believe a decision will be made at the Q.14 May 2003 Geneva meeting. Dominic. -----Original Message----- From: Boyle, Kevin [NCRTP:3Z40:EXCH] Sent: Friday, March 14, 2003 2:16 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: T.38 potentially broken by recent Corrigendum All, It is my understanding that the ellipsis was intended to be there, and that it wasn't until folks started implementing that it was noticed that it got dropped somewhere between the editor's hands and publication. There was a TD in the Feb 2000 meeting noting this typo. I can produce it if anyone wants to see it. It is also my understanding that care was taken to ensure that all known vendors were made aware of the change at the time. Kevin -----Original Message----- From: Klaghofer Karl ICN EN HS D 11 [mailto:karl.klaghofer@SIEMENS.COM] Sent: Friday, March 14, 2003 3:44 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: T.38 potentially broken by recent Corrigendum Paul, I fully agree with you, that the T.38 (1998) asn.1 and the Revision of T.38 (2002) asn.1 needs to be backwards compatible. Regards, Karl Klaghofer Siemens -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Gesendet: Montag, 3. März 2003 03:21 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: T.38 potentially broken by recent Corrigendum Folks, I just recently discovered that the ITU-T published a corrigendum to T.38 (1998) that apparently breaks backward compatibility for all T.38 devices currently deployed that follow the original 1998 specifications. The particular document in question is Corrigendum 1, which was approved in 2000 and subsequently published in May 2001. You can download the corrigendum document for free from this site: http://www.itu.int/rec/recommendation.asp?type=folders <http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC- T.38> &lang=e&parent=T-REC-T.38 The issue at hand is a change in the ASN.1 syntax found in Annex A/T.38. The particular data structure is shown here: Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end, ... }, field-data OCTET STRING (SIZE(1..65535)) OPTIONAL } The syntactical change was the addition of an ellipsis at the end of the ENUMERATED "field-type". In the published 1998 specification, this ellipsis did not exist. What I would like to know is whether this change impacts your product or not. I am aware of many deployed devices on the market today that employs the 1998 syntax without this ellipsis. I would like to find out to what extent this change is going to present problems for companies represented on various lists and, if I get sufficient support, I want to take a contribution to the ITU-T SG16 meeting in May to try to resolve this problem in such a way as to not break backward compatibility and interoperability. I am looking forward to your replies. Kindest Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

Re: T.38 potentially broken by recent Corrigendum
by James Rafferty 14 Mar '03

14 Mar '03

Kevin , Glenn Parsons, Dave Duehren and I have all pointed out that the ellipsis was supposed to be there but was dropped by the TSB during publication. We had a Rapporteur's/ Working Party meeting in in Fall 1999 that confirmed the need to reinstate it. The driver for the reinstatement was based on the need we foresaw to extend T.38 to support new features such as V.34 fax. And yes, we all tried to let people know about the issue at the time. But, it did take a while for the ITU to document the change, which has created today's issue. In a related vein, the fax question also saw that there were variations emerging as new T.38 features emerged, such as the TPKT support for TCP/IP, so we agreed to start adding a version to the T.38. New implementations will need to recognize that there are different versions of T.38 in order to gain proper interoperation. IP call control will also need to expose versions during negotiations if interoperability is to be assured. Given where we are, the relevant questions will need to sort this out at the next SG16 meeting in May. Gaining a rough consensus on how to resolve it before then would be a good thing. James -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Friday, March 14, 2003 9:16 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: T.38 potentially broken by recent Corrigendum All, It is my understanding that the ellipsis was intended to be there, and that it wasn't until folks started implementing that it was noticed that it got dropped somewhere between the editor's hands and publication. There was a TD in the Feb 2000 meeting noting this typo. I can produce it if anyone wants to see it. It is also my understanding that care was taken to ensure that all known vendors were made aware of the change at the time. Kevin -----Original Message----- From: Klaghofer Karl ICN EN HS D 11 [mailto:karl.klaghofer@SIEMENS.COM] Sent: Friday, March 14, 2003 3:44 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: T.38 potentially broken by recent Corrigendum Paul, I fully agree with you, that the T.38 (1998) asn.1 and the Revision of T.38 (2002) asn.1 needs to be backwards compatible. Regards, Karl Klaghofer Siemens -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Gesendet: Montag, 3. März 2003 03:21 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: T.38 potentially broken by recent Corrigendum Folks, I just recently discovered that the ITU-T published a corrigendum to T.38 (1998) that apparently breaks backward compatibility for all T.38 devices currently deployed that follow the original 1998 specifications. The particular document in question is Corrigendum 1, which was approved in 2000 and subsequently published in May 2001. You can download the corrigendum document for free from this site: http://www.itu.int/rec/recommendation.asp?type=folders <http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC- T.38> &lang=e&parent=T-REC-T.38 The issue at hand is a change in the ASN.1 syntax found in Annex A/T.38. The particular data structure is shown here: Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end, ... }, field-data OCTET STRING (SIZE(1..65535)) OPTIONAL } The syntactical change was the addition of an ellipsis at the end of the ENUMERATED "field-type". In the published 1998 specification, this ellipsis did not exist. What I would like to know is whether this change impacts your product or not. I am aware of many deployed devices on the market today that employs the 1998 syntax without this ellipsis. I would like to find out to what extent this change is going to present problems for companies represented on various lists and, if I get sufficient support, I want to take a contribution to the ITU-T SG16 meeting in May to try to resolve this problem in such a way as to not break backward compatibility and interoperability. I am looking forward to your replies. Kindest Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

AW: T.38 potentially broken by recent Corrigendum
by Klaghofer Karl ICN EN HS D 11 14 Mar '03

14 Mar '03

Paul, I fully agree with you, that the T.38 (1998) asn.1 and the Revision of T.38 (2002) asn.1 needs to be backwards compatible. Regards, Karl Klaghofer Siemens -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Gesendet: Montag, 3. März 2003 03:21 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: T.38 potentially broken by recent Corrigendum Folks, I just recently discovered that the ITU-T published a corrigendum to T.38 (1998) that apparently breaks backward compatibility for all T.38 devices currently deployed that follow the original 1998 specifications. The particular document in question is Corrigendum 1, which was approved in 2000 and subsequently published in May 2001. You can download the corrigendum document for free from this site: http://www.itu.int/rec/recommendation.asp?type=folders <http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC- T.38> &lang=e&parent=T-REC-T.38 The issue at hand is a change in the ASN.1 syntax found in Annex A/T.38. The particular data structure is shown here: Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end, ... }, field-data OCTET STRING (SIZE(1..65535)) OPTIONAL } The syntactical change was the addition of an ellipsis at the end of the ENUMERATED "field-type". In the published 1998 specification, this ellipsis did not exist. What I would like to know is whether this change impacts your product or not. I am aware of many deployed devices on the market today that employs the 1998 syntax without this ellipsis. I would like to find out to what extent this change is going to present problems for companies represented on various lists and, if I get sufficient support, I want to take a contribution to the ITU-T SG16 meeting in May to try to resolve this problem in such a way as to not break backward compatibility and interoperability. I am looking forward to your replies. Kindest Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Q.H/16 documents on Text over IP for Rapporteur meeting next week
by Gunnar Hellström 14 Mar '03

14 Mar '03

A set of documents from Omnitor, Cisco, Gallaudet University and TR30.1 are available at the informal site for the coming meeting of ITU-T Q.H/16 (Accessibility) next week in UK. A few more are to be provided. The topic of all documents so far is Text over IP. The site is www.totalconversation.org/standard Best regards Gunnar Hellström ------------------------------------------- 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

[H460.9] - Update on status of RTCP Reporting Extensions
by Alan Clark 06 Mar '03

06 Mar '03

Attached is an initial rough pass at an Annex for H.460.9 to incorporate the RTCP Reporting Extensions metrics. My ASN.1 may be a little rusty, hence apologies for any syntax errors. Regards Alan Clark Telchemy PS I mailed this to the reflector yesterday however it appeared not to "reflect". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Text over IP draft Requirements spec available in new version
by Gunnar Hellström 04 Mar '03

04 Mar '03

The draft requirements specification for Text over IP is available in a new version (0.0.5) in http://www.totalconversation.org/standard/index.htm It will be handled as document number QH16-03001 in the coming ITU Q.H/16 meeting in UK on March 18-19, and also for information as Q1103-006. Please provide comments to me, if possible before March 10, or as contributions to the meeting. Best regards Gunnar Hellström ------------------------------------------- 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

T.38 potentially broken by recent Corrigendum
by Paul E. Jones 03 Mar '03

03 Mar '03

Folks, I just recently discovered that the ITU-T published a corrigendum to T.38 (1998) that apparently breaks backward compatibility for all T.38 devices currently deployed that follow the original 1998 specifications. The particular document in question is Corrigendum 1, which was approved in 2000 and subsequently published in May 2001. You can download the corrigendum document for free from this site: http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-… The issue at hand is a change in the ASN.1 syntax found in Annex A/T.38. The particular data structure is shown here: Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end, ... }, field-data OCTET STRING (SIZE(1..65535)) OPTIONAL } The syntactical change was the addition of an ellipsis at the end of the ENUMERATED "field-type". In the published 1998 specification, this ellipsis did not exist. What I would like to know is whether this change impacts your product or not. I am aware of many deployed devices on the market today that employs the 1998 syntax without this ellipsis. I would like to find out to what extent this change is going to present problems for companies represented on various lists and, if I get sufficient support, I want to take a contribution to the ITU-T SG16 meeting in May to try to resolve this problem in such a way as to not break backward compatibility and interoperability. I am looking forward to your replies. Kindest Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com Paul E. Jones

2 1

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