- sg16-avd - lists.packetizer.com

FW: RFC 4351 on Real-Time Transport Protocol (RTP) Payload for TextConversation Interleaved in an Audio Stream
by simao.campos＠itu.int 23 Jan '06

23 Jan '06

Dear colleagues FYI Cheers, Simão -----Original Message----- From: ietf-announce-bounces(a)ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor(a)rfc-editor.org Sent: 12 January 2006 02:59 To: ietf-announce(a)ietf.org Cc: avt(a)ietf.org; rfc-editor(a)rfc-editor.org Subject: RFC 4351 on Real-Time Transport Protocol (RTP) Payload for TextConversation Interleaved in an Audio Stream A new Request for Comments is now available in online RFC libraries. RFC 4351 Title: Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream Author(s): G. Hellstrom, P. Jones Status: Historic Date: January 2006 Mailbox: gunnar.hellstrom(a)omnitor.se, paulej(a)packetizer.com Pages: 20 Characters: 44405 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-audio-t140c-00.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4351.txt This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting audio and text data within a single RTP session. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This document is a product of the Audio/Video Transport Working Group of the IETF. This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.

1 0

FW: ITU-ATIS workshop: Spotlight on NGN - Starting 19 March 2006, Las Vegas.
by simao.campos＠ITU.INT 20 Jan '06

20 Jan '06

FYI > ==== > What: Next Generation Network Technology and Standardization > - A joint ITU-T/ATIS workshop at the kind invitation of ATIS - > This free workshop will be held in conjunction with the ATIS Annual > Meeting of its Committees, ATIS TechThink (www.techthink.org) and > Telecom NEXT (www.telecom-next.com) > When: Starting Sunday 19 March 2006 > Where: Mandalay Bay Convention Centre, Las Vegas, USA > Who: Aimed at all who need to know where NGN is going next. > Why: A particular emphasis of the workshop will be NGN requirements > and standards objectives from a North American perspective and how > these can be optimally taken into account in global NGN > standardization in the ITU-T. > Next Generation Network (NGN) standardization is now well underway in > ITU-T and ATIS (as well as other standards organizations.) NGN aims to > increase quality and service features for users, independent of the > underlying transport technology. Following the success of these two > organizations to identify and react to industry's need for NGN > standards, and in continuing their commitment to achieve interoperable > global standards, this workshop will build on the existing > relationship between the two organizations to: > * examine the status of the work in both organizations > * identify standards work needed to support ongoing viable > businesses for all parties as NGN becomes reality, and > * enhance and extend ITU-T and ATIS cooperation to further > coordinate regional and global NGN standardization > For more information please visit: > www.itu.int/ITU-T/worksem/ngn/200603/index.html > Register for this workshop online: > www.itu.int/cgi-bin/htsh/edrs/ITU-T/scripts/edrs.ITU-T.workshops.form? > _eventid=17. >

1 0

FW: ITU-ATIS workshop: Spotlight on NGN - Starting 19 March 2006, Las Vegas.
by simao.campos＠itu.int 20 Jan '06

20 Jan '06

FYI > ==== > What: Next Generation Network Technology and Standardization > - A joint ITU-T/ATIS workshop at the kind invitation of ATIS - > This free workshop will be held in conjunction with the ATIS Annual > Meeting of its Committees, ATIS TechThink (www.techthink.org) and > Telecom NEXT (www.telecom-next.com) > When: Starting Sunday 19 March 2006 > Where: Mandalay Bay Convention Centre, Las Vegas, USA > Who: Aimed at all who need to know where NGN is going next. > Why: A particular emphasis of the workshop will be NGN requirements > and standards objectives from a North American perspective and how > these can be optimally taken into account in global NGN > standardization in the ITU-T. > Next Generation Network (NGN) standardization is now well underway in > ITU-T and ATIS (as well as other standards organizations.) NGN aims to > increase quality and service features for users, independent of the > underlying transport technology. Following the success of these two > organizations to identify and react to industry's need for NGN > standards, and in continuing their commitment to achieve interoperable > global standards, this workshop will build on the existing > relationship between the two organizations to: > * examine the status of the work in both organizations > * identify standards work needed to support ongoing viable > businesses for all parties as NGN becomes reality, and > * enhance and extend ITU-T and ATIS cooperation to further > coordinate regional and global NGN standardization > For more information please visit: > www.itu.int/ITU-T/worksem/ngn/200603/index.html > Register for this workshop online: > www.itu.int/cgi-bin/htsh/edrs/ITU-T/scripts/edrs.ITU-T.workshops.form? > _eventid=17. >

1 0

Second Call for Submissions || ICNS 2006 || ICAS 2006 || WSTC
by OKUBO Sakae 19 Jan '06

19 Jan '06

