dclowes at OZEMAIL.COM.AU
Sun Aug 30 20:30:47 EDT 1998
In common with others, I cannot see in H.323v2 generally, nor section 8.1.6
specifically, as quoted in your other response, where ARQ is being sent
between gatekeepers. I'll let their comments rest.
I am not too clear on conference calls, and how the MCU is determined.
presumably, that is done by the first party, or between the first two
parties. For the n'th party to join a conference, do they join by reference
to the conference, the MCU (not knowing which MCU was selected) or by
reference to one of the endpoints currently participating in the
conference? I suspect the latter, and that the call will be deflected to
the MC by a Facility response to the Setup.
Section 8.1.9 allows for an ad-hoc conference to be connected with "an MC
associated with the Gatekeeper". It also allows for "The master-slave
determination procedure is used to determine which MC will be the active MC
for the conference." So, if the MC is dynamic, how is the new endpoint
expected to "know" of it?
At 17:18 28/08/98 -0400, Radhika wrote:
>I am extremely happy in seeing Mr. Clowes answers. I am also adding a little
>text in Clowes' answers to clarify further in relation to the proposed
>AT&T's distributed model.
>I am using one of your assumptions is that MCU is located in zone that has
>its own GK. In H.323, each GK manages resources in its own zone.
>Now MCU will be acting as the central point that will be controlling the
>call. That is, a calling H.323 endpoint will set up a call with the MCU, and
>in turn MCU will set up the call with the called H.323 endpoints. If a new
>H.323 endpoint located in new zone wants to join the conference, it will
>also contact the MCU.
>Now the RAS signaling messages between the GKs will be following the similar
>logic. That is, from the calling H.323 endpoint's GK to the MCU's GK, and
>then from MCU's GK to the called H.323 endpoints' respective GKs, etc.
>1. Current H.323v2 (e.g., Section 8 with explicit Figures) DOES envisions
>the RAS signaling messages including ARQ can be sent between the GKs in
>addition between the H.323 entities and the GK. (Please note the difference
>with Mr. Purvis reply).
>2. In "logical" zone environment, the resource management is also extremely
>important especially in the context of large network where million of users
>share the same physical network (e.g., in carrier networks, in virtual
>private networking environment, the network reosources are partioned
>logically between the corporate customers, and resource managemnt is also
>done accordingly). [Please note the difference with Mr. Purvis reply].
>> > 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.
>[Radhika: As I have mentioned in the begining, the communication will be
>done between the MCU and the H.323 endpoint. So, the call will span at least
>two zones: Zone of MCU and Zone 4 of F. Each GK manages resources in each
>zone. As a result, GK of Zone 4 will not be able to confirm the ARQ message
>because it does not know about the resources of Zone of the MCU. Accordance
>to AT&T's proposed distributed model, GK4 of Zone 4 will send the ARQ
>message to the GK of (MCU) zone after cinfirming its own resources. As soon
>as the (MCU) GK confirms the resources of its zone, ACF message will be sent
>from the (MCU) GK to the GK4 of Zone 4. GK4 then sends the ACF message to
Where this initial connection is to one of the endpoints involved in the
conference, this gets to be a little confusing. How should the GK in the
destination zone respond, if a deflection to an out-of-zone MC is the
(unknown by GK at this time) future response, and yet local resources are
>> >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.
>[Radhika: According to AT&T's proposed distributed model, it will be
>preferable to follow the ARQ/ACF signaling paths as mentioned above by me.
>Then, the call signaling SETUP message should be sent to the MCU (because
>one of the main puposes of the ARQ message is to confirm the resource
>between the source-destination path).]
I thought that the ARQ bandwidth management was only local, and not path
related. Each endpoint (including the MCU) may send an ARQ to its own GK
for local bandwidth management. Gatekeepers in unrelated zones are not able
to do much about resources on shared backbone path segments. Mechanisms
such as RSVP, executed by the endpoints, would seem to be appropriate for
path resource reservation and confirmation.
More information about the sg16-avd