Subject: [Megaco] Questions - Primary MGC failure

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 28 Mar 2005 18:59:43 +0530

Hi folks,

Few questions on the MG/MGC behavior when the primary MGC fails.

Scenario
--------

1. MG is an access gateway interfacing with POTS
2. MG is configured with a primary and a secondary MGC.
3. MG does not get a reply from the primary MGC for a certain
   transaction..for example a Notify with an onhook event.
4. MG assumes that the primary MGC has failed and sends SVC with method
   "failover" to secondary MGC.

Questions
---------

1. What should MG do about existing contexts? Should it delete them or
   will the secondary MGC send a Subtract if it does not have the state?
2. How does the secondary MGC learn of the lost Notify (point 3 above)?
   Should the MG resend all failed Notifies to the secondary MGC?

thanks, 
CP

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 30 Mar 2005 09:34:52 -0500

Comments inline [KJBII]

Kevin 

-----Original Message-----
From: Chirayu Patel [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2005 3:57 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Subject: RE: [Megaco] Questions - Primary MGC failure

See below.

regards,
CP

On Tue, 29 Mar 2005 03:13:57 -0500, "Kevin Boyle"
<[email-masked]> said:

> 1. MG is an access gateway interfacing with POTS 2. MG is configured 
> with a primary and a secondary MGC.
> 4. MG assumes that the primary MGC has failed and sends SVC with
>    method "failover" to secondary MGC.
>
> Questions
> ---------
>
> [KJBII] The MG is not permitted to take autonomous action.  The only 
> way for the MG to clear its state is to undergo a Cold Boot.

I could not find text to this effect in the draft. While this behavior is
well understood, I think it would be beneficial if the draft made a note of
it. Also, suggestions on the behavior of a secondary MGC that does not share
state with the primary will be useful. I believe the secondary should give a
wildcarded subtract to delete all contexts incase it does not share state
with the primary.
[KJBII] This would very much depend upon the application of the MGCs/MG.  It
isn't really the place of the spec to proscribe behavior -- only the means
to accomplish particular behavior.  Your suggestion makes sense for the
application you describe, I just don't think it should be required from the
spec for all possible applications.

> [KJBII] There are many ways for the MGC to determine that a Notify was 
> lost. It seems that in the instance you talk about, however, that the 
> user is likely to go back onhook and reoriginate, given that call 
> processing will not proceed.  In this instance, the offhook will get 
> reported anew.

The instance I am talking of is when a user goes on-hook during a call.
My concern is that if MGC does not receive this event it will not release
the call and bill the user excessively.

In this case, what other methods can the MGC employ to determine loss of a
Notify? It seems that the only reliable way is for the MG to retransmit the
Notify.

[KJBII] If the secondary has no state synchronization with the primary, how
can billing be reliable over a failure of the primary?  It seems to me that
billing would have to be terminated at the failure of the primary in this
instance, because the secondary would not have enough knowledge of the call
in session, features activated, etc., to be able to bill accurately.

[KJBII] As for retransmitting the Notify, it seems to me that a
well-designed MGC will reprogram its terminations upon a failover.  This
way, it will find out what hookstate the terminations are in.  If the MGC
reapplies onhook in the Events descriptor (with the strict parameter set
appropriately), then the MG will let the MGC know the current state by
reporting the state again.

It seems that to sync with the MG, the MGC has to rely on Notify retries
from the MG (or other mehthods to detect loss of Notify's).
IMHO, MG and MGC implementations can be simplified if the AuditValue command
incorporates a "pastObservedEvents" descriptor. With the
"pastObservedEvents" MGC will be able to inquire the *complete* state of the
MG using AuditValue.

[KJBII] AuditValue specifically returns the current value of a descriptor.
How, exactly, would "pastOE" work?  How long in the past is "past"? What if
EventBuffer is involved?  I am not sure how this kind of thing would fit in
the protocol without making drastic changes.

What are your thoughts?

regards, CP