Subject: Megaco/H.248 Contexts and Context Parameters

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 7 Sep 1999 12:30:44 -0500

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: Mike Buckley <[email-masked]>
Date: Wed, 8 Sep 1999 10:22:43 +0000

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

-------------

Tom Taylor

---

From: Christian Groves <[email-masked]>
Date: Mon, 13 Sep 1999 11:20:20 +1000

G'Day Tom,

I think that your proposal is a good one and a positive way of moving
forward. Brian's and Abdallah's ABNF proposal is good as it shows that a
context may have properties.

From the other emails in this thread I see there's some discussion of
formats for the topology and bridging parameters. I think we should add
the topology descriptors from the Berlin meeting and if people want
changes then they can contribute to the SG16 meeting. This  will put it
in the document and give people a chance to review it and come up with
comments.

As we've seen nothing on bridging parameters I'm happy to leave them out
until people make a contribution on them.

I've cross posted this to SG16 so that MCU/bridging people are aware
that bridging properties are discussed.

Cheers, Christian