Subject: RE: Polls of MGC

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

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 9:46 AM
> To: Rosen, Brian
> Cc: 'Christian Groves'; [email-masked]
> Subject: RE: Polls of MGC
> 
> 
> 
> 
> 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)
> 
> 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: Troy Cauble <[email-masked]>
Date: Fri, 18 May 2001 11:14:54 -0400

> 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