Subject: Re: Topology

From: Brian Rosen <[email-masked]>
Date: Tue, 24 Aug 1999 13:33:15 -0400

Lots of ideas on this thread.

I personally don't like the complexity of the whole idea, but I don't
think fighting it is worthwhile.

The simplest syntax is a topology descriptor legal in an Add/Move/Modify.
The "TerminationA" is the TerminationID in the command.  The descriptor has
the other TerminationID (TerminationB) and the topology keyword.

Is that good enough?

Brian

> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Tuesday, August 24, 1999 3:42 AM
> To: [email-masked]
> Subject: Re: Topology
>
>
> Tom,
>
> Your proposal puts the complexity in a different place.  If
> we adopt it,
> we'll have to invent some kind of descriptor that a Termination may
> optionally have.  New syntax is needed for that.
>
> Furthermore, if someone has an application in which there is more than
> one Termination that has to receive special treatment, you'll see more
> Terminations with such a descriptor, effectively implementing the
> topology in a more or less invisible way.  Consider for instance the
> case that one person in a call is being monitored and the other person
> has to receive an operator announcement.
>
> I suggest that having the topology descriptor is a better
> mechanism.  As
> you point out yoursel, it is the context that can be viewed as the
> bridge.
>
> John
>
> Tom-PT Taylor wrote:
> >
> > 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
>
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 Aug 1999 13:44:27 -0400

>think fighting it is worthwhile.

Neither do I.  We are going from a complexity of 0(N) (star with per
termination mode) to 0(N^2) (arbitrary reception matrix), or maybe even
worse. I don't see why we should impose such complexity to all
configurations.  At a minimum, we ought to define an error code mentioning
that the topology extension is not supported.

>the other TerminationID (TerminationB) and the topology keyword.

I think we actually need two topology attributes:

1) a list of terminations that the command's termination listens to.
Default is "all" in the star system; can be overriden by setting the mode
to "receive only", in which case the termination will not hear anything.

2) a list of terminations that the command's termination sends to. Default
is "all" in the star system; can be overriden by setting the mode to "send
only", in which case the termination will not be heard by anyone.

Another way would be to have just one list, and then an optional mode per
termination in the list.
Christian Huitema