My understanding of the meeting was that APC-1422 was considered as good a place as any to start with a development, but there was acceptance that the final result may differ radically from what is in APC-1422, and we didn't want to preclude any other solution that we might find that was either already written, so somehow fitted our needs better than the framework that was out lined in APC-1422. It's my recollection that it was the view of the Intel delegates that this was a satisfactory situation.
Regards,
Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
From: Jim Toga[SMTP:jim.toga@INTEL.COM] Sent: 29 June 1998 21:51 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Report of the Cannes meeting
Dear Mr Roy,
Although I was unable to attend the meeting in Cannes, I have read all the previous reports and have spoken to a number of people that attended. There were many discussions during the meeting, which are summarized in the meeting report without re-hashing every detail. My understanding is that there were no objections from _anyone_ else at the meeting to progressing the work that has been started in APC-1422. The intent will be to have both telephone and email exchanges to further develop this work. I would look forward to having your constructive input as we move forward. In the spirit of this, I would like to elicit your input here.
I would like to point out a couple of misconceptions you might have based upon the text below and ask you for some concrete proposals in areas where you feel they're needed...
Best Regards, jimt.
[SNIP]
Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications)
APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications"
Mr. Roy also pointed out the following:
If these points were raised in the APC document and covered during the meeting why do they need to be called out explicitly in the meeting report? The list of contributed documents is part of the meeting.
* H.323 signaling schemes that were developed forH.323v1 in view of the LAN-based single GK model
Both v1 and v2 have never limited GK deployment to one entity (on the LAN or any other topology) The defined signalling for address resolution allows for N gatekeepers.
(signaling schemes in H.323v2 also remain almost the same so far the inter-GK communication is concerned) may not be good enough to satisfy all needs when it is applied in the context of multiple gatekeeper environment with different inter-GK architectures: Distributive, Centralized, and Hybrid (Distributive + Centralized).
(I think you mean 'Distributed' above) In any case, these different modes of operation define models with respect to _media_ distribution, not control. In this case they would (and do) affect the operation of an MCU. (this is not to say that the MCU can't be co-located with the GK).
V1 and V2 (and certainly the intent with V3) allow for many different GK topologies with hierarchical being one of the more general ones. Flat peer-peer models may be accomplished by having a degenerative 'hiearchy' with a depth of 1.
* Each inter-GK architecture may need differentsignaling schemes in order to optimize the use of communication resources especially in the context large networks for both connectionless and connection oriented networks.
Can you eloborate on this? Are you simply saying that we need to allow both UDP and TCP signalling (which is in fact specified in section 4 of APC-1422).
APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper Communications"
During the discussion of Intel's contribution, Mr. Roy also pointed out that this proposal appears to have the following limitations:
* The relationship between the zone (or internal) andthe border (or domain) gatekeeper is not defined: is it hierarchical or what?
As described in section 2 of APC-1422 the only difference (in terms of protocol interactions) between a GK acting as 'border GK' and an 'internal' GK is that fact that the border GKs may communicate with border GKs from other administrative domains. There are no specific models of deployment within an admistrative domain. Some organizaitons will choose to develop a hierachical model, others may choose to have a star topology, or perhaps a flat domain. It makes no difference to the signalling between administrative domains and the current signalling can facilitate all of these models. Can you offer any specific topologies that you believe will not work and cannot exploit this signalling?
* Does it mandates the use of proprietary protocolsbetween the zone (or internal) and domain (or border) gatekeeper?
It certainly does not _disallow_ proprietary protocols, but the intent would be to support standard messages internal to an adminstrative domain (which may be made up of a number of zones BTW...) as well as using these standard messages between administrative domains.
* The relationship between the multiple domaingatekeepers has not been defined: how communications occur in view of the multiple domain gatekeepers?
The definition of 'relationship' is multi-faceted. Many of the aspects of a 'relationship' may in fact be business related, and outside this realm. One of the points of annex G is to provide some signalling which will allow administrative domains (again an organizational term, not a formal H.323 topology term) to exchange information so that they can define the "relationship between the multiple domain..."
* As if it mandates a specific implementation schemethat may limit its scalability once one starts to use the gatekeeper discovery, address translation, admission control, and/or bandwidth/QOS control signaling messages for this particular architecture while a large network that may use highly distributive, centralized, and hybrid inter-GK architecture.
I'm really not sure what you asking/saying here...can you clarify this?
Therefore, Mr. Roy has the following view:
* It requires a fundamental understanding of thelogical relationships for inter-GK communications in view of the distributive, centralized, and hybrid inter-GK architecture that might be scaleable in view of large networks for both connectionless and connection oriented networking environment.
I think you mixing a number of things here (some of which have no relevance). Can you break this up unto a number simple points - so that a simple person such as I can understand? :-)
* AT&T's contribution (APC-1382) has been the firststep in that direction.
You may note that a number of the definitions and clarificaitons from Yokuska to Cannes were a direct result of APC-1382 - thank you.
I would appreciate a prompt action from your end.
Sincerely,
Radhika R. Roy AT&T Room 1K-330 101 Crawfords Corner Road Holmdel, NJ 07733 Tel: +1 732 949 8657 Fax: + 1 732 949 8569 e-mail: rrroy@att.com
From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: Thursday, June 25, 1998 11:49 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Report of the Cannes meeting
Dear Q.12-14/16 experts,
I have uploaded draft report of the Cannes meeting (APC-1425) at the /Incoming directory.
ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip /APC-1425_w95.zip
w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) with Word 97. w95 is a version converted into Word 6/95; there are obvious errors in section numbering and figures.
Please review it in a week time, and give me any comments. I will then complete it, uploade it at /9806_Can directory and send its copies to the SG16 management.
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@giti.or.jp
*** +1-503-264-8816(voice) Intel - Hillsboro, OR.
*** mailto:jim.toga@intel.com mailto:james.toga@itu.ch
*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 ***