RTP/RTCP protocols

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 specialist 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 behaviour 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.

RTP (Real-time Transport Protocol)

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:

• identify the type of information carried,
• add temporary markers and sequence numbers to the information carried,
• monitor the packets' arrival at the destination.

In addition, RTP may be conveyed by multicast packets in order to route conversations to multiple recipients.

RTCP (Real-time Transport Control Protocol)

RTCP protocol is based on periodic transmissions of control packets by all participants in the session.

It is a control protocol for RTP flow, making it possible to convey basic information on the participants of a session and the quality of service.

Planned use of RTP and RTCP

RTP allows the management of multimedia flows (voice, video) over IP. RTP works on UDP. The RTP header carries synchronisation 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 synchronisation. RTP offers an end to end service. It adds a header which provides timing information necessary for the synchronisation 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

Format of headers and their contents

The RTP header carries the following information:

<--------------------------- 32 bits --------------------------->

V=2	P	X	CC	M	Sequence number
Timestamp
Identification of the synchronisation source (SSRC)
Identification of the contribution source (CSRC)

Here are the meanings of the different header fields:

• Version field V 2 bits long indicates the protocol version (V=2)
• Padding field P: 1 bit, if P is equal to 1, the packet contains additional bytes for padding to finish the last packet.
• Extension field X: 1 bit, if X=1 the header is followed by a extension packet
• CSRC count field CC: 4 bits, contains the number of CSRC which follow the header
• Marker field M: 1 bit, its interpretation is defined by an application profile
• Payload type field PT: 7 bits, this field identifies the payload type (audio, video, image, text, html, etc.)
• Sequence number field: 16 bits, its initial value is random and it increments by 1 for each packet sent, it can be used to detect lost packets
• Timestamp field: 32 bits, reflects the moment when the first byte of the RTP packet has been sampled. This instant must be taken from a clock which increases in a monotonous and linear way in time to enable synchronisation and the calculation of the jitter at the destination.
• SSRC field: 32 bits uniquely identify the source, its value is chosen randomly by the application. The SSRC identifies the synchronisation source (simply called "the source"). This identifier is chosen randomly with the intent that it is unique among all the sources of the same session. The list of CSRC identifies the sources (SSRC) which have contributed to obtaining the data contained in the packet which contains these identifiers. The number of identifiers is given in the CC field.
• CSRC field: 32 bits, identifies contributing sources.

RTCP headers

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:

• Version field (2 bits):
• Padding field (1 bit) indicates that there is padding the size of which is indicated in the last byte
• Reception report count field (5 bits): number of reports in the packet
• Packet type field (8 bits) 200 for SR
• Length field (16 bits) packet length in 32 bit words
• SSRC field (32 bits): identification of the specific originator source
• NTP timestamp field (64 bits)
• RTP timestamp field (32 bits)
• Sender's packet count field (32 bits)
• Sender's packet byte field (32 bits) statistics
• SSRC-n field (32 bits) number of the source whose flow is analysed
• Fraction lost field (8 bits)
• Cumulative number of packets lost field (24 bits)
• Extended highest sequence number received field (32 bits)
• Interarrival jitter field (32 bits). This is an estimation of the time interval for an RTP data packet which is measured with the timestamp and which is in the form of a whole number. This is in fact the relative transit time between two data packets.
  The formula for calculating it is: J=J+(|D(i-1,i)|-J)/16
  The interarrival jitter is calculated for each data packet received by the source SSRC_n
  i -->First packet
  i-1 --> previous packet
  D --> difference
  J --> second packet
• Last SR timestamp field (32 bits)
• Delay since last SR timestamp field (32 bits)

How is RTCP used with regards RTP?

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 and RTCP operate above which protocols?

RTP/RTCP is above the UDP/TCP transport, but practically above UDP.
RTP is a session protocol, but it is placed in the application. It is for the developer to integrate it.

How is the type of flow transported?

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).