December 2005 - sg16-avd - lists.packetizer.com

AW: Merry Christmas and Happy New Year!
by Sebestyen, Istvan 27 Dec '05

27 Dec '05

Noah, Many thanks!!!! I wish also a Happy New year to you and to the entire Sg16!!!! Kind regards, Istvan Dr. Istvan Sebestyen SIEMENS AG COM GC PS Standards Hofmannstr. 51 81359 München Germany Tel: +49 89 722 47230 Mobile: +49 171 55 16216 Fax: +49 89 722 28139 e-mail: Istvan.sebestyen(a)siemens.com

1 0

Re: H.248.1 - Examples for the Usage of the Statistics Descript
by OKUBO Sakae 26 Dec '05

26 Dec '05

Mr. Schwarz and all, I have created the following directories for the April 2006 meeting of SG16: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/ http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/Working_Docs/ The latter is for any working documents or drafts to facilitate discussion before the submission of Delayed Contributions or Temporary Documents to TSB, and your subject document has been placed there. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Merry Christmas and Happy New Year!
by Noah Luo(罗忠) 22 Dec '05

22 Dec '05

Dear All First of all,I wish everyone merry Xmas and happy new year! Let's celebrate what we have achieved and plan what we should and can do in the coming year 2006 at this happy moment. Let's say goodbye to 2005 and say hello to 2006 and a lot of other things:H.325,Home Network,IPTV,RFID.... With Best Regards 　　　　　　　　 Noah Luo,Ph.D. 　　　　　　　　 Huawei Technologies,Co.,Ltd. Tel:+86-755-28786346 Fax:+86-755-28789166 　　　　　　　　　　2005-12-23

1 0

Fwd:ICNS 2006 || Second Call for Submissions
by OKUBO Sakae 17 Dec '05

17 Dec '05

