1. RTP: A Transport Protocol for Real-Time Applications
Felipe Santos

2. Roadmap Definition What RTP Does Not Do What RTP Does Protocol Stack
Terminology Definitions
RTP Packet Structure
A Quick Note on Multiplexing RTP Sessions
Translators & Mixers
RTCP Overview
Security

3. 1. Definition Real-Time Transport Protocol
Demand for real-time applications on IP networks on the rise
End-to-end transport protocol designed to facilitate the transmission of data with real-time characteristics
RFC 3550

4. 2. What RTP Does Not Do
Provide any mechanism to ensure timely delivery or other QoS guarantees
Guarantee delivery
Prevent out-of-order delivery
Assume that the underlying network is reliable

5. 3. What RTP Does Carry data that has real-time properties
Provide the means to transmit real-time data across different network segments with possible different bandwidths
Continuous monitoring of real-time data delivery to every participating node in a given RTCP session
Malleable standard protocol

6. 4. Protocol Layer Stack Most commonly implemented on top of UDP
Transport
Layer
copyright
J.F Kurose and K.W. Ross, All Rights Reserved
Most commonly implemented on top of UDP
Also works on TCP

7. 5. Terminology Definitions
RTP payload: data packet transported by RTP in a packet
RTP packet: data packet consisting of the RTP header and the RTP payload. This packet is in turn encapsulated into an appropriate transport layer packet
Multimedia session: set of parallel RTP sessions among a common group of participants
RTP session: a set of participants communicating via RTP

8. 6. RTP Packet Structure RTP Payload
V P X CC M PT Sequence Number
Timestamp
Synchronization source (SSRC) identifier
Contributing source (CSRC) identifiers
RTP Payload
Version (V) – 1 [RFC 1889] or 2[RFC3550]
Padding (P) – if 1, packet contains additional padding octets not part of the payload
Extension (X) – if set, header contains one extension
CSRC count (CC) – number of CSRC identifiers included
Marker (M) – implementation specific use

9. 6.1 Payload Type
Payload type (PT) – identifies the format of the RTP payload and determines its interpretation by the application
Currently supported audio payload types:
PT #
Audio Format
Samp. Rate
Bit Rate
PCM m-law
8 KHz
64 Kbps 1
1016
4.8 Kbps 3
GSM
13 Kbps 7
LPC
2.4 Kbps 9
G.722
16 KHz
48-64 Kbps 14
MPEG audio
90 KHz
variable 15
G.728
16 Kbps

10. 6.2 Sequence Number Currently supported video payload types:
Sequence number – increments by one for each packet sent by each source in a RTP session. Could be used by the receiver to detect packet loss and to restore packet ordering. Initial value is randomly (unpredictably) chosen by each source at the time of first transmission
PT #
Video Format 26
Motion JPEG 31
H.261 32
MPEG1 Video 33
MPEG2 Video

11. 6.3 Timestamp
Reflects the sampling instant of the first octet in the RTP data packet
Synchronization and jitter calculations performed based on this value
Clock restrictions:
Increments monotonically and linearly
Sufficiently high resolution to enable desired synchronization accuracy
Exceptional cases:
RTP packets logically generated at the same instant, will have the same timestamp
Payload types such as MPEG2 Long GOP may generate non- monotonic/linear timestamp increments

12. 6.4 Synchronization Source Identifier (SSRC)
Identifies the synchronization source
ID randomly chosen
Must be globally unique within any given RTP session
SSRC space = 232 = 4,294,967,296 IDs
What is a possible problem?

13. 6.4.1 SSRC Collisions Case 1: All sources started at the same time
Worst case scenario
N = number of sources (large)
L = length of ID = 32 bits
Case 2: One new source that has not received any packets
Probability of collision much lower
Case 3: One new source that has received at least one packet
Probability further reduced because the joining source knows at least a subset (k items) of the already taken IDs
Aside: If a source detects a collision, it must send a BYE packet for the old ID and pick a new one. If a receiver detects a collision between 2 sources, it may keep the packets from one and discard the other’s.

