- sg16-avd - lists.packetizer.com

Re: LS from SG 9 on J.web
by Sakae OKUBO 25 Dec '98

25 Dec '98

Dear Mr. Campos-Neto, Dear Q.12-14/16 colleagues, > Being in Geneva, I stumbled across a LS from SG 9 (which met > at the same time we did in Torino) to SG 16, which I think > can be best handled by Q.13. Please find this attached to > this message, for consideration at the Feb.99 meeting of > Q-12-14/16. Very belatedly I have placed this liaison statement at the ftp site as: ftp://standard.pictel.com/avc-site/9902_Mon/APC-1487.zip or http://standard.pictel.com/ftp/avc-site/9902_Mon/APC-1487.zip I have also placed APC-1486.zip there which is a liaison response from SG11 regarding Broadband Report Type IE. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

ftp site files
by Sakae OKUBO 23 Dec '98

23 Dec '98

Dear Q.12-14/16 experts, I have cleared the Incoming directory of the ftp site. Files for archive there have moved as follows: ftp://standard.pictel.com/avc-site/ or http://standard.pictel.com/ftp/avc-site/ 1) 9811_Tor/ 57432 Dec 23 03:38 APC-1485a.zip This is the meeting report with "confirmed" status. The only change from the previous version is the description regrading TD-13 as requested by Ms. Orit Levin. 2) 9905_San/ 122394 Dec 10 05:58 H4504draftwhite.zip 259733 Dec 10 05:59 h4505draftwhite.zip 64196 Dec 10 05:59 h4506draftwhite.zip 789980 Dec 14 10:41 h245_h.zip 99679 Dec 18 13:42 h4507white.zip 108725 Dec 19 10:47 H323-Annex-F-white.zip 135133 Dec 23 03:41 h341wht.zip 78063 Dec 23 03:56 annexg_white.zip 83033 Dec 23 04:17 H.323-annex-e-white.zip These are white contributions for the SG16 meeting in Santiago. For more information of each file, please refer to the e-mail posted at the reflector. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

H.323 Annex F White Paper available
by Joerg Ott 19 Dec '98

19 Dec '98

Dear colleagues, I have placed the H.323 Annex F white paper in the Incoming directory of the PictureTel ftp site. The file name is H323-Annex-F-white.zip and contains a change-marked and a non-change-marked copy. Most additions have been made to the informative section 10, with lots of ASN.1 now expressed as byte sequences (the one still missing will be coming soon). All these have been hand-encoded, and although I read X.691 again and again and finally doubled checked partly with the results the OSS as well as our own ASN.1 compiler produced I would ask interested parties for cross checks within the next weeks (its an informative part only, so changes are allowed). Another such exercise and I will probably start to dream in ASN.1... :-) Best regards, Joerg ------------------------------------------------------------------------------- Joerg Ott jo(a)tzi.uni-bremen.de Universitaet Bremen, Germany fax + 49 421 218-7000 TELES AG voice + 49 421 201-7028

1 0

White document submissions
by Gary Sullivan 18 Dec '98

18 Dec '98

ITU SG16 participants, I have been told by the chairman of WP3 that the deadline for submission of white documents for the next SG16 meeting has been extended to mid-January, in light of the likelihood that the SG16 meeting will be held in May rather than April. I therefore have not submitted the white document for Amendment 5 of H.262. Happy Holidays, Gary Sullivan ITU-T Advanced Video Coding (Q.15/SG16) Rapporteur PictureTel Corp. M/S 635 Tel: +1 978 623 4324 100 Minuteman Road Fax: +1 978 749 2804 Andover MA 01810 USA Email: garys(a)pictel.com

1 0

H.225.0 Annex G white draft
by Glen Freundlich 18 Dec '98

18 Dec '98

Dear colleagues, I have placed the Annex G white draft in the Incoming directory of the avc-site. The file is annexg_white.doc. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

H.450.7 whitepaper uploaded
by Dave Walker 18 Dec '98

18 Dec '98

Dear Colleagues, The white paper for H.450.7 has been uploaded to the PictureTel ftp site at ftp://standard.pictel.com/avc-site/Incoming/h4507white.zip Regards, Dave Walker Mitel Corporation Ontario, CANADA

1 0

Annex G
by Glen Freundlich 15 Dec '98

15 Dec '98

Dear colleagues, I have placed review copies of Annex G in the Incoming directory of avc-site. The file annexg10c contains change marks from the last draft at the Torino meeting. The file annexg10n is the same document with no change marks. I would appreciate any comments. Remember that the white drafts are due 19 December, so I plan to deliver Annex G on 18 December. I've compiled the ASN.1, but I would appreciate if someone else could also compile it as a sanity check. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

2 1

Invitation to the Monterey meeting (98/02/15-19)
by Sakae OKUBO 15 Dec '98

15 Dec '98

Dear Q.12-14/16 experts, Attached please find the inviation from the meeting host, IMTC, for our next Rapporteur meeting during 15-19 February 1999 in Monterey. The meeting notice will be issued in due time. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** From: Sebestyen Istvan ICN WN ES SP 4 <Istvan.Sebestyen(a)icn.siemens.de> To: 'garys(a)python.pictel.com', 'garys(a)pictel.com','tom.geary(a)rss.rockwell.com',"'jdale.skran(a)ascend.com'"< jdale.skran(a)ascend.com>,"'okubo(a)giti.or.jp'" <okubo(a)giti.or.jp>,"'gthom(a)delta-info.com'" <gthom(a)delta-info.com> Cc: "'toga(a)ideal.jf.intel.com'" <toga(a)ideal.jf.intel.com>,"'Deepak Kamlani'" <dkamlani(a)inventures.com>,"'Georgia Lund'"<georgia(a)inventures.com>,"'Bigi(a)itu.int'" <Bigi(a)itu.int>,"'mcollier(a)cwixmail.com'" <mcollier(a)cwixmail.com>,"'pierre-andre.probst(a)swisscom.com'" <pierre-andre.probst(a)swisscom.com>,"'georgeh(a)pictel.com'" <georgeh(a)pictel.com>,"'federico.tosco(a)cselt.it'"<federico.tosco(a)cselt.it> Subject: Joint Rapporteurs Group Meeting of the ITU-T/SG16/Q.11, Q.12, Q.13, Q.14, Q.15 hosted by IMTC Date: Fri, 11 Dec 1998 11:26:54 +0100 MIME-Version: 1.0 Dear Friends, this message comes now in my capacity as IMTC BoD Member, who has been involved in organizing the hosting the ITU-T Joint Rapp. Meeting for SG16 Q.11-15. First of all, the IMTC is very pleased to organize this important event,and we are trying to make this event as successful as possible.We have been working hard on the organizational details together with some of the ITU-T Rapporteurs, the IMTC BoD members and of course the IMTC Secretariat, especially Georgia Lund, to have a smooth organization. Monterey in California is a great location, it even takes up with the in February snowy, rainy and foggy Geneva! For any additional details, questions, requests etc. please contact Georgia, the IMTC Secretariat or myself. I think, now everything should be under control and in a good shape,so the invitation E-Mail (with the Hotel Registration Form) should go out in order to have a smooth registration process. I would like to ask the appropriate Rapporteurs, especially Mr. Okubo /Skran to put the invitation message (probably as one of the first official documents of their meeting) out for the Q.12-14 folks ("APC Group"), then Mr. Geary from Q.11 to the Circuit Switched Group, and finally Mr. Sullivan to the Q.15Video group. Please note, that the document distribution / handling at the meeting will be electronic (i.e. people must bring their laptops along). Currently we have only central PCs as file servers, distribution will take place by diskettes. It would be nice to have a LAN solution in place, but that can not be provided by the IMTC. Any contribution, help from the ITU-T side is most welcome to improve the infrastucture. Similarly, we know that Q.15 will have their demo equipment in place,but as usual, Q.15 shall take care of getting, installing, operating, etc.of those. I have a final request to the Rapporteurs (I think the decision is in their hands): The IMTC has 145 members, some of them small companies who are normally directly not participating in ITU-T standardization. If possible,the IMTC would also like to invite its members to the ITU- T Rapp. meeting,to give each member the chance to get a better feeling for how the standardization is done, may be to contribute, and may be also give them the incentive to participate in future in the ITU-T standardization work, if they like it,and if they see benefits in it. Of course, they have to follow all the rules the Rapporteurs set up for running the meeting. I am sure that ITU-T will also benefit to get some fresh views from outside its normal participation.If we get the above permission we will invite the IMTC membership. I wish for all of us a successful organization, meeting and Marry X- mas+ Happy New Year! Kind regards, Istvan Sebestyen ---------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN WN ES SP 4, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail: istvan.sebestyen(a)icn.siemens.de Intranet: http://www.pn.siemens.de/pngs/people/pngs9/ ---------------------------------------------------------------------- > From: Georgia Lund[SMTP:georgia@inventures.com] > Sent: Friday, December 11, 1998 2:40 AM > To: istvan.sebestyen(a)pn.siemens.de > Cc: mcollier(a)cwixmail.com; Deepak Kamlani; Betsy Gillette > Subject: Joint Rapporteurs Group Meeting of the ITU-T/SG16/Q.11, > Q.12, > > <<HOTEL.doc>> > > Dear Colleagues, > > We are pleased to announce that the next Joint Rapporteurs Group > meeting of the ITU-T/SG16/Q.11, Q.12, Q.13, Q.14, Q15 will be held > February 15-19, 1999, at the Embassy Suites on Monterey Bay in > Seaside, California just outside Monterey. Meeting agenda and exact > schedule of the various Rapporteurs Group meetings will be distributed > by the Rapporteurs in due time. > > Logistical details are as follows: > > ACCOMMODATIONS/INFORMATION > Embassy Suites on Monterey Bay > 1441 Canyon Del Rey > Seaside, CA 93955 > > Phone: +1.800.362.2779 - Embassy Suites Toll Free Reservations > Phone: +1.831.393.1115 - Embassy Suites on Monterey Bay directly > Fax: +1.831.393.1113 or +1.831.899.1928 - Faxed reservations using > the attached Hotel Reservation Fax Form > E-mail address: embsales(a)aol.com - An e-mail sent to this address > should be addressed to Reservations and Sales and mention IMTC or ITU- > T/SG16 Conference with the dates. > > URLs: > http://www.embassy-suites.com/HotelInfo/embassy/property.html?page= > HOME&pid=MRYES or > http://www.embassy-suites.com > > Rate: The guaranteed room rate is US$140.00 per night plus state and > local >taxes. Mention IMTC or ITU-T/SG16 Conference to secure this > price. > > Please note that we have reserved this block of rooms at special > group rates, and in order to keep the catering costs and sleeping and > meeting room rental rates low, IMTC has guaranteed that a minimum > number of rooms will be occupied at the hotel. For this reason, you > are strongly discouraged from taking accommodation at other area > hotels. IMTC may have to pay a substantial penalty if the minimum > guarantee is not met. > The sleeping room rate that the Embassy Suites is offering us is > excellent - you won't be disappointed! > > Note that the cutoff date for our room block is Wednesday, January > 27, 1999 and that the special room rate is not guaranteed after this > time! The hotel accepts all major credit cards. Check-in is 4:00 PM, > and check-out is 12:00 PM. > > MEETING ARRANGEMENTS AND MEALS > Full cooked to order breakfast is available in the garden atrium and > breaks will be served in the foyer area near the meeting rooms. A > reception is planned for Tuesday, February 16, 1999. > > In the meeting room we will have a beamer for PC projection, and an > overhead projector. AC power outlets will be available at each table > in the meeting rooms to facilitate use of notebook PCs. > > A copy machine, fax machine, computers with Internet connection and > printers will be available in the office, but electronic distribution > of contributions is planned. Currently we are planning to use > diskettes for document distribution, but any donation and/or > assistance to set up a LAN is welcome. We have been informed that a > D1-machine and a monitor will also be available for video viewing. > > TRANSPORTATION > The Monterey airport has daily flights to and from San Francisco and > Los Angeles. Airlines that fly in and out of Monterey are United > Airlines/United Express, American/American Eagle, Skywest Airlines/ > Delta and Trans State Airlines. Embassy Suites also has a > complimentary shuttle to and from the Monterey airport. For those who > want to drive from San Jose or San Francisco, drive time is > approximately 60 and 90 minutes respectively and can greatly depend on > traffic congestion. Driving directions are available at the Embassy > Suites web site listed above and parking is free. > > CLIMATE > The average temperature high in Monterey in February is 61 $B!# (BF (16.1 $B!# (BC). > The low is 44 $B!# (BF (6.7 $B!# (BC). The climate is mild and the rainy season is > between November and April. For more information about Monterey, > explore the following URL at: http://www.gomonterey.com . > > REGISTRATION > To confirm your meeting attendance, please reply directly to > georgia(a)inventures.com and include the following information for each > individual from your organization attending the meeting: > > Mr./Ms. ?: > Name: > Job Title: > Company: > Official Mailing Address: > Phone: > Fax: > E-mail: > > Will you attend the reception on Tuesday, February 16, 1999? > > Please indicate which of the group(s) below you intend to participate > in: > > * Plenary meeting (Q.11-15) > * Q.11 > * Q.12-14 > * Q.15 > > Please note that the agenda will be available as the event approaches, > and we have received an indication that not all Rapporteurs Groups > plan to hold meetings from Monday to Friday. > > It is a pleasure to acknowledge sponsorship of this event by the > International Multimedia Teleconferencing Consortium (IMTC), Inc., and > to extend our appreciation and thanks. The response that we have > received to this meeting thus far indicates a great turn-out. Please > don't hesitate to contact myself, Istvan Sebestyen > (istvan.sebestyen(a)icn.siemens.de) at Siemens, or Georgia Lund > (georgia(a)inventures.com) at the IMTC office if you have any questions. > > We look forward to seeing you in Monterey! > > Best regards, > > Istvan Sebestyen >

2 1

H.245 Version 5
by Mike Nilsson 14 Dec '98

14 Dec '98

I have now produced the final version of H.245 to be submitted to the ITU as a White Paper for the next SG16 meeting. It is available at ftp://standard.pictel.com/avc-site/Incoming/h245_h.zip The only change from the version I put onto the same ftp site on 3/12/98 is the addition of H.283 ASN.1 codepoints into Appendix VIII. The zip file contains with change marks (WCM), Clean (NCM) and delta (DEL) documents. Gary: Please submit this to Mr Bigi. Best regards Mike Nilsson *********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Real Time Internet Group Fax: +44 1473 645011 * * Applications and Middleware Email: mike.nilsson(a)bt-sys.bt.co.uk * * BT Laboratories [B54 Room 94] * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ***********************************************************************

1 0

APC-1479r1 uploaded
by Joerg Ott 14 Dec '98

14 Dec '98

All, I have uploaded APC-1479r1.zip to the incoming directory of the PictureTel ftp site: a version with no change marks and two with change marks (to Geneva and to the input APC-1479). The white paper will shown up during this week. Joerg

1 0

H.323 Press Releases
by Mike Buckley 14 Dec '98

14 Dec '98

Attached are two press release that were issued Dec 2nd and Dec 4th by the ITU in support of the H.323 and H.gcp work. Regards, Mike Buckley SG 16 Press Officer

