Subject: [Megaco] [Fwd: Re: Topology and video conferencing]

From: Christian Groves <[email-masked]>
Date: Fri, 24 Aug 2001 15:03:07 +1000

Subject: Re: Topology and video conferencing
Date: Fri, 24 Aug 2001 13:21:36 +1000
From: Christian Groves <[email-masked]>
To: Tom-PT Taylor <[email-masked]>
CC: "Even ,Roni" <[email-masked]>,'Dan Elbert'
<[email-masked]>, [email-masked]
References:
<[email-masked]>

G'Day Tom,

The ServiceChange can have a reason "xxx Descriptor Failure" which
essentially means that something in the descriptor has caused a failure.
For example Media Descriptor Failure means that something in the media
descriptor, say codec has failed. The MGC can then audit to find out if
the capabilities have changed, this might show that GSM coding is no
longer available.

Cheers, 
Christian

Tom-PT Taylor wrote:
> 
> What do you mean by "descriptor failure"?
> 
> My favoured approach for bulk resource status monitoring is to define
> logical terminations representing the bulk resources (e.g. network
> interfaces), then do a ServiceChange on the logical termination
> affected.
> 
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2001 11:33 PM
> To: Even ,Roni
> Cc: 'Dan Elbert'; [email-masked]
> Subject: Re: Topology and video conferencing
> 
> G'Day Roni,
> 
> You are correct about the service change that it is based on
> terminations. However for the case where someone rips out your "mixer
> card" its quite acceptable for TID=root to report a descriptor
> failure.
> The MGC can then audit to find out what went wrong. ie. context audit.
> 
> For the terminations involved in a conference that were using this
> card
> they can also servicechange a descriptor failure. The MGC could then
> audit the specific context to find out what went wrong.
> 
> No need for change in architecture - just an additional servicechange
> reason : Context Attribute Capability failure
> 
> Christian
> 
> "Even ,Roni" wrote:
> >
> > Christian,
> > I think that service change specifies terminations and not context
> level
> > packages. So there is a need for changing H.248 architecture. The
> question
> > is if that is the right direction or is it to have a mixer as
> termination.
> > That is the question I also raised during the ITU meeting and if we
> decide
> > on this issue we can continue from there and have a solution.
> > I personally prefer to have a termination for mixing. Changing H.248
> will be
> > version 3 and may be too long.
> > As for topology descriptor, the discussion about fan out shows
> another
> > problem with the default mode of the topology and the issue of
> having to
> > specify the topology of all termination in the context specified for
> each
> > change complicate the problem. Having stream ID will just solve one
> problem.
> > I would also use the mixer termination parameters to define the
> conference
> > topology and not by using the topology descriptor.
> > Roni Even
> >
> > -----Original Message-----
> > From: Christian Groves [mailto:[email-masked]]
> > Sent: Wednesday, July 18, 2001 4:07 AM
> > To: Even ,Roni
> > Cc: 'Dan Elbert'; [email-masked]
> > Subject: Re: Topology and video conferencing
> >
> > 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
> >
> > "Even ,Roni" wrote:
> > >
> > > 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
> > > > > >

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco