January 1999 - sg16-avd - lists.packetizer.com

Re: Ambiguity in H.225.0 Appendix D
by Joerg Ott 14 Jan '99

14 Jan '99

>Kishore, > >Looks a pretty good summary of our discussions - let's see what fallout it >generates!!! > Chris, Kishore, here are some ideas on the problem for further thinking (no solutions, of course :-) In essence, basing a protocol action on on whether the provoking message was sent via unicast or multicast is not a very good idea anyway -- even if you manage to solve the problem of distinguishing one from the other upon reception. Rather, we may need a "bit" indicating transmission via multicast or unicast: Our data transmission allows for multi-unicast, so why should discovery not do so as well? Particularly, you could imagine a scenario where you receive a set of potential gatekeeper locations via private DHCP extensions, via manual configuation, etc. some of which may be up and willing to register you and some may not -- be it for load balancing, robustness, etc. Now you have to try all those locations to find a gatekeeper that accepts your registration but your network (unfortunately) is not supporting multicast. Querying the gatekeepers one by one may (but need not) lead to having to wait for timers to expire before you try the next one. Querying them in parallel is semantically equivalent to multicast even if you do not us IP multicast to reach everybody. Finally note that a gatekeeper's decision if to respond (and how much information to include in a response) may depend on whether it was asked individually or together with a number of other gatekeepers. Assuming these considerations are valid, the remaining question would be which piece(s) of information to use to implement the "this-request-is- multicast-bit". Joerg

1 0

Re: Ambiguity in H.225.0 Appendix D
by Chris Purvis 14 Jan '99

14 Jan '99

Kishore, Looks a pretty good summary of our discussions - let's see what fallout it generates!!! Chris > -----Original Message----- > From: Kishore Babu Ramisetty [mailto:kish@TRILLIUM.COM] > Sent: 13 January 1999 6:56 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Ambiguity in H.225.0 Appendix D > > > Hi, > > This is wrt the second problem in the attached mail. > Chris Purvis mentioned that GK needs to know whether > a GRQ or LRQ is received via multicast or unicast so that > the response could be different. > > Actually, H.323 V2 specifies different multicast and unicast > responses only in case of LRQ. In case of GRQ, spec specifically > mentions that even in multicast case a response shall be > given (Section 7.2.1 para three which _only_ talks about > multicast GRQs). > > I believe spec should not mandate a GK to respond to > a multicast GRQ. It should be left to the implementor whether > a response should be sent out to a multicast GRQ or not. > The GK may have some additional information like redirecting > the endpoint to a different GK with altGKInfo etc, otherwise it > is just plain waste of bandwidth to mandate GK's to respond to > multicast GRQ's. The endpoints would time out if they > haven't received a single GCF. > > May be the following line in para 3 of section 7.2.1: > > "If a Gatekeeper does not want the endpoint to register to it, > it shall return Gatekeeper Reject (GRJ)" > > should be changed to something like: > > "On receiving a multicasted GRQ, if a Gatekeeper does not want > the endpoint to register to it, it MAY return Gatekeeper > Reject (GRJ)" > > Comments? > > Regards, > -Kishore. > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis > > Sent: Thursday, January 07, 1999 9:33 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Ambiguity in H.225.0 Appendix D > > > > > > We have had an ambiguity show up during interoperability > > testing, which > > I would like clarified by means of the implementer's guide > and future > > versions of the standard. Any objections, please shout in the usual > > way! > > > > The problem comes in 19.1.1.1 where UDP port numbers are > defined. The > > standard currently (I'm looking at version 2) says: > > Gatekeeper UDP Discovery Port 1718 > > Gatekeeper UDP Registration and Status Port 1719 > > > > There are two problems with this. The first is that it > > implies that the > > LRQ message (which is nothing to do with discovery) always > needs to be > > sent to port 1719, which is a problem for multicast LRQs, > because only > > one IP address and port number pair has been registered with > > the IETF - > > 224.0.1.41:1718. > > > > The second problem is, if anything, more subtle... The > standard also > > seems to imply by the above that GRQ, which is a discovery message, > > should always be sent to port 1718, whether it is sent to the > > multicast > > discovery port or not. > > The reason this is a problem is that gatekeepers need to > know whether > > these messages (GRQ and LRQ) have arrived by multicast or > by unicast, > > because the failure response is different in the two cases > > (no response > > to a multicast xRQ, but xRJ response to a unicast xRQ). The only > > indication that most IP stacks give as to how a message has > arrived is > > by a port number, however, so if all GRQs appear to port > 1718 (and all > > LRQs to port 1719), there is no way for the gatekeeper to > tell whether > > the message arrived by unicast or multicast. > > > > Common (but not universal - at least in products under development!) > > usage, driven by these practical considerations, seems to > be that the > > most common implementations send both sorts of multicast > addresses to > > the registered address - 224.0.1.41:1718, and unicast GRQ and LRQ > > messages to port 1719 (unless there is some private arrangement > > specifying other special usage). > > > > My suggestion is that this common usage is standardised, > initially via > > the implementer's guide, and then when appropriate in future > > versions of > > H.225.0. > > > > Regards, > > Chris > > >

