Linh, Soo, All,
I think there's a genuine problem here, and I think we need to look for the
"right" solution.
1. I agree with Linh that the fact that the MC happens to be located with
one of the endpoints in this scenario is (or should be) irrelevant.
2. I disagree with Linh's assertion that "an MC never sends ARQ". If I am
administering an MCU which can initiate conferences by calling up a list of
participants at a given time, I will certainly require that MCU to apply to
its gatekeeper for permission to make these calls.
In the particular case under discussion, E2/its MC certainly has to send
ARQ. It is going to make a call, which will result in data flowing its
gatekeeper's zone, and which may end up costing money.
E1's "call" does not result in data flowing in its gatekeeper's zone if the
centralised model is used for data (in which I include both audio and
video) and it happens to be in a different zone from E2/MC and E3 - so
maybe E1 doesn't have to send ARQ? However it will result in data flowing
in its gatekeeper's zone if the decentralised model is used for data, and
the MC may wish to (cross?) charge E1 for inviting E3, so maybe E1 does
need to send ARQ.
3. The destCallSignalAddress given in ACF is the only address to which an
endpoint should send a setup message. I find it hard to agree with Linh's
assertion that on the basis of an ACF mentioning E3, E1 should send a setup
message to E2/MC. The suggestion in the case of the gatekeeper routed
model is simply impossible. E1 doesn't know where E2/MC is, so I fail to
see how E1 can send its setup message to E2/MC in this case. Note that all
E1's call signalling goes to its gatekeeper - and as a routing gatekeeper I
would feel justified in ensuring that E1 doesn't find out where E2/MC is:
for instance I wouldn't feel obliged to leave mcLocationIndication messages
alone as I relay them. The upside of this is that at least then E1's
gatekeeper knows where the activeMC is, and should be able to work out
what's going on when the setup message comes in.
Outline Solution?:
I really don't think we have the tools at our disposal as things stand.
I'm (reluctantly) coming to the conclusion that we need either a1 & b or a2
& b (I think I prefer the latter) as follows:
a1) An extra RAS message to tell gatekeepers where the active MC lives in
conferences. I'm not certain how this works, though, because there needs
to be an "I am NOT the active MC" option (sent on receipt of
mcLocationIndication) which tells the gatekeeper where to find the active
MC. This may or may not be a problem.
a2) An "activeMCLocation" field in ARQ (and setup?).
b) A conferenceGoal element in ARQ (as in setup).
Then if a gatekeeper receives an "invite" ARQ from something that is not
the active MC in its conference it can send back in its confirm the
transport address to which to send setup, and destinationInfo for the final
destination. In the routed model I believe there is still sufficient
information in the setup message for the gatekeeper to do the right thing.
Handling "invite" from the activeMC is then fairly obvious.
I'd love to see how we can do this without new ASN.1, though...
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(a)madge.com
> -----Original Message-----
> From: Lee Hyoung soo [mailto:soo@DESKVIEW.NADA.CO.KR]
> Sent: 05 March 1999 3:35
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Invitation via Gatekeeper
>
>
> 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@nada.co.kr
