Subject: RE: Polls of MGC

From: Dave Sclarsky <[email-masked]>
Date: Wed, 23 May 2001 10:23:20 -0400

Christian,
What happens when the MGC wants to ring a phone on an MG that is a ResGW,
but that MG still thinks tbat it is connected to a 'broken' MGC?
DaveS.

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 9:48 AM
> To: Troy Cauble
> Cc: Dave Sclarsky; 'Rosen, Brian'; [email-masked]'; 
> [email-masked]
> Subject: Re: Polls of MGC
> 
> 
> 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!
>

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Wed, 23 May 2001 10:37:05 -0400

HI Dave,
If the MG is connected to the "broken" MGC how can it receive commands from
two MGC's. The MG should reinitiate the registration for accepting messages
from the new MGC.

Regards
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dave Sclarsky
Sent: Wednesday, May 23, 2001 10:23 AM
To: 'Christian Groves'; Troy Cauble
Cc: Dave Sclarsky; 'Rosen, Brian'; [email-masked]'; [email-masked]
Subject: RE: Polls of MGC

Christian,