*** At the first ICNS2005, Mr. Leo Lehmann and Ms. Subha Dhesikan *** *** kindly presented SG16 works on mobility and QoS. -- Sakae OKUBO *** Apologies if you receive multiple copies Second Call for Submissions ICNS 2006 Silicon Valley, July 16-18, 2006 <http://www.iaria.org/conferences/ICNS06.html>http://www.iaria.org/conferences/ICNS06.html The Second International Conference on Networking and Services (ICNS 2006) is organized on July 16-18 2006, in Silicon Valley, California. The ICNS 2006 is targeting general networking and services aspects in multi-technologies environments. The conference covers fundamentals on networking and services, and highlights new challenging industrial and research topics. Ubiquitous services, next generation networks, inter-provider quality of service, GRID networks and services, and emergency services and disaster recovery are considered. The conference has the following independents tracks: ENCOT 2006: Emerging Network Communications and Technologies COMAN 2006: Network Control and Management SERVI 2006: Multi-technology service deployment and assurance NGNUS 2006: Next Generation Networks and Ubiquitous Services MPQSI 2006: Multi Provider QoS/SLA Internetworking GRIDNS 2006: Grid Networks and Services EDNA 2006: Emergency Services and Disaster Recovery of Networks and Applications We welcome technical papers presenting research and practical results, position papers addressing the pros and cons of specific proposals, such as those being discussed in the standard fora or in industry consortia, survey papers addressing the key problems and solutions on any of the above topics short papers on work in progress, workshops, and panel proposals. For submissions, go on the ICNS 2006 page at <http://www.iaria.org/conferences/ICNS06.html>http://www.iaria.org/conferences/ICNS06.html and click "<http://www.iaria.org/conferences/SubmitICNS06.html>Submit a paper". Important dates: Submission deadline: January 20, 2006 Notification of acceptance: February 28, 2006 Camera-ready: March 20, 2006 ICNS Committees ICNS Advisory Committee Cosimo Anglano, Universit$B-(Bdel Piemonte Orientale Alessandra, Italy Prosper Chemouil, France Telecom, France Fabio Chiussi, Invento Networks, Inc., USA Alexander Clemm, Cisco Systems, Inc., USA Jos$B;(BNeuman de Souza, UFC, Brazil Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Luyuan Fang, AT&T, USA Geoffrey Fox, Indiana University, USA Mario Freire, University of Beira Interior, Portugal Wolfgang Gentzsch, MCNC - North Carolina, USA Stein Gjessing, Simula Research Laboratory, Norway Gigi Karmous-Edwards, MCNC, USA Takumi Kimura, NTT Corporation, Japan Paul Labb$B; (B First Secretary, TTCP, Defence R&D, Canada Pascal Lorenz, University Haute Alsace, France Abdelhamid Mellouk, University of Paris XII $B%_(B Val de Marne, France Nikolai Nefedov, Nokia Research Center, Finlad Gerard Parr, University of Ulster, Northern Ireland, UK Bruno Schulze, LNCC/MCT, Brazil Mazin S Yousif, Intel, USA ICNS 2006 Chairs Alan Marshall, Queen's University Belfast, Ireland [ENCOT 2006 Chair] Adolf Finger, Dresden University of Technology, Germany [COMAN Co-Chair] Stefano Giordano, Universit$B/(Bdi Pisa, Italy [COMAN Co-Chair] Bernhard Neumair, University of Gottingen, Germany [SERVI 2006 Co-Chair] Dimitra Simeonidou, University of Essex, UK [SERVI 2006 Co-Chair] Dilip Sarkar, University of Miami, USA [NGNUS 2006 Co-Chair] Emmanuel Bertin, France Telecom, France [NGNUS 2006 Co-Chair] Sakae Okubo, Waseda University, Japan [MPQSI 2006 Chair] Bruno Schulze, LNCC / MCT, Brazil [GRIDNS 2006 Co-Chair] Damien Magoni, University of Strasbourg, France [EDNA 2006 Chair] ICNS 2006 Technical Program Committee Nazim Agoulmine, Universit$B;(Bd'$B!&%_(Bry, France Rui Aguiar, University of Aveiro, Portugal Cosimo Anglano, Universit$B-(Bdel Piemonte Orientale Alessandra, Italy Amy Apon, University of Arkansas, USA Chadi Assi, Concordia University, Canada Tulin Atmaca, Institut National des T$B;M;D(Bommunications, France Michel Barbeau, Carleton University, Canada Jim Basney, University of Illinois at Urbana-Champaign, USA Sujoy Basu, HP Palo-Alto, USA Khalid Al-Begain, University of Glamorgan, UK Emmanuel Bertin, France Telecom, France Benny Bing, Georgia Institute of Technology, USA Fernando Boavida, University of Coimbra, Portugal Jos$B;(BMarcos C. Brito, INATEL, Brazil Wojciech Burakowski, Warsaw University of Technology, Poland Scott Burleigh, NASA Jet Propulsion Laboratory, USA Marco Carli, University of Roma TRE, Italy Augusto Casaca, INESC, Portugal Bruno Chatras, France Telecom, France Claude Chaudet, INRIA, France Serge Chaumette, University of Bordeaux, France Xueqi Cheng, Chinese Acad. of Sciences, China Jeremy de Clercq, Alcatel Research Center, Belgium Prosper Chemouil, France Telecom R&D, France Fabio Chiussi, Invento Networks, Inc., USA Paolo Conforto, Alenia Spazio, Italy Geoff Coulson, Lancaster University, UK Todor Cooklev, San Francisco State University, USA Paul Cotae, The University of Texas at San Antonio, USA Herv$B;(BDebar, France Telecom R&D, France Jeremy de Clercq, Alcatel Research Center, Belgium Jos$B;(BNeuman de Souza, UFC, Brazil Piet Demeester, Universiteit Gent, Belgium Qian Depei, Beihang University, China Dave de Roure, Southampton University, UK Michael Devetsikiotis, North Carolina State University, USA Marios Dikaiakos, University of Cyprus, Cyprus Theo Dimitrakos, BT, UK Peter Dinda, Northwestern University, USA Cosmin Dini, Cisco Systems, Inc., USA Petre Dini, Cisco Systems, Inc., USA Bart Dhoedt, Ghent University Belgium Mari Carmen Domingo, University of Technology (UPC), Spain Hans-Peter Dommel, Santa Clara University, USA Yezid Donoso University del Norte, Colombia Olivier Dugeon, France Telecom, France Sevki Erdogan, University of Hawaii, Hilo, USA Ramon Fabregat, Girona University, Spain Luyuan Fang, AT&T Labs, USA Armando Ferro Vazquez, University of the Basque Country, Spain Olivier Festor, LORIA-INRIA Lorraine, France Adolf Finger, Dresden University of Technology, Germany Geoffrey Fox, Indiana University, USA Matthias Matthew Frank, University of Bonn, Germany Mario Freire, University of Beira Interior, Portugal Steffen Fries, Siemens, Germany Alex Galis, University College London, UK Eric Garcia, University of Franche-Comte, France Emilio Garcia-Palacios, Queen's University Belfast, N. Ireland, UK Rosario Garroppo, Universit$B/(Bdi Pisa, Italy Markus Garschhammer, Leibniz Supercomputing Center, Munich, Germany Stefano Giordano, Universit$B/(Bdi Pisa, Italy Bezalel Gavish, Southern Methodist University, USA Marc Gilg, University of Haute-Alsace, France Wolfgang Gentzsch, D-GRID, Germany Manfred Georg, Washington University in St. Louis, USA Laurent George, Ecole Centrale d'Electronique, France Sorin Georgescu, Ericsson Research, Canada Fabrizio Granelli, University of Trento, Italy Karl-Johan Grinnemo, Karlstad University, Sweden Herv$B;(BGuyennet, University of Franche-Comte, France Abdelhakim Hafid, University of Montreal, Canada Mounir Hamdi, Hong Kong University of Science and Technology, China Salim Hariri, University of Arizona, USA Hermann Hellwagner, Universit$B3U(B Klagenfurt, Austria Pin-Han Ho, University of Waterloo, Canada Neil Hurley, University College Dublin, Ireland Juneseok Hwang, Syracuse University, USA Abbas Jamalipour, University of Sydney, Australia Admela Jukan, Univ. of Illinois at Urbana-Champaign, USA Matthias Kabatnik, University of Stuttgart, Germany Markus Kampmann, Ericsson GmBH, Germany Nirav Kapadia, Capital One, USA Gigi Karmous-Edwards, MCNC, USA Jiro Katto, Waseda University, Japan Xu Ke, Tsinghua University, China Ibrahim Khalil, RMIT University, Australia Takumi Kimura, NTT Corporation, Japan Hartmut K$BAs(Big, University of Cottbus, Germany Christopher Kruegel, Technical University Vienna Paul Labb$B; (B Attach$B;(BDefence R&D Canada, USA Jean-Louis Le Roux, France Telecom, France Laurent Lefevre, INRIA, France Leo Lehmann, Federal Office of Communications, Switzerland Frank Leymann, IBM, Germany Fidel Liberal, Universidad del Pa$B9a(Bg Vasco, Spain Jaime Lloret Mauri, Universidad Polit$B;D(Bnica de Valencia, Spain Pascal Lorenz, University of Haute Alsace, France Ignac Lovrek, University of Zagreb, Croatia Jos$B;(BSoler-Lucas, Research Center COM, Denmark Edmundo Madeira, University of Campinas, Brazil Damien Magoni, University of Strasbourg, France Zoubir Mammeri, University of Toulouse, France Gabriel Mateescu, National Research Council, Canada Jaime Lloret Mauri, Universidad Polit$B;D(Bnica de Valencia, Spain Ina Minei, Juniper Networks, USA Sudip Misra, Carleton University, Canada Melody Moh, San Jose State University, USA Antonella Molinaro, University $B!H(BMediterranea$B!I(B or Reggio Calabria , Italy Edmundo Monteiro, University of Coimbra, Portugal Jo$B5P(B C$B;T(Bar Moura Mota, UFC, Brazil Juan J. Ramos Munoz, Universidad de Granada, Spain Pramila Mullan, France Telecom, France Nikolai Nefedov, Nokia Research Center, Finland Bernhard Neumair, University of G$BAx(Btingen, Germany Mohammad S. Obaidat, Monmouth University, USA Satoru Okamoto, NTT, Japan Sakae Okubo, Waseda University, Japan Jalel Ben Othman, University of Versailles, France Philippe Owezarski, LAAS-CNRS, France Gerard Parr, University of Ulster, Northern Ireland, UK Manuela Pereira, University of Beira Interior, Portugal Christian Perez, INRIA, France Harry Perros, NC State University, USA Antonio Pescap$B; (B University of Napoli "Federico II$B!I(B, Italy Christian Prehofer, DoCoMo Euro-Labs, Germany Andreas Polze, University of Potsdam, Germany Ognjen Prnjat, University College London, UK Francesco Quaglia, University "La Sapienza", Italy Juan J. Ramos Munoz, Universidad de Granada, Spain Danny Raz, Technion, Israel Helmut Reiser, Ludwig-Maximilians-University Munich, Germany Mauricio G. C. Resende, AT&T Labs Research, USA Pierluigi Ritrovato, CRMPA, Italy Joel Rodrigues, University of Beira Interior, Portugal Marcos Rojerio Salvador, CPQD, Brazil Pierre Rolin, France Telecom R&D, France Dumitru Roman, DERI, Austria Paolo Romano, Rome University "La Sapienza$B!I(B, Italy Nikola Rozic, University of Split, Croatia Behcet Sarikaya, UNBC, Canada Dilip Sarkar, University of Miami, USA Bruno Schulze, LNCC / MCT, Brazil Fabrizio Sestini, European Commission, Belgium Karolj Skala, Ruder Boskovic Institute Zagreb, Croatia Dimitra Simeonidou, Univ. of Essex, UK Henk Sips, Technical University, Delft, Netherlands Kurt Stockinger, Lawrence Berkely National Laboratory, USA Sakir Sezer, Queen's University Belfast, N. Ireland, UK Tor Skeie, Simula Labs, Norway Zoran Skocir, University of Zagreb, Croatia Said Soulhi, Ericsson Research, Canada Maciej Stasiak, Poznan University of Technology, Poland Radu State, LORIA-INRIA Lorraine, France Giovanni Stea, Universit$B/(Bdi Pisa, Italy Valerie Elaine Taylor, Texam A&M University, USA Ant$B@m(Bio Lu$B9a(Bg Jesus Teixeira, University of Aveiro, Portugal Do van Thanh, Telenor, Norway Ingebj$BF+!W(Bg Theiss, Simula Labs, Norway Braun Torsten, UNIUBE, Switzerland Elisa Turrini, University of Bologna, Italy Rui Valadas, University of Aveiro, Portugal Teresa Vazao Vasques, INSEC/IST, Portugal Enrique Vazquez, Technical University of Madrid, Spain Armando Ferro Vazquez, University of the Basque Country, Spain Dimitrios Vergados, University of the Aegean, Greece Victor A. Villagra, Technical University of Madrid, Spain Carlos Becker Westphall, Federal University of Santa Catarina, Brazil Steven A. Wright, Bellsouth, USA Ramin Yahyapour, Univ. Dortmund, Germany Homayoun Yousefi$B!G(Bzadeh, University of California, Irvine, USA Mazin S. Yousif, Intel, USA Waider D. Yu, San Jose State University, USA Vlad Zaborovski, Saint-Petersburg Politechnical University, Russia Roland Zalite, Alcatel, France Pavel Zahradnik, Czech Technical University Prague, Czech Republic Arkady Zaslavsky, Monash University, Australia Hans-J$BH+!W(Bgen Zepernik, Blekinge Institute of Technology, Sweden Jun Zheng, University of Ottawa, Canada Looking forward for your submissions, On behalf of the organizing committees Dumitru Roman, Damien Magoni, Joel Rodriques Details: <mailto:petre@iaria.org>petre(a)iaria.org, <mailto:lorenz@ieee.org>lorenz(a)ieee.org ====================================================

