Invitation via Gatekeeper

[Truong Hong-Linh]

Chris,
a few comments to your statements:

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

I must admit that I only consider the "address resolution" part of the ARQ
procedure. I did not consider its BW management and reservation part,
because that part is in my view broken. I'd never use the ARQ for that
purpose. An endpoint only knows about the needed BW when a logical channel
is opened, and not at call setup time! And that applies already in case of a
point-to-point call. Since it does not work for point-to-point cases, it
will also not work for the conference cases.

To make the scenario a bit more complicated, assume there is already a
conference between E1, E2/MC and E4. Now E1 wants to invite E3. E4 will only
knows about the joining of E3 when it is requested by the MC to either
re-open the logical channels (centralized case with codec change) or open
new ones (distributed case). Should E4 sends ARQ when it is requested to
open the logical channels? I don't think that is actually specified.
Furthermore, how should E4 ask its GK for the permission to have a call with
E3? I don't know whether the BRQ procedure can help. Maybe somebody more
knowledgeable could help to clarify the situation.

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

I was assuming that the call between E1 and E2 was direct and the MC was
already created at E2. Otherwise, if the call was GK-routed then according
to H.323 Section 8.4.3.4 the GK would know where the MC is, and certainly E1
would have to sends its SETUP to the GK/MC as specified in 8.4.3.5.

Regards,
Linh
---------
TRUONG Hong Linh                    email: hlt at zurich.ibm.com
IBM Zurich Research Laboratory      tel  : +41 1 724 8434
CH-8803 Rueschlikon / Switzerland   fax  : +41 1 724 8955