Subject: Re: Megaco/H.248 Contexts and Context Parameters

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 10:20:23 -0400

If there is a proposal, let's put it on the table and discuss it.  If it
represents a complete understanding
at the level the rest of the protocol handles simple
audio calls, then we should incorporate it into the
text.  If there are new descriptors introduced to
hold parameters, there should be an extension mechanism
defined, as there is in several other descriptors.

What I don't want to see is a half-done proposal that doesn't stand up to
the expert criticism that has characterized the text that is there now.

We have ruthlessly beat down half answers.  We have
not allowed syntax and text that covers subsets of the problem unless we
have carefully defined the limits of the
subset, and done a thorough job of defining all the mechanisms needed for
that subset.

I have NO problem defining the way we break out of the
star connected context bridging default.  What I have a problem with is not
carefully thinking through what is needed to support, let us say,
straightforward H.323 or SIP video gateways.

Our audio support is not entirely sufficient to define conference bridges.
We explicitly did not cover moderator issues, we only allow simple star
bridges.  If we wish to define the scope of the video bridging to cover end
stations only, I am fine with that.  If we want to cover video MCUs, that is
okay, but we need to cover all the cases of MCUs, and think through what
that means, carefully
define what we will and won't consider, and have a thorough discussion of
the issues.

So then we get to the real question:
        Is this necessary for version 1?
If it is, we need to do it, and do it right.

