1 / 83

Transporting Multimedia Data in the Internet

Transporting Multimedia Data in the Internet. Dr. Dorgham Sisalem Tekelec sisalem@iptel.org. IP Based Multimedia Communication. Audio/Video samples are digitized, compressed and sent in IP packets Compression schemes use limitations of human ears/eyes to reduce bandwidth

selina
Download Presentation

Transporting Multimedia Data in the Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Transporting Multimedia Data in the Internet Dr. Dorgham Sisalem Tekelec sisalem@iptel.org

  2. IP Based Multimedia Communication • Audio/Video samples are digitized, compressed and sent in IP packets • Compression schemes use limitations of human ears/eyes to reduce bandwidth • Reduce audio bandwidth using silence suppression • Reduce video bandwidth using motion detection • Media data needs to be transported from sender to receiver • Media data differ in their characteristics

  3. Media Exchange D/A A/D encoding decoding packetization FCFS Route lookup OS OS

  4. Example audio encoding techniques G.711 PCM (non-linear) 4KHz bandwidth 64Kb/s G.722 SB-ADPCM 48/56/64Kb/s 4-8KHz bandwidth G.728 LD-CELP 4KHz bandwidth 16Kb/s G.729 CS-ACELP 4KHz bandwidth 8Kb/s G.723.1 MP-MLQ 5.3/6.3Kb/s 4KHz bandwidth GSM RPE/LTP 4KHz 13Kb/s

  5. Example video encoding techniques MPEG1 Up to 1.5Mb/s MPEG2 Up to 10Mb/s (HDTV quality) MPEG4 5-64Kb/s (mobile, PSTN) 2Mb/s (TV quality) MPEG7, MPEG21 H.261 and H.263 n 64Kb/s, 1n 30

  6. Streaming Media sender • not interactive • Delay • Less stringent • loss • Stringent, (can be long for the first packet but should then not vary a lot) • Rate • Need a minimum but can vary (as long as the play out buffer does not become empty) • Data constantly generated and played out player

  7. Video/Audio Communication sender • person-to-person • interactive • Delay • Stringent (should be small and constant) • Loss • Could be tolerated (depending on the situation and language) • Rate • Need a minimum and should not vary a lot • Data constantly generated and played out • Except for silence suppression player

  8. What are transport protocols needed for? • Addressing: application to application addressing • Reliable delivery (if needed) the receiver application should receive the same datastream the source puts on the net • Segment order maintenance: data segments should reach the applicationin the same order they left the sender • Flow control: the data sending speed should adapt itself to the receiversspeed • Congestion control: the transmission speed can not be faster than thespeed of the slowest link traversed on the connections path • Segmentation: data is sent in segments that provide the highest throughout. • Media transport protocols should further inform the receiver about the content of the data

  9. Application Addressing • IP addresses enable us to get from one device to another • Port numbers allow us to address one process at a device 195.33.33.33 192.22.22.22 77777 88888 80

  10. Internet Transport Protocols • We will focus on the two main Internet transport protocols: UDP and TCP. • Transmission Control Protocol (TCP) • Connection oriented protocol intended to provide a reliable end-to-end byte stream over an unreliable network. • User Datagram Protocol (UDP) • Connectionless protocol that provides an unreliable end-to-end datagram service.

  11. Transport Control Protocol

  12. TCP (RFC 793) • TCP is connection oriented and full duplex. • Reliabilityachieved using acknowledgments, round trip delay estimations and data retransmission. • TCP uses a variable window mechanism for flow control. • Congestion control and avoidance is realized using slow start and congestion avoidance schemes. • Specified in RFC 793; corrections and finer details in Host Requirement RFCs 1122 and 1123. • Used for FTP, HTTP, mail

  13. IP encapsulation of TCP segments IP datagram TCP segment IP header TCP header TCP data 20 bytes 20 bytes

  14. TCP header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  15. TCP connection Establishment SYN 141 (0)win 100, <mss 1024> SYN 181 (0) win 100, <mss 1024> ACK 142 ACK 182 • Connection establishment is done with a three way handshake client server

  16. TCP Data Exchange 142 144 ACK 143 ACK 143 client server 143 • Gaps in the sequence numbers indicate losses to the receiver • Missing or repeated acknowledgements indicate loss to the sender

  17. Normal TCP connection termination • 4 segments are needed to terminate a TCP connection • Each end must be shut down independently. • Either end can send a FIN when is it done. • The other end ACK’s the FIN. application CLOSE FIN deliver EOF to application ACK of FIN application CLOSE FIN ACK of FIN

  18. Flow Control in TCP • TCP uses a sliding window mechanism to adjust the senders transmission speed to that of the receiver. • The sliding window specifies the amount of data the sender is allowed to transmit without receiving additional ACKs. • ACK segments contain the last correctly received byte and the number of bytes the receiver is still willing to accept.

  19. Window Flow Control RTT 1 2 W data 1 2 W • Rate= (W packets x packet size) / RTT 1 2 W Source time ACKs Destination 1 2 W time

  20. TCP Congestion Control • To avoid congestion in advance, the sender must adapt its transmission window to the available link bandwidth. • On connection establishment TCP uses a window of the size of 1 MSS as Congestion Window, cwnd. • Increase the window size till some loss is noticed • Decrease the window after a loss and start increasing again • Slow Start: the congestion window is increased by 1 MSS for each acknowledged segment (exponential increase of cwnd). • The receiver also announces how much buffer it still has for the connection (advertised window) • At any time the sender has a transmission window of min (advertised window, congestion window)

  21. Slow Start sender receiver cwnd 1 data packet 1 RTT ACK 2 3 4 5 6 7 8 cwnd  cwnd + 1 (for each ACK)

  22. Congestion Avoidance sender receiver cwnd 1 data packet ACK 2 1 RTT 3 4 cwnd  cwnd + 1 (for each cwnd ACKS)

  23. Congestion Avoidance • ssthresh = ½ of window before loss • Slow start upto ssthresh • Starts when cwnd  ssthresh • Set at beginning of communication to a large value • Updated after a loss • On each successful ACK: cwnd  cwnd + 1/cwnd • Linear growth of cwnd each RTT: cwnd  cwnd + 1

  24. TCP Tahoe (Jacobson 1988) window time CA SS SS: Slow Start CA: Congestion Avoidance

  25. TCP over Wireless • In fixed networks losses are considered as congestion indication • In wireless networks losses might occur due to the characteristics of the physical link • Reacting to losses in a similar manner as in fixed netwroks is thus wasteful • Solutions: • Use a new TCP • Use mechanisms for distinguishing between congestion and wireless losses

  26. User Datagram Protocol

  27. UDP (RFC 768) • UDP is a simple, datagram-oriented protocol. • Each output operation by a process produces exactly one UDP datagram, which causes one IP datagram to be sent. IP datagram UDP datagram IP header UDP header UDP data 20 bytes 8 bytes

  28. UDP header • port numbers: used to identify the sending and the receiving process. • UDP and TCP modules demultiplex incoming data from IP. • UDP port numbers are looked at only by UDP. 16-bit source port number 16-bit destination port number 16-bit UDP length 16-bit UDP checksum data (if any)

  29. When should I use UDP? • UDP is not reliable!! • The amount of data to be transmitted is small. • The overhead of creating connections and ensuring reliable delivery may be more work than re-transmitting the entire data set. • Signaling protocols • Applications that fit a “query-response” model. • The response can be used as a positive acknowledgement to the query. • Messaging • The application provides its own reliable data delivery mechanism. • When minimizing overhead is more important than reliability. • e.g. video or speech transmission • You can even turn off UDP checksum

  30. UDP vs. TCP Traffic Characteristics packet/s packet/s Receiver Sender p p time time window window SS SS time time CA CA SS: Slow Start CA: Congestion Avoidance SS: Slow Start CA: Congestion Avoidance loss time

  31. Real Time Transport Protocol Based on slides by Vincent Roca

  32. Real Time Transport Protocol (RTP) • Why another transport protocol? • media content type • talk spurts • sender identification • timing • intra-media synchronization: remove jitter with playout buffers • inter-media synchronization: lip-synch between audio-video • loss detection • segmentation and reassembly • security (encryption)

  33. RTP: Functions Media content IP UDP RTP • Standardized by the IETF and used by ITU-T as well • Designed to be scalable, flexible and separate data and control mechanisms

  34. RTP: Header V P X M Ct Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  35. RTP: Header RTP version V V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  36. RTP: Header Padding for encryption P CC Payload V P X M Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  37. RTP: Header Extension bit Allows adding experimental headers X V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  38. RTP: Header Marker bit Usage depends on codec and media (end of frame for example) V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  39. RTP: Header Contributers Count Number of sources contributing to this packet Added by mixers and ranges from 0 to 15 V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  40. RTP: Header Audio/Video encoding method V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  41. RTP: Header Number of packet incresed by one for each new packet Sequence number V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  42. RTP: Header Different fixed value for each compression type (160 for 20 ms at 8000 Hz) V P X M CC Payload Sequence number Timestamp Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  43. RTP: Header A random number identifying the source (unique per source) chosen randomly  detect and solve collisions V P X M Payload Sequence number Timestamp Synchronization source identifier (SSRC) Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  44. RTP: Header V P X M Payload Sequence number Timestamp Identify the contributing sources to this packet (added by mixers) Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

  45. Time management Two times… • RTP time • Random initial offset (for each stream) • RTP timestamp present in each data packet • Describes the sampling instant of the payoad • Increases by 160 for packets carrying 20ms worth of samples (160) • NTP time (or wallclock time) • Absolute time (use Network Time Protocol format) • NTP timestamp present in each RTCP Sender Report • Relates RTP time to actual time • Enables inter-stream synchronization

  46. Real time Transport Control Protocol (RTCP) • Separate packets sent on a different port number • Packets sent in intervals determined based on number of end systems and available bandwidth • several functions • feedback on the quality of data distribution • let everybody evaluate the number of participants • persistant transport-level canonical name for a source, CNAME • usually: user@host • will not change, even if SSRC does! • provides binding across multiple media tools for a single user

  47. RTCP generalities • Five RTCP packets • SR sender reports tx and rx statistics from active senders • RR receiver reports rx statistics from other participants, or from active senders if more than 31 sources • SDES source description, including CNAME • BYE explicit leave • APP application specific extensions

  48. RTCP generalities… (cont’) • distribution • use same distribution mechanisms as data packets (nm multicast) • multiple RTCP packets can be concatenated by translators/mixers  compound RTCP packet • scalability with session size • RTCP traffic should not exceed 5% of total session bandwidth requires an evaluation of number of participants RTCP tx interval = f(number of participants) • at least 25% of RTCP bandwidth is for source reports let new receivers quickly know CNAME of sources!

  49. SR RTCP packets • includes • SSRC of sender identify source of data • NTP timestamp when report was sent • RTP timestamp corresponding RTP time • packet count total number sent • octet count total number sent • followed by zero or more receiver report…

  50. RR RTCP packets • includes • SSRC of source identify the source to which this RR block pertains • fraction lost since previous RR (SR) sent (= int(256*lost/expected)) • cumul # of packets lost long term loss • highest seq # received compare losses • interarrival jitter smoothed interpacket distortion • LSR time when last SR heard • DLSR delay since last SR

More Related