Unit 4.

1
Outcomes
Learners will be able to:
Discuss in detail, the attributes of the RTP
Identify and describe the features of the RTP
Illustrate the RTP header
Describe the specification of the RTP
Multimedia Streaming Protocols
signalling and control protocols
 protocols conveying session setup information and VCR-like
commands (play, pause, mute, setup, fast forward, backward etc.)
 ex. RTSP, SDP, SIP
real-time transport protocols
 protocols that convey the real-time data (audio, video or text)
 RTP/RTCP
RTP (Real-Time Transport Protocol)
is a real-time streaming protocol for IP networks
usually runs on top of UDP
is an Internet standardized packet format for transporting
continuous audio-video data over Internet
was developed by the Audio-Video Transport Working
Group of IETF
the standard was published as RFC 1889 in 1996 and then
superseded by RFC 3550 in 2003
RTP has several profiles and payload types for different
kinds of audio or video streams (e.g. MPEG-1/2/4,
H.26[1234] etc.)
the RTP RFC describes also RTCP (Real Time Control
Protocol) for monitoring QoS parameters
the default port is 5004
RTP characteristics
provides end-to-end delivery service for real-time data, in
unicast and multicast sessions
offers synchronization services (timestamping), packet
identification and loss detection (sequence numbering)
and delivery monitoring/feedback (through RTCP)
does not provide in-order and reliable delivery of packets
does not provide timely delivery of packets, nor QoS
guarantees
is independent of the transport protocol (TCP, UDP,
DCCP, SCTP etc.)
a RTP session carries one multimedia stream; a RTP
session is identified by a pair of triplets (IP address, RTP
port, RTCP port) which are negotiated at setup using RTSP
and SDP
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
RTP Specification
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
RTP

Specification
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
RTP Specification
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
 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
Audio and video conference
Two RTP sessions, one for audio and the other for
video
User can participate on audio, video or both
No direct coupling at RTP level except a user can
use the same name in RTCP packets for both audio
and video
• 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 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.
– 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.
RTP – packet format
V P X CSRC M Payload Sequence number
count type (16 bits) Fixed
header
Timestamp (32 bits)
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
RTP HEADER
RTP Header
 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 packet header
 version (2 bits) - RTP version number, always 2;
 padding (1 bit) - if set, the packet contains padding bytes at the end of the payload; the
last byte of padding contains how many padding bytes should be ignored;
 extension (1 bit) - if set, the RTP header is followed by an extension header;
 CSRC count (4 bits) - number of CSRCs (contributing sources) following the fixed
header;
 marker (1 bit) - the interpretation is defined by a profile;
 payload type (7 bits) - specifies the format of the payload and is defined by an RTP
profile;
 sequence number (16 bits) - the sequence number of the packet; the sequence
number is incremented with each packet and it can be used by the receiver to detect
packet losses;
 timestamp (32 bits) - reflects the sampling instance of the first byte of the RTP data
packet; the timestamp must be generated by a monotonically and linearly increasing
clock;
 synchronization source (SSRC) (32 bits) - identifies the source of the real-time data
carried by the packet;
 contributing sources (CSRC) (32 bits) - identifies a maximum of 15 additional
contributing sources for the payload of this RTP packet.
RTP header extensions
the Marker and PayloadType fields are defined by a
profile and the profile may even redefine the octet
containing these 2 fields
additional fixed fields can be added after the fixed
header by a profile
if the X bit in the RTP header is 1, a variable-length
header extension (for which the first 32 bits have a
specific structure) follows the fixed header; is intended
for limited use, experimenting and can be ignored by
non interested applications
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
same delay
t
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
Mixers and Translators
Mixer
Could receive and combine various sources in an effort
to reduce bandwidth
Translator
Keeps incoming sources separate
To transform to a lower quality format to broadcast on
lower-speed networks
To send through firewalls
RTP Mixer and Translator
Mixer
64 kbps 8 kbps
G.729
Mixer
64 kbps

64 kbps

 Translator
firewall
8 kbps
Translator
G.729

64 kbps Translator
PCM
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
RTP
RTP Features
Multicasting
Payload type identification
Time stamping
Sequencing
Delivery monitoring
RTP
RTP Issues
No QoS guarantees
No guarantee of packet delivery
RTP Timestamp (TS) and Sequence Number (SN)
TS used to order packets in correct timing order
SN to detect packet loss
For a video frame that spans multiple packets – TS is
same but SN is different
RTP profiles (Payload Types)
 RFC 2032 – RTP payload format for H.261 Video streams
 RFC 2190 - RTP payload format for H.263 Video streams
 RFC 2250 – RTP payload format for MPEG1/MPEG2 video
 RFC 3984 - RTP payload format for H.264 Video streams
 RFC 3016 – RTP payload format for MPEG-4 Audio/Visual streams
 RFC 2435 – RTP payload format for JPEG-compressed video
 RFC 3551 – RTP profile for Audio ad Video conferences with minimal
control
 RFC 3640 - RTP payload format for transport of MPEG-4 Elementary
Streams
 RFC 4175 – RTP payload format for uncompressed video