The spread of computers, added to the availability of cheap audio/video computer hardware, and the availability of higher connection speeds have increased interest in using the Internet for sending audio and video, data types which were traditionally reserved for specializt networks, and over several years audio and video conferencing have become common practice. However, the very nature of the Internet means that this network is not suited for data transmission in real time and as a result the quality of audio sent over the Internet is usually of mediocre quality. This theory specifically addresses the analysis and solution of these problems to enable an audio conferencing or telephone application over the Internet to change its behavior to maintain an acceptable auditory quality even in cases where the network is quite congested. These solutions, in the form of control mechanisms, have been implemented and tested on the audio conferencing and telephone software on Internet Free Phone which we developed. A study on the effect that these machines would have on an Internet which developed to integrate the Fair Queuing service discipline has shown that while these mechanisms would still be necessary, they would perform even better on this network type.
The aim of RTP is to provide a uniform means of transmitting data subject to real time constraints over IP (audio, video, etc. ). The principal role of RTP is to implement the sequence numbers of IP packets to reform voice or video information even if the underlying network changes the order of the packets.
More generally, RTP makes it possible to:
RTCP protocol is based on periodic transmissions of control packets by all participants in the session.
RTP allows the management of multimedia flows (voice, video) over IP. RTP works on UDP. The RTP header carries synchronization and numbering information. The data coding will depend on the compression type. RFCxxxx specifies RTP, on the other hand the adaptation of a compression method to RTP will be described in a specific RFC, for example H261 on RTP is described in RFCxxxx. One RTP channel is used per type of flow: one for audio, one for video. The field xxx is used for synchronization. RTP offers an end to end service. It adds a header which provides timing information necessary for the synchronization of sound and video type real time flow. RTP (Real time Transport Protocol) and its companion RTCP (Real time Transport Control Protocol) make it possible to respectively transport and monitor data blocks which have real time properties. RTP and RTCP are protocols which are located at application level and use underlying TCP or UDP transport protocols. But the use of RTP/RTCP is generally done above UDP. RTP and RTCP can use the Unicast (point to point) method just as well as the Multicast (multipoint) method. Each of them uses a separate port from a pair of ports. RTP uses the even port and RTCP the next highest odd port
The RTP header carries the following information:
<--------------------------- 32 bits --------------------------->
|Identification of the synchronization source (SSRC)|
|Identification of the contribution source (CSRC)|
Here are the meanings of the different header fields:
The objective of RTCP is to provide different types of information and a return regarding the quality of reception.
The RTCP header carries the following information:
RTCP is a control protocol associated with RTP, it measures performances but offers no guarantees. To do so, it must use a reservation protocol such as RSVP or make sure that the communication links used are correctly proportioned in relation to the use which is made of it.
RTP has nothing to do with the type of flow, it is above UDP, which itself is above IP. The type of flow is theoretically used in IP.
RTP carries a sequence number, timestamp and unique identifier for the source (SSRC).
Article written by Nico VanHaute, Julien Barascud et Jean-Roland Conca