1 0

Re: Drafts for H.450.4, H.450.5 and H.450.6 whitepapers uploaded
by Tom-PT Taylor 11 Dec '98

11 Dec '98

Nothing has changed. Endpoint signalling protocols have always been of concern to media gateway controller vendors and their customers, by definition. > -----Original Message----- > From: Rex Coldren [SMTP:coldrenr@AGCS.COM] > Sent: Thursday, December 10, 1998 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Drafts for H.450.4, H.450.5 and H.450.6 whitepapers > uploaded > > I agree. There appears to be a large discussion in navdec about media > gateway > controllers terminating the end device/terminal signaling protocol > (i.e.-H.323, > SIP) > and talking to the end device via a media gateway control protocol > (e.g.-MGCP). > That discussion group would be interested in knowing all variations of > signaling > > intended for endpoints so that it can assure that the control protocol is > extended to > be able to deal with such changes. Any and all changes or additions to > such > endpoint signaling protocols are now of interest to media gateway > controller > vendors and their customers. > > Ami Amir wrote: > > > Karl > > > > Since there is a lot of parallel going on in the IETF, maybe you should > also > > announce it on their mailing groups (e.g. Sigtran, Navdec, ipTel) should > be > > exposed to this information? > > > > Grussen > > > > Ami > > > > -----Original Message----- > > From: Klaghofer Karl PN VS LP3 > [SMTP:Karl.Klaghofer@VS.SIEMENS.DE] > > Sent: Thursday, December 10, 1998 1:10 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Drafts for H.450.4, H.450.5 and H.450.6 > whitepapers > > uploaded > > > > Drafts for the H.450.4, H.450.5 and H.450.6 whitepapers (as > > determined in > > September with minor changes as discussed via reflector) have > been > > uploaded > > to the pictel ftp site at: > > ftp://standard.pictel.com/avc-site/Incoming/ > > > > Karl Klaghofer > > ------------------------------------------------ > > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 > > Hofmannstr. 51, D-81359 Munich, Germany > > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > > e-mail: karl.klaghofer(a)vs.siemens.de

1 0

Re: Drafts for H.450.4, H.450.5 and H.450.6 whitepapers uploaded
by Ami Amir 10 Dec '98

10 Dec '98

Karl Since there is a lot of parallel going on in the IETF, maybe you should also announce it on their mailing groups (e.g. Sigtran, Navdec, ipTel) should be exposed to this information? Grussen Ami -----Original Message----- From: Klaghofer Karl PN VS LP3 [SMTP:Karl.Klaghofer@VS.SIEMENS.DE] Sent: Thursday, December 10, 1998 1:10 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Drafts for H.450.4, H.450.5 and H.450.6 whitepapers uploaded Drafts for the H.450.4, H.450.5 and H.450.6 whitepapers (as determined in September with minor changes as discussed via reflector) have been uploaded to the pictel ftp site at: ftp://standard.pictel.com/avc-site/Incoming/ Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

2 1

Drafts for H.450.4, H.450.5 and H.450.6 whitepapers uploaded
by Klaghofer Karl PN VS LP3 10 Dec '98

10 Dec '98

Drafts for the H.450.4, H.450.5 and H.450.6 whitepapers (as determined in September with minor changes as discussed via reflector) have been uploaded to the pictel ftp site at: ftp://standard.pictel.com/avc-site/Incoming/ Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

1 0

Clarification in Call Hold and Call Park supplementary services
by Klaghofer Karl PN VS LP3 07 Dec '98

07 Dec '98

We propose the following additions to Draft H.450.4 and Draft H.450.5 in order to clarify the usage of the H.225.0 CallIdentifier and ConferenceIdentifier in conjunction with consultation calls (H.450.4) and parked calls (H.450.5). If there are no objections, the text below will be part of the whitepepers we have to submit latest by Dec. 19. Proposed clarification in Draft H.450.4 3 Terms and Definitions ..... Consultation; consultation call An H.323 call established while having another call(s) on hold. ...... 9.3 Interaction with H.225.0 parameters (new paragraph) The H.225.0 elements ConferenceIdentifier and CallIdentifier within a consultation call shall be set to values which are different from the corresponding values of the held call. Proposed clarification in Draft H.450.5 8.3 Interaction with H.225.0 parameters (new paragraph) The H.225.0 CallIdentifier value within a parked call shall be set to the CallIdentifier value that was used in the primary call. For all other SETUP messages carrying SS-PARK or SS-PICKUP related APDUs as defined within this recommendation, new CallIdentifier values shall be used. Note that the CallIdentifier value of the parked/alerting call is preserved during the SS-PARK / SS-PICKUP procedure within the H.450 APDUs. H.225.0 ConferenceIdentifier values are not preserved during the SS-PARK and SS-PICKUP procedures, i.e. new values are assigned for new SETUP messages as part of the SS-PARK and SS-PICKUP procedures. Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

