Design and Testing of two secure Video ...

antlertextureSoftware and s/w Development

Jul 14, 2012 (6 years and 6 days ago)


Design and Testing of two secure Video Conferencing applications based on

JMF (Java Media Framework) and VIC (Video Conferencing Tool)

1 2 1 1
L. Mengual , J. Bobadilla , R. Caballero , G. Hernández
DLSIIS, Facultad de Informática, U.P.M., Madrid, Spain
{lmengual, rcaballero ghernandez }

multimedia application, as well as to choose an
encryption algorithm fast enough to allow real time

We present two secure real-time video conferencing
Real time packet transmission should resolve the
solutions with JPEG coding using a cipher engine based
difficulties inherent in packet networks [12,.. ,16], among
on the Blowfish algorithm. One of these solutions is
which we have: the delay and loss of packets, the
developed from Java Media Framework (JMF) [1]. In
unordered delivery, the appearance of duplicated packets,
this case, our solution consists of encrypting frames
etc. Real Time Protocol (RTP) [2] is a protocol based on
coded with JPEG that are later encapsulated in packets
IP networks that provides end-to-end network delivery
of the RTP protocol [2] (Real Time Transport Protocol).
services for the transmission of the real-time data. RTP is
Our cipher system is based on the Blowfish algorithm [3]
network and transport-protocol independent, thought it is
of the Cryptix [4] open source cryptographic software
often used over UDP. RTP enables you identify the type
of data being transmitted, determines what order the
Another solution is developed from VIC (Video
packets of data should be presented in, and resolve the
Conferencing Tool)[5]. In this case, our solution consists
problem of synchronize media streams from different
of encrypting the UDP packets that contain the JPEG
sources. While RTP does not provide any mechanism to
coded frames incorporated in RTP packets. In this paper
ensure timely delivery or provide other quality of services
we analyse the solutions proposed and test the
guarantees, it is augmented by the protocol RTCP (RTP
implementations developed in different data networks
Control Protocol) [2]. It provides control and
(LAN/ WLAN, Frame Relay).
identification mechanisms for RTP transmissions and

enables you to monitor the quality of the data distribution.
Key words: Secure video conferencing systems, JPEG
Over the past few years, a collaborative effort in the

Codec, Blowfish algorithm, LAN/WLAN
network research community has produced a suite of

tools and different systems for multimedia video
1. Introduction
conferencing over the Internet like JMF [1], VIC [17],

Marratech [18], Isabel [19], GnomeMeeting[20], Access
Usage of the Internet for on-line banking, shopping
Grid [21], MPEG-4IP[22] and others.
and many others applications like Video Conferencing
We have chosen some of the most well known tools,
systems is growing exponentially. Some of these
such as JMF and VIC, and we have created real time
applications involve the transfer of sensitive information
applications with symmetric-key encryption. In this paper
such as credit card details. Hence to support these type of
we present the conclusions reached in a comparative
networked transactions a number of security techniques
have been developed. [7,..11].
Java Media Framework (JMF) is a versatile
At the present, the problem of the security in the
Application Programming Interface (API) for
communications over Internet has extended to real-time
incorporating time-based media into Java applications
communications. The necessity to protect multimedia data
and therefore portable and independent of the underlying
distributed over Internet makes it necessary to encrypt the
hardware. Any data that change meaningfully with
audio/video flows transported on Internet. The aim is that
respect to time can be characterized as time-based media.
the resulting flow allows its later reproduction in real
Such media data can be obtained from a variety of
time. It is therefore very important to choose a specific
sources, such as cameras, microphones etc. To send or
place to incorporate the cipher engine in the code of our
receive a live media broadcast or conduct a Video

