The advent of the Internet, with novel facilities such as multicast has led to the separation of the protocols used for conference media streams from the protocols used to setup and control various aspects of a conference, as mentioned above, such as membership, session information, media activity, floor control and so on, as we shall see i nthe next few chapters.
But the usefulness of the IP multicast service has made itself felt in the control protocols too. A number of sites have used multicast as the way to disseminate control information within a conference. Again, as with the media streams, the advantages in terms of scalability are manifold.
Alongside the multicast group used to carry the media themselves, another associated multicast group can be used to disseminate this control information. The model is that of a computer bus, on which messages can be placed, and received by any device attached to the backplane. This Bus Model is used in two related ways:
The Local Bus can also be used to carry out receiver synchronization, If a machine is receiving different media streams with different delay variations that belong in the same session, then the adaptive playout buffer sizes can be exchanged by multicasting their status on the local Mbone (local to the receiver machine only), and used to add in a constant so that all streams are played out in synchronization, with no need for any complex end to end protocol to carry out complex delay bound calculations, as is used in many other systems.
The growth in the Mbone has led to some navigation difficulties (just as there are in the World Wide Web, and in Usenet News Groups). This has led to the creation of a Session Directory Service. This has several functions:
Conference Control [Schooler, 92] refers to the set of tasks concerned with managing the tools that mediate between users. This includes controlling access and membership, controlling starting and stopping media including coordinating this with any floor control mechanism, reporting activity by a user of a given media type, and so on.
Early Conference control systems in the Internet were modeled around telephony and the T.120/T.GCC style of management, where each and every control action is specified for a unique participant, and each and every action is specified to each and every participant. Such systems were targeted at closed, secure, managed, and generally floor controlled (chaired) conferences. Often, the conference control architecture was dictated by the low level network call control model, or even by the media distribution technology (as with MCU based T.120 based videoconference systems).
The Mbone style of conferencing separates out this functionality, but in no way precludes using tight coupling of control actions, participants and media. Indeed, the use of the local and wide area bus model to propagate control actions leads naturally to efficient scaling of all styles of conference. Yet again, we note the user expectation is of potential dynamics in membership, and quality of conferences. This is an advantage over hardwired groups and quality, since it is less constraining to designers of conferencing tools. They can always add constraints later.
The use of a single approach that seemlesslessly scales from small to large systems, from homogeneous, to heterogeneous, and from one style of use to another, is clearly a desirable engineering goal.
In following chapters, we will look at these various technologies.