Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
Hi Well - it seems we are getting pretty religious about this issue. My take: For a simple toll by-pass application - it makes sense to route H.245 to the MGC. The MG is "dumb" - all decisions are centralized - and life is simple :) However, if we believe that the real future of VoIP is in adding functionality and services, that there will be instances when H.323 end points also are involved, and multimedia is important, a case can be made for that the MG should support H.245. I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling. My question - can't we allow for both? Ami -----Original Message----- From: Flemming Andreasen [SMTP:fandreas@telcordia.com] Sent: Wednesday, March 10, 1999 4:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) I will agree with that. Let's not forget that we are addressing "decomposed gateways". As Dave pointed, out GW = MGC + MG + SG so there's no argument there. Also, the idea with the decompostion is precisely that; to decompose the GW into its logical components that each address different aspects of the combined GW. The MGC is the one with the intelligence/control/complexity, or whatever we want to call it, and as Brian pointed out earlier the bearer part is in the MG. Thus Dave's arguments still stand, and H.245 should be in the MGC, not the MG. Regards Flemming Andreasen "David R. Oran" <oran@cisco.com> on 03/10/99 09:33:05 AM To: "Taylor, Tom-PT [SKY:B318-I:EXCH]" <taylor@americasm01.nt.com>, "Mailing list for parties associated with ITU-T Study Group 16" <ITU-SG16@mailbag.cps.intel.com> cc: megaco@BayNetworks.COM (bcc: Flemming Andreasen/Bellcore) Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments) Dale's arguments are impeccable if one believes that MGCs are gatekeepers, which they're not. MGCs and MGs are a single H.323 endpoint, ripped apart and put in different boxes. The Megaco protocol glues the boxes together. If you put all of H.323 in the MG then you have no need of an MGC in the first place. QED. I don't think anyone proposes declaring that monolithic H.323 endpoints (i.e. MGC+MG+SG) must be split up. Heavens, many of us sell hundreds of these every day and they work just fine, thank you. So, I think I agree with Tom that this response is interesting but not terribly relevant to the engineering tradeoffs in marrying Megaco to H.323.
Amir, I would like to comment on your response, for the purpose of understanding the issues better. --Hong
Hi
Well - it seems we are getting pretty religious about this issue.
Maybe some technical discussions will help.
The main purpose is separate of concerns: the MGC handles signaling while the MG handles media streams. The scripting capability will minimize the messaging traffic between the MGC and the MG, and as a side effect, give the MG certain intelligence. But all these are under the control of MGC.
I would like to see concrete examples and sound technical arguments for your claim. Maybe you can show a few call flows that really demonstrate the needs to have H.245 down in the MG that could not be handled gracefully otherwise. This will really help both sides understand each other better.
I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling.
I would also like to see call flows and technical arguments for these cases.
Moi?
As I pointed out in my original tradeofs note (which was at least *intended* to be technically oriented and politically neutral), if you put the H.225 signaling exchanges as MGC-MGC and the H.245 exchanges as MG-MG we need to assure ourselves that either: 1) there is no state coupling between H.225 and H.245 that fails if the two aren't running in the same box, or 2) the MGC-MG protocol explicitly carries the information needed for this state coupling. In case 2, we also need to analyze whether there is significant performance impact in carrying the state coupling and whether the tradeoffs still favor H.245 in the MG for some cases. As a simple example, H.225 carries the IP address and port to run H.245 on. At the very least this information would need to be conveyed from the MGC to the MG in the Megaco protocol. Christian Huitema mentioned one quite reasonable way to do this in the MGCP case by describing the H.245 addressing in an SDP announcement with m=H.245. Another example is the fate-sharing between the H.225 connection and the H.245 connection. I forget whether it's the H.225 or H.245 connection which determines the "liveness" of the end-to-end session, but if it's the H.245 connection alone this introduces some complications in maintaining MGC state. It would take someone much more expert than I in H.323 to ascertain what the exact scope of the state coupling is. I don't think anyone wants to BAN H.245 in the MG; just that there are a lot of potentially subtle technical points and the difficulties might be sufficiently large to warrant real caution. Two issues that particularly trouble me are: a) giving up the ability for the MGC to see and modify the capabilities exchanges for policy or other reasons. b) giving up the ability to put the audio logical channels on one MG and the video logical channels on another MG for the same session.
Ami
Now, a meta question, for my edification. Do people interpret this as a purely technical posting (as intended) or are we so polarized that every technical point seems laden with politico-religious portents. Dave.
participants (4)
-
Ami Amir -
Dale L. Skran -
David R. Oran -
Hong Liu