02-06-2014, 10:56 AM
The Internet Multimedia Conferencing Architecture
The Internet Multimedia.pdf (Size: 63.02 KB / Downloads: 47)
Introduction
This article provides an overview of multimedia conferencing on the Internet. The protocols mentioned
are all specified elsewhere as internet-drafts or RFCs. Each RFC gives details of the protocol itself,
how it works and what it does. This document attempts to provide the reader with an overview of how
the components fit together and some of the assumptions made.
The term “conferencing” is used in two different ways: firstly, to refer to bulletin boards and mail
list style asynchronous exchanges of messages between multiple users; secondly, to refer to synchronous
or so-called “real-time” conferencing, including audio, video, shared whiteboads and other applica-
tions. This document is about the architecture for this latter application, in the Internet. There are other
infrastructures for conferencing in the world: POTS (Plain Old Telephone System) networks often pro-
vide voice conferencing and phone-bridges, while the ISDN provides H.320[1] for small, strictly or-
ganised video-telephony conferencing.
The architecture that has evolved in the Internet is far more general as well as being scalable to
very large groups, and permits the open introduction of new media and new applications as they are
devised.
Multicast Service Model
The IP multicast service model is as follows:
Senders send datagrams to a multicast group address.
Receivers express an interest in (join) certain multicast groups.
Multicast routers conspire to deliver multicast group addressed datagrams from the senders to
the receivers.
The important factor here is that senders do not have to know who the receivers are in order to be
able to send to them. In fact, in most situations, no single point in the network needs to know who
all the receivers are, and it is this that makes IP multicast scalable to very large groups. In addition,
receivers do not need to know who the senders are in order to be able to receive traffic from them, and
this solves many conference setup and resource location problems without needing explicit machinery.
There are many multicast routing protocols [2],[3],[4],[5] but all of them satisfy the above service
model. They differ in their mechanisms and in how they scale with number of senders and groups.
On a LAN, group membership is expressed by IGMP[6]. IGMP version 3 allows receivers to ex-
press an interest in only receiving some of the senders to a particular multicast group. Earlier versions
of IGMP only allow a receiver to request to receive all the sources sending to a multicast group.
Address Allocation
How does an application choose a multicast address to use?
In the absence of any other information, we can bootstrap a multicast application by using well-
known multicast addresses. Routing (unicast and multicast) and group membership protocols[6] can
do just that. However, this is not the best way of manage applications of which there is more than one
instance at any one time.
For these, we need a mechanism for allocating group addresses dynamically, and a directory ser-
vice which can hold these allocations together with some key (session information for example - see
later), so that users can look up the address associated with the application. The address allocation and
directory functions should be distributed to scale well.
Internet Service Models
Traditionally the internet has provide best-effort delivery of datagram traffic from senders to receivers.
No guarantees are made regarding when or if a datagram will be delivered to a receiver, however data-
grams are normally only dropped when a router exceeds a queue size limit due to congestion. The
best-effort internet service model does not assume FIFO queuing, although many routers have imple-
mented this.
With best-effort service, if a link is not congested, queues will not build at routers, datagrams will
not be discarded in routers, and delays will consist of serialisation delays at each hop plus propagation
delays. With sufficiently fast link speeds, serialisation delays are insignificant compared to propagation
delays.
If a link is congested, with best-effort service queuing delays will start to influence end-to-end de-
lays, and packets will start to be lost as queue size limits are exceeded.
Non-best effort service
Real-time internet traffic is defined as datagrams that are delay sensitive. It could be argued that all
datagrams are delay sensitive to some extent, but for these purposes we refer only to datagrams where
exceeding an end-to-end delay bound of a few hundred milliseconds renders the datagrams useless
for the purpose they were intended. For the purposes of this definition, TCP traffic is normally not
considered to be real-time traffic, although there may be exceptions to this rule.
On congested links, best-effort service queuing delays will adversely affect real-time traffic. This
does not mean that best-effort service cannot support real-time traffic - merely that congested best-
effort links seriously degrade the service provided. For such congested links, a better-that-best-effort
service is desirable.
Admission Control
If a network is provisioned such that it has excess capacity for all the real-time flows using it, a simple
priority classification ensures that real-time traffic is minimally delayed. However, if a network is in-
sufficiently provisioned for the traffic in a real-time traffic class, then real-time traffic will be queued,
and delays and packet loss will result. Thus in an under-provisioned network, either all real-time flows
will suffer, or some of them must be given priority.
RSVP provides a mechanism by which an admission control request can be made, and if sufficient
capacity remains in the requested traffic class, then a reservation for that capacity can be put in place.
If insufficient capacity remains, the admission request will be refused, but the traffic will still be
forwarded with the default service for that traffic’s traffic class. In many cases even an admission re-
quest that failed at one or more routers can still supply acceptable quality as it may have succeeded in
installing a reservation in all the routers that were suffering congestion. This is because other reserva-
tions may not be fully utilising their reserved capacity.
Receiver Adaptation
Best-effort traffic is delayed by queues in routers between the sender and the receivers. Even reserved
priority traffic may see small transient queues in routers, and so packets comprising a flow will be
delayed for different times. Such delay variance is known as jitter.
Real-time applications such as audio and video need to be able to buffer real-time data at the re-
ceiver for sufficient time to remove the jitter added by the network and recover the original timing
relationships between the media data. In order to know how long to buffer for, each packet must carry
a timestamp which gives the time at the sender when the data was captured. Note that for audio and
video data timing recovery, it is not necessary to know the absolute time that the data was captured at
the sender, only the time relative to the other data packets.
Conference Setup
Conferences come in many shapes and sizes, but there are only really two models for conference con-
trol: light-weight sessions and tightly coupled conferencing. For both models, a rendezvous mecha-
nism is needed. Note that the conference control model is orthogonal to issues of quality of service
and network resource reservation.
Light-weight Sessions
Light-weight sessions are multicast based multimedia conferences that lack explicit session member-
ship and explicit conference control mechanisms. Typically a lightweight session consists of a number
of many-to-many media streams supported using RTP and RTCP using IP multicast.
The rendezvous mechanism for light-weight sessions is a multicast based session directory. This
distributes session descriptions[8] to all the potential session participants. These session descriptions
provide an advertisement that the session will exist, and also provide sufficient information including
multicast addresses, ports, media formats and session times so that a receiver of the session description
can join the session. As dynamic multicast address allocation can be optimised by knowing which
addresses are in use at which times, the session directory is an appropriate agent to perform multicast
address allocation.
Summary/Conclusions
This article is an attempt to gather together in one place the set of assumptions behind the design of the
Internet Multimedia conferencing architecture, and the ideas and services that are provided to support
it.
This area is one of ongoing work, but we hope that we have clarified the basic goals of the work,
and shown how there actually is a big picture within which it fits, which some observers may not have
hitherto believed!