Re: IP changeover Procedures

Aha, you are overloading a single name (MID in FQDN format) with multiple addresses.
There are thus two issues in your configuration:
1) where did you specify that resolved DNS names are valid MID values?
2) your primary MGC instance (you got only one) is using two different MID formats (FQDN & numerical IP@).
 
You got to follow § 5.6.6/H.Sup7, see below.
This implies that you need an H.248 profile specification. If not, then the MG does not know how to use the respective SC parameters.
-Albrecht
 
 

5.6.6     Network availability: Changeover between primary and secondary systems


5.6.6.1      Address hierarchies


Using domain names for the MID of an H.248 entity allows the introduction of a further address hierarchy due to the basic possibility in mapping multiple IP addresses on a single FQDN. The basic idea is to support H.248 entities with multiple (physical and/or logical) IP interfaces (see clause 5.3.2.2). Changeover procedures between IP interfaces may affect correspondent address changes, but the domain name may be unchanged.

This concept is for instance anchored in some H.248 Profiles (e.g., [ETSI ES 283 002]).

Address-to-name or name-to-address resolution is not entirely described in [ITU-T H.248.1], but partially indicated in clause 7.2.8.1.3 of [ITU-T H.248.1]. Overloading of a name with multiple addresses, or vice versa, may not be excluded, but it is out of scope of the core protocol itself (H.248.1). Such kind of overlay functionality requires a mutual agreement between MGC and MG, e.g., could be defined in a profile specification.


5.6.6.2      Address changes (associated with changeover procedures)


The support of domain names, as a specific MID type, allows the support of two principal possibilities for address changes of H.248 entities.


5.6.6.2.1   With DNS involvement


This approach is based on the applied concept of clause 5.6.6.1. The H.248 entity must provide a DNS client instance and the DNS protocol for DNS server access. The local DNS database is coupled with databases of H.248 entities as described in clause 5.5.1.

For instance, in case of an MG the idea is the following:

The MG provides a database for MGC entries according to Table 2. The FQDNMGC (see column "symbolic IP address") remains unchanged for the designated MGC entity, but changes of address AMGC may be detected by the MG through DNS queries.

It has to be noted that this requires careful design considerations, primarily because of the following aspects:

•            Correspondent database updates at the MGC and MG levels are inherently not tightly synchronized (due to the third instance of a DNS server).

•            DNS is based on caching, associated with the DNS time-to-live (TTL) concept. The expiration of timer DNS-TTL triggers cache refreshes. It may thus take a rather long time until the MG gets the new MGC address via DNS.

             NOTE – Typical TTL configurations are for instance 60 seconds. H.248 entity embedded DNS clients require definitely much smaller TTL values.

•            There might be interactions with other ServiceChange-based procedures (e.g., according to clause 11.6 of [ITU-T H.248.1]), due to a natural transition period with address inconsistencies.


5.6.6.2.2   Directly controlled by peer H.248 entity


Address changes may be directly triggered via ServiceChange parameters: ServiceChangeAddress (see clause 5.6.5.1) or ServiceChangeMgcID (see clause 5.6.5.2), when the chosen address format relates to an actual IP address (IPv4 or IPv6, respectively). In case of a domain name based address format, there is a subsequent access operation on the local DNS cache, and a potential DNS query to a DNS server in case of a missing entry.

NOTE – There might be an enhancement of the "with DNS involvement" mechanism. The H.248 entity should always trigger a DNS server query – in case the above ServiceChange parameters are received – independent of whether an entry already exists in the local cache.


5.6.6.3      Role changes between primary and secondary entities


Any successful changeover between a primary and a secondary H.248 entity is always accompanied by the release of the old control association (with the primary) and the establishment of a new control association (with the secondary).

 
 


________________________________

	From: Akhil Jain [mailto:[email protected]] 
	Sent: Freitag, 11. Dezember 2009 15:54
	To: [email protected]; Schwarz Albrecht
	Subject: RE: [Megaco] IP changeover Procedures
	
	
Hi Schwarz,

Here are the answers and some more info:

-- MGC will use a MID ([email protected]) in FQDN format (which get resolves in IP1 and IP2).

