Subject: Re: MGC Recovery

From: Brian Rosen <[email-masked]>
Date: Wed, 18 Aug 1999 09:19:52 -0400

We had earlier discussed polling events.  We decided that they
could be in a package.

Recovery implies that the MG detected the failure of the MGC.
In that case, it should contact an alternate.  If the original
returns to service, I'd say the protocol is silent about what
happens.  Two obvious choices are that the secondary returns
control to the primary with the handover serviceChange.  The
second is that it keeps control.

Considering a third; the original demands return of control,
is not something I'm thrilled about.

Brian

> -----Original Message-----
> From: Bilalis Zacharias [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 3:05 AM
> To: [email-masked]
> Subject: MGC Recovery
>
>
> How can the MG detect the MGC recovery? I think there are two
> solutions:
> 1. MGC announces a 'return to service' by issuing a service change
> 2. MG polls regularly the status of MGC.
>
> I propose to include those methods in the chapter 'Failure of an MGC'
>
> Zacharias Bilalis
>
> SIEMENS ICN WN CS EC D12
> > Schertlinstr. 8
> > D-81359 Muenchen
> > Germany
> >
> Tel: + 49 89 722 28391
> Fax: + 49 89 722 61243
> Mail to: [email-masked]
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Aug 1999 08:33:50 -0700

> is not something I'm thrilled about.

   The MGC's MUST internally synchronize such that
a single termination is only ever controlled by
one MGC. Therefore, any "demand" is out of scope
of MEGACO; it implies that the MGC's aren't
communicating with one another.
   Besides, having zillions of MG's polling for a
lost MGC is good way to produce a network
meltdown.

                Mike