Subject: [Megaco] MGC failure and freeing MG resources

From: Dan Elbert <[email-masked]>
Date: Fri, 10 Aug 2001 14:08:57 -0500

Hi
If the MGC fails in the middle of a call, does the MG needs to take some
responsibility for freeing up his
resources or it can assume that the secondary MGC (if it succeed in
contacting it) will be responsible
for either continuing the call or clearing resources? It seems better for
the MG to have some robustness
and clear the resources, but then the backup MGC cannot keep the call alive.
Any toughts ?

Dan Elbert
RADVISION

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

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Fri, 10 Aug 2001 16:14:19 -0400

Hi Dan/All,
This is a good point to note. But how does the MG got to know about the MGCs
failure (It will definitely be through some response timeout for other
terminations, )in which case the MG has to register with its secondary MGCs.
IMHO while registering with secondary MGCs the state of the terminations in
the MG is same as when it registers for the first time (and the calls have
to be dropped, so does the resource clearing).  IMO except for the
disconnection method and MGC directed handoff method, in all other cases MG
has to take the terminations to their initial state.

Regards
Madhubabu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dan Elbert
Sent: Friday, August 10, 2001 3:09 PM
To: [email-masked]'
Subject: [Megaco] MGC failure and freeing MG resources

Hi

Dan Elbert
RADVISION

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 13 Aug 2001 10:09:23 -0400

This is not my understanding at all.  MG should never change the state 
of terminations without instructions from an MGC.  After any restoration 
of MGC signaling by:
1)  signaled handoff (ServiceChange with Method=handoff),
2) an MGC failure where MG registers with a Secondary MGC (ServiceChange 
Method = failover),
3) an MGC failure where MG re-registers with the Primary (ServiceChange 
Method = disconnected)

The state of terminations should be unchanged.  The new or 
recovered-original MGC may have means for knowing state (fault-tolerant 
machine pairs, fault-tolerant data repository or any other means) or it 
may have to audit the MG to discover state, but that is MGC's 
responsibility.  MG should not assume state is lost and reset all 
terminations.  That would terminatee all calls and be unacceptible 
behavior in many systems.  This behavior is needed to permit 
fault-tolerant operation, and I believe implied by the discussion in 10.5.

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

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Mon, 13 Aug 2001 11:22:03 -0400

HI Terry/All,

The present protocol doesn't indicate status of the state of
terminations/contexts after the change in control association. (Trigger for
the ambiguity).

In "RESTART" method ---- MG comes up clean with Physicals in Null context
and NO ephemerals. (No problem to asses the state of terminations)
"Failover" method  ---- If MG initiates this, there is no mention of the
states.
"Disconnect" method --- Assumes that MG is in same earlier state as it is
trying with the same controlling MGC.
"Handoff" method    --- State of terminations is same as before "Handoff" as
MGC has directed the change in controlling MGC. (Not sure what should be the
case when the newly indicated MGC fails to respond)

I completely "agree" that by the philosophy of this Master-Slave protocol,
the MG should not change the state by itself. I suggest what we specifically
mention what should be the state of the terminations in each case (as
direction was mentioned in usage of methods), This indication of state in
each method will make these cases crystal clear and hopefully no chance of
ambiguity.

Regards
Madhubabu

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 13 Aug 2001 12:39:24 -0400

I agree.  Tom Taylor suggested that we need a broader treatment 
precisely defining association state transitions and this clarification 
should certainly be a part of that.  I am expecting at least one 
contribution addressing this broader task in the near future and so I 
suggest we wait for this discussion before we introduce something 
through the IG.

Madhu Babu Brahmanapally wrote:

>>This is a good point to note. But how does the MG got to know about the
>>
>MGCs
>
>>terminations, )in which case the MG has to register with its secondary
>>
>MGCs.
>
>>and clear the resources, but then the backup MGC cannot keep the call
>>
>alive.
>
>>Any toughts ?
>>
>>Dan Elbert
>>RADVISION
>>