Subject: MG-MGC control interface

From: "Petros N. Mouchtaris" <[email-masked]>
Date: Fri, 29 Oct 1999 15:24:32 -0400

I find section 11 confusing. I haven't followed all of its iteration but as it
stands now it is confusing me.

Section 11 talks about multiple MGCs controlling one MG that may be partitioned
into multiple virtual MGs.
It then talks about a single primary MGC and several secondary MGCs.

At cold start, the MG notifies the primary MGC. Is it assumed that the primary
MGC will contact all other MGCs that are controlling the other virtual MGs? How
are other MGCs (controlling the various virtual MGs) going to find out about the
cold start?

Section 11.3 (Failure of an MG) is even more confusing.  If I understand it
right, this section talks about an MGC sending all commands to two MG, a working
one and a standby one. Only the working one actully executes the commands. I'm
unclear about what this is achieving. Can anybody explain? I can't even guess
how this would work.

Petros

---

From: Brian Rosen <[email-masked]>
Date: Fri, 29 Oct 1999 15:57:32 -0400

> MGC will contact all other MGCs that are controlling the
> other virtual MGs?
No.  You are getting the two concepts confused; they are totally separate.
If you have multiple virtual MGs, each one would have
a primary MGC and multiple secondary MGCs.  Perhaps primary/secondary is an
unfortunate choice of words, think of them both as an ordered list, the
primary merely being the first one on the list.

> How
Each virtual MG contacts its own MGC.  It starts with the first
one on its list and keeps going down the list until one of the MGCs accepts
it.

> one and a standby one. Only the working one actually executes
> the commands. I'm
If you had a redundant pair of MGs, the MGC would send the same commands to
both of them, but only the active one would do something - the standby one
would only track state.  If the MG fails but can still send messages, it
sends failover, and the MGC then uses the secondary as the active.  If the
MGC detects failure, it can activate the standby MG.  The wording could be
improved here.

Brian

---

From: "Petros N. Mouchtaris" <[email-masked]>
Date: Fri, 29 Oct 1999 16:46:49 -0400

>primary merely being the first one on the list.

This makes more sense. I was confused by the fact that the text stops using the
term virtual MG.
I thought it meant physical MG.

By the way, how does a virtual MG know that a message coming from the MGC is
destined
for this virtual MG? I assume that messages to all virtual MGs in the same
physical MG go to the
same IP address. The MGC IP address can be used as a way to route messages to
the right
virtual MG provided that the list of MGC for each virtual MG are mutually
exclusive.

>one on its list and keeps going down the list until one of the MGCs accepts

Sounds good.

>MGC detects failure, it can activate the standby MG.  The wording could be

What is the purpose of having the standby MG track the state? Is the goal to be
able to keep calls
alive when the active one fails and the standby takes over? I would think that
it is more likely that
the callers will hang up before the standby MG can take over.
I don't think this is worth wasting the bandwdith for carrying all messages
twice.

Petros

---

From: Brian Rosen <[email-masked]>
Date: Fri, 29 Oct 1999 17:09:51 -0400

> virtual MG provided that the list of MGC for each virtual MG
Actually it's more complicated than that, since, at least in
theory, the same MGC could control multiple virtual MGs on the same physical
MG.

The answer is that the mId of the message would be unique for each virtual
MG.  That implies you have something like
aliases in your DNS.

> I don't think this is worth wasting the bandwdith for
I won't presume to predict whether this would indeed occur.
If the MG is alive enough to send messages, the user may not notice.
Anyway, some people wanted it, and it seemed "free".
I believe it will be very hard to do in any way which is not proprietary,
and you don't need protocol support for proprietary mechanisms.

Brian