FW: Where H.245 goes - MG or MGC (Skran's comments)

Ami Amir amir at RADVISION.RAD.CO.IL
Wed Mar 10 21:25:53 EST 1999


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 at telcordia.com]
Sent:   Wednesday, March 10, 1999 4:58 PM
To:     ITU-SG16 at 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 at cisco.com> on 03/10/99 09:33:05 AM

To:   "Taylor, Tom-PT [SKY:B318-I:EXCH]" <taylor at americasm01.nt.com>,
      "Mailing list for parties associated with ITU-T Study Group 16"
      <ITU-SG16 at mailbag.cps.intel.com>
cc:   megaco at 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 at BayNetworks.COM
> [mailto:owner-megaco at 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 at 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 at ASCEND.COM]
> > Sent: Tuesday, March 09, 1999 12:22 PM
> > To:   ITU-SG16 at 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 at 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.245
> > between 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.
> >
> >
> > >
>



More information about the sg16-avd mailing list