Hi Fernando,
I think we should address at least one issue in detail: Support of multiple media streams (I am assuming that each media stream is a context) which are part of a single "Point to Point Call" (for lack of a better term) that are egressing through a MG into a single PSTN connection. This is relevant for gateways between PSTN and IP or for gateways between native ATM and IP.
Relevant issues there:
1. Define that a context supports only one media stream (RTP) - equivalent to an H.245 logical channel. 2. Decide that when there is a need for an association between contexts that on the PSTN side are "joined", to use the RTP mechanisms (see Scott Petrack's comments).
This will allow a "smart" MGC to do all the rest.
Most of the other issues raised seem to me like re-inventions of wheels. If we try to enlarge the scope to make MEGACO a generic call control protocol for everything - we will end up re-writing H.323.
Ami
-----Original Message----- From: Fernando Cuervo [SMTP:cuervo@NORTELNETWORKS.COM] Sent: Tuesday, April 06, 1999 5:00 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Issues Around Support of Multimedia
Tom,
What are we supposed to do from the point of view of the charter? Would it suffice to have a warm-fuzzy feeling that the protocol is extensible (this could be possible by having one or more "reasonable" proposals to handle Context "behaviour" and sychronisation between contexts but not necessarily reaching an agreement on the "best" way to do it)
Fernando > ---------- > From: Taylor, Tom-PT [CAR:5V00-I:EXCH] > Sent: April 5, 1999 12:09 PM > To: megaco@BayNetworks.COM; itu-sg16@mailbag.cps.intel.com > Subject: Issues Around Support of Multimedia > > I have suggested some directions for exploration of solutions to the > problem > of support of multimedia over the past week, but I suspect such > suggestions > go beyond my role as WG Chair. Hence I am taking a step backward and > simply > summarizing the issues for others to resolve. > > Issue 1: representation of connection topologies for multiple media types. > > It seems to me that contexts are not topologies themselves, but rather > represent envelopes within which different topologies will be realized > depending on the mode settings for the associated terminations. > > Requirements: > a) Coordinate between different media streams (e.g. for lip-synch, > stereo). > b) Represent degenerate cases simply (e.g. audio-only connections, > two-point connections). > c) Support multicast. > > Issue 2: support for different multipoint, medium-specific bridging > methods. > > For audio, the most obvious bridging method sums all inputs except that of > the party to which the signal is being sent. For video, one can have > continuous presence, most recent speaker, and probably lots of others. > > Issue 3: support for Chair-controlled conferences. > > We most assuredly do not want to develop yet another conference control > protocol. Nevertheless, we must understand conference control and how it > could affect the messaging between the MG and MGC. > > Issue 4: support for T.120 multipoint data conferencing service. > > T.120 assigns roles to individual nodes within a conference network. Can > the MG infer its role from the context cardinality (two-point vs. > multipoint), or is additional information required? > > Meta-issue: where do Megaco's interests stop and those of SG 16 take over? > Are we reaching the stage where some things have to be marked "for further > study", or do we work through all the issues now to make sure our base > solution will cover all needs? > > > Tom Taylor > E-mail: taylor@nortelnetworks.com (internally Tom-PT Taylor) > Tel.: +1 613 765 4167 (internally 395-4167) > This is frequently forwarded to my residence. >