- sg16-avd - lists.packetizer.com

Re: [VideoPhone:640] [wg5-3: 968] Re: AVC Request
by hatori＠hal.t.u-tokyo.ac.jp 29 Mar '98

29 Mar '98

$BK>7n9';V!!MM (B $B!!1)D;65<xHk=q$N:XF#$H?=$7$^$9!# (B $BK\F|%a!<%k$rGR8+$$$?$7$^$7$?!#$*?R$M$N7o!";vL3<<$KLd$$9g$o$;$^$7$?$i (B $B4{$K!";vL3<<$KFO$$$F$$$k$H$N$3$H$G$7$?!#9)3XIt#39f4[$NJFB<$5$s$N=j$X (B $B<h$j$K$$$i$7$F$/$@$5$$$H$N$3$H$G$9!#!JM9Aw$O=PMh$J$$$H$N;v$G$9!#!K (B $B0J>e!"$I$&$>59$7$/8f4j$$?=$7$"$2$^$9!# (B $BEl5~Bg3X9)3XIt!!1)D;65<xHk=q (B $B:XF# (B *********************************************************************** Professor Dr. Mitsutoshi Hatori Department of Information and Communication Engineering Faculty of Engineering, University of Tokyo Room 525, 5th floor, 14th building of School of Engineering Hongo 7-3-1, Bunkyo-ku, Tokyo 113-8656, Japan E-mail: hatori(a)hal.t.u-tokyo.ac.jp Phone: +81-3-3812-2111 ext.6661 / Facsimile: +81-3-5684-3982 ***********************************************************************

1 0

Re: AVC Request
by Sakae OKUBO 28 Mar '98

28 Mar '98

Dear Mark and Q.12-14/16 colleagues, Two new APC numbers have been allocated to MPEG liaison response and Mr. Reid's contribution. --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion --------------------------------------------------------------------- Sakae OKUBO

1 0

Re: Errata solicited
by Jim Toga 26 Mar '98

26 Mar '98

Frank (and others) The Decided version of the Implementors Guide for H.323 version 1 is on the avc sites in the 9703_GEN/TD42_plen.doc. Note that the name as 'Implementers Guide' is somewhat a misnomer. It does not really have guidlines or hints concerning easy ways to implement H.323. It is an ITU document that records errors and inconstencies to the Decided text; to be incorporated at the next revision. Regards, jimt. At 10:06 AM 3/26/98 +0100, you wrote: >Hi Jim, > >where can I find an (updated) version of the H.323 Implementors guide? > >Frank > >> -----Original Message----- >> From: Jim Toga [SMTP:jtoga@JF.INTEL.COM] >> Sent: 25 March 1998 18:17 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Errata solicited >> >> Greetings fellow Experts, >> >> >> I would like to solicit input for the H.323 Implementors Guide and the >> H.235 Implmentors Guide. I have received a number of comments/corrections >> to text that I will be incorporating into the proposed documents. >> >> The goal would be to have as much relevant text to bring _into_ the >> Yokuska >> meeting as possible. Please send me any comments that you have or post >> them to the reflector. >> >> Best Regards, >> jimt. >> >> >> *********************************************************** >> *** +1-503-264-8816(voice) +1-503-264-3485(fax) >> *** >> *** jim.toga(a)intel.com Intel - Hillsboro, OR. >> *** >> *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 >> *** >> *********************************************************** > >

1 0

H.450.3: Minor ASN.1 error
by Orit Levin 26 Mar '98

26 Mar '98

Dear Editors! During the compilation process, we found a minor editorial mistake in H.450.3 chapter 11 Operations in support of Call diversion supplementary service. In IMPORTS statement it is written: H225InformationElement FROM Generic-parameters-definition It should have been written: H225InformationElement FROM H225-generic-parameters-definition May be it is useful to put this correction into the Implementors Guide. Best Regards, Orit Levin RADVision Inc., Mahwah, NJ Tel: 201-529-4300 ext. 230 Fax: 201-529-3516 E Mail: orit(a)radvision.com

