Version (V): The field is of length 2 bits, indicating the current version of RTP. The current version of RTP is 2.0.

Padding (P): This field is of length 1 bit. If P is set, the PDU contains one or more additional padding octets at the end, which are not part of the payload. Padding is needed by some encryption algorithms, which require fixed block sizes, or for carrying several RTP PDUs in a lower-layer PDU.

Extension (X): This field is of length 1 bit. If X is set, the fixed header is followed by exactly one header extension.

CSRC count (CC): This field is of length 4 bits. The field indicates the number of CSRC identifiers that follow the fixed headers. As mentioned before, the field has a non-zero value only if passed through a mixer.

Marker bit (M): This field is of length 1 bit. If M is set, it indicates some significant events like frame boundaries to be marked in the PDU stream. For example, an RTP marker bit is set if the PDU contains a few bits of the previous frame along with the current frame.

Payload type (PT): This field is of length 7 bits. PT indicates the payload type carried by the RTP PDU. RTP Audio Video Profile (AVP) contains a default static mapping of payload type codes to payload formats. Additional payload types can be registered with IANA.

Sequence number: This field is of length 16 bits. The number increments by one for each RTP data PDU sent, with the initial value set to a random value. The receiver can use the sequence number not only to detect PDU loss but also to restore the PDU sequence.

Time stamp: This field is of length 32 bits. The time stamp reflects the sampling instant of the first octet in the RTP data PDU. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations at the receiver. The initial value should be random, so as to prevent known-plain text attacks. For example, if the RTP source is using a codec, which is buffering 20 ms of audio data, the RTP time stamp must be incremented by 160 for every PDU irrespective of the fact that the PDU is transmitted or dropped as silence.

SSRC: This field is of length 32 bits. This field identifies the source that is generating the RTP PDUs for this session. The identifier is chosen randomly so that no two sources within the same RTP session have the same value.

CSRC list: The list identifies the contributing sources for the payload contained in this PDU. The maximum number of identifiers is limited to 15, as is apparent from the CC field (All zero s is prohibited in CC field). If there are more than 15 contributing sources, only the first fifteen sources are identified.

Real-time protocols: RTP/RTCP/RTSP

CISC 856: TCP/IP and Upper Layer Protocols

Amit Hetawal ()

Due: Thursday December 8, 2005

References

RTP: a transport protocol for real-time applications, RFC 3550

Real Time Streaming Protocol (RTSP), RFC 2326

Exercises:

  1. How do the RTP, RTCP and RTSP protocols relate to each other?
  2. Give two reasons why each media stream (audio or video) should be carried on a different RTP session?
  3. How can a host receiving a report PDU know whether a previous SR/RR report was lost in transmit? (Hint RFC 3550)

RTP/RTCP Analysis:

For this exercise the members of the group should be present on individual Windows XP machines. And please arrange 2 microphones for the purpose of a voice conference between you two. Ethereal can be run on either of the machines.

(Before trying out this experiment just ping the other system. so as to confirm that you can reach to the other system)

Follow the following steps (on both the machines):

  1. GO to the START menu and click the RUN option.
  2. At the prompt type “conf.exe”.
  3. If step 2 does not work, type NetMeeting in the help and support of windows XP; you will be able to get the links from there.
  4. Step 2 or 3 will open a Windows NetMeeting application.
  5. If you are a first time user, fill in the details asked and enable the option to use Microsoft Internet Directory.
  6. On the menu bar, you can see the Call option. Click the new call
  7. Step 6 will open a new dialog box. Enter the IP address of your partner’s machine. (Be sure Netmeeting is running on the other machine too.)
  8. Click call and start a conference. But do not forget to start your ethereal before you click the call button.

(Carry out a conference for ~1 minute; it will be more than enough for the required observations)

Turn in an annotated transcript of your ethereal outputalong with the answers to the following questions:

  1. Mark the ports used by RTP and RTCP streams.
  2. Is a mixer present while communicating? How can you deduce this?
  3. Are you able to track an audio silence by seeing your ethereal output? Why or why not?
  4. How many SDES items are present in the RTCP PDUs?
  5. What does an END (0) signify in an RTCP PDU?

RTSP Analysis:

For this assignment you should have a real player installed on your machine.

You can play audio or video from the below link, or any one of your choice but just make sure that the audio is being streamed online and not downloaded and then played. Because often in real player, the audios are being downloaded and not streamed so in that case you will only be able to see the TCP traffic going on and no RTSP traffic.

Link is:

Before clicking to the link given on the above page, start ethereal. Now click the link and track what happens with RTSP.

Turn in an annotated transcript of your ethereal outputalong with the answers to the following questions:

  1. What methods are used by RTSP?
  2. Try different options of the player like pause, stop and fast-forward etc., and see what happens to your ethereal output and mark what methods are invoked by carrying these actions.