Managing Data in Multimedia Conferencing

Seminar Report’03 Multimedia Conferencing
Introduction
Distributed multimedia conferencing systems break the information to be

transmitted (voice, video, data) into packets which they transmit in a packet
stream. The system must maintain packet order and stream interrelationships
from origin to destination. Managing packet delivery among multiple users is
particularly difficult in conferencing systems, which typically involve many
source and destination nodes. For example ,this system often require extended
routing time and additional buffer space for merging data from multiple sources,
which delay packet delivery.
Most work to date on packet management in distributed multimedia

environments such as team workstation and Etherphone focuses on guaranteeing
isochronous presentation rates over a network where there’s single source and
destination. To support distributed multimedia conferencing systems we need a
system that can coordinate delivery of multiple packet streams from multiple
sources with minimal delay, allowing destination applications to manage
synchronization within the streams.
This report discusses the coordination and synchronization of multiple data

streams in a distributed interactive digital multimedia (DIDM) group with
multiple senders and receivers. The Ensembles Coordination Program (ECP)
performs the required coordination and synchronization using path selection and
rebroadcasting to reduce delays. ECP’s routing mechanism differs from
multicasting because while it provides data segment routing by duplicating
messages, it also coordinates multiple interdependent data streams.
Dept. of CSE 1 MESCE, Kuttippuram

Coordinating Distributed Multimedia Data
This coordination methodology is independent of the network delays

caused by the underlying network protocols. Delays caused by the network could
however cause jitter. Jitter occurs when, for instance a word or image is played
back with a stutter. In a conference, if two people speak at the same time, each
person’s voice must coincide with the formation of the words in that person’s
video image.
In ECP , an ensemble is a collection elements “A” from a stream to be

presented to an application with the collection of elements “B” of another stream,
for n streams .Ensemble coordination is the presentation of all “A” and “B”
elements in their required synchronization order to an application .E-systems are
nodes in the infrastructure.
We can coordinate the elements of multiple data streams at three points: a

common source or distribution center, the destination or intermediate points
along the path. This report concentrates on problems that occur along the source-
destination path. Key issues are minimizing the processing the to determine the
routing of stream elements , establishing adequate buffering at all nodes in the
network, and ensuring that the proper data segments are available for
synchronous presentation.
The related problems such as graph or network partitioning, fault

tolerance, dynamic group membership, transmission control protocol/internet
protocol versus asynchronous transfer mode and other network protocols. The
design of this procedure doesn’t preclude inclusion of this items in the future.

Processing at en E-system occurs at two stages. Stage one reads all

ensembles content definition and their sources and their targets. It also reads
definition of the network graphs, nodes and edges. With this information, stage1
creates the data structures required to perform synchronization. Stage2 transmits
and receives the multimedia data objects and presents them, in proper
synchronization, to the output processes. TCP/IP guarantees single source
ordering.
The object model represents the multimedia data streams and their
operations. A multimedia stream corresponds to “the data-specific for one or
more media”. For example an object can contain a video data stream and an
audio data stream with a time dependency between them. An Ensemble differs
from a stream or object in that streams don’t contain specifications for related
data, and an object can’t co-ordinate disjoint streams. Streams or objects might
require data to be presented together in real time synchronization, thus imposing
a dependency on the availability that all portions of a presentation moment be
available within some time span. In a multimedia group application, where any
group member can simultaneously be in multiple groups, Ensembles must
observe all the three ordering properties.
The ordering properties are as explained below:
Single Source ordering: If messages M1 and M2 originate at the same site, all
receivers within a specific multicast group will receive them in the same order.
Multiple source ordering: If different sources send messages M1 and M2 all

recipients in the group will receive them in the same order.
Multiple Group ordering: If messages M1 and M2 are delivered to two processes,
they are delivered in the same order to both processes, even if they originated at
different sources.

Note that there is a clear distinction between “doing“ and “seeing” in

multimedia conferencing. When a conference participant does something
feedback might not be instantaneous. All participants, including the participant
performing the action will see the reaction of the moment taken in the same way,
ordered with respect to the other data streams by the three properties mentioned
previously. Note that no common global time exists. All participants see all
events in the same order but not necessarily at the same real time.
This report makes no pre-judgments about implications. On a fast LAN

feedback will be nearly instantaneous. With other network functions, there might
be a noticeable delay with doing and seeing. For some types of conferences or
data streams, some delay might be acceptable; for others, the same amount might
tax participants adaptability or disorient them. For example if a video is
sporadically interrupted, viewers can continue to mentally process the
information while the voice continues, but when an audio information is
sporadically interrupted, the human listener experiences severe disorientation.
Synchronization types
Intra object synchronization: It is the time relation between the units of a

single time dependent media object.
Inter object synchronization: It is the time relation between the multiple media
objects at a single range.
Some application requires provisions where the processing program must

digitize and normalize some signals, then add to them some other signals. On
playback the program at the origin must subtract its own signal from the
summation. ECP handles these problems using a third type of synchronization
called Site synchronization.

Site synchronization: In this type of synchronization ECP provides the required

data segment to the multimedia applications, which then synchronizes the inter
object presentation. ECP delivers the data at different nodes in the conference,
such that all the same nodes display the same object identical synchronization
and delay within and between the objects.
Global synchronization: In this type of synchronization all sites provides all

three types of synchronization in a near universal time presentation of object
sequences, as in a live television broadcast received at multiple locations.
Ensembles coordination ensures that the transmission of element of a

multimedia conference honors the distributed system properties with minimal
buffering requirements and meet the requirements of all three synchronization
types. ECP differs from mixing or multiplexing. In Ensembles the individual data
streams aren’t physically merged. Rather than ECP transmits them as separate
TCP/IP messages and Ensemble coordination ensures that the related segments of
each streams are transmitted before the next set of segments.

Architecture and Implementation
ECP manages multiple segments of multiple data streams as they traverse

a network of distributed instances of a multimedia application. ECP is logically
positioned between the network interface and the multimedia application.
Structure
To simplify development and testing, the current implementation is a

single stand alone program that opens multiple data files, provides inter stream
coordination, and displays data. However the program structure is such that it
could be truncated to coordinate data only, allowing a real multimedia
application to provide and display the data segment.
In the truncated version, a multimedia application developer could test an

application with a copy of ECP running at many nodes without modifying,
recompiling, or changing the parameters. In this case all nodes running the ECP
is called an E-system.
Each E-system has two control files
1. NE.dat: This contains the virtual names assigned to all nodes along with their
network names, a list of all nodes and edges in the conference graph, and a list of
Ensembles names with their corresponding stream names.
2. ERULES.dat: It contains the list of rules expressing the relationship between
the streams and ensembles.
To initiate a conference, the conference operator starts all E-systems.

When the conference operator determines that the E-system have initialized,

he/she initiates the “conference start” via the command interface. At the
initialization, each E system communicate with each other. The current initiation
Simplifies the overall program structure, letting ECP concentrate on data routing
and coordination.
System Development
A sequential dependency exists within a single stream in multimedia

presentation. For example, a multimedia program must reproduce speech sounds
as spoken i.e in the same order or the meaning is lost. A sequential dependency
also exists across streams. For example, in Ensemble E1 in figure given below, if
stream s1 is voice and stream s2 is speaker's image, the voice must match the
movement of persons lips in the video stream. Thus at any instant the elements of
one stream must be synchronized with the elements of all the other streams
related to that presentation instant. In a movie, this relationship is called a frame
and the synchronization colloquially called a lip synchronization. In ECP, it is an
Ensemble.

Representing Conferences
Let Sn represent the nth stream in Ensemble Ee. Data stream coordination
requires that the ith element of stream S1 is presented simultaneously with the jth
element. A ratio of the stream elements prevents the streams S1 and S2 from
being transmitted
At a rate where i matches j, rather a relationship exists between the values

of i and j. We thus have an expression , Ee ($,&,…) relating the presentation
requirements of the frames of streams S1, S2, … within Ee, where $ and &
represent the relation i and j to the whole Ensemble. The entire conference, C, as
shown in the figure can be represented by
SO1 SO2
S1 S2
ISS2
SO3 ISS1
S3
SO4
S4
ISS3 ISS4
S5
SO5
D1 D2 D3
E1 E2 E2 E1
Where E is an Ensemble, e is the Ensemble number, m is the maximum

Ensemble number determined for the conference from the NE.dat(file) and $ is
the number assigned during the conference graph construction and

E=[Sm,Qn]
Where S represents a stream, Q is the quantity of data segments in the

