Published on

  • 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
  • One can consider webpages as media as well!
  • One way delays
  • Define the 4 terms… TCP/UDP/IP suite (internet networking) provides best-effort delivery -- No guarantees about end-to-end delay -- No guarantees about variance of packet delay within stream Because of lack of special effort to deliver packets in timely manner, multimedia hard!
  • Phone with delay? On the Internet and in other networks, Quality of Service (QoS) is the idea that transmission rates, error rates, and other characteristics can be measured, improved, and, to some extent, guaranteed in advance. Schemes in which certain packets are given higher priority
  • -- Variable bitrate media (where number of packets for “unit” of media varies) makes this relationship hard to model -- possible question here.
  • Scalable encoding will be discussed a little later (built into encoding schemes)
  • Pulse Code Modulation: PCM: 8000 x 8 = 64 Kb/s PCM (CD): 44100 x 16 = 715.6 Kb/s (mono) x 2 (stereo)
  • Add animation/block diagrams t
  • MPEG-1: MPEG-1 was the original MPEG standard, designed exclusively for computer use. It allows a 320x240, 30 frame per second video. MPEG-2: MPEG-2 is a higher-resolution version of MPEG-1 designed for digital television broadcast. MPEG-3: MPEG-3 was designed for HDTV. However, HDTV is just normal TV with a higher resolution and frame rate, so this standard was folded into MPEG-2 and is no longer used. MPEG-4: MPEG-4 is a new standard for digital video scheduled for release in November 1998. It is designed for use over low-bit-rate wireless and mobile communication systems. DCT cannot provide the required compression to operate over this type of line, so MPEG-4 does not enforce an encoding method. Instead, it leaves the choice of encoding method up to the designer. MPEG-7: MPEG-7 is yet another standard for digital video that has barely begun. The focus of MPEG-7 is supposed to be designing a representation for digital video that allows it to be stored and queried by content in a video database.
  • Streaming often requested thru web client (browser) Audio/video not tightly integrated with broswer, so helper applications needed (media player)
  • Audio/video break up… Take simple case. A simple architecture is to have the Browser requests the object(s) and after their reception pass them to the player for display - No pipelining
  • Web browser requests and receives a Meta File ___more details___ HERE (a file describing the object) instead of receiving the file itself; Browser launches the appropriate Player and passes it the Meta File; Player sets up a TCP connection with Web Server and downloads the file -- TCP bad…. Delays… -- HTTP bad… No control (Not rich enough)
  • 2 servers: HTTP (meta data), streaming (media)
  • Use UDP, and Server sends at a rate (Compression and Transmission) appropriate for client; to reduce jitter, Player buffers initially for 2-5 seconds, then starts display Use TCP, and sender sends at maximum possible rate under TCP; retransmit when error is encountered; Player uses a much large buffer to smooth delivery rate of TCP -- Chance of starvation with small buffer
  • For user to control display: rewind, fast forward, pause, resume, etc… Out-of-band protocol (uses two connections, one for control messages (Port 554) and for media stream) RFC 2326 permits use of either TCP or UDP for the control messages connection, sometimes called the RTSP Channel As before, meta file is communicated to web browser which then launches the Player; Player sets up an RTSP connection for control messages in addition to the connection for the streaming media
  • Bit rate is 8 KBytes, and every 20 msec, the sender forms a packet of 160 Bytes + a header to be discussed below Ideal case, this just works, but…. (next slide)
  • Loss is in a broader sense: packet never arrives or arrives later than its scheduled playout time
  • With fixed playout delay, the delay should be as small as possible without missing too many packets
  • The playout delay is computed for each talk spurt based on observed average delay and observed deviation from this average delay The beginning of a talk spurt is identified from examining the timestamps in successive and/or sequence numbers of chunks U can ask a couple of questions here: what are disadvantages; where did we use avg. delay estimation etc. before?
  • Mixed quality streams are used to include redundant duplicates of chunks Upon loss playout available redundant chunk (a lower quality one) Can recover from single losses
  • Has no redundancy, but can cause delay in playout beyond Real Time requirements… why does it work?
  • Thin protocol As is, doesn’t specify everything you need Serves as a skeleton that can be filled out
  • Framing, that is identifying and handling a unit of transfer suitable to the application level, (ALF principle). Multiplexing, in case we want to put different media within the same stream. Real-time delivery, possibly sacrificing reliability for timeliness. (but does not in itself provide this) Synchronization, both within successive packets in a stream and between different media in different streams. Feedback, on who is receiving data with what quality
  • Multiple streams can be differentiated. Can tell if packet dropped.
  • Control session associated with each RTP session. Control session has same participants as RTP session. Provides feedback on quality of data stream. Carries information to associate multiple streams as coming from the same participant. Scalable way of estimating group size. Synchronization mechanism across streams from same participant.
  • If each receiver sends RTCP packets to all other receivers, the traffic load resulting can be large RTCP adjusts the interval between reports based on the number of participating receivers Typically, limit the RTCP bandwidth to 5% of the session bandwidth, divided between the sender reports (25%) and the receivers reports (75%)
  • 441-mmedia.ppt

    1. 1. Multimedia Networking Ashwin Bharambe Carnegie Mellon University 15-441 Networking, Spring 2003 Tuesday, April 22, 2003
    2. 2. What media are we talking about? Audio and/or Video This lecture concerned about:
    3. 3. Lecture Overview <ul><li>Multimedia Applications </li></ul><ul><li>Application Requirements / Challenges </li></ul><ul><li>Media Encodings </li></ul><ul><li>Case Studies </li></ul><ul><ul><li>Streaming Stored Media </li></ul></ul><ul><ul><li>Real Time Interactive Media (Voice over IP) </li></ul></ul><ul><li>Protocols </li></ul><ul><ul><li>Real-Time Transport Protocol (RTP) </li></ul></ul><ul><ul><li>Real-Time Transport Control Protocol (RTCP) </li></ul></ul>
    4. 4. Application Classes <ul><li>Streaming Stored Media </li></ul><ul><ul><li>Pipeline reception of stored files over the network </li></ul></ul><ul><ul><li>No need to wait for entire file before viewing </li></ul></ul><ul><ul><li>Example: On-demand video </li></ul></ul><ul><li>Unidirectional Real-Time Media </li></ul><ul><ul><li>Similar, but data is generated on the fly </li></ul></ul><ul><ul><li>Non-interactive: just listen/view, no fast-forward! </li></ul></ul><ul><ul><li>Example: news broadcast </li></ul></ul><ul><li>Interactive Real-Time Media </li></ul><ul><ul><li>Example: video conference </li></ul></ul>
    5. 5. Streaming Media Applications <ul><li>Characteristics </li></ul><ul><ul><li>Interactive: Users can play, pause </li></ul></ul><ul><ul><li>Even rewind/fast-forward </li></ul></ul><ul><li>Requirements </li></ul><ul><ul><li>Delay: from client request until display start can be 1 to 10 seconds </li></ul></ul><ul><ul><li>Time is used to buffer data to reduce chance of stalling </li></ul></ul><ul><ul><li>Delay constraints on data delivery to maintain continuous playout. </li></ul></ul>On demand Video
    6. 6. Unidirectional Real-Time Apps <ul><li>Characteristics </li></ul><ul><ul><li>By storing media: can pause, rewind </li></ul></ul><ul><ul><li>Often used combined with multicast </li></ul></ul><ul><li>Requirements </li></ul><ul><ul><li>As with streaming media, delay constraints on data delivery to maintain continuous playout </li></ul></ul>News Broadcast
    7. 7. Real-Time Interactive Applications <ul><li>Requirements </li></ul><ul><ul><li>Very stringent delay requirements because of real-time interactive nature </li></ul></ul><ul><ul><li>Limit to how much people are willing to adapt to the delay </li></ul></ul><ul><ul><li>Video: < 150 msec acceptable (one-way) </li></ul></ul><ul><ul><li>Audio: < 150 msec not perceived, < 400 msec acceptable (one-way) </li></ul></ul>Internet Telephony
    8. 8. Roadmap <ul><li>Multimedia Applications </li></ul><ul><li>Application Requirements / Challenges </li></ul><ul><li>Media Encodings </li></ul><ul><li>Case Studies </li></ul><ul><ul><li>Streaming Stored Media </li></ul></ul><ul><ul><li>Real Time Interactive Media (Voice over IP) </li></ul></ul><ul><li>Protocols </li></ul><ul><ul><li>Real Time Protocol (RTP) </li></ul></ul><ul><ul><li>Real Time Control Protocol (RTCP) </li></ul></ul>
    9. 9. Review: Network Basics Source Dest Throughput = Amount of data arriving per unit time. Jitter = Variance of interpacket arrival times Interpacket Arrival Time Delay Loss Best-effort delivery!!
    10. 10. End-to-End Delay <ul><li>Interactive applications </li></ul><ul><ul><li>Video conferencing </li></ul></ul><ul><ul><ul><li>Human communication starts to break down at ~500 msec delays </li></ul></ul></ul><ul><ul><li>Feedback loops </li></ul></ul><ul><ul><li>Delay affected by encoding/decoding </li></ul></ul><ul><li>Today’s Internet </li></ul><ul><ul><li>Best effort service and end-to-end mechanisms </li></ul></ul><ul><ul><li>Provide little opportunity for controlling delay </li></ul></ul><ul><li>Longer term (only?) solution: Quality of Service </li></ul>
    11. 11. Packet Jitter <ul><li>Real-Time systems must deal with this </li></ul><ul><ul><li>Jitter is hard to bound even with QoS </li></ul></ul><ul><li>Partial solution: Buffer management </li></ul><ul><ul><li>Buffers are used to smooth jitter, but how big should the buffer be? </li></ul></ul><ul><ul><li>Unexpected jitter can lead to starvation or buffer overflow if buffer is too small </li></ul></ul><ul><ul><li>But over-provisioning buffers increases delay </li></ul></ul>
    12. 12. Throughput <ul><li>Estimating throughput is problematic </li></ul><ul><ul><li>Media coding may be tunable, but changes in quality are generally perceptually annoying </li></ul></ul><ul><ul><li>Throughput will often vary faster than feedback delay which makes estimation hard </li></ul></ul><ul><li>Multicast makes this worse </li></ul><ul><li>Possible Solutions: </li></ul><ul><ul><li>QoS mechanisms </li></ul></ul><ul><ul><li>Scalable encoding combined with congestion control (i.e., dynamically adapt compression to bandwidth) </li></ul></ul>
    13. 13. Packet Loss <ul><li>Effect of loss is media and encoding specific </li></ul><ul><ul><li>Loss of one packet in a video stream may result in the loss of multiple frames </li></ul></ul><ul><ul><li>Other packets received can be rendered useless </li></ul></ul><ul><ul><li>Retransmission often not feasible (no time) </li></ul></ul><ul><li>Possible Solutions: </li></ul><ul><ul><li>Encoding that alleviates packet loss effects </li></ul></ul><ul><ul><li>Forward Error Correction (FEC) </li></ul></ul>
    14. 14. Roadmap <ul><li>Multimedia Applications </li></ul><ul><li>Application Requirements / Challenges </li></ul><ul><li>Media Encodings </li></ul><ul><li>Case Studies </li></ul><ul><ul><li>Streaming Stored Media </li></ul></ul><ul><ul><li>Real Time Interactive Media (Voice over IP) </li></ul></ul><ul><li>Protocols </li></ul><ul><ul><li>Real Time Protocol (RTP) </li></ul></ul><ul><ul><li>Real Time Control Protocol (RTCP) </li></ul></ul>
    15. 15. Media Encoding <ul><li>Digitization essential, of course! </li></ul><ul><li>Sample signal at some frequency </li></ul><ul><ul><li>8KHz, for example </li></ul></ul><ul><li>Quantize </li></ul><ul><ul><li>represent each sample as some fixed #bits </li></ul></ul><ul><li>Compress: make number of bits small </li></ul><ul><ul><li>Audio: GSM, G.729, G.723.3, MP3, … </li></ul></ul><ul><ul><li>Video: MPEG 1/2/4, H.261, … </li></ul></ul><ul><li>Then: </li></ul><ul><ul><li>Send -> Receive, decompress/convert, play </li></ul></ul>
    16. 16. Audio Encoding <ul><li>Traditional telephone quality encoding </li></ul><ul><ul><li>8KHz samples of 8 bits each  64kbps </li></ul></ul><ul><li>CD quality encoding: 44.1 KHz of 16 bits </li></ul><ul><ul><li>1.41 Mbs uncompressed </li></ul></ul><ul><li>MP3 compression </li></ul><ul><ul><li>Frequency ranges that are divided in blocks, which are converted using DCT, quantized, and encoded </li></ul></ul>12 128 kbps Layer 3 8 192 kbps Layer 2 4 384 kbps Layer 1 Ratio Range
    17. 17. Image Encoding: JPEG <ul><li>Divide digitized image in 8 x 8 pixel blocks </li></ul><ul><li>The DCT phase converts the pixel block into a block of frequency coefficients </li></ul><ul><ul><li>Discrete Cosine Transform – similar to FFT </li></ul></ul><ul><li>The quantization phase limits the precision of the frequency coefficient </li></ul><ul><ul><li>This is based on a quantization table, which controls the degree of compression </li></ul></ul><ul><li>The encoding phase packs this information in a dense fashion </li></ul>
    18. 18. Video Encoding <ul><li>Once frames are captured (&quot;raw&quot; video) resulting file is very large: </li></ul><ul><ul><li>320 x 240 x 24 -bit color = 230,400 bytes/frame </li></ul></ul><ul><ul><li>15 frames/second = 3,456,000 bytes/second </li></ul></ul><ul><ul><li>10 seconds takes around 30 Mbytes! (no audio) </li></ul></ul><ul><li>Commonly-used encodings: AVI, MPEG </li></ul><ul><ul><li>Exploit spatial locality inside a single image </li></ul></ul><ul><ul><li>Temporal locality across images </li></ul></ul><ul><ul><li>Layered encoding </li></ul></ul>
    19. 19. MPEG Encoding of Video <ul><li>Three frame types: </li></ul><ul><ul><li>I frame: independent encoding of the frame (JPEG) </li></ul></ul><ul><ul><li>P frame: encodes difference relative to I-frame (predicted) </li></ul></ul><ul><ul><li>B frame: encodes difference relative to interpolated frame </li></ul></ul><ul><ul><li>Note that frames will have different sizes </li></ul></ul><ul><li>Complex encoding, e.g. motion of pixel blocks, scene changes, .. </li></ul><ul><ul><li>Decoding is easier than encoding. </li></ul></ul><ul><li>MPEG often uses fixed-rate encoding. </li></ul>I B B P B B P B B I B B P B B
    20. 20. MPEG System Streams <ul><li>Combine one more MPEG video and audio streams in a single synchronized stream. </li></ul><ul><li>Consists of a hierarchy with meta data at every level describing the data. </li></ul><ul><ul><li>System level contains synchronization information </li></ul></ul><ul><ul><li>Video level is organized as a stream of group of pictures </li></ul></ul><ul><ul><li>Group of pictures consists of pictures </li></ul></ul><ul><ul><li>Pictures are organized in slices </li></ul></ul><ul><ul><li>… </li></ul></ul>
    21. 21. Roadmap <ul><li>Multimedia Applications </li></ul><ul><li>Application Requirements / Challenges </li></ul><ul><li>Media Encodings </li></ul><ul><li>Case Studies </li></ul><ul><ul><li>Streaming Stored Media </li></ul></ul><ul><ul><li>Real Time Interactive Media (Voice over IP) </li></ul></ul><ul><li>Protocols </li></ul><ul><ul><li>Real Time Protocol (RTP) </li></ul></ul><ul><ul><li>Real Time Control Protocol (RTCP) </li></ul></ul>
    22. 22. Streaming Media Applications <ul><li>Important and growing </li></ul><ul><ul><li>Reduction of storage costs </li></ul></ul><ul><ul><li>High-speed access networks (e.g., DSL) </li></ul></ul><ul><ul><li>Enhancements to network caching of video using content distribution networks </li></ul></ul><ul><li>Operation </li></ul><ul><ul><li>Segment audio/video file; send over UDP/TCP </li></ul></ul><ul><ul><li>Real-Time Transport Protocol (RTP) </li></ul></ul><ul><li>User-Interactive Control </li></ul><ul><ul><li>Real-Time Transport Control Protocol (RTCP) </li></ul></ul>
    23. 23. Streaming Helper Application <ul><li>Displays content </li></ul><ul><ul><li>Typically requested via a Web browser </li></ul></ul><ul><ul><li>Example: RealPlayer </li></ul></ul><ul><li>Typical functions: </li></ul><ul><ul><li>GUI for user control </li></ul></ul><ul><ul><li>Decompression </li></ul></ul><ul><ul><li>Jitter removal </li></ul></ul><ul><ul><li>Error correction </li></ul></ul>
    24. 24. Streaming From Web Servers (1) <ul><li>Video sent as HTTP object(s) </li></ul><ul><li>Options: </li></ul><ul><ul><li>Interleaved audio and video in one file </li></ul></ul><ul><ul><li>Two separate files with client synchronizing the display </li></ul></ul>
    25. 25. Streaming From Web Servers (2) <ul><li>Alternative </li></ul><ul><ul><li>Set up connection between server and player, then download </li></ul></ul>
    26. 26. Using a Streaming Server <ul><li>Application layer protocol can be better tailored to streaming </li></ul><ul><ul><li>Gets us around HTTP, allows a choice of UDP vs. TCP </li></ul></ul>
    27. 27. Streaming Media Application Client Side Issues
    28. 28. Quick Question <ul><li>What protocol does RealPlayer or QuickTime use? </li></ul>
    29. 29. Tricky Question <ul><li>What protocol does RealPlayer or QuickTime use? </li></ul>
    30. 30. Real Time Streaming Protocol (RTSP) <ul><li>For user to control transmission of stream </li></ul><ul><ul><li>Display: rewind, fast forward, pause, resume, etc… </li></ul></ul><ul><ul><li>Think: remote control for your VCR </li></ul></ul><ul><li>Out-of-band protocol (Port 554) </li></ul><ul><li>RFC 2326 </li></ul>
    31. 31. RTSP at Work
    32. 32. Roadmap <ul><li>Multimedia Applications </li></ul><ul><li>Application Requirements / Challenges </li></ul><ul><li>Media Encodings </li></ul><ul><li>Case Studies </li></ul><ul><ul><li>Streaming Stored Media </li></ul></ul><ul><ul><li>Real Time Interactive Media (Voice over IP) </li></ul></ul><ul><li>Protocols </li></ul><ul><ul><li>Real Time Protocol (RTP) </li></ul></ul><ul><ul><li>Real Time Control Protocol (RTCP) </li></ul></ul>
    33. 33. Voice Over IP (VoIP) <ul><li>Internet phone applications generate packets during talk spurts </li></ul><ul><ul><li>No traffic during silence </li></ul></ul><ul><li>Operation </li></ul><ul><ul><li>Sample, quantize, encapsulate and send </li></ul></ul><ul><li>Protocol choices </li></ul><ul><ul><li>UDP: some packets may be lost (up to ~20% loss is tolerable) </li></ul></ul><ul><ul><li>TCP: eliminates loss but creates variance in delay </li></ul></ul><ul><ul><li>TCP slow start can also create periods of very small throughput </li></ul></ul>
    34. 34. Voice Over IP (VoIP): Issues <ul><li>Delay </li></ul><ul><ul><li>End-to-end delays > 400 msec cannot be tolerated </li></ul></ul><ul><ul><li>Packets that are that delayed are ignored (i.e., lost) </li></ul></ul><ul><li>Jitter </li></ul><ul><ul><li>Use timestamps, sequence numbers </li></ul></ul><ul><ul><li>Delay playout at receivers (fixed or adaptive) </li></ul></ul><ul><li>Packet loss </li></ul><ul><ul><li>Forward Error Correction (FEC) </li></ul></ul><ul><ul><li>Interleaving </li></ul></ul><ul><ul><li>Receiver-based repair </li></ul></ul>
    35. 35. Compensating for Jitter: VoIP with Fixed Playout Delay Playout delay
    36. 36. Compensating for Jitter: Adaptive Playout Delay <ul><li>Disadvantages of fixed playout delay </li></ul><ul><ul><li>More packet loss (delayed packets), if too small </li></ul></ul><ul><ul><li>High latency, if too large </li></ul></ul><ul><li>Solution: track network delay performance </li></ul><ul><ul><li>Estimate average delay and delay variance </li></ul></ul><ul><ul><li>Similar to RTT estimation in TCP </li></ul></ul><ul><li>Adjust playout delay during silent periods </li></ul><ul><ul><li>Silent periods get shortened/expanded </li></ul></ul><ul><ul><li>Hardly noticeable! </li></ul></ul>
    37. 37. Recovery from Packet Loss: Forward Error Correction (FEC) <ul><li>Send redundant encoded chunk every n chunks (XOR original n chunks) </li></ul><ul><ul><li>If 1 packet in this group lost, can reconstruct </li></ul></ul><ul><ul><li>If > 1 packet lost, cannot recover </li></ul></ul><ul><li>Disadvantages: </li></ul><ul><ul><li>The smaller the group size, larger the overhead </li></ul></ul><ul><ul><li>Playout delay increased </li></ul></ul>
    38. 38. Recovering from Packet Loss: Piggybacking Lo-fidelity Stream
    39. 39. Recovering from Packet Loss: Interleaving <ul><li>Divide 20 msec of audio data into smaller units of 5 msec each and interleave </li></ul><ul><li>Upon loss, have a set of partially filled chunks </li></ul>
    40. 40. Recovering from Packet Loss: Receiver-based Repair <ul><li>Exploit temporal similarity </li></ul><ul><ul><li>Replicate packets </li></ul></ul><ul><li>Smart solutions </li></ul><ul><ul><li>Interpolation </li></ul></ul>
    41. 41. Roadmap <ul><li>Multimedia Applications </li></ul><ul><li>Application Requirements / Challenges </li></ul><ul><li>Media Encodings </li></ul><ul><li>Case Studies </li></ul><ul><ul><li>Streaming Stored Media </li></ul></ul><ul><ul><li>Real Time Interactive Media (Voice over IP) </li></ul></ul><ul><li>Protocols </li></ul><ul><ul><li>Real Time Protocol (RTP) </li></ul></ul><ul><ul><li>Real Time Control Protocol (RTCP) </li></ul></ul>
    42. 42. Real Time Transport Protocol (RTP) <ul><li>Recall: </li></ul><ul><ul><li>Multimedia apps. append headers to audio/video chunks </li></ul></ul><ul><ul><li>Format, sequence numbers, timestamps, … </li></ul></ul><ul><li>RTP: public domain standard for such headers </li></ul><ul><ul><li>Chunks encapsulated in RTP packets before being sent to UDP </li></ul></ul><ul><ul><li>Real Time Control Protocol (RTCP) for control </li></ul></ul><ul><li>RTP logically extends UDP. </li></ul><ul><ul><li>Sits between UDP and application </li></ul></ul><ul><ul><li>Thin Protocol </li></ul></ul>
    43. 43. RTP: What does it do? <ul><li>Framing </li></ul><ul><li>Multiplexing </li></ul><ul><li>“ Real-time delivery” (sort’a) </li></ul><ul><li>Synchronization </li></ul><ul><li>Feedback </li></ul>
    44. 44. RTP Packet Format <ul><li>Source/Payload type </li></ul><ul><ul><li>Different formats assigned different codes </li></ul></ul><ul><ul><li>E.g., GSM -> 3 , MPEG Audio -> 14 </li></ul></ul><ul><li>Sequence numbers </li></ul><ul><li>Time stamps </li></ul><ul><li>Synchronization source ID </li></ul><ul><li>Miscellaneous fields </li></ul>
    45. 45. Timestamp vs. Sequence Number <ul><li>Timestamp relates packet to real time </li></ul><ul><ul><li>Timestamp values sampled from a media specific clock </li></ul></ul><ul><li>Sequence number relates packet to other packets </li></ul><ul><li>Allows many packets to have the same timestamp but different sequence numbers </li></ul>
    46. 46. Audio silence example <ul><li>Consider audio data: what do you want to do during silence? </li></ul><ul><ul><li>Not send anything </li></ul></ul><ul><li>Why might this cause problems? </li></ul><ul><ul><li>Other side needs to distinguish between loss and silence </li></ul></ul><ul><li>How does the timestamp/seq# mechanism help? </li></ul><ul><ul><li>Big jump in timestamps, but correct next sequence number  Silence! </li></ul></ul>
    47. 47. SSRC: Synchronization Source <ul><li>Identifies the stream </li></ul><ul><ul><li>Not just the participant </li></ul></ul><ul><ul><li>All packets with the same SSRC go together </li></ul></ul><ul><li>Picked at random </li></ul><ul><li>Why do we need this? </li></ul><ul><ul><li>No assumption of stream association from underlying network mechanism </li></ul></ul><ul><li>Possible problems? </li></ul><ul><ul><li>Collision </li></ul></ul>
    48. 48. Real Time Control Protocol (RTCP) <ul><li>RTCP packets transmitted by each participant in RTP session to all others using multicast </li></ul><ul><li>Distinct port number from RTP </li></ul><ul><li>Reports on: </li></ul><ul><ul><li>Loss rate </li></ul></ul><ul><ul><li>Inter-arrival jitter </li></ul></ul><ul><ul><li>Identity of receivers </li></ul></ul><ul><ul><li>Delay, (indirectly). </li></ul></ul>
    49. 49. Control Bandwidth Scaling <ul><li>Needed for scalability </li></ul><ul><ul><li>Consider one speaker and 2 receivers as compared to one speaker with 20 or 200 receivers </li></ul></ul><ul><li>Recommendation: </li></ul><ul><ul><li>5% of data bandwidth </li></ul></ul><ul><ul><li>Sending delay should be randomized </li></ul></ul><ul><ul><li>Should account for overhead of underlying network service (i.e., UDP and IP) </li></ul></ul>
    50. 50. Summary <ul><li>Supporting multimedia applications in today’s Internet is difficult </li></ul><ul><ul><li>Several tricks to alleviate problems posed by best-effort delivery </li></ul></ul><ul><ul><li>In future, perhaps bandwidth will be extremely plentiful everywhere </li></ul></ul><ul><ul><li>Or – we will need Quality of Service some day or the other! </li></ul></ul><ul><li>Bunch of Real-Time protocols standardizing some aspects of real-time communication </li></ul>