Subject: [Megaco] VDY:>> MGC Failure

From: "vidya g" <[email-masked]>
Date: 19 Feb 2002 15:57:04 -0000

hi 
   I have some doubts regading failure of MGC.

oOo  case one:
    Primary MGC failed when MG is in active state ( running state ) then MG detects peer failure and 
try to connect to secondary MGC. But in this case new MGC doesn't know about the call contexts and all
activities happened in MG. In such a case what MG do..? should he cancel all active calls and start from 
scratch or just maintain all the calls and whenever MGC request for audit give the details .. ?

oOo  case two:
     Primary MGC wants MG to connect to a new MGC. In this case we can maintain all calls provided PrimMGC
passes all information related to the MG activities to new MGC and then relinquishes the control ... 
( in that case what would be the protocol between primary MGC and directed MGC .. ? )
If this case works, what do we do with unresponded requests from MG .. do we need to expect the response
for them from new MGC or we need to drop all unresponded requests and send it again .. ?

oOo  case three :

     Primary MGC goes down and secondary also is not reachable, and according to RFC we need to try all
possible listed MGC in a loop and the if we are able to connect to primary again, start conversation .. in 
this case what do we so with the unresponded requests from the MGC before it goes down .. ? 

   What I feel is RFC doesn't talk about the state of the calls and other requests if MGC goes down and 
connect to new MGC ...

oOo
   One more doubt is if a service change message is coming for ROOT termination, can that message contain 
more some other transactions also .. ? or for the transaction which contains service change command for
ROOT termination contain more than one action .. ?

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

---

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 20 Feb 2002 14:02:14 -0800

Chak/Vidya

The transaction level equalization is not defined in the protocol and is
proprietary. I would think that for case 1, MG has no choice but to clear
contexts.

For case 2, it is handoff case. MG doesn't need to clear contexts but can
keep sending commands to New MGC. Also, responses to commands received from
previous MGC need to be sent to new MGC (as per discussions on the mailing
list, although it violates "thumb rule that responses go to the source
transport address".

Case 3 MG will have to clear up contexts

- Bharat

-----Original Message-----
From: P.S.K. Chakravarthi [mailto:[email-masked]]

> scratch or just maintain all the calls and whenever MGC request for audit
give the details .. ?
Chak:
In this case MG should not cancel any context. 
MG should even send the pending responses to the New MGC. 
New MGC will accept the pending responses if
transaction level equalization is done between primary and secondary.  If
there is no transaction level equalization, then new MGC rejects the
responses (I mean MGC stack will not pass those responses to MGC
apllication) So MGC application after long timer will send SUBTRACT to
clear the contexts.
So in this there should be any problem for those calls which are not
having any pending responses from MG.

> for them from new MGC or we need to drop all unresponded requests and send
it again .. ?
Chak:
If you do not have transaction level equalization between primary and
secondary, you need to either drop the calls for which responses are
pending by sending SUBTRACT or re-transmit the requests from NEW MGC after
receiving SVC from MG.
> this case what do we so with the unresponded requests from the MGC before
it goes down .. ? 
Chak: In this case MG should send SVC with disconnected method.  After
receiving SVC MGC should AUDIT all the terminations and initiate necessary
clean-up.

> ROOT termination contain more than one action .. ?
Chak: Protocol does not limit this.  But I could not able to find any
usage for such a transaction.

---

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 20 Feb 2002 14:02:14 -0800

Chak/Vidya

- Bharat

-----Original Message-----

Chak:

Chak:

---

From: "Kevin Boyle"<[email-masked]>
Date: Wed, 20 Feb 2002 17:23:14 -0500

Wait a minute... You have indicated that a MG may clean up contexts on its
own.  This is certainly not described in the spec, and I strongly advise
against it.  For the first case, it is the MGC's responsibility to audit and
then take any appropriate action.  How does the MG know that the MGC doesn't
know about the contexts?  It doesn't, actually, and therefore cannot choose
to take it upon itself to clean up the contexts.

For the second example, once again, it is the MGC's responsibility to audit
and take any appropriate action.  If it has a knowledge of the current
state, then that makes the process easier -- potentially eliminating the
audit step.

The third case is similar to the first, except that the Disconnected method
should be used.  Other than this, the MGC has the responsibility to audit,
and take any appropriate action.

By allowing the MG to automatically clean itself up without intervention
from the MGC, we would introduce many opportunities for the MGC and the MG
to get out of sync, leading to reduction of capacity and reliability.  The
MG should never take it upon itself to "clean itself up".  The MGC should be
designed such that it audits and takes appropriate action, or cleans up the
MG, if it chooses not to audit.

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:02 PM
To: 'P.S.K. Chakravarthi'; vidya g
Cc: Boyle, Kevin [NCRTP:3Z30:EXCH]; [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Chak/Vidya

- Bharat

-----Original Message-----

Chak:

Chak:

---

From: "Kevin Boyle"<[email-masked]>
Date: Wed, 20 Feb 2002 17:23:14 -0500

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:02 PM
To: 'P.S.K. Chakravarthi'; vidya g
Cc: Boyle, Kevin [NCRTP:3Z30:EXCH]; [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Chak/Vidya

- Bharat

-----Original Message-----

Chak:

Chak:

---

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 20 Feb 2002 14:53:15 -0800

Ummm..there seems to be an implication that from practical point of the view
all three cases should be equivalent (to handoff) with new MGC relying on
audit to discover MG states. I would agree with you ideally but I forsee
some issues as listed below.

For example 1 (and example 3), it would seem that if we want MG to maintain
contexts, the MG should send a ServiceChange with "disconnect method" to the
new MGC. There are two cases:

* MGC knows about MG 
  
  This case is simpler. MGC audits and moves forward.

* MGC does not know about MG

  Since "disconnect" is not the way to register with the MGC, MGC will have
to send an error response. Does this error response imply MG has to cleanup
? I guess not. 

If it doesn't have any more MGC's provisioned what does MG do ? 

If it has more MGC's provisioned, it can end up in example 3, where MG will
keep going to different MGC's. Because of transaction time out related
issues (e.g. what if secondary MGC doesn't respond), what choice does MG
have ?

- Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 2:23 PM
To: Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----

Chak:

Chak:

---

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 20 Feb 2002 14:53:15 -0800

* MGC knows about MG 

- Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 2:23 PM
To: Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----

Chak:

Chak:

---

From: "Kevin Boyle"<[email-masked]>
Date: Wed, 20 Feb 2002 18:09:00 -0500

Disconnect is only used if the MG goes back to the MGC it was communicating
with when problems started.  If it goes to any other MGC, it must use
Handoff or Failover as appropriate.  Either way, it is up to the MGC how to
handle the MG when these scenarios occur.

Further comments inline [KJBII].

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Kaul, Bharat; 'P.S.K. Chakravarthi';
vidya g
Cc: [email-masked]

* MGC knows about MG 

[KJBII] How would the MG know that the MGC "knows about" it?  It doesn't,
and therefore can make no assumptions as to how to behave.  The MGC will
take any actions it deems appropriate.

[KJBII] Unless the MG is communicating back with the "failed" MGC, then
Disconnected should not be used.  If there is a control change to a new MGC,
then Handoff or Failover must be used.  Again I ask: How does the MG know
that the MGC doesn't "know about" it?  The MG does not have this knowledge,
and therefore cannot assume that the MGC is not capable of continuing the
contexts that are in existence.  It must wait for the MGC to clean it up, if
necessary.

[KJBII] It waits a random amount of time, and attempts to contact the MGCs
that are provisioned in its list.  This is described in the spec.

[KJBII] Once the MG has exhausted its list, it waits a random amount of
time, and then starts again through its list.  Once the MG finally makes
contact with an MGC, the MGC can take whatever action it deems appropriate.
Until that time, the MG can make no assumptions as to whether the MGC it
will eventually be controlled by is capable of continuing the existing
contexts or not.

- Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 2:23 PM
To: Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----

Chak:

Chak:

---

From: "Kevin Boyle"<[email-masked]>
Date: Wed, 20 Feb 2002 18:09:00 -0500

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Kaul, Bharat; 'P.S.K. Chakravarthi';
vidya g
Cc: [email-masked]

* MGC knows about MG 

- Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 2:23 PM
To: Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----

Chak:

Chak:

---

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 20 Feb 2002 15:51:50 -0800

Awwwrightie...this acted as a refresher for me :)...I had forgotten that
there is "failover" from MG->MGC is also possible.

I think there are two basic clarifications I still need

MG maintains the state of its terminations/contexts. And it seems even if MG
has to go through multiple MGC's before successfully establishing a control
association, it must do so (even if it takes really long theoretically
speaking). Correct ?

If answer to above question is yes, I presume MG doesn't need to maintain
currently unacknowledged transactions as MGC's auditing should lead to
discovery of termination/context states and normal execution can be picked
up from there ? Maintaining currently unacked transactions has time out
related issues and obviously don't have same lifetime as states of
terminations/contexts.

- Thanks
  Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 3:09 PM
To: Kaul, Bharat; Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Kaul, Bharat; 'P.S.K. Chakravarthi';
vidya g
Cc: [email-masked]

* MGC knows about MG 

- Bharat

---

From: "Kaul, Bharat" <[email-masked]>
Date: Wed, 20 Feb 2002 15:51:50 -0800

- Thanks
  Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 3:09 PM
To: Kaul, Bharat; Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Kaul, Bharat; 'P.S.K. Chakravarthi';
vidya g
Cc: [email-masked]

* MGC knows about MG 

- Bharat

---

From: "Kevin Boyle"<[email-masked]>
Date: Thu, 21 Feb 2002 12:52:26 -0500

Comments inline. [KJBII]

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 6:52 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

[KJBII] Yes.

[KJBII] Unacknowledged transactions will eventually "die" because
retransmission will stop.  Once the MG gets a new association established,
then the newly controlling MGC should figure out what the situation is
(through some means -- usually this would be auditing), and then take action
based on what it finds out.  This may be as simple as tearing all the calls
down, or the MGC may be sophisticated enough to pick calls up from where the
previous MGC left off.  It becomes very implementation-specific at this
point.  However, you are correct -- the timeout for retransmission will tend
to be a lot shorter than the lifespan of a particular state of a term or
context.

- Thanks
  Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 3:09 PM
To: Kaul, Bharat; Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Kaul, Bharat; 'P.S.K. Chakravarthi';
vidya g
Cc: [email-masked]

* MGC knows about MG 

- Bharat

---

From: "Kevin Boyle"<[email-masked]>
Date: Thu, 21 Feb 2002 12:52:26 -0500

Comments inline. [KJBII]

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 6:52 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

[KJBII] Yes.

- Thanks
  Bharat

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 3:09 PM
To: Kaul, Bharat; Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
Cc: [email-masked]
Subject: RE: [Megaco] VDY:>> MGC Failure

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 5:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Kaul, Bharat; 'P.S.K. Chakravarthi';
vidya g
Cc: [email-masked]

* MGC knows about MG 

- Bharat