Subject: RE: [Megaco] VDY:>> MGC Failure

From: "Kaul, Bharat" <[email-masked]>
Date: Tue, 23 Jul 2002 10:54:35 -0700

I suppose we need to have all this again summed up somewhere. Here is what I
gather as summary of the discussion.

If an MG is contacting any other MGC than the one that failed, it should use
Handoff or Failover as appropriate.  Disconnect is only used if the MG goes
back to the MGC it was communicating with when problems started.  If that
MGC has lost the registered state information of the MG, it returns an error
response with error code as 504 (Unauthorized). The MG upon receiving the
response should sending ServiceChange with method as "Restart" and Reason as
"Service Restored". 

This seems fair enough to me. 

- Bharat

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 9:31 AM
To: Gunter Weiss
Cc: Kevin Boyle; Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g;
[email-masked]; Tom-PT Taylor
Subject: Re: [Megaco] VDY:>> MGC Failure

Gunter Weiss wrote:

>Hello all,
>
>although I had a look to this discussion right now still one or two
question remain
>unclear to me:
>
>first of all:
>- assuming the MG tried to contact a secondary MGC with retries, but the
secondary
>  MGC does not answer- the MG has to contact the primary MGC (failed one)
again.
>  But how shall this one be contacted according H248 v1??
>  In H248v2 it is stated :
> "When contacting its previously controlling MGC the MG sends the
>   ServiceChange message with "Disconnected" method!"
>  This is clear to me and logically!
> This assumes that the MGC knows the MG as a registered one!
>  Unfortunatly this is not explicitly mentioned in H248v1!
>
not in the original text of v1 but it was added through the Implementors 
Guide and DOES appear in the H.248.1 (the latest text for v1).

>  Its also not logically that the MG send SVCH (restart or failover) to the
failed MGC,
>  because it does not know what happend to that MGC.
>
The failed MGC may have recovered or the failure may have been a 
temporary failure in the network, etc. So after trying the provisioned 
alternates, it will retry the original MGC, continuing the cycle until 
some MGC accepts it. MG does not need to know what happened to the MGC, 
it just wants to find one that accepts it.

>second point - but related:
>  assuming the MGC would answer on the SVCH (disconnected) with a negative
>  reply (504 - unautherized ...) - because it lost the registered state of
the MG.
>  What should be the reaction of the MG?
>  SVCH (restart) to get registered again  - but what reasoncode ??
>
I believe it should send restart. I am not sure there is a perfect 
reason but perhaps 900 Service Restored

>
>-- ,
>Gunter
>
>Kevin Boyle wrote:
>
>  
>
>>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]
>>Subject: RE: [Megaco] VDY:>> MGC Failure
>>
>>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.
>>
>>[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.
>>
>>* 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.
>>
>>[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.
>>
>>If it doesn't have any more MGC's provisioned what does MG do ?
>>
>>[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.
>>
>>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 ?
>>
>>[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
>>
>>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: P.S.K. Chakravarthi [mailto:[email-masked]]
>>
>>    
>>
>>>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 .. ?
>>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.
>>
>> >
>>    
>>
>>>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 .. ?
>>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.
>>    
>>
>>>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 .. ?
>>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.
>>
>>    
>>
>>>   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 .. ?
>>>      
>>>
>>Chak: Protocol does not limit this.  But I could not able to find any
>>usage for such a transaction.
>>    
>>
>>>
>>>
>>>_______________________________________________
>>>Megaco mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>      
>>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>    
>>
>
>
>
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>  
>

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 23 Jul 2002 14:24:55 -0500

Not quite

For starter according to Annex L which is now supposedly H.248.8, error code is
listed as "NOT USED".

This was after some discussion as to prevent flooding the network w/Reply to
"Unauthorized sender".

So if the implementation was following H.248.8, no reply would have been
received in your scenario
(MGC cold booted - assuming that MGC does not have control association after
rebooted).

So the question is
What should MG do if MG does not get a reply after so many retries of SC
Disconnected?

Is it after X num of retries, then MG goes through it list of MGCs?

Say yes, then a very high probability that the MG will get registered w/another
MGC using Failover.
(Any robust network would configured this to happen where I seriously doubt if
the list is ever traversed more
than once.)

Thus the failed controlling MGCx will become the un-controlling MGCx.
Therefore the next SC from this MG to MGCx would likely be Failover and not
Restart.

So if one looks at this failure scenario, it would seem only SC Disconnected
and Failover will be used.

So the question is
Is it necessary to qualify SC Methods w/control association for
terminationID=ROOT?

OR do we need to redefine control association?

---

Since control association dictates what MGC needs to do, what about MG?

IF MG cold boot, does MG has to remember who was its controlling MGC?
Does it send SC Disconnected to the controlling MGC first before it goes to its
list of MGCs?

Or does start w/its primary MGC using SC Restart?

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 23 Jul 2002 14:24:55 -0500

Not quite

So the question is

So the question is

---