An Introduction to the Realtime Transport Protocol RTP

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

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

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

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.

Web. TP - Current • Web. TP 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 IP Kernel Space

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-oforder delivery. • Primarily designed to support multiparty multimedia conferences, typically assumes IP multicast.

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.

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.

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.

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.

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.

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 Inside Firewall

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.

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.

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.

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

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.

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

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

SR Packet

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

SDES Packet

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.

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

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

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.

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, 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.

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).

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.

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

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

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.

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.

Example of A Profile Document RFC 1890: 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.

Payload Types