real time protocol

1. An Introduction to the Real-time
Transport Protocol (RTP)
Ye Xia
WebTP Meeting
12/12/00

2. Transport Functions
• Application Support
– Reliability control: loss recover, in-sequence delivery,
etc.
• Network Control
– Congestion control, rate allocation, etc
• The distinction between the two is not sharp.
– Rate allocation and scheduling can be viewed as part of
either one above.
• This dual view arises when we contemplate
traditional transports: TCP and UDP

3. Violation of the Old View Leads
to New Ideas
Application
Support
Network
Control
Application-Specific
Support
Network
Control
Monolithic Transport
General Application
Support
User Space
Kernel Space
RTP-like Arrangement
Network Adaptation
By Application

4. Fine-grained Application Support
• In monolithic transport, application support
function needs to be general. Why?
– Transport sits in the kernel. Hard to modify.
– API needs to be stable.
– The philosophy of some transport designers: transport
should have sufficient generality.
• How to accommodate specific application’s
needs?
– Build complex logic into the (monolithic) transport. But
should not be overly ambitious.

5. WebTP - Current
• WebTP is still monolithic
• Some trade-off of programmability with efficiency, but
may be justifiable.
– The key is to make the user-IP path fast.
Application
Support
Network
Control
User Space
Kernel Space
IP

6. Overview of RTP
• Provides end-to-end delivery services for real-time
traffic: interactive audio and video
– Payload identification, sequence numbering,
timestamping and delivery monitoring
• Runs on top of UDP, and less often, TCP.
– RTP does not guarantee delivery or prevent out-of-
order delivery.
• Primarily designed to support multiparty
multimedia conferences, typically assumes IP
multicast.

7. Overview – Cont.
• The protocol has two parts.
– RTP: carry real-time data
– RTP control protocol (RTCP): monitor the quality of
service and to convey information about the
participants.
• Principles of application level framing and
integrated layer processing.
– Is malleable to provide application specific info.
– Is typically integrated into the application processing.
– Protocol is deliberately not complete. It only contains
the common functions.
– A complete specification for an application also
includes a profile and a payload format document.

8. Example- Multicast audio
conference
• Need a multicast address and a pair of ports: one
for data and one for (RTCP) control.
• RTP header contains type of audio encoding (such
as PCM). Senders can change encoding during the
conference.
• RTP header contains timing information. Audio
data can be played out as they are produced by the
source.
• Senders and receivers multicast reports through
RTCP. Packet loss ratio, delay jitter, and other
status info can be monitored.

9. Example – Audio and Video
Conference
• Audio and video are transmitted using
separate RTP sessions. (with different UDP
ports and/or multicast addresses.)
• Each participant of both sessions can be
identified by the same name in RTCP
packets.
• The decoupling of the two sessions allows
some participants to join only one session.

10. Example – Mixers and
Translators
• Mixers: a RTP-level entity that receives streams of RTP
data packets from one or more sources and combines them
into a single stream.
• A translator forwards RTP packets from different sources
separately.
• Mixer is like a new RTP-level source to the receivers.
• Translator is more transparent. Receivers can identify
individual sources even though packets pass through the
same translator and carry the translator’s network source
address.
• Mixer can re-synchronize the incoming stream and
generates its own timing info.

11. Translators and Mixers
• The real distinction between mixers and translators: SSRC
identifier is not changed at a translator, but is changed at a
mixer.
• They both use a different transport address (network
address + port) at the output side.
• Multiple data packets can be combined into one.
• Uses of translators and mixers: go-through firewalls;
transcoding for low-bandwidth links; adding or removing
encryption; emulating multicast address with one or more
unicast addresses.

12. Example: Translator at Firewall
Translator
Firewall
Translator
On multicast
Address a, port p, p+1
On multicast
Address b, port q, q+1
Inside Firewall
Note that UDP or TCP connections terminates at Firewall.

13. Some RTP Definitions
• Transport address: network address + port
• RTP session: communications on a pair of transport
addresses (data + control)
• Synchronization source (SSRC): the source of a stream of
RTP packets
– Identified by 32-bit SSRC identifier.
– All packets from the same SSRC form a single timing and
sequencing space. Receivers group packets by SSRC for playback.
– Not dependent on network address.
– Examples: all packets from a camera; from a mixer; for layered
encoding transmitted on separate RTP sessions a single SSRC is
used for all layers.
– A participant need not use the same SSRC for all RTP sessions in a
multimedia session.

14. RTP Fixed Header
P: Padding
X: Header Extension
CC: CSRC count
M: Marker of record
boundary
PT: Payload type; mapping can be
specified by profile of the
application
Sequence number: for each packet
can be used by the receiver to
detect loss or restore sequence.

15. RTP Fixed Header – Cont.
• Timestamp
– Reflects sampling instant of the first byte of data
– Clock frequency can be specified by profile of payload
format documents for the application.
– Example: for fixed-rate audio, clock may increment by
one for each sampling period.
• SSRC: chosen randomly for each synchronization
source; with the intent that no two synchronization
sources in the same session have the same SSRC.

