INTERNET-DRAFT M. Handley/J. Crowcroft/C. Bormann/J. Ott
Expires: January 1998 ISI/UCL/Universitaet Bremen/Universitaet Bremen
July 1997
The Internet Multimedia Conferencing Architecture
draft-ietf-mmusic-confarch-00.txt
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
This document provides an overview of multimedia conferencing on the
Internet. The protocols mentioned are specified elsewhere as RFCs,
Internet-Drafts, or ITU recommendations. Each of these
specifications 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 of some of the
assumptions made, as well as some statement of direction for those
components still in a nascent stage.
This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working
group's mailing list at confctrl@isi.edu and/or the authors.
(To do for final version: fix references.)
Handley/Crowcroft/Bormann/Ott [Page 1]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
1. Introduction
In conjunction with computers, the term ``conferencing'' is often
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 communication and shared tools
such as whiteboards and other applications. This document is about
the architecture for this latter application, multimedia conferencing
in the Internet.
There are other infrastructures for teleconferencing in the world:
POTS (Plain Old Telephone System) networks often provide voice
conferencing and phone-bridges, while with ISDN, H.320 [1] can be
used for small, strictly organised 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.
As the simplest case, it also allows two persons to communicate via
audio only, so it encompasses IP telephony.
The determining factors of a conferencing architecture are
communication in (possibly large) groups of humans and real-time
delivery of information. In the Internet, this is supported at a
number of levels. The remainder of this section provides an overview
of this support, and the rest of the document describes each aspect
in more detail.
In a conference, information must be distributed to all the
conference participants. Early conferencing systems used a fan-out
of data streams, e.g., one connection between each pair of
participants, which means that the same information must cross some
networks more than once. The Internet architecture uses the more
efficient approach of multicasting the information to all
participants (section 2).
Multimedia conferences require real-time delivery of at least the
audio and video information streams used in the conference. In an
ISDN context, fixed rate circuits are allocated for this purpose --
whether their bandwidth is required at any particular instance or
not. On the other hand, the traditional Internet service model
(``best effort'') cannot make the necessary quality of service
available in congested networks. New service models are being
defined in the Internet together with protocols to reserve capacity
in a more flexible way than that available with circuit switching
(section 3).
In a datagram network, multimedia information must be transmitted in
packets, some of which may be delayed more than others. In order
that audio and video streams be played out at the recipient in the
correct timing, information must be transmitted that allows the
recipient to reconstitute the timing. A transport protocol with the
Handley/Crowcroft/Bormann/Ott [Page 2]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
specific functions needed for this has been defined (section 4).
Conference tools such as virtual whiteboards or shared editors are
not concerned with real-time delivery of audio or video but maintain
and update shared state between the participants. Work on support of
such applications in a multicst environment is in progress (section
5).
The humans participating in a conference generally need to have a
specific idea of the context in which the conference is happening,
which can be formalized as a conference policy. Some conferences are
essentially crowds gathered around an attraction, while others have
very formal guidelines on who may take part (listen in) and who may
speak at which point. In any case, initially the participants must
find each other, i.e. establish communication relationships
(conference setup, section 6). During the conference, some
conference control information is exchanged to implement a conference
policy or at least to inform the crowd of who is present (section 7).
In addition, security measures may be required to actually enforce
the conference policy, e.g. to control who is listening and to
authenticate contributions as actually originating from a specific
person. In the Internet, there is little tendency to rely on the
traditional ``security'' of distribution offered e.g. by the phone
system. Instead, cryptographic methods are used for encryption and
authentication, which need to be supported by additional conference
setup and control mechanisms (section 8).
Figure 1: Internet Multimedia Conferencing protocol stacks
|<--- Conference Management --->|<--- Media Agents --->|
| | |
| Conference | Conference | Audio/ | Shared |
| Setup & Discovery | Course Control | Video | Applications |
+-------------------------+------+--------+-+--------+------------+ +
| S D P | | Distr. | RTP / | Reliable | |
| SAP | SIP | HTTP | SMTP | RSVP | Ctrl(1)| RTCP |Multicast(2)| |
+-----+--+--+------+------+ +--+--------+----------+------------+--+
| UDP | T C P | | U D P |
+--------+----------------+---+--------------------------------------+
| IP + IP Multicast |
+--------------------------------------------------------------------+
| Integrated Services Forwarding |
+--------------------------------------------------------------------+
Notes:
(1) The work on distributed control for tightly coupled conferences
is in progress (see section 6).
(2) See section 5.
Handley/Crowcroft/Bormann/Ott [Page 3]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
The protocol stacks for Internet Multimedia Conferencing are shown in
Figure 1. Most of the protocols are not deeply layered unlike many
protocol stacks, but rather are used alongside each other to produce
a complete conference.
2. Multicast Traffic Distribution
IP multicast enables efficient many-to-many datagram distribution.
It is one of the basic building blocks of the Internet Multimedia
Conferencing architecture. For most conferencing purposes, unicast
is viewed as being a special case of multicast traffic.
2.1. Multicast Service Model
The IP multicast service model is as follows:
- Senders send datagrams to the address of a multicast group.
- 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-5] but all of them
satisfy the above service model. They differ in their mechanisms and
in how they scale with the number of senders and groups.
Within a single LAN, group membership is expressed by IGMP [6, 7].
IGMP version 3 allows receivers to express 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.
2.2. Address Allocation
How does an application choose a multicast address to use?
In the absence of any other information, we can bootstrap a multicast
Handley/Crowcroft/Bormann/Ott [Page 4]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
application by using well-known multicast addresses. Routing
(unicast and multicast) and the group membership protocol IGMP can do
just that. However, this is not the best way of managing
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 service 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.
Address allocation schemes should avoid clashes, hence some kind of
hash function suggests itself for forming initial ``random'' values
for the address. Furthermore, both the address allocation system and
the directory service can take advantage of the baseline multicast
mechanism by advertising conferences through multicast messages on a
well-known address, and using this to inform other directory servers
to remove clashes and inform applications of the allocation; see also
section 7.
Such advertisements, as well as the multicast traffic itself, can be
restricted to a defined region in the network (such as a corporate
network) by using multicast addresses out of a range reserved for
administrative scoping [***REF***]. In the future, address
allocation may further be influenced by the desire to allocate
addresses such that the corresponding landmarks used in emerging
inter-domain multicast routing protocols are close to a significant
subset of the participants [***REF***].
3. Internet Service Models
Traditionally the Internet has provided 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 datagrams 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
implemented 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[1].
_________________________
[1] For slow links, a set of mechanisms has been defined that
helps minimize serialisation and link access delays [8].
Handley/Crowcroft/Bormann/Ott [Page 5]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
If a link is congested, with best-effort service queuing delays will
start to influence end-to-end delays, and packets will start to be
lost as queue size limits are exceeded.
3.1. 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-than-best-effort service is desirable.
To achieve this, the service model of the routers can be modified.
At a minimum, FIFO queuing can be replaced by packet forwarding
strategies that discriminate different ``flows'' of traffic. The
idea of a flow is very general. A flow might consist of ``all
marketing site web traffic'', or ``all fileserver traffic to and from
teller machines'' or ``all traffic from the CEOs laptop wherever it
is''. On the other hand, a flow might consist of a particular
sequence of packets from an application in a particular machine to a
peer application in another particular machine between specific times
of a specific day.
Flows are typically identifiable in the Internet by the tuple:
{source machine, destination machine, source port, destination port,
protocol} any of which could be ``ANY'' (wildcarded).
In the multicast case, the destination is the group, and can be used
to provide efficient aggregation.
Flow identification is called classification and a class (which can
contain one or more flows) has an associated service model applied.
This can default to best effort.
Through network management, we can imagine establishing classes of
long lived flows -- enterprise networks (``Intranets'') often enforce
traffic policies that distinguish priorities which can be used to
discriminate in favor of more important traffic in the event of
overload (though in an underloaded network, the effect of such
policies will be invisible, and may incur no load/work in routers).
The router service model to provide such classes with different
Handley/Crowcroft/Bormann/Ott [Page 6]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
treatment can be as simple as a priority queuing system, or it can be
more elaborate.
Although best-effort services can support real-time traffic,
classifying real-time traffic separately from non-real-time traffic
and giving real-time traffic priority treatment ensures that real-
time traffic sees minimum delays. Non-real-time TCP traffic tends to
be elastic in its bandwidth requirements, and will then tend to fill
any remaining bandwidth.
We could imagine a future Internet with sufficient capacity to carry
all of the world's telephony traffic. Since this is a relatively
modest capacity requirement, it might be simpler to establish
``POTS'' as a static class which is given some fraction of the
capacity overall, and then within the backbone of the network no
individual call need be given an allocation (i.e. we would no longer
need the call setup/tear down that was needed in the legacy POTS
which was only present due to under-provisioning of trunks, and to
allow the trunk exchanges the option of call blocking). The vision
is of a network that is engineered with capacity for all of the
average load sources to send all the time.
3.2. Reservations
For flows that may take a significant fraction of the network (i.e.
are ``special'' and can't just be lumped under a static class), we
need a more dynamic way of establishing these classifications. In
the short term, this applies to any multimedia calls since the
Internet is largely under-provisioned at the time of writing.
RSVP is being standardised for just this purpose. It provides flow
identification and classification. Hosts and applications are
modified to speak RSVP client language, and routers speak RSVP.
Since most traffic requiring reservations is delivered to groups
(e.g. TV), it is natural for the receiver to make the request for a
reservation for a flow. This has the added advantage that different
receivers can make heterogeneous requests for capacity from the same
source. Thus RSVP can accommodate monochrome, color and HDTV
receivers from a single source.
Again the routers conspire to deliver the right flows to the right
locations.
RSVP accommodates the wildcarding noted above.
3.3. Admission Control
If a network is provisioned such that it has excess capacity for all
Handley/Crowcroft/Bormann/Ott [Page 7]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
the real-time flows using it, a simple priority classification
ensures that real-time traffic is minimally delayed. However, if a
network is insufficiently 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 request 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 reservations may not be fully utilising their
reserved capacity in those routers where the reservation failed.
3.4. Billing
If a reservation involves setting aside resources for a flow, this
will tie up resources so that other reservations may not succeed, and
depending on whether the flow fills the reservation, other traffic is
prevented from using the network. Clearly some negative feedback is
required in order to prevent pointless reservations from denying
service to other users. This feedback is typically in the form of
billing. For real-time non-best effort multicast traffic that is not
reserved, this negative feedback is provided in the form of loss due
to congestion of a traffic class, and it is not clear that usage
based billing is required.
Billing requires that the user making the reservation is properly
authenticated so that the correct user can be charged. Billing for
reservations introduces a level of complexity to the Internet that
has not typically been experienced with non-reserved traffic, and
requires network providers to have reciprocal usage-based billing
arrangements for traffic carried between them. It also suggests the
use of mechanisms whereby some fraction of the bill for a link
reservation can be charged to each of the downstream multicast
receivers.
4. Audio/Video Transport Protocols
So-called real-time delivery of traffic requires little in the way of
transport protocol. In particular, real-time traffic that is sent
over more than trivial distances is not retransmittable.
Handley/Crowcroft/Bormann/Ott [Page 8]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
4.1. Separate Flows for each Media Stream
With packet multimedia data there is no need for the different media
comprising a conference to be carried in the same packets. In fact
it simplifies receivers if different media streams are carried in
separate flows (i.e., separate transport ports and/or separate
multicast groups). This also allows the different media to be given
different quality of service. For example, under congestion, a
router might preferentially drop video packets over audio packets.
In addition, some sites may not wish to receive all the media flows.
For example, a site with a slow access link may be able to
participate in a conference using only audio and a whiteboard whereas
other sites in the same conference may also send and receive video.
4.2. 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 receiver 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.
4.3. Synchronisation
As audio and video flows will receive differing jitter and possibly
differing quality of service, audio and video that were grabbed at
the same time at the sender may not arrive at the receiver at the
same time. At the receiver, each flow will need a playout buffer to
remove network jitter. Inter-flow synchronisation can be performed
by adapting these playout buffers so that samples/frames that
originated at the same time are played out at the same time. This
requires that the time base of different flows from the same sender
can be related at the receivers, e.g. by making available the
absolute times at which each of them was captured.
Handley/Crowcroft/Bormann/Ott [Page 9]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
4.4. RTP
The transport protocol for real-time flows is RTP [9]. This provides
a standard format packet header which gives media specific timestamp
data, as well as payload format information and sequence numbering
amongst other things. RTP is normally carried using UDP. It does
not provide or require any connection setup, nor does it provide any
enhanced reliability over UDP. For RTP to provide a useful media
flow, there must be sufficient capacity in the relevant traffic class
to accommodate the traffic. How this capacity is ensured is
independent of RTP.
Every original RTP source is identified by a source identifier, and
this source id is carried in every packet. RTP allows flows from
several sources to be mixed in gateways to provide a single resulting
flow. When this happens, each mixed packet contains the source ids
of all the contributing sources.
RTP media timestamp units are flow specific -- they are in units that
are appropriate to the media flow. For example, 8kHz sampled PCM
encoded audio has a timestamp clock rate of 8kHz. This means that
inter-flow synchronisation is not possible from the RTP timestamps
alone.
Each RTP flow is supplemented by Real-Time Control Protocol (RTCP)
packets. There are a number of different RTCP packet types. RTCP
packets provide the relationship between the real-time clock at a
sender and the RTP media timestamps, and provide textual information
to identify a sender in a conference from the source id.
4.5. Conference Membership and Reception Feedback
IP multicast allows sources to send to a multicast group without
being a receiver of that group. However, for many conferencing
purposes it is useful to know who is listening to the conference, and
whether the media flows are reaching receivers properly. Accurately
performing both these tasks restricts the scaling of the conference.
IP multicast means that no-one knows the precise membership of a
multicast group at a specific time, and this information cannot be
discovered, as to try to do so would cause an implosion of messages,
many of which would be lost[2]. Instead, RTCP provides approximate
membership information through periodic multicast of session messages
which, in addition to information about the recipient, also give
information about the reception quality at that receiver. RTCP
session messages are restricted in rate, so that as a conference
_________________________
[2] Note that a conference policy that restricts conference mem-
bership can be implemented using encryption and restricted distri-
bution of encryption keys, of which more later.
Handley/Crowcroft/Bormann/Ott [Page 10]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
grows, the rate of session messages remains constant, and each
receiver reports less often. A member of the conference can never
know exactly who is present at a particular time from RTCP reports,
but does have a good approximation to the conference membership.
Reception quality information is primarily intended for debugging
purposes, as debugging of IP multicast problems is a difficult task.
However, it is possible to use reception quality information for rate
adaptive senders, although it is not clear whether this information
is sufficiently timely to be able to adapt fast enough to transient
congestion. However, it is certainly sufficient for Van Jacobson
congestion control [10] style adaption to a ``share'' of the current
capacity.
4.6. Control of Stream Playback and Recording
A control protocol for initiating and controlling playing and
recording audio, video, and other RTP-based information is the Real-
Time Stream control Protocol (RTSP) [11]. While primarily intended
for web-based media-on-demand services, RTSP may also be used in the
context of teleconferences to make recorded audio/video information
available to the participants, or to control recording the course of
the conference.
5. Protocols for Non-A/V Applications
Applications other than audio and video have evolved in Internet
conferencing, e.g. Imm, Wb [12], Nt. Such applications can be used
to substitute for meeting aids in physical conferences (whiteboards,
projectors) or replace visual and auditory cues that are lost in
teleconferences (e.g., a speaker list application); they also can
enable new styles of joint work.
Most non-A/V applications have in common that the application
protocol is about establishing and updating a shared state. Loss of
information is often not acceptable, so some form of multicast
reliability is required. The applications' requirements differ: Some
applications make per-participant additions to the shared state that
are orthogonal to each other (e.g., whiteboards), some evolve a more
closely interrelated common state (e.g., additions to a speaker list
must be properly sequenced). Some applications can make use of added
bandwidth/react to congestion in an elastic way, others transport
data that, although not strictly real-time, is time-critical.
In the IRTF research group on Reliable Multicast, work is in progress
on common protocol elements that can be used in such applications.
At the time of writing, some aspects of reliable multicast are not
well-understood, such as the proper way to provide congestion control
in a multicast environment. As congestion control is considered an
essential element, standards track protocols are not expected before
this can be solved. Refer to http://www.irtf.org/rm for further
Handley/Crowcroft/Bormann/Ott [Page 11]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
information.
6. Conference Control
Conferences come in many shapes and sizes, but there are only really
two models for conference control: light-weight sessions and tightly
coupled conferencing. For both models, rendezvous mechanisms are
needed. Note that the conference control model is orthogonal to
issues of quality of service and network resource reservation. Note
also that the issue of conference control is orthogonal to the
mechanism for discovering the conference.
6.1. Light-weight Sessions
Light-weight sessions are multicast based multimedia conferences that
lack explicit session membership 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[3]. The only conference control information available
during the course of light-weight sessions is that distributed in the
RTCP session information, i.e. an approximate membership list with
some attributes per member.
6.2. Tightly coupled Conferences
Tightly coupled conferences may also be multicast based and use RTP
and RTCP, but in addition they have an explicit conference membership
mechanism and may have an explicit conference control mechanism that
provides facilities such as floor control.
At the time of writing, no standard mechanism for performing tightly
coupled conference control currently exists in the Internet
community. Another standards body, the ITU, has defined two
standards that can be used in the Internet:
- The T.120 series of recommendations includes a centralized
conference control protocol currently used for data application
only, T.124 [13].
- Recommendation H.323 for Multi-Media Conferences for Packet-
_________________________
[3] There is some confusion on the term session, which is some-
times used for a conference and sometimes for a related set of me-
dia streams transported by RTP and perceived as a unit, e.g., the
audio channel in a conference. In this document, we prefer to use
the less ambiguous term conference except where existing protocols
use the term session.
Handley/Crowcroft/Bormann/Ott [Page 12]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
based Network Environments [14] specifies a point-to-point
channel setup protocol [15] that also covers a few multipoint
conferencing aspects.
As T.124 is not accepted by the industry as a basis for audiovisual
conference control on one hand and H.245 does not provide distributed
control for tightly coupled conferences on the other hand, there is
no obvious choice. The Simple Conference Control Protocol (SCCP)
[16] is being developed as a prototype towards providing this kind of
control (being a shared state application, SCCP could also benefit
from developments in the area of reliable multicast). A future
distributed conference control protocol could be used as the
distributed control mode envisioned by H.323 (which has not yet been
addressed by the ITU).
7. Conference Discovery
There are two basic forms of conference discovery mechanism. These
are session advertisement and session invitation. Session
advertisements are provided using a session directory, and inviting a
user to join a session is provided using a session invitation
protocol.
7.1. Session Directories
The rendezvous mechanism for light-weight sessions is a multicast
based session directory. This distributes session descriptions [17]
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. The protocol SDP
(session description protocol) describes contents and format of the
session descriptions.
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. SAP
(session announcement protocol) is the protocol used by the session
directory agents [18].
This mechanism can also be applied to advertised tightly coupled
sessions, and only requires that additional information about the
mechanism to use to join the session is given.
7.2. Session Invitation
Handley/Crowcroft/Bormann/Ott [Page 13]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
Not all sessions are advertised, and even those that are advertised
may require a mechanism to explicitly invite a user to join a
session. Such a mechanism is required regardless of whether the
session is a lightweight session or a more tightly coupled session,
although the invitation system must specify the mechanism to be used
to join the session.
As users are mobile, it is important that such a mechanism is capable
of locating and inviting a user in a location independent manner.
This requires an extra level of indirection (addressing). The
invitation mechanism should also provide for alternative responses,
such as leaving a message or being referred to another user, should
the invited user be unavailable.
Based on a protocol with many of the properties required [19], a
session initiation protocol (SIP) is being developed [20].
8. Security
There is a temptation to believe that multicast is inherently less
private than unicast communication since the traffic visits so many
more places in the network. In fact, this is not the case except
with broadcast and prune type multicast routing protocols. However,
IP multicast does make it simple for a host to anonymously join a
multicast group and receive traffic destined to that group without
the other senders' and receivers' knowledge. If the application
requirement (conference policy) is to communicate between some
defined set of users, then strict privacy can only be enforced in any
case through adequate end-to-end encryption.
RTP specifies a standard way to encrypt RTP and RTCP packets using
private key encryption schemes such as DES [21]. It also specifies a
standard mechanism to manipulate plain text keys using MD5 [22] so
that the resulting bit string can be used as a DES key. This allows
simple out-of-band mechanisms such as privacy-enhanced mail to be
used for encryption key exchange.
8.1. Authentication and Key Distribution
Key distribution is closely tied to authentication. Conference or
session directory keys can be securely distributed using public-key
cryptography on a one-to-one basis (by email, a directory service, or
by an explicit conference setup mechanism), but this is only as good
as the certification mechanism used to certify that a key given by a
user is the correct public key for that user. Such certification
mechanisms [23] are not specific to conferencing, and no standard
mechanisms are currently in use for conferencing purposes other than
PEM [24].
At the time of writing, no standard mechanisms for key distribution
Handley/Crowcroft/Bormann/Ott [Page 14]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
are defined for the conference setup and control protocols in use.
Even without privacy requirements in the conference policy, strong
authentication of a user is required if making a network reservation
results in usage based billing.
8.2. Encrypted Session Announcements
Session Directories can make encrypted session announcements using
private key encryption, and carry the encryption keys to be used for
each of the conference media streams in the session. Whilst this
does not solve the key distribution problem, it does allow a single
conference to be announced more than once to more than one key-group,
where each group holds a different session directory key, so that the
two groups can be brought together into a single conference without
having to know each other's keys.
9. Summary
This document is an attempt to gather together in one place the set
of assumptions behind the design of the Internet Multimedia
Conferencing architecture, and the services that are provided to
support it.
10. Acknowledgments and Authors' Addresses
Acknowledgments are due to the End-to-End Research Group, the Int-
serv, RSVP, MMUSIC and AVT working groups of the IETF, and discussion
with colleagues at UCL. The earliest clear exposition of the ideas
here can be found at http://www-mice.cs.ucl.ac.uk/mice-old/van/ and
was presented at ACM SIGCOMM 1994 in London by Van Jacobson.
Mark Handley
(fix me)
Email: mjh@isi.edu
Jon Crowcroft
Department of Computer Science
University College London
Gower Street,
London WC1E 6BT
UK
fax +44 171 387 1397
Email: m.handley@cs.ucl.ac.uk, j.crowcroft@cs.ucl.ac.uk
Web: http://www.cs.ucl.ac.uk/index.html
Handley/Crowcroft/Bormann/Ott [Page 15]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
Carsten Bormann
Universitaet Bremen
Postfach 330440
D-28334 Bremen
GERMANY
fax +49 421 218-7000
Email: cabo@tzi.org
Web: http://www-rn.informatik.uni-bremen.de
References
1. ITU, Recommendation H.320.
2. S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C.-G. Liu, and
L. Wei, An Architecture for Wide Area Multicast Routing, 24, pp.
126-135, ACM SIGCOMM, October 1994.
3. S. Deering, C. Partridge, and D. Waitzman, "Distance Vector
Multicast Routing Protocol," RFC 1075, November 1988.
4. A. Ballardie, P. Francis, and J. Crowcroft, An Architecture for
Scalable Inter-Domain Multicast Routing, pp. 85-95, ACM SIGCOMM,
1993.
5. J. Moy, "Multicast Extensions to OSPF," RFC 1584, March 1994.
6. S. Deering, Multicast Routing in Internetworks and Extended LANs,
pp. 55-64, ACM SIGCOMM, August 1988.
7. S. Deering, "Host Extensions for IP Multicasting," RFC 1112,
August 1989.
8. C. Bormann, "Providing integrated services over low-bitrate
links," Internet-Draft draft-ietf-issll-isslow-02.txt, Work in
Progress, May 1997.
9. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications," RFC 1889.
10. V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM,
August 1988.
11. H. Schulzrinne, A. Rao, and R. Lanphier, "Real-Time Stream
Control Protocol (RTSP)," Internet-Draft draft-ietf-mmusic-
rtsp-0x.txt, Work in Progress, (fix me).
12. S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang, A
Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing, pp. 342-356, ACM SIGCOMM, 1995.
Handley/Crowcroft/Bormann/Ott [Page 16]
INTERNET-DRAThe Internet Multimedia Conferencing Architecture July 1997
13. ITU-T, Recommendation T.124 -- Generic Conference Control.
14. ITU-T, Recommendation H.323 -- Multi-Media Conferences for
Packet-based Network Environments.
15. ITU-T, Recommendation H.245.
16. C. Bormann, J. Ott, and C. Reichert, "Simple Conference Control
Protocol," Internet-Draft draft-ietf-mmusic-sccp-0x.txt, Work in
Progress, (fix me).
17. M. Handley and V. Jacobson, "SDP: Session Description Protocol,"
Internet-Draft draft-ietf-mmusic-sdp-0x.txt, Work in Progress,
(fix me)..
18. M. Handley and V. Jacobson, "SAP: Session Announcement Protocol,"
Internet-Draft draft-ietf-mmusic-sap-0x.txt, Work in Progress,
(fix me)..
19. H. Schulzrinne, "Personal Mobility for Multimedia Services in the
Internet," IMDS'96, March 1996..
20. M. Handley, H. Schulzrinne, and E. Schooler, "SIP: Session
Initiation Protocol," Internet-Draft draft-ietf-mmusic-
sip-0x.txt, Work in Progress, (fix me)..
21. National Institute of Standards and Technology (NIST), FIPS
Publication 46-1: Data Encryption Standard, January 1988.
22. R. Rivest, "The MD5 Message-Digest Algorithm," RFC 1321, April
1992.
23. CCITT, Recommendation X.509: The Directory -- Authentication
Framework, 1988..
24. J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures," RFC 1421,
Feb 1993.
Handley/Crowcroft/Bormann/Ott [Page 17]