This work is supported partially by Science and Technology Ministry of Spain under the projects: “A Multi-Agent System Architecture for the
automatic and dynamic Implementation of security protocols (TIC2001-3376)” and “Open System of Multimedia Digital Presentation in Real Time
(TIC2000-1734-C03-02)” RT RTP PACKE P PACKET T
Conference over Internet or Intranet, you need to be able
to receive and transmit media streams in real time. JMF
IP IP H He ea ad de er r RTP RTP Header Header
uses RTP for receiving and transmitting media streams UD UD UDP P P Header Header Header
20 O 20 O 20 O 20 O 20 O 20 O 20 O 20 Oc c c c c c c ctttttttt........
8 O 8 O 8 O 8 O 8 O 8 O 8 O 8 O 8 Oc c c c c c c c cttttttttt......... 12 O 12 Oc ctt..
across the network. This way, JMF can: play various
multimedia files in a Java applet or application (The

formats supported include AVI, MIDI, MPEG,
Figure 1: Incorporation of encrypting in a video
QuickTime, and WAV); play streaming media from the
conferencing application implemented with JMF
Internet; capture audio and video with your microphone

and video camera; process time-based media and change

the content-type format; transmit audio and video in real-
In the VIC solution we have incorporated the Blowfish
time on the Internet; broadcast live radio or television
algorithm from [6] in the part of the code in charge of
constructing the RTP packets and incorporating them in
VIC (Video Conferencing Tool) is a real-time video
the UDP datagrams. The solution used in this case (see
conferencing application over the Internet developed by
Fig. 2) is therefore not related to the chosen Codec. The
the Network Research Group at the Lawrence Berkeley
most important implementation work involved here was
National Laboratory in collaboration with the University
to locate the classes in charge of transporting the RTP
of California, Berkeley. VIC was designed with a flexible
packets that contain the video frames, and within them, to
and extensible architecture to support heterogeneous
encrypt the UDP datagrams generated.
environments and configurations. For example, in high

bandwidth settings, multi-megabit full-motion JPEG
streams can be sourced using hardware assisted
compression, while in low bandwidth environments like
IIP P H He ead ader er
UDP UDP He Head ader er RT RTP P He Head ader er
2 2 2 2 2 2 2 20 0 0 0 0 0 0 0 O O O O O O O Oc c c c c c c ct. t. t. t. t. t. t. t.
the Internet, aggressive low bit-rate coding can be carried 8 O 8 O 8 O 8 O 8 O 8 O 8 O 8 Oc c c c c c c ctttttttt........ 12 12 12 12 12 12 12 12 O O O O O O O Oc c c c c c c ctttttttt........
out in software.
VIC is based on the Draft Internet Standard Real-time

Transport Protocol (RTP) developed by the IETF
Figure 2: Incorporation of encrypting in the VIC
Audio/Video Transport working group. RTP is an
application-level protocol implemented entirely within
VIC. You need no special system enhancements to run

RTP. Although VIC can be run point-to-point using
3. Video Conference Application Structure
standard unicast IP addresses, it is primarily intended as a
based on JMF
multiparty conferencing application. To make use of the

conferencing capabilities, your system must support IP
The incorporation of security services to a video
Multicast, and ideally, your network should be connected
conference application, that has been developed with
to the IP Multicast Backbone (MBone).
JMF, implies to encrypt the video/audio data that are

transported by the network. This circumstance outlines
2. Solutions Presented
several problems to solve: a first problem resides in the

election of an encryption algorithm fast enough to
In this paper we compare two solutions for real time
guarantee the real time communications. Another
video transmission with symmetric-key encryption. The problem resides in choosing the proper location of the
Blowfish algorithm is used in both solutions. The two
cipher engine inside the JMF architecture of classes.
evaluation contexts are: an owner application developed
Finally, a last problem and, that’s not trivial, is the
using the API in Java of Java Media Framework, and the
distribution of the session key among the system users.
VIC, a video conferencing application developed by the
Regarding the previous problems our alternative
Lawrence Berkeley National Laboratory. consist in, firstly, selecting the Blowfish algorithm as the
In the video conferencing with JMF solution we opted
responsible cipher engine. Blowfish is a symmetric block
for the implementation of a secure JPEG Codec using the
cipher of 64 bit block and uses a variable-length key,
Codec dynamic registration services provided by the JMF
from 32 bits to 448 bits, fast enough to make the
API. This means that in this case (see Fig. 1) we designed
communication in real time possible.
a JPEG Codec in which the RTP packets have a payload
We decide to include the cipher engine in the classes
that corresponds to the encrypted video frames using a
that implement the JPEG video Codec selected. In
cipher engine based on Blowfish using the Cryptix library
particular, the location was the classes of the JMF
[4]. architecture denominated "...packetizer/...depacketizer”.

The “….packetizer” class is an implementation of the “BasicCodec” interface inside the architecture of classes basically of encapsulating the data that receives from the
and interfaces of JMF. This class encapsulates the JPEG processor in RTP packets.
data in RTP packets to be sent through the network. The The "...jpegencrypted.Packetizer" object (see Fig. 5)
class "...depacketizer" is invoked in the receiver. This was created from the “SecureCustomTrans” class by the
class receives RTP packets in a buffer and depacketizes “registerCustomPayload” method by means of a
them to obtain a complete frame in JPEG format. Our constructor that receives as parameter a session key
solution consists on encrypt the video data before its distributed by the security protocol. In this constructor the
incorporation to the RTP packets (see Fig. 3). “CipherEngineCodec” object is created. This will be in
charge of encrypting video data with Blowfish algorithm.

