Subject: RE: Polls of MGC

From: Dan Elbert <[email-masked]>
Date: Fri, 18 May 2001 08:41:11 -0500

Using SVC, the MGC could control the poll frequency by setting the value of
a property of the root termination (I assume the the poll is done with the
root termination id ).

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, May 18, 2001 8:53 AM
To: 'Christian Groves'; [email-masked]
Subject: RE: Polls of MGC

Christian

Everyone agrees that the way the MGC finds out if an MG is down is
to send a message and look for a response.  There are quite
a few messages an MGC could use.  I've suggested an audit.

Everyone also agrees that the way the MG finds out if the MGC is down
is to send a message and get a response.  It would presumably have
some timer that is reset by any message from the MGC.  If the timer
expired, it would send a message (a poll), and look for a reply.

There are two issues:
1. What message do you send?  MGs only send two messages, ServiceChange
and Notify.  The first series of messages on this thread talked about
using SC as the message.  The issue is how to construct an SC
which does not change the MGCs notion of the MG state (ie behave
as a no-op).  The second set of messages talked about using Notify
as the poll

2. How fast do you poll? The MGC really ought to be able to control
the frequency of polls, which would depend on how many MGs it was
controlling.  For this reason, we have been talking about using Notify,
with an interval parameter, which would be set by the MGC to control
the polling.  Using SC, even if you could, there is no way for the
MGC to control the polling rate.

If the MGC is down, the MG can do the right thing, which is to contact
an alternate MGC for service. 

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 4:18 AM
> To: [email-masked]
> Subject: Re: Polls of MGC
>
>
> G'Day,
>
> I'd really like to understand the network scenario for adding this
> polling.
> As I see it the MGC can determine that an MG is down. ie. It issues a
> command and gets no response. It can take the appropriate action.
> Likewise the MG can determine when the MGC is down in the same way.
> Except that if the MGC its connected to is down the MG can't do much.
> Remember the MGC is the Master and the MG is the slave.
>
> I really don't see the benefit of the MG doing periodic
> polling. It will
> find something is wrong when it tries to signal the MGC.
>
> Without going to Servicechange methods, reasons etc. What's
> the benefit?
>
> Cheers, Christian
>
>

---

From: Wenxin Ma <[email-masked]>
Date: Fri, 18 May 2001 09:54:34 -0400

Hi,

Is the pulling of MGC similar to "keep alive" between Gateway and Gatekeeper
in H.323?

Regards,

Wenxin

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Friday, May 18, 2001 9:49 AM
To: 'Rosen, Brian'; 'Christian Groves'; [email-masked]
Subject: RE: Polls of MGC

Hi Brian/list,
Even today without the Polling mechanism the MG can follow the MGC failure
procedures defined in Section 11.5. So, what is the additional gain by
sending another message to the MGC and then initiating the failure
procedures.

When this polling needs to be done??
1) When there is no activity between MG and MGC OR
2) When any command generated from MG is not acknowledged by the MGC with
any response?

Regards
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rosen, Brian
Sent: Friday, May 18, 2001 8:53 AM
To: 'Christian Groves'; [email-masked]
Subject: RE: Polls of MGC

Christian

There are two issues:

Brian

---

From: Dave Sclarsky <[email-masked]>
Date: Fri, 18 May 2001 10:45:59 -0400

Madhubabu,

Sorry, I failed to answer your original question - polling only needs to be
done when there is no activity between MG and MGC.

The problem with HANDOFF is that it assumes that the MGC is alive enough
(and its NIC is still working, its NIC cable didn't come unplugged or get
cut, etc.) to send it!  In any case, the protocol must provide some
mechanism to allow the MG to switch to the new MGC ASAP.  If there is no
other Megaco activity, polling is the only option (at least for UDP and TCP,
but not for SCTP)!

DaveS.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Friday, May 18, 2001 10:28 AM
To: 'Dave Sclarsky'
Subject: RE: Polls of MGC

HI Dave,
I agree that both the MGC and the MG needs to be sync whether a Standby MGC
takeover a MGC OR a redundant MG takes over the actual MG. As you suggested
in case of MGC going down, it has to generate a HANDOFF service change
command towards the MG indicating the MG to establish a new control
association with the newly specified address in the "MgcIdToTry" field. All
these cases are already taken care by the protocol (cases like MG taken over
by Redundant MG or MGC taken over by a standby MGC).

The Polls of MGC is something the MG needs to initiate. The trigger for this
is lack of response from the MGC for a specific Notify command. If the MGC
is really down then the next Notify with the poll event will also not be
acknowledged by the MGC. So, I think there is no concrete gain by defining a
new event and adding addition processing logic(which IMO is overhead). If
the MGC is not down and the response of the first Notify is lost because of
the Network congestion...then the same can happen with the Notify with the
"poll" event. Then it merely ends like probability of message lost over a
unreliable network. At least iam not able to convince myself why this
polling mechanism is advantageous for the MG/MGC.(or enabling the MG to
circumvent the MGC failure).

Regards
Madhubabu

-----Original Message-----
From: Dave Sclarsky [mailto:[email-masked]]
Sent: Friday, May 18, 2001 10:07 AM
To: 'Madhu Babu Brahmanapally'
Subject: RE: Polls of MGC

Madhubabu,
If an MGC goes down and its standby takes over, the MGs don't notice until
they have a notify to send.  This could be a long time (middle of the night
on a ResGW).  In the meantime, what happens if the new MGC needs to make a
call to a quiescent MG?  The MGC cannot initiate a control association, so
the physical terminations are effectively lost from the network until one of
them generates an event!
DaveS.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Friday, May 18, 2001 9:49 AM
To: 'Rosen, Brian'; 'Christian Groves'; [email-masked]
Subject: RE: Polls of MGC

Hi Brian/list,

Regards
Madhubabu

-----Original Message-----

Christian

There are two issues:

Brian

---

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

The problem exists when there is no normal message flow between the
MG and the MGC.  This could be common (all idle lines).  If there is
messaging, then you don't need the poll.

The 11.5 mechanisms would be used when you determine the MGC is
not available. This discussion is how you determine that.  You would
also initiate the failure procedures if you did not get a response
from the MGC (after all the repetitions failed, of course). 

Brian

---

From: Dan Elbert <[email-masked]>
Date: Fri, 18 May 2001 10:12:28 -0500

In the protocol it says that the ServiceChange method can also be "Another
value whose meaning is mutually understood between the MG and the MGC" so I
think that specifying a "noop" value in the Implementor's guide is covered
under this. 
The problem with the package is that it has to be implemented by both sides
to work, and making the package "mandatory" also implies a modification of
the spec.
The SVC will work even if only the MG implements it, because the MGC should
reply to this even if the method is unknown to him.

Dan

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, May 18, 2001 10:52 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: Polls of MGC

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.
The poll CREATES a message for the purpose of seeing if it
can get a response.  If, during the processing of the poll,
it gets no response, then it initiates failover procedures
as documented. "No Response" to the poll is exactly the same
as no response to a normal message.

