Subject: RE: Topology and video conferencing

From: "Even ,Roni" <[email-masked]>
Date: Wed, 18 Jul 2001 11:23:24 +0200

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

---

From: "Sarju Garg" <[email-masked]>
Date: Wed, 18 Jul 2001 16:28:07 +0530

Hi all,

Are there any available documents that lists down the test cases to test
parser implementations?. I need to check whether our SDP parser for MEGACO
is correct or not. Same for MEGACO parser.

SDP parser for MEGACO allow use of CHOOSE or alternatives in place of single
parameter value. I think MGC will use CHOSE or alternative value for
parameter which are allocated by MG like port number. Is there a list which
says that the MGC can specify CHOOSE or alternative value for these
parameters only. Just to cross check my implementation. Also use of
alternative means alternative values in the list, ranges, greater than/less
than single value or something else? Can somebody define how to encode
alternatives? I think we use the grammar for alternativeValue given in Annex
B.

alternativeValue= ( VALUE
    / LSBRKT VALUE *(COMMA VALUE) RSBRKT
                         ; sublist (i.e. A AND B AND ...)
          / LBRKT VALUE *(COMMA VALUE) RBRKT
         ; alternatives (i.e. A OR B OR ...)

    /  LSBRKT VALUE COLON VALUE RSBRKT )
     ; range

where format for value will depend on  the parameter value.

TIA
Sarju

---

From: Christian Groves <[email-masked]>
Date: Thu, 19 Jul 2001 13:33:13 +1000

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