Thanks for a good summary of the work.
As a matter of principle, as well as from a company point of view, you know
I cannot accept backward compatibility with past MGCP drafts as a
requirement. I hope the
MEGACO group can be made to see that backward compatibility is unfair to
all the
companies (like mine) that implmented IPDC or whatever rather than some
draft of
MGCP.
Dale
At 07:54 AM 5/28/99 -0400, you wrote:
>If the partnership between Megaco and Study Group 16 is to work, I need to
>provide you with a detailed and honest description of the implications of
>the Santiago results, so you can decide for yourselves whether we are moving
>in the right direction.
>
>The latest H.GCP draft records three changes from the current Megaco draft.
>One is the idea of what I will describe as the multiplane context. Another
>is the idea of multiplex termination classes, on the packet as well as the
>circuit side. The third is a list of most of the currently-known
>termination attributes, grouped on a per-termination, per-plane, and
>per-directed-media-flow basis as applicable. In addition, the idea of a
>syntax for termination descriptors which expresses them as a termination
>class (or template) ID plus a set of delta values was not recorded, but is
>very interesting for the way it supports either SDP or H.245 signalling
>between MGCs. I will explain each of these proposals in technical detail
>below, followed by an assessment of their implications.
>
>First, an explanation of the multiplane (AKA multimedia) context. The first
>part of the idea is that a single context is used to express all of the
>media flow connections between a given set of terminations within the same
>MG. Conceptually this context is equivalent to a stacked set of monomedia
>contexts, but frees us from the need to represent the same termination in
>multiple contexts and simplifies expression of lip-synch and other
>inter-plane relationships. Conceptually also, the context provides one
>bridge/mixer for each plane it contains, and the mode of bridge
>operation/mixing has to be specified for each plane. The planeID can be an
>optional parameter, and can certainly be omitted in the simple audio case.
>Similarly the mixing type can be omitted in the simple audio case, as it is
>in the current Megaco draft.
>
>For each termination in a multiplane context, the following has to be
>specified in the most general case:
>* the base termination attributes (which are by definition independent
>of the media flows that termination currently supports)
>* attributes which are needed to describe it in each plane in which it
>participates, but which are common to both directions of media flow
>* attributes which are unique to a particular direction of media flow
>within a given plane.
>In the simple audio case this degenerates into the current organization of
>common attributes (TerminalState) plus per-flow-direction attributes
>(LTDescriptor and RTDescriptor).
>
>The positive aspect of the multiplane context is that this offers a
>marvellously flexible tool for expressing pretty well anything we need to,
>regarding multipoint, multimedia conferencing within a single MG. It has
>benefits even if we are talking only about audio: I could describe to you
>how to apply it to support a main conference plus side-conferences between
>subsets of participants, all within a single context. The negative aspect
>of this proposal is that it forces, even in the audio case, at least a minor
>rearrangement of termination attributes. In particular, for multiplane
>contexts to be effective, the send-receive aspect has to be extracted from
>the current Mode parameter and stated on a per-plane rather than a
>per-termination basis. Moreover, the current breakout of terminal
>descriptors in our commands into terminal state, LTDescriptor, and
>RTDescriptor parts has to be augmented (for conciseness) by a
>planeDescriptor part. This is not essential: the planeDescriptor could also
>be distributed into both the LTDescriptor and the RTDescriptor parts.
>
>Next, the idea of multiplex termination classes has already been described
>in previous discussions of H.320 operation. The basic idea as developed in
>Santiago is that the termination descriptor includes a multiplex type
>attribute. For a circuit-side multiplex, the common terminal parameter set
>includes a list of the individual circuits included in the multiplex. The
>idea of packet-side multiplexes was introduced for two reasons: to provide a
>simple and implicit way to indicate synchronization requirements between
>media flows relating to the same user, and to accommodate the need for
>control channel interworking in the H.320-to-H.323 case. The syntax for
>relating individual packet streams to the multiplex of which they are a part
>is natural and implicit in the listing of per-directed-media-flow components
>of the multiplex termination description. With the control channels comes
>the need for unique event packages to support them.
>
>As already stated, the idea of multiplex termination classes on both the
>packet and the circuit side solves the H.320/H.324 multilink problem. It
>also allows all media flows relating to a given user session to be grouped
>in a natural way so that relationships such as lip-synch can be easily
>expressed. further, it provides a way to relate an H.245 control channel
>terminating in the MG (because of interworking with H.320/H.324) to the
>video flows for which that channel will carry commands and indications. The
>negative side of this must be the need to extend our repertoire of
>termination classes and attributes -- not, I believe, a significant
>consideration in our decision to adopt the idea, since support of the
>mechanism is not required for simple audio operation.
>
>The tabulation of individual termination attributes and their grouping on a
>per-termination, per-plane, and per-directed-media-flow basis is the
>scariest part of the whole exercise. I will provide that tabulation in a
>separate message. The positive aspects of this work are that it detaches
>the discussion of termination attribute syntax from the H.245/SDP debate,
>and it allows a careful analysis of how we have to organize the content of
>our protocol. It also provides a starting point for rapid development of
>the detailed description of termination classes, to the extent that the
>descriptions in the current Megaco draft need to be fleshed out. The
>negative aspect is that it puts the current description of command
>parameters into jeopardy and potentially sets back any parser development
>which has been carried out based on the "unreviewed" portion of the current
>Megaco draft. We also have to resist the impression that the list of
>attributes is now closed; it should remain extensible to accommodate the
>definition of new termination classes, even if the basic logical
>organization remains unchanged.
>
>Finally, there is the idea of using thermination classIDs to carry major
>amounts of information. The basic concept is that our termination classes
>would be and their associated classIDs would be standardized and registered.
>Each termination class would imply a list of attributes, ranges of values
>for those attributes, a list of supported event packages, and a set of
>default attribute values (which could include a list of which event packages
>are active upon instantiation of a member of the class). Because the
>classes are standardized, the classID by itself can carry a lot of
>information between the MG and MGC.
>
>The idea of transmitting termination descriptors as the combination of a
>classID (which connotes a predefined attribute list and a bunch of preset
>default values) and a delta list of attribute values has several benefits.
>The most obvious is more compact expression of termination descriptors in
>the most common cases. Secondly, it is a means to make MG-MGC signalling
>independent of MGC-MGC signalling: the MGC can carry pre-coded templates in
>its favourite language, to which it can add the delta attribute values
>before sending the whole thing off to the other end. Even more radically,
>MGC-MGC signalling could itself carry the classIDs and deltas, but that is a
>topic for another discussion. The negatives of this proposal are the
>evident impact on command syntax in the current draft, plus the need to have
>a way to provide unique identification of every attribute which could appear
>in a delta list (including an indication of which plane and which flow
>direction it applies to, as applicable).
>
>Well, that's the story. Now we need a political debate on whether the
>relationship with SG 16 is workable based on the fruits of the meeting just
>concluding, and a technical debate on the merits of each of the proposals I
>have outlined. I'm sure you are aware that the two debates are
>inter-related, in that SG 16 will feel let down if we reject their proposals
>for grounds other than technical inadequacy (e.g. because some of us are
>already committed to parsers based on the current Megaco draft). I've
>stated the situation honestly, I hope, and I also hope that you find that
>good things were done in Santiago. Let the discussion begin.
>
>Tom Taylor
>E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor)
>Tel.: +1 613 736 0961 (ESN 396-1490)
>FAX: same number by prior arrangement (manual answer).
>
