Subject: RE: [Megaco] MGC failure and freeing MG resources

From: "Kaul, Bharat" <[email-masked]>
Date: Mon, 13 Aug 2001 12:27:25 -0700

Hi Terry/Madhu/Dan/List,

 While we are discussing how Terminations get affected, we also need to
consider some basic stuff i.e. transactions. Consider one of the cases of
sending failover from MG to secondary MGC. 

What does this MG do with commands that it had previously transmitted to
primary MGC? I suppose obvious response is retransmit it to new MGC. But
this can be done only after registration with new MGC is complete. Now what
if registration fails and MG has to go to another MGC in the list ? How long
are these commands kept and note that we have timers running on these
transactions ? What would expiry of this timer mean to termination state ?

Similarly consider the situation where MG needs to send responses to
previously received commands from the primary MGC and MGC fails. The MG may
go and register with secondary MGC (with failover) but what about protocol
requirement "The response must go to the source transport address" 

These are issues we need to deal with before we decide it is alright to use
"failover" (in this case) . I suppose that is why in the first place,
restart was chosen. If it is felt that "Restart" is not appropriate when MG
moves from primary to secondary MGC, then we need to address above issues
before we choose "failover".

Similar issues may be there with all these other methods and we need to
address them

- Bharat

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Monday, August 13, 2001 9:39 AM
To: Madhu Babu Brahmanapally
Cc: 'Dan Elbert'; [email-masked]
Subject: Re: [Megaco] MGC failure and freeing MG resources

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:

>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
>
>-----Original Message-----
>From: Terry L Anderson [mailto:[email-masked]]
>Sent: Monday, August 13, 2001 10:09 AM
>To: Madhu Babu Brahmanapally
>Cc: 'Dan Elbert'; [email-masked]
>Subject: Re: [Megaco] MGC failure and freeing MG resources
>
>
>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.
>
>Madhu Babu Brahmanapally wrote:
>
>>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
>>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
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>http://www1.ietf.org/mailman/listinfo/megaco
>>
>
>--
>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
>
>
>
>

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

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

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