Subject: RE: Polls of MGC

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 May 2001 11:22:29 -0400

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 11:39:46 -0400

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

> 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: "Paul Long" <[email-masked]>
Date: Fri, 18 May 2001 11:49:59 -0500

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.

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

-troy

---

From: Troy Cauble <[email-masked]>
Date: Fri, 18 May 2001 14:53:11 -0400

> need a MG-to-MGC polling mechanism.

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.

---

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

Troy,

Yes, I was assuming that alternate MGCs would not be aware of the previous,
now-failed association. It seems like you are making an awful lot of
assumptions about those MGCs.

Regarding your email comment, our expectations vary according to the
communication medium. For example, I know that email may get lost or
delayed, so I factor that into my expectation of a timely reply. By
contrast, when I place a phone call, I fully expect to get an accurate and
immediate busy or ring signal.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 18, 2001 1:53 PM
To: Paul Long
Cc: [email-masked]
Subject: Re: Polls of MGC

Paul,

Polling is bad.

-troy