Subject: RE: Polls of MGC

From: Dave Sclarsky <[email-masked]>
Date: Fri, 18 May 2001 15:07:05 -0400

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.  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!

DaveS.

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Friday, May 18, 2001 3:00 PM
To: Dave Sclarsky
Cc: 'Rosen, Brian'; [email-masked]'; [email-masked]
Subject: Re: Polls of MGC

If the MGC doesn't have the capability to save *SOME* information 
about the ResGW, like the mapping between it's IP address and 
Johnie's Dad's phone number, it will never work.

Given the capability to save this information, what information
can't it save?  What doesn't it know when it reboots?  Just
the port number?  Why not keep it simple and make it know
that too?

-troy

Polling is bad.
The traffic it causes is bad.
The logic of using it to solve this problem is bad.
It is bad enough to make people look for other protocols.

Dave Sclarsky wrote:
> 
> Brian,
> We cannot let the MGs wait until they need to send something before
learning
> that an MGC went down.  You could have a ResGW disconnected from the
network
> all night!  What if Johnny at college needs to call home at 3am to bail
him
> out of jail?  Dad's controlling MGC won't be able to make his phone ring
> because Dad hasn't made a call since the MGC restarted!  I guess if you're
> Johnny's dad this is a good thing :-)
> 
> DaveS.
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 11:22 AM
> To: 'Troy Cauble'
> Cc: [email-masked]'; [email-masked]
> Subject: RE: Polls of MGC
> 
> Y'know, I've asked myself that.  I'm not sure I'd use it IFF
> the whole process of finding an MGC and getting back up was fast
> enough to not cause problems with subscribers.
> 
> My conclusion is that it COULD take a long time, and thus I think
> finding it out sooner is better.  I don't feel so strongly that
> I think we just GOTTA change the protocol.
> 
> Brian
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:[email-masked]]
> > Sent: Friday, May 18, 2001 11:15 AM
> > To: Rosen, Brian
> > Cc: [email-masked]'; [email-masked]
> > Subject: Re: Polls of MGC
> >
> >
> > "Rosen, Brian" wrote:
> > >
> > > This discussion is not specifically detecting failure of the
> > > MGC by timeout of response to a message.  It has to do with
> > > detecting failure of the MGC when there is no message flow.
> >
> > Brian,
> >
> > I think the question is why do we *NEED* to detect failure
> > when there is no message flow?  Why not wait and detect it
> > when the MG tries to send something?  (From the MGs view,
> > nothing has failed yet!)
> >
> > -troy
> >

---

From: Troy Cauble <[email-masked]>
Date: Fri, 18 May 2001 15:24:06 -0400

Dave Sclarsky wrote:
> 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

---

From: "Paul Long" <[email-masked]>
Date: Fri, 18 May 2001 14:45:43 -0500

Troy,

Bad polling! Bad polling! You're a bad polling! Bad, bad, bad! :-) Sorry, I
couldn't resist.

I don't know the underlying protocols very well at all, but doesn't TCP
itself poll or send keep-alives? Isn't that how each side knows when the
connection is lost? How about mobile networks? Surely the phones and cell
nodes do something like this, too, don't they? It seems like when you get
away from a dedicated piece of wire from the phone (I'm thinking residential
MGs) to the local end-office switch, you're going to have to have some kind
of periodic signal to verify the connection with the controlling entity.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Troy Cauble
Sent: Friday, May 18, 2001 2:24 PM
To: Dave Sclarsky
Cc: 'Rosen, Brian'; [email-masked]'; [email-masked]
Subject: Re: Polls of MGC

Polling is bad.

-troy

---

From: Christian Groves <[email-masked]>
Date: Wed, 23 May 2001 23:48:14 +1000

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

---

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

Hi Groves/all,
Since that start of this thread, back of my mind I was not able to convince
myself why polling from MG is necessary (Infact I posted couple of mails
too) But since there was no response from the list I started thinking about
how polling can be advantageous. I ended up taking an example as follows.
For Ex: In a residential gateway when there is no communication between MG
and MGC for long Duration. If the Residential user goes offhook a Notify is
generated towards the MGC. If the MGC is down the MG initiates the
registration with other MGC. But after Registration with the MGC I think the
offhook event will not again be sent to the new MGC. Thus introducing a
chance of dropping one call (or calls originated at that time) when MGC is
down. I think polling will enable the MG to learn about the MGC's status and
thus enabling the MG to handle these calls originated from the MG.

Of course this doesn't eliminate the chance of dropping the call during the
inter-polling time.

I'm not sure how in case of Trunking gateway this is advantageous.

Regards
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Christian Groves
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,

Cheers, Christian

---

From: "Paul Long" <[email-masked]>
Date: Wed, 23 May 2001 11:49:51 -0500

Christian,

As Dave said, your #2 does not consider an incoming call. It is therefore
_not_ true that "interaction is only needed with the MGC when the end-user
does something." Without periodic signaling between the MG and MGC whereby
the MG can detect MGC failure and switch to an operative MGC, incoming calls
will be missed after MGC failure and until there is end-user activity.
Period. Are you saying that this is satisfactory behavior given the penalty
of extra bandwidth consumption that periodic signaling would entail? That's
a valid position, but I want to be sure that you have taken this into
consideration. Maybe you and others are saying that losing an association is
like leaving the phone off the hook--the end user will miss incoming calls
until he or she needs to make a call.

Paul Long
ipDialog, Inc.

-----Original Message-----
Sent: Wednesday, May 23, 2001 8:48 AM

G'Day Troy et all,

Cheers, Christian

---

From: Troy Cauble <[email-masked]>
Date: Wed, 23 May 2001 14:48:50 -0400

Paul Long wrote:
> Period. 

Only when you base your argument on the assumption that the MG 
is the only one that can repair the relationship.

The MGC can detect and fix this problem.

-troy

> Are you saying that this is satisfactory behavior given the penalty

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 23 May 2001 13:07:18 -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).

--
------------------------------------------------------------
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

---

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

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).  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.