Subject: RE: Polls of MGC

From: Dan Elbert <[email-masked]>
Date: Wed, 23 May 2001 09:44:56 -0500

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: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Wed, 23 May 2001 11:22:03 -0400

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'

Hi

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,

Regards
Madhubabu

-----Original Message-----

Christian,

---

From: Christian Groves <[email-masked]>
Date: Thu, 24 May 2001 19:43:19 +1000

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

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 24 May 2001 12:24:32 -0400

But Christian,

I agree that a recovered-after-failed MGC should be able to reestablish
communications (should have fault-tolerant state info), but you are ignoring the
case of a failed MGC where an alternate MGC might take over.  It might share
state with the failed MGC but CANNOT reestablish communications unless it assumes
the failed MGC's network address (then it is not really an alternate MGC - it is
part of a fault-tolerent MGC - probably a better idea but not the only choice
H.248 should support).

Even the case of altMGC taking over works for your ResGW case where GW is left
with an active event but for SS7 signaling where new calls are initiated at MGC
end and GW's have no active events when outside a call, recovery will never
occur.  So unless we believe there is no need to support altMGCs for recovery in
such systems, we need a way for MGs to become aware of primary MGC failure.

(we have customers insisting on this very feature)

--
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla