Previous: Conference Control
Up: Conference Multiplexing and Management Centre (CMMC)
Previous Page: Conference Control
Next Page: Infrastructure
Where a conference uses hardware codecs (whether at the CMMC or at remote sites), some form of resource allocation is required to ensure that each codec produces video of a format and data rate the receiver(s) can decode. Where codecs communicate with each other over serial lines, the H.320 suite of protocols (H.221, H.230, H.242) ensure that upgrades from a base (audio only) service are negotiated. Where such codecs communicate over packet networks, these protocols are inappropriate, and are either stripped off, or not added in the first place. Thus, codec configuration must be controlled out of band.
Such codec configuration is best performed in the light of knowledge about the interconnecting networks, with access to network management (QOS reservation) where available, and with access to data about all the other proposed participants in the conference. Such information and services will eventually be provided by the CMMC's resource allocation functionality. Most importantly (from the point of view of the CMMC), resources such as codecs within the CMMC will be limited, so it is important to provide booking facilities to ensure that a pre-arranged conference will have the facilities it requires.
It is, of course, important that impromptu conferences can also take place, but this can be done by allowing ad-hoc bookings providing the facilities required are available. This places certain requirements on the timeliness of conference booking data, and on the ability to reconfigure conferences that are underway. We may, for instance, be using a particular codec to communicate with a remote site over a packet network, when another user attempts to join the conference over ISDN. Some of the high quality codecs would be our first choice for either network, but our only choice for ISDN, and thus a re-configuration and change of codec for the original user are our only option if we are not to refuse access to the ISDN user. If the conference had been pre-booked this occurrence would have been avoided, and indeed an impromptu conference would be locked out rather than trigger a reconfiguration of a pre-booked conference which is underway.
When performing such resource allocation, we use a concept of minimum acceptable quality. Users specify a minimum quality of service (in terms of bandwidth, CIF vs QCIF, and various other parameters), and if those parameters and those of any other pre-booked conference cannot be met, the booking is refused. If spare capacity is available, the user may find that when the conference takes place, the quality of service is actually better than specified, but those factors under the control of the CMMC will not be worse than requested.
Many factors, such as packet loss on unreserved internet links, will, of course, be outside the control of the CMMC. The CMMC will keep statistics about performance of these links, which can be used in the future to ensure that bookings are only made which are likely to give acceptable performance.
Many of the functions do not need to be centralised, and it is planned that the CMMC be replicated eventually. Which functions can be replicated, and how CMMCs should interact, is currently investigated. One activity which will clearly be replicated is that of audio relay; we expect that there will be a deployment of facilities which can perform this function attached to, or as part of, many of the National networks.