Subject: Re: Topology

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 24 Aug 1999 10:22:00 -0400

I've thought of a name for my new properties: a SELector descriptor.  We may
not even need a new termination type to support it.  Think of it as
modelling a particular tap on the bridge.

If you put the topology at the context level, you have to specify a complete
connectivity matrix.  Most of the time (999999 calls out of  1000000), this
will default to full connectivity, so the sensible approach would be to use
a sparse matrix representation: a sequence of (source terminationId,
destination terminationId) pairs indicating the blocked paths.  You will get
some repetition of terminationIDs, because the special termination will
appear multiple times.  You can't always assume it is the destination,
because that doesn't cover the operator case.

If you put the topology at the termination level, then for the special
termination only you list the terminations it will receive from and those
that it will transmit to.  In the wiretap case, no redundancy.  In the
operator case, the same termination in both lists.  I think you save in both
cases over the matrix approach.

> -----Original Message-----
> From: John Segers [SMTP:[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: John Segers <[email-masked]>
Date: Tue, 24 Aug 1999 16:37:10 +0200

Tom,

The topology descriptor at the context level describes how the messages
look.   The MG somehow has to store information about which audio
streams to mix and to which termination(s) the mixed stream(s) go if it
receives a change of topology.

You propose to do this by making one row or column of the matrix
explicit at a special Termination.  The others are implicitly set to
"receive from all".  The proposal from Ericsson did not prescribe how
the MG should represent the topology information.  I feel this is the
right thing to do: the protocol only specifies the messages, and as
little as possible about the information conveyed by the messages.

Going into the details of your proposal, how do you guarantee that
information is consistent if there are multiple "special" Terminations
in a Context?  For instance, Termination A's selector descriptor could
specify that it sends to B, while Termination B's selector descriptor
could say that it only wants to receive from C.

John