audet at NORTELNETWORKS.COM
Thu Mar 11 15:08:39 EST 1999
> -----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)
> 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.
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.
More information about the sg16-avd