*** Our apologies if you receive multiple copies of this message *** Second CALL FOR SUBMISSIONS We are pleased to announce a group of 3 outstanding scientific and industrial events scheduled in Silicon Valley, mid-July 2006. Submission deadline: February 15, 2006 Notification of acceptance: March 5, 2006 Camera-ready: March 20, 2006 (workshops: special deadlines) Submissions could cover any of the tracks listed along with each conference. We stress out the third event which is an open contest on the topics listed on the web site. Substantial prizes will be offered. Submissions to the contest are separate from submissions to the collocated conferences. Three specialized workshops are also planned. ICNS'06, International Conference on Networking and Services July 16-18, 2006, Silicon Valley, USA http://www.iaria.org/conferences/ICNS06.html 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 GRID 2006: Grid Networks and Services EDNA 2006: Emergency Services and Disaster Recovery of Networks and Applications includes: IPv6DFI Workshop, IPv6 - Deploying the Future Infrastructure IPDy Workshop, Internet Packet Dynamics ICAS'06, International Conference on Autonomic and Autonomous Systems July 19-21, 2006, Silicon Valley, USA http://www.iaria.org/conferences/ICSA06.html SYSAT 2006: Advances in system automation AUTSY 2006: Theory and practice of autonomous systems AWARE 2006: Design and deployment of context-awareness networks, services and applications AUTONOMIC 2006: Autonomic computing: design and management of self-behavioral networks and services MCMAC 2006: Monitoring, control, and management of autonomous Self-aware CASES 2006: Automation in specialized mobile environments ALCOC 2006: Algorithms and theory for control and computation MODEL 2006: Modeling, virtualization, any-on-demand, MDA, SOA includes SELF Workshop, Self-adaptability and self-management of context-aware systems Summer Contest: WCTS'06, World Class Technology Summit July 16-23, 2006, Silicon Valley, USA http://www.iaria.org/conferences/SummerContest06.html Looking forward for your contribution, On behalf of the organizers and the advisory committees Details: petre(a)iaria.org, lorenz(a)ieee.org ============================================= -- 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

H.323 Instant Messaging and Presence
by Paul E. Jones 17 Jan '06

17 Jan '06

Folks, I have received three independent queries over the past month or so calling for the creation of procedures that detail how to do presence and instant messaging within the context of H.323. Since this requires some discussion and since we do not have any meeting time planned until April, I have decided to create a separate mailing list to discuss this topic among interested parties who might work to draft an initial set of contributions to the next SG16 meeting. If you are interested in this topic, please visit http://lists.packetizer.com <http://lists.packetizer.com/> and join the h323impp list. Paul

1 0

Procedures for Media Type registration in IETF
by simao.campos＠ITU.INT 10 Jan '06

10 Jan '06

Attached, for your information! Cheers, Simão

1 0

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

Q1/16 meeting has concluded: report and documents
by Patrick Luthi 05 Dec '05

05 Dec '05

Dear experts, 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, Patrick Luthi Rapporteur for Q.1/16

1 0

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

05 Dec '05

Dear experts, The following are the reports and liaison statements for Questions 2, 3, 4, 5, 21, 22, 24 and 25. Q.1 documents will be advised separately. -------------------------------------------------------- Topic Report Liaison statements -------------------------------------------------------- Question 2 TD-11a TD-56, TD-57 Question 3 TD-12a TD-39a, TD-40, TD-41b, TD-49a Question 4 TD-13a Question 5 TD-14a Question 21 TD-15 TD-53 Question 22 TD-16a Question 24 TD-17 Question 25 TD-18a TD-28a, TD-29, TD-30 General TD-55a -------------------------------------------------------- They are available at: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/ or ftp://ftp3.itu.int/avc-site/2005-2008/0511_Gen/ user: avguest, password:Avguest -- 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

Fwd: Sentence for Annex A/H.324
by Patrick Luthi 01 Dec '05

01 Dec '05

Dear experts, Here is the proposed sentence from the H.241 editor to consider to include in A.1/H.324 tomorrow morning: "It is recommended that, when possible, multiple H.245 messages should be sent in each single SRP or LAPM frame in order to reduce the number of round-trip message exchanges and frame header overhead." I suggest we discuss in Q.1 whether or not we want to leave out the 3 bold words. --Dave See you tomorrow morning at 9.00! Patrick Luthi Rapporteur for Q.1/16

1 0

Incoming liaison from IMTC
by Patrick Luthi 29 Nov '05

29 Nov '05

Dear experts, We have just received a liaison statement from the IMTC 3G-324M AG titled "LS Response to call setup time improvement methods for H.324". It will be document Q1-E24 and I have updated the agenda to consider it at this Q.1 meeting. Best regards, Patrick Luthi Rapporteur for Q.1

1 0

Fwd:Incoming LS TD 180-GEN/16 from FGNGN
by OKUBO Sakae 29 Nov '05

29 Nov '05

