Subject: RE: Polls of MGC

From: Dan Elbert <[email-masked]>
Date: Thu, 24 May 2001 09:33:49 -0500

Hi Christian
I was referring to the case were there is no redundancy or redundancy fails.
I was trying to see what is the minimal level of support that the protocol
has to provide. I think that you can have the same problem in TCP, i.e., the
connection was broken but you didn't detect it until trying to send a
Notify.
As other people pointed, one of the problems of waiting for the MG to send a
Notify to reconnect is when another party try to contact the disconnected
MG, and other problem is with specific MG's that will never generate
Notifies.
A final point that I'd like to make is that probably this issues will be
less important when we have very reliable MGCs, but they are very useful for
the development phase. That's why having some kind of parameter configurable
by the MGC will be very useful.

Dan

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 5:43 AM
To: Dan Elbert
Cc: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Troy Cauble'; 'Rosen,
Brian'; [email-masked]; [email-masked]
Subject: Re: Polls of MGC

G'Day Dan,

I don't understand "the MGc can never contact the MG because it doesn't
know where the MG is listening". The MGC should at least maintain the
state of registered MGs. This problem is not unique to the "polling"
situation described in 1 & 2. H248 clause 11.5 covers MGC failure.

If a MG is registered with a certain MGC to accept incoming calls then
its up to the operator of the MGC to provide an alternative in case of
failure. 11.5 describes how the new MGC can use the same identity.

On an outgoing call from the ResGW if it detects an MGC failure it can
always choose and register with another MGC in its list.

You could also use a reliable connection oriented transport and give
UDP/ALF a miss and solve your problems.

Christian

Dan Elbert wrote:
>
> 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: Laurent Nicolas <[email-masked]>
Date: Thu, 24 May 2001 13:09:56 -0400 (EDT)

Dan, the point is that for TCP or UDP we have a client/server model.
The MGC is the server, and stays in listen mode, waiting for clients to
initiate connections.  It is better to have the server on the MGC because
a server is more complex.
The MG then acts as a client and is supposed to initiate the TCP or UDP
connection with a MGC.

For TCP, liveness (or poll) is part of the protocol.  So if connectivity
is lost, the TCP client will detect it, and the MG can then try to
reestablish the connection with the same MGC or an alternate MGC.

For UDP, there is no liveness, so the application must take care of it if
required.  A way to achieve it (as already said), is for the MG to start
an inactivity timer when it receives something from the MGC.  If the MGC
is regularly polling the MG, then the MG will rearm this timer and has
nothing to do.  If the MG does not hear from the MGC, it can then initiate
a recovery procedure.

cheers, Laurent