1 0

Real Time Device Control
by Gary A. Thom 26 Mar '98

26 Mar '98

All, Please remember that Q14 is supposed to be working on the low level Real Time Device Control (RDC) protocol/procedure for H.245 based systems. I encourage all interested parties to give this serious consideration, and submit proposals to the Yokosuka meeting. This is particularly important for those who object to using T.120 for RDC. At the Geneva meeting, much of this work was moved back into Q3, because there was no objection during the Joint Q3/Q14 meeting. If we do not develop a proposal which takes into account the Q11-14 needs, they will move forward developing a T.120 based solution. To start the discussion: There are probably may approaches, some are: 1) Run H.281 FECC over a UDP logical channel. With H.224, without H.224, or with some other low level protocol to assure delivery. 2) Develope a more robust RDC protocol to run over a TCP/UDP logical channel. 3) Provide FECC like functions within H.245. (not a good idea). 4) Provide FECC like functions within T.120. (This was the approach before the RDC work was moved to Q14 last year.) This work should be coordinated for use in H.323, H.324, H.310 systems which all use H.245 and logical channels. Please begin discussion and preparation of proposals for the April meeting Also, Tom Geary, could you please send this to the Q11 reflector. Thanks Gary ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com ------------------------------------------------------

2 1

Re: Errata solicited
by Derks, Frank 26 Mar '98

26 Mar '98

Hi Jim, where can I find an (updated) version of the H.323 Implementors guide? Frank > -----Original Message----- > From: Jim Toga [SMTP:jtoga@JF.INTEL.COM] > Sent: 25 March 1998 18:17 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Errata solicited > > Greetings fellow Experts, > > > I would like to solicit input for the H.323 Implementors Guide and the > H.235 Implmentors Guide. I have received a number of comments/corrections > to text that I will be incorporating into the proposed documents. > > The goal would be to have as much relevant text to bring _into_ the > Yokuska > meeting as possible. Please send me any comments that you have or post > them to the reflector. > > Best Regards, > jimt. > > > *********************************************************** > *** +1-503-264-8816(voice) +1-503-264-3485(fax) > *** > *** jim.toga(a)intel.com Intel - Hillsboro, OR. > *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 > *** > ***********************************************************

1 0

APC numbers
by Sakae OKUBO 25 Mar '98

25 Mar '98

Dear Messrs. Walker and Kimchi, Attached please find APC numbers which have been allocated to your contributions. --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 --------------------------------------------------------------------- Sakae OKUBO

1 0

Re: MPEG-4 Compatibility with ITU-T H.263
by Gary Sullivan 25 Mar '98

25 Mar '98

