RTP: A Transport Protocol for Real-Time Applications Provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, timestamping and delivery monitoring. Applications typically run RTP on top of UDP

Why RTP? Faster Avoid Starvation Monitoring services Independent of network protocol Multicasting

RTCP RTP is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.

RTP Use Scenarios Simple Multicast Audio Conference The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding (such as PCM, ADPCM or LPC) is contained in each packet.

TP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source. The sequence number can also be used by the receiver to estimate how many packets are being lost. the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP port. The reception report indicates how well the current speaker is being received. A site sends the RTCP BYE packet when it leaves the conference.

Audio and Video Conference Audio and video media are transmitted as separate RTP session and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTP packets for both sessions.

RTP Works Video and audio payloads are sent separately IP Header UDP Header RTP Header RTP Video Payload IP Header UDP Header RTP Header RTP Audio Payload Video and audio payloads are sent separately Uses sequence number to synchronise audio and video once received

MIXER Receives streams of RTP data packets from one or more sources, possibly changes the data format, combines the streams in some manner and then forwards the combined stream. All data packets forwarded by a mixer will be marked with the mixer's own SSRC identifier. In order to preserve the identity of the original sources contributing to the mixed packet

Translator Forwards RTP packets with their SSRC identifier intact May change the encoding of the data and thus the RTP data payload type

Format of RTP (V) Version; 2 bits (P) Padding; 1 bit. (X) Extension; 1 bit. (CC) CSRC Count; 4 bits. (M) Marker; 1 bit. (PT) Payload Type; 7 bits. Sequence Number; 16 bits. Time Stamp; 32 bits. SSRC(Synchronization source); 32 bits. CSRC(Contributing source) List;

RTCP Is based on the periodic transmission of control packets to all participants in the session and perform the following functions: provide feedback on the quality of the data distribution and allows one who is observing problems to evaluate whether those problems are local or global.

RTCP carries an identifier for an RTP source called the canonical name or CNAME. Receivers use CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video.

RTCP Message SR: Sender report, for transmission and reception statistics from participants that are active senders. RR: Receiver report, for reception statistics from participants that are not active senders. SDES: Source description items, including CNAME. BYE: Indicates end of participation. APP: Application specific functions.

RTCP Transmission Interval RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. In an audio conference the data traffic is inherently self- limiting because only one or two people will speak at a time, so with multicast distribution the data rate on any given link remains relatively constant independent of the number of participants. However, the control traffic is not self-limiting. If the reception reports from each participant were sent at a constant rate, the control traffic would grow linearly with the number of participants.

To maintain scalability, the average interval between packets from a session participant should scale with the group size. The control traffic should be limited to a small and known fraction of the session bandwidth: small so that the primary function of the transport protocol to carry data is not impaired; known so that each participant can independently calculate its share. It is suggested that the fraction of the session bandwidth allocated to RTCP be fixed at 5%

SRC Identifier Allocation The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session. All RTP implementations must be prepared to detect collisions and take the appropriate actions to resolve them. If a source discovers at any time that another source is using the same SSRC identifier as its own, it must send an RTCP BYE packet for the old identifier and choose another random one. If a receiver discovers that two other sources are colliding, it may keep the packets from one and discard the packets from the other.

Disadvantages/ Limitations Non-preservation of marker. Congestion Control Algorithms. -The marker bit of RTP is not preserved for redundant data blocks. -This means that if the primary is lost (containing the marker) the marker itself is lost.