Top Banner
REAL-TIME TRANSPORT PROTOCOL SUBMITTED BY: TAPAN KUMAR IT-B , ROLL.NO-27
19
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 1. REAL-TIME TRANSPORT PROTOCOL SUBMITTED BY: TAPAN KUMAR IT-B , ROLL.NO-27

2. CONTENT: INTRODUCTION LIMITATION OF TCP PROTOCOL STRUCTURE RTP SESSION SYNCHRONISATION DATA TRANSMISSION RTP PACKETS MIXER AND TRANSLATOR CONCLUSION 3. HISTORY: 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. INTRODUCTION: provide end to end delivery service for data with real time characteristics such as audio and video, The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over IP NETWORK. RTP is used extensively in communication and entertainment systems that involve streaming media such as telephony, video teleconference applications, television services and web-based push to talk features. RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. RTP is originated and received on even port number and the associated RTCP communication uses the next higher odd port number. 4. LIMITATION OFTCP: TCP is not used because- TCP does retransmissions unbounded delays No provision for time stampings(slow and noisy walks) TCP does not support multicast TCP congestion control (slow-start) unsuitable for real- time transport 5. PROTOCOLSTRUCTURE: Application layer protocol Typically used on top of IP and UDP Applications that use RTP are: Less sensitive to packet loss Very sensitive to packet delays UDP provides key services: Multiplexing Checksum 6. CONTINUED. Traditional transport services such as: addressing, segmentation/reassembly, quality-of-service, and delivery semantics are all provided by a lower level protocol. 7. RTPSESSION: RTP session is sending and receiving of RTP data by a group of participants For each participant, a session is a pair of transport addresses used to communicate with the group If multiple media types are communicated by the group, the transmission of each medium constitutes a session. 8. RTP Synchronization Source: synchronization source - each source of RTP PDUs Identified by a unique, randomly chosen 32-bit ID (the SSRC) A host generating multiple streams within a single RTP must use a different SSRC per stream 9. RTPBasics of Data Transmission: basic RTP message consists of Synchronization source identifier of sender Sequence number Timestamp Payload 10. RTP PDU Header: Version (V): Padding (P) Extension (X) CSRC Count (CC) Marker (M) Payload Type (PT) Sequence Number Timestamp Synchronization Source (SSRC) Contributing Source (CSRC) 11. Version (V, 2 bits): indicate the version of the protocol (Current version is 2) Padding (P, 1 bit): if set, last byte of payload is padding size Extension (X, 1 bit): if set, variable-size header extension exists CSRC Count (CC, 4 bit): number of CSRC identifiers Marker (M, 1 bit): defined in profile, mark significant event Payload type (7 bits): audio/video encoding scheme Sequence number: random initial value, increase by one for each RTP packet; for loss detection and sequence restoration SSRC: identify source; chosen randomly and locally; collision needs to be resolved CSRC list: identifiers of contributing sources, inserted by mixer 12. Translator : An intermediate system that Connects two or more networks Multicasting through a firewall Modifies stream encoding, changing the streams timing Transparent to participants SSRCs remain intact end system 1 end system 2 transl.1 from ES1: SSRC=6 from ES2: SSRC=23 transl.2 from ES2: SSRC=23 from ES1: SSRC=6 authorized tunnel firewall from ES2: SSRC=23 from ES1: SSRC=6 13. Mixer: Stream may be transcoded, special effects may be performed. A mixer will typically have to define synchronization relationships between streams.Thus Sources that are mixed together become contributing sources (CSRC) Mixer itself appears as a new source having a new SSRC RTP mixer - an intermediate system that receives & combines RTP PDUs of one or more RTP sessions into a new RTP PDU 14. RTPControl Protocol (RTCP) : RTCP specifies report PDUs exchanged between sources and destinations of multimedia information receiver reception report sender report source description report Reports contain statistics such as the number of RTP- PDUs sent, number of RTP-PDUs lost, inter-arrival jitter Used by application to modify sender transmission rates and for diagnostics purposes 15. CONCLUSION: Today, as the Real-time Transport Protocol (RTP) is used more and more widely in the streaming media services such as real time video in the internet. RTP provides powerful instruments for adaptive video transmission. Potential applications include wireless links. Optimization can be done within the frames of the protocol specification (loosely defined packet sizes and RTCP communication frequency). Finally, the experiments are carried out to illustrate that the algorithm can enhance the stabilization of RTP flow, decrease the jitter, and utilize network bandwidth efficiently. 16. APPLICATION OF RTP TO DECODE LIVE MUSIC: 17. REFERENCES: 1. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: a transport protocol for real-time applications. RFC 1889, January 1996. 2. H. Schulzrinne, About RTP and the audio-video transport working group, http://www.cs.columbia.edu/~hgs/rtp/. 3. B. A. Forouzan, TCP/IP Protocol Suite ,Third edition. 4. H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: a transport protool for real-time applications", RFC 3550, July 2003. 5. H. Schulzrinne, A. Rao and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998 6. D. Wu, Y.T. Hou, Y.-Q. Zhang, Transporting real-time video over the Internet: challenge and approaches, Proc. IEEE 88 (12) (December 2000) 119. 18. THANK YOU !!!!!!!!!!