14. 6.5 CSRC List Contributing source identifiers
Tracks all contributors in a mixed packet
IDs inserted by mixers (discussed next)
Up to 15 can be listed
Could generate a maximum default RTP header size of 576 bits (excludes padding and extension)

15. 7. A Quick note on Multiplexing RTP Sessions
Separate audio and video streams should not be carried in a single RTP session, unless the media format has natively embedded the streams
Problems introduced by multiplexing:
If two audio streams, for instance, were multiplexed, and one changed its payload type on the fly, there would be no way of distinguishing the one that changed
There is only one timing space per session
RTCP can only provide statistics for one timing reference
Mixers would be unable to combine incompatible media types
Prevents clients from choosing whether or not he/she wishes to receive both streams (possible bandwidth problems)

16. 8. Translators & Mixers Intermediate systems at the RTP level
Translator – Forwards RTP packets with their SSRC identifier intact. Payload may or may not be affected. Makes RTP transmission possible across network barriers (e.g. Firewalls, local network policies, etc)
Mixer – Receives streams of RTP data packets from one or more sources, possibly changes data format, combines these streams in some predefined manner, and then forwards the mixed packet with its own SSRC ID and appends each source’s respective SSRC ID to the mixed packet’s CSRC field. Responsible for timing adjustments

17. 8.1 Translators & Mixers Example

18. 9. RTP Control Protocol (RTCP)
Provides the necessary statistics to allow for monitoring of QoS and convey information about the participants of an ongoing session
4 functions:
Primary function: provide feedback on the quality of the data distribution. Control of adaptive encodings and network diagnostics
Carry a persistent transport-level canonical name (CNAME) for an RTP source. SSRC ID collision and loop detection.
The fact that all RTP participants send its own RTCP packets to all other participants implies that all nodes know how many users are connected to the session. Used to determine the RTCP send rate (discussed next)
Optional: Convey minimal session control information
Packet types: Sender Report (SR), Receiver Report (RR), Source Description Items (SDES), End of Participation (BYE), Application Specific (APP)

19. 9.1 RTCP Example
All users continuously exchange RTCP packets. What is a potential problem?
copyright
J.F Kurose and K.W. Ross, All Rights Reserved

20. 9.2 RTCP Transmission Rate
Each user concatenates all of its RTCP packets into a single compound packet that gets sent at a calculated time interval
Not in the original proposal of RTP (RFC 1889)
Original proposal suggested a method that allowed RTCP packets to grow linearly with increasing number of users, which could very quickly overpower the RTP data bandwidth and generate excessive network congestion
This approach attempts to limit RTCP traffic to 5% of the session bandwidth, which is divided such that 25% of this rate is dedicated to senders and 75% to receivers

21. 10. Security & SRTP
Because current transport protocols do not implement security measures, a confidentiality approach was embedded in RTP
New real-time secure transport protocol – Secure RTP (SRTP) is being developed (RFC 3711) – based on Advanced Encryption Standard (AES)
Confidentiality – Only intended receivers can decode the received packets
RTCP: 32 bit random number redrawn for each encrypted transport layer unit to be sent – number must be prepended to each unit
RTP: no number prepended; instead sequence number and timestamp fields are initialized with random offsets
Default encryption algorithm is Data Encryption Standard (DES) algorithm with cipher block chaining (CBC) mode (RFC 1423)

22. 11. Related Work
RFC 1889 – First version of RTP: major difference RTCP send period calculation
Timer Reconsideration for Enhanced RTP Scalability Jonathan Rosenberg and Henning Schulzrinne
RFC 3711 – SRTP
RFC 3261 – Session Initiation Protocol (SIP)

23. Critique
Security
RTCP packet losses – inaccurate statistics