Subject: RE: Polls of MGC

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

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: Ian Leighton <[email-masked]>
Date: Fri, 18 May 2001 10:48:27 -0400

Unless I'am missing something, polling is a requirement for
Trunking MG's which are registered and the MGC fails. The
Trunking MG  application does not require Notify messaging and
ServiceChange messages are sent infrequently (eg. on facility
failures). Without polling how would the Trunking MG
initiate re-registration proceedures with its list of alternate
(and primary) MGC's.

Regards
Ian