Multimedia Conferencing

    The typical media ingredients of a multimedia conference, as part of computer supported cooperative work, include audio, video, and perhaps a shared whiteboard or similar. These media each need specific treatment:

• The intelligibility of digitised audio is very sensitive to missing samples and playout jitter. A bandwidth share of 64 kbps is necessary for the uncompressed transmission of one audio source at telephone quality. Compression mechanism can further reduce the data rate. In any case, the bandwidth demand is small compared to the capacities of current LANs, whereas packet loss due to congestion occurs often over the Internet.
  
• Video generated by a typical computer-mounted camera is less sensitive to loss and jitter than audio, but the data rate even of compressed video is much higher than the audio data rate.
  Because audio and video conferences are real-time interactive applications, a low transmission latency is required for both media; the low-latency requirement further implies that buffering cannot be used in larger scale to compensate for transmission jitter, as could be done on the receiving end of video-on-demand systems.
• Compared to the other two media, whiteboard applications generate very little traffic. Their real-time demands, concerning delay, latency or jitter, are also comparably low. However, the reliable transmission of every single event is absolutely necessary to give each participant an identical, consistent view of the virtual board.

  The Real-Time Transport Protocol described above in Section is well suited to be used as the transport protocol for conferencing applications. For multicasting-capable IP networks, encapsulation of audio and video RTP packets in multicasted UDP packets is a common and working practice. Additional measures should be taken to ensure reliable transmission of whiteboard application data with RTP.

The transport of audio and video data with RTP in conferencing applications is described in a profile for audio and video conferences [RFC1890]. It provides interpretation of generic fields within the RTP and RTCP headers suitable for audio and video conferences that were left open by the RTP specification [RFC1889]. It also states guidelines for a variety of different audio and video encodings, as well as a set of default mappings from payload type numbers to these encodings.

If available, resource reservation mechanisms can be used, especially for widely distributed sessions. However, QoS-control--capable network equipment is not very common yet and is technically incompatible with the popular bus-style Ethernet LANs. So, monitoring of the delivery by means of RTCP receiver reports and corresponding adjustment of the encoding to the congestion state is advisable, as proposed for example in [BDS96] and [BTW94].

However, RTP and other transport-level protocols provide no or only minimal support for higher level session management functions, such as session announcement, session description, and conference control.

Handley, Wakeman, and Crowcroft summarise the main tasks of conference control [HWC95]:

• Application control. The parametrising of applications with a correct initial state.
• Membership control. Information about the current conference members and their tools and applications.
• Floor management. Control over the input to particular applications.
• Network management. Requests for end-to-end media connection establishment and tear down, and requests from the network to change bandwidth usage because of congestion.
• Meta-conference management. Initiation, announcement, invitation and termination of conferences.

 
Figure:  Conference Control Channel Protocol.

    The Multiparty Multimedia Session Control (MMUSIC) working group of the IETF is developing a related set of protocols that addresses the issues related to meta-conference management:

Session Description Protocol (SDP).

    SDP [HJ96] is intended to describe the properties of multimedia sessions for purposes of session announcement or session initiation. The distributed information can comprise:

• Session name and purpose.
• Time during which the session is active.
• Media conveyed in the session.
• Information necessary to receive those media (such as addresses, ports, formats).
• Bandwidth estimations to facilitate resource reservations.
• Contact information for the initiator or session manager.

Session Announcement Protocol (SAP).

     The Session Announcement Protocol [Han96] is used to advertise a multimedia conference or session. To announce a session, a client periodically multicasts SAP packets to a well-known multicast address and port, using the same TTL as the session itself. An SAP packet consists of an SAP header and a payload block, which is in turn an SDP message describing the session.

Session Initiation Protocol (SIP).

     SIP [HSS96] is used to invite individual users to participate in multimedia sessions. It communicates via location servers and user agents, thereby allowing mobility by relaying and redirecting invitations to a user's current location. It can also be used to invite media recording or playback servers into a session. SIP also makes use of SDP.