An Introduction to the Real-time Transport Protocol (RTP)

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-Specific Support Network Adaptation By Application User Space Application Support General Application Support Kernel Space Network Control Network Control Monolithic Transport RTP-like Arrangement

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 User Space Network Control 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 Note that UDP or TCP connections terminates at Firewall. On multicast Address a, port p, p+1 On multicast Address b, port q, q+1 Translator Translator Inside Firewall 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 Domain C Backbone Domain A Client Edge Device Domain B 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 RFC1890: RTP Profile for Audio and Video Conferences with Minimal Control. • 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.

35. Payload Types