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