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.


        -----Original Message-----
        From:   Fernando Cuervo [SMTP:cuervo at NORTELNETWORKS.COM]
        Sent:   Tuesday, April 06, 1999 5:00 AM
        To:     ITU-SG16 at
        Subject:        Re: Issues Around Support of Multimedia


        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
        could be possible by having one or more "reasonable" proposals to
        Context "behaviour" and sychronisation between contexts but not
        reaching an agreement on the "best" way to do it)

        > ----------
        > From:         Taylor, Tom-PT [CAR:5V00-I:EXCH]
        > Sent:         April 5, 1999 12:09 PM
        > To:   megaco at BayNetworks.COM; itu-sg16 at
        > Subject:      Issues Around Support of Multimedia
        > I have suggested some directions for exploration of solutions to
        > 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
        > 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
        > represent envelopes within which different topologies will be
        > depending on the mode settings for the associated terminations.
        > Requirements:
        >   a) Coordinate between different media streams (e.g. for
        > stereo).
        >   b) Represent degenerate cases simply (e.g. audio-only
        > two-point connections).
        >   c) Support multicast.
        > Issue 2: support for different multipoint, medium-specific
        > 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
        > continuous presence, most recent speaker, and probably lots of
        > Issue 3: support for Chair-controlled conferences.
        > We most assuredly do not want to develop yet another conference
        > 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
        > study", or do we work through all the issues now to make sure our
        > solution will cover all needs?
        > Tom Taylor
        > E-mail: taylor at  (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