Subject: [Megaco] Regarding virtual MGs

From: "Gopalarathnam Sambasivan" <[email-masked]>
Date: Thu, 16 Aug 2007 16:33:50 +0530

Hello All,
Can someone Please enlighten me with the concept of virtual MG from MG point
of view and more so from MGC point of view.
RFC3525, Sec 11.1 states
   "Each virtual MG has its own Root Termination.  In most cases the
   values for the properties of the Root Termination are independently
   settable by each MGC.  Where there can only be one value, the
   parameter is read-only to all but the Master MGC.

   ServiceChange may only be applied to a Termination or set of
   Terminations partitioned to the Virtual MG or created (in the case of
   ephemeral Terminations) by that Virtual MG."

Question:
=======
Does MGC need to specifically remember it is a virtual GW?
How is the property of root termination per MGC?? Is there no need for MGC
to make any difference between MG and a Virtual MG and it is
complete responsibility or MG??
What MGC needs to do if service change restart root comes from a Virtual MG
by mistake and if it controls both the Virtual GWs?

Please also let me know which commercially available GWs support virtual MG.

Thanks and Best Regards,
Gopalarathnam.
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Jagan Mohan" <[email-masked]>
Date: Fri, 17 Aug 2007 17:12:29 +0530

Before I answer to your queries, here is basic concept of how virutal
MGs would be implemented.

There would be a profile on a MG, which has the info. about the MGC to which
it needs to register. You can have multiple profiles and hence the MG can
register to multiple MGCs. Any physical/ephemeral termination on the
MG would be associated with only profile and hence associated with only one
MGC.

Please see my answers inline.

>>> MGC is not aware that there are virtual GWs on a single physical MG.
It's the MG which needs to be aware of the terminations associated with the
particular MGC.

>> Yes, it's the responsibility of the MG.

>> MGC treats virtual GWs as two separate MGs.

Cheers,
Jagan

On 8/16/07, Gopalarathnam Sambasivan <[email-masked]> wrote:
>
> Hello All,
> Can someone Please enlighten me with the concept of virtual MG from MG
> point of view and more so from MGC point of view.
> RFC3525, Sec 11.1 states
> What MGC needs to do if service change restart root comes from a Virtual
> MG by mistake and if it controls both the Virtual GWs?
>

---

From: "Gopalarathnam Sambasivan" <[email-masked]>
Date: Fri, 17 Aug 2007 20:05:59 +0530

Hello Jagan, All,
Thanks for your answer. But it still doesn't completely solve my query.
Iam working on a MGC and not on a MG.
The physical real MG that Iam using is a small audiocode gateway which is
not capable of handling multiple MGCs.

I had the following configuration in my MGC. MG is done using simulator.
MGC had 2 Gateways (VGW) - 2 different logical names in MGC With the same
ip@.
I had all other configurations - DNs and other things needed for making the
call.
When I sent a restart service change for root termination from this ip@ only
one of the 2 VGW endpoints is made to in-service in the MGC. If restart
service change (1 terminations in 2 VGWs) seperately, same configuration,
those terminations are in service in MGC and call is possible.

A bug raised for the same has been rejected as configuration problem -
saying VGWs need to have its own IP@ (floating IP@) on the same physical
interface.
But Iam not fully convinced with this reply. 1 physical gateway with x VGW
mapped to x IP@.
why should a service provider have x IP@ for 1 device???

Iam not able to find much info from the web for a GW product supporting VGW
with configuration details.
I saw a cisco product document - VXSM card for VoIP -
http://www.cisco.com/en/US/products/hw/gatecont/ps3869/products_configuration_guide_chapter09186a0080751588.html#wp1089696
but it is not clear whether it *can/must* have different IP@.

Please let me know about some gateway which supports VGWs and its
configuration needs different ip@ or same ip@ can also be used. But from
rest of the configuration details it seems to be it should work with same
ip@

If it must be different IP@, then why is there a RFC statement

"ServiceChange may only be applied to a Termination or set of
   Terminations partitioned to the Virtual MG or created (in the case of
   ephemeral Terminations) by that Virtual MG."

- only if ip@ and port be the same is there a need not to send root and use
Termination or set of termination alone.
Otherwise with ip@ and/or port a distinction - root handling can be done by
MG for its various VirtualMG.

So, should MGC make a mark for virtual gateway, to know its virtual?
 What MGC needs to do if service change restart root comes from a Virtual MG
by mistake and if it controls both the Virtual GWs?

Thanks in advance.

Best Regards,
Gopalarathnam.

On 8/17/07, Jagan Mohan <[email-masked]> wrote:
> There would be a profile on a MG, which has the info. about the MGC to
> which it needs to register. You can have multiple profiles and hence the MG
> can register to multiple MGCs. Any physical/ephemeral termination on the
> > How is the property of root termination per MGC?? Is there no need for
> > MGC to make any difference between MG and a Virtual MG and it is

---