ITU and MPEG Particpants, Two days ago I sent a message noting the achievement of H.263 compatibility in MPEG-4 video. I want to clarify one aspect of that message. In my exuberance over the outcome of the Tokyo MPEG meeting, I may have glossed over describing the precise resulting technical relationship between the two standards. This was pointed out to me in a private email message. To clarify, the MPEG-4 video syntax was altered in Tokyo so that an MPEG-4 video decoder can decode H.263 Baseline bitstreams. However, since the MPEG-4 video syntax can also support additional features not supported in H.263 Baseline syntax, the opposite is not true in general -- not all MPEG-4 video streams can be decoded by H.263 Baseline decoders. (This is probably understood by those of us who have intimate knowledge of these standards, but may need to be clarified for others.) Best Wishes, Gary Sullivan ---------------------------------------------- From: Gary Sullivan <garys(a)pictel.com> Subject: MPEG-4 Compatibility with ITU-T H.263 In Re: Compatibility between MPEG-4 Video and ITU-T Rec. H.263: I wish to take note of what I believe to be an important milestone in video coding standardization. Last week, the MPEG-4 project achieved compatibility with ITU-T H.263. MPEG created a "final committee draft" of its draft MPEG-4 video coding standard last week (March 16-20) at its 43rd meeting in Tokyo. Full compatibility with the prior video coding standard ITU-T Recommendation H.263 was adopted into that draft. The compatibility was achieved by an alignment of complete syntax support for the primary "Baseline" interoperability operational mode of Rec. H.263. This is an important event in video coding standardization development, ensuring that the new implementations of the future MPEG-4 video standard (FCD for ISO/IEC 14496-2) can have full compatibility with the deployed implementations of Rec. H.263 worldwide. This action sends a clear message that H.263 technology remains at the heart of today's understanding of low bit-rate video compression coding, and that interoperability of these standardized systems is needed world-wide. ITU-T Recommendation H.263 is a video coding standard developed by the International Telecommunications Union (Telecommunications Standardization Sector, formerly CCITT). It was originally approved in November of 1995 and is maintained by the ITU-T Advanced Video Coding Experts Group, formally chartered as Question 15 of the ITU-T Study Group 16 for Multimedia Standardization. Newly approved in a second-generation specification completed in September of 1997 and approved in January of 1998, Rec. H.263 is the current "flagship" ITU standard for low bit rate video communication coding. The "Baseline" mode which forms the heart of H.263 operation was the fundamental requirement for all implementations of the original H.263 specification and is now also fully supported in both the second version of H.263 and in the new draft of MPEG-4 video. The H.263 Baseline mode provides an excellent interoperable common core for video coding systems. MPEG-4 video, to be formalized in ISO/IEC 14496-2, is a project of the Moving Picture Experts Group (MPEG) formally chartered as Working Group 11 of ISO/IEC JTC1 SC29. The MPEG-4 video coding standardization project is developing its specification to provide a broadly-applicable and flexible set of video coding tools and defined configuration profiles for a wide range of multimedia applications with new functionalities such as object-segmented coding and the handling of hybrids of natural and synthetic content. The first of two planned versions of MPEG-4 video is now in a "final committee draft" stage and is expected to receive final approval in December of 1998. I want to thank those who helped bring about this important convergence of standardization development. In particular I would like to thank the MPEG convenor Mr. Leonardo Chiariglione, the MPEG Video chairman Mr. Thomas Sikora, the MPEG Video Coding Efficiency chairman Mr. T. K. Tan, and the supporting MPEG National Bodies of Canada, France, Norway, and the Netherlands. I also wish to especially thank those individuals who recently actively contributed toward the final detailed technical evaluation, proposal, and drafting process for this effort, in particular especially Ms. Gunn Kristin Klungsoyr, Mr. Cor Quist, Mr. Aasmand Sandvand, Mr. Peter List, and Ms. Cecille Dufour. I also wish to thank those who contributed toward this goal previously at critical moments, in partular Mr. Robert Danielsen, Mr. Tom-Ivar Johansen, Mr. Richard Schaphorst, Prof. Faouzi Kossentini, and Mr. Jan De Lameillieure. Sincerely, Gary Sullivan ITU-T Advanced Video Coding Rapporteur PictureTel Corporation This is not an official statement of PictureTel or of ITU-T Q15/SG16.

1 0

Errata solicited
by Jim Toga 25 Mar '98

25 Mar '98

Greetings fellow Experts, I would like to solicit input for the H.323 Implementors Guide and the H.235 Implmentors Guide. I have received a number of comments/corrections to text that I will be incorporating into the proposed documents. The goal would be to have as much relevant text to bring _into_ the Yokuska meeting as possible. Please send me any comments that you have or post them to the reflector. Best Regards, jimt. *********************************************************** *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jim.toga(a)intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** ***********************************************************

1 0

Registration status of Q.11-14 Yokosuka Rapporteur meeting
by Hidenobu Harasaki 23 Mar '98

23 Mar '98

