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.
-----Original Message----- From: owner-megaco@BayNetworks.COM [mailto:owner-megaco@BayNetworks.COM]On Behalf Of Taylor, Tom-PT [SKY:B318-I:EXCH] Sent: Wednesday, March 10, 1999 8:54 AM To: Mailing list for parties associated with ITU-T Study Group 16 Cc: megaco@BayNetworks.COM Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments)
I'll forward this to the Megaco list. One point, though. Just because call signalling is in the MGC doesn't mean we have a GK-routed model: the MGC is part of the Gateway in the SG 16 architecture and TIPHON's. (Its relationship to the H.323 architecture is unstated in Megaco, except that we cite the TIPHON architecture as an example.)
-----Original Message----- From: Dale L. Skran [SMTP:dskran@ASCEND.COM] Sent: Tuesday, March 09, 1999 12:22 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
See detailed comments below.
Dale Skran Q13 rapporteur
At 12:07 PM 3/8/99 -0600, Tom-PT Taylor wrote:
-----Original Message----- From: David R. Oran [SMTP:oran@cisco.com] Sent: Monday, March 08, 1999 10:25 AM To: megaco Subject: Where H.245 goes - MG or MGC
Here are some random thoughts on one of the questions of marrying
Megaco
with H.323 - where H.245 goes. Some prior messages have
indicated that
there are tradeoffs involved here, and I agree. Some
food for thought:
- If we terminate H.245 on the MG, this blows away V2
fast start, and
looking at likely call flows may introduce 1/2 RTT extra over a
monolothic
H.323 gateway.
If GW A sends a setup with an OLC to GW B, H.225.0 and H.245 both go between the GWs and fast start
works fine. The
penalty of not using fast start only occurs if you want the
call signaling
going to the controller and the H.245 to the GWs.
In any case, the key word here is OPTIONAL. All three
alternatives need to
be supported, not just the imposition of the GK-routed call
model on all
vendors and customers.
a)full GK-routed b)GK routed signaling; H.245 between GWs c)direct call model with H.323 RAS in MGC and H.225.0/H.245between GWs
- The MGC may wish to participate in CAPs exchange for
policy reasons.
Of course, and this should be the MGC's choice to force the
GK-routed call
model just as is currently the case.
- The H.245 open logical channel operation is analogous
to doing VC
establishment on the MG in the ATM case, and for
parallelism might be
best
done MG-MG. It is also where certain resource allocation
operations get
This is part of the case for doing H.245 between GWs rather
than through
the controller.
done and hence synchronizes well with the H.323 model of error
reporting.
Unfortunately, putting CAPs excahnge in one association
and logical
channel control in a different association would be a
pretty major
tweak
to H.323.
There is a mental leap here that is not clear; why would
this be done?
- Putting H.245 completely on the MG factors the problem
of translating
among different media description syntaxes (e.g.
H245/ASN1 vs SDP) -
the
MGC-MG protocol then might not need to have a full-blown media
description
in it when using H.323 for global signaling.
Indeed, another good reason for H.245 between the GWs.
- Putting H.245 on the MG gives the MG a lot of autonomy. This is
arguably
more autonomy than the Megaco model should assign to the MG.
Different strokes for different folks. Different customers
will take each
approach.
- Splitting up H.323 with H.225 signaling in one place and H.245
signaling
in another place may uncover some state coordination
issues which would
(unneccesarily?) complicate the MGC-MG protocol and
possibly introduce
direct H.323 dependencies.
Certainly this is possible, although there are vendors who
do this right
now (how about a posting?). It is difficult to not have H.323
dependencies in
a protocol to decompose an H.323 GW.
My intuition says that the tradeoffs favor keeping H.245
in the MGC.
What
do others think?
The arguements presented here indicate the opposite; that
H.245 should
optionally go between the GWs, as well as H.225.0 call signaling.
Beware the black/white view. Different customers will use
the products in
different ways.
participants (1)
-
Flemming Andreasen