Subject: RE: Polls of MGC

From: Dave Sclarsky <[email-masked]>
Date: Wed, 23 May 2001 12:22:56 -0400

Madhubabu,

The assumption that (from Christians email below) "interaction is only
needed with the MGC when the end-user does something" ignores the
fact that sometimes the MGC needs to initiate an interaction because
an end-user on a DIFFERENT MG did something.

Here is a situation where case 2 is not sufficient:

 o UserX is connected to MG1 and UserY is connected to MG2.
 o MG1 and MG2 have established control associations with MGCPrimary.
 o UserY goes to sleep.
 o MGCPrimary goes down, and MGCSecondary takes over.
 o So far, neither MG has a control association to MGCSecondary.
 o UserX goes off-hook.
 o MG1 sends Notify to MGCPrimary.
 o MG1 notices that MGCPrimary is gone, and establishes with MGCSecondary.
 o UserX never hears dialtone and hangs up.
 o UserX goes off-hook again, hoping desperately to get dialtone.
 o MG1 sends Notify to MGCSecondary.
 o UserX hears dialtone, so dials the phone number of UserY.
 o MGCSecondary has no control association with MG2, so the phone never
rings!

We absolutely need some way for an MG to notice that an MGC has gone away
even
when there is no other activity.  Maybe this situation doesn't exists on a
Trunking Gateway, but there are other types of MGs in the network, and the
protocol must support all of them!

DaveS.

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 11:55 AM
> To: 'Dave Sclarsky'; 'Dan Elbert'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> Subject: RE: Polls of MGC
> 
> 
> Hi Dave/all,
> MG can reinitiate new control association due to two possible 
> scenarios
> 1) MG does periodic (period to be decided) polling and 
> identifies the MGC's
> failure. OR
> 2) MG if doesn't receive response for any of its commands 
> from the MGC.
> 
> But now the query is which one of the two needs to be followed???  AND
> WHY???
> 
> Without any new addition (and w/o processing overhead in 
> MG/MGC) in the
> protocol the case (2) works. So, one need to asses the 
> additional gain by
> adding the new polling logic.
> 
> 
> 
> 
> Regards
> Madhubabu
> 
> 
> -----Original Message-----
> From: Dave Sclarsky [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 11:28 AM
> To: 'Madhu Babu Brahmanapally'; 'Dan Elbert'; Dave Sclarsky; 
> 'Christian
> Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> Subject: RE: Polls of MGC
> 
> 
> Madhubabu,
> This is exactly the issue.  Since it is the MG that initiates 
> the control
> association, the new MGC cannot tell the MG anything.
> DaveS.
> 
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2001 11:22 AM
> > To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> > Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> > Subject: RE: Polls of MGC
> >
> >
> > Hi Dan/all,
> >
> > A related query...Can a new MGC indicate to MG that it is now
> > taking over
> > instead of the old MGC( I don't see any  servicechange method
> > described in
> > the protocol). Doesn't this introduce any security threat???.
> >
> > Regards
> >
> > Madhubabu
> >
> > -----Original Message-----
> > From: Dan Elbert [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2001 10:45 AM
> > To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Christian Groves';
> > 'Troy Cauble'
> > Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> > Subject: RE: Polls of MGC
> >
> >
> > Hi
> > I think the scenario can be as following:
> > 1. The MGC fails without being able to send a "Handoff"
> > 2. Later on the MGC restarts or a backup MGC comes up
> > In this case the MGC can never contact the MG because it
> > doesn't know where
> > the MG is listening.
> > So the problem stands if the MGC needs to contact the MG 
> before the MG
> > becomes aware that the connection with the MGC has been lost.
> >
> > Dan
> >
> > -----Original Message-----
> > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2001 10:37 AM
> > To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> > Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> > Subject: RE: Polls of MGC
> >
> > 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,
> > 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: Troy Cauble <[email-masked]>
Date: Wed, 23 May 2001 14:46:45 -0400

> an end-user on a DIFFERENT MG did something.

Dave,

Yes, the receiving side MG cannot detect this type of error.
But the (new) MGC detects this type of error.  Why not give it
the mechanism to fix the situation instead of insisting
that the MG detect and fix it?

-troy