Subject: RE: [Megaco] Regarding virtual MGs

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 4 Sep 2007 07:53:36 +0200

Do agree to Christian.

Looking at the email discussions, the key point is the "H.248 Control Association" (CA) concept.
A single CA binds a MG to an MGC, independent of a PMG or VMG.

Now, what constitutes a CA? Is the transport endpoint address part of the CA or not?
H.Sup7, § 5.2 provides a clarification, see:

http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/H_Supp_7_output.zip 

=> the understanding is that a CA is constitute just by the MID pair, independent of transport endpoint information or any address tuples in general!

This is an important aspect, also concerning some ServiceChange procedures (e.g. handoff), where transport address information may change, but not the MID value.

-Albrecht

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]] 
> Sent: Mittwoch, 22. August 2007 06:20
> To: Gopalarathnam Sambasivan
> Cc: [email-masked]
> Subject: Re: [Megaco] Regarding virtual MGs
> 
> 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.
> > 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] 
> > <mailto:[email-masked]>> wrote:
> >
> >     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:
> >     > 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/product
> s_configuration_guide_chapter09186a0080751588.html#wp1089696
> >     
> <http://www.cisco.com/en/US/products/hw/gatecont/ps3869/produc
> ts_configuration_guide_chapter09186a0080751588.html#wp1089696>
> >     >
> >     
> <http://www.cisco.com/en/US/products/hw/gatecont/ps3869/produc
> ts_configuration_guide_chapter09186a0080751588.html#wp1089696
> >     
> <http://www.cisco.com/en/US/products/hw/gatecont/ps3869/produc
> ts_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]
> >     <mailto:[email-masked]>
> >     > <mailto:[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.
> >     >
> >     >     Please see my answers inline.
> >     >
> >     >     Does MGC need to specifically remember it is a virtual GW?
> >     >     >>> 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
> >     >     complete responsibility or MG??
> >     >     >> Yes, it's the responsibility of the 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?
> >     >     >> MGC treats virtual GWs as two separate MGs.
> >     >
> >     >     Cheers,
> >     >     Jagan
> >     >
> >     >
> >     >     On 8/16/07, *Gopalarathnam Sambasivan* <
> >     [email-masked] <mailto:[email-masked]>
> >     >     <mailto: [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
> >     >            "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] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>
> >     >         https://www1.ietf.org/mailman/listinfo/megaco
> >     >
> >     >
> >     >
> >     >
> >     
> --------------------------------------------------------------
> ----------
> >     >
> >     > _______________________________________________
> >     > Megaco mailing list
> >     > [email-masked] <mailto:[email-masked]>
> >     > https://www1.ietf.org/mailman/listinfo/megaco
> >     >
> >
> >
> > 
> ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >   
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco