Subject: Re: Topology

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 24 Aug 1999 00:48:46 -0500

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

---

From: John Segers <[email-masked]>
Date: Tue, 24 Aug 1999 09:42:03 +0200

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

--
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 Groves <[email-masked]>
Date: Tue, 24 Aug 1999 11:24:14 +1000

Whilst you can achieve a one way flow of traffic I still think that you
need some mechanism to be able to describe the topology of a context.
The star configuration is fine for most cases and this is why it is the
default but for other cases you should be able to change it.
That's why I like topology descriptors. Topology descriptors are
something that relates to the context and as such they are general
enough to be used in many scenarios not only Legal Intercept and
Operator Calls. I think defining a termination type ties the termination
to a certain application. In my mind this tying to an application should
be done with Packages rather than a special termination type in the main
protocol.

Christian

---

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

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