1. MG has entries for both the IP's i.e. IP1 and IP2 corresponding to MGC.

2. Now as soon as MG sends a ServiceChange Request to MGC (consider IP1) MGC replies through IP1 and association has been created. In this reply MGC has used [email protected] as MID.
   Following is the reply:
   
   MEGACO/1 <[email protected]>:2944 Reply=11{Context=-{ServiceChange=ROOT{Services{VERSION=2,ServiceChangeAddr=[IP1]:2944,20091211T13451100}}}}


3. Now after some time IP1 goes down at MGC end.

4. Now MGC sends a ServiceChange message from IP2,mentioned below:

MEGACO/2 <[email protected]>:2944 Transaction=9{Context=-{ServiceChange=ROOT{Services{Method=HandOff,Reason="903 MGC Directed Change",MgcIdToTry=
[IP2]:2944,20091211T13452000}}}}|


In Handoff request MID has not been changed because Its the same MGC, only the active interface has changed to IP2.So Now, shall MG will reply to this service change and then again initiate Handoff procedure with IP2 ? The only difference with § 8.2/H.Sup7 is we have same MGC involved in Handoff Procedure and IP1,IP2 reside on same MGC and get resolved from same MID ([email protected]).


Thanks
Akhil Jain

--- On Fri, 11/12/09, Schwarz Albrecht <[email protected]> wrote:


	
	From: Schwarz Albrecht <[email protected]>
	Subject: RE: [Megaco] IP changeover Procedures
	To: "Akhil Jain" <[email protected]>, [email protected]
	Date: Friday, 11 December, 2009, 3:03 PM
	
	
	 
	Your description is still not complete, see below.
	See also § 8.2/H.Sup7.


________________________________

		From: Akhil Jain [mailto:[email protected]] 
		Sent: Donnerstag, 10. Dezember 2009 08:46
		To: [email protected]; Schwarz Albrecht
		Subject: RE: [Megaco] IP changeover Procedures
		
		
Hi Schwarz,

Sorry for delay in responding. Here is the detailed info:

1. MGC makes an association with peer gateway.It fills MID as [email protected] and fills ServiceChangeAddress as IP1.
[[Schwarz, Albrecht]] Did the MG accept the request? I.e., is there an established CA? 
2. Now IP1 goes down at MGC end.
3. MGC is now sending a ServiceChange Message (Method Handoff) from IP2 with MID as [email protected] and fills MGCIDtotry field with IP2.
[[Schwarz, Albrecht]] The H.248 Message for the MGC_1-initiated Handoff request is identified by "MID as xxx@yyy", but which MID value carries the ServiceChangeMgcID?  Really ServiceChangeMgcID = 'IP2'? 

So shall MG be able to handle the request and will it reply to IP2 ?
[[Schwarz, Albrecht]] only if the indicated secondary MGC is listed in the MG database of MGC instances, see Table 2/H.Sup7 


Thanks
Akhil Jain

--- On Tue, 1/12/09, Schwarz Albrecht <[email protected]> wrote:



	From: Schwarz Albrecht <[email protected]>
	Subject: RE: [Megaco] IP changeover Procedures
	To: "Akhil Jain" <[email protected]>, [email protected]
	Date: Tuesday, 1 December, 2009, 11:29 AM
	
	
	 
	Akhil,
	it's difficult to answer your questions because there's some information missing.
	The constitution of a CA (Control Association) is tightly coupled to the MID (see § 5.2/H.Sup7).
	The MID values are missing on your scenarios.
	Please provide that info, too.
	 
	Concerning the ServiceChangeMgcID scenario, could you please refer to § 8/H.Sup7 (§ 8.2) and indicate the difference?
	 
	Concerning the ServiceChangeAddress scenario, H.Sup7 is fairly clear that this parameter may be used for IP interface redirections, during CA establishment phases (i.e., the CA is NOT yet existent). Again pls refer to H.Sup7?
	 


________________________________

		From: [email protected] [mailto:[email protected]] On Behalf Of Akhil Jain
		Sent: Donnerstag, 26. November 2009 06:09
		To: [email protected]; Kevin Boyle
		Subject: Re: [Megaco] IP changeover Procedures
		
		
