Invitation via Gatekeeper

[Truong Hong-Linh]

Chris and Soo,
my comments are inserted below (and marked with <Linh>). Hope,
they help clarify the scenario you are looking for.
Linh
---
TRUONG Hong Linh      hlt at zurich.ibm.com
IBM Zurich Research Laboratory      tel  : +41 1 724 8434
CH-8803 Rueschlikon / Switzerland   fax  : +41 1 724 8955

_______________________________________________

Soo,

Yes, it is splendidly unclear, isn't it?

> I tried to get answer from implementors group and some other
> person, but I couldn't get any satisfiable answer.
>
> My question is here.
>
> In section 8.4.3.2(Figure 28/H.323-Non-MC invite signalling),

It's worth mentioning which standard here.  For the benefit of anyone
needing to catch up, we're talking about H.323.

> when an
> endpoint(E1) which do not have active MC wants to invite other
> endpoint(E3), does E1 send an ARQ to its Gatekeeper for the invite or
> does E2 send the ARQ to its gatekeeper, or do both of them send ARQ's?

I would suggest that both ought to send ARQs.  Both are logically setting up
calls, so both need to ask permission.  However, E1's ARQ need ask for no
bandwidth as none will be used on the call between it and E2.

<Linh> Here I think we have to distinguish carefully between an endpoint and
an
MC (what the current H.323 achieves very badly!). In the above scenario, the
MC is hosted in the same device as E2 and E1 is sending the SETUP message
to the MC and not to E2 (H.323 Figure 28-30 are misleading, because they
only
show E2 and not the MC!). Therefore, IMO only E1 has to send an ARQ, not E2,
and an MC never sends ARQ!

> And, when Gatekeeper doesn't know which endpoint has active MC in any
> conference, what should Gatekeeper do if it receives ARQ(for
> invitation)
> from an endpoint which do not have active MC? I mean, if Gatekeeper
> receives ARQ from E1, what should Gatekeeper do? Does Gatekeeper send
> ACR with E2's CallTransportAddress instead of E3's
> CallTransportAddress?

E1's gatekeeper can conceivably spot that invite is probably what's wanted,
by matching up conferenceIDs, although there's nothing in the ARQ message to
say directly that invite is the desired outcome.  The gatekeeper certainly
MUST return the address to which E1 should send its Setup message, so in the
direct-routed model that will be E2.  However, a non-routing gatekeeper will
have no way of knowing where the active MC is.  I believe this is a genuine
"hole" in the standard.

Linh,

I know you've implemented some of this stuff: how do you get around this?

<Linh>The point here is in general the GK does not (and needs not) know
where
the MC is actually located! It therefore, in response to the ARQ sent by E1,
returns
the transport address of either E3 (direct model) or itself (GK-routed
model).
In both cases, E1 has to send its SETUP message to the MC (which is in
our specific scenario colocated with E2).Then the MC will relay that message
to
either E3 or the GK, depending on which transport address is included in the
SETUP message sent by E1.

Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.  ENGLAND
Phone: +44 1753 661 359  email: cpurvis at madge.com