Dear Q.11-14 Yokosuka Rapporteur meeting participants: The following is the registration status of March 24 10:30 JST. Please check your name, company name, mainly attending question and hotel reservation status. What question your are mainly going to attend will help us to allocate meeting rooms. If your hotel reservation field is blank, the hotel does not have any reservation record for you as of March 23. In case that your name is missing or spell is incorrect, please let me know. Looking forward to seeing all of you in Yokosuka, Hideh Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232 Name Registered LAST, first Company name Questions on Hotel ANDO, Dai NTT Q.13 3/5 ARONSON, Barry Barry Aronson Consulting Q.11 3/21 Okay BAUGHER, Mark Intel Q.13,14 3/24 BELL, Bob Selsius Systems Q.11 3/21 processing BLIN, Jean-Pierre France Telecom Q.12 3/20 Okay BOZIER, Michele Madge Networks Q.13,14 3/20 processing CALLAGHAN, Robert Siemens Q.13,14 3/20 Okay CAMPOS-NETO, Simao COMSAT Q.11,12,13,14 3/20 Okay CARADEC, Jean-philippe HP Q.13 3/23 De MUIJNCK, Jeroen KPN Research Q.13,14 3/21 processing FREUNDLICH, Glen Lucent Q.13,14 3/20 Okay FU, Zuqiang (Frank) Nokia Mobile Phones Q.11 3/20 canceled GALVIN, Pat DataBeam Q.13,14 3/20 Okay GEARY, Tom Rockwell Q.11 3/6 Okay GURLE, David VOCALTEC Q.13,14 3/4 Okay HAIGNERE, Isabelle France Telecom Q.13,14 3/20 Okay HARASAKI, Hidenobu NEC Q.12 3/4 HEDAYAT, Kaynam PicturTel Q.13,14 3/16 Okay KAJOS, Geroge VideoServer Q.13,14 3/13 Okay KATTO, Jiro NEC Q.13,14 3/6 KILEGRAN, Annika Telia Research Q.13 3/20 Okay KIMCHI, Gur ETSI Q.13,14 3/6 Okay KOBAYASHI, Naoki NTT Q.11-14 3/9 KORPI, Markkv Siemens Q.13 3/12 Okay KOYANO, Hiroshi NTT Q.13 3/5 KUFFEL, Irene Cisco Q.14 3/20 KUMAR, Vineet Intel Q.13 3/12 Okay LEVIN, Drit Radvision Q.13 3/13 processing LIU, Hong Bellcore Q.13,14 3/19 Okay LINDBERGH, David PictureTel Q.11,13,14 3/13 Okay LUTHI, Patrick PictureTel Q.11,13,14 3/13 MAENG, Joon VTEL Q.13,14 3/16 processing MURAKI, Takahiro NTT Q.11-14 3/9 NAKAI, Toshihisa Oki Q.13 3/21 NASIRI, Mickey Ericsson Q.11 3/20 Okay OKUBO, Sakae GCL Q.12 3/18 OTT, Joerg TELES (Q.11),13,14 3/20 Okay QUIST, Cor KPN Research Q.11 3/24 REID, Mark VideoServer Q.13,14 3/16 Okay RISSANEN, Pekka Nokia Q.13,14 3/20 Okay ROY, Radhika R. AT&T Q.13 3/11 processing SAKAI, Kiyoshi Fujitsu Q.12 3/4 SAKAZAWA, Shigeyuki KDD Q.13,14 3/23 SEBESTYEN, Istvan Siemens Q.13,14 3/21 Okay SINGH, Hardish 8x8 Q.13 3/20 Okay SKRAN, Dale Ascend Q.13,14 3/21 SUCONICK, Irina VideoServer Q.13,14 3/13 Okay SVENNEVIK, Anders Ericsson Q.13,14 3/23 Okay TAYLOR, Tom Nortel Q.13 3/7 Okay THOM, Gary Delta Information Systems Q.14 3/10 Okay TOGA, Jim Intel Q.13.14 3/16 Okay TRUONG, Hong Linh IBM Q.12,13,14 3/17 Okay WALKER, Dave Mitel Q.13,14 3/20 Okay YAMAGUCHI, Hiroyuki NTT Q.11 3/20 YAN, Li Lucent Q.12 3/20 Okay YANG, Zhong Jin Okay end of the list

1 0

IETF iptel working group
by Jonathan Rosenberg 23 Mar '98

23 Mar '98

