Subject: RE: [Megaco] Redundancy of MGC

From: "Tamar Nemet" <[email-masked]>
Date: Sun, 27 Jan 2008 12:31:29 +0200

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-masked]] 
	Sent: Sunday, January 27, 2008 12:25 PM
	To: Tamar Nemet; [email-masked]
	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-masked]] 
	Sent: Sunday, January 27, 2008 12:21 PM
	To: [email-masked]
	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. *** 
________________________________

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

---

From: "Raphael Tryster" <[email-masked]>
Date: Sun, 27 Jan 2008 14:18:46 +0200

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-masked]] 
Sent: Sunday, January 27, 2008 12:31 PM
To: Raphael Tryster; [email-masked]
Subject: RE: [Megaco] Redundancy of MGC

11.5      Failure of an MGC

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Sunday, January 27, 2008 12:25 PM
	To: Tamar Nemet; [email-masked]
	Subject: RE: [Megaco] Redundancy of MGC

	Raphael Tryster

	Hi,

	 
	 
	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. ***
**********************************************************************************************
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Sun, 27 Jan 2008 11:29:14 -0500

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-masked]] 
Sent: Sunday, January 27, 2008 7:19 AM
To: Nemet, Tamar TELRD (External:EXTRNL:TELRD); [email-masked]
Subject: RE: [Megaco] Redundancy of MGC

Raphael Tryster

11.5      Failure of an MGC

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Sunday, January 27, 2008 12:25 PM
	To: Tamar Nemet; [email-masked]
	Subject: RE: [Megaco] Redundancy of MGC

	Raphael Tryster

	Hi,

	 
	 
	Thanks for your help,
	Tamar

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 29 Jan 2008 19:26:45 +0100

Tamar,

your „MGC redundancy concept“ is not fully clear to me from your original email.

You may distinguish two level’s of redundancy:

a)    H.248 entity “internal”: working plane and protection plane (see e.g. Fig. 1 in H.Sup7)

Draft ITU-T H.Sup7 “Gateway Control Protocol: Establishment Procedures for the H.248 MGC-MG Control Association”

http://ftp3.itu.int/av-arch/avc-site/2005-2008/0801_Seo/TD-35.zip

b)    primary/secondary concept for H.248 entities

*      (b) is in scope of H.248 by changeover methods

*      (a) is out of scope because primarily related to internal implementations of H.248 entities in order to achieve high-availability; 

*      (a) may be completely decoupled from (b)

*      if (a) is not completey decoupled from (b), then “internal” changeover procedures *may* be supported by *H.248 changeover* procedures (if possible, depends on design)  

Saying that, I got the impression that you are talking about (b), which would actually relate to a “MGC takeover” scenario (“the first MGC may still be in-service”).

See also discussion of that scenario in:

Discussion H.248.1 Version 4 – MGC Takeover

http://ftp3.itu.int/av-arch/avc-site/2005-2008/0801_Seo/AVD-3213.zip

... and to note that existing H.248 versions do *not* support „MGC takeover“.

-Albrecht

From: Kevin Boyle [mailto:[email-masked]] 
Sent: Sonntag, 27. Januar 2008 17:29
To: Raphael Tryster; Tamar Nemet; [email-masked]
Subject: RE: [Megaco] Redundancy of MGC

Kevin

Raphael Tryster

11.5  Failure of an MGC

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]] 
	Sent: Sunday, January 27, 2008 12:25 PM
	To: Tamar Nemet; [email-masked]
	Subject: RE: [Megaco] Redundancy of MGC

	Raphael Tryster

	Hi,

	Thanks for your help,

	Tamar