stream, and n is the stream number (thus, Qn is the quantity of data segments in
stream n). ECP receives these rules from the conference file ERULES.dat . The
program determines the contents of an Ensemble by the set of its ordered pairs of
stream S and the quantity Q of segments per stream.
Minimizing Delay
As previously noted, a movie with both a audio and an audio portion

contains multiple elements of video data for one element of audio information
( video data consists of 30 frames per second ). A segment of this Ensemble
would thus be 30 video elements and one audio element. This would be now
reflected in the ERULES.dat file with the record E1 (S1,30) (S2,1).
Given the synchronization requirements and the desire to reduce

buffering, an Ensemble node requires a routing mechanism that will ECP
transmit the ith portion of S1 with the ith portion of j and so on, as a relative
cohesive unit. By relatively cohesive, I mean that users should receive the
segments within a short enough time span so that they won’t preceive a program
related delay between Ensembles i.e. ECP doesn’t physically merge ( or mix or
multiplex) the individual stream segments that form an Ensemble into a single
message, but still presents them as a single synchronized unit. Other researchers
have addressed the ability to handle other sources of delay; this research should
be incorporated in a more universal solution.
We can extend interobject synchronization to more than two streams, as

when the signals from the simulator are separately recorded and then all

recordings are played together. Because multimedia conferencing is human

