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

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 29 Jul 2002 19:32:40 -0400

I'm going to jump in at this point rather than later in the thread because
this note is easy to respond to.  Please see inline.

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Friday, July 26, 2002 7:53 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Megaco] VDY:>> MGC Failure

This discussion stopped in its tracks and I think we need to address this
important issue. Here is the crux of the discussion so far:
 
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). 

[PTT] This isn't what we originally designed that return code for.  Why
doesn't the MGC simply accept the registration, then either force a restart
on the MG or do an audit to restore synchronization?

The MG upon receiving the response should sending ServiceChange with method
as "Restart" and Reason as "Service Restored".
 
However, as Chuong pointed out, Annex L says that Error Code 504 is Not Used
(and reason was to prevent DOS). So the question still remains, how does MG
recover its communication with the MGC or rather when would MG start sending
"Restart" to the MGC ?
 
One simple solution is to always let MGC's accept "DISCONNECT" also as a
means of contacting but mandate that MGC's must Audit MG's after
"disconnect".

[PTT] What the MGC does is an implementation matter.  The two choices are as
I stated above.  The main thing DISCONNECT says is that the MG state is
bound to be out of date.
 
This solution does not break any protocol rules and enables smooth recovery
of communication with the MGC.
 
- Bharat

 -----Original Message-----
From: Chuong N. Nguyen [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 12:25 PM
Cc: [email-masked]
Subject: Re: [Megaco] VDY:>> MGC Failure

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? 

"Kaul, Bharat" wrote: 
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
-- 
  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 ****

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

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Mon, 29 Jul 2002 18:53:26 -0500

> on the MG or do an audit to restore synchronization?

Are you saying that ServiceChange Disconnected is also a registration
ServiceChange like
Restart, Failover, Handoff which is fine with me since it makes everything a
lot simpler.
That is basically these Methods are an overkill.  The Reason code could have
been used to
distingush these different Method behaviors to start with.

So far I have not seen any text that refers to SC Disconnected being a
registration SC.

Now if you can comment on the following.
If UDP is being used and the MGC has already specified that port 10,000 be
used.
MGC cold boot and does not have any registered MG info.
Therefore MGC is only listening on 2944.

MG keeps sending SC Disconnected to MGC on port 10,000.
Therefore MG will never get a reply.
What should MG do?
1) Go through its list of MG - Probably so.
2) MG went through its list and come back to MGC that failed.
     IT will again use port 10,000 and will not get an answer.
3) Worse case the MG has only MGC provisioned.  We are hung forever????

By the way you lost me after the "force a restart".

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Mon, 29 Jul 2002 18:53:26 -0500