Subject: Re: Topology

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 25 Aug 1999 10:34:23 -0400

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 >>