Subject: Re: Topology

From: Mike Buckley <[email-masked]>
Date: Thu, 26 Aug 1999 17:45:15 +0000

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: Christian Groves <[email-masked]>
Date: Fri, 27 Aug 1999 12:55:07 +1000

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 anybodies
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