16. Profile-Specific Modifications to
the RTP Header
• Marker bit and payload type are interpreted
according to the application’s profile.
• Moreover, the byte containing them can be
redefined by the profile.
• If a particular class of application needs additional
functionality, the profile should define additional
fixed fields following SSRC.
• If X bit is 1, exactly one header extension follows
CSRC list (if present).
– Variable length
– Used to experimental purpose

17. RTCP
• Primary function is to provide feedback on the quality
of data distribution.
– Through sender and receiver reports;
– For adaptive encoding (adaptive to network congestion);
– Can be used to diagnose faults
• RTCP carries a persistent transport-level identifier for
an RTP source, called canonical name, CNAME.
– Receivers use CNAME to keep track of each participant
– And to synchronize related media streams (with the help of
NTP)
• Passes participant’s identification for display.

18. RTCP Packets
• SR: sender reports; sending and reception
stat.
• RR: receiver reports; for reception statistics
from multiple sources.
• SDES: source description item, include
CNAME
• BYE: indicates end of participation
• APP: application specific functions

19. Compound RTCP Packets
• A compound RTCP packet contains multiple
RTCP packets of the previous types.
• Example:

20. SR Packet

21. SR Packet – Cont.
• RC: receiver report count
• Length: in 32-bit words – 1
• NTP ts: wallclock time, used to calculate RTT
• RTP ts: in unit and offset of RTP ts in data packets. Can be used
with NTP ts for inter-media synchronization.
• Fraction lost: since the last RR or SR packet was sent. Short term
loss ratio.
• LSR: last SRT time stamp; middle 32 bits of NTP timestamp.
• DLSR: delay since last SR; expressed in 1/65536 seconds between
receiving the last SR packet from SSRC_n and sending this report.
Source SSRC_n can compute RTT using DLSR, LSR and the
reception time of the report, A.
RTT = A – LSR – DLSR
• An application’s profile can define extensions to SR or RR packets

22. SDES Packet

23. CNAME Item in SDES Packet
• Mandatory
• Provides a persistent identifier for a source.
• Provides a binding across multiple media used by one
participant in a set of related RTP sessions. CNAME should
be fixed for that participant.
• SSRC is bound to CNAME
• Example: doe@sleepy.megacorp.com; doe@192.0.2.89, etc.

24. Other Items in SDES Packet
• NAME: user name
• EMAIL:
• PHONE:
• LOC: location
• TOOL: application or tool name
• NOTE: notice/status

25. BYE: Goodbye RTCP Packet
• Mixers should forward the BYE packet with
SSRC/CSRC unchanged.
• Reason for leaving: string field; e.g., “camera
malfunction”

26. APP RTCP Packet
• Subtype: allows a set of APP packets to be
defined under one unique name.
• Name: unique name in the scope of one this
application.

27. Conclusions - I
• RTP defines transport support for common
functions of real-time applications.
– Timing information: sampling period and NTP
– Synchronization source for playback
– Payload types (encoding)
– Quality reports: short-term and long-term packet loss, and jitters.
– Participants indication: CNAME, NAME, EMAIL, etc.
– Multicast distribution support
– Conversion: mixers and translators
• Extensible protocol by profile payload format documents
• Customizable to application or application classes.
Necessity of this feature is not clear.

28. Conclusion – II
• Separation of control and data stream
(analogous to out-band signaling)
– Data header overhead is small.
– Can accomplish complex control features.
– Complexity of the protocol/algorithm is not so
bad, because there is little hard guarantee (It
relies on TCP or application for hard
guarantees).

29. Conclusions – III
• Congestion control is not defined in baseline
document, but may be defined by application’s
profile.
– Leads to application-specific congestion control or
adaptation
• RTP can be considered user-space transport
entities, but does not run as stand-alone process.
• Mixers and translators are stand-alone processes.
They terminate TCP or UDP connections.

30. A View of Future Network
Layer 3 Systems
Transport System
End Systems

31. Inter-Domain Scenario
Backbone
Domain A
Client
Domain C
Domain B
Edge Device
Access Link
Fat Pipe

32. RTP Algorithms - I
• RTCP packets generation: need to limit the control
traffic
– Control traffic takes 5% of data traffic bandwidth (not
defined)
– ¼ of the RTCP bandwidth is used by senders
– Interval between RTCP packets scales linearly with the
number of members in the group.
– Each compound RTCP packet must include a report
packet and a SDES packet for timely feedback.

33. RTP Algorithms - II
• SSRCs are chosen randomly and locally and can
collide.
• Loops introduced by mixers and translators
– A translator may incorrectly forward a packet to the
same multicast group from which it has received the
packet.
– Parallel translators.
• Collision avoidance of SSRC and loop detection
are entangled.

34. Example of A Profile Document
• RTP data header:
– use one marker bit
– No additional fixed fields
– No RTP header extensions are defined.
• RTCP
– No additional RTCP packet types.
– No SR/RR extensions are defined
– SDES use: CNAME is sent every reporting interval,
other items should be sent only every fifth reporting
interval.
RFC1890: RTP Profile for Audio and Video Conferences with Minimal Control.

35. Payload
Types