Subject: Re: Topology

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 1999 10:17:15 -0400

What does T1>T2 one way mean in a videoconference?
        Does it mean that a mosaic (everyone sees everyone
                else in little windows) is required?
        Suppose T1>T2 one way is set, the video bridge
                is "loudest audio wins video", and T2 is
                talking.  What does T1 see?  What does he
                hear?

What does T1>T2 one way mean to a T.120 shared whiteboard?

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Sunday, August 29, 1999 7:46 PM
> To: [email-masked]
> Subject: Re: Topology
>
>
> 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
>
>
>
> Brian Rosen wrote:
> >
> > 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
> > >
>