It is possible to use SC if you add a no-op method.  It is
possible to control frequency at the MGC by having a settable
parameter on root.  That is, to me, an acceptable answer,
but adding the no-op actually changes the protocol. 
The advantage of the package with the event is that it's a normal
package, and can be standardized without modifying RFC3015
and Recommendation H.248.  Trying to do this with an "Implementor's
Guide" seems to me to be stretching the definition of "Guide"
pretty far.  Alternatively, this can be deferred to a future
revision.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 9:46 AM
> To: Rosen, Brian
> Cc: 'Christian Groves'; [email-masked]
> Hi Brian
> I think what Christian is pointing out is that do we really
> need polling......
> The question is that in case of unreliable transport protocol
> like UDP whether
> the MGC ( or MG) should be allowed to wait for timeout of "a
> reply to a valid
> request message" (like ADD, MODIFY etc. from MGC and NOTIFY,
> SVC from MG) to
> detect failure of the other end. Or else, there should be a
> mechanism in built
> in the MEGACO protocol to detect a MG or MGC failure....seems
> a better option
> though it has an added overhead of polling.
>
> Now, if we decide to introduce polling......the next issue is
> how to add
> one.....
> There are two proposals....
> 1.   Through a notify...event "noop" with a delay parameter
> which controls the
> frequency of polling.
>      But, this I think has a dependency that this poll can
> only be initiated by
> MGC thru' activation of an event descriptor.
> 2.   Alternatively, we can use Service Change with "noop"
> method and add a
> property to Base Root package "normalMGCIdleTime....or
> normalMGCPollTime". This
> is the polling timeout duration provisioned at MG and
> settable by MGC at
> runtime.
> If MGC sets the value of this timer at runtime, MG should
> restart the polling
> timer. Additionally, we can put a guideline that in case the
> MG or MGC receives
> either a valid request or a valid reply from the other end
> within a polling
> interval, the SVC "noop" need not be sent at the expiry of
> that polling
> interval. Since service change can be sent by both MG and MGC
> this gives a
> suitable solution for polling.
>
> The concern about controlling the polling thru' MGC is
> addressed suitable by
> both the alternatives.
>
> Thanks,
> -Kapil Nayar
> Hughes Software Systems
>
>
>
>
>
> "Rosen, Brian" <[email-masked]> on 05/18/2001 06:22:46 PM
>
> To:   "'Christian Groves'" <[email-masked]>,
> [email-masked]
> cc:    (bcc: Kapil Nayar/HSS)
>

---

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

If you add a method in the Implementor's Guide, that's a change to
the spec.  If you do it in something like a profile, it wouldn't be.

You need a parameter so the MGC can control rates.  That would have
to be in a package, and both sides would have to implement it.

Brian

