Subject: Re: Topology

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 25 Aug 1999 09:36:26 -0500

I absolutely agree that we have to have context-level mixing parameters for
each streamID value, although audio would presumably default to N-1
addition.

> -----Original Message-----
> From: [email-masked] [SMTP:[email-masked]]
> Sent: Tuesday, August 24, 1999 1:31 PM
> To:   Taylor, Tom-PT [CAR:B901-I:EXCH];
> [email-masked]
> Subject:      RE: Topology
>
> I am not suggesting all the individual connections need to be specified
> each time
> a call is set up.  [[TomT]]  ...
> Without some form of Context parameters I don't see how video mixing
> properties
> can adequately be specified (eg switch between speakers or display all
> conference participants, zoom in etc etc.) or how text to speech
> conversion
> might be handled.
>
> Mike
>
> ____________________ Begin Original Message
> ___________________________
> Date: Tue Aug 24 10:09:45 -0400 1999
> From: internet!nortelnetworks.com!taylor (Tom-PT Taylor)
> Subject: RE: Topology
> To: !mikebuckley
> Content-Type: Text
> Content-Length: 3649
>
> The problem with this is that you run into the n-squared problem -- you
> have
> to specify a complete matrix to say what is going on amongst all the
> terminations.  This just isn't necessary -- most of the time you'll have
> the
> usual behaviour where all broadcast to all.  Can't you think of my
> SELector
> termination (I've thought up a name for it) as a way to manipulate a
> specific tap on the bridge?
>
> > -----Original Message-----
> > From:       [email-masked] [SMTP:[email-masked]]
> > Sent:       Tuesday, August 24, 1999 5:55 AM
> > To: Taylor, Tom-PT [CAR:B901-I:EXCH]
> > 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: Mike Buckley <[email-masked]>
Date: Thu, 26 Aug 1999 00:12:09 +0000

The mixing may not be a function of each stream alone.  e.g. don't transcode if
only one person is speaking (with vocodersmixing requires transcoding ) - only
transcode for simultaneous speakers.  Some audio bridges work like this.  We
should not presuppose the nature of the mixing in the design of the protocol nor
limit what is possible.  We can default to as simple scheme but we need to keep
extensibility and that requires a means of specifying the mixing properties of the
context. These could also be manufacturer specific so the method also needs to
be capable of specifying non-standard parameters.

Mike

____________________ Begin Original Message
___________________________
Date: Wed Aug 25 09:36:26 -0500 1999
From: internet!nortelnetworks.com!taylor (Tom-PT Taylor)
Subject: RE: Topology
To: !mikebuckley
To: internet!standards.nortelnetworks.com!megaco
Content-Type: Generic-Text
Content-Length: 4949