Subject: Re: Polls of MGC

From: Terry L Anderson <[email-masked]>
Date: Wed, 23 May 2001 23:30:32 -0400

(resending since my original seems not to have made it to the list)

MGC/MG relationship is indeed master/slave but registrations are only
initiated
from the MG end, so MGC being aware of loss of connectivity or an
alternate MGC
being aware that the primary is down does not allow reconnection to the
alternate - only the MG can take action to register with the alternate
(as in
11.5).  So it seems to me most important that MG detect failures (as it
is the
only one that can take action).  Its the MGC that can do little when it
detects
a failure.
MGC perhaps should make the decision as to whether failures should be
detected
and frequency of polling but it seems to me that MG should do the
polling.

For failures of a TCP link or MGC failure and recovery without loss of
state,
MGC may reestablish communications with a re-registration, but I don't
understand how an alternate MGC can take over after a primary failure
without MG

detecting the failure.

I did not think that an MG normally sent Add, Move, Subtract.  I believe
that
the only MG initiated transactions commonly used are Notify and
ServiceChange.
Thus during a quiet period (edge GW with SS7/ISUP signaling, no active
calls),
there would be no active events and so no reason to send either Notify
or
ServiceChange and so GW would be unaware that:
1. MGC has gone down
2. network has lost connectivity to MGC

In either case, without polling, MG would be unaware.  Yet registering
with
alternateMGC might allow it to handle calls.

I thought that the previously discussed methods for MGC and for MG
polling were
adequate but if we want to add a new mechanism, one could allow complete
control

from MGC end by adding a "timer" event through a package.  MGC could
activate
the timer event on say root termination and this would cause a notify
after the
MGC specified period.  MGC would detect failure by lack of this notify.
MG
would detect failure when the Notify received no reply.  MGC thus
decides
whether polling should occur, what period to use and there is only
polling
traffic in one direction but both ends detect failure.  It would be
improved if
the package specified that the timer was automatically reset by any
messages, so

it would fire only when no messages had been exchanged for the specified
time
(MGC would still detect failure by absense of any message for greater
than the
timer period, MG detect by failed reply).

Christian Groves wrote:

> G'Day Troy et all,
>
> Sorry for the late support of No Polling. I still have not seen a
> definitive reason that the MG needs to poll the MGC. We have defined a

> master slave protocol with the MGC as the master. The MGC should be in

> control of error situations.
>
> I believe that it's enough that the MG can detect that the MGC has
gone
> down when it try to signal using any appropriate H.248 Commands ie.
> Add, Move, sub replies, Notify request, Service Change etc. Lack of
> timely response will indicate failure. The MG can then re-register
based
> on this.
>
> If you look at the common MG use cases:
> 1. The MG is a trunking gateway. In this scenario enough traffic will
be
> generated to maintain a reasonable flow of signalling to minimise the
> time to detect errors. For a proper Telco solution you should also
have
> enough management systems/redundency to know what MGC to hand over to.

>
> 2. The MG is a residential gateway. Signalling traffic is not that
great
> but interaction is only needed with the MGC when the end-user does
> something. Therefore the MG will find out about the failure at this
> time. Why generate unessary signalling across limited BW links?
There's
> the avalanche problems mentioned earlier but more importantly someone
> will have to pay for bandwidth this signalling takes which basically
> serves no purpose.
> Again in this scenario the MGC will hopefully be owned by someone who
> wants to offer a decent service and has the necessary management
> systems/reduncy. I do not envisage MG registration will take very long

> on a small residential gateway. Its a ServiceChange request/response
> round trip.
>
> What ever the proposed package, service change reason/method, protocol

> update polling is unecessary.
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Dave Sclarsky wrote:
> > >
> > > Troy,
> > >
> > > It doesn't matter what the new (or restarted) MGC knows or doesn't
know.
> > > Megaco defines that the control association between MG and MGC is
ALWAYS
> > > initiated by the MG.
> >
> > Then this definition is the problem and should be revisited.
> >
> > Polling is bad.
> >
> > -troy
> >
> > > Given that definition, Johnny's Dad's MG won't be
> > > reachable by a new (or a restarted) MGC until the his MG notices
the
> > > failure.  We must define a way for it to know ASAP!

--
-------------------------------------------------------
Terry L Anderson, DMTS                   [email-masked]
Lucent Technologies /INS/ Voice over IP Access Networks
Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
Voice:908 582-7013  FAX:908 582-6729
http://its.lucent.com/~tla  (Lucent internal)
http://www.gti.net/tla
-------------------------------------------------------

---

From: "atanum" <[email-masked]>
Date: Thu, 24 May 2001 10:09:24 +0530

Hi all,
How about defining a sanity punch message on the MGC end which will be sent
towards the MG at regular intervals if there is no standard message to
communicate to MG. In that case if a timer is defined in the root of the MG,
it cannot get timed out since even if there is no standard message coming
from the MGC, the sanity punch continues to reach which will restart the
timer of the MG. If the timer in the MG times out, it knows that the MGC is
down and it goes for registration with the secondary MGC....

Regards
Atanu

---

From: Troy Cauble <[email-masked]>
Date: Thu, 24 May 2001 09:56:46 -0400

Terry L Anderson wrote:
> 11.5).  

Again, it seems much cleaner to fix this problem by changing
"registrations are only initiated from the MG end" statement.  
Why are MGC initiated regstrations considered so evil?

-troy

> So it seems to me most important that MG detect failures (as it
> is the