Re: MGC and virtual MG

"Schwarz Albrecht" <[email protected]>
Newsgroups gmane.ietf.megaco
Message-ID <F4562D4585113D42AC08DC47FDEC49B002407908@FRVELSMBS23.ad2.ad.alcatel.com>
Ron, you should read H.Sup7 in all details.
There are two concepts here:
a) H.248 Control Association and
b) H.248 IP Transport connection (for your example of IP-based H.248 transport).
 
A singlehomed PMG could still support multiple, VMG-individual IP transport connection endpoints (due to different L4 port values).
There isn't any need at all to share a single IP transport connection endpoint by all VMG instances in a single PMG!
That might be even impossible at all ... due to different H.248 transport modes on different VMGs ... due to ServiceChange procedures with impact on the H.248 transport connection!
 
Thus, keep the difference of (a) and (b) in mind and assume VMG-individual IP transport connections.
 


________________________________

	From: [email protected] [mailto:[email protected]] On Behalf Of Ron Ho
	Sent: Dienstag, 22. September 2009 15:36
	To: Schwarz Albrecht
	Cc: megaco
	Subject: Re: [Megaco] MGC and virtual MG
	
	
	I assume that multiple Virtual MGs within the same physical MG can have only one ipaddress+port configured. 
	[[Schwarz, Albrecht]]  This condition is NOT valid.
	 As long as the mid of the virtual MG is different for each virtual MG (e.g. using device name format), the same IP connection can be used to carry multiple control associations between the MGC and the multiple virtual MGs. Right?
	
	If that is the case, who control the setup/tear down of the IP connection? How MGC handover/failover and MG handover/failover are controlled? Should there be one virtual MG designated as the master MG? Similarly, who should receive the keep alive message (e.g. auditvalue if it is configured)? Does the keep alive message need to be sent to all VMG or only the master MG should receive it?
	
	I am still confused.
	
	Thanks,
	Ron
	
	
	On Tue, Sep 22, 2009 at 3:15 AM, Schwarz Albrecht <[email protected]> wrote:
	

		You may found a lot of complementary information with respect to the H.248 Control Association in:
		
		H.Sup7 : Gateway control protocol: Establishment procedures for the H.248 MGC-MG control association
		http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.Sup7-200805-I!!PDF-E&type=items <http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.Sup7-200805-I%21%21PDF-E&type=items> 
		
		see e.g. § 5.2 Constitution of a control association
		

		> -----Original Message-----
		> From: [email protected]
		> [mailto:[email protected]] On Behalf Of Tom Taylor
		> Sent: Dienstag, 22. September 2009 04:04
		> To: Ron Ho
		> Cc: megaco
		> Subject: Re: [Megaco] MGC and virtual MG
		>
		> The MGC only needs one mid.
		>
		> Ron Ho wrote:
		> > Thanks for the clarification. So one MGC can control multiple MGs.
		> > Does the MGC need multiple mid, one for each MG? Or the MGC
		> needs one
		> > only mid and every MGs send to the same MGC using the same
		> mid of the MGC?
		> >
		> > On Fri, Sep 18, 2009 at 4:13 PM, Tom Taylor
		> <[email protected]> wrote:
		> >
		> >> You should be able to control multiple virtual MG from one MGC
		> >> instance if you need to. I can see a simple use case for
		> this, where
		> >> the normal MGC for one of the virtual MGs has failed and an MGC
		> >> controlling another virtual MG takes its place. I am sure
		> there are other applications.
		> >>
		> >> And yes, you can multiplex control associations for
		> multiple virtual
		> >> MGs over the same physical connection. You would have to take some
		> >> care not to clear down the connection just because one
		> virtual MG is doing a restart.
		> >>
		> ...
		
		> _______________________________________________
		> Megaco mailing list
		> [email protected]
		> https://www.ietf.org/mailman/listinfo/megaco
		>

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.