Subject: RE: Polls of MGC

From: "Michael Brown" <[email-masked]>
Date: Wed, 23 May 2001 14:49:36 -0400

Hello all,

   Given all the traffic on this thread and that I was content that my
opinion was being expressed by others, I didn't feel compelled to post. But
since this topic seems to be going around again...

   I am also in the camp that polling BY the MG is unnecessary. Until
Christian's post, I think the biggest consideration that has not been taken
into account is that any reliable telephony system/network requires that
there is a robust network management system. IMHO, the scenarios proposed
that SEEM to point to using a polling mechanism (MGC has gone down and calls
to the MG will simply fail) will not happen. If an MGC crashes before being
able to a initiate graceful recovery/transition, it will not go unnoticed
from the network management perspective. This will (as suggested earlier) be
considered to be a "reportable" outage and I don't believe that any operator
or (potentially) regulatory agency is going to be content to say "it's OK...
service will be restored eventually".

   On the other hand in order to support the scenario in Megaco where the MG
autonomously detects an MGC outage and "rehomes" on a secondary MGC, there
have been a couple of proposals based on polling by the MGC (or lack
thereof) which would work quite nicely to address an outage. The idea of
defining a property on the ROOT of the MG for "MGC polling time" works very
well. Using this, the MG can determine that the MGC hasn't been
communicating as expected. The MG could use a ServiceChange with a
Disconnected method to attempt to contact the MGC. If that transaction
fails, the MG could then decide to go on to it's backup MGC.

  For the case where the network management system is responsible for
"monitoring" and correcting control association outages, the property could
be set such that the MG is not expecting polling or is set to a relatively
long time interval as an "emergency" backup.

  Either way, I think that this mechanism does address the issues and
doesn't require polling by the MG.

Michael Brown

-----Original Message-----
From: Knight, Ty [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 12:21 PM
To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Dan Elbert';
'Christian Groves'; 'Troy Cauble'
Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
Subject: RE: Polls of MGC

Hello Madhubabu / all,

#2 only works if there is active messaging. It seems to me that unless we
can guarantee that there is always message traffic from the MG to the MGC,
it alone is not a solution.  #1 is merely a way to guarantee traffic. 

A simple problematic scenario is as follows (for a trunking solution):

	1. MG after cold start is sending registration SvcChg to MGC. There
is no active callp.
	2. MGC accepts the association and sends the SvcChg reply to the MG.
Both are happy.
      3. Before any callp can be started, the MGC recovers.

The MG will never attempt to contact the MGC. It especially won't
re-register since it doesn't detect a problem. The MGC can't send a message
to the MG because the MGC has lost it's association data and doesn't know
which port to send it to.
	
Regards,
Ty

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

RE: Polls of MGC
Yes, This seems to be logical. Define some property (MGC polling time) on
ROOT and if MGC didn't send any message/response for this duration then MG
will initiate SC with "disconnected" method. Else if MG receives
commands/responses from MGC this timer needs to be restarted at the MG with
the same defined duration. Thus avoiding any polling from the MG.

Regards
Madhubabu
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Michael Brown
  Sent: Wednesday, May 23, 2001 2:50 PM
  To: [email-masked]
  Subject: RE: Polls of MGC

  Hello all,

     On the other hand in order to support the scenario in Megaco where the
MG autonomously detects an MGC outage and "rehomes" on a secondary MGC,
there have been a couple of proposals based on polling by the MGC (or lack
thereof) which would work quite nicely to address an outage. The idea of
defining a property on the ROOT of the MG for "MGC polling time" works very
well. Using this, the MG can determine that the MGC hasn't been
communicating as expected. The MG could use a ServiceChange with a
Disconnected method to attempt to contact the MGC. If that transaction
fails, the MG could then decide to go on to it's backup MGC.

  Michael Brown

  -----Original Message-----
  From: Knight, Ty [mailto:[email-masked]]
  Sent: Wednesday, May 23, 2001 12:21 PM
  To: 'Madhu Babu Brahmanapally'; 'Dave Sclarsky'; 'Dan Elbert';
  'Christian Groves'; 'Troy Cauble'
  Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
  Subject: RE: Polls of MGC

  Hello Madhubabu / all,

          1. MG after cold start is sending registration SvcChg to MGC.
There
  is no active callp.
          2. MGC accepts the association and sends the SvcChg reply to the
MG.
  Both are happy.
        3. Before any callp can be started, the MGC recovers.

  The MG will never attempt to contact the MGC. It especially won't
  re-register since it doesn't detect a problem. The MGC can't send a
message
  to the MG because the MGC has lost it's association data and doesn't know
  which port to send it to.

  Regards,
  Ty

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

  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,

---

From: Chuong Nguyen <[email-masked]>
Date: Wed, 23 May 2001 17:05:24 -0500

Hi All

This sounds good since SC Disconnected is defined to be used if MG
thinks it has
temporary lost it connection w/MGC.
So say that originally (for UDP), MGC has specified a
ServiceChangeAddress of 55555.
So MG was sending msgs to MGC at port 55555.

Now there is some disconnection, does MG send the SC Disconnected to
55555 or
2944?
Should MGC accept SC Disconnected on 2944 if it has specified 55555?

So far is it agreed that SC Restart, Failover, HandOff are registration
SCs thus
they always go to 2944?

(By the way no matter how you word it. It is still polling.)

What about MGC wanting to detect if MG is up or not?

In response to all the questions do we need polling, there are customers
that have
been asking if UDP is used how does MG and MGC know if each other are
down.
So if the customer wants it, are we going to say NO?

Chuong

Madhu Babu Brahmanapally wrote:

> Yes, This seems to be logical. Define some property (MGC polling time)
> on ROOT and if MGC didn't send any message/response for this duration
> then MG will initiate SC with "disconnected" method. Else if MG
> receives commands/responses from MGC this timer needs to be restarted
> at the MG with the same defined duration. Thus avoiding any polling
> from the MG. RegardsMadhubabu
>
>         Given all the traffic on this thread and that I was
>      content that my opinion was being expressed by others, I
>      didn't feel compelled to post. But since this topic seems to
>      be going around again...
>
>         I am also in the camp that polling BY the MG is
>      unnecessary. Until Christian's post, I think the biggest
>      consideration that has not been taken into account is that
>      any reliable telephony system/network requires that there is
>      a robust network management system. IMHO, the scenarios
>      proposed that SEEM to point to using a polling mechanism
>      (MGC has gone down and calls to the MG will simply fail)
>      will not happen. If an MGC crashes before being able to a
>      initiate graceful recovery/transition, it will not go
>      unnoticed from the network management perspective. This will
>      (as suggested earlier) be considered to be a "reportable"
>      outage and I don't believe that any operator or
>      (potentially) regulatory agency is going to be content to
>      say "it's OK... service will be restored eventually".
>
>         On the other hand in order to support the scenario in
>      Megaco where the MG autonomously detects an MGC outage and
>      "rehomes" on a secondary MGC, there have been a couple of
>      proposals based on polling by the MGC (or lack thereof)
>      which would work quite nicely to address an outage. The idea
>      of defining a property on the ROOT of the MG for "MGC
>      polling time" works very well. Using this, the MG can
>      determine that the MGC hasn't been communicating as
>      expected. The MG could use a ServiceChange with a
>      Disconnected method to attempt to contact the MGC. If that
>      transaction fails, the MG could then decide to go on to it's
>      backup MGC.
>
>        For the case where the network management system is
>      responsible for "monitoring" and correcting control
>      association outages, the property could be set such that the
>      MG is not expecting polling or is set to a relatively long
>      time interval as an "emergency" backup.
>
>        Either way, I think that this mechanism does address the
>      issues and doesn't require polling by the MG.
>
>      Michael Brown
>
--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****