communication every node, $, in a conference of C nodes should display the
same Ensembles such that all human conference participants preceives the
Ensemble with some predefined offset # from each instant in time as measured at
the ensemble’s originating site. ECP isn’t concerned with the value of this offset
other than to attempt to quantify it’s effects on data presentation at the
destination. Much research on quality of service has focused on the value of #.
This report concentrate on the problems involved with multisource,
multidestination synchronization of interdependent data streams. In a multimedia
environment, where multimedia programs requires large quantities of data and
many streams, buffering alone might provide neither the necessary
synchronization nor the data’s close to real time requirements. Current streaming
techniques donot address the merging separate source stream requirements.
Merging and routing Streams
The figure drawn previously shows three data streams S1, S2, S3
originating at separate locations SO1, S02 andSO3. ECP must offer these streams
which constitute Ensemble E1, all three synchronization types at each of the final
destinations D1, D2 and D3. Streams S4 and S5 compose Ensemble E2. A time
dependency exists between streams E1(1,2,3)(#,$,..), where #, $ etc represents
the relationship of the number of data packets in each stream that must be
transmitted with elements of the other stream to form the Ensemble. Depending
on the type of conference we might or might not want to make the presentation at
destination D1 simultaneous with the presentation at destination D3( delayed
presentation must be desirable in replay systems. The same dependencies exist
for E1.
E-system run a DIDM application using TCP/IP and don’t modify the
underlying operating system or network processing facilities. E-system which are

neither stream sources nor final destinations, are intermediate synchronization

stations. Their purpose is to merge streams from multiple sources before the
Ensemble move to the next graph node.
For Example in the figure drawn previously we must forward stream S3

from SO3 to D1 with S1 and S2(from ISS4) but independently of D3, so the
multimedia application can process it there with the re with the proper elements
of it’s Ensemble from S1 and S2.Note that this Ensemble’s methodology doesn’t
directly address dynamic reconfiguration of the network graph, although the
implementation allows for it. Virtual nodes are mapped to IP addresses, which
could be dynamic.
Flits
Flits are flow control units the header of which deterministically controls
the flow of all succeeding datagrams parts. Flits strongly influenced the
development of the ECP routing scheme. Instead of flits, however the ECP uses a
path node vector(PV) and a distribution vector (DV) both computed at program
initialization. Tha PV determines all destination for each data streams. The DV
determines, for each node, all sites that are one graph distant , and which must
receive the the current data stream segment(or data element). To the best of my
knowledge , the flit and DV have so far implemented in hardware used to
interconnect large scale mesh or cube connected multicomputers.

Managing Stream Segments
Normally three arrays to manage the selection of segments for display or

transmission. They are Required, Avail, and Avail_S. Required specifies the
number of segments per Ensemble and stream at the current node. Avail and
Avail_S specifies the number of segmrnts currently in the buffer , either awaiting
retransmission or display(Avail) or original transmission(Avail_S).ECP assigns
number to all streams and Ensembles, and then indexes the three arrays by
Ensemble and stream number. The ERULES.dat file directly determines the
values in Required. It determines the values in other two arrays at run time as
segments arrive(either from other node or from a file reading thread).
To control the use and removal of the Ensemble and stream segments ,
each stream is a C++ object. Each object contains a list of available segments in
the stream and arrays with the starting and ending list indexes of the segments in
the current Ensemble. During program execution, the number of segments
available for Ensemble transmission can exceed the number of segments
required for the current Ensemble. This occurs because the various segments
come from different nodes. These index arrays together with Required, Avail,
Avail_S provide the information needed to ensure transmission a complete
Ensemble. In addition because , multimedia buffers can use any stream, ECP
can’t purge the buffer segments until the application program no longer needs the
segments.
The Ensemble Algorithm
The Ensemble coordination must perform several initializations before it

can begin processing conference data. Once the system is initialized , ECP moves
into it’s operational stage, during which it accepts data for transmission and
receives incoming data for display. The Ensemble algorithm describes these
operations.

Initialization
First create the graph, G, and a LEDA( Library of efficient Data Structures
and Algorithms) graph array, G, representing all nodes in the graph. List source
nodes first, destination nodes second, and intermediate nodes last.
Next compute the adjacency vector (AV) for the current node. This is directly
available using the LEDA function, G.adj_nodes.
For receiver nodes , use the LEDA Graphwin function to create a window
for each Ensemble to be played at this node. Graphwin is a platform independent
mechanism that lets users draw windows and insert graphics and text. Next for
each Ensemble originating at this node store the information computed in 1, 2,
3(below) in the stream object for each node in the stream.
1. Given the streams starting and ending locations determine the path to all the
stream destinations.
2. Create the path node vector, the path node vector is a string of bits, one bit per
graph node. A bit set to 1 if the node is supposed to process (display or
transmit) this stream, otherwise it’s 0.
3. Compute the DV for each stream, the DV is a string of bits, one per graph
node, where a 1 represents a node in the path of the stream from the current
node to the next destination.
Operation
For each stream of this Ensemble:

1. Obtain a stream element.
2. Attach it’s Position Vector.
3. Send the elements of this data stream to nodes represented by 1’s in the DV.

Then for each Ensemble passing through or originating at this node, if all
required Ensembles elements are available (either from the network or from the
multimedia application).Next use the Ensemble’s stream coordination rules to
create a list of elements to be forwarded. Extract the PV from the stream element.
Compute the Distribution Vector doing the logical AND of the bits of Position
Vector with the bits in Adjacency Vector for the current node. Then,
1. Send the elements of this data stream to the nodes represented by 1’s in the
DV, and
2. Update the control arrays to indicate this ensemble has been processed.
Building a Distribution Vector
Given the directed graph G of the nodes in the figure drawn previously
compute the adjacency matrix for each node at initialization. A modified Dijkstra
subroutine to the graph to determine the routing for every stream and to build the
Distribution Vector to control the routing through the network. Thus, the path for
stream S3 are
SO3, ISS3, D1
SO3, ISS3, D3
Once this paths are found, it is merged to single path list with no
duplicate entries(SO3, D1, D3, ISS3),using the same ordering of nodes the
Adjacency vector is computed which is as written below
where the overbar indicates that the node isn’t in the path for this stream
in the path for this stream in the Ensemble and 001001010010 is the Position
vector for the stream SO3.

To determine the routing from the current node , SO3, I perform a bitwise
AND of the Position vector for S3(001001010010) with the Adjacency vector
for SO3 (000000000010), giving the Distribution vector and (000000000010)
representing ISS3 as this elements next destinations.
At ISS3, (000001110000) is the Adjacency vector , perform an AND

operation on this result with the position vector sent with the stream
(001001010010) to get the Distribution vector (000001010000), which
corresponds to nodes D1 and D3. Thus, these are this element’s next destinations.
At D1 and D3, the program recognizes that the current node is the target ( the
resulting AND operation will be all zeros).The window created for Ensemble E1
will display the element the element in the corresponding elements from the SO1
and SO2 when they arrive.

Transmission of Data and Protocol Used
ECP creates an object class, Gnodedata, that maintains all the information
about a node and includes multiple occurances of the class Ensemble – one for
each group of data streams the node will process. ECP accesses a Gnodedata
object from the parametric data at a node n of the graph G. When the algorithm
determines that a stream is to be processed , the ECP at the node accesses all the
data pertaining to that stream from within Ensemble E. The Gnodedata maintains
such relevant data such as mapping from the virtual to real nodes and mapping
streams identifiers to and from Ensembles and Adjacency vector. Ensemble E
stores identifiers for it’s streams , Position vectors for each streams and rules for
merging streams, such as those used for synchronizing Ensemble streams in the
Algorithm.
When an E system transmits a stream element, ECP concatenates the

stream with identifying data, such as a stream ID and PV. Using the stream ID,
we can get directly to to the Ensemble data in the Gnodedata object, then
determine which other streams will be available and whether or not they are.
Each receiving location can use this data to quickly determine where to forward
the element when all Ensemble content is available. This organization let us
rapidly map from stream to ensemble and viceversa and from virtual node to IP
address. It also provides the underlying structure for graph traversals.
One immediate advantage of this mechanism is the reduction of data

rebroadcasts, because only nodes with more than one adjacent node must send
the data only to those adjacent node. Additionally, in the absence of graph
reconfiguration, the ECP at the nodes doesn’t have to recomputed complex
multicast routing at each rebroadcaster. In the event of reconfiguration, the
routing.

Computation is still a simple AND operation, although all vectors would

have to be modified. The underlying TCP/IP manages the actual routing to the
specified graph node. ECP also lets any node provide update information to
other nodes with respect to Ensembles and streams for existing Ensembles. The
basic program structure, however, doesn’t preclude dynamic changes to the
graph.
RTP
RTP is designed as an end-to-end transport protocol that is suitable for

unicast or multicast transmission of real-time data, such as interactive audio or
video. RTP follows the two principles:
Application Level Framing: The key architectural principle is Application

Level Framing. The idea is that the application should break down the data into
aggregates, which are meaningful to the application, and which do not dependent
on a specific network technology. These data aggregates are called Application
Data Units (ADUs). The frame boundaries of ADUs should be preserved by
lower levels, that is, by the networksystem.
The rule, by which the size of an ADU is chosen, states that an application
must be able to process each ADU separately and potentially out of order with
respect to other ADUs. So, the loss of some ADUs, even if a retransmission is
triggered, does not stop the receiving application from processing other ADUs.
Therefore and to express data loss in terms meaningful to the application, each
ADU must contain a name that allows the receiver to understand the place of an
ADU in the sequence of ADUs produced by the sender. Hence, RTP data units
carry sequence numbers and timestamps, so that a receiver can determine the
time and sequence relation between ADUs. The ADU is also the main unit of
error recovery. Because each ADU is a meaningful data entity to the receiving
application, the application itself can decide about how to cope with a lost data

unit: real-time applications, such as digital video broadcasting, might prefer to

simply ignore a few lost frames instead of delaying the presentation until the lost
frames are retransmitted, whereas file transfer applications cannot accept the loss
of a single data unit. In addition, if the application has the choice of how to deal
with a lost unit, the sender can decide whether to buffer the data units for
potential retransmission, to recompute the lost units if requested again, or to send
new data that which diminishes the harm done by the loss of the original ADU.
Integrated Layer Processing : Because application level framing breaks down

the data in pieces that an application can handle separately from other data units,
all processing of a single, complete ADU can be done in one integrated
processing step for reasons of efficiency. This engineering principle is called
Integrated Layer Processing. Layered isolation, as employed in conventional
protocol stacks, is suitable for the network layer and below, they argue that many
of the functions of the transport and above layers could be structured in a way
that would permit the use of the more efficient IntegratedLayerProcessing.
Especially for RISC systems, whose performance is substantially limited by the
costs of memory cycles, an integrated processing loop is more efficient than
several, isolated steps that each read the data from memory, possibly process it in
someway, and write it back to memory.
RTP is used in combination with other network or transport protocols---
typically on top of UDP---as visualised in Figure.

The RTP specification recommends the use of two different generalised

destination ports within one RTP session, one port for the reception of RTP
payload packets and one for RTCP control packets. If RTP is used in
conjunction with RSVP, one RTP session corresponds to two RSVP sessions,
which are identified by the addresses of the RTP data and control destination
ports, respectively. RTP supplements the data delivery functions of the
underlying protocols with the following services:
• Payload type identification.

• Sequence numbering.
• Timestamping.
It should be noted that RTP itself does not make any QoS commitments,
does not guarantee reliable, timely, or in-order delivery, and does not enforce any
error treatment measures. However, extensions, add reliability to RTP for
applications that cannot tolerate packet loss, for instance white-board
applications. The accompanying RTP Control Protocol (RTCP) facilitates
monitoring of the delivery QoS, and conveys rudimentary information about the
participants of an RTP session.
RTP and RTCP’s specification serves only as a protocol framework; RTP

is intended to be tailored to the needs of particular applications by additional
specifications:
• Payload format specification documents, which define how a particular

payload is to be carried in RTP. Currently, payload format specification
RFCs exists for H.261 video streams, for CellB video encoding], for
JPEG-compressed video, and for MPEG video.
• A profile specification document, which defines a set of payload type
codes and their mapping to payload formats, as well as any extension or

modification of the RTP message headers that are necessary for a specific
class of applications.
RTP Payload Transmission
RFC 1889 introduces the term of an RTP session to describe a set of

participants that communicate via a particular pair of destination transport
address, for example a multicast IP address together with two UDP ports for
control and payload data. Within one session, only a single payload type and the
associated control information are transmitted; this rule has several
consequences:
• Multiple RTP sessions must be used for multimedia applications.

• Demultiplexing of the received data streams by the payload type is
avoided, following the principle of integrated layer processing.
• Different QoS reservations can be established for each session in
accordance with the different needs of each medium and each receiver's
possibilities.
An RTP packet consists of a fixed header, a variable-length list of sources

that contributed to the payload in the packet, a potential header extension as
defined in a profile specification, and the actual payload, which is encoded
according to a payload format specification.
The fields of highest importance in the RTP packet header are:
• Synchronisation source (SSRC) identifier. A receiver uses the

synchronisation source identifier to demultiplex the packets received via
one destination port. Therefore, each SSRC identifier must be unique
within one RTP session. All packets from one synchronisation source fit
into the same timing and sequence numbering space.

• Sequence number. The synchronisation source increments by one the

sequence number of each RTP data packet sent in one session. This
number can be used by a receiver to restore the sequence of packets
disordered during the transmission, to detect packet loss, and to compute
the number of expected and lost packets.
• Timestamp. The timestamp describes the sampling time of the first octet
of the payload data carried by the packet. The sampling instant must be
measured by means of a clock, which produces timestamps increase
monotonically and linearly in time. The clock frequency that is used for
the mapping of timestamps to wall clock time should be layed down in a
protocol or payload specification, or could be recomputed with the help of
NTP timestamps sent within RTCP packets. A receiver can use the
timestamps for intra- and inter-stream playout synchronisation as well as
for inter-arrival jitter estimation.
An RTP data packet does not contain any length indication; an application
must either rely on the protocol used beneath RTP to provide framing
mechanisms, or, in case the underlying protocol provides a continuous octet
stream abstraction, define a method of encapsulating RTP packets in the octet
stream.
Control and Feedback Information
RTCP control packets are sent periodically (with small random time
variations to avoid traffic bursts) to the same (multicast) host address as the RTP
data packets. Their content facilitates:
• QoS monitoring and congestion control. The primary function of RTCP
messages is to provide feedback on the quality of the data distribution.
The conveyed information can be used for flow and congestion control, to
control adaptive encodings, and to detect network faults.
Applications that produce payload data generate RTCP sender reports.

These reports contain counters of sent packets and octets that allow other
session participants to estimate a sender's data rate.
Applications that have recently received packets issue RTCP receiver
reports, which contain the highest sequence number received, loss
estimations, jitter measures, and timing information needed to calculate
the round-trip delay between the sender and the receiver.
• Media synchronisation. Sender reports contain an NTP timestamp and an
RTP timestamp. The RTP timestamp describes the same instant as the
NTP timestamp but is measured in the same units as the timestamps issued
in the data packets of the sender. These two timestamps allow to
synchronise a receiver's playout clock rate with the sampling clock rate of
the sender. In addition, a receiver can use this RTP/NTP timestamp
correspondence information to synchronise the playout offset delay of
related streams.
• Member identification. RTP data packets and most RTCP packets carry
only an SSRC identifier but convey no other context data about a session
participant. Therefore, RTCP source description packets are sent by both
data senders and receivers. They contain additional information about the
session members, especially the obligatory canonical name (cname),
which identifies a participant throughout all related sessions independently
from the SSRC identifiers. The representation of the canonical name must
be understandable by both humans as well as machines. Other conveyed
information includes email addresses, telephone numbers, the application
name as well as optional application-specific information. An application
that decides to leave a session must transmit an RTCP bye packet to
indicate that it will not participate in the session anymore.
• Session size estimation and control traffic scaling. The total control
traffic generated by all participants in a session should not exceed a small
percentage of the data traffic, typically 5 percent. The control messages
from other session members enable a participant to estimate the session

size and to adapt its control packet rate, so as to remain within the limit of
the control traffic share. So, RTP scales up to large numbers of
participants.
Different schemes have been developed to exploit delivery feedback

information in order to estimate the network congestion state and to adjust the
application bandwidth accordingly. These schemes work for applications that can
scale their media quality and their data rates to a given bandwidth value.
Busse, Deffner, and Schulzrinne propose a simple though interesting and
workable mechanism. The fraction of lost packets, conveyed by normal RTCP
receiver reports, is used as the primary indicator of the congestion state of the
network: a data sender classifies the network path to each receiver as
UNLOADED, LOADED, or CONGESTED. Depending either on the average
classification of all paths or on the worst path, the sender makes an adjustment
decision about its sending behavior it may increase, hold, or decrease its
application bandwidth.
In a different approach instead of using the information from standard

RTCP messages, a sender solicits congestion state information from a subset of
the receivers, and then decides about appropriate bandwidth adjustments.
Current implementation
In February 2001, ECP began running on multiple systems. To reduce
extraneous delay factors, the program uses textual data only. This should also
simplify performance measurement. In May 2001, I had enough physical systems
to fully implement the network graph in Figure 1. In August 2001, I began
working with sufficiently large data streams (more than 200 records) to establish
some statistically meaningful information. Raw measurements show that
Ensemble segments arrive within 10 ms of each other from systems that are
within one hop differential from their destination, even though delays between
Ensembles can exceed this by a factor of 4. This work continues.

Configuration
The system is currently implemented on seven systems running SunOS

5.6 (UNIX), compiled with g++ and one MS Windows98 machine, and compiled
with MS Visual C++ 5.0. The Windows machine controls the systems using
Hummingbird’s Exceed software, so all the UNIX systems appear on the
Windows 98 screen. Graph manipulation functions come from the LEDA
package which is also provides all the classes in the C++ Standard Template
Library, as well as application independent, cross-platform windowing(X and
MS).
Scalability
Because the program maintains the network’s graph structure, growth of

the current implementation design is restricted by the amount of virtual memory
available. The time available to search the graph for all streams’ routing at
initialization limits the number of nodes in the network. A larger graph would
slow program startup, but would only minimally affect the steady-state
performance. The search for the data structure for a graph node is O(n). The
number of streams is not a major performance bottleneck as the search for stream
information is also O(n).

Conclusion
The Ensembles coordination program will be used in almost all the

multimedia application since it reduces the buffer required and minimizes delay.
The next step in this field is to transmit the effects of transmission delays on the
coordination and presentation of data. Given that the graph is available at all
nodes, ECP could easily allow dynamic reconfiguration as well as operations on
the graph itself. A program segment can reduce the information to textual format
for transmitting the new graph to all nodes. ECP could also extend graph to add
new conference attendees, which would allow users to join and leave a
continuing conference at will, and new conferences.

References
• http://www.mpi-sb.mpg.de
• http://computer.org/publications/dlib
• csdl.computer.org/comp/mags
• www.starbak.com/news_events/

ABSTRACT
Managing packets in distributed multimedia environment involves

coordinating and synchronizing multiple datastreams. The Ensembles
Coordination Program provides the required coordination, reduces delay using
path selection and message rebroadcasting, and allows the end application to
manage the synchronization within the streams.
One immediate advantage of this mechanism (ECP) is the reduction of

data rebroadcasts, because nodes with more than one adjacent nodes must send
the data and only to those adjacent nodes.

ACKNOWLEDGMENT
I express my sincere thanks to Prof. M.N Agnisarman Namboothiri
(Head of the Department, Computer Science and Engineering, MESCE),
Mr. Sminesh (Staff incharge) for their kind co-operation for presenting the
seminar.
I also extend my sincere thanks to all other members of the faculty of
Computer Science and Engineering Department and my friends for their
co-operation and encouragement.
Ajan Daniel Kutty

CONTENTS
• INTRODUCTION
• COORDINATING DISTRIBUTED MULTIMEDIA DATA
o Synchronization types
• ARCHITECTURE AND IMPLEMENTATION
o Structure
o System Development
• REPRESENTING CONFERENCES
o Minimizing Delay
o Merging and routing Streams
o Flits
• MANAGING STREAM SEGMENTS
o The Ensemble Algorithm
• TRANSMISSION OF DATA AND PROTOCOL USED
o RTP
RTP Payload Transmission
Control and Feedback Information
o Current implementation
o Configuration
o Scalability
• CONCLUSION
• REFERENCES

Managing Data in Multimedia Conferencing

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Managing Data in Multimedia Conferencing

Transféré par

Droits d'auteur :

Formats disponibles

Seminar Report’03 Multimedia Conferencing

Distributed multimedia conferencing systems break the information to be

Most work to date on packet management in distributed multimedia

This report discusses the coordination and synchronization of multiple data

Dept. of CSE 1 MESCE, Kuttippuram

Coordinating Distributed Multimedia Data

This coordination methodology is independent of the network delays

In ECP , an ensemble is a collection elements “A” from a stream to be

We can coordinate the elements of multiple data streams at three points: a

The related problems such as graph or network partitioning, fault

Dept. of CSE 2 MESCE, Kuttippuram

Processing at en E-system occurs at two stages. Stage one reads all

The ordering properties are as explained below:

Multiple source ordering: If different sources send messages M1 and M2 all

Dept. of CSE 3 MESCE, Kuttippuram

Note that there is a clear distinction between “doing“ and “seeing” in

This report makes no pre-judgments about implications. On a fast LAN

Intra object synchronization: It is the time relation between the units of a

Some application requires provisions where the processing program must

Dept. of CSE 4 MESCE, Kuttippuram

Site synchronization: In this type of synchronization ECP provides the required

Global synchronization: In this type of synchronization all sites provides all

Ensembles coordination ensures that the transmission of element of a

Dept. of CSE 5 MESCE, Kuttippuram

Architecture and Implementation

ECP manages multiple segments of multiple data streams as they traverse

To simplify development and testing, the current implementation is a

In the truncated version, a multimedia application developer could test an

Each E-system has two control files

To initiate a conference, the conference operator starts all E-systems.

Dept. of CSE 6 MESCE, Kuttippuram

A sequential dependency exists within a single stream in multimedia

Dept. of CSE 7 MESCE, Kuttippuram

At a rate where i matches j, rather a relationship exists between the values

Where E is an Ensemble, e is the Ensemble number, m is the maximum

Dept. of CSE 8 MESCE, Kuttippuram

Where S represents a stream, Q is the quantity of data segments in the

As previously noted, a movie with both a audio and an audio portion

Given the synchronization requirements and the desire to reduce

We can extend interobject synchronization to more than two streams, as

Dept. of CSE 9 MESCE, Kuttippuram

recordings are played together. Because multimedia conferencing is human

Merging and routing Streams

Dept. of CSE 10 MESCE, Kuttippuram

neither stream sources nor final destinations, are intermediate synchronization

For Example in the figure drawn previously we must forward stream S3

Dept. of CSE 11 MESCE, Kuttippuram

Managing Stream Segments

Normally three arrays to manage the selection of segments for display or

The Ensemble Algorithm

The Ensemble coordination must perform several initializations before it

Dept. of CSE 12 MESCE, Kuttippuram

For each stream of this Ensemble:

Dept. of CSE 13 MESCE, Kuttippuram

Building a Distribution Vector

Dept. of CSE 14 MESCE, Kuttippuram

At ISS3, (000001110000) is the Adjacency vector , perform an AND

Dept. of CSE 15 MESCE, Kuttippuram

Transmission of Data and Protocol Used

When an E system transmits a stream element, ECP concatenates the

One immediate advantage of this mechanism is the reduction of data

Dept. of CSE 16 MESCE, Kuttippuram