Subject: RE: Polls of MGC

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 May 2001 13:04:43 -0400

This is a whole other problem.

If the calling party is on the same MG as the called party,
then the MG discovers the MGC is down by having the notify of
off hook (or equivalent), as we have been talking about, or the poll.

If the calling party is on a different MG, but the same MGC,
then the calling party will discover the MGC is down as above.

If the calling party is on a different MG and that MG is on a
different MGC, then the calling MGC will discover the MGC is down.

In all cases, the calling party gets a busy or other error,
and the called party is blissfully unaware of a missed call.

Brian

> -----Original Message-----
> From: Paul Long [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 12:50 PM
> To: [email-masked]
> Subject: RE: Polls of MGC
> 
> 
> 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
> 
> 
> "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: "Paul Long" <[email-masked]>
Date: Fri, 18 May 2001 12:21:16 -0500

Brian,

The last two cases are what I'm talking about. The called MG will miss the
call because its MGC is down and it hasn't realized it yet in order to find
an alternate MGC. The MG didn't, of course, care if the MGC was down when
there was no activity, but, unlike placing an outgoing call, the activity of
a subscriber calling it from another MG will not cause the MG to find an
alternate MGC. I'm just saying that by polling the MGC or receiving a
keep-alive from the MGC, as someone just recommended, the MG would
substantially decrease the chance of a subscriber missing a call due to a
failed MGC.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rosen, Brian
Sent: Friday, May 18, 2001 12:05 PM
To: 'Paul Long'; [email-masked]
Subject: RE: Polls of MGC

Brian