Members of ITU SG16, As many of you are probably are aware, the IETF has created a new working group, called iptel (IP Telephony), to develop some protocols related to Internet telephony. There has been a lot of confusion about this group and what it is (and isn't) doing, so as chair of this group, I'd like to provide some clarification. Firstly, the group is not standardizing an alternative to H.323. The group will be standardizing two things, both of which are independent, orthogonal, and complementary to H.323. The first output of the group is a call processing syntax. This is a directive which can be uploaded by a client to a server, such as a gatekeeper or gateway. When a call arrives at this server, the directive is processed, and a decision about what do to with the call is made. This allows clients to express preferences about call handling based on inputs such as caller, time of day, subject, media, etc. The second output of the group is a protocol for distributing attributes to aid in the process of selecting a gateway to complete an IP to PSTN call. The protocol will focused on wide-area (aka inter-zone) distribution, where scalability is a serious concern. Likely it would be implemented by gateways and gatekeepers, adding greater reach to the existing intra-zone mechanism currently in RAS. This work is quite complementary to both H.323 and the efforts of ITU SG16. I would encourage those of you who are interested to attend the meeting for more details. In addition, you should join the group's mailing list. Instructions for doing so can be found at http://www.bell-labs.com/mailing-lists/iptel/. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen(a)bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen

1 0

MPEG-4 Compatibility with ITU-T H.263
by Gary Sullivan 23 Mar '98

23 Mar '98

In Re: Compatibility between MPEG-4 Video and ITU-T Rec. H.263: I wish to take note of what I believe to be an important milestone in video coding standardization. Last week, the MPEG-4 project achieved compatibility with ITU-T H.263. MPEG created a "final committee draft" of its draft MPEG-4 video coding standard last week (March 16-20) at its 43rd meeting in Tokyo. Full compatibility with the prior video coding standard ITU-T Recommendation H.263 was adopted into that draft. The compatibility was achieved by an alignment of complete syntax support for the primary "Baseline" interoperability operational mode of Rec. H.263. This is an important event in video coding standardization development, ensuring that the new implementations of the future MPEG-4 video standard (FCD for ISO/IEC 14496-2) can have full compatibility with the deployed implementations of Rec. H.263 worldwide. This action sends a clear message that H.263 technology remains at the heart of today's understanding of low bit-rate video compression coding, and that interoperability of these standardized systems is needed world-wide. ITU-T Recommendation H.263 is a video coding standard developed by the International Telecommunications Union (Telecommunications Standardization Sector, formerly CCITT). It was originally approved in November of 1995 and is maintained by the ITU-T Advanced Video Coding Experts Group, formally chartered as Question 15 of the ITU-T Study Group 16 for Multimedia Standardization. Newly approved in a second-generation specification completed in September of 1997 and approved in January of 1998, Rec. H.263 is the current "flagship" ITU standard for low bit rate video communication coding. The "Baseline" mode which forms the heart of H.263 operation was the fundamental requirement for all implementations of the original H.263 specification and is now also fully supported in both the second version of H.263 and in the new draft of MPEG-4 video. The H.263 Baseline mode provides an excellent interoperable common core for video coding systems. MPEG-4 video, to be formalized in ISO/IEC 14496-2, is a project of the Moving Picture Experts Group (MPEG) formally chartered as Working Group 11 of ISO/IEC JTC1 SC29. The MPEG-4 video coding standardization project is developing its specification to provide a broadly-applicable and flexible set of video coding tools and defined configuration profiles for a wide range of multimedia applications with new functionalities such as object-segmented coding and the handling of hybrids of natural and synthetic content. The first of two planned versions of MPEG-4 video is now in a "final committee draft" stage and is expected to receive final approval in December of 1998. I want to thank those who helped bring about this important convergence of standardization development. In particular I would like to thank the MPEG convenor Mr. Leonardo Chiariglione, the MPEG Video chairman Mr. Thomas Sikora, the MPEG Video Coding Efficiency chairman Mr. T. K. Tan, and the supporting MPEG National Bodies of Canada, France, Norway, and the Netherlands. I also wish to especially thank those individuals who recently actively contributed toward the final detailed technical evaluation, proposal, and drafting process for this effort, in particular especially Ms. Gunn Kristin Klungsoyr, Mr. Cor Quist, Mr. Aasmand Sandvand, Mr. Peter List, and Ms. Cecille Dufour. I also wish to thank those who contributed toward this goal previously at critical moments, in partular Mr. Robert Danielsen, Mr. Tom-Ivar Johansen, Mr. Richard Schaphorst, Prof. Faouzi Kossentini, and Mr. Jan De Lameillieure. Sincerely, Gary Sullivan ITU-T Advanced Video Coding Rapporteur PictureTel Corporation This is not an official statement of PictureTel or of ITU-T Q15/SG16.

1 0

Contributions APC-1328 and APC-1329
by Markku Korpi 22 Mar '98

22 Mar '98

<fontfamily><param>Arial</param><color><param>0000,0000,ffff</param><bigger>I have just uploaded the following Siemens contributions to the PictureTel incoming site: - APC-1328 on Call Hold supplementary service - APC-1329 on Cal Park and Pickup supplementary service They are in Word 8.0/'97 format. --Markku ------------ Markku Korpi, Siemens 4900 Old Ironsides Dr., P.O.Box 58075, Santa Clara CA 95054 Phone: +1 408 492 7328, E-mail: korpim(a)sbs.de </bigger></color></fontfamily>

1 0

Handover of the Q.12-14/16 ftp site
by Sakae OKUBO 22 Mar '98

22 Mar '98

Dear SG16 colleagues, Since GCL is going to terminate its R&D activities on 31 March 1998 as set out at the time when it was established 5 years ago, we have to close the GCL ftp site that has been used for the Q.12-14/16 experts group. In this situation, PictureTel has kindly offered to change its mirror site to the primary site. Mr. Bob Webber will continue to manage the operation of this ftp site and I will continue to manage the APC-numbered and other documents stored at this site. Though the GCL ftp site will be working by the end of this month, please take the following actions right now: 1) For retrieval of the documents, please change the URL to ftp://standard.pictel.com/avc-site/ or http://standard.pictel.com/ftp/avc-site/ from ftp://itu-t:sg15!avc@ftp.gctech.co.jp/ 2) For uploading your contributions, please send it to ftp://standard.pictel.com/avc-site/Incoming/ and send an e-mail to me when you have finished your uploading. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