1 0

Torino meeting report APC-1485
by Sakae OKUBO 04 Dec '98

04 Dec '98

Dear Q.11-14/16 experts, I have uploaded the Torino meeting report of Q.12-14/16 group as APC-1485 at the following place: ftp://standard.pictel.com/avc-site/Incoming/1485.zip or http://standard.pictel.com/ftp/avc-site/Incoming/1485.zip This is an integration of TD-07, 12, 18, 19 and other TDs. Please review it and return your comments, if any, by 11 December 1998. Then I will move it to /9811_Tor directory with confirmed status and send copies to Mr. Tosco and Mr. Bigi. Attached please find Section 7.1 recording the IMT-2000 related discussion and conclusion. I have added the alternative way of describing the requirements to the IMT-2000 network. Please Mr. Wenger and other interested members review the second last paragraph and return your advice to make it correct. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** 7.1 Future direction (APC-1458, 1459, 1460) APC-1458 and 1459 (TAO) presented high level requirements for the future system H.32L and discussed some technical aspects. APC-1460 (NTT DoCoMo) discussed multimedia terminals on IMT-2000 network proposing that H.324 and H.323 be used for circuit switched service and packet switched service, respectively. A joint session among Q.11-14/16 addressed the appropriate multimedia systems for IMT-2000 in the context of currently conceptual future system H.32L. A crucial question for our multimedia communication systems is what type(s) of network service would prevail in the future including those of IMT-2000. After some discussion, the meeting concluded that the multimedia system (including but not limited to voice only) for IMT-2000 could not be singled out, rather the approach taken so far should be applied to IMT-2000 as well, resulting in systems optimized to the given network characteristics such as H.323 and H.324/M. Based on this discussion, the meeting attempted to return a liaison response to ITU-T TG8/1 and ITU-T SG11/Q.23 as in TD-14. However, due to lack of quantitative requirement description which was thought essential for sending the liaison, the meeting concluded to attach TD-14 to this report as a basis for further study toward the next meeting (Annex 5 to this report). An alternative way of presenting the requirements was proposed; to describe the performance of each H.300-series system when the given network characteristics (such as bit rate) are minimum and expected performance when the network characteristics are beyond the minimum. Contributions are solicited. ----------< end >----------

1 0

GK implementation
by Stefano Giacometti 03 Dec '98

03 Dec '98

Hi all people, I don't want to bother you with basic questions, I'd just like to ask you if there is a place or a way to find information on the basics of a gatekeeper implementation. The aim of out research consortium is to start designing an open source gatekeeper on the Linux/Unix platform. Our basis are the H323 recommendations and mailing lists and a good software staff: what I'd like is some high level indications about a gatekeeper implementation (also to dimension the work to be done). I hope someone can help, and thanks in advance. Stefano Giacometti -- ****************************************************************** Stefano Giacometti CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni EMAIL : giacometti(a)coritel.it URL : http://www.coritel.it TEL : +39-6-20410028 ADDRESS : Via di Tor Vergata, 135 FAX : +39-6-20410037 00133 Roma - ITALY ICQ : 1051773 ******************************************************************

2 2

Draft of H.245 Version 5 now available
by Mike Nilsson 03 Dec '98

03 Dec '98

I have produced a draft of the white paper for version 5 of H.245. It is available at ftp://standard.pictel.com/avc-site/Incoming/drafth~1.zip Change marks are relative to the previously decided version (version 4). This includes: This contribution, known as H245WCMH, provides text for version 5 of Recommendation H.245 "Control protocol for multimedia communication". Changes are shown relative to the decided version 4, known as H245NCMF. It has been created from H245NCMF, and the changes determined in the September 1998 meeting of SG16 in TD 39 (PLEN). The version number in the syntax has been changed and Annex D has been updated to reference the new version. The following additions were also made as a result of the Torino meeting of Q.11/12/13/14. 1) The improved version of generic capabilities, given in TD-08A of the Torino meeting of Q.11/12/13/14, has replaced the corresponding text in TD39 (PLEN). In addition, the editor has added the GenericCapability structure to MultiplexCapability and ModeElement, and added a subIdentifier field to the Object Identifier of the GenericCapability structure to allow different sets of parameters belonging to the same recommendation, and hence sharing a CapabilityIdentifier, to be distinguished. The first use of this additional parameter is to distinguish the Logical Channel Bit Rate Capability and the MPEG-4 Visual Capabilitities that have been defined to share the CapabilityIdentifier 'ITU-T Recommendation H.245 Version 5'. 2) Added the MPEG-4 Visual capability codepoints in the object orientated capability syntax, its description being given in Annex E. This has been done according to the document 'H245V5White_MPEG4Visual.doc' that was distributed by e-mail. 3) APC-1440 has been included. This includes FlowControlIndication, the Logical Channel Bit Rate Change procedure and the signalling of its capability. The indication of this capability has been moved by the editor to the Capability structure to make it available to all terminals (not just H.323), and has been represented by the object orientated capability syntax, its description being given in Annex F. 4) All capabilities have been added using the object orientated syntax for capabilities. However, the ASN.1 representation has been included in Appendix VIII in case this syntax is not accepted. If the object orientated syntax is accepted, then Apendix VIII should be deleted. But it does not include a codepoint for RDC and improvements to the semantics for error handling for video codecs similar to that for H.320/H230 - could someone please send me the appropriate text. I would appreciate comments as soon as possible as the submission deadline is approaching. In particular, could everyone who has proposed inclusions please check that I have included them completely and correctly Best regards Mike Nilsson *********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Real Time Internet Group Fax: +44 1473 645011 * * Applications and Middleware Email: mike.nilsson(a)bt-sys.bt.co.uk * * BT Laboratories [B54 Room 94] * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ***********************************************************************