Hi, 

Can someone please help ?

--Akhil Jain

--- On Sat, 21/11/09, Akhil Jain <[email protected]> wrote:



	From: Akhil Jain <[email protected]>
	Subject: RE: [Megaco] IP changeover Procedures
	To: [email protected], "Kevin Boyle" <[email protected]>
	Date: Saturday, 21 November, 2009, 9:33 PM
	
	
Hi Kevin, 

Thanks for the reply. So if MGC-active sends a Service change from IP2 (as IP1 has been down) then shall it will fill Handoff as reason and new IP address as IP2 in MGCIDtotry field ? If that is the case then shall MG will reply on the new IP i.e. IP2 ? Kindly help.

Thanks
Akhil Jain

--- On Wed, 18/11/09, Kevin Boyle <[email protected]> wrote:



	From: Kevin Boyle <[email protected]>
	Subject: RE: [Megaco] IP changeover Procedures
	To: "'Akhil Jain'" <[email protected]>, [email protected]
	Date: Wednesday, 18 November, 2009, 8:49 PM
	
	
	 
	Hi Akhil,
	 
	A change of address for the MGC implies a new control association.  That does not necessarily mean that any contexts will be altered; all it means is that the control association has undergone a change.  It is up to the MGC to clean up anything on the MG that is out-of-whack.  Given that this is really the same MGC (though the MG cannot possibly know that), the MGC can choose to take NO action and continue everything as it is.  I will note that the change of interface will take a non-zero amount of time, so there is the possibility that messages will be lost.  The spec is pretty clear that the MG has to send replies back to where the command came from, so there is no way that a change of IP address can not result in a change of association (see H.248.1, Clause 9).
	 
	There is no way the MG could know that the MGC is the same one after the change of interfaces.  Please see H.248.1 Annex F for normative details on the ServiceChange procedures that are then used in the overall procedures in Supplement 7.
	 
	Kevin
	
	

________________________________

		From: [email protected] [mailto:[email protected]] On Behalf Of Akhil Jain
		Sent: Wednesday, November 18, 2009 5:30 AM
		To: [email protected]
		Subject: [Megaco] IP changeover Procedures
		
		
		
Hi All, 

Per our Implementation, we need to provide Interface Redundancy at MGC end, the architecture we were going to implement is MGC-Active will have 2 IP interfaces and MGC-Standby will have 2 IP interfaces.Can someone help in answering following things:

1. If an Association has been established between MGC-Active (IP1) and peer MG, and now IP1 of MGC-Active has gone down and IP-2 of MGC-Active needs to takeover without breaking the current control association how can we achieve that? 
<<< Per "Updated Draft ITU-T H.Sup7 “Gateway Control Protocol: Establishment Procedures for the H.248 MGC-MG Control Association” (Ed. 0.14)" ServiceChangeAddress field can be used by MGC to tell new IP address for remaining association. But the document has suggested the use of Service Change Address field in the "Association Establishment Phase".
Another thing if MGC sends ServiceChangeMethod as "Handoff" then It would mean that MGC wants a new association but that is not the case, MGC only wants to change the address for rest of the association. >>>


2. If we use MGCIDtotry field in the ServiceChange command then MGC will send this command through IP2 (as IP1 of MGC has been down) so, how will MG got to know that this request has been sent by MGC that has been registered on IP1. Shall it recognizes the MGC via MID ?


Kindly help!


Thanks
Akhil Jain

________________________________

		Now, send attachments up to 25MB with Yahoo! India Mail. Learn how <http://in.rd.yahoo.com/tagline_galaxy_2/*http://in.overview.mail.yahoo.com/photos> .


________________________________

	The INTERNET now has a personality. YOURS! See your Yahoo! Homepage <http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/> .


________________________________

		The INTERNET now has a personality. YOURS! See your Yahoo! Homepage <http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/> .


________________________________

		The INTERNET now has a personality. YOURS! See your Yahoo! Homepage <http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/> .


________________________________

	The INTERNET now has a personality. YOURS! See your Yahoo! Homepage <http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/> .

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco