Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's las t Ca ll - MGC failure)

From: Dan Elbert <[email-masked]>
Date: Tue, 15 May 2001 09:49:13 -0500

This is only needed for UDP, in TCP you always know when the connection is
lost.
I don't think the MGC needs to poll, it can always detect the MG loss when
trying to do something. In any case if it detects that the MG is down there
is no much it can do. 
The MG in the other hand needs to know if it needs to reestablish the
connection to the MGC ( or try to connect a backup MGC).
I still think that SVC with method "noop" is the simplest solution , and
every MGC should support this either with a reply (if it implements the
method) or with an error (if it doesn't know it). The spec allows for the
use of "extension" SVC methods.
 
Dan Elbert
RADVISION
 
-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 10:28 AM
To: [email-masked]
Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's last
Ca ll - MGC failure)

If the Standard is going to specify a poll mechanism, let's do it right and
specify it for 
both MG and MGC. 
A package that only satisfies MG and might not be supported by everyone does
not sound 
like a very good specification. 
An audit of packages can give varying messages size from MG which can be a
performance 
issue to the MGC. 
SC is definitely the way to go where a small known fixed size simple
Request/Reply is 
all that is needed for polling purpose. 
Is this strictly a UDP issue or is the intend that TCP implementation would
need the polling 
too? 
Chuong 
"Rosen, Brian" wrote: 
This thread is about an MG poll of MGC, not the other way.  An MGC poll of
MG iseasy (audit of packages is an easy one).  Yes, both sides would have to
implementthe package for it to work.  That is why I like the original
ServiceChange idea. 
The package is just an "easy out" if we don't do something with SC. 
Brian 
-----Original Message----- 
From: Chuong Nguyen [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, May 15, 2001 9:24 AM 
To: [email-masked] 
Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's last
Ca ll - MGC failure)
Notify goes from MG to MGC. 
MGC does not send Notify. 
So how does MGC poll the MG? 
If we are making the assumption that by MGC requesting an event from MG, we 
are saying that MGC is sort of polling MG too. 
But what if MG does not support this package? 
Chuong 

