Introduction

RTP: A Transport Protocol for

Internet standard for real-time data
Real-Time Applications
„
„ Interactive and streamed audio and video
„ Designed for multi-user multimedia conferencing
„ Provides end-to-end transport functions for real-time
„ Introduction applications
„ RTP use scenarios „ Delay-oriented rather than loss-oriented (such as TCP)
„ RTP
„ RTCP

Tao Li & M. Veeraraghavan,

University of Virginia 1 2

Introduction – cont. Introduction – cont.

„ Contains two closely linked parts: data + control
„ RTP: Real-time transport protocol „ Does NOT provide time-guaranteed delivery
„ To transport real-time data
or other QoS guarantees
„ RTCP: RTP control protocol
„ QoS monitoring and feedback
„ Relies on lower-layer protocols
„ Session control
„ Does NOT assume the underlying network is
„ Protocol architecture reliable and delivers packets in sequence
„ Uses sequence number
Applications
RTP & RTCP
Other transport and UDP
network protocols IP
3 4

1
Introduction – cont. RTP use scenarios
„ RTP implementation is expected to be „ Simple multicast audio conference
integrated into the application rather than as a „ A multicast IP address and two UDP ports (for RTP and
separate module RTCP ), assigned and distributed by mechanisms beyond
„ The use of RTP for a particular application the scope of RTP
needs other documents „ Speaker sends:
„ Profile specification documents defines sets of
IP header UDP header RTP header Audio data
payload type codes, and their mapping to payload
formats „ Receiver plays out audio data according to RTP header
„ Payload format specification documents define how „ Senders/receivers periodically multicast RTCP reports
to carry a specific encoding
„ Who is participating?
„ example: MPEG2 video or ADPCM audio
„ What is the audio quality?
„ RFC 1890: payload types; RFC 2250: MPEG

5 6

RTP use scenarios – cont. RTP – packet format

V P X CSRC M Payload Sequence number
„ Audio and video conference count type (16 bits) Fixed
„ Two RTP sessions, one for audio and the other for Timestamp (32 bits) header
video Synchronization source (SSRC) id. (32 bits)
„ User can participate in audio, video or both Contributing source (CSRC) id. (0~15 items, 32 bit each) optional
„ No direct coupling at the RTP level except a user Header extension (optional) header
uses the same name in RTCP packets for both Payload (real time data)
audio and video sessions Padding (size Padding size
optional
x 8 bits) (8bits)
„ Mixers: to mix streams from multiple sources
„ Translators: to change formats „ Version (V, 2bits): =2
„ Padding (P, 1bit): If set, last byte of payload is padding size
„ Extension (X, 1bit): If set, variable-size header extension exists
7 8

2
 RTP payload types (few
examples); RFC 1890 SSRC and CSRC
„ All packets from a given synchronizing source (with a
Payload Encoding name Audio/Video Clock rate given SSRC identifier) will use the same timing and
type (A/V)
sequence number space to allow receivers to
0 PCMU (mu-law G.711) A 8000 recreate the packet sequence
8 PCMA (A-law G.711) A 8000 „ A mixer receives RTP packets from multiple sources,
26 JPEG V 90000 combines packets, makes timing adjustments, and
32 MPV (MPEG-I and MPEG V 90000 forwards new RTP packets with a new timing
II) sequence
33 MP2T (MPEG-II transport AV 90000 „ All packets in the new sequence will have mixer SSRC as
streams) their synchronization source
„ The mixer inserts in each RTP packet header a CSRC list of
the sources that contributed to this combined stream

9 See Section 10.6 of book by Leon-Garcia and Widjaja 10

RTP - header RTP – header - timestamp

„ Reflects sampling instance of the first byte in payload
„ CSRC count (4 bits): number of CSRC identifiers
Clock frequency depends on data type; specified in profile
Marker (1 bit): defined in profile, mark significant event
„
„

„ Payload type (7 bits): Audio/Video encoding scheme „ Random initial value

„ Example: CBR audio, clock increment by 1 for each sample.
„ Sequence number: random initial value, increase by one for
each RTP packet; for loss detection and seq. restoration „ Consecutive RTP packets may have same timestamp
(logically generated at same instant): Video packets that
„ SSRC: identify source; chosen randomly and locally;
belong to the same frame
collision needs to be resolved
„ CSRC list: identifiers of contributing sources, inserted by „ Timestamps of consecutive RTP packets may not increase
monotonically if the data is not transmitted in the order in
mixer
which it was sampled: MPEG interpolated video frames
11 12

3
 Relative timestamping scheme Delay vs. loss
„ Receivers compute delay and jitter „ To ensure 0 jitter in playout, choose
experienced by packet maximum delay as the total delay in selecting
„ This allows them to adaptively size their playout delay value
reconstruction buffers „ Other option:
D1 = 75ms
„ Use 95% of transmission delay to select playout
D2 = 50ms delay value
Packets received „ Packets that take longer transmission delay than
25ms 50ms this 95% value will be dropped because they did
Packets played out not arrive in time
D1 = 100ms „ Telephony requirements: 150ms one-way
D2 = 100ms Goal: keep jitter low (0 in this case) delay with echo cancellers; loss: 5%
13 14