From: "Jagan Mohan" <[email-masked]>
Date: Sat, 18 Aug 2007 13:01:57 +0530

Your mail is quite confusing. It's not very clear.

>From what I understood from your mail, you could have the following:

Even if 2 VGWs (on a single MG) have the same IP address, the port on which
the H.248 service runs could be different for the 2 VGWs. Then, your MGC can
differentiate the VGWs through the port information.

You might have other ways of controlling VGW by a MGC.

Regards,
Jagan

On 8/17/07, Gopalarathnam Sambasivan <[email-masked]> wrote:
> I had all other configurations - DNs and other things needed for making
> the call.
> When I sent a restart service change for root termination from this ip@
> only one of the 2 VGW endpoints is made to in-service in the MGC. If restart
> Iam not able to find much info from the web for a GW product supporting
> VGW with configuration details.
> - only if ip@ and port be the same is there a need not to send root and
> use Termination or set of termination alone.
> Otherwise with ip@ and/or port a distinction - root handling can be done
> by MG for its various VirtualMG.
>
> >  On 8/16/07, Gopalarathnam Sambasivan < [email-masked]>
> > wrote:
> >
> > >  Hello All,
> > > What MGC needs to do if service change restart root comes from a
> > > Virtual MG by mistake and if it controls both the Virtual GWs?
> > >

---

From: Ashish Singh <[email-masked]>
Date: Sat, 18 Aug 2007 15:01:09 -0700

Hi Gopal,

MGC should be able to handle Virtual MG or physical MG in the same way. 
MGC only requires some way to identify the VMG. Normally each VMG on the 
same physical MG uses the unique (IP + port), so MGC can identify the 
VMG on receiving any message.

One more thing, VMG can change its (IP + port) through configuration 
interface while the H248 association is active. In this case, VMG 
indicate this to MGC by sending a Servicechange with new [ip adrr]: 
port. After this, MGC should expect to receive VMG messages from new 
address.

The only thing VMG doesn't change during the tenure of H248 association 
is MID (Message Identifier). So MGC can use this field also to identify 
VMGs.

My 2 cents :-)
Ashish

