Subject: Re: Topology

From: Mike Buckley <[email-masked]>
Date: Tue, 24 Aug 1999 17:31:11 +0000

I am not suggesting all the individual connections need to be specified each time
a call is set up.  The assumption before was that the star configuration was the
default.  This is fine.  An alternative way of looking at this is that  this and other
commonly occurring topologies could be specified as templates.  The star
configuration could then be the default templete.  If necessary Parameters could
be defined to express deltas wrt these templates.

I agree with you in that any manipulations of flows on a particular Termination
can be handled as operations on that Termination as long as they only effect that
Termination and no others.

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: Stephen Terrill <[email-masked]>
Date: Wed, 25 Aug 1999 15:37:12 +0200

Hi All,

I think that Mikes suggestion (separating the context handling and the termination handling) has some sence here, it a rather clean solution).  It allows for a separation of the problems, and a logical split of functionality for both the MGC and MG.

I read that there is some concern expressed about the "n*squared problem", is this a real problem or theotical, I see that there are some clever ways to restrict this problem - especially since the MGC is more likely to run out of steam before the MG runs out of memory.

..//Steve