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

. But should not be overly ambitious. application support function needs to be general. Why? – Transport sits in the kernel. – The philosophy of some transport designers: transport should have sufficient generality. Hard to modify. – API needs to be stable.Fine-grained Application Support • In monolithic transport. • How to accommodate specific application’s needs? – Build complex logic into the (monolithic) transport.

WebTP .Current • WebTP is still monolithic • Some trade-off of programmability with efficiency. Application Support User Space Network Control IP Kernel Space . but may be justifiable. – The key is to make the user-IP path fast.

TCP. and less often. • Primarily designed to support multiparty multimedia conferences. . timestamping and delivery monitoring • Runs on top of UDP.Overview of RTP • Provides end-to-end delivery services for real-time traffic: interactive audio and video – Payload identification. sequence numbering. typically assumes IP multicast. – RTP does not guarantee delivery or prevent out-oforder delivery.

– A complete specification for an application also includes a profile and a payload format document. – Is typically integrated into the application processing. – Protocol is deliberately not complete. • 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. – Is malleable to provide application specific info. It only contains the common functions.Overview – Cont. • Principles of application level framing and integrated layer processing.

and other status info can be monitored.Multicast audio conference • Need a multicast address and a pair of ports: one for data and one for (RTCP) control. • RTP header contains timing information. Senders can change encoding during the conference. • Senders and receivers multicast reports through RTCP. • RTP header contains type of audio encoding (such as PCM).Example. . Audio data can be played out as they are produced by the source. delay jitter. Packet loss ratio.

• The decoupling of the two sessions allows some participants to join only one session. .) • Each participant of both sessions can be identified by the same name in RTCP packets. (with different UDP ports and/or multicast addresses.Example – Audio and Video Conference • Audio and video are transmitted using separate RTP sessions.

. Receivers can identify individual sources even though packets pass through the same translator and carry the translator’s network source address. • Mixer is like a new RTP-level source to the receivers. • A translator forwards RTP packets from different sources separately. • Translator is more transparent.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. • Mixer can re-synchronize the incoming stream and generates its own timing info.

transcoding for low-bandwidth links. emulating multicast address with one or more unicast addresses. • Multiple data packets can be combined into one. adding or removing encryption. • Uses of translators and mixers: go-through firewalls. • They both use a different transport address (network address + port) at the output side. but is changed at a mixer.Translators and Mixers • The real distinction between mixers and translators: SSRC identifier is not changed at a translator. .

On multicast Address b.Example: Translator at Firewall Note that UDP or TCP connections terminates at Firewall. q+1 Translator On multicast Address a. port p. port q. p+1 Translator Inside Firewall Firewall .

from a mixer. for layered encoding transmitted on separate RTP sessions a single SSRC is used for all layers. . – Examples: all packets from a camera. – A participant need not use the same SSRC for all RTP sessions in a multimedia session. Receivers group packets by SSRC for playback.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. – Not dependent on network address.

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.

with the intent that no two synchronization sources in the same session have the same SSRC. • SSRC: chosen randomly for each synchronization source. clock may increment by one for each sampling period. – Example: for fixed-rate audio. • Timestamp – Reflects sampling instant of the first byte of data – Clock frequency can be specified by profile of payload format documents for the application.RTP Fixed Header – Cont. .

the byte containing them can be redefined by the profile.Profile-Specific Modifications to the RTP Header • Marker bit and payload type are interpreted according to the application’s profile. – Variable length – Used to experimental purpose . • If a particular class of application needs additional functionality. exactly one header extension follows CSRC list (if present). • Moreover. • If X bit is 1. the profile should define additional fixed fields following SSRC.

– Through sender and receiver reports.RTCP • Primary function is to provide feedback on the quality of data distribution. 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. – Can be used to diagnose faults • RTCP carries a persistent transport-level identifier for an RTP source. . – For adaptive encoding (adaptive to network congestion).

sending and reception stat. for reception statistics from multiple sources.RTCP Packets • SR: sender reports. include CNAME • BYE: indicates end of participation • APP: application specific functions . • SDES: source description item. • RR: receiver reports.

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

SR Packet .

Fraction lost: since the last RR or SR packet was sent. Short term loss ratio. • • • • • • • RC: receiver report count Length: in 32-bit words – 1 NTP ts: wallclock time. DLSR: delay since last SR. Source SSRC_n can compute RTT using DLSR.SR Packet – Cont. A. RTT = A – LSR – DLSR An application’s profile can define extensions to SR or RR packets • . used to calculate RTT RTP ts: in unit and offset of RTP ts in data packets. LSR and the reception time of the report. middle 32 bits of NTP timestamp. LSR: last SRT time stamp. Can be used with NTP ts for inter-media synchronization. expressed in 1/65536 seconds between receiving the last SR packet from SSRC_n and sending this report.

SDES Packet .

. doe@192.CNAME Item in SDES Packet • Mandatory • Provides a persistent identifier for a source.89.2. • SSRC is bound to CNAME • Example: doe@sleepy.com.megacorp. CNAME should be fixed for that participant. • Provides a binding across multiple media used by one participant in a set of related RTP sessions.0. 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. “camera malfunction” . e. • Reason for leaving: string field.g.

• Name: unique name in the scope of one this application. .APP RTCP Packet • Subtype: allows a set of APP packets to be defined under one unique name.

Necessity of this feature is not clear.I • RTP defines transport support for common functions of real-time applications. etc. EMAIL. NAME. and jitters. . Participants indication: CNAME.Conclusions . Multicast distribution support Conversion: mixers and translators • Extensible protocol by profile payload format documents • Customizable to application or application classes. – – – – – – – Timing information: sampling period and NTP Synchronization source for playback Payload types (encoding) Quality reports: short-term and long-term packet loss.

because there is little hard guarantee (It relies on TCP or application for hard guarantees). . – Can accomplish complex control features.Conclusion – II • Separation of control and data stream (analogous to out-band signaling) – Data header overhead is small. – Complexity of the protocol/algorithm is not so bad.

• Mixers and translators are stand-alone processes. .Conclusions – III • Congestion control is not defined in baseline document. They terminate TCP or UDP connections. but may be defined by application’s profile. but does not run as stand-alone process. – Leads to application-specific congestion control or adaptation • RTP can be considered user-space transport entities.

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 .

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.RTP Algorithms . – Each compound RTCP packet must include a report packet and a SDES packet for timely feedback. .

• 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.II • SSRCs are chosen randomly and locally and can collide.RTP Algorithms . . – Parallel translators. • Collision avoidance of SSRC and loop detection are entangled.

– No SR/RR extensions are defined – SDES use: CNAME is sent every reporting interval. • RTP data header: – use one marker bit – No additional fixed fields – No RTP header extensions are defined. .Example of A Profile Document RFC1890: RTP Profile for Audio and Video Conferences with Minimal Control. other items should be sent only every fifth reporting interval. • RTCP – No additional RTCP packet types.

Payload Types .