Subject: RE: [Megaco] Questions - Primary MGC failure

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

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chirayu Patel
Sent: Monday, March 28, 2005 8:30 AM
To: [email-masked]
Subject: [Megaco] Questions - Primary MGC failure

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?
[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.

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?
[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.

thanks,
CP

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

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

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 29 Mar 2005 14:26:36 +0530

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] 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.

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.

What are your thoughts?

regards, CP