1 0

Report of the Geneva meeting AVD-2833
by OKUBO Sakae 16 Dec '05

16 Dec '05

Dear SG16 WP2/16 experts, Mr. Seong-Ho Jeong, meeting organizer, has completed to edit the report of the Q.2,3,4,5,21,22,24 and 25 Rapporteur meeting held in Geneva during 28 November - 2 December 2005. This is now available at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/AVD-2833.zip -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: H.248.1 - Examples for the Usage of the Statistics Descriptor
by Christian Groves 15 Dec '05

15 Dec '05

Hello Albrecht, The contribution certainly covers most use cases. I'm a little concerned that a 20 page appendix is an overkill for the description of statistics. I don't think the setting / resetting / deactivation is sufficiently different from normal properties/parameters to justify this amount of specification. If we go down the approach of document every case for the setting of statistics, do we need another appendix to show everycase for the setting of properties? another one to show call flows for the setting of signals. I think it is better to concentrate of the source of confusion and fix this rather than try to respecify the whole functionality. Unfortunately I couldn't make it to the last meeting to see the depth of confusion. Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: >Dear All! > >With regards to our discussions last WP2/16 meeting and: > > >>This is why I believe contributions are needed to April's meeting. >> >> > >I'd like to inform you that we drafted a contribution with a first >proposal: > >See in >http://ftp3.itu.int/av-arch/avc-site/Incoming/ > >file: > >http://ftp3.itu.int/av-arch/avc-site/Incoming/Alcatelt1%20T05-SG16-060403-D… > >After intensive studies of § 7.1.15 we did finally come to the conclusion >what a new Appendix for H.248.1 on"Practices on Statistics ? Exemplary Use >Cases" could be one way forward. > >Comments? >Albrecht > >PS >Yangbo, >the specific capability you are looking for is in IV.5.7 > > >----- Forwarded message from Kevin Boyle <kboyle(a)nortel.com> ----- > Date: Fri, 2 Dec 2005 10:06:14 -0500 > From: Kevin Boyle <kboyle(a)nortel.com> >Reply-To: Kevin Boyle <kboyle(a)nortel.com> > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >Clarification of statistic reset capability > To: albrecht.schwarz(a)ties.itu.ch, Yangbo Lin <linyangbo(a)huawei.com> > >There is certainly no *documented* capability in H.248 to allow the MGC >to assign a value to a statistic. This is why I believe contributions >are needed to April's meeting. > >Kevin > >-----Original Message----- >From: albrecht.schwarz(a)ties.itu.ch [mailto:albrecht.schwarz@ties.itu.ch] > >Sent: Friday, December 02, 2005 10:03 AM >To: Yangbo Lin >Cc: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin [NCRTP:3Z40:EXCH]; >albrecht.schwarz(a)ties.itu.ch; geoff.hunt(a)bt.com; >arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian Groves >Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >Clarification of statistic reset capability > >Firstly, the MGC as master and "prime served user" for H.248 statistics >may perform any operation(as defined by H.248) on statistics. > >Secondly: > > >>This capability is not in the existing protocol. >> >> >I think that all outlined scenarios in these emails are syntactically, >and even semantically in line with H.248.1. >Could find sth against it in the spec. > >Albrecht > > >Quoting Yangbo Lin <linyangbo(a)huawei.com>: > > > >>In my understanding, the statistic only operated by the MG, and the >>MGC can only disable or enable it. This setting the statistic to zero >>actually give the MGC the capability to interrupt the operation of >>statistic arbitrarily as it will. This capability is not in the >> >> >existing protocol. > > >> ----- Original Message ----- >> From: albrecht.schwarz(a)ties.itu.int >> To: Kevin Boyle >> Cc: Yangbo Lin ; albrecht.schwarz(a)ties.itu.ch ; geoff.hunt(a)bt.com ; >>arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; Christian >> >> >Groves > > >> Sent: Friday, December 02, 2005 3:30 PM >> Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >>Clarification of statistic reset capability >> >> >> Yangbo, >> any "reset" operation comes finally down to the defined "data type" >>and "value >> range" of a dedicated statistic. >> Reset means setting to the "initial value". >> The initial value in the context of statistics is typically either >> a) value = 0, or >> b) value = 'unknown' (e.g., certain VoIP metrics). >> >> Of course the name/value combination in the context of a desired >>reset operation >> makes perhaps only sense for case (a), and I'm fairly sure, is only >>required for >> case (a). >> But I will check out also potential metrics of type (b). >> >> Albrecht >> >> PS >> Do you have already a specific statistic of type (b) in mind? >> >> >> Quoting Kevin Boyle <kboyle(a)nortel.com>: >> >> > The intent is that the statistic will be explicitly set to 0. Of >> > course, other statistics may need to be reset to some other >> >> >default > > >> > value. This puts the onus on the MGC to know what the "reset >> >> >value" of > > >> > all supported statistics are. >> > >> > So, the "0" is not a flag, it is a value. There is no exceptional >> > request here. This syntax is legal, but the way to handle it in >> >> >the MG > > >> > is currently undefined in the spec. >> > >> > Kevin >> > >> > >> > ________________________________ >> > >> > From: Yangbo Lin [mailto:linyangbo@huawei.com] >> > Sent: Friday, December 02, 2005 9:11 AM >> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz(a)ties.itu.ch >> > Cc: geoff.hunt(a)bt.com; albrecht.schwarz(a)ties.itu.ch; >> > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian >>Groves >> > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >> > Clarification of statistic reset capability >> > >> > >> > Maybe I misunderstand, you mean the "SA{pkg/stat1=0}" represents >> > the resetting? Is the "0" a reset flag or only a value? Does it >> >> >request > > >> > the MG to deal with the "0" exceptionally? Moreover, what will >>happen if >> > the "0" is a valid value of the parameter and no resetting value? >> > >> > >> > ----- Original Message ----- >> > From: Kevin Boyle <mailto:kboyle@nortel.com> >> > To: Yangbo Lin <mailto:linyangbo@huawei.com> ; >> > albrecht.schwarz(a)ties.itu.ch >> > Cc: geoff.hunt(a)bt.com ; albrecht.schwarz(a)ties.itu.ch ; >> > arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; >> >> >Christian > > >> > Groves <mailto:cngroves@bigpond.net.au> >> > Sent: Friday, December 02, 2005 2:51 PM >> > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: >> > TD-46-1 6.4 Clarification of statistic reset capability >> > >> > The concept would look like this:(assume pkg/stat1 and >> > pkg/stat2) >> > >> > !/3 [12.34.56.78]:2944 >> > T=123{C=12{MF=term1{AT{SA{pkg/stat1}},SA{pkg/stat1=0,pkg/stat2}}}} >> > >> > This would lead to the following response: >> > >> > !/3 [12.34.56.79]:2944 >> > P=123{C=12{MF=term1{pkg/stat1=123}}} >> > >> > Because this behavior is currently undocumented in the >> > spec, this will require a contribution to Q3 in April. Albrecht >> >> >has > > >> > agreed to bring such a contribution. >> > >> > Kevin >> > >> > >> > ________________________________ >> > >> > From: Yangbo Lin [mailto:linyangbo@huawei.com] >> > Sent: Friday, December 02, 2005 8:45 AM >> > To: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin >> > [NCRTP:3Z40:EXCH] >> > Cc: geoff.hunt(a)bt.com; >> > albrecht.schwarz(a)ties.itu.ch; >> >> >arturo.martin-de-nicolas(a)ericsson.com; > > >> > cdahm(a)cisco.com >> > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; >> > Re: TD-46-1 6.4 Clarification of statistic reset capability >> > >> > >> > Do you mean that a Modify command with three >> > descriptors, i.e. Audit Descriptor (for read), Statistics >> >> >Descriptor > > >> > excluding the statistic (for disable and remain) and Statistics >> > Descriptor including the statistic (for re-enable and reset) in >> >> >order? > > >> > Is it valid in protocol about including two Statistics Descriptors >> >> >in > > >> > one command? >> > >> > >> > ----- Original Message ----- >> > From: albrecht.schwarz(a)ties.itu.int >> > <mailto:albrecht.schwarz@ties.itu.int> >> > To: Kevin Boyle >> > <mailto:kboyle@nortel.com> >> > Cc: geoff.hunt(a)bt.com >> > <mailto:geoff.hunt@bt.com> ; linyangbo(a)huawei.com >> > <mailto:linyangbo@huawei.com> ; albrecht.schwarz(a)ties.itu.ch >> > <mailto:albrecht.schwarz@ties.itu.ch> ; >> > arturo.martin-de-nicolas(a)ericsson.com >> > <mailto:arturo.martin-de-nicolas@ericsson.com> ; cdahm(a)cisco.com >> > <mailto:cdahm@cisco.com> >> > Sent: Friday, December 02, 2005 1:53 PM >> > Subject: 1 Comm. with 2 Descr.;RE: >> > Attach; Re: TD-46-1 6.4 Clarification of statistic reset >> >> >capability > > >> > >> > >> > We did discuss a potential improvement >> > over lunch: >> > >> > 1 Modify Command with an Audit >> > Descriptor (for read) & Statistics Descriptor >> > (for reset) >> > >> > This solution is syntactically correct, >> > requires only a single H.248 Command, >> > and ensure processing in order. >> > >> > I'll bring a correspondent contribution >> > to next meeting for updating IMGs (V2 & V3). >> > >> > - Albrecht >> > >> > Quoting Kevin Boyle <kboyle(a)nortel.com>: >> > >> > > While I think that is a valid >> > optimization, I am not sure we can place >> > > it in the protocol spec. The spec >> > already goes out of its way to >> > > require that transactions, actions and >> > commands are executed in order. >> > > Given this, I am not sure that we can >> > put text in that allows an >> > > explicit exception for this operation. >> > > >> > > This then becomes an implementation >> > detail. As far as I am concerned, >> > > as long as the MG executes the >> > commands (in this case, report the stat >> > > and clear it) it does not really >> > matter whether that is done one command >> > > at a time or in an optimized >> > "one-step" fashion. >> > > >> > > Kevin >> > > >> > > >> > > ________________________________ >> > > >> > > From: geoff.hunt(a)bt.com >> > [mailto:geoff.hunt@bt.com] >> > > Sent: Friday, December 02, 2005 6:40 >> > AM >> > > To: linyangbo(a)huawei.com; Boyle, Kevin >> > [NCRTP:3Z40:EXCH]; >> > > albrecht.schwarz(a)ties.itu.ch >> > > Cc: >> > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com >> > > Subject: RE: Attach; Re: TD-46-1 6.4 >> > Clarification of statistic >> > > reset capability >> > > >> > > >> > > Is it possible to recommend that a >> > gateway which *can* do >> > > lookahead across the commands in a >> > transaction, and sees read-and-reset >> > > commands combined like this, *should* >> > do the read-and-reset atomically? >> > > This could ensure that no value which >> > should contribute to the statistic >> > > is lost between read and reset. >> > > >> > > I'm sorry I don't understand H.248 in >> > enough depth and detail to >> > > know whether there is any fundamental >> > objection to this :( >> > > >> > > ________________________________ >> > > >> > > From: Yangbo Lin >> > [mailto:linyangbo@huawei.com] >> > > Sent: 02 December 2005 11:28 >> > > To: Kevin Boyle; >> > albrecht.schwarz(a)ties.itu.ch >> > > Cc: >> > arturo.martin-de-nicolas(a)ericsson.com; Hunt,RG,Geoff,XDE81 >> > > R; cdahm(a)cisco.com >> > > Subject: Re: Attach; Re: TD-46-1 6.4 >> > Clarification of statistic >> > > reset capability >> > > >> > > >> > > OK, I just ignored this more efficient >> > way, then we have a great >> > > idea and a good example. Now the only >> > leaving problem is how to avoid >> > > the lost about the extreme value >> > between the two command. I hope we can >> > > discuss and resolve it in Q3 as early >> > as possible. >> > > >> > > >> > > ----- Original Message ----- >> > > From: Kevin Boyle >> > <mailto:kboyle@nortel.com> >> > > To: albrecht.schwarz(a)ties.itu.ch >> > > <mailto:albrecht.schwarz@ties.itu.ch> >> > ; Yangbo Lin >> > > <mailto:linyangbo@huawei.com> >> > > Cc: >> > arturo.martin-de-nicolas(a)ericsson.com >> > > >> > <mailto:arturo.martin-de-nicolas@ericsson.com> ; >> >> >geoff.hunt(a)bt.com > > >> > > <mailto:geoff.hunt@bt.com> ; >> > cdahm(a)cisco.com <mailto:cdahm@cisco.com> >> > > Sent: Friday, December 02, 2005 12:05 >> > PM >> > > Subject: RE: Attach; Re: TD-46-1 6.4 >> > Clarification of >> > > statistic reset capability >> > > >> > > I think this is a great idea. I look >> > forward to your >> > > contribution in >> > > April. Maybe you can use the example >> > I cooked up in my >> > > earlier email as >> > > a start! ;) >> > > >> > > Kevin >> > > >> > > -----Original Message----- >> > > From: albrecht.schwarz(a)ties.itu.ch >> > > [mailto:albrecht.schwarz@ties.itu.ch] >> > > >> > > Sent: Friday, December 02, 2005 6:03 >> > AM >> > > To: Yangbo Lin >> > > Cc: albrecht.schwarz(a)ties.itu.ch; >> > Boyle, Kevin >> > > [NCRTP:3Z40:EXCH]; >> > > albrecht.schwarz(a)ties.itu.ch; >> > > arturo.martin-de-nicolas(a)ericsson.com; >> > > geoff.hunt(a)bt.com; cdahm(a)cisco.com >> > > Subject: Re: Attach; Re: TD-46-1 6.4 >> > Clarification of >> > > statistic reset >> > > capability >> > > >> > > See previous eamils. >> > > >> > > Nevertheless, there is a demand for >> > examples in order to >> > > illustrate the >> > > application of the Statistics >> > Descriptor capabilities. >> > > Just the note that I'll draft some >> > examples for next >> > > meeting. >> > > >> > > Albrecht >> > > PS >> > > My motivation is that I think that the >> > Statistics >> > > Descriptor is a fairly >> > > powerful tool due to: >> > > >> > > The Statistics Descriptor may contain, >> > according syntax >> > > specifications >> > > in Annex A and Annex B of H.248.1, >> > either * an empty >> > > list ("empty >> > > Statistics Descriptor"), or * an >> > explicit list of >> > > name/value pairs [NVP; >> > > (statistic name)/(statistic value); >> > statistic name is >> > > defined by >> > > PackageID/StatisticID], or * an >> > explicit list of >> > > statistic names without >> > > correspondent values (note: >> > > statistic value is optional), or >> > > * an explicit list of names and >> > name/value combinations. >> > > This syntactical definition of the >> > protocol allows a >> > > fairly flexible >> > > usage of the Statistics Descriptor. >> > Some examples may >> > > illustrate some >> > > use use cases. >> > > >> > > >> > > >> > > Quoting Yangbo Lin >> > <linyangbo(a)huawei.com>: >> > > >> > > > How can we perform read and/or >> > disable in one command? >> > > The statistic >> > > > included in the descriptor means it >> > should be read, >> > > and the statistic >> > > > excluded from the descriptor means >> > it should be >> > > disable. This seems a >> > > > conflict. So the read, disable and >> > re-enable need >> > > three commands, it >> > > > is too inefficient and do not >> > resolve problem, >> > > especially for the >> > > > extreme parameter. It is just the >> > cause we proposed >> > > the universal >> > > > resetting mechanism which want to >> > resolve the problem >> > > in one command. >> > > > >> > > > ----- Original Message ----- >> > > > From: >> > albrecht.schwarz(a)ties.itu.int >> > > > To: Kevin Boyle >> > > > Cc: albrecht.schwarz(a)ties.itu.ch ; >> > > linyangbo(a)huawei.com ; >> > > > >> > arturo.martin-de-nicolas(a)ericsson.com ; >> > > geoff.hunt(a)bt.com ; >> > > > cdahm(a)cisco.com >> > > > >> > > > Sent: Friday, December 02, 2005 >> > 11:17 AM >> > > > Subject: RE: Attach; Re: TD-46-1 >> > 6.4 Clarification >> > > of statistic >> > > > reset capability >> > > > >> > > > >> > > > I think >> > > > * we should be explicit that the >> > 1st Modify >> > > inherently supports >> > > > "Statistic read" >> > > > operation, in addition to the >> > "disable operation", >> > > > >> > > > and if this is true >> > > > * an additional AuditValue prior >> > to the first Modify >> > > is thus not >> > > > required. >> > > > >> > > > The assumption is that a dedicated >> > Statistics >> > > Descriptor setting in >> > > > the 1st >> > > > Modify allows "read and/or >> > disable" in one step. >> > > > My second assumption is, that the >> > 1st Modify may be >> > > replace by >> > > > AuditValue to get >> > > > adequate "read and/or disable" >> > operations in one >> > > step. >> > > > >> > > > If my understanding is correct, >> > then I'd like to >> > > propose to >> > > > a) replace "to disable" by " to >> > read and/or to >> > > disable", and >> > > > b) replace "the MGC may send a >> > Modify ..." by "the >> > > MGC may send a >> > > > Modify or >> > > > AuditValue ..." >> > > > >> > > > Albrecht >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > Quoting Kevin Boyle >> > <kboyle(a)nortel.com>: >> > > > >> > > > > I like the points raised by your >> > suggested text. >> > > How about this: >> > > > > >> > > > > For terminations not in the NULL >> > Context, the MGC >> > > may send a >> > > Modify >> > > > > Command with a Statistics >> > Descriptor to disable >> > > one or more >> > > statistics >> > > > > followed by a second Modify >> > Command including a >> > > Statistics >> > > > Descriptor to >> > > > > re-enable those statistics. As >> > explained above, >> > > this has the >> > > effect of >> > > > > resetting the included >> > statistics. By bundling >> > > the two commands >> > > > > together into the same action or >> > transaction, the >> > > MGC can minimize >> > > the >> > > > > time during which statistics are >> > not collected by >> > > the MG. >> > > > > >> > > > > If this looks OK, I will alter >> > the IG and upload >> > > it as 46a. >> > > > > >> > > > > Kevin >> > > > > >> > > > > -----Original Message----- >> > > > > From: >> > albrecht.schwarz(a)ties.itu.ch >> > > > >> > [mailto:albrecht.schwarz@ties.itu.ch] >> > > > > >> > > > > Sent: Friday, December 02, 2005 >> > 4:24 AM >> > > > > To: Boyle, Kevin >> > [NCRTP:3Z40:EXCH] >> > > > > Cc: >> > albrecht.schwarz(a)ties.itu.ch; >> > > linyangbo(a)huawei.com; >> > > > > >> > arturo.martin-de-nicolas(a)ericsson.com; >> > > geoff.hunt(a)bt.com; >> > > > > cdahm(a)cisco.com >> > > > > Subject: Attach; Re: TD-46-1 6.4 >> > Clarification of >> > > statistic reset >> > > > > capability >> > > > > >> > > > > Not sure whether attachment was >> > delivered. >> > > > > Again ... >> > > > > >> > > > > >> > > > > Quoting >> > albrecht.schwarz(a)ties.itu.int: >> > > > > >> > > > > > Kevin, >> > > > > > >> > > > > > pls find attached comments to >> > > > > > "6.4 Clarification of >> > statistic reset >> > > capability". >> > > > > > >> > > > > > Like to offer following change >> > proposals: >> > > > > > - "prior to Subtract" (of >> > course it's >> > > semantically correct) >> > > > > > - add AuditValue, >> > > > > > - add one or two Notes in >> > order to incate >> > > Statistic Descriptor >> > > > details >> > > > > >> > > > > > (this is important usage >> > information IMHO) >> > > > > > >> > > > > > Albrecht >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > >> >> >> >> >> > > > > > > >----- End forwarded message ----- > > > > > >

1 0

H.248.1 - Examples for the Usage of the Statistics Descriptor
by Albrecht.Schwarz＠alcatel.de 15 Dec '05

15 Dec '05

Dear All! With regards to our discussions last WP2/16 meeting and: > This is why I believe contributions are needed to April's meeting. I'd like to inform you that we drafted a contribution with a first proposal: See in http://ftp3.itu.int/av-arch/avc-site/Incoming/ file: http://ftp3.itu.int/av-arch/avc-site/Incoming/Alcatelt1%20T05-SG16-060403-D… After intensive studies of § 7.1.15 we did finally come to the conclusion what a new Appendix for H.248.1 on"Practices on Statistics ? Exemplary Use Cases" could be one way forward. Comments? Albrecht PS Yangbo, the specific capability you are looking for is in IV.5.7 ----- Forwarded message from Kevin Boyle <kboyle(a)nortel.com> ----- Date: Fri, 2 Dec 2005 10:06:14 -0500 From: Kevin Boyle <kboyle(a)nortel.com> Reply-To: Kevin Boyle <kboyle(a)nortel.com> Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 Clarification of statistic reset capability To: albrecht.schwarz(a)ties.itu.ch, Yangbo Lin <linyangbo(a)huawei.com> There is certainly no *documented* capability in H.248 to allow the MGC to assign a value to a statistic. This is why I believe contributions are needed to April's meeting. Kevin -----Original Message----- From: albrecht.schwarz(a)ties.itu.ch [mailto:albrecht.schwarz@ties.itu.ch] Sent: Friday, December 02, 2005 10:03 AM To: Yangbo Lin Cc: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz(a)ties.itu.ch; geoff.hunt(a)bt.com; arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian Groves Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 Clarification of statistic reset capability Firstly, the MGC as master and "prime served user" for H.248 statistics may perform any operation(as defined by H.248) on statistics. Secondly: >This capability is not in the existing protocol. I think that all outlined scenarios in these emails are syntactically, and even semantically in line with H.248.1. Could find sth against it in the spec. Albrecht Quoting Yangbo Lin <linyangbo(a)huawei.com>: > In my understanding, the statistic only operated by the MG, and the > MGC can only disable or enable it. This setting the statistic to zero > actually give the MGC the capability to interrupt the operation of > statistic arbitrarily as it will. This capability is not in the existing protocol. > > ----- Original Message ----- > From: albrecht.schwarz(a)ties.itu.int > To: Kevin Boyle > Cc: Yangbo Lin ; albrecht.schwarz(a)ties.itu.ch ; geoff.hunt(a)bt.com ; > arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; Christian Groves > Sent: Friday, December 02, 2005 3:30 PM > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 > Clarification of statistic reset capability > > > Yangbo, > any "reset" operation comes finally down to the defined "data type" > and "value > range" of a dedicated statistic. > Reset means setting to the "initial value". > The initial value in the context of statistics is typically either > a) value = 0, or > b) value = 'unknown' (e.g., certain VoIP metrics). > > Of course the name/value combination in the context of a desired > reset operation > makes perhaps only sense for case (a), and I'm fairly sure, is only > required for > case (a). > But I will check out also potential metrics of type (b). > > Albrecht > > PS > Do you have already a specific statistic of type (b) in mind? > > > Quoting Kevin Boyle <kboyle(a)nortel.com>: > > > The intent is that the statistic will be explicitly set to 0. Of > > course, other statistics may need to be reset to some other default > > value. This puts the onus on the MGC to know what the "reset value" of > > all supported statistics are. > > > > So, the "0" is not a flag, it is a value. There is no exceptional > > request here. This syntax is legal, but the way to handle it in the MG > > is currently undefined in the spec. > > > > Kevin > > > > > > ________________________________ > > > > From: Yangbo Lin [mailto:linyangbo@huawei.com] > > Sent: Friday, December 02, 2005 9:11 AM > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz(a)ties.itu.ch > > Cc: geoff.hunt(a)bt.com; albrecht.schwarz(a)ties.itu.ch; > > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian > Groves > > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 > > Clarification of statistic reset capability > > > > > > Maybe I misunderstand, you mean the "SA{pkg/stat1=0}" represents > > the resetting? Is the "0" a reset flag or only a value? Does it request > > the MG to deal with the "0" exceptionally? Moreover, what will > happen if > > the "0" is a valid value of the parameter and no resetting value? > > > > > > ----- Original Message ----- > > From: Kevin Boyle <mailto:kboyle@nortel.com> > > To: Yangbo Lin <mailto:linyangbo@huawei.com> ; > > albrecht.schwarz(a)ties.itu.ch > > Cc: geoff.hunt(a)bt.com ; albrecht.schwarz(a)ties.itu.ch ; > > arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; Christian > > Groves <mailto:cngroves@bigpond.net.au> > > Sent: Friday, December 02, 2005 2:51 PM > > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: > > TD-46-1 6.4 Clarification of statistic reset capability > > > > The concept would look like this:(assume pkg/stat1 and > > pkg/stat2) > > > > !/3 [12.34.56.78]:2944 > > T=123{C=12{MF=term1{AT{SA{pkg/stat1}},SA{pkg/stat1=0,pkg/stat2}}}} > > > > This would lead to the following response: > > > > !/3 [12.34.56.79]:2944 > > P=123{C=12{MF=term1{pkg/stat1=123}}} > > > > Because this behavior is currently undocumented in the > > spec, this will require a contribution to Q3 in April. Albrecht has > > agreed to bring such a contribution. > > > > Kevin > > > > > > ________________________________ > > > > From: Yangbo Lin [mailto:linyangbo@huawei.com] > > Sent: Friday, December 02, 2005 8:45 AM > > To: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin > > [NCRTP:3Z40:EXCH] > > Cc: geoff.hunt(a)bt.com; > > albrecht.schwarz(a)ties.itu.ch; arturo.martin-de-nicolas(a)ericsson.com; > > cdahm(a)cisco.com > > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; > > Re: TD-46-1 6.4 Clarification of statistic reset capability > > > > > > Do you mean that a Modify command with three > > descriptors, i.e. Audit Descriptor (for read), Statistics Descriptor > > excluding the statistic (for disable and remain) and Statistics > > Descriptor including the statistic (for re-enable and reset) in order? > > Is it valid in protocol about including two Statistics Descriptors in > > one command? > > > > > > ----- Original Message ----- > > From: albrecht.schwarz(a)ties.itu.int > > <mailto:albrecht.schwarz@ties.itu.int> > > To: Kevin Boyle > > <mailto:kboyle@nortel.com> > > Cc: geoff.hunt(a)bt.com > > <mailto:geoff.hunt@bt.com> ; linyangbo(a)huawei.com > > <mailto:linyangbo@huawei.com> ; albrecht.schwarz(a)ties.itu.ch > > <mailto:albrecht.schwarz@ties.itu.ch> ; > > arturo.martin-de-nicolas(a)ericsson.com > > <mailto:arturo.martin-de-nicolas@ericsson.com> ; cdahm(a)cisco.com > > <mailto:cdahm@cisco.com> > > Sent: Friday, December 02, 2005 1:53 PM > > Subject: 1 Comm. with 2 Descr.;RE: > > Attach; Re: TD-46-1 6.4 Clarification of statistic reset capability > > > > > > We did discuss a potential improvement > > over lunch: > > > > 1 Modify Command with an Audit > > Descriptor (for read) & Statistics Descriptor > > (for reset) > > > > This solution is syntactically correct, > > requires only a single H.248 Command, > > and ensure processing in order. > > > > I'll bring a correspondent contribution > > to next meeting for updating IMGs (V2 & V3). > > > > - Albrecht > > > > Quoting Kevin Boyle <kboyle(a)nortel.com>: > > > > > While I think that is a valid > > optimization, I am not sure we can place > > > it in the protocol spec. The spec > > already goes out of its way to > > > require that transactions, actions and > > commands are executed in order. > > > Given this, I am not sure that we can > > put text in that allows an > > > explicit exception for this operation. > > > > > > This then becomes an implementation > > detail. As far as I am concerned, > > > as long as the MG executes the > > commands (in this case, report the stat > > > and clear it) it does not really > > matter whether that is done one command > > > at a time or in an optimized > > "one-step" fashion. > > > > > > Kevin > > > > > > > > > ________________________________ > > > > > > From: geoff.hunt(a)bt.com > > [mailto:geoff.hunt@bt.com] > > > Sent: Friday, December 02, 2005 6:40 > > AM > > > To: linyangbo(a)huawei.com; Boyle, Kevin > > [NCRTP:3Z40:EXCH]; > > > albrecht.schwarz(a)ties.itu.ch > > > Cc: > > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com > > > Subject: RE: Attach; Re: TD-46-1 6.4 > > Clarification of statistic > > > reset capability > > > > > > > > > Is it possible to recommend that a > > gateway which *can* do > > > lookahead across the commands in a > > transaction, and sees read-and-reset > > > commands combined like this, *should* > > do the read-and-reset atomically? > > > This could ensure that no value which > > should contribute to the statistic > > > is lost between read and reset. > > > > > > I'm sorry I don't understand H.248 in > > enough depth and detail to > > > know whether there is any fundamental > > objection to this :( > > > > > > ________________________________ > > > > > > From: Yangbo Lin > > [mailto:linyangbo@huawei.com] > > > Sent: 02 December 2005 11:28 > > > To: Kevin Boyle; > > albrecht.schwarz(a)ties.itu.ch > > > Cc: > > arturo.martin-de-nicolas(a)ericsson.com; Hunt,RG,Geoff,XDE81 > > > R; cdahm(a)cisco.com > > > Subject: Re: Attach; Re: TD-46-1 6.4 > > Clarification of statistic > > > reset capability > > > > > > > > > OK, I just ignored this more efficient > > way, then we have a great > > > idea and a good example. Now the only > > leaving problem is how to avoid > > > the lost about the extreme value > > between the two command. I hope we can > > > discuss and resolve it in Q3 as early > > as possible. > > > > > > > > > ----- Original Message ----- > > > From: Kevin Boyle > > <mailto:kboyle@nortel.com> > > > To: albrecht.schwarz(a)ties.itu.ch > > > <mailto:albrecht.schwarz@ties.itu.ch> > > ; Yangbo Lin > > > <mailto:linyangbo@huawei.com> > > > Cc: > > arturo.martin-de-nicolas(a)ericsson.com > > > > > <mailto:arturo.martin-de-nicolas@ericsson.com> ; geoff.hunt(a)bt.com > > > <mailto:geoff.hunt@bt.com> ; > > cdahm(a)cisco.com <mailto:cdahm@cisco.com> > > > Sent: Friday, December 02, 2005 12:05 > > PM > > > Subject: RE: Attach; Re: TD-46-1 6.4 > > Clarification of > > > statistic reset capability > > > > > > I think this is a great idea. I look > > forward to your > > > contribution in > > > April. Maybe you can use the example > > I cooked up in my > > > earlier email as > > > a start! ;) > > > > > > Kevin > > > > > > -----Original Message----- > > > From: albrecht.schwarz(a)ties.itu.ch > > > [mailto:albrecht.schwarz@ties.itu.ch] > > > > > > Sent: Friday, December 02, 2005 6:03 > > AM > > > To: Yangbo Lin > > > Cc: albrecht.schwarz(a)ties.itu.ch; > > Boyle, Kevin > > > [NCRTP:3Z40:EXCH]; > > > albrecht.schwarz(a)ties.itu.ch; > > > arturo.martin-de-nicolas(a)ericsson.com; > > > geoff.hunt(a)bt.com; cdahm(a)cisco.com > > > Subject: Re: Attach; Re: TD-46-1 6.4 > > Clarification of > > > statistic reset > > > capability > > > > > > See previous eamils. > > > > > > Nevertheless, there is a demand for > > examples in order to > > > illustrate the > > > application of the Statistics > > Descriptor capabilities. > > > Just the note that I'll draft some > > examples for next > > > meeting. > > > > > > Albrecht > > > PS > > > My motivation is that I think that the > > Statistics > > > Descriptor is a fairly > > > powerful tool due to: > > > > > > The Statistics Descriptor may contain, > > according syntax > > > specifications > > > in Annex A and Annex B of H.248.1, > > either * an empty > > > list ("empty > > > Statistics Descriptor"), or * an > > explicit list of > > > name/value pairs [NVP; > > > (statistic name)/(statistic value); > > statistic name is > > > defined by > > > PackageID/StatisticID], or * an > > explicit list of > > > statistic names without > > > correspondent values (note: > > > statistic value is optional), or > > > * an explicit list of names and > > name/value combinations. > > > This syntactical definition of the > > protocol allows a > > > fairly flexible > > > usage of the Statistics Descriptor. > > Some examples may > > > illustrate some > > > use use cases. > > > > > > > > > > > > Quoting Yangbo Lin > > <linyangbo(a)huawei.com>: > > > > > > > How can we perform read and/or > > disable in one command? > > > The statistic > > > > included in the descriptor means it > > should be read, > > > and the statistic > > > > excluded from the descriptor means > > it should be > > > disable. This seems a > > > > conflict. So the read, disable and > > re-enable need > > > three commands, it > > > > is too inefficient and do not > > resolve problem, > > > especially for the > > > > extreme parameter. It is just the > > cause we proposed > > > the universal > > > > resetting mechanism which want to > > resolve the problem > > > in one command. > > > > > > > > ----- Original Message ----- > > > > From: > > albrecht.schwarz(a)ties.itu.int > > > > To: Kevin Boyle > > > > Cc: albrecht.schwarz(a)ties.itu.ch ; > > > linyangbo(a)huawei.com ; > > > > > > arturo.martin-de-nicolas(a)ericsson.com ; > > > geoff.hunt(a)bt.com ; > > > > cdahm(a)cisco.com > > > > > > > > Sent: Friday, December 02, 2005 > > 11:17 AM > > > > Subject: RE: Attach; Re: TD-46-1 > > 6.4 Clarification > > > of statistic > > > > reset capability > > > > > > > > > > > > I think > > > > * we should be explicit that the > > 1st Modify > > > inherently supports > > > > "Statistic read" > > > > operation, in addition to the > > "disable operation", > > > > > > > > and if this is true > > > > * an additional AuditValue prior > > to the first Modify > > > is thus not > > > > required. > > > > > > > > The assumption is that a dedicated > > Statistics > > > Descriptor setting in > > > > the 1st > > > > Modify allows "read and/or > > disable" in one step. > > > > My second assumption is, that the > > 1st Modify may be > > > replace by > > > > AuditValue to get > > > > adequate "read and/or disable" > > operations in one > > > step. > > > > > > > > If my understanding is correct, > > then I'd like to > > > propose to > > > > a) replace "to disable" by " to > > read and/or to > > > disable", and > > > > b) replace "the MGC may send a > > Modify ..." by "the > > > MGC may send a > > > > Modify or > > > > AuditValue ..." > > > > > > > > Albrecht > > > > > > > > > > > > > > > > > > > > > > > > Quoting Kevin Boyle > > <kboyle(a)nortel.com>: > > > > > > > > > I like the points raised by your > > suggested text. > > > How about this: > > > > > > > > > > For terminations not in the NULL > > Context, the MGC > > > may send a > > > Modify > > > > > Command with a Statistics > > Descriptor to disable > > > one or more > > > statistics > > > > > followed by a second Modify > > Command including a > > > Statistics > > > > Descriptor to > > > > > re-enable those statistics. As > > explained above, > > > this has the > > > effect of > > > > > resetting the included > > statistics. By bundling > > > the two commands > > > > > together into the same action or > > transaction, the > > > MGC can minimize > > > the > > > > > time during which statistics are > > not collected by > > > the MG. > > > > > > > > > > If this looks OK, I will alter > > the IG and upload > > > it as 46a. > > > > > > > > > > Kevin > > > > > > > > > > -----Original Message----- > > > > > From: > > albrecht.schwarz(a)ties.itu.ch > > > > > > [mailto:albrecht.schwarz@ties.itu.ch] > > > > > > > > > > Sent: Friday, December 02, 2005 > > 4:24 AM > > > > > To: Boyle, Kevin > > [NCRTP:3Z40:EXCH] > > > > > Cc: > > albrecht.schwarz(a)ties.itu.ch; > > > linyangbo(a)huawei.com; > > > > > > > arturo.martin-de-nicolas(a)ericsson.com; > > > geoff.hunt(a)bt.com; > > > > > cdahm(a)cisco.com > > > > > Subject: Attach; Re: TD-46-1 6.4 > > Clarification of > > > statistic reset > > > > > capability > > > > > > > > > > Not sure whether attachment was > > delivered. > > > > > Again ... > > > > > > > > > > > > > > > Quoting > > albrecht.schwarz(a)ties.itu.int: > > > > > > > > > > > Kevin, > > > > > > > > > > > > pls find attached comments to > > > > > > "6.4 Clarification of > > statistic reset > > > capability". > > > > > > > > > > > > Like to offer following change > > proposals: > > > > > > - "prior to Subtract" (of > > course it's > > > semantically correct) > > > > > > - add AuditValue, > > > > > > - add one or two Notes in > > order to incate > > > Statistic Descriptor > > > > details > > > > > > > > > > > (this is important usage > > information IMHO) > > > > > > > > > > > > Albrecht > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- End forwarded message -----

1 0

Fwd:Tree structure view of available meeting documents
by OKUBO Sakae 06 Dec '05

06 Dec '05

*** This looks a great improvement -- Sakae OKUBO *** >Subject: Tree structure view of available meeting documents >Date: Tue, 6 Dec 2005 18:17:23 +0100 >Thread-Topic: Tree structure view of available meeting documents >Thread-Index: AcX6h9Xig12CLb9CSr648izhtHDt6wAAMVpw >From: <simao.campos(a)itu.int> >To: <t05sg16mgt(a)ties.itu.int>, <tsg6mgt(a)ties.itu.int> >Sender: owner-t05sg16mgt(a)itu.int >Reply-To: <simao.campos(a)itu.int> >X-Greylist: Sender IP whitelisted, not delayed by >milter-greylist-2.0.2 (mail4.itu.ch [156.106.192.20]); Tue, 06 Dec >2005 18:18:04 +0100 (MET) >X-Biglobe-VirusCheck: Wed, 07 Dec 2005 02:18:10 +0900 > >Dear colleagues, > >you may find this way of checking meeting documents more convenient >than before. Please share it with experts in your Qs. Specific >feedback/problems should be provided directly to TSB EDH >(<mailto:tsbedh@itu.int>tsbedh(a)itu.int). > >Best regards, >Sim黍 > > >From: owner-tsagwp3(a)itu.int [mailto:owner-tsagwp3@itu.int] On Behalf >Of Al.Dayao(a)itu.int >Sent: 06 December 2005 18:10 >To: tsagwp3, ITU (MLIST) >Cc: TSBEDH, ITU >Subject: TSAG-D30 Proposal: Provide tree structure of list of >meeting documents > >Dear TSAG WP3 Participants, > >Following the proposal of Republic of Korea for enhancements in the >electronic working environment in ITU-T meetings, a new web page has >been created based on the information provided in TSAG Delayed >Contribution 30 ( ><http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051…>http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051… ). > >The new page lists all the meeting documents available in DMS and in >the Informal FTP areas (IFAs) of all the Study Groups using a >directory tree menu structure. It allows the users to view all the >Study Groups' documents without display limit and provides quick >navigation across the different Study Group documents without having >to open other pages. > >A link to the new page has been included in the TSAG as well as in >all the Study Groups main pages under the item "View Documents in >Directory Tree Mode". > >The new page is available here: ><http://www.itu.int/ITU-T/meetingdocs/index.asp>http://www.itu.int/ITU-T/meetingdocs/index.asp > >Kind regards, >Al Dayao >TSB EDH Coordinator

1 0

Fwd:Tree structure view of available meeting documents
by OKUBO Sakae 06 Dec '05

06 Dec '05

*** This looks a great improvement -- Sakae OKUBO *** >Subject: Tree structure view of available meeting documents >Date: Tue, 6 Dec 2005 18:17:23 +0100 >Thread-Topic: Tree structure view of available meeting documents >Thread-Index: AcX6h9Xig12CLb9CSr648izhtHDt6wAAMVpw >From: <simao.campos(a)itu.int> >To: <t05sg16mgt(a)ties.itu.int>, <tsg6mgt(a)ties.itu.int> >Sender: owner-t05sg16mgt(a)itu.int >Reply-To: <simao.campos(a)itu.int> >X-Greylist: Sender IP whitelisted, not delayed by >milter-greylist-2.0.2 (mail4.itu.ch [156.106.192.20]); Tue, 06 Dec >2005 18:18:04 +0100 (MET) >X-Biglobe-VirusCheck: Wed, 07 Dec 2005 02:18:10 +0900 > >Dear colleagues, > >you may find this way of checking meeting documents more convenient >than before. Please share it with experts in your Qs. Specific >feedback/problems should be provided directly to TSB EDH >(<mailto:tsbedh@itu.int>tsbedh(a)itu.int). > >Best regards, >Sim黍 > > >From: owner-tsagwp3(a)itu.int [mailto:owner-tsagwp3@itu.int] On Behalf >Of Al.Dayao(a)itu.int >Sent: 06 December 2005 18:10 >To: tsagwp3, ITU (MLIST) >Cc: TSBEDH, ITU >Subject: TSAG-D30 Proposal: Provide tree structure of list of >meeting documents > >Dear TSAG WP3 Participants, > >Following the proposal of Republic of Korea for enhancements in the >electronic working environment in ITU-T meetings, a new web page has >been created based on the information provided in TSAG Delayed >Contribution 30 ( ><http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051…>http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051… ). > >The new page lists all the meeting documents available in DMS and in >the Informal FTP areas (IFAs) of all the Study Groups using a >directory tree menu structure. It allows the users to view all the >Study Groups' documents without display limit and provides quick >navigation across the different Study Group documents without having >to open other pages. > >A link to the new page has been included in the TSAG as well as in >all the Study Groups main pages under the item "View Documents in >Directory Tree Mode". > >The new page is available here: ><http://www.itu.int/ITU-T/meetingdocs/index.asp>http://www.itu.int/ITU-T/meetingdocs/index.asp > >Kind regards, >Al Dayao >TSB EDH Coordinator

1 0

Re: Summary of the last week Rapporteur meeting
by OKUBO Sakae 05 Dec '05

05 Dec '05

Dear experts, At 7:22 AM -0500 05/12/05, OKUBO Sakae wrote: >[...]Q.1 documents will be advised separately. Mr. Patrick Luthi has announced the following: At 3:00 PM +0100 05/12/05, Patrick Luthi wrote: >The Rapporteur meeting of Q.1/16 has concluded. This was a busy >meeting with 24 input contributions (+ several docs. generated at >the meeting) and I am happy to report that we made some good >progress in 2 main areas: H.241 and H.324M. > >The meeting report can be found here: >http://ftp3.itu.int/av-arch/lbc-site/0511_Geneva/q1e33.doc > >The report will remain posted for a couple of weeks with change >marks on, so experts can see the changes and additions that were >made during the closing session. > >The final list of documents is available here: >http://ftp3.itu.ch/av-arch/lbc-site/0511_Geneva/q1e00r2.doc -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0