Gopalarathnam Sambasivan wrote:
> The physical real MG that Iam using is a small audiocode gateway which 
> is not capable of handling multiple MGCs.
>  
> MGC had 2 Gateways (VGW) - 2 different logical names in MGC With the 
> same ip@.
> I had all other configurations - DNs and other things needed for 
> making the call.
> When I sent a restart service change for root termination from this 
> ip@ only one of the 2 VGW endpoints is made to in-service in the MGC. 
> If restart service change (1 terminations in 2 VGWs) seperately, same 
> configuration,
> saying VGWs need to have its own IP@ (floating IP@) on the same 
> physical interface.
> But Iam not fully convinced with this reply. 1 physical gateway with x 
> VGW mapped to x IP@.
> Iam not able to find much info from the web for a GW product 
> supporting VGW with configuration details.
> <http://www.cisco.com/en/US/products/hw/gatecont/ps3869/products_configuration_guide_chapter09186a0080751588.html#wp1089696>
> configuration needs different ip@ or same ip@ can also be used. But 
> from rest of the configuration details it seems to be it should work 
> with same ip@
>  
>  
> - only if ip@ and port be the same is there a need not to send root 
> and use Termination or set of termination alone.
> Otherwise with ip@ and/or port a distinction - root handling can be 
> done by MG for its various VirtualMG.
>  
> On 8/17/07, *Jagan Mohan* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Before I answer to your queries, here is basic concept of how
>     virutal MGs would be implemented.
>      
>     There would be a profile on a MG, which has the info. about the
>     MGC to which it needs to register. You can have multiple profiles
>     and hence the MG can register to multiple MGCs. Any
>     physical/ephemeral termination on the MG would be associated with
>     only profile and hence associated with only one MGC.
>      
>     >>> MGC is not aware that there are virtual GWs on a single
>     physical MG. It's the MG which needs to be aware of the
>     terminations associated with the particular MGC.
>      
>     How is the property of root termination per MGC?? Is there no need
>     for MGC to make any difference between MG and a Virtual MG and it is
>     On 8/16/07, *Gopalarathnam Sambasivan* < [email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hello All,
>         Can someone Please enlighten me with the concept of virtual MG
>         from MG point of view and more so from MGC point of view.
>         RFC3525, Sec 11.1 states
>         How is the property of root termination per MGC?? Is there no
>         need for MGC to make any difference between MG and a Virtual
>         MG and it is
>         What MGC needs to do if service change restart root comes from
>         a Virtual MG by mistake and if it controls both the Virtual GWs?
>          
>         [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Gopalarathnam Sambasivan" <[email-masked]>
Date: Tue, 21 Aug 2007 15:03:10 +0530

Hello All,
Iam still not convinced by the concept of each VMG in a physical MG needs to
have a unique IP+port.
Please read the following theoritical description of a MG and let me know if
it is in any contradiction with any of the RFCs including RFC3525.
=================================================================================
A physical gateway has a physical interface card for IP and various other
cards for connecting telephone lines,....
This physical interface is configured having only 1 IP and 1 port used for
communication with the MGCs.
Say totally 4K subscrs are managed by this card.
This is split across 4 MGCs with each 1K subscrs.
Each Termination is configured with its own primary and secondary MGCs and
say 4 max failing MGC contacts.
VGW1/1 to 1000 - MGC1, MGC1B (if MGC1 doesnt respond),MGC1C, MGC1D
VGW2/1 to 1000 -MGC2..... and so on.
Also, the RTP ports can be similarly allocated per MGC.......

Communications from MGC:
=====================
MG checks whether the MGC is the one controlling those terminations.
Per termination - If there is modify/add/subtract from a MGC1 to VGW1/1 to
1000 it is done..... otherwise error reply.

Root or wildcard - If a MGC sends a modify for ROOT, MGC1 then all
terminations controlled by that MGC -
VGW1/1 to 1000 are alone affected.

Communications from MG:
===================
A notify VGW1/50 going offhook and dialling digits - needs to be sent only
to MGC1 which controls it.

Service change:
-----------------------
When coming online, this MG does not send service change restart for root
termination,
it sends service change restart for terminations VGW1/1 to 1000 - VGW1/* to
MGC1, VGW2/* to MGC2,....

There is no need of seperate IP+port per VGW, as this I see the handling is
just internal logic of MG and its
configuration association with a MGC per termination.The termination-MGC
association needs to be checked for
both communication from and to a MG, by the MG.

Since Iam a more a tester basically, I do not know much about the internal
designs....
still, Handling of each requests is going to be processed via seperate
threads, internal temp memory needed,.....
are all independent of the IP+port from which the message arrives.... also
the actual processing itself need not be in the same card having the
interface - it depends on the realisation of MG..........
================================================================================

Please let me know if this theoritical description valid according to RFC.

Isn't there any GW which works like this ?? - a real GW supporting VGW -
"The model does not
   require that other resources be statically allocated, just
   Terminations."

Please also let me know what are the practical difficulties in not following
same IP+port for all VGWs, if any.

Thanks in Advance.

Best Regards,
Gopalarathnam.

On 8/19/07, Ashish Singh <[email-masked]> wrote:
> > <

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Aug 2007 14:19:57 +1000

Hello,

 From a MGC perspective it should not be aware of the difference between 
a control association with a physical MG or with a VMG.

Regards, Christian

Gopalarathnam Sambasivan wrote:
> Hello All,
> Iam still not convinced by the concept of each VMG in a physical MG 
> needs to have a unique IP+port.
> Please read the following theoritical description of a MG and let me 
> know if it is in any contradiction with any of the RFCs including RFC3525.
> A physical gateway has a physical interface card for IP and various 
> other cards for connecting telephone lines,....
> This physical interface is configured having only 1 IP and 1 port used 
> for communication with the MGCs.
> Each Termination is configured with its own primary and secondary MGCs 
> and say 4 max failing MGC contacts.
> Per termination - If there is modify/add/subtract from a MGC1 to 
> VGW1/1 to 1000 it is done..... otherwise error reply.
>  
> A notify VGW1/50 going offhook and dialling digits - needs to be sent 
> only to MGC1 which controls it.
>  
> Service change:
> -----------------------
> When coming online, this MG does not send service change restart for 
> root termination,
> it sends service change restart for terminations VGW1/1 to 1000 - 
> VGW1/* to MGC1, VGW2/* to MGC2,....
>  
> There is no need of seperate IP+port per VGW, as this I see the 
> handling is just internal logic of MG and its
> configuration association with a MGC per 
> termination.The termination-MGC association needs to be checked for
> Since Iam a more a tester basically, I do not know much about the 
> internal designs....
> are all independent of the IP+port from which the message arrives.... 
> also the actual processing itself need not be in the same card having 
> the interface - it depends on the realisation of MG..........
> Isn't there any GW which works like this ?? - a real GW supporting VGW 
> - "The model does not
> Please also let me know what are the practical difficulties in not 
> following same IP+port for all VGWs, if any.
>  
> Thanks in Advance.
>  
> Best Regards,
> Gopalarathnam.
>
>  
> On 8/19/07, *Ashish Singh* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Gopal,
>
>     <http://www.cisco.com/en/US/products/hw/gatecont/ps3869/products_configuration_guide_chapter09186a0080751588.html#wp1089696
>     <http://www.cisco.com/en/US/products/hw/gatecont/ps3869/products_configuration_guide_chapter09186a0080751588.html#wp1089696>>
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     On 8/16/07, *Gopalarathnam Sambasivan* <
>     [email-masked] <mailto:[email-masked]>
>     >     <mailto: [email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >         Hello All,
>     <mailto:[email-masked] <mailto:[email-masked]>>