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

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 8 Sep 1999 08:38:07 -0400

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: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 09:34:58 -0400

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

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 8:38 AM
> To: [email-masked]

---

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

I think it is incumbent on us to do the best we can to
make sure that whatever mechanisms we put are extensible
to cover the foreseeable expansion of capabilities.  This
is a big reason I don't like half done proposals; either
we think through what we really need, or we end up
describing something that won't cover the cases that
come up in the future.

This is the problem I have with, for example, the current topology proposal.
It covers star connected bridges, but what does T1->T2 one way mean when you
have Tom's
video-follows-speaker bridge?

We can never foresee all the things that evolve.  There
clearly will come a time when some folks in the future
try to put something eminently reasonable in and declare
"What were those guys THINKING?!! How could they have
been so dumb to not recognize that --- fill in the blank --
would be required and allowed for it in the protocol?".
We can try, by collective effort, to avoid many such
potholes.  Experience says that such effort doesn't happen
overnight.  That is why I raise the issue of do we need it
now.

I offer no real opinion on the answer.  I offer the observation that we
won't have a protocol this month if
we expand the scope to cover video MCUs.

Brian

> From: Paul Sijben [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 10:20 AM
> 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
>
> Brian Rosen wrote:
> >
> > 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
> >
> > > Sent: Wednesday, September 08, 1999 9:50 AM
> > > 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.
> > >
> > > > 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
> > > >
> --
> 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)
>