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.
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? 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@madge.com