Hi Everyone: I need to add some clarifications in Mr. Glen Freundlich's note. RAS messages are the madatory that are sent via the GKs. A GK is responsible for a given zone. H.323's ARQ/ACF/ARJ and BRQ/BCJ/BRJ messages do contain abstraction of BW. H.323 does not mandate how these parameters to be implemented for any specific networking environment. We have also discussed how important these BW/QOS parameters are to provide or differentiate services. Definitely, there can be many implementation schemes how to abstract those network level BW/QOS information to the higher layer such as GK level (In fact, H.323 GK does have the capability for admission control, bandwidth control, zone management, call control, etc) whether media and signaling are going through the same path or different paths. The complexity of implmentation will depend from a very simple one to a very complex one. It is the job of the lower layer how these functions will be performed, and how those abstractions will be communicated to the higher layer (e.g., GK level). In H.323v2, we have kept all those parameters open for use for RAS messages for the GKs. At H.323 level, we are not dealing with specific technology dependent implementation issues at the lower network level. There are many standard bodies including ITU-T, IETF, ATM-F, TIPHON, IMTC, and others are dealing with many aspects of H.323 for implementations over the specific networking technologies including abstraction of network level BW/QOS parameters up to the GK level. If anyone has any questions, please let me know. Thanks and regards, Radhika R. Roy AT&T, USA Tel: 732 949 8657 email: rrroy@at.com
---------- From: Glen Freundlich[SMTP:ggf@lucent.com] Reply To: ggf@lucent.com Sent: Tuesday, August 25, 1998 12:18 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225.0 Annex G conference call
There will be another conference call to discuss H.225.0 Annex G: date: 27 August (Thursday) time: 10:00am Mountain Time (9:00 Pacific, 12:00 Eastern, etc) bridge number: +1 630-224-4444 code: 911202 duration: 1 hour
Tentative agenda: - next call 4 September (Friday)? more than 1 hour? - closure on Santo Wiryaman's proposal - review of Pete Cordell's proposal - review of Radhika Roy's proposal
Attendees on last call: (I'm sorry if I didn't get your name on the list. Please email me after a call so that I can build a roster.) Kaynam Hedayat - PictureTel Kerwin Yuu - PictureTel Markku Korpi - Siemens Pete Cordell - BT Radhika Roy - AT&T Hal Purdy - AT&T Jim Toga - Intel Dieter Rencken - Siemens Chris Purvis - Madge Networks Andrew Draper - Madge Networks Michele Bozier - Madge Networks Santo Wiryaman - VideoServer Sree Peyyety - ITXC Glen Freundlich - Lucent
Notes from last call: We spent about 40 minutes discussing Santo Wiryaman's document. The proposal for an addressing hierarchy seems to help scaling, however there are concerns about roaming, portability, and applicability to private networks. There are concerns about defining a numbering or addressing plan, which include political issues as well as technical. However, we probably need some way to assure that an alias is unique. We could leave definition of the address space to bodies such as Tiphon. Annex G might specify that support for E.164 addressing is required, email addresses optional. Annex G or H.225 should stress that email addresses should use the email alias address, not the h323-id. There is also some concern about signaling through the domains in the hierarchy (e.g., going through domains B and C when domain A attempts to signal domain D) - whether this is efficient, what happens when a node is out of service, whether this makes sense in packet networks, and what the net benefit is.
This led into a discussion of some of the points in Radhika Roy's proposal. It is difficult for a GK to control transport level QoS since a GK does not know about other (non-H.323) traffic on the network, and media may take a different path than the signaling between GKs.
For those who were on the last call, please correct me if I've missed something.
Glen
-- Glen Freundlich ggf@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA
Roy, Sorry, I just joined, and maybe have missed the disscussion of the following questions. I am a bit confused about how they are handled. ---- In a distributed gatekeeper architecture of multiple zones environment, say, the H.245 control channel topology looks like as follows: E1 ----- GK -------E2 / | \ / | \ / | \ E3 E4 E5 E1 is in zone 1, E2 is in zone 2, and (E3,E4,E5) are in zone 3. (the corresponding gatekeeper in each zone is denoted to GKi) GK is a gatekeeper that contains an active MC for multipoint conference ocntrol. 1. Should GK has to be in one of {zone1, zone2, zone3)? 2. If endpoint F in in zone 4 would like to join the conference, F must send an ARQ to GK4 before any setup to join the conf. (because GK4 is in charge of the admission for call bandwidth etc. local resources.) Should GK4 forwards ARQ to GK that has the MC?? F should not use any resources in the zone of GK is responsible for. or F has to, because H.245 control message exchanges also consume the reources? or some others? Please advise. Thanks a lot. Regards, Vivian Liao
At 12:30 27/08/98 +0800, you wrote:
Roy,
Sorry, I just joined, and maybe have missed the disscussion of the following questions. I am a bit confused about how they are handled.
---- In a distributed gatekeeper architecture of multiple zones environment,
say, the H.245 control channel topology looks like as follows:
E1 ----- GK -------E2 / | \ / | \ / | \ E3 E4 E5
E1 is in zone 1, E2 is in zone 2, and (E3,E4,E5) are in zone 3. (the corresponding gatekeeper in each zone is denoted to GKi)
GK is a gatekeeper that contains an active MC for multipoint conference ocntrol.
I find it best to view these as separate entities. Then you can see that is is the MCU that sends messages to its own gatekeeper, not the other members of the conference.
1. Should GK has to be in one of {zone1, zone2, zone3)?
There is no reason why all entities should be in any zone, either all in the same zone, or all in different zones. There is no absolute reason why the MC has to be in the same zone as its colocated gatekeeper, even though it may make sense to do so.
2. If endpoint F in in zone 4 would like to join the conference, F must send an ARQ to GK4 before any setup to join the conf. (because GK4 is in charge of the admission for call bandwidth etc. local resources.)
This is correct.
Should GK4 forwards ARQ to GK that has the MC?? F should not use any resources in the zone of GK is responsible for.
Not normally.
or F has to, because H.245 control message exchanges also consume the reources?
Endpoint F should receive an ACF from its own gatekeeper, relating to resource and policy in its own zone. It should then establish a call signalling channel and send a SETUP to the MC. The MC will send an ARQ to its own gatekeeper, to request resourse allocation in its own zone, for this part of the conference.
or some others?
Please advise. Thanks a lot.
Regards,
Vivian Liao
Regards, Douglas
participants (3)
-
Douglas Clowes -
Roy, Radhika R, ALTEC -
WanJiun Liao