RTP: A Transport Protocol for

Real-Time Applications

RFC 1889

H. Schulzrinne, GMD Fokus, S.

Casner, R. Frederick, V. Jacboson
 Introduction
 Internet standard for real-time data
 Interactive audio, video, and simulation data
 Primarily designed for multi-user multimedia
conference
 Session management
 Scalability considerations
 Provides end-to-end transport functions for real-time
applications
 Payload type identification
 Sequence numbering
 Timestamping
 Delivery monitoring
 Introduction – cont.
 Containing two closely linked parts: data + control
 RTP: Real-time transport protocol
 Carry real-time data

 RTCP: RTP control protocol

 QoS monitoring and feedback

 Session control

 Architecture
Applications
RTP & RTCP
Other transport and UDP
network protocols IP
 Introduction – cont.
 Independent of the underlying transport and
network layers
 Does NOT provide timely delivery or other
QoS guarantees
 Relies on lower-layer
 Does NOT assume the underlying network is
reliable and delivers packets in sequence
 Use sequence number
Introduction – cont.
 New style: Application level framing and
integrated layer processing
 Often be integrated into the application
rather than a separate layer
 Deliberately not complete – Application
could add or tailor when needs
 Complete specification of RTP for particular
application needs other documents
 Profile, payload format specification document
 RTP use scenarios
 Simple multicast audio conference
 A multicast address and two UDP ports (for RTP and
RTCP ), assigned and distributed by mechanisms
beyond the scope of RTP
 Speaker send:
IP header UDP header RTP header Audio data
 Receiver play out audio data according to RTP header
 Sender/receiver periodically multicast report by RTCP
 Who is participating?
 How well is the audio quality?
RTP use scenarios – cont.
 Audio and video conference
 Two RTP sessions, one for audio and the
other for video
 User can participate audio, video or both
 No direct coupling at RTP level except a
user use the same name in RTCP packets
for both audio and video
 RTP – packet format
V P X CSRC M Payload Sequence number
count type (16 bits) Fixed
Timestamp (32 bits) header
Synchronization source (SSRC) id. (32 bits)
Contributing source (CSRC) id. (0~15 items, 32 bit each) optional
Header extension (optional) header
Payload (real time data)
Padding (size Padding size
optional
x 8 bits) (8bits)
 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
 RTP - header
 CSRC count (4 bits): number of CSRC id.
 Marker (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 seq. restoration
 SSRC: identify source; chosen randomly and locally;
collision needs to be resolved
 CSRC list: id. of contributing sources, inserted by mixer
 RTP – header - timestamp
 Reflects sampling instance of the first octet in payload
 Derived from a clock increments monotonically and linearly
 Clock frequency depends on data type; specified in profile
 Random initial value
 Example: CBR audio, clock increment by 1 for each sample.
If block have 160 samples, timestamp increase 160
 Consecutive RTP packets may have same timestamp: Video
 Timestamps of consecutive RTP may not increase
monotonically: MPEG interpolated video frames
 RTP – intra-media synchronization
 Reconstruction with playout buffering
Desired: all
packets have the
t same delay
Packets
sent
d1 d1+y
Packets
received
h h-y
Packets
playout
t
RTP – cont.
 Multiplexing
 Provided by transport address (network
address + port number)
 Teleconference with Audio and Video
 A and V are carried in separate RTP session
 Each session has two transport address
 Profile-specific modification
 Marker bit
 Header extension starts at payload section
 RTCP – RTP control protocol
 Periodically transmit report to all participants;
Functions of RTCP:
 Provide QoS feedback
 Carry persistent id. - Canonical name (CNAME)
 Track a user if SSRC changed (confliction, etc.)
 Associate multiple streams from a user – A and V
 Control the rate of RTCP packets – scalability
 Convey minimal session control information
 Not enough for complicated session control requirements
RTCP - types
 Sender report (SR): statistics from
active sender
 Receiver report (RR): statistics from
participants except active sender
 Source description item (SDES):
includes CNAME
 BYE: indicates end of participation
 APP: application specific functions
RTCP – compound packet
 RTCP packets have a length field in
header; aligned to 32 bits --- stackable
 Sent in a compound packet of at least 2
RTCP packets; example:
 RTCP – sender report (SR)
 SSRC: identify sender
 Sender info. block:
 NTP timestamp: sent time (wallclock time or other)
 RTP timestamp: corresponding to NTP but in formats of
RTP data packet timestamp; used for intra&inter media
synchronization
 Sender’s packet count & octet count
 Multiple report blocks, each block has
 SSRC_n, fraction lost, number of lost
 Highest sequence number received
 Inter-arrival jitter, LSR, DLSR
RTCP – RR & SDES
 Receiver Report (RR): Similar to SR but
without sender information block
 RTCP Source Description packet (SDES)
 Containing CNAME, mandatory
 Constant for a user, unique among all users
 Providing binding across multiple medias sent
by a user
 Example: poly_id@utopia.poly.edu;
7182603384
 RTCP – round trip time calculation
t1 t4
sender
SR RR
receiver
t2 DLSR t3
 SR packet contains: NTP (=t1)
 RR packet contains: Last SR timestamp (LSR=t1),
Delay Since Last SR (DLSR=t3-t2)
 Roundtrip time = t4 - t3 + t2 - t1 = t4 – (t3-t2) –t1
= t4 – DLSR - LSR
 RTCP – transmission interval
 Designed to scale from a few to thousands users
 Problem: RTCP traffic is not self-limiting; grows linearly with
number of user if sent in constant rate
 Solution: limit control traffic to a small and known fraction of
total session traffic, 5% suggested
 Small: efficiency Known: resource reservation
 Characteristics of transmission interval calc. algorithm
 Sender occupies 25% of control traffic bandwidth
 Calculated interval should be no less than 5 seconds
 Trans. interval randomly varied between a range
 Dynamic estimate average compound packet size
RTP Mixer and Translator
 Mixer 64 kbps 8 kbps
G.729
64 kbps Mixer

64 kbps

 Translator
8 kbps firewall
G.729 Translator

64 kbps Translator
PCM
Other issues
 Collision detection and resolution
 Two sources use the same SSRC
 Loop detection
 Inter-media synchronization
 Security
 Header compression – RFC 2508
 IP+UDP+RTP = 40 bytes, large overhead