"Rosen, Brian" wrote: 
It would be a real package (would need approval).  You would have 
to put it in the event descriptor, but I think that is right - 
you don't want the MGC getting events it didn't expect. 
Brian 
> -----Original Message----- 
> From: Madhu Babu Brahmanapally [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, May 15, 2001 9:13 AM 
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Kevin Boyle'; 'Dan Elbert' 
> Cc: [email-masked]; 'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
> Hi All, 
> If this event is defined in a new package, does the MGC needs 
> to send this 
> event in the event descriptor...or is this an exception of 
> the normal event 
> detection behavior? 
> Regards 
> Madhubabu 
> 
> -----Original Message----- 
> From: [email-masked] 
> [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of Rosen, Brian 
> Sent: Tuesday, May 15, 2001 7:57 AM 
> To: 'Tom-PT Taylor'; Kevin Boyle; Dan Elbert 
> Cc: [email-masked]; 'Chuong Nguyen' 
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's 
> last Ca ll - MGC failure) 
> 
> 
> If you don't want to create the noop method, we can go 
> back to a package. 
> 
> 
>    PackageID: nop (0x00xx) 
>    Version: 1 
>    Extends: None 
> 
>    Description: No op event.  Can be used for testing or MG 
> poll of MGC. 
> 
> Properties 
> 
>    None 
> 
> Events 
> 
>    noop 
>    ----- 
>    EventID:     noop (0x0001) 
> 
>    No op event 
> 
>    Events Descriptor Parameters: 
> 
>         Interval 
>         ------------- 
>         ParameterID: delay (0x0001) 
> 
>         Description: delay in milliseconds to generate event. 
>             if not specified, MG may choose any value. 0 implies 
>                immediate response. 
>         Possible Values: INTEGER 
> 
> Brian 
> 
> -----Original Message----- 
> From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, May 15, 2001 3:59 AM 
> To: Kevin Boyle; Dan Elbert 
> Cc: [email-masked]; 'Chuong Nguyen' 
> Subject: Polls of MGC (was RE: Implementors' Guide Update 
> Editor's last Ca 
> ll - MGC failure) 
> 
> 
> Let's follow through the logic here.  A restart implies loss 
> of state.  I 
> don't care whether you're talking ROOT or a real termination. 
>  It would be 
> inconsistent to declare restart of the latter a no-op. 
> I'd suggest the safest poll would be a NOTIFY with no events 
> and a bogus 
> requestID in it.  The MGC has to answer, even if only to 
> return an error, 
> but the NOTIFY doesn't change anything. 
> > -----Original Message----- 
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> > Sent: Monday, May 14, 2001 12:50 PM 
> > To: Dan Elbert 
> > Cc: [email-masked]; 'Chuong Nguyen' 
> > Subject: Re: Implementors' Guide Update Editor's last Call - 
> > MGC failure 
> > 
> > 
> > Yes.  Root is a special case.  Restart on Root, if it is already in 
> > service, implies that the MG has gone out of service and 
> returned, and 
> > that anything that was happening previously is lost.  This 
> > was discussed 
> > on an earlier thread. 
> > 
> > Kevin 
> > 
> > Dan Elbert wrote: 
> > 
> > > Well I was just following the logic that a restart of a 
> termination 
> > > already in service is a noop. Is the root termination a 
> > special case ? 
> > > . The problem with poll vs restart is the same in any case. 
> > > 
> > > -----Original Message----- 
> > > From: Chuong Nguyen [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > Sent: Monday, May 14, 2001 12:22 PM 
> > > To: [email-masked] 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > 
> > > To me definitely NOT. 
> > > How will MGC knows that it is a registration restarts vs a poll? 
> > > Don't tell me that one can use Reason Code since Reason 
> > Code has to be 
> > > IANA registered 
> > > before it can be widely used. 
> > > But since anyone can register w/IANA at any time, it only 
> means that 
> > > it might not be supported by 
> > > everyone. 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > 
> > > Another thing : Can I then use a restart of the "root" 
> > termination to 
> > > poll the MGC ? It seems to me more clean that to just use any 
> > > termination. 
> > > 
> > > -----Original Message----- 
> > > From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > Sent: Monday, May 14, 2001 12:00 PM 
> > > To: 'Dan Elbert'; [email-masked]'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > I think that a restart of a termination that is already in service 
> > > should be treated 
> > > 
> > > as a nop by an MGC. 
> > > 
> > > I have no objection to adding an explicit no-op method, 
> but I don't 
> > > think it is needed. 
> > > 
> > > Brian 
> > > -----Original Message----- 
> > > 
> > > From: Dan Elbert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > Sent: Friday, May 11, 2001 5:57 PM 
> > > To: [email-masked]'; 'Chuong Nguyen' 
> > > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > Using a fully specified terminationID can disrupt the 
> > operation of the 
> > > termination (for example if the termination is in a call). 
> > > 
> > > It's not clear what a "bogus" termination is, if the MGC 
> receives a 
> > > SVC from an MG termination it can assume that this 
> > termination is real 
> > > and start sending audits or commands. 
> > > 
> > > Yes, by poll I mean some type of heartbeat as the MG needs 
> > to know if 
> > > the MGC is alive. 
> > > 
> > > Brian Rosen suggested in the past to use SVC with Restart 
> method for 
> > > this purpose, I don't think that there was any mantion if 
> > this should 
> > > be done with id=root or other. 
> > > 
> > > Dan 
> > > -----Original Message----- 
> > > 
> > > From: Chuong Nguyen [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > Sent: Friday, May 11, 2001 5:38 PM 
> > > To: [email-masked] 
> > > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > > failure 
> > > 
> > > The intend was not to use ROOT but a fully specified 
> > terminationID or 
> > > even better a 
> > > known invalid terminationID (A bogus terminationID that the sender 
> > > knows is not valid and is 
> > > used specifically for heartbeat purpose).  The idea is to get some 
> > > kind of responses. 
> > > 
> > > "poll" do you mean heartbeat like msg to from MG to MGC 
> or something 
> > > else here. 
> > > 
> > > Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
> > > 
> > > Chuong 
> > > 
> > > Dan Elbert wrote: 
> > > Hi 
> > > 
> > > After reviewing the issue of MGC failure ( when the MG is 
> connected 
> > > trough UDP ) I believe that there is no satisfactory way 
> > for the MG to 
> > > poll the MGC to see if the MGC is still alive. Using a 
> ServiceChange 
> > > with "Restart" method and termination id of "root" may 
> cause the MGC 
> > > to assume that the MG restarted and can affect the state of 
> > a call in 
> > > progress. 
> > > 
> > > I think that it would be good to add a ServiceChange 
> method "noop" : 
> > > 
> > > Noop : Can be used by the MG (with unreliable protocols) 
> to obtain a 
> > > response from the MGC or detect a communication failure. When 
> > > receiving this SVC the MGC should take no action other that reply. 
> > > 
> > > If this is not acceptable, then I think that some clarification is 
> > > needed as when a SVC with restart method should be 
> considered "noop" 
> > > by the MGC. 
> > > 
> > > Dan Elbert 
> > > 
> > > RADVISION 
> > > 
> > > -- 
> > > 
> > >   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 **** 
> > > 
> > > -- 
> > > 
> > >   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 **** 
> > > 
> > 
> > 
>
-- 
  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 ****
 
-- 
  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 ****

---

From: "Paul Long" <[email-masked]>
Date: Tue, 15 May 2001 10:00:42 -0500

Dan,

If the MGC knew that an MG was down, it could free up resources related to
that association. That's about the only benefit I can see. However, that may
be reason enough to have an explicit MGC-to-MG polling mechanism.

Paul Long
ipDialog, Inc.
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dan Elbert
  Sent: Tuesday, May 15, 2001 9:49 AM
  To: 'Chuong Nguyen'; [email-masked]
  Subject: RE: Polls of MGC (was RE: Implementers' Guide Update Editor's
last Ca ll - MGC failure)

  I don’t think the MGC needs to poll, it can always detect the MG loss when
trying to do something. In any case if it detects that the MG is down there
is no much it can do.

  I still think that SVC with method “noop” is the simplest solution , and
every MGC should support this either with a reply (if it implements the
method) or with an error (if it doesn’t know it). The spec allows for the
use of “extension” SVC methods.

  Dan Elbert

  RADVISION

  -----Original Message-----
  From: Chuong Nguyen [mailto:[email-masked]]
  Sent: Tuesday, May 15, 2001 10:28 AM
  To: [email-masked]
  Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's

  If the Standard is going to specify a poll mechanism, let's do it right
and specify it for
  both MG and MGC.

  A package that only satisfies MG and might not be supported by everyone
does not sound
  like a very good specification.

  Is this strictly a UDP issue or is the intend that TCP implementation
would need the polling
  too?

  Chuong

  "Rosen, Brian" wrote:

  Brian

  -----Original Message-----
  From: Chuong Nguyen [mailto:[email-masked]]
  Sent: Tuesday, May 15, 2001 9:24 AM
  To: [email-masked]
  Subject: Re: Polls of MGC (was RE: Implementers' Guide Update Editor's

  So how does MGC poll the MG?
  If we are making the assumption that by MGC requesting an event from MG,
we
  are saying that MGC is sort of polling MG too.

  Chuong

  "Rosen, Brian" wrote:

  Brian

  > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
  > [mailto:[email-masked]]On Behalf Of Rosen, Brian
  > From: Tom-PT Taylor [mailto:[email-masked]]
  > > > From: Rosen, Brian [mailto:[email-masked]]
  > > > From: Dan Elbert [mailto:[email-masked]]

---

From: Christian Groves <[email-masked]>
Date: Fri, 18 May 2001 18:17:48 +1000

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: Ian Leighton <[email-masked]>
Date: Fri, 18 May 2001 08:47:59 -0400

It was my understanding that the poll was required so that
the MG can determine whether or not to initiated MGC Failure
proceedures described in Section 11.5.

Regards
Ian

---

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

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

> find something is wrong when it tries to signal the MGC.

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.