QoS Measurement Tool for RTP

Problem Statement:

Extending our RTP tool set, write a traffic generator that generates a stream of RTP audio packets from a file or at regular intervals, and a receiver that measures the packet loss, delay and delay jitter. The traffic generator should generate a continuous stream. The output can either be a Tcl/Tk graph or textual. The tools should be commandline tools. Language: C, Tcl/Tk.

1. Which software are we extending? rtptools
2. Features to be supported and priorities? TBD
3. Existing libraries or modules? rtptools
4. Programming language? C and probably Tcl/tk for GUI.
5. Operating system? Solaris and Linux
6. GUI tool kit? Tcl/tk
7. Component testing? Test sipconf performance.
8. Error logging? TBD.
9. Installation mechanism? TBD.
10. Milestones? described in this document.

1. An RTP generator "rtpgen" that generates, based on an .au file, a continuous stream of audio packets (G.711) to a given address and port.
2. A QOS analyzer that processes rtpdump files generated by rtpdump, either to a file or read via a pipe. The analyzer should compute, periodically, and via text output
   • packet loss
   • an indication of jitter (e.g., the deviation from the nominal arrival instant); see also http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt
   • possibly clock drift (low priority)
3. A Tk tool that displays this information graphically, as a function of time.

We use Real-time Transport Protocol (RTP) for transport of real-time media packets on Internet. Audio telephony on Internet involve digitization of audio (from analog to digital, includes sampling, quantization, and encoding) and transport of encoded audio packets to the remote IP address. We use UDP as the transport layer because the reliability provided by TCP is not needed by audio (it does not matter even if you loose some packets) and UDP provide lower delay than TCP. However, because of the unreliable nature of UDP there could be packet losses and out of order arrival at the destination. Moreover, even if the sender sends the packet periodically say every 50 ms, the receiver may not get the packets every 50 ms, due to variance in the network delay (also called as jitter). If the receiver plays out the packets as soon as they arrive the audio will be broken. To take care of this it is advisible to have the receiver play out the packets with the same rate as they were sent from the sender, periodically every 50 ms in this example. This requires that the sender put some kind of timing information in the packet (timestamp). RTP provides this information in its header field. Moreover, it also give sequence number field to detect if there was any packet loss. Sender increments the sequence number of every subsequent packet, so receiver can detect packet loss or out-of-ordering using this number. Other header fields in RTP are explained in the specification RFC 1889.

Part-1: Background study due Oct 13

1. Read RFC1889, and relevant sections in Internetworking Multimedia and/or Kurose and Ross. An informal tutorial will be arranged describing IP telephony in general.
2. Read the format of AU file. See /usr/demo/SOUND/include/multimedia on Solaris machine. See the work done by the conference recording project students. Also, xanim does this.

Part-2: RTP streaming using .au due Oct 20

1. Implement and test an RTP streaming program which streams packets from a .au file. See the code by conference recording students.
2. Provide command line options to change the packatization time. By default it should use 20 ms packatization. i.e., for G.711 Mu Law audio, 160 bytes payload + 12 bytes RTP header in each packet.
3. The remote address and port number is also provided from the command line.
4. It should also send out RTCP packets periodically. You do not need to calculate the RTCP transmission interval. You can assume static interval of default 5 seconds. Make this as a command line option.

Part-3: QoS background due Oct 28

Reading and understanding of IP Performance Metrics RFC's and drafts.

Test the rtp tools (in particular rtpdump and rtpsend/rtpplay)

Part-4: QoS measurement tool due Nov 10

1. Write a tool that processes rtpdump output.
2. It should be able to identify different senders from the dump using RTP header fields SSRC/CSRC.
3. It should be able to identify silence period from talk spurt, using RTP header field m. You may also use timestamp and sequence number information to differentiate a silence period from a talk spurt.
4. Identify how many packets where lost using the sequence number.
5. Calculate delay and jitter at any instance.

Part-5: QoS measurement tool extension due Nov 20

1. Extend your tool to print out a running value every 5 seconds for the packet loss, delay and jitter. Your tool itself receives packets from network instead of using rtpdump output. Plugin the relevant portion of the rtpdump code for socket interface.
2. Include clock drift calculation if any.

Part-6: Integrate Tcl/tk GUI due Dec 5

1. Integrate Tcl/tk graph drawing tool to show graphical representation of delay and jitter. (See BLT widget in Tk installed on CS machines)

Consider writing a technical report describing your project. This is optional.