I think this sums things up. There was absolutely no intention that we mandate that H.245 be co-located with the MG. The only question was whether we would even consider it as an option. I think the answer is yes, but SG 16 has some issues to work out before it becomes a real priority for Megaco. These relate to definition of SG 16's interfaces B (occurs if H.225.0 call signalling is co-located with the MG) and E (occurs if H.245 is co-located with the MG). These interfaces are additional to the device control interface A, but will share the transport and do need to be coordinated with it. It is not our job to define what goes across those interfaces; the content will be tightly coupled to H.323.
Until the definition of the messaging across those interfaces is well-begun, I'd say our main concern is what I stated in the first place: to make sure that our protocol is modular enough that parts of it can be left unused if the MG is designed to respond autonomously to H.245 messaging. The second possible requirement is to think about how to coordinate device control messaging with other messaging happening between the same boxes (e.g. back-hauled SCN signalling). Beyond that, I can't see any need to add anything to our protocol to support this option beyond the ability to negotiate its use.
-----Original Message----- From: Christian Huitema [SMTP:huitema@research.telcordia.com] Sent: Wednesday, March 10, 1999 12:42 PM To: Rex Coldren; David R. Oran Cc: Taylor, Tom-PT [SKY:B318-I:EXCH]; Mailing list for parties associated with ITU-T Study Group 16; megaco@BayNetworks.COM Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
On Mar 10, 8:57am, Rex Coldren wrote:
Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) Just to get this argument back on track...
Are we going to allow for the option of H.245 channels being opened on the MG?
Hey, we are not the protocol police... The answer to your "are we going to allow" is an unquivocal yes. You could in fact easily extend even our simplest MG-MGC protocol (SGCP) to support H.245 in the gateway, for example by declaring an "m=h245" media type in SDP. As Dave pointed out, it would be difficult then to support the fast start option, but this would definitely result in H.245 in the MG. It would also become very difficult for the MGC to keep track of the resources used by the MG.
The real question is whether the base protocol defined by Megaco should mandate autonoumous support of H.245 in each and every MG. I think that at this point, the consensus is "no." There is no need for a full support in simple telephone-only gateways, the protocol is quite heavy and also subject to rapid evolution with the definition of new media and new algorithm, and the resulting resource control is very murky.
On the other hand, there may be value in an H.245 "option", so that we don't get three vendors implementing the H.245-in-the-gateway extensions in three different ways.
-- Christian Huitema