The Real-Time Transport protocol (RTP) provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video or simulation data, over multicast or unicast network services. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols. RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network.

RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender"s packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.

RTP consists of two closely-linked parts:

• The real-time transport protocol (RTP), to carry data that has real-time properties.
• The RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an on-going session. The latter aspect of RTCP may be sufficient for "loosely controlled" sessions, i.e., where there is no explicit membership control and set-up, but it is not necessarily intended to support all of an application"s control communication requirements.

Protocol Structure

• V - Version. Identifies the RTP version.
• P - Padding. When set, the packet contains one or more additional padding octets at the end which are not part of the payload.
• X - Extension bit. When set, the fixed header is followed by exactly one header extension, with a defined format.
• CSRC count -Contains the number of CSRC identifiers that follow the fixed header.
• M - Marker. The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream.
• Payload type - Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means.
• Sequence number - Increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence.
• Timestamp - Reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations.
• SSRC - Synchronization source. This identifier is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier.
• CSRC - Contributing source identifiers list. Identifies the contributing sources for the payload contained in this packet.

Related protocols: UDP, TCP, RTSP, RTCP

Sponsor Source: RTP is defined by IETF (http://www.ietf.org) in RFC 3550 and 3551.

Reference:
http://www.javvin.com/protocol/rfc3550.pdf: RTP: A Transport Protocol for Real-Time Applications
http://www.javvin.com/protocol/rfc3551.pdf: RTP Profile for Audio and Video Conferences with Minimal Control