Published on

real time protocol

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. An Introduction to the Real-time Transport Protocol (RTP) Ye Xia WebTP Meeting 12/12/00
  2. 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. 3. Violation of the Old View Leads to New Ideas Application Support Network Control Application-Specific Support Network Control Monolithic Transport General Application Support User Space Kernel Space RTP-like Arrangement Network Adaptation By Application
  4. 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. 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 Network Control User Space Kernel Space IP
  6. 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. 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. 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. 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. 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. 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. 12. Example: Translator at Firewall Translator Firewall Translator On multicast Address a, port p, p+1 On multicast Address b, port q, q+1 Inside Firewall Note that UDP or TCP connections terminates at Firewall.
  13. 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. 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. 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. 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. 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. 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. 19. Compound RTCP Packets • A compound RTCP packet contains multiple RTCP packets of the previous types. • Example:
  20. 20. SR Packet
  21. 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. 22. SDES Packet
  23. 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@, etc.
  24. 24. Other Items in SDES Packet • NAME: user name • EMAIL: • PHONE: • LOC: location • TOOL: application or tool name • NOTE: notice/status
  25. 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. 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. 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. 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. 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. 30. A View of Future Network Layer 3 Systems Transport System End Systems
  31. 31. Inter-Domain Scenario Backbone Domain A Client Domain C Domain B Edge Device Access Link Fat Pipe
  32. 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. 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. 34. Example of A Profile Document • 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. RFC1890: RTP Profile for Audio and Video Conferences with Minimal Control.
  35. 35. Payload Types