In order to demonstrate the key features of the software and its usage, a RTP monitoring tool was implemented. This application (JRTPMon), by no means, exploits the GUI features of the language and was not intended to do so.
What the application does:
Application's main screen allows the user to enter the Multicast group's IP/port addresses followed by a payload type to monitor. After supplying the necessary parameters in the required format, user clicks the connect button and the monitor establishes a connection to the multicast group and start listening to the RTP and RTCP packets. The RTP and RTCP buttons remain disabled until a connection is made, at this point, the user can click the RTP or RTCP button to bring up the respective monitor log window. Following screen shows a connected main window
here, a payload type 3 is selected, which corresponds to GSM encoded audio.
A vat tool is brought up and the encoding type is changed to GSM. Following screen shows the vat tool. Notice that the vat tool has successfully picked up the packets from the monitor and the name is displayed in the member's list.
The first entry in the list is of the vat tool itself and the second entry is of the JRTPMon. Clicking on the JRTPMon and requesting the Site-Info results in the following screen
So far, it has been demonstrated that JRTPMon is a valid member and does send RTCP SDES packets which are properly parsed by the vat tool. The vat tool starts sending packets as soon as the right mouse button is clicked and we see that these packets are picked up by the monitor as shown below:
JRTPMon also picked up the RTCP packets and are shown in the following screen capture:
Up until this point, the monitor has not sent any packet. So the ReportBlock is false. Observe that the RTP Packet Monitor window has a text field and a button named "Send Test Packet". This can be used to send a test packet to the multicast group. Vat tool does not understand RTP packets with strings and interprets them as audio data packets. This results in a clicking sound, but this demonstrates the fact that the monitor (hence the package) is able to send RTP data packets.
This was done and the following screen shows that the RTP packet monitor window received this test packet and is highlighted (the RTP packet loop-back was enabled):
On the receiving end, looking at the vat tool statistics on the monitor shows that one RTP packet was received
This demonstrates the full cycles of sending and receiving the packet.
Internals of JRTPMon:
This application tries to convey the simplicity of the software package and how it can be used. Code samples from the monitor are presented to highlight the key usage steps.
class frmMain extends frame {
…
rtpSession = new Session ( IP, // MulticastGroupIPAddress
Port, // MulticastGroupPort
Port+1, // RTCPGroupPort
Port+5, // RTPSendFromPort
Port+6, // RTCPSendFromPort
10000 // bandwidth
);
rtpSession.setPayloadType ( this.PayloadType );
rtpSession.setCName ( "JRTPMon" );
rtpSession.setEMail ( "monitor@ais.com" );
rtpSession.DebugOutput = true;
RTCPMon = new frRTCPMonitor ( rtpSession );
RTPMon = new frRTPMonitor ( rtpSession );
// Register the RTCP frame as the RTCP action listener
Session.addRTCP_actionListener ( RTCPMon );
Session.addRTP_actionListener ( RTPMon );
…
}
The code fragment above is executed when the user clicks the "Connect" button. A new Session instance is created and necessary parameters are set. Then RTCPMon and RTPMon frames instances are created. What follows the frame creating is their registration. Note that each frame is implementing one of the interfaces. It is possible to have the main frame implement the interface and reroute the events as necessary but to demonstrate the usage of two distinct classes implementing the interfaces, this implementation was chosen.
Following is the code fragment from the RTCP packet monitor frame:
import java.awt.*;
import java.net.RTP.*;
import java.net.RTP.Packets.*;
public class frRTCPMonitor extends Frame implements RTCP_actionListener
{
public void handleRTCPEvent ( RTCPReceiverReportPacket RRpkt)
{
list.addItem ( "**** RTCP RR Packet: *****" );
list.addItem ( "SSRC = " + Long.toHexString(RRpkt.SenderSSRC) );
list.addItem ( "ReportBlock = " + RRpkt.containsReportBlock );
…
}
public void handleRTCPEvent ( RTCPSenderReportPacket SRpkt)
{ ..}
}
Here, the RTCP monitor frame is shown implementing the RTCP_actionListener interface. The main frame registered this frame instance hence it was not required for it to register itself. Notice that the event handling function handleRTCPEvent makes use of the receiver report packet by displaying its contents in the monitor window.
The source for the JRTPMon package could be downloaded from here.