Subsribe
by nloesing 21 Mar '98

21 Mar '98

norb.j.loesing(a)ameritech.com

1 0

Registration to the Upcoming SG16 experts meetings in Yokosuka
by Istvan Sebestyen 20 Mar '98

20 Mar '98

At 20:01 17.03.1998 +0900, Kiyoshi SAKAI wrote: >Dear SG16 Q.11, Q.12-14 Experts, > >As we have announced earlier, March 20 is the deadline for the >registration and hotel reservation for the SG16 Yokosuka meeting. >If you plan to attend the meeting, please register as soon as possible >according to the following directions; > >1) Registration form should be sent to "harasaki(a)ccm.cl.nec.co.jp" > with copy to Rapporteurs. > >2) Hotel reservation form should be faxed to Yokosuka Prince Hotel. > >Block room reservation will expire on March 20, however, the hotel will >continue to accept your reservation at the same price after the deadline >only if the rooms are available. > >Registration and hotel reservation forms are attached to this mail. > >Best regards, > >Hidenobu Harasaki, NEC Corporation >Kiyoshi Sakai, Fujitsu Laboratories LTD. > >********************************************************************** > Kiyoshi Sakai > Media Processing Laboratory > Multimedia Systems Labs. > FUJITSU LABORATORIES LTD. > Tel. : +81 44 754 2679 > Fax. : +81 44 754 2347 > E-mail : sakai(a)flab.fujitsu.co.jp >********************************************************************** > >Attachment Converted: C:\TEMP\invitat2.zip > Yes, I would like to register to the above meeting. I did not find the registration form in the attachement... Kind regards, Istvan Sebestyen ------------------------------------------------------------------ Istvan Sebestyen Siemens AG Standardization, Large Networks PN GS 94, Private Communications Systems Group, Mch H/1760/255 Tel: +49-89-722 47230 Hofmannstr. 51 Fax: +49-89-722 47713 D-81359 Munich, GERMANY Internet: istvan.sebestyen(a)mch.pn.siemens.de (preferred) istvan.sebestyen(a)pn.siemens.de (Fall back only) X.400: c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail; s=Sebestyen;g=Istvan Note: Unfortunately - in practice - e-mails sent to me occasionally may get lost or stay unread for a long time due to business trips. So, for very important communication pls. send a "back-up" in fax. ------------------------------------------------------------------

2 1

Re: Registration to the Upcoming SG16 experts meetings in Yokosuka
by Nancy Greene 20 Mar '98

20 Mar '98

Regarding Mr. Sebastien's message of not finding the registration document attached to the e-mail, it may be a better practice to "do like the IETF" and send all meeting announcements and agendas in pure text so that they are quickly and easily available to all. Nancy ----------------------------------------------------------------------- Nancy Greene, Public Data Networks, Nortel Tel 613-763-9789 Fax 613-763-8904 Email ngreene(a)nortel.ca -----------------------------------------------------------------------

1 0

Request for APC-Number
by Sakae Okubo 20 Mar '98

20 Mar '98

Dear Kaynam Hedayat, In response to your request, APC-1339 has been allocated to your contribution "Proposals and General Comments for H.323 Annex C". Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ******************************************************************** --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C ---------------------------------------------------------------------

1 0

subscription
by Jong-il Kim 19 Mar '98

19 Mar '98

Woud you add me on this reflector? subscribe, subscription. Thanks in advance

1 0

Multiple GRQs
by Chris Purvis WVdevmt-WS 19 Mar '98

19 Mar '98

In H.225.0, under GRQ (section 7.8.1 in version 2, 7.8 in version 1), it says "Note that one GRQ is sent per logical endpoint; thus an MCU or a Gateway might send many.". Why would an MCU or Gateway want to do this? Does this mean that an MCU might go on to register with multiple gatekeepers? Or that a gateway might register multiply with one gatekeeper, registering different sets of aliases to correspond to different bandwidths or other WAN-side characteristics? Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Request for APC numbers
by Sakae Okubo 18 Mar '98

18 Mar '98

Dear Orit Levin, In response to your request, APC-1331 and 1332 have been allocated to your two contributions as attached. Using this opportunity, I would like to draw the attention of Editors that I have allocated APC-numbers to the draft Recommendations which should be elevated to White Contributions at the Yokosuka meeting. Please use these document numbers for your input documents. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ******************************************************************** --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 ---------------------------------------------------------------------

1 0

Migration Indication
by Euchner Martin ZT IK 3 17 Mar '98

17 Mar '98

------------------------------- Der folgende Text gilt nicht fuer SMTP und nur fuer ZT Mitarbeiter! Die MS Mail Adresse Ihres Teilnehmers "Euchner Martin ZT IK 3" ist nur noch bis Juni 98 gueltig und wurde an die neue Exchange Adresse weitergeleitet. Sie finden die neue Adresse in der globalen Adressliste - des MS Mail Client unter "Euchner Martin(Exchange)" - des Exchange Client unter "Euchner Martin" Andere Adressen finden Sie im SCD.Passe

1 0

protocolIdentifier omnipresence
by Paul Long 17 Mar '98

17 Mar '98

I was wondering, why is the protocolIdentifier field present in so many H.225.0 messages? The value must be consistent from message to message, right? In contrast, protocolIdentifier is only transmitted once, in termCapSet, in H.245. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Re: Fast Connect and mediaChannel
by Toby Nixon 17 Mar '98

17 Mar '98

