Hi Chris,
>> 5. If a call signalling is routed through Gatekeeper, and there exists
an
>> MCU which is not involved in this call. Is it possible for the
Gatekeeper
>> to involve this MCU to create an ad-hoc conference from this call. If
yes,
>> what is the procedure? If not, why?
>
> You leave the biggest question until last...
> And one close to my heart.
> I've written a number of documents on this, and now I can't find any of
them...
>
> The tricky bit is working out that this is what you want to do.
> I assume you have a gatekeeper which routes both H.225.0 (extended Q.931)
call
> signalling and H.245 control signalling.
>
> First off, the gatekeeper uses terminal type for master-slave determination
as
> if it had the MCU functionality built-in. This is permitted because
wherever
> the standard talks about a gatekeeper having an MCU it uses the phrase
"access
> to an MCU".
> When the gatekeeper decides a call needs to be split out into a conference
(for
> example, one of the parties in the call sends a setup using the same
> conferenceID and different CallID & CRV) - or even on ARQ for this new call
-
> the gatekeeper does the following:
> 1. Make two calls to the MCU, and get them to state "connected".
> 2. Send the MCU the terminal capability sets for the endpoints in the
existing
> call (one on each call).
> 3. Do master-slave determination on each call (the gatekeeper will be
"master"
> on the original calls, otherwise you're stuffed - but in this case there
was
> already an MCU in the call, so no problem) - in which the gatekeeper will
end
> up as "slave" (all MCUs beat all GKs).
> 4. "Wire things up" internally such that instead of all the Q.931 and H.245
> messages going directly from one endpoint to the other, each endpoint talks
to
> the MCU on a different call.
> ...and you have a two-party conference (as opposed to a call). The MCU
will
> now generate various exotic messages, and the endpoints will respond
> beautifully - the gatekeeper just passes things through transparently now.
Assume that the gatekeeper uses the half call model. Let us say that the callId
of the original call was CIo, and callIds of the new calls from gatekeeper to
the MCU are CIn1 and CIn2. Now, at the gatekeeper, there are two calls in the
conference, one call has one call leg with callId CIo and other call leg with
callId CIn1, and the other call has one call leg with callId CIo and the other
call leg with callId CIn2. Now, if one of the terminals, want to send any call
signalling message e.g. facility to its peer (terminal does not know it is
connected to MCU), it will send this message with callId CIo. In this case,
gatekeeper has to interpret the message and change its contents to reflect the
new callId. This will make the gatekeeper very complex and lead to many
interoperability issues as it will be very specific implementation of this
feature as opposed to a well defined scenario in the protocol itself.
>
> Alternatives/extras:
> If you trust people to have implemented H.450.2, or you care about
everybody
> paying properly for everything,
>
How are various charging models for supplementary services like H.450.2 and
H.450.3. Are these very much same as SCN or some other models totally different
from SCN models?
How does charging issues affect the conversion of call into ad-hoc
conference?
> you could transfer the calls to the MCU using
> H.450.2.
> You could send some "CloseLogicalChannel"s to the endpoints in the original
> call before connecting them up to the MCU, so that the MCU starts from a
"clean
> sheet".
>
> What I've given is a bit of an outline, and it does need a little
refinement,
> but essentially it should give you a call-to-conference transition with the
> endpoints concerned having little or no knowledge of what's going on!!!
>
> Regards,
> Chris
> --
> Dr Chris Purvis -- Development Manager
> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> Winkfield Row, Berkshire. RG42 6LY ENGLAND
> Phone: +44 1344 899 007
> Fax: +44 1344 899 001