Dear WP2/16 experts, This report of the FGNGN final meeting has been uploaded as AVD-2832 for your consideration. 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 ****************************************************************** >Subject: Incoming LS TD 180-GEN/16 from FGNGN >Date: Tue, 29 Nov 2005 13:25:09 +0100 >Thread-Topic: Incoming LS TD 180-GEN/16 from FGNGN >Thread-Index: AcUDuR/b3WfnV8bASz2stpECZ+PPZQ== >From: <Isabelle.Frost(a)itu.int> >To: <tsg16mgt(a)ties.itu.int> >Cc: <simao.campos(a)itu.int> >Sender: owner-tsg16mgt(a)itu.int >Reply-To: <Isabelle.Frost(a)itu.int> >X-Greylist: Sender IP whitelisted, not delayed by >milter-greylist-2.0.2 (mail4.itu.ch [156.106.192.20]); Tue, 29 Nov >2005 13:26:34 +0100 (MET) >X-Biglobe-VirusCheck: Tue, 29 Nov 2005 21:27:21 +0900 > >Dear All, > >Please find attached Incoming LS TD 180-GEN/16, addressed to >Questions ALL/16, as well as the updated draft list. > ><<2006April03-13_draftlist_withOLSref.doc>> <<GEN-0180-attcht2.doc>> ><<GEN-0180.doc>> <<GEN-0180-attcht1.doc>> > >Best regards. > >Isabelle Frost >Assistant for ITU-T Study Group 16 >Tel: +41 22 730 5865 >Fax: +41 22 730 5853 >SG 16 e-mail: tsbsg16(a)itu.int

1 0

Documents for the next week meeting of Q.1
by Patrick Luthi 24 Nov '05

24 Nov '05

Dear experts, All meeting documents have been posted: http://ftp3.itu.int/av-arch/lbc-site/0511_Geneva ftp://ftp3.itu.int/lbc-site/0511_Geneva user: avguest, password:Avguest The list of documents is available here: http://ftp3.itu.ch/av-arch/lbc-site/0511_Geneva/q1e00.doc Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

Documents for the next week meeting of WP2 Questions
by OKUBO Sakae 23 Nov '05

23 Nov '05

Dear colleagues, The meeting document archive has been updated: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen ftp://ftp3.itu.int/avc-site/2005-2008/0511_Gen user: avguest, password:Avguest The list of documents is available as: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/0511_Gen.html or http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/0511_Gen.xls Please note that the following liaison statements have been added: AVD-2826 All LS on Archiving of Rapporteur Group Meeting Documents TSAG Att Archiving_Rapporteur_Group_Documents AVD-2827 All LS on Request for registration and dissemination of ITU-T Technology Watch function TSAG AVD-2828 (supersedes TD-21) 1, 2, 22 LS on Signal levels definition in codecs and transcoding specifications SG12 AVD-2829 21, 22, 24 LS on Terms of Reference for the HN QoS Task force under JCA HN SG12 AVD-2830 21 Reply to LS on Latency in the NGN (OLS 39/16) SG12 -- 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: Level matching issue between NB/WB speech signals
by OKUBO Sakae 22 Nov '05

22 Nov '05

Dear WP2/16 experts, I have received that attached message from Mr. Yushi Naito, WP1/16 Chair. The document referred to has been uploaded as: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/TD-21.zip for your consideration. 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 ****************************************************************** At 16:49 +0900 05/11/21, Y. NAITO wrote: >Dear Sakae and Istvan, > >When I attended SG12 meeting ( 17-21 October), I found that level >matching between NB and WB speech signals had became their dilemma >as can be found in TD 25 Rev.1/(WP1/12) attached to this document >(highlited two places in yellow). > >Mr. Monfort asked me to check whether we (WP1/16 & SG12) can >collaborate with on this issue, and I had already raised this issue >at Q.15-Q.18 Experts meetings in Newport Beach last week, > >But I think basically this issue should be more relevant to WP2/16, >probablly on voice mixing function in teleconference sysytem >(Multipoint Control Unit ? if I remember correctly). As for WP3/16, >Claude & Paul were also attending the meeting and should have been >already aware of this issue. > >So I would like to raise your attention on this issue. SG12 will >appreciate if you could make useful comments or suggestions on this >issue. > >Regards, > >Yushi

1 0

Re: AVD-2816 H.248.SDPSPEC; Re: Documents for the next week
by OKUBO Sakae 22 Nov '05

22 Nov '05

Dear Mr. Schwarz, At 14:10 +0100 05/11/21, Albrecht.Schwarz(a)alcatel.de wrote: >fyi, I've uploaded (to "Incoming"): > >AVD-2816 3 Draft H.248.SDPSPEC - Comments by ALCATEL > >This contribution provides mainly editorial comments, but proposes >also an additional clause on one issue raised in ETSI TISPAN LS >"Dynamic Codecs in H.248 SDP" (= AVD-2804; = TISPAN 08bTD325). Thank you for your advice. This document is now available at the /0511_Gen directory. -- 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