RTCP: RTP control protocol Role of RTCP

„ Receivers send reports „ Periodically transmit report to all participants
Functions of RTCP:
„ Report contains number of packets lost „
„ Provide QoS feedback
at receiver, interarrival jitter, etc. „ Carry persistent id - Canonical name (CNAME), e.g.,
„ This allows senders to adjust data rate user@host
„ Track a user if SSRC changes (in case of conflicts)
„ Jitter is an early indicator of congestion „ Associate multiple streams from a user – synchronize A and V
Control the rate of RTCP packets by noting how many
Senders also send reports
„
„ participants are on session – otherwise too many RTCP
packets
„ Convey minimal session control information
„ Not enough for complicated session control requirements
15 16

4
 RTCP - types RTCP – compound packet
„ Sender report (SR): statistics from active sender – „ RTCP packets have a length field in header;
includes RR blocks also aligned to 32 bits --- stackable
„ Receiver report (RR): statistics from participants that „ Sent in a compound packet of at least 2 RTCP
are not active senders
„ RR RTCP packet sent if a node is only a receiver, i.e., it does
packets; example:
not send data
„ Source description report (SDES): includes CNAME,
email, name, phone number, location, application
tool/version
„ BYE: indicates end of participation
„ APP: application-specific functions

17 18

RTCP – sender report (SR) RTCP Receiver Report (RR)

„ SSRC: identifies sender
„ SSRC_n: identifies source whose data this report
„ Sender information block: block is about
NTP timestamp: wallclock time (absolute time as per
„
Network Time Protocol) when packet is sent (seconds
„ Fraction lost: fraction of packets lost since last report
elapsed since 0 hour, January 1, 1900. was sent
„ RTP timestamp: time when packet is sent according to the „ Cumulative number of lost packets since the
clock used to send RTP data packet timestamps; used for beginning of reception
intra- & inter-media synchronization
„ Highest sequence number received
„ Sender’s packet count: total number of packets sent since
the start of session „ Inter-arrival jitter
„ Octet count: total number of bytes sent since the start of „ Last SR (LSR): The NTP timestamp of the last sender
session report received from the source
„ Multiple receiver report blocks, one for each source „ Delay since Last SR (DLSR): Delay between receiving
from which this host receives packets the last SR from this source and sending this RR
19 20

5
Interarrival jitter computation RTCP – round trip time calculation
„ Interarrival jitter J defined as: t1 t4
sender
„ mean deviation (smoothed absolute value) of the
difference D in packet spacing at the receiver SR RR
compared to the sender for a pair of packets receiver
„ D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) t2 DLSR t3
„ Ji = Ji-1 + (|D(i-1,i)| - Ji-1)/16 „ SR packet contains: NTP (=t1)
„ Algorithm: optimal first-order estimator; the gain „ RR packet contains: Last SR timestamp (LSR=t1),
parameter 1/16 gives a good noise reduction ratio Delay Since Last SR (DLSR=t3-t2)
while maintaining a reasonable rate of „ Roundtrip time = t4 - t3 + t2 - t1 = t4 – (t3-t2) –t1
convergence [Cadzow] = t4 – DLSR - LSR
21 22

Analyzing sender
RTCP – RR & SDES and receiver reports
„ Receiver Report (RR): Similar to SR but „ Sender may modify its transmissions based on the
feedback
without sender information block
„ Receivers can determine whether problems are
„ RTCP Source Description packet (SDES) local, regional or global
„ Containing CNAME, mandatory „ Network managers may use profile-independent
„ Constant for a user, unique among all users monitors that receive only the RTCP packets and
„ Provides binding across multiple medias sent by not the corresponding RTP data packets to
a user evaluate the performance of their networks for
„ Example: [email protected] multicast distribution.

23 24

6
 RTCP – transmission interval Other issues
„ Designed to scale from a few to thousands of „ Collision detection and resolution
users „ Two sources use the same SSRC
„ Problem: RTCP traffic is not self-limiting; grows linearly with
number of usesr if sent at a constant rate „ Loop detection
„ Solution: limit control traffic to a small and known fraction of
total session traffic, 5% suggested „ Inter-media synchronization
„ Characteristics of transmission interval calc. algorithm „ Security
„ Sender occupies 25% of total control traffic bandwidth for that
session to allow receivers to quickly know who is sending „ Header compression – RFC 2508
„ Calculated interval should be greater than 5 seconds „ IP+UDP+RTP = 40 bytes, large overhead when
„ Trans. interval randomly varied between a range to avoid voice packets need to be small for delay reasons
synchronization of RTCP packets from many end points
„ Dynamic estimate the average RTCP packet size is made to
adapt to changes in amount of control packets sent
25 26

References
„ RFC 1889, “RTP: A Transport Protocol for Real-
Time Applications”
„ RFC 1890, "RTP Profile for Audio and Video
Conferences with Minimal Control"
„ RFC 2250, "RTP Payload Format for
MPEG1/MPEG2 Video"
„ J. A. Cadzow, "Foundations of Digital Signal
Processing and Data Analysis," New York, New
York: Macmillan, 1987.

27