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:
- Make two calls to the MCU, and get them to state "connected".
- 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