Voip

Jason Chang jasonc at NPLAB.COM
Tue Mar 9 20:13:11 EST 1999


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