Mailing List

Simon Brewer simon at
Thu Mar 11 21:48:20 EST 1999

At 10:41 AM 3/11/99 -0500, David R. Oran wrote:
>> -----Original Message-----
>> From: owner-megaco at BayNetworks.COM
>> [mailto:owner-megaco at BayNetworks.COM]On Behalf Of Ami Amir
>> Sent: Wednesday, March 10, 1999 9:26 PM
>> 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)
>> 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?
>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.

I'll count this one as technical!

Expect a longer reply to come.




More information about the sg16-avd mailing list