Invitation via Gatekeeper

[Lee Hyoung soo]

Dear Hong-Linh and Chris,

Thank you for your mail.

my questions are embeded below. ^.^



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

Yes, I mentioned H.323 v2(October 1997).

> > 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!

I agree with Chris's opnion. I think, every endpoint which is registered to
Gatekeeper must send ARQ to its Gatekeeper.

But I still have some problems. In the above scenario, if E1 sends ARQ to its
Gatekeeper, E1's behavior after receiving ACF is not clear. There are two
different cases. One is that E1 receives ACF with E3's CallTransportAddress. In
this case, E1's behavior is not clear. E1 should keep its status(invite or not),
and after receiving ACF, E1 send Setup message to E2 regardless of
CallTransportAddress in ACF.
And the other is that E1 receives ACF with E2's CallTransportAddres. In this
case, E1' behavior is clear, but Gatekeeper should know E2 is active MC, and
send ACF with E2's CallTransportAddress regardless of destination address in
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.

Yes, you are right. E1's Gatekeeper can know E1's intention, but generally E1's
gatekeeper doesn't know which endpoint is active MC in that conference.


> <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.

According to Linh's opnion, As I explained above, E1 should keep its
status(invite or not) and E1 should follow different procedure between
invitation and other calls, after receiving ACF from its Gatekeeper.

Best wishes,
soo.

--
Nada Research Co., Ltd. Korea
TEL : 82-2-525-3941

Lee Hyoung soo.

mailto:soo at nada.co.kr