Subject: RE: Polls of MGC

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 May 2001 15:06:44 -0400

There is no way for the alternate MGC to take over control
of the MGs.  That is a design decision, and we made it because
of security concerns ("Hello, I'm your new boss, don't worry
about a thing")

Whether you know about port numbers or not, another MGC cannot
break into an existing control association.  There are ways that
you can build redundant MGCs that can do a takeover where the
MG is unaware of the takeover.  That is not the circumstance we
are discussing.

That means the MG is the one that discovers the MGC is dead, and
it needs a way to do that.  

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 2:53 PM
> To: Paul Long
> Cc: [email-masked]
> Subject: Re: Polls of MGC
> 
> 
> Paul Long wrote:
> > 
> > Troy,
> > 
> > I was leaning towards the no-polling camp, but then I 
> thought about a
> > situation that hasn't been mentioned yet. We could just 
> wait until the
> > subscriber attempts to place a call to find an available 
> MGC, but what about
> > incoming calls? If the MGC is down, that subscriber cannot 
> be reached until
> > after he or she attempts to place a call. For that reason 
> alone, I think we
> > need a MG-to-MGC polling mechanism.
> > 
> > Paul Long
> > ipDialog, Inc.
> 
> Paul,
> 
> *Why* can't that subscriber be reached?  What doesn't the 
> backup MGC know?
> Dan just pointed out to me the only hole I see:  the port number.
> 
> Reverse polling and notification is not the way to fix that.
> Make it known to the MGC, via a "default or configurable" statement
> in the docs.  The MGC knew the IP address right?  That would be 
> shared with the backup MGC right?  Why wouldn't the port number 
> be the same?
> 
> You guys don't have some vision of COMPLETE discovery and re-discovery
> do you?
> 
> 	Discovery of capabilities is nice.  But in the real world an
> 	MGC will have to be at least minimally configured for MGs.  
> 	Even if an MGC can find out that a box at IP address X is an 
> 	Y profile RG, or an Z profile TG, it'll have to be told some 
> 	details like what phone numbers map into an RG.  
> 
> 	Even if it doesn't map to the outside world like an RG's phone 
> 	numbers, there are issues of trust.  Consider an announcement 
> 	server that does a standard package of announcements.  I would 
> 	expect an MGC to only use ones it's been told are OK, instead 
> 	of any one that signs up.  Otherwise it's a hack waiting to 
> 	happen -- "alternative" announcements.
> 
> Make the port number known the the MGC.
> 
> 
> 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.
> 
> 
> -troy
> 
> 
> P.S.  I don't send e-mail to everyone I know once a minute
> so I will know in advance if their e-mail is broken.
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Troy Cauble
> > Sent: Friday, May 18, 2001 10:40 AM
> > To: Rosen, Brian
> > Cc: [email-masked]'; [email-masked]
> > Subject: Re: Polls of MGC
> > 
> > "Rosen, Brian" wrote:
> > >
> > > 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.
> > 
> > I haven't followed this thread enough to know if the "process"
> > is even known yet.  (I mostly obsess on the parsing issues.)
> > 
> > I think the MGCP/NCS use of DNS is fairly good, but I doubt
> > the timer & count values are such that, for example, it's not
> > visible to a user in a residential gateway situation.
> > 
> > But MGC failure will be a non-frequent event, so I think
> > that some small amount of recovery time is OK and better than
> > the alternative of polling.
> > 
> > > 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.
> > 
> > In terms of the "process" being fast:  How fast is it
> > going to be for the MGs that need to get through to a new MGC
> > because they're trying to put a call though, when 2000 MGs with
> > no immediate beat them to it because of their polling cycle.
> > 
> > I think that polling is a bad idea in either direction.
> > 
> > -troy
>

---

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

> of security concerns ("Hello, I'm your new boss, don't worry

Security isn't in *how* it's discovered.
Security is in what action is taken.

If the MG discovers his MGC is dead by polling, he
goes to his pre-configured list of secondary MGCs, yes?

How is this less secure than letting him accept
"I'm your new boss" from MGCs on that list?

> MG is unaware of the takeover.  That is not the circumstance we

Than what are we discussing???  If you can fix the problem without 
the MG knowing about it, why are discussing ways the MG can discover 
the problem ????

Polling is bad.

-troy