Real time multimedia applications have enjoyed the global interest over the last few years. These applications are characterized by three main properties: the demand for high data transmission rate (bandwidth-consuming applications), the sensitiveness to packet delays (latency and jitter) and the tolerance to packet losses (packet-loss tolerant applications), when compared to other kind of applications. The Transmission Control Protocol (TCP) is the dominant and the most widely used protocol at the transport layer. However, there are three characteristics of this protocol that makes it insufficient for real time data delivery:
- TCP has a built-in retransmission mechanism that may be in fact useless for delay-sensitive applications.
- TCP does not carry any time related information, which are needed by real time applications and lastly.
- TCP employs a "strict" congestion control mechanism that reacts even in the light of a single packet loss event.
On the other hand, the User Datagram Protocol (UDP) does not also provide any support for multimedia applications. Therefore, the need of a new protocol led the research community to design the Real Time Protocol (RTP) and the associated RTP Control Protocol (RTCP) in order to support multimedia applications. The RTP protocol constitutes a new de facto standard and is the dominant transport protocol for multimedia data transmission.
The implementation of the RTP in NS2 is very generic. It provides only the main functions of a "common" transport protocol and runs on the top of the UDP. In this work we extended the functionality of the RTP and RTCP code in NS2 to include:
- Most of its feedback functions described in RFC 3550.
- TCP friendly behavior by the meaning that the transmitted flow consumes no more bandwidth than a TCP connection, which is traversing the same path with the transmitted flow
Real Time Protocol (RTP)
RTP is a real time transport protocol that is used usually on top of the UDP protocol (also other transport protocols are supported). By saying this we already accept a transport protocol on top of another transport protocol and this statement may be misleading. On the other hand, RTP is highly coupled to the application that it carries. Therefore, RTP would better be viewed as a framework for real time applications and not as just a transport protocol. RTP neither provides any guarantees for data delivery nor for sequencing packet delivery. The main functions of the RTP include:
- Identification of payload type
- Identification of the source sending the RTP packets
- Timestamps to the RTP packets
- Sequence numbers of the RTP packets
RTP Control Protocol (RTCP)
The RTCP protocol provides to participants of the RTP session feedback information of the network conditions. RTP and RTCP protocols use different port numbers. The main functions of the RTCP are:
- Network measurements for QoS (packet loss ratio, delay jitter, timestamps of sender and receiver reports etc)
- Identification of the source sending the RTCP packets
- Estimation of the session size and scaling mechanisms
The RTCP sender and receiver reports (SR) and (RR) provide direct information on the packet losses, cumulative number of the RTP packets sent by the source and delay jitter. They provide also additional fields that can be used for the implementation of congestion control policies by separate protocols, like for example TCP-like flow control which we have implemented. A separate entity like a network management can obtain network metrics based on the reception of the RTCP reports without actually taking part in the RTP session.
Other information carried by the RTCP packets include a source identifier of the transport layer (CNAME), the e-mail address, name, phone, location of the source originated the RTCP report.