Issues Around Support of Multimedia

Ami Amir amir at RADVISION.RAD.CO.IL
Tue Apr 6 06:15:44 EDT 1999


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 at NORTELNETWORKS.COM]
        Sent:   Tuesday, April 06, 1999 5:00 AM
        To:     ITU-SG16 at 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 at BayNetworks.COM; itu-sg16 at 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 at nortelnetworks.com  (internally Tom-PT Taylor)
        > Tel.: +1 613 765 4167     (internally 395-4167)
        >   This is frequently forwarded to my residence.
        >



More information about the sg16-avd mailing list