Subject: Re: Topology

From: Mike Buckley <[email-masked]>
Date: Thu, 26 Aug 1999 14:36:12 +0000

>As for intermedia conversions, we already have that through use of the
>StreamID mechanism -- we specify conversion between voice at one termination
>and text at another by giving them both the same StreamID value.

Yes, but how would you specify the properties of the conversion device?  This is
the same problems as the mixing properties of a bridge or any other operation
you might wish to perform on a media stream or group of media streams.  Your
simple connection argument is fine provide these operations are trivial or their
nature can be taken as given.  I don't think we should rule out the possibilities
of having to specify these at this stage in the design of the protocol.  All I am
arguing for is a consistent and logical MEGACO framework capable of future
extension.

Mike

____________________ Begin Original Message
___________________________
Date: Wed Aug 25 10:34:23 -0400 1999
From: internet!nortelnetworks.com!taylor (Tom-PT Taylor)
Subject: RE: Topology
To: !mikebuckley (Mike Buckley)
To: internet!standards.nortelnetworks.com!megaco
Content-Type: Text
Content-Length: 3871

I've argued on essentially algebraic grounds (e.g. more compact notation)
that it's better to set topology by manipulating the bridge taps
individually than specifying a matrix at the context level.  If you want to
argue from modelling principle that this is invalid I can't argue with you.
This is not a particularly significant matter either way, given the tiny
number of wiretaps which occur in practice.

As for intermedia conversions, we already have that through use of the
StreamID mechanism -- we specify conversion between voice at one termination
and text at another by giving them both the same StreamID value.

> -----Original Message-----
> From: Mike Buckley [SMTP:[email-masked]]
> Sent: Tuesday, August 24, 1999 1:25 PM
> To:   [email-masked]
> Subject:      Re: Topology
>
> Tom,
>
> I would prefer to see some clear distinctions between the role of a
> Context and a
> Termination. I think we came up with some general understandings on this
> in the
> past.  i.e. Terminations relate to the properties of information flows to
> the outside
> world and Contexts the way in which these information flows are linked
> together.
>
> I think it follows that:
>
> *   Any connectivity between Terminations should be a Context property,
>
> *   Bridging and Mixing Functionality should be a Context property,
>
> We may need to define parameters associated with a Context which enable
> the
> full range of multimedia interconnectivity (eg text to speech), bridging
> and mixing
> functionality as well as connectivity topology to be specified.
>
> Let's keep the distinction between Terminations and Context very clear.
>
> Mike
>
>
>
> ____________________ Begin Original Message
> ___________________________
> Date: Tue Aug 24 00:48:46 -0500 1999
> From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor)
> Subject: Re: Topology
> To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
> Content-Type: Text
> Content-Length: 1702
>
> I guess the requirement is clear: to be able to receive from and possibly
> send to selected terminations only.
>
> I would suggest that making this a context property is consistent with a
> view of the context as a bridge which you want to control, but may not be
> the most efficient way to do the job syntactically.  In fact, in all cases
> you want to give special treatment to one termination only: the wiretap or
> the operator position, as the case may be.  It seems much more efficient
> to
> define a special termination type like our MUX termination type, only this
> one has as properties the list of terminations it will receive from and
> terminations it will send to within the same context.  The activity
> parameter in LocalControl then controls its relationship to the user
> connected to it: in the wiretap case that will be sendonly, while in the
> operator case it will be sendreceive.
>
> > -----Original Message-----
> > From: Stephen Terrill [SMTP:[email-masked]]
> > Sent: Monday, August 23, 1999 7:34 PM
> > To:   [email-masked]
> > Subject:      Re: Topology
> >
> > > Regardless of whether this is a good idea or not, you can definitely
> > > install a one way intercept using the termination mode. Add to the
> > context
> > > a termination that feeds to the intercept, and set the termination
> mode
> > to
> > > "send only."
> > > Christian Huitema
> >
> >
> > Hi Christian,
> >
> > Unfortunately this approach does not meet all the requirements.  In a
> > multiparty call (conference etc), it must be possible to monitor a
> single
> > stream from an idetified termination.  That does not work when just
> using
> > the mode of the termination.
> >
> > Regards,
> >
> > ..//Steve << File: RTF attachment, source: Text_1 >>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Aug 1999 12:02:31 -0400

The more I listen to the ongoing debate, the more I believe that we should
not rush to implement a "topology" extension.  So far, the only
justification of the topology extension is to permit monitoring of some
specific call legs without monitoring the entire call. The other
requirements, such as operator, or even basic monitoring of an entire call,
are in fact fulfilled with the current definition. Rushing to the
conclusion that we should implement a "full matrix" topology control is
premature, because it is not the most natural way to implement monitoring
of individual streams, and also because we don't know whether this is the
best way to solve all topology control requirements. For example:

1) Monitoring of individual flows could easily be implemented through a
specific "duplicate flow" command, that would essentially allow us to send
a copy of the flow to a separate monitoring context. (Another way to think
of this is to add the same termination to several contexts.) Technologies
such as RTP in fact allow to mix several sources on the same packet stream
while keeping each source well identified. The monitoring systems could
well profit of this technologies, something that should be discussed with
law enforcement agencies.

2) There are requirements that do not lend themselves well to matrix
description. For example, the mixing of video streams in a conference can
be achieved by selecting a single source, by incrustation of one stream as
a small image into a main stream, by mixing 4 or 6 streams into a mosaic.
Often, the image depends on a participant role, such as speaker, leader,
last speaker, etc. The matrix approach does not appear as a very good fit
to the requirement.

In short, we have a solution today that implements basic monitoring, and is
probably enough at least for a trial phase.  We should take our time to
define the righ solution for both monitoring and topology control. We
should not obliterate the future with a half-baked proposal.
Christian Huitema