- sg16-avd - lists.packetizer.com

Re: Ambiguity in H.225.0 Appendix D
by Rajesh Patwardhan 14 Jan '99

14 Jan '99

Just FYI on multicast/unicast taken from Stevens book: "...Some applications also bind the multicast address to the socket, in addition to the port. This prevents any other datagrams that might be received for that port from being delivered to the socket. Historically, Berkeley-derived implementations only require that some socketon the host join the mcast group, not necessarily the socket that binds the port and then receives the mcast datagram. There is a potential, however, with these implementations for mcast datagrams to be delivered to the applications that are not mcast aware. Newer mcast kernels now require that the process bind the port and set any mcast socket option for the socket, the latter being an indication that the application is mcast aware. Solaris 2.5 differs slightly and only delivers received mcast datagrams to a socket that has both joined the group and bound the port. For portability, all mcast apps should join a group and bind the port. Some older mcast-capable hosts do not allow the bind of mcast addr to a socket. For portability an application may wish to ignore a bind error for a mcast address...." ----rrp

1 0

Re: Relationship of H.323 and H.245 versions
by Chris Purvis 14 Jan '99

14 Jan '99

Pete, The answer to your direct question is, I believe, a) - but I don't see why it needs to be. In some senses an H.323 version is defined by a combination of an H.225.0 version and an H.245 version. You may or may not discover the second of these pieces of information from another endpoint, in particular if you're using faststart (it seems only to be communicated in a terminalCapabilitySet message). How you'd discover an H.323 version by any other means I don't know! There's also the issue that when people say they support version n, they do not necessarily mean that they support ALL the features of that version (it generally simply means that all the ASN.1 is there); also there may be cases where different signalling channels follow different routes (eg a version 28 gatekeeper or proxy routing a version 1 endpoint's (or vice versa) H.225 but not H.245) - so it's dangerous to make assumptions on the basis of knowledge of another party's version. Is there something particular that you're trying to achieve? If there's a reason for it, we need to think about how to put more versioning information in to the standards. I'd add the further question: Is there any point at which we can assume support of some of the H.450 supplementary services? Or H.235 security? I doubt it... Regards, Chris > -----Original Message----- > From: Pete Cordell [mailto:pete.cordell@BT-SYS.BT.CO.UK] > Sent: 14 January 1999 2:59 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Relationship of H.323 and H.245 versions > > > Gary, > > As H.323 editor can you comment on which of the following > statements is > more correct: > > a) H.323 version 2 can be used with H.245 version 3 ONLY > b) H.323 version 2 can be used with H.245 version 3 OR LATER. > > My view is that it is undesirable to have to up-issue H.323 to a new > version if all you want to do is make use of new features in H.245. > Also, as part of third party re-routing, in the future it may > occur that > an H.323 version 3 endpoint originally connected to another H.323 > version 3 endpoint will end up being connected to the H.245 from an > H.323 version 2 endpoint. Hence assuming that the H.323 and H.245 > versions are locked together does not work. However, I'm not sure if > this aligns with the groups understanding. Do you have any comments? > > Regards, > > Pete > > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= >

1 0

Relationship of H.323 and H.245 versions
by Pete Cordell 14 Jan '99

14 Jan '99

Gary, As H.323 editor can you comment on which of the following statements is more correct: a) H.323 version 2 can be used with H.245 version 3 ONLY b) H.323 version 2 can be used with H.245 version 3 OR LATER. My view is that it is undesirable to have to up-issue H.323 to a new version if all you want to do is make use of new features in H.245. Also, as part of third party re-routing, in the future it may occur that an H.323 version 3 endpoint originally connected to another H.323 version 3 endpoint will end up being connected to the H.245 from an H.323 version 2 endpoint. Hence assuming that the H.323 and H.245 versions are locked together does not work. However, I'm not sure if this aligns with the groups understanding. Do you have any comments? Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

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