If it is not, we should NOT do it at all.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 9:50 AM
> To: [email-masked]
> Subject: Re: Megaco/H.248 Contexts and Context Parameters
>
>
> I've already suggested to Abdallah that we could start with a
> couple of
> well-known video bridging algorithm names ("mosaic",
> "currentSpeaker") and
> hope that more get added by our SG 16 colleagues.  The main
> point I was
> discussing with Mike was extensibility beyond the standard algorithms.
>
> > -----Original Message-----
> > From: Brian Rosen [SMTP:[email-masked]]
> > Sent: Wednesday, September 08, 1999 9:35 AM
> > To:   Taylor, Tom-PT [CAR:B901-I:EXCH];
> > [email-masked]
> > Subject:      RE: Megaco/H.248 Contexts and Context Parameters
> >
> > This would be the first and only case where the protocol
> > defined a mechanism, but not the precise syntax.  I think
> > it's a bad idea.  I can see allowing extension parameters
> > (X-), but to define a mechanism and no standard use of it
> > means we have not completed our job.
> >
> > The point of MEGACO is to define interwork between MGs and
> > MGCs.  That means we want one way to do things.
> > If we need to define how video bridging, conference audio,
> > and shared whiteboard is to be done, then we should do
> > that.  If that is not required for the first version of the
> > protocol, then we should not define any unused mechanisms
> > that may or may not be appropriate whenever the real
> > definition of bridging is done.
> >
> > Abdallah and I have reached agreement on how we should
> > structure context parameters.  They will look like
> > commands, but appear before commands.  An example would be:
> > Transaction=<trid> {Context=<cid>{ Bridging=<sid>{..},
> >       Topology{...}, Add=<tid>{....}}}
> >
> > There is no point in actually defining the Bridging syntax
> > until there are known parameters for it.  Adding it when
> > there is a definition is a one line change to the ABNF.
> > The same applies to topology, and any other context
> > parameter.  If we have an acceptable definition of any
> > context parameters, we should include the ABNF for them.
> > If we don't, there should be no mention of them.
> >
> > A real MG that had some notion of bridging parameters would
> > have it's parser able to parse the entire descriptor,
> > whatever the parameters might be.  There is zero gain in
> > defining an empty descriptor.  When we define its contents,
> > we can define its structure.
> >
> > Brian
> >
> >
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > Sent: Wednesday, September 08, 1999 8:38 AM
> > > To: [email-masked]
> > > Subject: Re: Megaco/H.248 Contexts and Context Parameters
> > >
> > >
> > > Abdallah Rayhan is our wizard at constructing regular ABNF
> > > expressions.  I
> > > think he has some good proposals for this.  If I read you
> > > correctly, you
> > > want the ability to add an arbitrary set of parameters within
> > > the confines
> > > of the bridging descriptor, with the MG being able to
> pass over those
> > > parameters it doesn't recognize but successfully parse the rest.
> > >
> > > > -----Original Message-----
> > > > From: Mike Buckley [SMTP:[email-masked]]
> > > > Sent: Wednesday, September 08, 1999 6:23 AM
> > > > To:   [email-masked]
> > > > Subject:      Re: Megaco/H.248 Contexts and Context Parameters
> > > >
> > > > Tom,
> > > >
> > > > Support for individual option parameters would necessarily
> > > be optional eg
> > > > a
> > > > particular mixing property.  What  matters is that the
> > > protocol allows
> > > > parsing of
> > > > the propereties if they are present.
> > > >
> > > > Mike
> > > >
> > > >
> > > > ____________________ Begin Original Message
> > > > ___________________________
> > > > Date: Tue Sep  7 12:30:44 -0500 1999
> > > > From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor)
> > > > Subject: Megaco/H.248 Contexts and Context Parameters
> > > > To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
> > > > Content-Type: Text
> > > > Content-Length: 2940
> > > >
> > > > We have had a long discussion on the Megaco list about
> > > whether the sort of
> > > > topology micro-management proposed in Berlin, with
> > > "Topology" as a context
> > > > property, is really necessary.  I would summarize the
> > > outcome of that
> > > > discussion by saying that we can meet the known
> > > requirements for Legal
> > > > Interception (if a vendor chooses to implement it in the
> > > MG) without the
> > > > proposed Topology property.  However, that property could
> > > allow for some
> > > > value-added capability in a gateway (e.g. the
> difference between the
> > > > subject
> > > > of an operator intervention hearing only the operator and
> > > hearing the
> > > > operator and also the other parties to the call in the
> > > background).  I
> > > > therefore propose this as the consensus resolution: the
> > > Topology property
> > > > will be defined in the protocol, but support is optional
> > > both at the MG
> > > > and
> > > > the MGC.
> > > >
> > > > With this resolution in mind, I propose a change in the
> > > opening paragraph
> > > > of
> > > > section 6.1, "Contexts", of the current draft.  It
> currently reads:
> > > >
> > > > "A Context is an association between a number of
> Terminations.  The
> > > > Context
> > > > describes the topology (who hears/sees whom) and the media
> > > mixing and/or
> > > > switching parameters if more than two Terminations are
> > > involved in the
> > > > association."
> > > >
> > > > I propose instead this more expanded description:
> > > >
> > > > "A Context is an association ... Terminations.  When
> more than two
> > > > Terminations are present in a Context, the Context takes on
> > > the properties
> > > > of a mixing bridge.  The default assumption for audio
> > > streams is that the
> > > > Context serves as an N-1 additive bridge, passing to each
> > > Termination the
> > > > sum of inputs from all other Terminations in the context.
> > > When other
> > > > media
> > > > or other types of mixing are desired, the mixing behaviour
> > > for each stream
> > > > must be stated explicitly as a context parameter.
> > > >
> > > > "By default, the Context is assumed to implement a star
> > > topology with the
> > > > mixing bridge at the centre.  The topology of the media
> > > flows through the
> > > > context is controlled by controlling the flows into and out
> > > of the context
> > > > at the individual Termination level.  The flows between the
> > > Terminations
> > > > and
> > > > the mixing bridge are assumed to be continuations of the
> > > external flows in
> > > > each direction.
> > > >
> > > > "As a value-added option, some MGs may support an alternate
> > > mesh topology
> > > > through the mixing bridge.  To control this, the protocol
> > > provides for a
> > > > Topology property at the context level.  Support of
> this property is
> > > > optional at both the MG and the MGC."
> > > >
> > > > -------------
> > > >
> > > > Following on from that, we need help from the specialists
> > > in Study Group
> > > > 16,
> > > > to create the appropriate syntax, first to describe the bridging
> > > > properties
> > > > and secondly to describe the topology.  I will remind
> > > people proposing the
> > > > syntax that the bridging behaviour will generally be
> > > different for each
> > > > medium, and hence must be tied to the StreamID.
> > > >
> > > > Tom Taylor
> > > > Advisor -- IPConnect Standards
> > > > E-mail: [email-masked] (internally, Tom-PT Taylor)
> > > > Phone and FAX: +1 613 736 0961
> > >
>

---

From: Paul Sijben <[email-masked]>
Date: Wed, 8 Sep 1999 16:19:56 +0200

Brian,

I agree with your line of thinking. There is one additional requirement:
Does putting in something now preclude future extentions. We all have our
favirite future applications, so we can not say that we can not foresee
extentions.  But we cannot drop things that are in v1 when we get to v2.
This is a requirement on all ITU standards which we need to stick to.

Paul

--
Paul Sijben              Tel:+31 35 687 4774
Lucent Technologies      Fax:+31 35 687 5954
Forward Looking Work     mailto:[email-masked]
Huizen, The Netherlands  http://voip.nl.lucent.com/sijben (internal)