Akhil Jain | 18 Nov 2009 11:30
Picon
Favicon

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.
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Kevin Boyle | 18 Nov 2009 16:19
Favicon

Re: IP changeover Procedures

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.
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Akhil Jain | 21 Nov 2009 17:03
Picon
Favicon

Re: IP changeover Procedures

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.
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Christian Groves | 23 Nov 2009 06:11

Re: Reply to audit all contexts, list of commands with specific terminations

Hello Raphael,

Finally got around to looking at the email.

I believe that option 2 is the correct response. I think the example is 
the same as specifying Transaction 1 [ContextID=ALL,TID=C1], Transaction 
2 [ContextID=ALL, TID=C2], Transaction 3 [ContextID=ALL, TID=C3]. Thus 
section 6.3.2/H.248.1 is relevant.

Please see my comments below.

Regards, Christian

Raphael Tryster wrote:
>
> Consider an MG that has terminations C1, C2 and C3. C1 is in context 
> 1, C2 is in context 2, and C3 is in the null context. What is the 
> correct reply to this transaction?
>
> !/1 [192.168.59.1]:2944 T=2629{
>
> C=*{O-AV=C1{AT{M}}, O-AV=C2{AT{M}}, O-AV=C3{AT{M}}}}
>
> Answer 1:
>
> MEGACO/1 [192.168.59.2]:2944
>
> Reply=2629{
>
> Context=1{
>
>
AuditValue=C1{Media{LocalControl{Mode=SendReceive},TerminationState{ServiceStates=InService, 
> Buffer=OFF}}},
>
> AuditValue=C2{Error=435{"Termination not in specified context"}},
>
> AuditValue=C3{Error=435{"Termination not in specified context"}}
>
> },
>
> Context=2{
>
> AuditValue=C1{Error=435{"Termination not in specified context"}},
>
>
AuditValue=C2{Media{LocalControl{Mode=SendReceive},TerminationState{ServiceStates=InService, 
> Buffer=OFF}}},
>
> AuditValue=C3{Error=435{"Termination not in specified context"}}
>
> }
>
> }
>
> Answer 2:
>
> MEGACO/1 [192.168.59.2]:2944
>
> Reply=2629{
>
> Context=1{
>
>
AuditValue=C1{Media{LocalControl{Mode=SendReceive},TerminationState{ServiceStates=InService, 
> Buffer=OFF}}},
>
> },
>
> Context=2{
>
>
AuditValue=C2{Media{LocalControl{Mode=SendReceive},TerminationState{ServiceStates=InService, 
> Buffer=OFF}}}
>
> }
>
> }
>
> Answer 3:
>
> MEGACO/1 [192.168.59.2]:2944
>
> Reply=2629{
>
> Context=1{
>
>
AuditValue=C1{Media{LocalControl{Mode=SendReceive},TerminationState{ServiceStates=InService, 
> Buffer=OFF}}},
>
> AuditValue=C3{Error=431{"No TerminationID matched a wildcard"}}
>
> },
>
> Context=2{
>
>
AuditValue=C2{Media{LocalControl{Mode=SendReceive},TerminationState{ServiceStates=InService, 
> Buffer=OFF}}},
>
> AuditValue=C3{Error=431{"No TerminationID matched a wildcard"}}
>
> }
>
> }
>
> Why should it be Answer 1? Although section 7.2.5 says that "the 
> command Context=*{AuditValue=t2/*{Audit{Packages}}} returns 
> Context=1{AuditValue=t2/1{Packages{ccc,ddd}}}, 
> Context=2{AuditValue=t2/2{Packages{ccc,ddd}}}", this case is 
> different, because the terminations are enumerated explicitly, and so 
> a reply is expected for each termination listed, for each context that 
> exists.
>
[CNG] Answer 1 isn't valid. You are correct that the case is different 
because the terminations are specific. Is does say though that using 
ContextID=ALL and TerminationID=specific returns "(Non-NULL) ContextID 
in which the termination currently exists.
>
> Why should it be Answer 2? Because of 6.3.2, "ContextID wildcarded 
> (ALL) with TerminationID specific: In the case where the ContextID is 
> wildcarded (i.e. ContextID = ALL) and the TerminationID is fully 
> specified, the effect is identical to a command specifying the 
> non-NULL context that contains the specified termination. Thus a 
> search must be made to find the context and only one instance of the 
> command is executed. No errors are reported for contexts that do not 
> contain the specified termination".
>
[CNG] I believe Answer 2 is valid.
>
> Why should it be Answer 3? Because 6.3.2 continues, "If the 
> termination is not contained in any (non-NULL) context then Error Code 
> 431 (“No TerminationID matched a wildcard”) is returned".
>
[CNG] Because C3 IS in the NULL context the error wouldn't be generated.
>
> Answer 2 seems to be the most manageable and useful, but that doesn't 
> count for much if an MGC is expecting a different format and will draw 
> wrong conclusions if it doesn’t get it. So, if anyone can see the 
> right answer clearly, I would appreciate it.
>
> Raphael Tryster
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>   
Christian Groves | 23 Nov 2009 06:16

Results from the recent ITU-T Q.3/16 meeting

Hello all,

For those interested the latest outputs from the recent ITU-T Q.3/16 
meeting can be found at:
http://wftp3.itu.int/av-arch//avc-site/2009-2012/0910_Gen/0910_Gen.html

The packetiser site also has a H.248 document status and history page 
that may be useful:
http://www.packetizer.com/ipmc/h248/doc_status.html

Regards, Christian
Akhil Jain | 26 Nov 2009 06:09
Picon
Favicon

Re: 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
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

Gmane