Chris,
my comments are marked with <Linh>
Regards,
Linh
----------------------------------------------------------------------------
---
PLEASE READ IF YOU CARE ABOUT EITHER GATEKEEPERS OR CONFERENCES!!!
Linh and I appear to agree that we need the views of more interested
parties!
Linh,
> >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.
I agree that the bandwidth stuff is broken. However, if a gatekeeper
chooses to do things with it, you're going to end up with interoperability
problems from saying you don't use it. The point is slightly wider, though,
that someone needs to have knowledge of whether a given user is authorised
to initiate the inviting of people to conferences. I'd rather have all my
configuration for that sort of thing in my gatekeeper than in the
(potentially multiple) MCs in its zone.
<Linh>I didn't say that I don't use the ARQ procedure. I need it for address
resolution purpose. I only want to say that the BW management part of the
ARQ procedure is broken.
> 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).
Really? I thought that was what the conferenceIndication
"terminalJoinedConference" was for, and that the MC was supposed to send it
to all participants whenever anyone new joined the conference.
<Linh> You're rigth. I was thinking about the BW stuff.
> 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.
In my view, the calls are logically between each endpoint and the MC, and
this is how the control paths run. Yes the model is slightly broken for
data paths, particularly by by decentralised conferences.
> >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.
Fair-ish cop... For some of it (ie the GK routed stuff). It kind of
depends on your understanding of a GK having "access to" an MC. Does any
entity with MC functionality that's registered with a GK count as an MC to
which it "has access"? Or just ones that happen to be involved in this
call? This is an area in which the standard is terribly woolly.
<Linh>Agree. We need clarification. (BTW do you think that it is the only
area? ;-) )
Can I just clarify your position, please? If I understand you correctly
you're suggesting that if I as an endpoint want to send a setup "towards"
the active MC in my call or conference in order to invite a new party to the
conference, I don't need to send ARQ to my gatekeeper. In any other
circumstances I need to send ARQ and receive ACF before I may send Setup.
In the gatekeeper routed model, any setup message with conference goal
"invite" will be sent by the gatekeeper to the active MC for the conference
whose conferenceID matches that in the setup message UNLESS it comes from
that entity, in which case it will go to the desired destination.
<Linh>No. In my view, if an endpoint wants to invite a new party, it has to
send ARQ to its GK. Then it shall send the SETUP mesage with the address
info contained in the ACF to the MC. The MC will then route that SETUP
accordingly, i.e. to the GK in the GK-routed case or to the destination
endpoint in the direct case.
Arising questions:
What if there is NO active MC (ie the call is a typical one)? How do I
promote a call to a conference in the direct-routed model where I've ended
up as "slave" in the master-slave determination procedure (where other
entities in the call may or may not contain MCs)?
<Linh>With the terminal capabilty set exchange, you _know_ whether the
remote endpoint is MC-capable or not. If yes you send the invite SETUP to
the remote endpoint which then creates an MC. If no then tough luck the call
cannot be promoted to a conference.
Who is vetting the inviting endpoint's right to invite (certainly the GK's
job in my opinion, whatever routing model you're using).
Regards,
Chris