> From: Dan Elbert [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 11:12 AM
> To: [email-masked]

---

From: Dave Sclarsky <[email-masked]>
Date: Fri, 18 May 2001 11:45:59 -0400

Brian,
I agree that adding a package is a simpler process than changing the specs.
But I still have one nagging problem with making this an event on ROOT -
does it prevent any future package from defining signals on ROOT?  Maybe the
interaction of events and signals is reason enough to avoid defining either
of them in packages for use on ROOT.
Do you see this as a potential problem?
DaveS.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, May 18, 2001 10:52 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: Polls of MGC

Brian

---

From: [email-masked]
Date: Fri, 18 May 2001 21:19:08 +0530

Hi Troy

You have a very valid point......but what if the MGC goes down and doesnot come
up at all....the MGs (5000 of them) shall wait for
1. an event initiated by a subscriber action
2. a notify request sent to the MGC.
3. notify response timeout for configured "max number of retries" times
4. generate a new service change and get a valid response from another MGC
before they can service their respective subscriber's request..

Thanks,
-Kapil Nayar
Hughes Software Systems

Troy Cauble <[email-masked]> on 05/18/2001 08:40:54 PM

Please respond to Troy Cauble <[email-masked]>

To:   Christian Groves <[email-masked]>
cc:   [email-masked] (bcc: Kapil Nayar/HSS)

> Remember the MGC is the Master and the MG is the slave.

MGCP/NCS has a failover scheme involving multiple DNS entries.  Basically
if the MG can't reach the MGC after X tries, it checks the DNS entry for
another IP address and tries it.  (Actually it's fairly complicated with
attempt counts and timers, etc., but that's the idea.)

Any failover method needs to consider security.  It's not very good
if the MG accepts messages that say "I'm your MGC now" from anyone.

> I really don't see the benefit of the MG doing periodic polling. It will

I don't see the benefit either.  It'll find out when it tries to
communicate something. Before then, it didn't need to know.
The MGC might come back online before the MG needs it.

Picture 5000 MGs polling an MGC.  That's a lot of traffic.
If the MGC is down for 5 minutes, 5000 MGs detect it and
switch over *somehow* to the backup MGC, then need to be
switched back to the original.  That's a lot of traffic too.
If you let the MGs handle the problem as needed, maybe only
a handful would have needed to.

> Without going to Servicechange methods, reasons etc. What's the benefit?
>
> Cheers, Christian

---

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

I suppose.  I haven't yet come up with a reason for signal on
root, although if the folks that want signals to create external
signalling (the example is ATM SVC creation triggered by a signal
on a termination) get the definition of a signal extended that way, that
opens u a whole new set of things you may define signals for, and
since signals are defined in packages, that could end up causing
interaction problems with the poll event.

Given the level of discussion, maybe we should punt for now.
A profile could define a new method for ServiceChange, and a package
on root for the interval.  So, any systems that weren't happy with the
"wait until you need it to worry about a failed MGC" idea have a
way.  We might want to get some more real experience with things like
failure recovery time before we really standardize a method.

I've also offered another idea - define a restart of an already
up termination to be a no-op.  That IS something the Implementors
Guide can do - the behavior is not specified, you can reasonably
interpret a restart of an up termination as a no-op, and we could
make it so in the I-G.  We would need the package for the interval,
but that is easy.

Brian

> Sent: Friday, May 18, 2001 11:46 AM
> To: 'Rosen, Brian'; [email-masked]'
> Cc: [email-masked]

---

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

Woops, there is no such thing as "Graceful Restart".  Just a
Restart with a time of -1 could do it.

Brian

> Sent: Friday, May 18, 2001 1:29 PM
> To: 'Dave Sclarsky'; 'Troy Cauble'
> Cc: [email-masked]'; [email-masked]
> Right.  I just replied to another version of this and forgot the
> point that Johnnies MGC will figure out that Dad's MGC is down,
> and that can be fixed, but Dad's MG won't register with the
> replacement MGC because it doesn't know (yet) to do so. 
> 
> See that message for options.  The package will work, I think,
> pretty well (modulo the worry about signals).  So will the
> profile defined no-op SC method, and declaring restart of an 
> up termination to be a no-op.  It occurs to me that we could
> make this more palateable by saying a gracefull restart of an
> up termination with a time of -1 was defined to be a no-op.
> 
> Brian
> 
> > Sent: Friday, May 18, 2001 1:18 PM
> > To: 'Rosen, Brian'; 'Troy Cauble'
> > Cc: [email-masked]'; [email-masked]
> > 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.
> > 
> > Sent: Friday, May 18, 2001 11:22 AM
> > To: 'Troy Cauble'
> > Cc: [email-masked]'; [email-masked]
> > 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
> > 
> > > From: Troy Cauble [mailto:[email-masked]]
> > > Sent: Friday, May 18, 2001 11:15 AM
> > > To: Rosen, Brian
> > > Cc: [email-masked]'; [email-masked]
> > > "Rosen, Brian" wrote:
> > > 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: "Kaul, Bharat" <[email-masked]>
Date: Fri, 18 May 2001 10:56:59 -0700

Dan, 

 Paul has suggested changes to this passage....esentially UDP will be
replaced with Connection Less transport protocol and MID is just a logical
identifier i.e. it does not convey any transport address information. The
mention of MID in the passage is a typo.

For connection less transport, the intention is that MG can ask MGC to
communicate at some other port through ServiceChangeAddress. 

If ServiceChangeAddress is missing, then it is source transport address used
by MG to send the command. Essentially this is where it differs from MGCP
world.

- Bharat

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Friday, May 18, 2001 9:22 AM
To: [email-masked]'
Subject: RE: Polls of MGC

Well, in the implementers guide is specified  ( in 7.2.8 ) :

For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor.. If the
transport ServiceChangeAddress parameter is not present, then the MGC shall
use the source transport address (mId) used by the MG for sending commands
in subsequent communication with the MG.

Using a configured port may limit flexibility, but maybe is a better
solution.

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Friday, May 18, 2001 12:02 PM
To: Dan Elbert
Cc: [email-masked]
Subject: Re: Polls of MGC

Then that's the problem:)
Have the MGs use a default or configured port also.
Seriously, why not?

Polling is BAD.

-troy

(BTW, I wasn't really proposing that we use the MGCP/NCS
 DNS based mechanism.  I was just responding to Christian's
 comment that the "MG can't do much" when it detects failure.
 A quick peek at section 9 shows me the H.248 mechanism:
 "The MGC is provisioned with a name or address of a primary and
 zero or more secondary MGCs".)

Dan Elbert wrote:
>
> The difference with MGCP is that in MGCP when the MGC comes up it know how
> to contact the MGs ( they listen in a default or configured port) , but in
> Megaco the MGC only knows the MG port after the MG connects to it. If the
> MGC goes down normally this information can be saved, but if it fails and
> this information is lost, in some situations there is no way for the MG
and
> MGC to connect to each other again.
>
> Dan
>
> Sent: Friday, May 18, 2001 11:11 AM
> To: Christian Groves
> Cc: [email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 20 May 2001 10:16:22 -0400

If PSTN standards are used, failure of MGCs will be a rare event, and a
failure of any significant extent in the US will have to be reported to the
FCC.  Let's be realistic here.  I like Kevin's proposal of MGC-initiated
polling -- it keeps control of the process where it belongs.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 20 May 2001 10:20:13 -0400

If you're determined on this, you can prevent interaction problems by
defining an abstract termination other than ROOT whose job it is to report
the poll event.  I really don't buy the neutering of the RESTART method.

---

From: Dave Sclarsky <[email-masked]>
Date: Mon, 21 May 2001 10:17:09 -0400

Tom,
No matter how rare, the protocol must handle recovery from MGC failures.
I don't see a big difference between MGC initiated vs MG initiated polling.
Both cases require a writeable timeout value on the MG, which the MGC
can use to control the polling frequency. 
DaveS.

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Sunday, May 20, 2001 10:16 AM
To: 'Dave Sclarsky'; 'Rosen, Brian'; 'Troy Cauble'
Cc: [email-masked]'; [email-masked]
Subject: RE: Polls of MGC

> From: Dave Sclarsky [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Knight, Ty" <[email-masked]>
Date: Wed, 23 May 2001 12:20:35 -0400

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.

> Sent: Wednesday, May 23, 2001 11:22 AM
> To: 'Dan Elbert'; 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> 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
>
> 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]
> 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
>
> Sent: Wednesday, May 23, 2001 10:37 AM
> To: 'Dave Sclarsky'; 'Christian Groves'; 'Troy Cauble'
> Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> 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
>
> [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]
> 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.
>
> > Sent: Wednesday, May 23, 2001 9:48 AM
> > To: Troy Cauble
> > Cc: Dave Sclarsky; 'Rosen, Brian'; [email-masked]';
> > [email-masked]
> > 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: "Kaul, Bharat" <[email-masked]>
Date: Thu, 24 May 2001 10:49:26 -0700

>For TCP, liveness (or poll) is part of the protocol.  So if connectivity
>is lost, the TCP client will detect it, and the MG can then try to
>reestablish the connection with the same MGC or an alternate MGC.

Currently what is a MG supposed to do if it loses a TCP connection ? Does it
attempt to re-establish the connection to same MGC a finite number of times
and send ServiceChange with "disconnected" (??) or does it switch over to
the next configured MGC ?

Protocol doesn't seem to say anything and I wonder why. It should say
something about this issue.

- Bharat

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 24 May 2001 13:55:34 -0400

Since networks vary a lot, the number of times you should retry can
vary a lot, and that is why we don't specify how many times to try,
or how long to wait.

Some networks will not want MGs to wait; if connectivity is lost,
they will want MGs to switch to a new MGC right away.  Others will have
the MG retry for some number of times, supplying Disconnect if after
a few tries, the MGC eventually responds.

Brian

> From: Kaul, Bharat [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 1:49 PM
> To: 'Laurent Nicolas'; Dan Elbert