1 0

TD13.
by Yair Miranda 01 Dec '98

01 Dec '98

Dear Mr. Okubo. I have uploaded TD-13 into the incoming directory. The text contains two changes according to the comments of Mr. Kaynam Hedayat. Regards, Yair Miranda yair(a)radvision.rad.co.il Tel : +972-3-6455271 Fax : +972-3-6476669 Video : +972-3-6489010 http://www.radvision.com

1 0

Updated APC-1480 uploaded
by Douglas Clowes 29 Nov '98

29 Nov '98

As promised at Torino, an updated version of APC-1480 has been uploaded to the Incomming Directory. This version reflects recent changes which had been made to the Interline BEST protocol, but which had not been incorporated into the documentation. The main changes in the protocol have been the addition of a "Connection" concept where a single set of identification and authorisation information can be grouped with a set of possible destination transport addresses, to permit line-hunting with that set of identification and authorisation information across the destinations. By allowing repeated connection groups, different identification/authorisation sets allows line-hunting across different domains (which may require different Id/Auth sets). Also, an element PSTNInfo has been added specifically for the SCN to SCN VoIP scenario. Other changes have been fairly minor. TransactionIdentifier has been documented, and its serverData component has been changed to a sequence of nonStandardParameter to allow for the inclusion of server data from intervening domains (such as all domains in the aggregation point example in Annex G, Figure 6). Two multi-domain use cases have been added. One demonstrates the use of the Access Request to obtain address resolution and authorisation in the aggregation point type example. The other demonstrates the mechanism for line hunting, in GK-routed calls, both within a zone, and across domains. I hope these serve to further clarify some of the concepts within the protocol. I would be happy to answer further queries and provide further information. Regards, Douglas Clowes OzEmail Interline

1 0

Re: Tunneling in FACILITY
by Sengodan Senthil NRC/Boston 26 Nov '98

26 Nov '98

Pete, Your interpretation of the sentence would permit us to achieve what we want to do with no rewording. As Martin mentioned, we are trying to use the tokens and cryptoTokens field that comes with all H.225.0 message UUIEs to provide security services for H.245 messages. This then implies that whenever a H.245 message is to be sent, there is a "need" for transmission of a Q.931 message, since there is a "need" for using the tokens and cryptoTokens field of the Q.931 message UUIE. With that interpretation, we are set. Thanks. Regards, Senthil ---------- From: Mailing list for parties associ To: ITU-SG16 Subject: Re: Tunneling in FACILITY Date: Thursday, November 26, 1998 3:59PM The point is what we should do with the H.245 tunneling mode when there is no Facility message to be sent but we still want to secure the tunneled message with the ClearText and CryptoTokens. Idea is to send "dummy" information in the facility message containing at least some "useless" information. However, when the facility message would empty as specified in H.323v2 section 8.2.1 then the CryptoTokens and ClearTokens could not be used. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Sent: Donnerstag, 26. November 1998 12:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Tunneling in FACILITY > > Senthil, > > I think if what you are doing needs you send tokens etc., then the only > way to do this is to send a Q.931 message, which means that you need to > send a Q.931 message! Therefore I think the original version of the > sentence still holds. > > Or perhaps I am missing something! > > Regards, > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Sengodan Senthil > >NRC/Boston[SMTP:sengodan@NASBPD01BS.NTC.NOKIA.COM] > >Reply To: Mailing list for parties associated with ITU-T Study Group > >16 > >Sent: 25 November 1998 21:37 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Tunneling in FACILITY > > > >Folks, > > > >Section 8.2.1 of H.323 states: > > > >"If tunneling is being utilized and there is no need for transmission > >of a Q.931 message at the time an H.245 message must be transmitted, > >then a FACILITY message shall be sent with 'h323-message-body' set to > >'empty'." > > > >I would like to know - for the case where no Q.931 message needs to be > >sent - if there are any negative implications of setting the > >'h323-message-body' to 'facility' with 'reason' set to > >'undefinedReason'. This would enable the use of several fields that are > >available within the 'Facility-UUIE' structure - such as 'tokens' and > >'cryptotokens' - which would not be available if 'h323-message-body' is > >set to 'empty'. > > > >A rewording of the sentence as below would enable this: > > > >"If tunneling is .... a FACILITY message shall be sent and the > >'h323-message-body' should be set to 'empty'." > > > >Comments? > > > > - Senthil > > > >Senthil Sengodan > >Nokia Research Center, Boston > >

1 0

Re: Tunneling in FACILITY
by Euchner Martin 26 Nov '98

26 Nov '98

The point is what we should do with the H.245 tunneling mode when there is no Facility message to be sent but we still want to secure the tunneled message with the ClearText and CryptoTokens. Idea is to send "dummy" information in the facility message containing at least some "useless" information. However, when the facility message would empty as specified in H.323v2 section 8.2.1 then the CryptoTokens and ClearTokens could not be used. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Sent: Donnerstag, 26. November 1998 12:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Tunneling in FACILITY > > Senthil, > > I think if what you are doing needs you send tokens etc., then the only > way to do this is to send a Q.931 message, which means that you need to > send a Q.931 message! Therefore I think the original version of the > sentence still holds. > > Or perhaps I am missing something! > > Regards, > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Sengodan Senthil > >NRC/Boston[SMTP:sengodan@NASBPD01BS.NTC.NOKIA.COM] > >Reply To: Mailing list for parties associated with ITU-T Study Group > >16 > >Sent: 25 November 1998 21:37 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Tunneling in FACILITY > > > >Folks, > > > >Section 8.2.1 of H.323 states: > > > >"If tunneling is being utilized and there is no need for transmission > >of a Q.931 message at the time an H.245 message must be transmitted, > >then a FACILITY message shall be sent with 'h323-message-body' set to > >'empty'." > > > >I would like to know - for the case where no Q.931 message needs to be > >sent - if there are any negative implications of setting the > >'h323-message-body' to 'facility' with 'reason' set to > >'undefinedReason'. This would enable the use of several fields that are > >available within the 'Facility-UUIE' structure - such as 'tokens' and > >'cryptotokens' - which would not be available if 'h323-message-body' is > >set to 'empty'. > > > >A rewording of the sentence as below would enable this: > > > >"If tunneling is .... a FACILITY message shall be sent and the > >'h323-message-body' should be set to 'empty'." > > > >Comments? > > > > - Senthil > > > >Senthil Sengodan > >Nokia Research Center, Boston > >

1 0

Re: Tunneling in FACILITY
by Pete Cordell 26 Nov '98

26 Nov '98

Senthil, I think if what you are doing needs you send tokens etc., then the only way to do this is to send a Q.931 message, which means that you need to send a Q.931 message! Therefore I think the original version of the sentence still holds. Or perhaps I am missing something! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Sengodan Senthil >NRC/Boston[SMTP:sengodan@NASBPD01BS.NTC.NOKIA.COM] >Reply To: Mailing list for parties associated with ITU-T Study Group >16 >Sent: 25 November 1998 21:37 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Tunneling in FACILITY > >Folks, > >Section 8.2.1 of H.323 states: > >"If tunneling is being utilized and there is no need for transmission >of a Q.931 message at the time an H.245 message must be transmitted, >then a FACILITY message shall be sent with 'h323-message-body' set to >'empty'." > >I would like to know - for the case where no Q.931 message needs to be >sent - if there are any negative implications of setting the >'h323-message-body' to 'facility' with 'reason' set to >'undefinedReason'. This would enable the use of several fields that are >available within the 'Facility-UUIE' structure - such as 'tokens' and >'cryptotokens' - which would not be available if 'h323-message-body' is >set to 'empty'. > >A rewording of the sentence as below would enable this: > >"If tunneling is .... a FACILITY message shall be sent and the >'h323-message-body' should be set to 'empty'." > >Comments? > > - Senthil > >Senthil Sengodan >Nokia Research Center, Boston >

1 0

Tunneling in FACILITY
by Sengodan Senthil NRC/Boston 25 Nov '98

25 Nov '98

Folks, Section 8.2.1 of H.323 states: "If tunneling is being utilized and there is no need for transmission of a Q.931 message at the time an H.245 message must be transmitted, then a FACILITY message shall be sent with 'h323-message-body' set to 'empty'." I would like to know - for the case where no Q.931 message needs to be sent - if there are any negative implications of setting the 'h323-message-body' to 'facility' with 'reason' set to 'undefinedReason'. This would enable the use of several fields that are available within the 'Facility-UUIE' structure - such as 'tokens' and 'cryptotokens' - which would not be available if 'h323-message-body' is set to 'empty'. A rewording of the sentence as below would enable this: "If tunneling is .... a FACILITY message shall be sent and the 'h323-message-body' should be set to 'empty'." Comments? - Senthil Senthil Sengodan Nokia Research Center, Boston

1 0

Re: Gateway Decomposition Requirements
by Tom-PT Taylor 25 Nov '98

25 Nov '98

Thanks for getting this started. I have some discussion points for further clarification. > -----Original Message----- > From: Dale L. Skran [SMTP:dskran@ASCEND.COM] > Sent: Saturday, November 21, 1998 7:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Gateway Decomposition Requirements > [Taylor, Tom [CAR:B318-I:EXCH]] [snip] > B Interface: > > 1)It must be possible to request that the MGW do H.323 signaling to a > specified IP address, which might, for example, be a composed GW. Of > course, this > is an optional feature. > [Taylor, Tom [CAR:B318-I:EXCH]] The one misgiving I had when documenting the "H.323 Endpoint Type" in IPDC was that the SETUP message contains a lot more than we provided for, and in fact IPDC probably was broken for GW to GW operation (because of missing address information). In effect, the requirement is that interface B should pass all of the relevant contents of the SETUP message. Some things such as the CRV can obviously be left to the Media Gateway to handle. > 2)It must be possible to do this call by call, ie. for one call request > 323 signaling and for the next not request it. > > 3)Point 2 strongly suggests that the protocol for B and A should be the > same, > for example, as in IPDC. [Taylor, Tom [CAR:B318-I:EXCH]] Aside from its call by call operation, it seems to me that the chief requirement on B, C, and D is encapsulation of signalling protocol elements. This suggests you have to have stuff like call identifiers, endpoint identifiers, protocol identifiers, and provision for shipping across large blocks of opaque data. I'm not sure that is logically linked with the device control stuff (interface A). Could we come up with sample message flows that demonstrate an increase in efficiency through use of a common protocol? > C Interface: > > 1)It must be possible to bring call signaling up to the controller so that > signaling can be terminated there (optionally). This suggests a need to > map > different types of call signaling into a single protocol. Q.931 is an > obvious > solution. See Ascend's "Reliable Gateway Signaling Protocol" for an > example. [Taylor, Tom [CAR:B318-I:EXCH]] This seems to be a pretty good consensus on this for trunk signalling, except that apparently some R2 information has to be carried some other way. Our terms of reference don't cover line-side signalling. P.S. I thought the Ascend/Bay RSGP was intended for the D interface. > 2)It must be possible to terminate/generate the Q.931, etc. call signaling > on the gateway > (optionally). This is equivalent to having the MGW signal 323 on the > packet > size. > This allows a call from a MGW with IMT trunks to talk to a MGW with PRI/T1 > trunks > under SS7 control. [Taylor, Tom [CAR:B318-I:EXCH]] Implications for interface C? > 3)(1) is a kind of tunneling for Q.931, so it is not so clear that this > should be > the same protcol as A/B. > > 4)(2) seems like it should be a part of the A/B protcol. > > X requirements(common requirements on A/B/C): > > 1)A/B/C signaling must all travel over the same data network to the MGW. > > 2)It must be possible to use both UDP and TCP > > 3)Either the protocol is Message/ACK or we must use a reliable UDP like > Annex E. > > 4)Given the similiarity of B/C to A, all should use a similar message > format, > the same ports, etc. to ease implementation. Note that both B/C parts are > probably > optional, but they are part of the same protocol as A. The only exception > is the case > where you want to put SCN call signaling(Q.931, FAS SS7) in the > controller, > and > you need to tunnel it up. This stuff might be tunneled through the A/B/C > protocol, or it might be a separate protocol/port, i.e. Q.931 on Annex E > with > a different port. > > 5)Part of the A/B/C message set must include an MGW cap set so the > controller > knows what to expect [Taylor, Tom [CAR:B318-I:EXCH]] This can be argued two ways. If it's there, then as you suggest below we are looking at H.245. Alternatively caps could be set by other means (i.e. configuration). We're talking about boot-up messaging here, not per-call operation. > As noted at the meeting, you need to reflect the terms of reference in the > A > requirements. > > A couple of obvious ones: > > A Interface > > 1)Must include video/data (i.e. consider the possibility of incoming > H.320/H.324 > calls). > > 2)Must not duplicate H.323 functions, eg. cap exchange, conference > management, etc. > > 3)Must be elemental. This goes along with (2). cap exchange is not an > elemental > function. > > 4)Must be suitable for connecting an MC (MultiPoint Controller) to an MP > (Media > Processer) as defined in H.323. This implies a need for elemental > conferencing > primatives, but broken out by media stream, ie. data MP, voice MP, video > MP. > > I'm sure there is more that could be added by a careful review of the > terms of reference. > > > Dale Skran > Rapporteur, Q13 WP2 SG16 ITU-T > > > > > > >Can anyone get us down to another level of detail? > > > >Tom Taylor > >E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) > >Tel.: +1 613 765 4167 (internally 395-4167) > >FAX: +1 613 763 7236 (internally 393-7236) > >

1 0