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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 30 Jul 2002 07:10:31 -0400

I would agree with both of these propositions.

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Monday, July 29, 2002 8:38 PM
To: Taylor, Tom-PT [CAR:B602:EXCH]; 'Chuong N. Nguyen'
Cc: [email-masked]'
Subject: RE: [Megaco] VDY:>> MGC Failure

Once the MGC failure occurs, essentially MGC and MG have gone out of sync as
far as state information is concerned. The obvious goal is to come back into
sync and we have Audits for that. Like I said in one of my previous emails,
MGC should accept "DISCONNECT" as a valid means of contact and take it up
from there.

As far as MG contacting MGC at port other than default is concerned,  once
MG detects failure of an MGC, next time it shouldn't assume that it would be
able to communicate anywhere other default port as "Control Association"
needs to be established again. So in this case, MGs behavior needs fixing -
protocol is ok.

- Bharat

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, July 29, 2002 5:08 PM
To: 'Chuong N. Nguyen'
Cc: [email-masked]'
Subject: RE: [Megaco] VDY:>> MGC Failure

As far as I'm concerned, there are three key state issues a ServiceChange
(ROOT) from the MG has to address: 
(1) What service state is the MG as a whole in or about to be in?
(2) Is it possible the addressed MGC has state data relating to the
requesting MG?
(3) Are the MG's termination states right up to date, stale, or
reinitialized?

SCMethod and SCReason in combination should address these issues.  As you
say, our methods are probably overkill, but it's a bit late to prune them
back.  I would also say that SCReason seems to be the place where there is a
bit of freedom to address point (3) above.

As to your second question, I think you've answered it yourself.  The MG's
behaviour is maladaptive.  At some point it has to forget that it had a
relationship with a specific MGC and go back to using default port (assuming
the contact port isn't configured in the MGC).  Does anyone think the
duration of the timeout before amnesia is a protocol issue?

-----Original Message-----
From: Chuong N. Nguyen [mailto:[email-masked]]
Sent: Monday, July 29, 2002 7:53 PM
Cc: [email-masked]'
Subject: Re: [Megaco] VDY:>> MGC Failure

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? 

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

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

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 30 Jul 2002 10:10:58 -0500

I agreed too.

But let make sure MGC implementors understand the following:

Again back to the scenario where MGC told MG to send msg to UDP port 10,000.

Now say we didn't have an MGC cold boot but a temporary network failure
(original intend of the use of
SC Disconnected).

Thus MGC is still listening on port 10,000 for msg from MG.
MG sends SC Disconnected to MGC on port 2944 as you said.

This would mean that MGC implementor should accept SC Disconnected from port
2944 and
reply back w/port 10,000 if it chooses to continue using that port for future
communication w/MG
or use another port and close port 10,000.

If everyone agrees, I think we have covered it.

So Kevin, do you see any of these need to be added to TD.41?

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 30 Jul 2002 10:10:58 -0500

I agreed too.