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

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

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

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

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

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

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

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

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

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

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

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?

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.

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)

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)

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

8.1 Translators & Mixers Example

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)

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

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

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)

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)

Critique Security RTCP packet losses – inaccurate statistics