ARQ/ACF

[Douglas Clowes]

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