Subject: Re: Topology

From: Brian Rosen <[email-masked]>
Date: Fri, 27 Aug 1999 08:44:51 -0400

You are advocating the current voice-centric topology mechanism as
a property of the context, presumably because you see it as changing
the "star" property that an audio context defines.

I think of this kind of topology (who sees/hears/smells whom) as
a property of a termination:
        Who does this termination see/hear/smell
So I believe that making it a context property is not appropriate.

I think the merits of this particular proposal are debatable.  They
may or may not be appropriate for LI, they may or may not be appropriate
for operator monitoring.  They may or may not be appropriate for
conference bridge services.

Given that there is no consensus, and it is possible to define this
capability as a termination property, can we define a package that
implements this capability and make it optional to implement the package?

If it "proves in", then we will eventually conclude that it should be
mandatory.  Anyone who has placed a bet that it is not the right answer
may have a problem.  If it is supplanted by a better mechanism, those
who have implemented it will have wasted some bits and some time.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, August 26, 1999 10:55 PM
> To: [email-masked]
> Subject: Re: Topology
>
>
> I agree with Mike on that we need to in the protocol today to have a
> mechanism to specify context properties.
>
> It would seem to me that one requirement is enough to add topology to
> H.248. It is easy to do as its a context property. I don't see that
> implementing this destroys the star topology model or anybody's
> implementation of an incomplete H.248 protocol.
>
> With regards to 1 are you proposing a whole new command for every
> gateway? isn't that more of a burden to people's
> implementations that an
> optional context property?
>
> I don't believe in such things as 'it will be OK for a trial
> phase'. The
> H.248/Megaco protocol should fulfill the requirements and be suitable
> for deployed, real and working system. If we can't deploy this then
> there will be no future.
>
> Cheers, Christian G
>
>
> Mike Buckley wrote:
> >
> > Christian,
> >
> > >So far, the only
> > >justification of the topology extension is to permit
> monitoring of some
> > >specific call legs without monitoring the entire call.
> >
> > Please see my earlier postings for other reasons.  The
> points you make below
> > support my arguments that we need to be able to specify
> context properties
> > which would include tolologies as well as mixing
> properties, media conversion
> > propertries etc.  Each of these could be packages/templates
> which may be
> > proprietory in nature.  The protocol need not worry about
> the details of how the
> > combining/conversion works -  just how the streams are
> interconnected to the
> > combining/conversion element.
> >
> > Mike
> >
> > The more I listen to the ongoing debate, the more I believe
> that we should
> > not rush to implement a "topology" extension.  So far, the only
> > justification of the topology extension is to permit
> monitoring of some
> > specific call legs without monitoring the entire call. The other
> > requirements, such as operator, or even basic monitoring of
> an entire call,
> > are in fact fulfilled with the current definition. Rushing to the
> > conclusion that we should implement a "full matrix"
> topology control is
> > premature, because it is not the most natural way to
> implement monitoring
> > of individual streams, and also because we don't know
> whether this is the
> > best way to solve all topology control requirements. For example:
> >
> > 1) Monitoring of individual flows could easily be
> implemented through a
> > specific "duplicate flow" command, that would essentially
> allow us to send
> > a copy of the flow to a separate monitoring context.
> (Another way to think
> > of this is to add the same termination to several
> contexts.) Technologies
> > such as RTP in fact allow to mix several sources on the
> same packet stream
> > while keeping each source well identified. The monitoring
> systems could
> > well profit of this technologies, something that should be
> discussed with
> > law enforcement agencies.
> >
> > 2) There are requirements that do not lend themselves well to matrix
> > description. For example, the mixing of video streams in a
> conference can
> > be achieved by selecting a single source, by incrustation
> of one stream as
> > a small image into a main stream, by mixing 4 or 6 streams
> into a mosaic.
> > Often, the image depends on a participant role, such as
> speaker, leader,
> > last speaker, etc. The matrix approach does not appear as a
> very good fit
> > to the requirement.
> >
> > In short, we have a solution today that implements basic
> monitoring, and is
> > probably enough at least for a trial phase.  We should take
> our time to
> > define the righ solution for both monitoring and topology
> control. We
> > should not obliterate the future with a half-baked proposal.
> > Christian Huitema
>

---

From: Rex Coldren <[email-masked]>
Date: Fri, 27 Aug 1999 08:49:10 -0700

Brian,
   I agree with Christian Groves and others who believe that topology is
a context property.  I'd rather see the topology information centralized
than distributed.  That is, one place describes the topology between T1
and T2 (i.e.-the context) rather than two (i.e.-the terminations).  As the
number of terminations increases, the complexity gets worse if you have
distributed the information.

   And I believe topology should have nothing at all to do with packages.
I guess if you've made the leap that says every termination knows about
every other one you might be able to extend the concept by saying that
this knowledge is a property of the termination.  I can't make that leap.

Rex

---

From: John Segers <[email-masked]>
Date: Fri, 27 Aug 1999 18:20:57 +0200

Adding the topology to descriptors of Terminations has a certain
disadvantage.  If we would allow specifications such as "receive from"
_and_ "send to" we will have to deal with inconsistencies (T1 saying it
sends to T2, while T2 says it only receives from T3).

If only one of the two specifications is allowed, say "receive from",
then adding a send-to-many-listen-to-none Termination requires multiple
commands: one to each of the Terminations that has to receive the new
media stream.

Centralizing it at the Context level doesn't suffer from this.  Any
descriptor making a change to the topology does exactly that.

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 344
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: Mon, 30 Aug 1999 09:45:30 +1000

I don't see how 't1>t2 one way' is particularly voice centric and I
didn't see that the "star" topology was only associated with an audio
context.

I see topology as a way of giving some extra connection information when
the star configuration was not sufficient (in the LI was the example
where it isn't). I don't see it as a property of the termination
because as I understood terminations are a sink/source of data. To
me it seems that the context was the most appropriate place to put the
topology because it added something to the 'star' configuration which a
context implied. Thus from both a modelling and implementation point of
view I see that it is most appropriate to be a context property.

We'll have to implement a method of giving properties to contexts for
mixing and if a topology is optional parameter to a context then as has
been said 'its just some bits and time'.

Cheers, Christian