Subject: Re: [Megaco] IP changeover Procedures

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 1 Dec 2009 06:59:57 +0100

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-masked] [mailto:[email-masked]] On Behalf Of Akhil Jain
	Sent: Donnerstag, 26. November 2009 06:09
	To: [email-masked]; Kevin Boyle
	Subject: Re: [Megaco] IP changeover Procedures

Hi, 

Can someone please help ?

--Akhil Jain

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

	From: Akhil Jain <[email-masked]>
	Subject: RE: [Megaco] IP changeover Procedures
	To: [email-masked], "Kevin Boyle" <[email-masked]>
	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-masked]> wrote:

	From: Kevin Boyle <[email-masked]>
	Subject: RE: [Megaco] IP changeover Procedures
	To: "'Akhil Jain'" <[email-masked]>, [email-masked]
	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-masked] [mailto:[email-masked]] On Behalf Of Akhil Jain
		Sent: Wednesday, November 18, 2009 5:30 AM
		To: [email-masked]
		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/> .

---

From: Akhil Jain <[email-masked]>
Date: Thu, 10 Dec 2009 13:16:26 +0530 (IST)

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-masked] and fills ServiceChangeAddress as IP1.2. Now IP1 goes down at MGC end.3. MGC is now sending a ServiceChange Message (Method Handoff) from IP2 with MID as [email-masked] and fills MGCIDtotry field with IP2.
So shall MG be able to handle the request and will it reply to IP2 ?

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

From: Schwarz Albrecht <[email-masked]>
Subject: RE: [Megaco] IP changeover Procedures
To: "Akhil Jain" <[email-masked]>, [email-masked]
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-masked] 
  [mailto:[email-masked]] On Behalf Of Akhil 
  Jain
Sent: Donnerstag, 26. November 2009 06:09
To: 
  [email-masked]; Kevin Boyle
Subject: Re: [Megaco] IP changeover 
  Procedures

    
      Hi,

        --Akhil Jain

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

From: 
          Akhil Jain <[email-masked]>
Subject: RE: [Megaco] 
          IP changeover Procedures
To: [email-masked], "Kevin Boyle" 
          <[email-masked]>
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-masked]> wrote:

From: 
                  Kevin Boyle <[email-masked]>
Subject: RE: [Megaco] 
                  IP changeover Procedures
To: "'Akhil Jain'" 
                  <[email-masked]>, [email-masked]
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-masked] [mailto:[email-masked]] 
                    On Behalf Of Akhil Jain
Sent: Wednesday, 
                    November 18, 2009 5:30 AM
To: 
                    [email-masked]
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.

          The INTERNET now has a personality. YOURS! See your Yahoo! 
        Homepage.

  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 

      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Fri, 11 Dec 2009 10:33:32 +0100

Your description is still not complete, see below.
See also § 8.2/H.Sup7.

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

Hi Schwarz,

1. MGC makes an association with peer gateway.It fills MID as [email-masked] 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-masked] 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

	 
	Akhil,

Hi, 

--Akhil Jain

Hi Kevin, 

Thanks
Akhil Jain

	 
	Hi Akhil,

	 
	Kevin

		
Hi All, 

Kindly help!

Thanks
Akhil Jain

---

From: Akhil Jain <[email-masked]>
Date: Fri, 11 Dec 2009 20:24:23 +0530 (IST)

Hi Schwarz,
Here are the answers and some more info:
-- MGC will use a MID ([email-masked]) 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-masked] as MID.   Following is the reply:      MEGACO/1 <[email-masked]>: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-masked]>: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-masked]).

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

From: Schwarz Albrecht <[email-masked]>
Subject: RE: [Megaco] IP changeover Procedures
To: "Akhil Jain" <[email-masked]>, [email-masked]
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-masked]] 
Sent: Donnerstag, 10. Dezember 
  2009 08:46
To: [email-masked]; Schwarz Albrecht
Subject: 
  RE: [Megaco] IP changeover Procedures

    
      
        Hi Schwarz,

        1. MGC makes an association with peer gateway.It fills MID as 
        [email-masked] 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-masked] 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-masked]> wrote:

From: 
          Schwarz Albrecht 
          <[email-masked]>
Subject: RE: [Megaco] 
          IP changeover Procedures
To: "Akhil Jain" 
          <[email-masked]>, [email-masked]
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-masked] 
            [mailto:[email-masked]] On Behalf Of Akhil 
            Jain
Sent: Donnerstag, 26. November 2009 
            06:09
To: [email-masked]; Kevin Boyle
Subject: 
            Re: [Megaco] IP changeover Procedures

              
                Hi, 

                  --Akhil Jain

From: 
                    Akhil Jain <[email-masked]>
Subject: RE: 
                    [Megaco] IP changeover Procedures
To: [email-masked], 
                    "Kevin Boyle" <[email-masked]>
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-masked]> wrote:

From: 
                            Kevin Boyle <[email-masked]>
Subject: 
                            RE: [Megaco] IP changeover Procedures
To: "'Akhil 
                            Jain'" <[email-masked]>, 
                            [email-masked]
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-masked] 
                              [mailto:[email-masked]] On Behalf Of 
                              Akhil Jain
Sent: Wednesday, November 
                              18, 2009 5:30 AM
To: 
                              [email-masked]
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.

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Fri, 11 Dec 2009 16:17:32 +0100

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-masked]] 
	Sent: Freitag, 11. Dezember 2009 15:54
	To: [email-masked]; Schwarz Albrecht
	Subject: RE: [Megaco] IP changeover Procedures

Hi Schwarz,

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-masked] as MID.
   Following is the reply:
   
   MEGACO/1 <[email-masked]>:2944 Reply=11{Context=-{ServiceChange=ROOT{Services{VERSION=2,ServiceChangeAddr=[IP1]:2944,20091211T13451100}}}}

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

Thanks
Akhil Jain

	

Hi Schwarz,

Thanks
Akhil Jain

	 
	Akhil,

Hi, 

--Akhil Jain

Hi Kevin, 

Thanks
Akhil Jain

	 
	Hi Akhil,

	 
	Kevin

		
Hi All, 

Kindly help!

Thanks
Akhil Jain