1 0

White contributions for the Santiago SG16 meeting
by Sakae OKUBO 13 Jan '99

13 Jan '99

Dear Q.12-14/16 experts, I have sent to ITU-TSB and placed at the ftp site the following two white contributions regarding H.222.0: White_H2220_AMD5.zip Draft for Amendment 5 to ITU-T Recommendation H.222.0|ISO/IEC 13818-1 White_H2220_AMD6.zip Draft for Amendment 6 to ITU-T Recommendation H.222.0|ISO/IEC 13818-1 Its location is: ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ The first one (AMD5) is basically an integration of APC-1451 and 1450 of the Torino meeting. The second one is basically TD-30/P of the September 1998 meeting of SG16. I have considered the changes made at the MPEG meeting in December 1998 (actually there were elevated one step without changes at that meeting). 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

Correction to the notice of the Monterey meeting
by Sakae OKUBO 10 Jan '99

10 Jan '99

Dear Q.12-14/16 experts, This is a minor correction to the meeting notice I posted on 9 January. The date of issue should read "9 January 1999" instead of "?? January 1999." The corrected version has been placed at the ftp site: ftp://standard.pictel.com/avc-site/9902_Mon/Notice_Monterey.txt or http://standard.pictel.com/ftp/avc-site/9902_Mon/Notice_Monterey.txt 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

Notice of the Monterey meeting
by Sakae OKUBO 09 Jan '99