Orit, your proposal seems fine to me on first reading. The way to get this into the implementor's guide would be to submit the text you have below as a written contribution to a rapporteur's meeting so that it can be approved, and then the editor of the implementor's guide will include the text. -- Toby > -----Original Message----- > From: Orit Levin [SMTP:orit@RADVISION.COM] > Sent: Thursday, March 12, 1998 7:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Fast Connect and mediaChannel > > > Toby, Jim, Pete and all others! > > > > During the implementation of Fast Connect Procedure, we found two > > pitfalls regarding the use of Transport Addresses as it are currently > > defined. For compatibility sake I provide following > clarifications > for your revision: > > > > 1. In chapter 8.1.7.1 Proposal, Selection, and Opening of Media > > Channels is written: > > "The mediaChannel element shall be set appropriately according to the > > calling endpoint requirements; different values may be used in > > alternative proposals if desired." > > > > As a part of the "Fast Connect Procedure", it is the responsibility of > > the called endpoint to decide about the coupling of proposed incoming > > and outgoing media streams for each SessionId. According to RTP/RTCP > > specifications, such a couple uses a common RTCP channel. Besides > > there are implementations, that rely on dependency between RTP and > > RTCP ports values. > > As a result of all that, "different values" for proposed (by the > > calling endpoint) mediaChannels can NOT be used within the same > > SessionId. > > It means that in the SETUP message all alternative OpenLogicalChannel > > structures, that propose a channel for transmission from the called > > endpoint to the calling endpoint, shall contain not only the same > > sessionID value but also the same mediaChannel value. > > > > 2. The "Fast Connect Procedure" doesn't explicitly define how the RTCP > > port values are provided. In order to support the general case > > (including one direction media transmission) and in accordance with > > (1) above, the following procedures shall be performed in addition to > > the described in H.323. > > > > In the SETUP message, each OpenLogicalChannel which proposes a channel > > for transmission from the calling endpoint to the called endpoint, > > shall contain mediaControlChannel element (indicating the reverse RTCP > > channel) into the H2250LogicalChannelParameters element of the > > forwardLogicalChannelParameters structure. > > In the SETUP message, each OpenLogicalChannel which proposes a channel > > for transmission from the called endpoint to the calling endpoint, > > shall contain mediaControlChannel element (indicating the RTCP channel > > going in the same direction) into the H2250LogicalChannelParameters > > element of the reverseLogicalChannelParameters structure. > > All mediaControlChannel elements inserted by the calling endpoint for > > the same sessionID for both directions shall have the same value. > > > > When accepting a proposed channel for transmission from the calling > > endpoint to the called endpoint, the called endpoint shall return the > > corresponding OpenLogicalChannel structure to the calling endpoint, > > inserting a valid mediaControlChannel element (indicating the RTCP > > channel going in the same direction) into the > > H2250LogicalChannelParameters element of the > > forwardLogicalChannelParameters structure. > > When accepting a proposed channel for transmission from the called > > endpoint to the calling endpoint, the called endpoint shall return the > > corresponding OpenLogicalChannel structure to the calling endpoint, > > inserting a valid mediaControlChannel element (indicating the reverse > > RTCP channel) into the H2250LogicalChannelParameters element of the > > reverseLogicalChannelParameters structure. > > All mediaControlChannel elements inserted by the called endpoint for > > the same sessionID for both directions shall have the same value. > > > > I propose that we put such sort of clarifications into H.323 > > Implementers Guide. > > What is your opinion and what is the procedural way to do that? > > > > Best Regards, > > Orit Levin > RADVision Inc. E Mail: orit(a)radvision.com > 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 > Mahwah, NJ 07430 Fax: 201-529-3516

1 0

Invitation to Q.12-14/16 Yokosuka meeting
by Sakae Okubo 17 Mar '98

17 Mar '98

Dear Mr. Korpi, >>I noticed that the size of the invitation file shrinks to only >>34kB(!) when I made a PDF-file of it using the Adobe Distiller. >>Since the Word-file is 19MByte, the deduction is significant... You >>may want to put it on the ftp-site. Thank you very much for your effort. I have placed it as: /9804_Yok/Invitation.pdf Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0