headers
Schwarz Albrecht | 1 Dec 2009 06:59
Favicon

Re: IP changeover Procedures

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

Hi,

Can someone please help ?

--Akhil Jain

--- On Sat, 21/11/09, Akhil Jain <akhil_jain111 <at> yahoo.co.in> wrote:

From: Akhil Jain <akhil_jain111 <at> yahoo.co.in>
Subject: RE: [Megaco] IP changeover Procedures
To: megaco <at> ietf.org, "Kevin Boyle" <kboyle <at> huawei.com>
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 <kboyle <at> huawei.com> wrote:

From: Kevin Boyle <kboyle <at> huawei.com>
Subject: RE: [Megaco] IP changeover Procedures
To: "'Akhil Jain'" <akhil_jain111 <at> yahoo.co.in>, megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Akhil Jain
Sent: Wednesday, November 18, 2009 5:30 AM
To: megaco <at> ietf.org
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.
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 4 comments |
headers
François Plagnard | 3 Dec 2009 17:20
Favicon

Specifying audio codec on fixed termination

Hello,

 

In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.

In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).

How this audio codec may be indicated by the MGC to the gateway?

 

Best regards,

 

François Plagnard

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 8 comments |
headers
Tom Taylor | 4 Dec 2009 17:23

Re: Specifying audio codec on fixed termination

It is legitimate to specify a Local Descriptor for the B channel termination, 
indicating which codec is being used.

François Plagnard wrote:
> Hello,
> 
>  
> 
> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
> 
> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
> 
> How this audio codec may be indicated by the MGC to the gateway?
> 
>  
> 
> Best regards,
> 
>  
> 
> François Plagnard
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 6 comments |
headers
Bhattacharjee, Arindam (Arindam | 4 Dec 2009 17:24
Favicon

Re: Specifying audio codec on fixed termination

Hi Farcois,

Audio codec is indicated by some other protocol ( Mostly SDP-session description protocol. RFC 4566)  in Local & Remote Descriptor in Megaco.

H248.1 specifies the details about those descriptor.

 

-Arindam

From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of François Plagnard
Sent: Thursday, December 03, 2009 11:20 AM
To: megaco <at> ietf.org
Subject: [Megaco] Specifying audio codec on fixed termination

 

Hello,

 

In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.

In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).

How this audio codec may be indicated by the MGC to the gateway?

 

Best regards,

 

François Plagnard

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
François Plagnard | 4 Dec 2009 17:58
Favicon

Re: Specifying audio codec on fixed termination

Thank you for your answer.
But, now my concern is how to specify an audio codec in a B channel in Local descriptor?
I have found no way to describe it in SDP format contained in Local descriptor (there is no RTP involved here
or any other transport).

Best regards,

François Plagnard

-----Message d'origine-----
De : Tom Taylor [mailto:tom111.taylor <at> bell.net] 
Envoyé : vendredi 4 décembre 2009 17:23
À : François Plagnard
Cc : megaco <at> ietf.org
Objet : Re: [Megaco] Specifying audio codec on fixed termination

It is legitimate to specify a Local Descriptor for the B channel termination, 
indicating which codec is being used.

François Plagnard wrote:
> Hello,
> 
>  
> 
> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
> 
> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
> 
> How this audio codec may be indicated by the MGC to the gateway?
> 
>  
> 
> Best regards,
> 
>  
> 
> François Plagnard
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 5 comments |
headers
Bhattacharjee, Arindam (Arindam | 4 Dec 2009 18:10
Favicon

Re: Specifying audio codec on fixed termination


For ISDN-IP on ISDN side you will have physical terminator which the B-channel, for IP side you have to have a
ephemeral terminator created by MG where you use RTP with local/remote descriptor.

If you are trying TDM only calls then the the T1 or E1 with ulaw or alaw should be preconfigured in MG. MGC does
not need to know physical resource configuration of the MG.

May need more information on your implementation.

-Arindam

-----Original Message-----
From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of François Plagnard
Sent: Friday, December 04, 2009 11:58 AM
To: Tom Taylor
Cc: megaco <at> ietf.org
Subject: Re: [Megaco] Specifying audio codec on fixed termination

Thank you for your answer.
But, now my concern is how to specify an audio codec in a B channel in Local descriptor?
I have found no way to describe it in SDP format contained in Local descriptor (there is no RTP involved here
or any other transport).

Best regards,

François Plagnard

-----Message d'origine-----
De : Tom Taylor [mailto:tom111.taylor <at> bell.net] 
Envoyé : vendredi 4 décembre 2009 17:23
À : François Plagnard
Cc : megaco <at> ietf.org
Objet : Re: [Megaco] Specifying audio codec on fixed termination

It is legitimate to specify a Local Descriptor for the B channel termination, 
indicating which codec is being used.

François Plagnard wrote:
> Hello,
> 
>  
> 
> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
> 
> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
> 
> How this audio codec may be indicated by the MGC to the gateway?
> 
>  
> 
> Best regards,
> 
>  
> 
> François Plagnard
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
Tom Taylor | 4 Dec 2009 20:03

Re: Specifying audio codec on fixed termination

Once upon a time (almost ten years ago) I created an SDP solution for ISDN, but 
eventually backed off before it was standardized. I forgot about the need to 
specify a transport for the media in the m= line when I answered you today. 
Either we would have to carry the necessary changes through as a new AVT profile 
or you'll have to use some sort of trick.

François Plagnard wrote:
> Thank you for your answer.
> But, now my concern is how to specify an audio codec in a B channel in Local descriptor?
> I have found no way to describe it in SDP format contained in Local descriptor (there is no RTP involved here
or any other transport).
> 
> Best regards,
>  
> François Plagnard
>  
> -----Message d'origine-----
> De : Tom Taylor [mailto:tom111.taylor <at> bell.net] 
> Envoyé : vendredi 4 décembre 2009 17:23
> À : François Plagnard
> Cc : megaco <at> ietf.org
> Objet : Re: [Megaco] Specifying audio codec on fixed termination
> 
> It is legitimate to specify a Local Descriptor for the B channel termination, 
> indicating which codec is being used.
> 
> François Plagnard wrote:
>> Hello,
>>
>>  
>>
>> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
>>
>> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
>>
>> How this audio codec may be indicated by the MGC to the gateway?
>>
>>  
>>
>> Best regards,
>>
>>  
>>
>> François Plagnard
>>
>>  
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
> 
>
Permalink | Reply | 3 comments |
headers
Christian Groves | 6 Dec 2009 12:28

Re: Specifying audio codec on fixed termination

Hello Francois,

You can use the attributes from H.248.1 Annex C. i.e ACodec from C.1 or 
layer1prot from C.9. If you want to carry these in the text encoding use 
H.248.15 and a package ID of "anxc" (as defined in  Annex C).

Regards, Christian

Tom Taylor wrote:
> Once upon a time (almost ten years ago) I created an SDP solution for 
> ISDN, but eventually backed off before it was standardized. I forgot 
> about the need to specify a transport for the media in the m= line 
> when I answered you today. Either we would have to carry the necessary 
> changes through as a new AVT profile or you'll have to use some sort 
> of trick.
>
> François Plagnard wrote:
>> Thank you for your answer.
>> But, now my concern is how to specify an audio codec in a B channel 
>> in Local descriptor?
>> I have found no way to describe it in SDP format contained in Local 
>> descriptor (there is no RTP involved here or any other transport).
>>
>> Best regards,
>>  
>> François Plagnard
>>  
>> -----Message d'origine-----
>> De : Tom Taylor [mailto:tom111.taylor <at> bell.net] Envoyé : vendredi 4 
>> décembre 2009 17:23
>> À : François Plagnard
>> Cc : megaco <at> ietf.org
>> Objet : Re: [Megaco] Specifying audio codec on fixed termination
>>
>> It is legitimate to specify a Local Descriptor for the B channel 
>> termination, indicating which codec is being used.
>>
>> François Plagnard wrote:
>>> Hello,
>>>
>>>  
>>>
>>> In a gateway between ISDN and IP, B channels on ISDN side are fixed 
>>> terminations.
>>>
>>> In some ISDN networks, the audio codec used line may vary per call 
>>> (often between G.711 A law and mu law).
>>>
>>> How this audio codec may be indicated by the MGC to the gateway?
>>>
>>>  
>>>
>>> Best regards,
>>>
>>>  
>>>
>>> François Plagnard
>>>
>>>  
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>
Permalink | Reply | 2 comments |
headers
Akhil Jain | 10 Dec 2009 08:46
Picon
Favicon

Re: 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 xxx <at> yyy.com 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 xxx <at> yyy.com and fills MGCIDtotry field with IP2.

So shall MG be able to handle the request and will it reply to IP2 ?


Thanks
Akhil Jain

--- On Tue, 1/12/09, Schwarz Albrecht <Albrecht.Schwarz <at> alcatel-lucent.com> wrote:

From: Schwarz Albrecht <Albrecht.Schwarz <at> alcatel-lucent.com>
Subject: RE: [Megaco] IP changeover Procedures
To: "Akhil Jain" <akhil_jain111 <at> yahoo.co.in>, megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Akhil Jain
Sent: Donnerstag, 26. November 2009 06:09
To: megaco <at> ietf.org; Kevin Boyle
Subject: Re: [Megaco] IP changeover Procedures

Hi,

Can someone please help ?

--Akhil Jain

--- On Sat, 21/11/09, Akhil Jain <akhil_jain111 <at> yahoo.co.in> wrote:

From: Akhil Jain <akhil_jain111 <at> yahoo.co.in>
Subject: RE: [Megaco] IP changeover Procedures
To: megaco <at> ietf.org, "Kevin Boyle" <kboyle <at> huawei.com>
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 <kboyle <at> huawei.com> wrote:

From: Kevin Boyle <kboyle <at> huawei.com>
Subject: RE: [Megaco] IP changeover Procedures
To: "'Akhil Jain'" <akhil_jain111 <at> yahoo.co.in>, megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Akhil Jain
Sent: Wednesday, November 18, 2009 5:30 AM
To: megaco <at> ietf.org
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.
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 3 comments |
headers
Schwarz Albrecht | 11 Dec 2009 10:33
Favicon

Re: IP changeover Procedures

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

From: Akhil Jain [mailto:akhil_jain111 <at> yahoo.co.in]
Sent: Donnerstag, 10. Dezember 2009 08:46
To: megaco <at> ietf.org; 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 xxx <at> yyy.com 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 xxx <at> yyy.com 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 <at> 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 <Albrecht.Schwarz <at> alcatel-lucent.com> wrote:

From: Schwarz Albrecht <Albrecht.Schwarz <at> alcatel-lucent.com>
Subject: RE: [Megaco] IP changeover Procedures
To: "Akhil Jain" <akhil_jain111 <at> yahoo.co.in>, megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Akhil Jain
Sent: Donnerstag, 26. November 2009 06:09
To: megaco <at> ietf.org; Kevin Boyle
Subject: Re: [Megaco] IP changeover Procedures

Hi,

Can someone please help ?

--Akhil Jain

--- On Sat, 21/11/09, Akhil Jain <akhil_jain111 <at> yahoo.co.in> wrote:

From: Akhil Jain <akhil_jain111 <at> yahoo.co.in>
Subject: RE: [Megaco] IP changeover Procedures
To: megaco <at> ietf.org, "Kevin Boyle" <kboyle <at> huawei.com>
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 <kboyle <at> huawei.com> wrote:

From: Kevin Boyle <kboyle <at> huawei.com>
Subject: RE: [Megaco] IP changeover Procedures
To: "'Akhil Jain'" <akhil_jain111 <at> yahoo.co.in>, megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Akhil Jain
Sent: Wednesday, November 18, 2009 5:30 AM
To: megaco <at> ietf.org
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.
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 2 comments |

Gmane