sends a RTP packet. Likewise, the RTCP sender stops sending packets after 
application requests a shutdown by calling the <A 
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/docs/java.net.RTP.Session.html#Stop">Session.Stop()</A> 
function. According to the RTP protocol specifications, it is mandatory for the 
RTCP sender thread to be silent following the transmission of the BYE packet. 
Although the <A 
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/docs/java.net.RTP.Session.html">Session</A> 
user has some control over the <A 
href="http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/java_rtp/docs/java.net.RTP.RTCPSenderThread.html">RTCPSenderThread</A>'s 
packet sending behavior, it has no explicit control over when the RTCP packet 
will be sent, this is due to the randomness introduced while calculating the 
RTCP sending interval.</P>
<P>Sending RTCP packets has to follow certain rules and guidelines as dictated 
by the rfc[1]. The flowchart shown in Figure 2 summarizes the algorithms used in 
the implementation of the sender.</P>
<P align=center><IMG height=473 src="Java RTP Implementation.files/Image25.gif" 
width=646></P><B>
<P align=center>Figure 2: RTCP Send flowchart. The thread loop is entered at the 
top-left and exited at the right.</P></B>
<P>&nbsp;</P>
<P>This flow depicted in the flow-diagram above implements the BYE back-off 
algorithm (rfc-1889, section 7.3.7). Furthermore, SSRC of sources are timed out 
following the algorithm described in Option B of rfc-1889 (section 7.3.6).</P>
<P>RTCP reception involves parsing the incoming RTCP packets, which can be of 
type described in RTCPConstants</A> class. After parsing the packet, source 
table is updated if required and an event is generated for the registered 
listener.</P>
<P>RTP and RTCP reception update the Session</A> and source level statistics 
that are necessary to sustain an RTP session with minimal interaction from the 
application. This makes it easy for applications, which do not necessary need to 
concern themselves with the protocol intricacies, to use this software package 
and with only a few lines of code, have a fully functional RTP session. For 
instance, notice the following sample code</P>
<P>&nbsp;</P>
<DIR>
<DIR><FONT face="Courier New" size=1>
<P>// Construct a new </FONT>Session</A><FONT face="Courier New" size=1> 
object</P>
<P>rtpSession = new </FONT>Session</FONT></A><FONT face="Courier New" size=1> ( 
"234.5.6.7", // MulticastGroupIPAddress</P>
<DIR>
<DIR>
<DIR>
<DIR>
<P>8000, // MulticastGroupPort</FONT><BR><FONT face="Courier New" size=1>8001, 
// RTCPGroupPort</FONT><BR><FONT face="Courier New" size=1>8051, // 
RTPSendFromPort</FONT><BR><FONT face="Courier New" size=1>8052, // 
RTCPSendFromPort</FONT><BR><FONT face="Courier New" size=1>10000 // 
bandwidth</FONT><BR><FONT face="Courier New" size=1>);</FONT> <BR><FONT 
face="Courier New" size=1>// Set the session parameters</FONT><BR><FONT 
face="Courier New" size=1>rtpSession.setPayloadType ( 5 
);</P></DIR></DIR></DIR></DIR>
<P>rtpSession.setCName ( "RTPUser" );</FONT> <BR><FONT face="Courier New" 
size=1>rtpSession.setEMail ( "user@pluto.com" );</P>
<P>// Start the session</FONT><BR><FONT face="Courier New" 
size=1>rtpSession.Start();</P>
<P>// Send a test packet.</FONT> <BR><FONT face="Courier New" 
size=1>rtpSession.SendPacket ( String ( "TestString" ).getBytes() );</P>
<P>// Stop the session</FONT><BR><FONT face="Courier New" 
size=1>rtpSession.Stop();</P></FONT>
<P>&nbsp;</P></DIR></DIR>
<P>However, for the applications requiring finer control over the RTP session, 
it is necessary to expose some of the session internals. This allows for 
applications, requiring distinct level of control, to use the same software 
package. Session</A> exposes some of the internal functionality, such as, thread 
handling, source-table modification methods etc. for flexibility and 
extendibility.</P>
<P>It was mentioned earlier that when a RTP or RTCP packet arrives, session</A> 
level state and statistics are updated, furthermore, it is necessary to forward 
the RTP packets over to the user of the session (application or any other class 
requiring the received RTP packets). To avoid using hard-coded callback 
functions, an event model was designed which is discussed in the next 
section.</P>
<H3><A name=EventModel>Event Model</A></H3>
<P>The event model in this package is based on the one implemented by the 
Abstract Windowing Toolkit (AWT) 1.1. In the AWT event-model, asynchronous 
events, such as button-click etc. are handled by registered listeners. A 
listener is a class which implements an interface specified by the event-model. 
For instance, there exists in AWT, the <A 
href="http://java.sun.com/products/jdk/1.1/docs/api/java.awt.event.MouseListener.html">mouseListener</A> 
interface. Any class interested in mouse events, must implement this interface. 
Additionally, the interested class instance must register itself with the event 
source by calling the method <A 
href="http://java.sun.com/products/jdk/1.1/docs/api/java.awt.Component.html">addMouseListener</A> 
and passing its own instance reference. This step of registration will allow the 
event dispatcher to call the appropriate event handling functions in the 
listener when an event is posted. The dispatcher is guaranteed that the 
listener, which declares that it implements the interface, indeed does implement 
all the methods. This guarantee is in effect by the compiler, which will produce 
compile-time errors until an implementation, even if empty, is provided by the 
interface implementor. </P>
<P>Following the same model, two interfaces, RTCP_actionListener</A> are made 
available. It is not required by the application classes to implement any of 
these interfaces. The only requirement is that once an application class is 
declared that it implements the interface, it must provide handlers for each and 
every method. The objects passed to the event handler are classes which 
encapsulate the RTP and RTCP packets. Following object model diagram will help 
clarify how these packet classes are interrelated.</P>
<P>RTP Packet</A><B>:</P>
<DIR>
<DIR></B>
<P>Attributes of the RTP Packet are listed in the following model 
diagram.</P></DIR></DIR>
<P align=center><IMG height=145 src="Java RTP Implementation.files/Image18.gif" 
width=171></P>
<DIR>
<DIR>
<P>When the Session.postAction()</A> is called. This method is provided with the 
newly constructed RTPPacket object. An alternative is to post the byte data 
stream instead, but from the user's point of view, it is easier to work with 
objects and attributes than to parse bits and bytes out of a byte datagram. To 
the user, an incoming RTP packet is nothing more than the object instance of the 
RTPPacket class. Note that the user is not required to do anything with any of 
the attributes, most often, it will only need the data attribute, which contains 
the payload. But an application like RTP monitor needs to have access to the RTP 
packet header and this encapsulation targets such users.</P></DIR></DIR>
<P>&nbsp;</P>
<P>RTCPSenderReportPacket</A><B>, <BR></B>RTCPReceiverReportPacket</A><B>:</P>
<DIR>
<DIR></B>
<P>RTCP receiver and sender report packets inherit from the RTCPPacket</A> 
class, which contains zero or one Report Block. It is possible that there are 
more than 31 members in an RTP session, and the specifications allow for a RTCP 
packet to have at most 31 report blocks, hence, the feedback about this source 
might be in the next RTCP packet. </P></DIR></DIR>
<P align=center><IMG height=322 src="Java RTP Implementation.files/Image19.gif" 
width=547></P>
<DIR>
<DIR>
<P>When a RTCP sender report or receiver report packet is encountered in the 
compound packet, a corresponding packet object is instantiated and 
handleRTCPEvent()</A> method and hands the packet object to it.</P></DIR></DIR>
<P>SDES</A><B> Packets:</P>
<DIR>
<DIR></B>
<P>Following object diagram displays the SDES and BYE packets. Similar to the 
RTCP sender/receiver report reception, when SDES and BYE packets are received, 
respective packet objects are created and posted to Session</A>.</P>
<P align=center><IMG height=189 src="Java RTP Implementation.files/Image20.gif" 
width=347></P>
<P>&nbsp;</P></DIR></DIR><B>
<P>Sequence Diagram:</P></B>
<P>Following sequence diagram shows the interaction between the Session, the 
session instantiator which implements the RTP_actionListener interface, the RTP 
receiver and the RTPPacket object.</P>
<DIR>
<DIR>
<P align=center><IMG height=450 src="Java RTP Implementation.files/Image21.gif" 
width=613></P></DIR></DIR><I>
<P>Sequence 1 and 1.5: The registration takes place. Here instance of the class 
which is implementing the </I>reference</A><I> in order to post the RTP events 
to this listener. </P>
<P>Sequence 2: The asynchronous event, i.e. the RTP packet reception.</P>
<P>Sequence 3: The RTP receiver, after performing the house-keeping tasks, such 
as updating the source table, upgrading the sender of this RTP packet to active 
sender etc., instantiates a RTPPacket object and populates its fields. It then 
posts the packet object with the session in sequence 3.5.</P>
<P>Sequence 4: Session determines if any RTP_actionListener implementing object 
is registered. In this case, there is a registered object.</P>
<P>Sequence 5: The packet object is handled by the RTP_actionListener.</P></I>
<P>&nbsp;</P><B>
<P>Following rules and guidelines apply while working with the events model and 
actionListener interfaces:</P></DIR>
<DIR></DIR>
<UL>
  <UL></B>
    <LI>It is recommended that a class implement the RTP_actionListener</A> 
    interface.</LI></UL></UL>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR><FONT face="Courier New" size=1>
<P>class MyClass implements RTP_actionListener { 
厎</P></DIR></DIR></DIR></DIR></FONT>
<P>&nbsp;</P></DIR></DIR>
<UL>
  <UL>
    <LI>Session maintains registration and in the current implementation, there 
    can only be one listener per interface. Registration is performed using the 
    methods Session.addRTCP_actionListener</A>(). 
    <LI>Only one registered listener will get the event notifications. For 
    instance, there are two classes, A and B, that implement the 
    RTP_actionListener interface, and if instance of A followed by B registers 
    itself by calling the Session.addRTP_actionListener() function, then the 
    last registration will overwrite the one preceding it. It is necessary to 
    understand that there can only be one instance registered for 
    RTP_actionListener. Similarly, for RTCP events, there should be no more than 
    one class implementing the RTCP_actionListener interface and registering 
    itself. 
    <LI>If a class implements both interfaces, it must provide implementation 
    for methods in both the interfaces.</LI></UL></UL>
<DIR>
<DIR>
<P>&nbsp;</P>
<P>Following code examples may help clarify the event model.</P>
<DIR>
<DIR><B>
<P>// Example 1: One class that implements the RTP_actionListener interface and 
registers itself</B><BR><FONT face="Courier New" size=1>class MyClass implements 
<B>RTP_actionListener</B> {</P>
<DIR>
<DIR>
<P>MyClass {</P>
<DIR>
<DIR>
<P>Session rtpSession = new Session (