?? java rtp implementation.htm
字號(hào):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0079)http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html -->
<HTML><HEAD><TITLE>Java RTP Implementation</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<META content="RTP; java; RTCP" name=keywords>
<META content="Brief description of project." name=description>
<META content="C:\Program Files\Microsoft Office\Office\html.dot"
name=Template></HEAD>
<BODY vLink=#800080 link=#0000ff bgColor=#ffffff>
<P></P>
<H1>java.net.RTP</H1>
<P>Waqar Ali<BR><I>Columbia University<BR>New York, NY 10027<BR>USA<BR></I><A
href="mailto:aliw@usa.net"><I>aliw@usa.net</I></A></P>
<ADDRESS> </ADDRESS>
<P>Akhil Nigam<BR><I>Columbia University<BR>New York, NY 10027<BR>USA<BR></I><A
href="mailto:anigam@lehman.com"><I>anigam@lehman.com</I></A></P><I>
<P> </P></I>
<H2>Abstract</H2>
<P>The Real-time Transport Protocol (RTP <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#references">[1]</A>)
has become a widely implemented internet-standard protocol for transport of
real-time data. It provides a mechanism for the participants to give feedback
about the service using the RTP Control Protocol (RTCP <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#references">[1]</A>).
This document presents the platform independent RTP implementation in Java. This
implementation, which is available as a java.net.RTP package, can be easily
incorporated into an application, which then has access to all of the transport
level features RTP and RTCP provide. This package also provides out of band
initialization classes, which implement a late-initialization protocol. These
classes could be used to implement a late initialization server which is capable
of synchronizing late-joining clients.</P>
<H2>Introduction</H2>
<P>This report describes the Java implementation of RTP protocol. It covers the
following topics.</P>
<P>1) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#related_work">Related
Work</A></P>
<P>2) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#Background">Background</A></P>
<P>3) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#architecture">Architecture</A></P>
<DIR>
<DIR>
<P>3.1) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#ObjectModel">Object
Model</A><BR>3.2) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#EventModel">Event
Model</A><BR>3.3) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#LateInitializationClientServer">Late
Initialization Client/Server</A></P></DIR></DIR>
<P>4) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#ProgramDocumentation">Program
Documentation</A></P>
<P>5) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#APIProgrammerDocumentation">Java
RTP API documentation</A></P>
<P>6) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#references">References</A></P>
<P>7) <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/java_net_RTP.tar.gz">Downloads</A></P>
<P> </P>
<H2><A name=related_work>Related Work</A></H2>
<DIR>
<DIR><B>
<P></B><A href="http://www.iasi.rm.cnr.it/iasi/netlab/netlabWelcome.html">RTP
Library:</A></P>
<P>C++ library which provides application independent implementation of the RTP
protocol. This library is available for DEC OSF/1 v3.2 and Solaris 2.3 platforms
only.</P><B>
<P></B><A
href="http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html">Java
Media Framework: </A></P>
<P>The Java Media Framework API (JMF) specifies a simple, unified architecture
to synchronize and display time-based data, such as audio and video, within Java
applications and applets. The JMF 1.0 API was developed by Sun Microsystems,
Inc., Silicon Graphics Inc., and Intel Corporation.<A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#references">[2]</A></P><B>
<P></B><A href="http://204.127.236.149/elemedia/px3230s.htm">Elemedia H.323
stack</A></P>
<P>The elemedia PX3230S H.323 Protocol Stack software module is a software
implementation of the ITU-T H.323 standard. The RTP/RTCP module supports header
validity checks, statistic logging, sender reports, reception reports, and a
system time-to-media time utility. <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#references">[3]</A></P><B>
<P></B><A href="http://webcanal.inria.fr/">Webcanal</A></P>
<P>WebCanal contains a set of networking packages and applications mainly for
information distribution using IP Multicast. WebCanal networking packages
include a Java implementation of RTP (real time transport protocol), LRMP,
SAP/SDP (session announcement protocol) and more. <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#references">[3]</A>
</P></DIR></DIR>
<H2><A name=Background></H2>
<H2>Background</H2>
<DIR>
<DIR>
<P><A name=architecture></A>The project was motivated by the need to have a
platform independent, multicast-capable RTP implementation, which could be used
in collaborative applications like the Whiteboard. The whiteboard application
has special initialization requirements where all the instances of the
collaborating whiteboards have to display the identical content, i.e. they need
to have a common state. This becomes a problem for late joiners which then have
to be synchronized and brought to a common state like the other instances, hence
there must exist either a dedicated server or such, which is capable of serving
such clients and is responsible to provide late joiners with historic data. A
generic functionality to build such a client and a server needs to be available
for such an application. The package was designed and developed to be modular
with a generic late-initialization client/server classes implementing a
late-initialization protocol.</P></DIR></DIR>
<H2>Architecture</H2>
<DIR>
<DIR>
<P></A>This section describes the architecture of the software. When
appropriate, the design decisions and alternatives are discussed.</P>
<H3><A name=ObjectModel>Object Model</H3>
<P>Overall architecture of the software was motivated by the need to have a
modular, simple and platform-independent RTP implementation which could be
easily integrated into any application requiring RTP as its transport protocol.
By choosing Java as the development platform, the goal of having
platform-independent implementation was immediately met. The object oriented
features of Java and the language's simplicity made it possible to make the
software simple and modular.</P>
<P>Session<B>:</P></B>
<P>The top most class the user of the package interacts with is Session. This
class encapsulates the RTP and RTCP related setup, startup and shutdown
procedures. Session also serves as the interface using which object's states and
their interactions are controlled.
<P>Source</A> objects. Source class encapsulates the source-related attributes,
which are updated by the sender and receiver modules. The participants include
active senders as well as listeners. Source table is implemented as a Java
hash-table, which essentially is an associative array with search functionality
built into it. The key in the hash-table is the SSRC of the source and the value
is the Source object itself. Java Map and Vector classes (in java.util) were
considered as implementation alternatives. Both of these are container classes
just like the hash-table but due to the reasons discussed below, it was agreed
upon to use the hash-table.</P>
<P>Map (java.util.Map) is only available in JDK 1.2 (which at the time of
writing this document is in beta release). Selecting this as a source container
would have limited the usability of the package to 1.2 or later versions of JDK.
Hash-table, on the other hand, is available in all JDK releases as early as the
version 1.02. </P>
<P>Vector (java.util.Vector) was not chosen because it does not provide the
key-value associations and would have required manual search to find the desired
source object. The hash-table, on the other hand, has the search functionality
and association built-in making it trivial to retrieve the desired source object
given its SSRC as the key.</P>
<P>An implementation aspect of the source table needs to be pointed out; it is
that the sample implementation suggested rfc-1889 distinguishes between the
senders and members by maintaining two separate tables. In this package, the
source table provided by the session holds the members and there is no separate
table for senders. A source attribute ActiveSender is used to distinguish the
senders from listeners in the member table. Functions in Session are provided to
get the senders or the members.
<P>From the user's perspective, the Session interacts with the network and is
responsible for sending and receiving RTP and RTCP packets. What constitutes the
network interaction can be classified into two distinct processes:</P>
<DIR>
<P>(i) Synchronous processes:</P>
<DIR>
<DIR>
<P>Sending RTP packets</P></DIR></DIR>
<P>(i) Asynchronous processes:</P>
<DIR>
<DIR>
<P>Receiving RTCP packets<BR>Receiving RTP packets<BR>Sending RTCP
packets<BR> </P></DIR></DIR></DIR></DIR>
<P>The <B>synchronous interaction</B> with the network is straightforward, this
is driven by the application (the user of the package) and is invoked by calling
the Session.SendRTPPacket() function.
<P>The <B>asynchronous interaction</B>, on the other hand, requires the RTP and
RTCP receivers to run on separate threads and wait for the packet arrival.
Following the reception of a packet, several tasks are performed among which is
posting of the packet arrival event. Using events, the application has the
option to ignore a particular event family or subscribe to it. The event model
and the object interaction that takes place when asynchronous events occur are
described in the <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/report.html#EventModel">Event
Model</A> section of this document. </P><B>
<P align=center><IMG height=425 src="Java RTP Implementation.files/Image24.gif"
width=545></P>
<P align=center>Figure 1: Higher level functional modules</P>
<P>RTP Packet Sending and Receiving:
<P>Figure 1 depicts the object model where Session uses the RTPThreadHandler
object to send and receive RTP packets. RTPThreadHandler class is inherited from
Thread and the function which receives the RTP packets, runs in an infinite
loop. This loop is started directly by calling the or using Session.Start()
method which starts all the receivers. RTPThreadHandler class also doubles as a
sender by providing the SendPacket() function.
<H3>RTCP Packet Sending and Receiving</H3>
<P>RTCP receiver RTCPReceiverThread is similar to RTPThreadHandler described
above as it receives RTCP packets in an endless loop, but it is dissimilar as it
does not provide any send functionality.
<P>For sending RTCP packets, a separate threaded class RTCPSenderThread is
provided. The functionality of sending and receiving RTCP packets is not folded
into one class to keep the design modular and simple. RTCP sender and receiver
both have complicated algorithms and to keep the changes in the send RTCP module
from effecting the receiver module (or vice-versa), these functional modules are
implemented as separate encapsulations. This was decided upon to keep the
overall design in accordance with the design guideline of isolating the package
modules from the changes made in other modules, while allowing for
extensibility. </P>
<P>RTCPThreadHandler class is the parent class, which serves as an intstantiator
of the sender and receiver thread classes. This class has the sole purpose of
policing the RTCP sender and receiver threads. </P>
<P>Although sending of the RTCP packets is an asynchronous process, the sender
thread does not run in an endless loop like the receiver -- the Session</A> has
some control over it. For instance, after the RTCP sender thread is started, it
does not send any RTCP packets unless the application (user of the <A
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/docs/java.net.RTP.Session.html">Session</A>)
?? 快捷鍵說(shuō)明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -