Subject: RE: [Megaco] MGC-MG dialogue failure detection

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 17 Jul 2002 09:41:57 -0400

Resend, because the message was too big for the list:

I still don't see how autonomous secondary takeover doesn't violate the
principle that MGs establish control associations, and not the other way
around.  That, alone, is a significant strike against this idea, let alone
the fact that, as Terry has pointed out, there doesn't seem to be any outage
reduction.

Kevin

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 2:37 PM
To: Aleksandr Ryabin
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; Boyle, Kevin
[NCRTP:3R90:EXCH]; Carl Rutter
Subject: Re: [Megaco] MGC-MG dialogue failure detection

I am assuming that primary and secondary probe each other for liveness 
over the network (presumably more often than MG probes), and there is 
the case where MG can reach both MGCprim and MGCsec but due to some 
router failure MGCsec cannot reach MGCprim and so concludes that it is 
dead.  I believe that this case is possible but I suppose that it is not 
real common since a path between MGCprim and MGCsec must exist through 
MG's local router except when the paths are over half the max hop count 
limit (and if the hop count is that hight the network may be too poor of 
quality to be acceptible for VoIP anyway).

In this case, however, each MGC believes the other is dead and will yank 
the MG back and forth unless, as you suggest, they detect this rapid 
alternation state and take some other corrective action.  Of course each 
may be very busy auditing its "new MG" to determine the state of all its 
calls.

I just wonder how the MGCs monitor each other reliably significantly 
faster than the MGs can monitor.  Are you just counting on the number of 
monitors being much smaller (list of secondaries rather than all MGs) so 
that the polling frequency can be higher or are you primarily interested 
in the case where MGC are colocated and polling over LAN or even 
backplane connections?

Aleksandr Ryabin wrote:

> As previously was noted on this thread there is a possibility of 
> "unexpected"
> (for primary MGC) handoff from secondary MGC. In this case primary MGC
> will loose control (that is MG will reject messages with error 505).
>
> Ideally this would not happen since if the mechanism is used (e.g primary
> MGC explicitly sets acceptSecondaryHandoff to yes) then MGCs better
> have these "some means" to detect each other run status, otherwise
> secondary MGC would not know when to initiate handoff in the first place.
> But even if in this case "incidental" handoff is initiated by 
> secondary MGC,
> primary MGC can regain control on the very next send since its very next
> message to MG will fail with error 505, thus primary now has turned into
> secondary and thus it can initiate handoff to regain control (if 
> necessary).
> One can say this can then potentially turn into a race. The answer is in
> word "incidental": that is normally MGCs will correctly identify each 
> other
> run status and if "incidental" handoff detected MGCs will take steps
> to report it via some management mechanism and correct as needed.
> All this can be documented in "procedures" of the package.
>
>         Aleks

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2002 13:40:17 +1000

G'Day,

I support Kevin's view on this. It seems that we've revisited the arguements
several times on this thread. We've also visited this issue several times
previously on the mailing list and at face to face meetings. The players change
but the facts and argument still are the same. Each time we've decided to stay
with what we have. As Tom points out if one company wants to produce a
proprietory package to do this functionality then it can by registering a
private package. I just don't think its anything worth endorsing on the Megaco
list.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2002 13:40:17 +1000

G'Day,

Regards, Christian