RE: Redundancy of MGC

"Kevin Boyle" <[email protected]>
Newsgroups gmane.ietf.megaco
Message-ID <34B3EAA5B3066A42914D28C5ECF5FEA41352F936@zrtphxm2.corp.nortel.com>
Recall that H.248.14 defines a package that lets the MG detect the status of the control association.
 
Kevin

________________________________

From: Raphael Tryster [mailto:[email protected]] 
Sent: Sunday, January 27, 2008 7:19 AM
To: Nemet, Tamar TELRD (External:EXTRNL:TELRD); [email protected]
Subject: RE: [Megaco] Redundancy of MGC


That's why it says "if".  Usually, the MG will only detect an MGC failure if it does not receive a reply to messages it sends (Notify or ServiceChange), after retransmissions are exhausted.  If the MG currently has no messages to send, the MGC may very well failover to a redundant unit, or to itself, as you described, without the MG ever knowing.
 
Raphael Tryster

________________________________

From: Tamar Nemet [mailto:[email protected]] 
Sent: Sunday, January 27, 2008 12:31 PM
To: Raphael Tryster; [email protected]
Subject: RE: [Megaco] Redundancy of MGC



 I want to add that in the standard it is written that "if the MG detect a failure of its controlling MGC" (paragraph 11.5), but I don't understand how the MG shell detect failure of MGC ? The MG has no reason to send messges to the MGC , so how it should detect it ?


11.5      Failure of an MGC


If the MG detects a failure of its controlling MGC, it attempts to contact the next MGC on its pre‑provisioned list. It starts its attempts at the beginning (primary MGC), unless that was the MGC that failed, in which case it starts at its first secondary MGC. It sends a ServiceChange message with a "Failover" method and a " MGC Impending Failure" reason. If the MG is unable to establish a control relationship with any MGC, it shall wait a random amount of time as described in 9.2 and then start again contacting its primary, and (if necessary) its secondary MGCs. When contacting its previously controlling MGC, the MG sends the ServiceChange message with "Disconnected" method.

	-----Original Message-----
	From: Raphael Tryster [mailto:[email protected]] 
	Sent: Sunday, January 27, 2008 12:25 PM
	To: Tamar Nemet; [email protected]
	Subject: RE: [Megaco] Redundancy of MGC
	
	
	In both cases, I would say it is the responsibility of the MGC.  If the MGC consists of two units with a floating IP address, then part of their design should be that the MGC taking over has access to information that was known to the one that failed.  In the non-redundant case, I would expect that the MGC would at least maintain the address of the MGs that it controls.  It could then issue audit commands for all terminations in all contexts and in the null context to get its database up to date.
	 
	Raphael Tryster

________________________________

	From: Tamar Nemet [mailto:[email protected]] 
	Sent: Sunday, January 27, 2008 12:21 PM
	To: [email protected]
	Subject: [Megaco] Redundancy of MGC
	
	
	Hi,
	 
	I have a question regarding redundancy of MGC:
	 
	If MGC has a failure and another MGC starting to work instead of the failed one (with the same IP address), as much as I understand the MG should continue working with no change and the MGC should continue sending messges to this MG.  Is it correct ?
	 
	If the MGC has no redundant companent and it make restart and start up again, the MG will not make registration again because the MG doesn't know that the MGC failed. So how should the connection between MGC and MG start again ?  Is there something that the MG should do ? or it is up to MGC ?
	 
	Thanks for your help,
	Tamar
	 
________________________________

	IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only.
	If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof.
	*** eSafe scanned this email for viruses, vandals, and malicious content. *** 
________________________________


________________________________

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. *** 
________________________________

_______________________________________________
Megaco mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/megaco
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.