09 Jan '99

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. I. Sebestyen, IMTC BoD Member De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 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 Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Ascend Communications, Inc. 621 Shrewsbury Avenue Shrewsbury, NJ 07702 USA Tel: +1 908 450 1635 Fax: +1 908 450 1611 E-mail: Dale.Skran(a)ascend.com Gary Thom Rapporteur for Q.14/16 in ITU-T SG16 Delta Information Systems Inc. Horsham Business Center Bldg. 3 300 Welsh Road, Horsham, PA 19044 Tel: +1 215 657 5270 ex 23 Fax: +1 215 657 5273 E-mail: gthom(a)delta-info.com ------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting Date: ?? January 1999 ------------------------------------------------ Dear SG16 Colleagues, The subject meeting of ITU-T SG16 experts will be held in Monterey, USA at the kind invitation of IMTC. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 15 (Monday) - 19 (Friday) February 1999 starting at 9:00 on the first day Please note that this time we meet for FIVE days. 2. Venue ^^^^^^^^ Embassy Suites on Monterey Bay 1441 Canyon Del Rey, Seaside California 93955 USA Tel: +1.831.393.1115 Fax: +1.831.393.1113 or +1.831.899.1928 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - H.321 Implementors Guide - MPEG packetization (jointly with Q.13) - Future audiovisual communication system 3) Q.13/16 Packet switched multimedia systems and terminals - Advance the work of H.323 V3/H.225.0 V3 - Discussion of H.323 Annex C V3 - Further development of GK-GK communications - Preparation of new H.450.x drafts for determination - Discussion of new SUDs 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Preparation of H.GCP for determination - Preparation of H.224 V2 for determination - Discussion of ISUP signaling transport - Discussion of new H.246 interworking Annexes 5) Coordination with Q.11/16 and Q.15/16 - Requirements for IMT-2000 - Requirements for H.26L 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 5 February /// /// Distribution of the document: by 8 February /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 5 February (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Monterey, 15-19 February 1999 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (by 8 February) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /9902_Mon directory of the ftp site. 5) Please bring 60 copies of your document to Monterey. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is very limited. 6) The document distribution / handling at the meeting will be electronic (i.e. participants must bring their laptops along). 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation distributed by the meeting host (ftp://standard.pictel.com/avc-site/9902_Mon/Invitation_Monterey.zip). 6. Registration ^^^^^^^^^^^^^^^ To confirm your meeting attendance, please reply directly to Georgia Lund (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 with copy to three Rapporteurs (e-mail: okubo(a)giti.or.jp, Dale.Skran(a)ascend.com, gthom(a)delta-info.com). 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact Embassy Suites on Monterey Bay using the form included in the host's invitation as indicated in 5 above. Participants are requested to book at the Embassy Suites, as its "conference arrangement" price is very reasonable, paying also for the conference facilities including beverages. Your cooperation helps the meeting host. CUTOFF DATE for the special room rate is Wednesday, 27 January 1999. We are looking forward to meeting with you in Monterey. Sincerely yours, Sakae OKUBO Dale SKRAN Gary THOM ----------

1 0

Ambiguity in H.225.0 Appendix D
by Chris Purvis 08 Jan '99

08 Jan '99

We have had an ambiguity show up during interoperability testing, which I would like clarified by means of the implementer's guide and future versions of the standard. Any objections, please shout in the usual way! The problem comes in 19.1.1.1 where UDP port numbers are defined. The standard currently (I'm looking at version 2) says: Gatekeeper UDP Discovery Port 1718 Gatekeeper UDP Registration and Status Port 1719 There are two problems with this. The first is that it implies that the LRQ message (which is nothing to do with discovery) always needs to be sent to port 1719, which is a problem for multicast LRQs, because only one IP address and port number pair has been registered with the IETF - 224.0.1.41:1718. The second problem is, if anything, more subtle... The standard also seems to imply by the above that GRQ, which is a discovery message, should always be sent to port 1718, whether it is sent to the multicast discovery port or not. The reason this is a problem is that gatekeepers need to know whether these messages (GRQ and LRQ) have arrived by multicast or by unicast, because the failure response is different in the two cases (no response to a multicast xRQ, but xRJ response to a unicast xRQ). The only indication that most IP stacks give as to how a message has arrived is by a port number, however, so if all GRQs appear to port 1718 (and all LRQs to port 1719), there is no way for the gatekeeper to tell whether the message arrived by unicast or multicast. Common (but not universal - at least in products under development!) usage, driven by these practical considerations, seems to be that the most common implementations send both sorts of multicast addresses to the registered address - 224.0.1.41:1718, and unicast GRQ and LRQ messages to port 1719 (unless there is some private arrangement specifying other special usage). My suggestion is that this common usage is standardised, initially via the implementer's guide, and then when appropriate in future versions of H.225.0. Regards, Chris

1 0

FW: Notice of Meeting and Call for Contributions on new ITU quest ion on Internet Gateway Equipment
by Tom-PT Taylor 07 Jan '99

07 Jan '99

