Subject: RE: Topology and video conferencing

From: "Even ,Roni" <[email-masked]>
Date: Tue, 17 Jul 2001 13:39:55 +0200

Christian,

The first issue is that MPs can have different video capabilities. The can
mix 4 streams, they can mix up to 9 streams, the can mix by combining 4 qcif
images to cif images which involves asymmetric communication or they can
only mix. An MP can support any combination of the above. The MP may lose
some of the functionality due to module on maintenance. This can be defined
in a package. The question is if we have a package defining the mixing
parameters that is supported as a context attribute how do the mp signal the
mc that it support it, how many it support and if their status changed.

Regards
Roni Even

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, July 16, 2001 5:42 AM
To: Even ,Roni
Cc: 'Dan Elbert'; [email-masked]
Subject: Re: Topology and video conferencing

G'Day Roni,

Can you give a bit of an explanation why you want signals and events
added to operate on the context?

Cheers, Christian

"Even ,Roni" wrote:
> 
> Hi,
> I submitted a contribution at the last ITU meeting about a profile for MCU
> decomposition that included a mixer termination. The reason was to support
> the media handling. Christian has suggested to use version 2 feature of
> context properties with packages. The problem is that the context can only
> support the package parameters and cannot support events. There is also
> problem with letting the MGC (MC) know what mixing capabilities the MP
has.
> I think that there are two roads we can take. one is to change H.248 and
> expand the context properties enabling a context to send signal and use
> events. The other is to add a mixer termination like my contribution.
> Regards
> Roni even
> 
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 3:23 AM
> To: 'Dan Elbert'
> Cc: [email-masked]
> Subject: Re: Topology and video conferencing
> 
> G'Day Dan,
> 
> I think several approaches are needed to fully specify video
> conferencing and  conference control. I agree with Brian that some
> packages are needed. Things like floor control specification come to
> mind. But other things such as updates to Context Properties to enable
> the specification of mixing parameters are also needed. H.248v2 already
> incorporates a mechanism for the specification of context properties
> through the use of packages.
> 
> Regards, Christian
> 
> "Rosen, Brian" wrote:
> >
> > I've never appreciated topology.
> >
> > I think we should make a package for conference bridges.
> > That would allow us to have all the controls we needed.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Dan Elbert [mailto:[email-masked]]
> > > Sent: Wednesday, July 11, 2001 3:56 PM
> > > To: [email-masked]
> > > Subject: Topology and video conferencing
> > >
> > >
> > >
> > >
> > > Hi
> > >
> > > What would be the best way to control the topology of the
> > > connections for a
> > > video conferencing scenario? Megaco topology descriptor
> > > controls allows
> > > topology control only at the termination level and not at the
> > > level of a
> > > particular media stream, so if we have both video and audio
> > > streams and the
> > > topology for them is different, we have a potential problem.
> > > One way to
> > > solve this may be to use different ephemeral terminations for
> > > the video
> > > stream and for the audio stream, but then we lose the
> > > synchronization. Any
> > > ideas ?
> > >
> > > Dan Elbert
> > > Radvision
> > >

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Jul 2001 12:07:18 +1000

Hello Roni,

I think we are mixing the term, "signal". I agree with you that MPs can
handle different streams etc and that if some functionality its lost in
the MG it should signal ie. Notify or ServiceChange to the MGC.

However in your original email you stated that we needed signals and
events on contexts. This is what I am questioning the need for. If you
loose functionality this is typically sent up in a servicechange, you
wouldn't set an event. I don't see why we would need a signal on a
context.

You can today audit the MG to determine what values are supported for
context attributes. I am currently writing a contribution clarifying its
use for Context Attributes defined by a package. My initial thinking is
to add a new code point to indicate that the MG should return the
Packages which define context attributes. If you do this for Context=ALL
then you get ALL the packages on the MG that have context attributes.
AuditCapability will also be added to find out the possible values for
context attributes.

Cheers, Christian