Published on

  • Be the first to comment

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

No notes for slide


  1. 1. Real-Time Transport Protocol (RTP) Tung Dao Manh Future Internet Class, 2007.04.15 1
  2. 2. Agenda <ul><li>Introduction </li></ul><ul><ul><li>Motivation </li></ul></ul><ul><ul><li>RTP outline </li></ul></ul><ul><li>Fundamental design philosophies of RTP </li></ul><ul><ul><li>Application-level framing </li></ul></ul><ul><ul><li>The end-to-end principle </li></ul></ul><ul><ul><li>Flexibility </li></ul></ul><ul><li>Standard elements of RTP </li></ul><ul><ul><li>RTP Specification </li></ul></ul><ul><ul><li>RTP Profile </li></ul></ul><ul><ul><li>RTP Payload Format </li></ul></ul><ul><li>RTP Packet Format </li></ul><ul><li>Potential further development of RTP </li></ul><ul><li>Related Protocol </li></ul><ul><ul><li>RTCP </li></ul></ul><ul><li>Conclusion </li></ul>2
  3. 3. Introduction <ul><li>Requirements for delivery of media stream </li></ul><ul><ul><li>Examples of real-time applications: </li></ul></ul><ul><ul><ul><li>Videoconferencing </li></ul></ul></ul><ul><ul><ul><li>VoIP, IP telephone system </li></ul></ul></ul><ul><ul><ul><li>Game online… </li></ul></ul></ul><ul><ul><li>Real-time data: interactive audio and video </li></ul></ul><ul><ul><ul><li>Receivers: playing out immediately and synchronously, rather than playing back </li></ul></ul></ul><ul><ul><li>Requirements for transport protocols: </li></ul></ul><ul><ul><ul><li>Predictable variation in network transit time </li></ul></ul></ul><ul><ul><ul><li>Reliable delivery of all packets </li></ul></ul></ul>Motivation 8
  4. 4. Introduction <ul><li>Requirements drive the choice of transport protocols </li></ul><ul><ul><li>TCP/IP </li></ul></ul><ul><ul><ul><li>It favors reliability over timeliness, but these applications require timely delivery. Retransmissions can lead to high delay and cause delay jitter </li></ul></ul></ul><ul><ul><ul><li>Does not support multicast </li></ul></ul></ul><ul><ul><ul><li>Congestion control mechanism not suitable for audio-video (AV) media </li></ul></ul></ul><ul><ul><li>UDP/IP </li></ul></ul><ul><ul><ul><li>A UDP/IP-based should be suitable, provided that the variation in transit time of the network can be characterized and loss rates are acceptable. But it is: </li></ul></ul></ul><ul><ul><ul><ul><li>No defined technique for synchronizing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Streams from different servers may collide </li></ul></ul></ul></ul><ul><ul><ul><ul><li>A feedback channel must be defined for quality control </li></ul></ul></ul></ul>Motivation 8
  5. 5. Introduction <ul><li>The standard real-time transport protocol was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889 – A solution to these described problems. </li></ul>Motivation 8
  6. 6. Introduction Real-time data transport at glance 8 <ul><li>Encoded frames are produced </li></ul><ul><li>They are assigned a timestamp and a sequence number </li></ul><ul><li>Then, they are load into RTP packet and ready for transmission </li></ul><ul><li>The sender also generates periodic status reports in the form of RTCP packets to participants </li></ul><ul><li>The participants also send quality feedback to the sender. </li></ul><ul><li>Collect packets from network, and insert them into a per-sender input queue. </li></ul><ul><li>Packets then are passed to a channel- coding routine for loss correct. </li></ul><ul><li>Next, they are put into a playout-buffer, and any variation in interpacket timing caused by the network has been smoothed. </li></ul><ul><li>They are then grouped to form complete frames that are decoded to play out. </li></ul>
  7. 7. Introduction <ul><li>RTP: Defines a standardized packet format for delivering audio and video over the internet. </li></ul><ul><li>Internet standard for real-time data </li></ul><ul><ul><li>Interactive and streamed audio and video </li></ul></ul><ul><ul><li>Designed for multi-user multimedia conferencing </li></ul></ul><ul><li>Provides end-to-end transport functions for real-time applications </li></ul><ul><ul><li>Delay-oriented rather than loss-oriented (such as TCP) </li></ul></ul>RTP Outline 8
  8. 8. RTP <ul><li>Application-Level Framing </li></ul><ul><ul><li>A transport protocol should accept data in application-meaningful units (ADUs) </li></ul></ul><ul><ul><li>A transport protocol should expose the details of the data delivery as much as possible </li></ul></ul><ul><li>The end-to-end principle </li></ul><ul><ul><li>The system can pass responsibility for the correct delivery of data along that with data, meaning it relies on the lower protocols. </li></ul></ul><ul><ul><li>Intelligence is at the endpoints, not within the network (smart, network-aware endpoints and a dumb network) </li></ul></ul><ul><li>Achieving flexibility </li></ul><ul><ul><li>Provides a unifying framework for real-time audio/video transport, satisfying most application directly. </li></ul></ul>8 Fundamental design philosophies of RTP
  9. 9. RTP <ul><li>RTP specifications </li></ul><ul><li>RTP profiles </li></ul><ul><li>RTP payload formats </li></ul><ul><li>Optional elements </li></ul>8 Standard elements of RTP Framework
  10. 10. Introduction <ul><li>A session consists of an RTP/RTCP pair of channels, containing two closely linked parts: Data + Control. </li></ul><ul><ul><li>RTP to transport real-time data </li></ul></ul><ul><ul><li>RTCP: RTP control protocol </li></ul></ul><ul><ul><ul><li>QoS monitoring and feedback </li></ul></ul></ul><ul><ul><ul><li>Session control </li></ul></ul></ul><ul><li>Protocol architecture: usually works over UDP/IP </li></ul>RTP Outline 8 Media Application RTP IP RTCP UDP
  11. 11. Introduction RTP Outline 8
  12. 12. Introduction <ul><li>RTP Issues: The protocol itself does not </li></ul><ul><ul><li>provide mechanisms to ensure timely delivery </li></ul></ul><ul><ul><ul><li>Relies on lower-layer protocols </li></ul></ul></ul><ul><ul><li>prevent out-of-order delivery of packets </li></ul></ul><ul><ul><li>give any Quality of Service (QoS) Guarantee. </li></ul></ul><ul><li>RTP Timestamp (TS) and Sequence Number (SN) </li></ul><ul><ul><li>TS is used to order packets in correct timing order </li></ul></ul><ul><ul><li>SN detect packet loss </li></ul></ul>RTP Outline 8
  13. 13. RTP <ul><li>Multicasting </li></ul><ul><li>Payload type identification </li></ul><ul><li>Time stamping </li></ul><ul><ul><li>Enable timing recovery </li></ul></ul><ul><li>Sequencing </li></ul><ul><ul><li>Loss detection </li></ul></ul><ul><li>Delivery monitoring </li></ul>8 RTP Features
  14. 14. RTP <ul><li>Version (V): </li></ul><ul><li>Padding (P) </li></ul><ul><li>Extension (X) </li></ul><ul><li>CSRC Count (CC) </li></ul><ul><li>Marker (M) </li></ul>8 RTP Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=2 | P | X | CC | M | PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | (0~15 items).... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header extension (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (real time data) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <ul><li>Payload Type (PT) </li></ul><ul><li>Sequence Number </li></ul><ul><li>Timestamp </li></ul><ul><li>Synchronization Source (SSRC) </li></ul><ul><li>Contributing Source (CSRC) </li></ul>Padding size (8 bits) Padding (size X 8 bits)
  15. 15. RTP 8 RTP header <ul><li>Version (V, 2 bits): indicate the version of the protocol (Current version is 2) </li></ul><ul><li>Padding (P, 1 bit): if set, last byte of payload is padding size </li></ul><ul><li>Extension (X, 1 bit): if set, variable-size header extension exists </li></ul><ul><li>CSRC Count (CC, 4 bit): number of SCRC identifiers </li></ul><ul><li>Marker (M, 1 bit): defined in profile, mark significant event </li></ul><ul><li>Payload type (7 bits): audio/video encoding scheme </li></ul><ul><li>Sequence number: random initial value, increase by one for each RTP packet; for loss detection and sequence restoration </li></ul><ul><li>SSRC: identify source; chosen randomly and locally; collision needs to be resolved </li></ul><ul><li>CSRC list: identifiers of contributing sources, inserted by mixer </li></ul>
  16. 16. RTP 8 RTP header: SSRC and CSRC <ul><li>All packets from a given synchronizing source (with a given SSRC identifier) will use the same timing and sequence number space to allow receivers to recreate the packet sequence </li></ul><ul><li>A mixer receives RTP packets from multiple sources, combines packets, makes timing adjustments, and forwards new RTP packets with a new timing sequence </li></ul><ul><ul><li>All packets in the new sequence will have mixer SSRC as their synchronization source </li></ul></ul><ul><ul><li>The mixer inserts in each RTP packet header a CSRC list of the sources that contributed to this combined stream </li></ul></ul>
  17. 17. RTP 8 RTP header: Timestamp <ul><li>Reflects sampling instance of the first byte in payload </li></ul><ul><li>Clock frequency depends on data type; specified in profile </li></ul><ul><li>Random initial value </li></ul><ul><li>Example: CBR audio, clock increment by 1 for each sample </li></ul><ul><li>Consecutive RTP packets may have same timestamp (logically generate at same instant): video packets that belong to the same frame </li></ul><ul><li>Timestamps of consecutive RTP packets may not increase monotonically if the data is not transmitted in the order in which it was sampled: MPEG interpolated video frames </li></ul>
  18. 18. RTP 8 RTP header: Payload types <ul><li>Some examples (RFC 1890) </li></ul>90000 AV MP2T (MPEG- II transport stream) 33 90000 V MPV (MPEG-I and MPEG II) 32 90000 V JPEG 26 8000 A PCMA (A-law G.711) 8 8000 A PCMU (mu-law G.711) 0 Clock rate Audio/Video (A/V) Encoding name Payload type
  19. 19. RTP <ul><li>RTP implementation is expected to be integrated into the application rather than as a separate module. </li></ul><ul><li>The use of RTP for a particular application requires other documents </li></ul><ul><ul><li>Profile specification documents defines sets of payload type codes, and their mapping to payload formats </li></ul></ul><ul><ul><li>Payload format specification documents define how to carry a specific encoding </li></ul></ul><ul><ul><ul><li>Example: MPEG2 video or ADPCM audio </li></ul></ul></ul><ul><ul><ul><li>RFC 1890: payload types; RFC 2250: MPEG </li></ul></ul></ul>RTP-based networking application 8
  20. 20. RTP 8 RTP-based networking application <ul><li>RTP is part of the application and lies above the UDP socket </li></ul>Application RTP Socket UDP IP Data Link Physical
  21. 21. RTP 8 RTP-based networking application <ul><li>RTP can be viewed as a sub-layer of the transport layer </li></ul>Application RTP UDP IP Data Link Physical Transport
  22. 22. RTCP 8 Introduction – RTP Control Protocol <ul><li>Scenario </li></ul><ul><ul><li>Receivers send reports </li></ul></ul><ul><ul><li>Report contains number of packets lost at receiver, inter-arrival jitter, etc. </li></ul></ul><ul><ul><li>This allows senders to adjust date rate </li></ul></ul><ul><ul><li>Jitter is an early indicator of congestion </li></ul></ul><ul><ul><li>Senders also send reports </li></ul></ul>
  23. 23. RTCP 8 Introduction - Goals <ul><li>The control protocol, RTCP, provides for periodic reporting of reception quality, participant identification and other source description information, notification on changes in session membership, and the information needed synchronize media streams. </li></ul>RTCP QoS feedback Canonical Name Identify and keep track of participant Minimal session control information
  24. 24. RTCP 8 Packet Types Bye: End of session APP: Application specifics SDES: Source Description RR: Receive report SR: Sender report RTCP packet types
  25. 25. RTCP 8 Compound RTCP Packet
  26. 26. RTCP 8 Compound RTCP Packet
  27. 27. RTCP 8 Sender report (SR) <ul><li>SSRC: identifies source of data </li></ul><ul><li>Sender information blocks: </li></ul><ul><ul><li>NTP timestamp: absolute time identifying when report was sent </li></ul></ul><ul><ul><li>RTP timestamp: time when packet is sent according to the clock used to send RTP data packet timestamps; used for synchronization </li></ul></ul><ul><ul><li>Sender’s packet count: Total number of packets sent since the start of session </li></ul></ul><ul><ul><li>Sender’s octet count: Total number of bytes sent since the start of session </li></ul></ul><ul><li>Multiple receiver report blocks, one for each source from which this host receives packets </li></ul>
  28. 28. RTCP 8 Receiver report (RR) <ul><li>SSRC: identifies source whose data this block is about (who’s being reported on) </li></ul><ul><li>Loss fraction: fraction of packets lost since last report was sent </li></ul><ul><li>Cumulative number of packets lost: long-term loss since the beginning of reception </li></ul><ul><li>Highest sequence number received: compare losses, disconnect </li></ul><ul><li>Interarrival jitter: smoothed interpacket distortion </li></ul><ul><li>LSR: The NTP timestamp of the last sender report received from the source </li></ul><ul><li>DLSR: Delay between receiving the last SR from this source and sending this RR </li></ul>
  29. 29. RTCP 8 Round-trip delay estimation
  30. 30. RTCP 8 Intermedia synchronization
  31. 31. RTCP 8 SDES Packet Type <ul><li>Source description (SDES): provide participant identification and supplementary details, such as location, emai address, etc. </li></ul><ul><li>The standard items are: CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE, and PRIV. </li></ul><ul><ul><li>Constant for a user, unique among all users </li></ul></ul><ul><ul><li>Providing binding across multiple medias sent by a user </li></ul></ul><ul><ul><li>Example: user@postech.ac.kr </li></ul></ul>
  32. 32. RTCP 8 Analyzing sender and receiver reports <ul><li>Sender may modify its transmissions based on the feedback </li></ul><ul><li>Receivers can determine whether problems are local, regional or global </li></ul><ul><li>Network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance od their networks for multicast distribution. </li></ul>
  33. 33. RTP/RTCP 8 Other issues <ul><li>Collision detection and resolution </li></ul><ul><ul><li>Two sources use the same SSRC </li></ul></ul><ul><li>Loop detection </li></ul><ul><li>Security </li></ul><ul><li>Header compression – RFC 2508 </li></ul>
  34. 34. RTP/RTCP 8 Applications using RTP SIP, RTP ,Proprietary P2P protocol video, voicemail, phone in, phone out, multiparty calling, conference recording, text messaging, NAT traversal, video mail SightSpeed SIP (using TLS) and RTP (media) Video, file transfer, PC to phone, phone to PC Yahoo! Messenger SIP, RTP Video, voice, chat, text messaging, PC to Phone Windows Live Messenger SIP, STUN, RTP Address Book Integration, Daylite CRM Integration, Call Recording, IM, Conferencing, Mulitple Providers, Simple Setup, Call transfer, 5 lines iSoftPhone SIP, RTP Video, file transfer, PC to phone, phone to PC AOL instance messenger Protocols Capability Program
  35. 35. RTP/RTCP 8 Questions <ul><ul><li>감사합니다 & Question? </li></ul></ul>