Subject: [Megaco] Re: Polls of MGC

From: Dan Elbert <[email-masked]>
Date: Wed, 1 Aug 2001 10:59:47 -0500

Hi

I think that solution (3) is the cleanest one. In this case "polling" is
reduced to a minimum, i.e. as long as the MGC is sending the MG messages the
polling is not used.
And the MGC controls the frequency.
But the implementation of the polling seems weird, the MG will send a Notify
of an event which was not requested by the MGC which is not standard. Also,
what termination is going to send the notify ?
That's why I proposed to add some "noop" method to SVC , I thought this was
covered in the protocol under "Another value whose meaning is mutually
understood between the MG and the MGC".
From the point of view of implementation is easier to said : set a timer for
period T and when it expires check if any messages have been received from
the MGC. This is more efficient that resetting the timer every time. So the
"failure time" will be well less defined (i.e. for a given T it make take
almost 2T to detect the failure if the last message was received at the
beginning of the first period) but I think is good enough for our needs.

Dan Elbert
RADVISION

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 3:41 PM
To: [email-masked]
Subject: [Megaco] Re: Polls of MGC

I'm sorry to bring this up again (the thread has over 100 messages to date),
but I do not believe we ever resolved this.  It died down May 24 at least
partly because several of the participants began traveling to Porto Seguro,
as
well as lack of any consensus.  Two more recent queries about the status
failed
to generate much response or claim of consensus, so I will try to summarize
where I think we are.  There are a number of positions:

1) change nothing.  MGC can poll MG using null Audit and MG can poll MGC
using
a ServiceChange Restart on an inservice termination
Pro: Needs no change in protocol.  Neither entity needs any special
capability
from the other or even need tell the other that the purpose is "polling".
Con: If both want to detect failure, we get two sets of message/replies when
one would do if they had an agreement.  MGC cannot prevent MG from polling
or
control frequency.  There may be no terminations in service (but one could
then
confirm the out-of-service state by sending ServiceChange Forced on a
termination).  Sending ServiceChange on a termination requires knowing what
Context it is in which may be inconvenient for a link manager routine.

2) change nothing.  MGCs can poll MG using null Audit and MGs should NOT
poll.
Pro: Needs no change in protocol. MGC controls polling activity (if polls
occur
and frequency).  Avoids two sets of polls. (one arguement was MGC should be
fault tolerant and never fail, but then why do we have alternate MGCs?  Only
for planned handoff?)
Con: MG must establish new assoc with alt MGC but may not be aware of fault
in
some cases (calls initiate at MGC, e.g, SS7, and MG cannot tell difference
between low traffic and failed MGC and so alt MGC cannot initiate calls on
the
MGs lines).  MG doesn't know the frequency of polling (or if polling is
occurring) and so does not know duration of silence that should constitute
failure.

3) add polling package.  MGC can poll MG using null Audit but inform MG
about
polling and frequency using polling package property.
Pro: MGC controls if polling occurs and frequency, avoids two sets of polls.
No change in protocol but a new package.  MG can detect failure from silence
longer than property setting.  Note that package can define polling to occur
only during lack of other messages, MG detects failure from complete message
silence not just lack of polling.  MGC can detect failure even if MG does
not
implement package.
Con: if MGC does not choose to use package MG cannot detect failure (maybe
ok,
MGC should decide reliability policy).

4) same as #3 but a new more distinctive message rather than null audit.
Con: Little advantage over #3 and changes protocol.

5) Timer Event Package on ROOT.  Not exactly polling, but equivalent.  MGC
adds
a "timer" event to event list of ROOT with a specified duration property.
This
causes MG to Notify when timer expires.  MGC detects failure if Notify fails
to
arrive on time.  MG detects failure if Notify receives no reply.
Pro: no change in protocol, but new package.  Such a timer package might
have
some other uses??  MGC controlls frequency of "polling". MG's failure
detection
is nothing special since it normally detects failure on timeout for response
-
it need not know that the timer is for this purpose.  Timer package is
little
different from polling package in #3 - both set a timer based on a package
property.  If timer were special for failure detect it could implicitly
reset
on any message and so Notify only during silence from other messages.  Both
MGC
detects failure from silence longer than timeout rather lack of Notify
longer
than timeout. Note that message traffic is same, if timer event is assumed
to
reset after notify.
method #3: Audit/response - Audit/response - ...
method  #5 Event/response - Notify/response - Notify/response - ...
that is only one pair extra at beginning of association.
Con: requires MG to implement package for failure detect in either
direction.
Might cancel signals if we support ROOT signals.

6) add  Method to ServiceChange.  MGC polls using null Audit.  MG polls
using
ServiceChange on ROOT using new "no-op" method or "poll" method.
Pro: similar to #1 but avoids problems with using a non-ROOT termination.
Con: changes the protocol (rather than adding a package).

So where are we?
I think #2, #3 and #5 or minor variations on these had the most support, but
I
saw no consensus.  Both #3 and #5 require new packages.  I will volunteer to
draft a package for the next Rapporteur's meeting if we have any consensus
between #3 vs #5 or do I need to write both to be looked at in more detail?

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

_______________________________________________
Megaco mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/megaco

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Wed, 1 Aug 2001 13:48:48 -0400

HI All,
The method #3 seems better. As it adds only another package implementation
at the both MG and MGC. The procedure in the package will define how this
property (say pollFreq)needs to be used for generation of the "poll" event.
For this event to be reported, the MGC (as it is implementing the package)
has to include the poll event. IMO the Termination Identifier used in the
message can be a DONTCARE but shouldn't be wildcard. ( I have no good reason
to say why it can't be ROOT).

Regards
Madhubabu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dan Elbert
Sent: Wednesday, August 01, 2001 12:00 PM
To: [email-masked]'
Subject: [Megaco] Re: Polls of MGC

Hi

Dan Elbert
RADVISION

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 3:41 PM
To: [email-masked]
Subject: [Megaco] Re: Polls of MGC

So where are we?