Subject: Re: Topology

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

Perhaps it wasn't clear, but I was making a protocol proposal, not
describing internal representation.  I'm saying the logical level of
topology description should be at the termination rather than context level
because it gives a more compact notation in the messages the MGC sends to
the MG.  When I was talking about matrix and sparse matrix, I was talking
about how the topology descriptor would look in a Megaco message.

As far as conflict is concerned, it is up to each termination to determine
what it will receive (to anthropomorphize a bit) -- that means that in the
strange case you're talking about, where presumably one of the selectors
enables a wiretap and the other an operator position, both present on the
same call, the legal requirements of the wiretap would be met.

> -----Original Message-----
> From: John Segers [SMTP:[email-masked]]
> Sent: Tuesday, August 24, 1999 10:37 AM
> To:   Taylor, Tom-PT [CAR:B901-I:EXCH]
> Cc:   [email-masked]
> Subject:      Re: Topology
>
> 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
>
> Tom-PT Taylor wrote:
> >
> > 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
>
> --
> 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