Megaco/H.248 Contexts and Context Parameters

[Christian Groves]

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

Tom-PT Taylor wrote:
>
> 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: taylor at nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961