RTP is used for real-time multimedia streaming applications that require timely delivery over UDP. It provides timestamps, sequence numbers, and payload format identification to enable synchronization and detection of packet loss or reordering. The companion protocol RTCP is used for quality of service feedback and synchronization between media streams. Common uses of RTP include simple multicast audio conferences where each participant's audio is sent in chunks with RTP headers, and audio/video conferences where separate RTP sessions are used for each medium.

1. Real-time Transport
Protocol

2.  Real-time multimedia streaming applications require timely
delivery of information and often can tolerate some packet
loss to achieve this goal.
 For example, loss of a packet in audio application may
result in loss of a fraction of a second of audio data, which
can be made unnoticeable with suitable error
concealment algorithms.
 The Transmission Control Protocol (TCP), although
standardized for RTP use is not normally used in RTP
applications because TCP favors reliability over timeliness.
 Instead the majority of the RTP implementations are built
on the User Datagram Protocol (UDP).

3. Limitations of TCP
• TCP is not used because-
 TCP does retransmissions  unbounded delays
 No provision for time stampings(slow and noisy
walks )
 TCP does not support multicast
 TCP congestion control (slow-start) unsuitable for
real-time transport

4. Protocol components
The RTP specification describes two sub-protocols, RTP and
RTCP.
RTP, facilitates the transfer of real-time data. Information provided
by this protocol include
1. Timestamps (for synchronization),
2. Sequence numbers (for packet loss and reordering detection)
3.Payload format which indicates the encoded format of the data.

5.  The control protocol RTCP is used to specify
1.Quality of service (QoS) feedback
2. synchronization between the media streams.
 The bandwidth of RTCP traffic compared to RTP is
small, typically around 5%.
 RTP sessions are typically initiated between
communicating peers using a signaling protocol, such
as Session Initiation Protocol (SIP),

6. Protocol stack for multimedia
services

7. SIP SESSION
• RTP session is sending and receiving of RTP data by a group
of participants
• For each participant, a session is a pair of transport
addresses used to communicate with the group
• If multiple media types are communicated by the group, the
transmission of each medium constitutes a session.

8. RTP HEADER FORMAT

9.  Version (V, 2 bits): indicate the version of the protocol (Current
version is 2)
 Padding (P, 1 bit): if set, last byte of payload is padding size
 Extension (X, 1 bit): if set, variable-size header extension exists
 CSRC Count (CC, 4 bit): number of SCRC identifiers
 Marker (M, 1 bit): defined in profile, mark significant event
 Payload type (7 bits): audio/video encoding scheme
 Sequence number: random initial value, increase by one for each
RTP packet; for loss detection and sequence restoration
 SSRC: identify source; chosen randomly and locally; collision needs
to be resolved
 CSRC list: identifiers of contributing sources, inserted by mixer

10. Introduction Real-time data transport at glance
• Encoded frames are produced
• They are assigned a timestamp and a
sequence number
• Then, they are load into RTP packet and
ready for transmission
• The sender also generates periodic
status reports in the form of RTCP
packets to participants
• The participants also send quality
feedback to the sender.
• Collect packets from network, and insert
them into a per-sender input queue.
• Packets then are passed to a channel-
coding routine for loss correct.
• Next, they are put into a playout-buffer,
and any variation in inter packet timing
caused by the network has been
smoothed.
• They are then grouped to form complete
frames that are decoded to play out.

11. RTP Packets
 Consist of RTP header, optional payload
headers and the payload itself RTP
overhead = 12 bytes
 IP+UDP+RTP overhead = 20+8+12 = 40 bytes
 It is advisable to keep coded slice sizes as
close to, but never bigger than, largest size
of a packet that can be transmitted without
being split/recombined on the transport and
network layer

12. RTP Packets
 Reasons are as follows :-
 It optimizes the payload/header overhead
relationship
 Minimizes the loss probability of a (fragmented)
coded slice due to the loss of a single fragment
on the network/transport layer and the resulting
discarding of all other fragments belonging to
the coded slice.

13. RTP Use Scenarios
 Streaming media is multimedia that is constantly
received by and presented to an end-user while being
delivered by a provider. The verb "to stream" refers to
the process of delivering media in this manner; the
term refers to the delivery method of the medium,
rather than the medium itself, and is an alternative
to downloading.

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

15.  RTP 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.

16.  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.