> -----Original Message----- > From: Jerry Skene [SMTP:Jerry.Skene@tellabs.com] > Sent: Thursday, January 07, 1999 10:41 AM > To: sigtran(a)BayNetworks.COM; list iptel; 'tsg16q13(a)itu.int'; > 'stg16q14(a)itu.int'; Taylor, Tom-PT [SKY:B318-I:EXCH]; > 'TIPHON_WG6(a)LIST.ETSI.FR'; 'TIPHON_WG2(a)LIST.ETSI.FR'; > 'TIPHON_WG5(a)LIST.ETSI.FR' > Subject: Notice of Meeting and Call for Contributions on new ITU > question on Internet Gateway Equipment > > Notice of Meeting and Call for Contributions on new ITU question on > Internet Gateway Equipment > > In October, the Telecommunications Standardization Bureau of the > International Telecommunications Union, (ITU-T) Study Group 15 > (Transport Networks, Systems and Equipment)approved a new Question > dealing with interconnection equipment between the GSTN and IP Networks. > The first meeting of this new Question (Q21/15)will be held in > conjunction with the Study Group 15/Working Party 2 interim meeting on > 16 - 19 February, 1999. > > ITU members can find the full text of the question on the ITU Informal > FTP Area, at: > http://ftp.itu.int/u/tsg15/sg15/wp2/q21/q21_index.htm > Note that this site is password protected, and is accessible to ITU > members only. > > Non-ITU members can find the text of the Question at: > http://www.coherent.com/itu > > This message is a call for contributions on this important new work. The > goal of > the February meeting is to establish working methods for the Question, > the baseline structure for the Recommendation, a timetable for > completion of the work, and to begin > drafting text. > > The Recommendation being developed in this Question will be of interest > to the following parties: > - GSTN telephony carriers interfacing or planning to interface their > networks to the Internet > - Internet Service Providers carrying or planning to carry telephony > traffic originating or terminating on the GSTN > - Network equipment vendors providing or developing Internet > Telephony interface equipment > > Meeting Registration > ITU and interested non-ITU members may attend this meeting. Details on > registration for the interim meeting may be obtained from the host, Tom > Oshidari [toshidari(a)ditechcorp.com]. The venue for the meeting is the > Sheraton on Fisherman's Wharf, San Francisco. The meeting will be one > day long, and will be held during the week of February 15-19. The > specific day will be known by January 15. > > Contributions > If you plan to attend this meeting, please let the Rapporteur, Mr. Jerry > Skene and the host, Mr. Oshidari know. If you plan to submit a > contribution on this topic, please email it to the Rapporteur, and it > will be included in the discussion. > > If you are a non ITU member, you are most welcome to attend and to > submit contributions. Please contact the rapporteur for guidance on > this. > > To ensure proper consideration of a contribution, the title of the > contribution must be received by the rapporteur no later than January 8, > 1999. > > Sincerely; > > Jerry Skene Rapporteur, Q21/15 > > _________________________________________________ > Jerry Skene | Tellabs, Inc. > Director, | 45085 University Drive > International Standards | Ashburn, VA 20147.2745 USA > tel:+1 703 724-7302 | URL: www.tellabs.com > fax: +1 703 724-7202 | email: jerry.skene(a)tellabs.com > >

1 0

Fwd: Notice of Meeting and Call for Contributions on new ITU question on Internet Gateway Equipment
by Joerg Ott 07 Jan '99

07 Jan '99

Just FYI, in case you are not subscribed to the ITU-based e-mail reflectors of SG16. Actually, there was a *very* lucky hand involved in picking the date. Joerg >From: Jerry Skene <Jerry.Skene(a)tellabs.com> >To: sigtran(a)BayNetworks.COM, list iptel > <iptel(a)lists.research.bell-labs.com>, > "'tsg16q13(a)itu.int'" > <tsg16q13(a)itu.int>, > "'stg16q14(a)itu.int'" <stg16q14(a)itu.int>, > "'Taylor, Tom-PT [SKY:B318-I:EXCH]'" <Tom-PT.Taylor.taylor(a)nt.com>, > "'TIPHON_WG6(a)LIST.ETSI.FR'" <TIPHON_WG6(a)LIST.ETSI.FR>, > "'TIPHON_WG2(a)LIST.ETSI.FR'" <TIPHON_WG2(a)LIST.ETSI.FR>, > "'TIPHON_WG5(a)LIST.ETSI.FR'" <TIPHON_WG5(a)LIST.ETSI.FR> >Subject: Notice of Meeting and Call for Contributions on new ITU question > on Internet Gateway Equipment >Date: Thu, 7 Jan 1999 10:40:34 -0500 >X-Mailer: Internet Mail Service (5.5.1960.3) >Sender: owner-iptel(a)lists.research.bell-labs.com > >Notice of Meeting and Call for Contributions on new ITU question on >Internet Gateway Equipment > >In October, the Telecommunications Standardization Bureau of the >International Telecommunications Union, (ITU-T) Study Group 15 >(Transport Networks, Systems and Equipment)approved a new Question >dealing with interconnection equipment between the GSTN and IP Networks. >The first meeting of this new Question (Q21/15)will be held in >conjunction with the Study Group 15/Working Party 2 interim meeting on >16 - 19 February, 1999. > >ITU members can find the full text of the question on the ITU Informal >FTP Area, at: >http://ftp.itu.int/u/tsg15/sg15/wp2/q21/q21_index.htm >Note that this site is password protected, and is accessible to ITU >members only. > >Non-ITU members can find the text of the Question at: >http://www.coherent.com/itu > >This message is a call for contributions on this important new work. The >goal of >the February meeting is to establish working methods for the Question, >the baseline structure for the Recommendation, a timetable for >completion of the work, and to begin >drafting text. > >The Recommendation being developed in this Question will be of interest >to the following parties: >- GSTN telephony carriers interfacing or planning to interface their >networks to the Internet >- Internet Service Providers carrying or planning to carry telephony >traffic originating or terminating on the GSTN >- Network equipment vendors providing or developing Internet >Telephony interface equipment > >Meeting Registration >ITU and interested non-ITU members may attend this meeting. Details on >registration for the interim meeting may be obtained from the host, Tom >Oshidari [toshidari(a)ditechcorp.com]. The venue for the meeting is the >Sheraton on Fisherman's Wharf, San Francisco. The meeting will be one >day long, and will be held during the week of February 15-19. The >specific day will be known by January 15. > >Contributions >If you plan to attend this meeting, please let the Rapporteur, Mr. Jerry >Skene and the host, Mr. Oshidari know. If you plan to submit a >contribution on this topic, please email it to the Rapporteur, and it >will be included in the discussion. > >If you are a non ITU member, you are most welcome to attend and to >submit contributions. Please contact the rapporteur for guidance on >this. > >To ensure proper consideration of a contribution, the title of the >contribution must be received by the rapporteur no later than January 8, >1999. > >Sincerely; > >Jerry Skene Rapporteur, Q21/15 > >_________________________________________________ >Jerry Skene | Tellabs, Inc. >Director, | 45085 University Drive >International Standards | Ashburn, VA 20147.2745 USA >tel:+1 703 724-7302 | URL: www.tellabs.com >fax: +1 703 724-7202 | email: jerry.skene(a)tellabs.com > > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. >

1 0

New email address for Tom Geary
by tom.geary＠CONEXANT.COM 05 Jan '99

05 Jan '99

Dear colleges: With the formation of the new company by Rockwell known as"Conexant", my email address has changed. Please note it is now "tom.geary(a)conexant.com" (was "tom.geary(a)rss.rockwell.com"). {Jim and Cor, could you do me a favor and correct my email address in the reflector lists? Sorry to trouble you but with my outgoing mail now bearing the new address, I cannot remotely delete myself and I don't want to be duplicated in the data base.} Thank you, Tom Geary

1 0

H.283 white draft
by Mark Duckworth 05 Jan '99

05 Jan '99

I uploaded H283white.zip to ftp://standard.pictel.com/avc-site/Incoming Gary, this is the same as H283draftD which I sent to you a couple of weeks ago. Mark Duckworth PictureTel Corporation

1 0