The kernel of the Codec “…jpegencrypted.Packetizer” is
the “process” method that carries out the processing of
the input signal through the “inbuf “object and it returns
P Pack acket eti iz zer er D De eP Pa acket cketiz izer er
the encryption data through the “outBuf “object.
Nat Nati iv ve e
Na Nat ti iv ve e
D Deco ecod de er r
CI CIP PH HE ER R E EN NG GI IN NE E C CI IP PH HER ER EN ENG GI IN NE E public class Packetizer extends BasicCodec {
static final JPEGFormat fJPEG = new JPEGFormat(); static String
JPEG_ENCRYPTED = "jpegencrypted/rtp"; private MotorEncriptacionCODEC
SEC SECU UR RE J E JPEG PEG C CO OD DE EC C private byte[] mykey;

public Packetizer (byte[] key) {

inputFormats = new VideoFormat[] {new VideoFormat(VideoFormat.JPEG)};
outputFormats = new VideoFormat[] {new
Figure 3. Secure JPEG CODEC in JMF VideoFormat(JPEG_ENCRYPTED)};
MyCipherEngine =new CipherEngineCODEC(); } // Packetizer
public synchronized int process(Buffer inBuffer, Buffer outBuffer){
The basic structure of our application is composed of
the “SecureCustomTrans” class (see Fig. 4). This class, byte [] inData = (byte[]) inBuffer.getData();
System.arraycopy(inData,offset + inBuffer.getOffset(),sincif,0,copyLength);
from its method main, obtains the session key in a secure
byte[] cifin = MyCipherEngine.BlowfishCipher(sincif, mykey);
way implementing a security protocol; next it carries out

} // Packetizer
the dynamic registration in the architecture JMF of the

secure video JPEG Codec that we have implemented
Figure 5. “...jpeg.packetizer “ class pseudocode
through “registerCustomPayload” method. Once

registered the new Codecs, the start method of the

“SecureCustomTrans” class invokes the methods and
4. Video Conference Application based on
functions of the JMF API to establish the RTP session.

public class SecureCustomTrans {
static Format myJPEGFormat
static Format myGSMFormat
One of the problems that arose when including
private byte[] key;
security in our video conferencing application based on
VIC was the way to add the security. We considered
static boolean registerCustomPayload () {.....}
private String createProcessors() { ...} several solutions depending on where the cipher engine
private String createTransmitter() { ...}
was included. One possible solution would be to encrypt
at frame level, i.e. every time a frame is obtained from the
public static void main(String [] args) {
data source, the source should be encrypted by the cryptix.provider.Cryptix());
application. Another possible solution would be to design
security_protocol sp=new security_protocol ();
Key = sp. Get_Key ;
a Codec in such a way that it automatically encrypts all
the information that goes through it. This Codec will be
used to encrypt and decrypt the information depending on
SecureCustomTrans sct = new SecureCustomTrans (..);
whether it is used by the transmitter or the receiver. The
String result =sct.start(); }//main
last solution to this problem, which was the one that was

finally chosen, is to add the security at socket level, i.e. to
Figure 4. SecureCustomTrans class pseudocode
detect the socket that is being used for the transmission

and reception of the data of the corresponding session and
This way the “SecureCustomTrans” class creates two
to encrypt the data just before it is sent by the transmitter
new classes: “CreateProcessor” and
and decrypt it as soon as it is received by the receiver.
“CreateTransmiter”. The first one creates what in JMF is
To achieve this objective we used a Blowfish cipher
called proccesor that is the entity in charge of managing
engine using the source code [6] as the starting point,
the input signal, to choose the appropriate Codec and to
which was fast enough to allow it to work in real time.
return the encoded data. The second class takes charge
The code that implements and makes the data encryption possible, using the Blowfish API functions, is in LAN at 10/100 Mbps or FR at 2 Mbps, whilst only 12
incorporated in the Network class methods. The fps are reached in WLAN (see Fig. 7.a). With a JPEG
“Network” class (see Fig. 6) incorporates methods that quality of 0.7, 11 fps are reached in LAN at 10/100 Mbps
implement the transfer of information between entities or FR at 2 Mbps, whilst only 8 are reached in WLAN (see
through the Windows Sockets interface and it is part of the Fig. 7.a).
group of classes invoked from the TclObject class. We
have added the symmetrical cipher engine to these 5.1.2 Relationship between the number of frames and
methods so that before sending any data it is encrypted the quality without encryption. The set of tests carried
with the session key, and as soon as any data is received it
out covers a range of JPEG qualities from 0.2 to 0.7,
is decrypted with the same key. obtaining a clear conclusion from the reduction in the
number of frames from a range of 14-12 fps with quality
T T T T T T Tc c c c c c cl l l l l l lO O O O O O Ob b b b b b bj j j j j j ject ect ect ect ect ect ect 0.2 to a range of 11-8 fps when the quality is increased.
T T T T T T T T Tc c c c c c c c cl l l l l l l l lO O O O O O O O Ob b b b b b b b bj j j j j j j j ject ect ect ect ect ect ect ect ect
By increasing the quality the JPEG algorithm is
compressed to lesser extent and the JPEG frames are
Tr Tr Tr Tr Tr Tr Transm ansm ansm an an an ans s s sm m m mi i i i i i it t t t t t ter er er er er er er
Ne Ne Ne Ne Ne Ne Ne Ne Netw tw tw tw tw tw tw tw two o o o o o o o or r r r r r r r rk k k k k k k k k

Se Se Se Se Se Se Ses s s s s s si i i i i i io o o o o o on n n n n n nMana Mana Mana Mana Mana Mana Manage ge ge ge ge ge ger r r r r r r
5.1.3 Relationship between the number of frames, the
IP IP IP IP IP IP IP IP IPN N N N N N N N Ne e e e e e e e et t t t t t t t tw w w w w w w w wor or or or or or or or ork k k k k k k k k
quality and Bits per second without encryption. In
direct association with the previous conclusion we can
V V V V V V Vi i i i i i ideo deo deo deo deo deo deoS S S S S S Sesi esi esi esi esi esi esio o o o o o onM nM nM nM nM nM nManage anage anage anage anage anage anager r r r r r r
point out the following: At low quality, we have

mentioned that more small frames are transmitted due to

the strong compression. Therefore, in this situation less
Figure 6. Class Structure in VIC
bandwidth is required, oscillating between approximately
450 Kbps (WLAN)-500 Kbps (LAN/FR) with quality 0.2

and almost 1250 (WLAN)-1450 Kbps (LAN/FR) with
5. Performance Study
quality 0.7.

A wide range of tests were carried out to prove the
5.1.4 Cost of real time encryption. With quality 0.2 we
features of the implementations made. The tests consisted
can see that the average rate of fps reached is around 12
of evaluating the performance of real time video
fps in LAN/FR whilst in WLAN only 11 fps are reached
transmission with JPEG code in the two implementations
(see Fig. 7.a). With quality 0.7 we can see that the
developed, VIC and JMF. The analysis of the
average rate of fps reached is around 7 fps in LAN/FR and
transmission was carried out by evaluating the
WLAN only 6 fps are reached (see Fig. 7.a).
incorporation of a Blowfish cipher engine and by using
From the analysis of the results we can deduce that the
different Network technologies (LAN 10 -100 Mbps,
cost of encryption at low quality (0.2) is approximately 1-
Frame Relay 2 Mbps and WLAN 11 Mbps). Finally, the
2 fps: From 14 fps sent without encryption to 12 fps
possible influence of abrupt movements in front of the
encrypted in LAN/FR. And from 12 fps sent without
camera was studied.
encryption to 11 fps encrypted in WLAN. By increasing
We must point out that in both evaluation
the quality to 0.7 the cost of using real time encryption is
environments a fixed RTP packet size of 960 Bytes was
also increased, reaching a difference of 4 fps in LAN/FR:
used in the VIC environment and 1024 Bytes in the JMF
From 11 fps sent without encryption to 7 fps encrypted.
environment. The relative comparison of features was
And of 2 fps in WLAN: From 8 fps sent without
also carried out in the Windows 2000 operating system
encryption to 6 fps encrypted.
with a Pentium II processor at 450 MHz with 512 Mbytes
on the transmitter and a Pentium II processor at 400 MHz
5.2 Comparison of Results JMF-VIC
256 Mbytes on the video receiver.

In relation to the curves without encryption, the
5.1 Results in JMF behaviour of VIC and JMF is similar as regards the fps
sent. This way, this value increases to 12 fps at medium

quality (0,5) with LAN/FR and 10 fps in WLAN, for
5.1.1 Cost of frame transmission protocol. Different
example (see Fig. 7). The difference is in the bandwidth
data networks have been evaluated: LAN (Local Area
used from 700 Kbps (WLAN)-750 Kbps (LAN/FR) in VIC
Networks) 10 -100 Mbps, Frame Relay 2 Mbps and
and 780 Kbps (WLAN)-900 Kbps (LAN/FR) in JMF.
WLAN (Wireless Local Area Networks) 11 Mbps. At
The number of packets required also varies
JPEG quality 0.2, 14 fps (frames per second) are reached
proportionally: from 90 pps (WLAN)-100 pps (LAN/FR) in VIC and 110 pps (WLAN)-130 pps (LAN/FR) in JMF. 3,5 times faster in C/C++ tests than in Java tests (3,03
The explanation could be found in the optimisation of the using a 400-Mhz. CPU and 3,98 using a 1-GHz. CPU).
JPEG Codec of VIC as opposed to JMF and the slight Both solutions show a similar performance without the
difference in the size of the RTP packet used in VIC and use of the cipher engine; however, by using a JPEG
JMF. quality of more than 0.3, the secure JMF version produces
an average of 2 frames per second less than the VIC
S S Se e ec c cu u ure re re J J JM M MF F F (a (a (a) ) )
version. This is the price we have to pay in order to use
13 13 13 JMF, a portable, flexible and reliable java-based
0.2 0.2 0.2 0.2 0.2 0.2
framework where the new codecs and digital drivers are
0. 0. 0. 0. 0. 0.2 2 2 2 2 2
0.3 0.3 0.3 0.3 0.3 0.3
11 11 11
0.5 0.5 0.5 0. 0. 0. automatically maintained.
0.3 0.3 0.3 0.3 0.3 0.3
0. 0. 0.6 6 6

9 9 9
0.5 0.5 0.5 0.7 0.7 0.7
6. Conclusions
7 7 7

0.7 0.7 0.7 0.7 0.7 0.7
0.6 0.6 0.6
5 5 5 In this work we have presented two practical real time
250 250 250 500 500 500 750 750 750 1000 1000 1000 1250 1250 1250
video conferencing solutions using the Blowfish cipher
engine. In the first solution, using JMF we obtain a
w w wiiittth h h enc enc encr r ry y ypt pt ptiiio o on n n w w wiiittth h hout out out en en encr cr cry y yp p ptttiiion on on
flexible solution, which, through the dynamic registration
of Codecs, allows users to choose the security services in
Sec Sec Sec Sec Sec Sec Secu u u u u u ur r r r r r re e e e e e e VI VI VI VI VI VI VIC ( C ( C ( C C C C b b b) ) )
the JPEG Video transmission. In this solution we encrypt
13 13 13 13 13 13 13
the content of the RTP packets. The use of the Java
0.2 0.2 0.2 0.2 0.2 0.2 0.2 0.2 0.2 0.2
0. 0. 0. 0. 0. 0. 0. 0. 0. 0.3 3 3 3 3 3 3 3 3 3
language allows versatility in the video broadcast
11 11 11 11 11 11 11
0.4 0.5 0.4 0.5 0.4 0.5 0.4
0.5 0.6 0.5 0.6 0.5 0.6 0.5
platform. In the second solution, we propose a cipher
0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7 0.7
9 9 9 9 9 9 9 engine that has no relation with the Codec in the VIC
video conferencing environment. In this solution, the
7 7 7 7 7 7 7
content of the UDP packets that contain the video
conferencing frames is encrypted. The cipher engine used
5 5 5 5 5 5 5
developed in C/C++ has been used from [6].
250 250 250 250 250 250 250 500 500 500 500 500 500 500 750 750 750 750 750 750 750 10 10 10 10 10 10 1000 00 00 00 00 00 00 1250 1250 1250 1250 1250 1250 1250
The comparison of results reveals that both solutions
M M M M M M Mbps bps bps bps bps bps bps
present a similar rate of fps without the use of the cipher

engine, however there is a greater use of bandwidth in the
Figure 7. JMF-VIC Comparative test results. WLAN,
case of JMF. When using the Blowfish cipher engine the
400-MHz, CPU
differences are more significant as an average difference
of 3 fps is produced in the transmission of JPEG
Nevertheless, the most significant differences are
encrypted video. These differences can attributed, firstly,
centred on the results obtained using Blowfish cipher
to the difference in the efficiency of the cipher engine in
engine. Therefore, using VIC the average number of
Java as opposed to in C/C++, as we have already
frames sent with medium quality is 10 fps in LAN/FR and
mentioned, and, secondly, to the efficiency of the JPEG
9 fps in WLAN (see Fig. 7.b). In JMF on the other hand,
Codec in one version or the other.
we obtain 8 fps in LAN/FR and 7 fps in WLAN (see Fig.

7.a). The relative difference is therefore 2 fps. Using
7. References
encryption the use of bandwidth oscillates between 650

Kbps (WLAN) and 700 Kbps (LAN/FR) in VIC and 550
1. Java Media Framework (JMF):
Kbps (WLAN) and 650 Kbps (LAN/FR) in JMF. A clear
difference according to the lower number of frames sent
2. Schulzrinne, H, Casner, S., Frederick, R., Jacobson, V.
by JMF.
(Audio-video Transport working group) “RTP: A Transport

Protocol for Real-Time Applications”, RFC 1889, January
VIC and our JMF secure videoconferencing system
have been tested using a wireless network (WLAN
802.11b) and a 400-MHz CPU. Fig. 7 shows the test
3. Schneier B. “Description of a New Variable-length Key, 64-
Bit Block Cipher (Blowfish).”, Cambridge Security
results using different JPEG qualities (y-axis: fps
Workshop Proceedings Springer-Verlag, 1994.
achieved, x-axis: necessary bandwidth). We can observe
that the encryption algorithm processing overload affects
4. Cryptix: open-source cryptographic software libraries:
JMF more than VIC. This is mainly because Java does
not run as fast as C/C++; the Blowfish cipher engine runs
fps fps fps fps fps fps fps
fps fps fps5. McCanne, S., and Jacobson, V. “VIC: A Flexible 21. Access Grid:
Framework for Packet Video”. ACM Multimedia 95 -
22. MPEG-4IP:
Electronic Proceedings November 5-9, 1995 San Francisco.

6. Blowfish open source code:
7. Deswarte, Y.; Powell, D. "Internet security: an intrusion-
tolerance approach" Proceedings of the IEEE, Volume 94,
Issue 2, Feb. 2006 Page(s):432 - 441
8. Chang, S.S., Chiang, M.S. "An e-intelligence approach to e-
commerce intrusion detection". IEEE International
Conference on Granular Computing, 2005. Volume 2, 25-27
July 2005. Page(s):401 - 404. Vol. 2.
9. Kemmerer, R.A. , Vigna, G. "Hi-DRA: intrusion detection
for Internet security". Proceedings of the IEEE, Volume 93,
Issue 10, Oct. 2005. Page(s):1848 – 1857.
10. Ylitalo, J., Salmela, P., Tschofenig, H."SPINAT: Integrating
IPsec into Overlay Routing"First International Conference
on Security and Privacy for Emerging Areas in
Communications Networks, 2005. SecureComm 2005. 05-
09 Sept. 2005 Page(s):315 - 326.
11. Schwab, S.; Wilson, B.; Thomas, R. "Methodologies and
Metrics for the Testing and Analysis of Distributed Denial
of Service Attacks and Defenses". IEEE Military
Communications Conference, 2005. MILCOM 2005. 17-20
Oct. 2005 Page(s):1 – 7.
12. Mehra, P., De Vleeschouwer, C., Zakhor, A. "Receiver-
driven bandwidth sharing for TCP and its application to
video streaming". IEEE Transactions on Multimedia,
Volume 7, Issue 4, Aug. 2005 Page(s):740 – 752.
13. Qian Zhang, Quji Guo, Qiang Ni, Wenwu Zhu, Ya-Qin
Zhang "Sender-adaptive and receiver-driven layered
multicast for scalable video over the Internet". IEEE
Transactions on Circuits and Systems for Video
Technology, Volume 15, Issue 4, April 2005 Page(s):482 -
14. Ahmed, T., Mehaoua, A., Boutaba, R., Iraqi, Y. "Adaptive
packet video streaming over IP networks: a cross-layer
approach". IEEE Journal on Selected Areas in
Communications Volume 23, Issue 2, Feb 2005 Page(s):385
- 401.
15 Yan, J., Katrinis, K., May, M.; Plattner, B. "Media- and
TCP-Friendly Congestion. Control for Scalable Video
Streams". IEEE Transactions on Multimedia, Volume 8,
Issue 2, April 2006 Page(s):196 - 206.
16. Chou, P.A., Miao, Z. "Rate-Distortion Optimized Streaming
of Packetized Media". IEEE Transactions on Multimedia,
Volume 8, Issue 2, April 2006 Page(s):390 – 404.
17. Video Conference Tool (VIC): http://www-
18 Marratech:
20. GnomeMeeting: