You are on page 1of 35

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

Ye Xia WebTP 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

Network Adaptation By Application General Application Support Network Control

Application Support

Kernel Space

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 applications needs?


Build complex logic into the (monolithic) transport. But should not be overly ambitious.

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

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 translators 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 b, port q, q+1 Translator

On multicast Address a, port p, p+1 Translator

Inside Firewall 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 applications 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 participants 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 applications 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, 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.

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 applications 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
Backbone

Domain C

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


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.

Payload Types

You might also like