Subject: RE: MGC failure

From: "Groom, William" <[email-masked]>
Date: Thu, 3 May 2001 08:46:45 -0400

Dan,

With regards to the first part of your question. I hope the following helps.

Clarification Of Problem:

When the MGC restarts (including O/S) all associations to the MG are lost.
No messages can be sent from the MGC to the MG until the MG has sent a SC
(restart message on root).

If the connection is TCP, then the MG will get to know about the MGC restart
(eventually) and can go through its normal restart processing to
re-establisg MGC connections. 

If UDP, then the MG is oblivious to the MGC restart.  The action taken by
the MG will depend upon the state of the MG at the time of the MGC restart.
I.E.

1. MG is active carrying traffic. In this state the MG will timeout the MGC,
break existing MGC associations and reconnect. This is fine.

2. MG is already trying to connect. This is also fine.

3. MG is Down (offline). This is fine since it will establish connection
upon restart.

4. MG is Idle (No calls in progress). A trunking MG will remain in this
state forever, until some manual intervention takes place. This is the main
concern we are trying to address. Other gateway's (E.G. Residential) will
detect signals that will eventually lead to a timeout of the MGC and
connection re-establishment taking place.

Two Possible Proposals (there maybe others)

1. Heartbeat Message

I believe a package has been proposed where the MG heartbeats the MGC
(signal on root). I have not seen any proposal nor do I know of the status
of such a proposal. Perhaps someone (Brian) could comment on this.

2. Using Service Change Message

I have not seen this proposal, but cannot see why it would not work.

Upon startup of the MGC, a UDP SC message could be sent to each MG with the
ServiceChangeMgcId set to the MGC IP address. To the MG, this message will
look like a handover of the MGC to itself. 

Note this message is not a connection request, just a message to inform the
MG to re-establish new MGC connections.

The first option is preferred (but none standard) as it caters for the
problem where the MGC goes down and stays down.

Regards
Bill Groom
Siemens

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 5:06 PM
To: [email-masked]'
Subject: MGC failure

Assume that the MGC goes down and up again.
Is there any way for the MGC to indicate the MGs that they need to send a
SVC, or is only the MGs responsibility to have some sort or "keep alive"
(e.g. by sending a noop SVC if nothing is coming from the MGC in a long
time). ?
Note that the MGC doesn't know what port the MG is using.
Related to this, what is the standard response if the MGC receives a Notify
from an MG that is not registered ? ( Because it was registered and then MGC
went down and up again) . Should it send a reply with an error so the MG
knows that it must send a SVC, or just ignore it ?

Thanks,
Dan Elbert
RADVISION

---

From: Ian Leighton <[email-masked]>
Date: Thu, 03 May 2001 09:30:14 -0400

Hi William

Can you explain what timeout you are referring to in problem 1.

Although my understanding of the spec is limited, I believe that
events are not a mandatory part of the spec. If this is true then
problem 1 is not  solved by the MG sending SC.

Regards
Ian