Telematics 2 & Performance Evaluation

Transcription

1 Telematics 2 & Performance Evaluation Chapter 1 Multimedia 1 Multimedia, Quality of Service: What is it? Multimedia applications: network audio and video ( continuous media ) QoS Network provides application with level of performance needed for application to function. 2

2 Multimedia Application Class Typically sensitive to delay, but can tolerate packet loss (would cause minor glitches that can be concealed) Antithesis of classical data applications, which are loss intolerant but delay tolerant! Multimedia data contains audio and video content ( continuous media ), three classes of applications: Streaming Unidirectional Real-Time Interactive Real-Time Each class may be broadcast, multicast or simply unicast 3 Application Classes (more) Streaming Clients reuest audio/video files from servers and pipeline reception over the network and display Interactive: user can control operation (similar to VCR: pause, resume, fast forward, rewind, etc.) Delay: from client reuest until display start typically 1 to 10 seconds Unidirectional Real-Time: Similar to existing TV and radio stations, but delivery on the network Non-interactive, just listen/view Interactive Real-Time : Phone conversation, video conference or games More stringent delay reuirement than streaming Unidirectional because of real-time nature Video: < 150 ms acceptable Audio: < 150 ms good, < 400 ms acceptable 4

3 Streaming Stored Multimedia Streaming: Media stored at source Transmitted to client Streaming: client playout begins before all data has arrived Timing constraint for still-to-be transmitted data: in time for playout 5 Streaming Stored Multimedia: What is it? 1. video recorded 2. video sent network delay 3. video received, played out at client time Streaming: at this time, client playing out early part of video, while server still sending later part of video 6

4 Streaming Stored Multimedia: Interactivity VCR-like functionality: Client can pause, rewind, FF, push slider bar 10 sec initial delay OK 1-2 sec until command effect OK Bandwidth adaptation: Clients may automatically reuest higher or lower uality content Timing constraint for still-to-be transmitted data: in time for playout 7 Streaming Live Multimedia Examples Internet radio talk show Live sporting event Streaming Playback buffer Playback may lag tens of seconds after transmission Still have timing constraint Interactivity Fast forward impossible Rewind, pause possible! 8

5 Interactive, Real-Time Multimedia Applications: IP telephony, video conference, computer games Anybody remembering Second Life? End-end delay reuirements: Audio: < 150 ms good, < 400 ms OK Includes application-level (encoding & packetization) and network delays Higher delays noticeable, impair interactivity Session initialization How does callee advertise its IP address, port number, encoding algorithms? 9 Multimedia Over Today s Internet TCP/UDP/IP: best-effort service No guarantees on delay & loss?????? But you said multimedia apps reuires QoS and level of performance to be effective!????? Today s Internet multimedia applications use (mostly) application-level techniues to mitigate (as best possible) effects of delay & loss 10

6 Challenges TCP/UDP/IP suite: Provides best-effort No guarantees on expectation or variance of packet delay Streaming applications delay of 5 to 10 seconds is typical and has been acceptable, but performance deteriorate if links are congested (transoceanic, ISP backbones at rush hour ) Real-Time Interactive reuirements on delay and its jitter have been satisfied by: Over-provisioning (= providing plenty of bandwidth), or Unfair use of bandwidth What will happen when the load increases? Challenges (more) Most router implementations use only First-Come-First-Serve (FCFS) packet processing and transmission scheduling Net neutrality Pre-configured setting Missing business models To mitigate impact of best-effort protocols, end-users can: Use UDP to avoid TCP s rate control Buffer content at client and control playback to remedy jitter Adapt compression level to available bandwidth 12

7 Different Solution Approaches in IP Networks Just add more bandwidth and enhance caching capabilities (overprovisioning)! Use of content delivering networks (CDNs) most popular approach Change of the protocols: Incorporate resource reservation (bandwidth, processing, buffering), and new scheduling policies Set up service level agreements with applications, monitor and enforce the agreements, charge accordingly Make changes in ueueing policy (i.e., not just best-effort FIFO) Better strategies like RED well-known but hard to parameterize Not well adapted Current trend: use of deep packet inspection to find & priorize interesting flows 13 Multimedia terminology Multimedia session: a session that contains several media types e.g., a movie containing both audio & video Continuous-media session: a session whose information must be transmitted continually e.g., audio, video, but not text (unless ticker-tape) Streaming: application usage of data during its transmission Playback pt Data stream Rcv pt In transmission or to be transmitted 14

8 Streaming Important and growing application due to reduction of storage costs, increase in high speed net access from homes, enhancements to caching and introduction of QoS in IP networks Audio/Video file is segmented and sent over either TCP or UDP, public segmentation protocol: Real-Time Protocol (RTP) Today: Mostly usage of Dynamic Adaptive Streaming over HTTP (DASH) and similar 15 Multimedia vs. Raw Data Multimedia e.g., Audio/Video Tolerates some packet loss Packets have timed playout reuirements Raw Data e.g., web pages, SSH Lost packets must be recovered Timing: faster delivery always preferred Why not just always use TCP for multimedia traffic? Often do not need the high level of reliability Rate might slow down too much 16

9 A Few Words About Audio Compression Analog signal sampled at constant rate Telephone: 8,000 samples/sec CD music: 44,100 samples/sec Each sample uantized, i.e., rounded E.g., 2 8 =256 possible uantized values Each uantized value represented by bits 8 bits for 256 values Example: 8,000 samples/sec, 256 uantized values 64,000 bps Receiver converts it back to analog signal: Some uality reduction Example rates CD: Mbps FLAC: ~50% less MP3, M4A: 128, 160, 192 kbps Internet telephony: kbps 17 A Few Words About Video Compression Video is seuence of images displayed at constant rate E.g. 24 images/s Digital image is array of pixels Each pixel represented by bits Redundancy Spatial Temporal Examples: MPEG 1 (CD-ROM) 1.5 Mbps MPEG 2 (DVD) 3-6 Mbps MPEG 4 (often used in Internet, < 1 Mbps) HDTV/4K up to 25 MBit/s Research: Layered (scalable) video Adapt layers to available bandwidth State of the art: Ad-hoc switching between different streams 18

10 Multimedia Transmission Challenges and Solutions Jitter Buffering, time-stamps Packet loss Loss-tolerant apps Interleaving Retransmission (ARQ) or Packet-Level Forward Error Correction (FEC) Single-rate Multicast Destination Set Splitting Layering 19 Jitter The Internet makes no guarantees about time of delivery of a packet Consider an IP telephony session: Speaker Hi There, What s up?? Listener Hi The re, Wha t s up? Time 20

11 Jitter (cont d) A packet pair s jitter is the difference between the transmission time gap and the receive time gap Sender: Pkt i Pkt i+1 Receiver: Pkt i Pkt i+1 S i S i+1 jitter R i R i+1 Time Desired time-gap: S i+1 - S i Received time-gap: R i+1 - R i Jitter between packets i and i+1: (R i+1 - R i ) - (S i+1 - S i ) 21 Buffering: A Remedy to Jitter Delay playout of received packet i until time S i + C (C is some constant) How to choose value for C? Bigger jitter need bigger C Small C: more likely that R i > S i + C «missed deadline Big C: reuires more packets to be buffered increased delay prior to playout Application timing reuirements might limit C: Interactive apps (IP telephony) cannot impose large playout delays (e.g., the international call effect) non-interactive: more tolerant of delays, but still not infinite... 22

12 Real-Time (Phone) Over IP s Best-Effort Internet phone applications generate packets during talk spurts Bit rate is 8 KB/s, and every 20 ms, the sender forms a packet of 160 Bytes + a header to be discussed below The coded voice information is encapsulated into a UDP packet and sent out Some packets may be lost; up to 20% loss ok depending on codec Using TCP eliminates loss but at a considerable cost: high variance in delay; FEC (Forward Error Correction) is sometimes used to fix errors and make up losses 23 Real-Time (Phone) Over IP s Best-Effort End-to-end delays above 400ms cannot be tolerated Packets that are delayed too long: ignored at the receiver ITU recommends end-to-end delays up to 150ms Delay jitter is handled by using timestamps, seuence numbers, and delaying playout at receivers either a fixed or a variable amount With fixed playout delay, the delay should be as small as possible without missing too many packets; delay cannot exceed 400ms 24

13 Internet Telephony with Fixed Playout Delay packets packets generated loss packets received playout schedule p' - r playout schedule p - r time r p p' 25 Adaptive Playout For some applications, the playout delay need not be fixed e.g., [Ramjee 1994] / p. 430 in Kurose-Ross Speech has talk-spurts w/ large periods of silence Can make small variations in length of silence periods w/o user noticing Can re-adjust playout delay in between spurts to current network conditions 26

14 Adaptive Playout Delay Objective is to use a value for p r that tracks the network delay performance as it varies during a phone call The playout delay is computed for each talk spurt based on observed average delay and observed deviation from this average delay Estimated average delay and deviation of average delay are computed in a manner similar to estimates of RTT and deviation in TCP The beginning of a talk spurt is identified from examining the timestamps in successive and/or seuence numbers of chunks 27 Packet Loss / Recovery Problem: Internet might lose / excessively delay packets making them unusable for the session arrival time: Pkt i Pkt i+1 Pkt i+3 app deadline: i i+1 i+2 i+3 usage status:, i used, i+1 late, i+2 lost, i+3 used,... Solution step 1: Design app to tolerate some loss Solution step 2: Design techniues to recover some lost packets within application s time limits 28

15 Applications that tolerate some loss Techniues are medium-specific and influence the coding strategy used (beyond scope of course) Video: e.g., MPEG Audio: e.g., GSM, G.729, G.723, replacing missing pkts w/ white-noise, etc. Note: loss tolerance is a secondary issue in multimedia coding design Primary issue: compression 29 Reducing loss w/in time bounds Problem: packets must be recovered prior to application deadline Solution 1: extend deadline, rcvr, use ARQ (Automatic Repeat Reuest: i.e., ACKs & NAKs) Recall: unacceptable for many apps (e.g., interactive) Solution 2: Forward Error Correction (FEC) (Technically: we are using Erasure Codes, not FEC codes) Send repair before a loss is reported Simplest FEC: transmit redundant copies Sender: Pkt i Pkt i Pkt i+1 Pkt i+1 Pkt i+2 Pkt i+2 Receiver: Pkt i Pkt i+1 Pkt i+1 duplicate i+2 lost 30

16 More advanced FEC techniues FEC often used at the bit-level to repair corrupt/missing bits (i.e., in the data-link layer) header data FEC bits Here, we will consider using FEC (really Erasure Codes) at the packet layer (special repair packets): Data 1 Data 2 Data 3 FEC 1 FEC 2 31 A Simple XOR code For low packet loss rates (e.g. 5%), sending duplicates is expensive (wastes bandwidth) XOR code XOR a group of data pkts together to produce repair pkt Transmit data + XOR: can recover 1 lost pkt Å Å Å Å Å Å

17 Reed-Solomon Codes Based on simple linear algebra can solve for n unknowns with n euations each data pkt represents a value Sender and receiver know which euation is in which pkt (i.e., information in header) Rcvr can reconstruct n data pkts from any set of n data + repair pkts In other words, send n data pkts + k repair packets, then if no more than any k pkts are lost, then all data can be recovered In practice To reduce computation, linear algebra is performed over fields that differ from the usual, i.e. Galois field arithmetic 33 Reed Solomon Example over Pkt 1: Pkt 2: Pkt 3: Data1 Data2 Data3 Original data Pkt 4: Data1 + Data2 + 2 Data3 Pkt 5: 2 Data1 + Data2 + 3 Data3 Specific linear combinations Pkts 1, 2, 3 are data (Data1, Data2, and Data3) Pkts 4, 5 are linear combinations of data Assume 1-5 transmitted, pkts 1 & 3 are lost: Data1 = (2 * Pkt 5-3 * Pkt 4 + Pkt 2) Data2 = Pkt 2 Data3 = (2 * Pkt 4 - Pkt 5 - Pkt 2) 34

18 Using FEC for continuous-media Sender: Data 1 block i D2 blk i D3 blk i FEC 1 blk i F2 blk i D1 blk i+1... D1 Receiver: blk i Receiver App: D3 blk i F1 blk i Decoder F2 blk i D1 blk i D1 blk i+1 D2 D3 blk i blk i Time when Block i needed Divide data pkts into blocks by app Send FEC repair pkts after corresponding data block Rcvr decodes and supplies data to app before block i deadline 35 FEC via variable encodings Media-specific approach Packet contents: high uality version of media frame k low uality version of media frame k c (c is a constant) If packet i containing high uality frame k is lost, then can use packet i + c with low uality frame k in place i low: k-c high: k i+1 low: k-c+1 high: k+1 i+2 low: k-c+2 high: k+2 36

19 FEC tradeoff FEC reduces channel efficiency: Available bandwidth: B Fraction of packets that are FEC: f Max data-rate (barring packet loss): B (1 f) Need to be careful how much FEC is used!!! 37 Bursty Loss Many codecs can recover from short (1 or 2 packet) loss outages Bursty loss (loss of many pkts in a row) creates long outages: uality deterioration more noticeable FEC provides less benefit in a bursty loss scenario (e.g., consider 30% loss in bursts 3 packets long) D1:i D2:i D3:i F1:i F2:i D1:i+1 D2:i+1 D3:i+1 F1:i+1 F2:i+1 Too much FEC Too little FEC 38

20 Interleaving To reduce effects of burstiness, reorder packet transmissions Sender schedule D1 D4 D7 D2 D5 D8 D3 D6 Arrival schedule D1 D4 D8 D3 D6 D1 D3 D4 D6 D8 Playback schedule D1 D2 D3 D4 D5 D6 D7 D8 Drawback: induces buffering and playout delay 39 Multimedia Internet Protocols We ll look at 4: RTP/RTCP: transport layer RTSP: session layer for streaming media applications SIP: session initiation protocol (alternative to H.323) H.323: session layer for conferencing applications TCP RTSP H.323 UDP RTP/RTCP TCP UDP/multicast 40

21 RTP/RTCP [RFC 3550 by Schulzrinne et al] General purpose Real-Time Multimedia protocol Scalable to large sessions (many senders, receivers) Session data sent via RTP (Real-time Transfer Protocol) RTP components / support: seuence # and timestamps uniue source/session ID (SSRC or CSRC) encryption payload type info (codec) Receiver/Sender session status transmitted via RTCP (Real-time Transfer Control Protocol) last seuence # rcvd from various senders observed loss rates from various senders observed jitter info from various senders member information (canonical name, , etc.) control algorithm (limits RTCP transmission rate) 41 RTP/RTCP details All of a session s RTP/RTCP packets are sent to the same multicast group (by all participants) All RTP pkts sent to some even-numbered port, 2p All RTCP pkts sent to port 2p+1 Only data senders send RTP packets All participants (senders/rcvrs) send RTCP packets 42

22 RTP runs on top of UDP RTP libraries provide a transport-layer interface that extend UDP: port numbers, IP addresses payload type identification packet seuence numbering time-stamping 43 Real-Time Protocol (RTP) Provides standard packet format for real-time application Specifies header fields below Payload Type: 7 bits, providing 128 possible different types of encoding; e.g.: Payload type 0: PCM mu-law, 64 kbps Payload type 3, GSM, 13 kbps Payload type 7, LPC, 2.4 kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 video etc. (or dynamic) Seuence Number: 16 bits; used to detect packet loss 44

23 Real-Time Protocol (RTP) Timestamp: 32 bytes; gives the sampling instant of the first audio/video byte in the packet; used to remove jitter introduced by the network For audio, timestamp clock typically increments by one for each sampling period (for example, each 125 usecs for a 8 KHz sampling clock) If application generates chunks of 160 encoded samples, then timestamp increases by 160 for each RTP packet when source is active. Timestamp clock continues to increase at constant rate when source is inactive. Synchronization Source identifier (SSRC): 32 bits; an id for the source of a stream; assigned randomly by the source; each stream in a RTP session should have a distinct SSRC 45 RTP header Why do most (all) multimedia apps reuire seuence #? timestamp? (uniue) Sync Source ID? Why should every packet carry the 7-bit payload type? Why not just when sender initiates session? (Hint: ever showed up late to a movie?) Transmission rate: application specific (no congestion control specified in RTP) 46

24 RTP Example Consider sending 64 kbps PCM-encoded voice over RTP. Application collects the encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunk. The audio chunk along with the RTP header form the RTP packet, which is encapsulated into a UDP segment. RTP header indicates type of audio encoding in each packet sender can change encoding during a conference. RTP header also contains seuence numbers and timestamps. 47 RTP and QoS RTP does not provide any mechanism to ensure timely delivery of data or provide other uality of service guarantees. RTP encapsulation is only seen at the end systems: it is not seen by intermediate routers. Routers providing best-effort service do not make any special effort to ensure that RTP packets arrive at the destination in a timely matter. 48

25 Session Initiation Protocol (SIP) SIP long-term vision All telephone calls and video conference calls take place over the Internet People are identified by names or addresses, rather than by phone numbers. You can reach the callee, no matter where the callee roams, no matter what IP device the callee is currently using. SIP has been defined by the IETF 49 SIP Services Setting up a call Provides mechanisms for caller to let callee know she wants to establish a call Provides mechanisms so that caller and callee can agree on media type and encoding. Provides mechanisms to end call. Determine current IP address of callee. Maps mnemonic identifier to current IP address Call management Add new media streams during call Change encoding during call Invite others Transfer and hold calls 50

26 Setting Up a Call to a Known IP Address Alice time INVITE bob@ c=in IP m=audio RTP/AVP 0 port 5060 port 5060 port OK c=in IP m=audio RTP/AVP 3 GSM ACK port 5060 µ Law audio port time Bob Bob's terminal rings Alice s SIP invite message indicates her port number & IP address. Indicates encoding that Alice prefers to receive (PCM ulaw) Bob s 200 OK message indicates his port number, IP address & preferred encoding (GSM) SIP messages can be sent over TCP or UDP; here sent over RTP/UDP. Default SIP port number is Setting Up a Call (more) Codec negotiation: Suppose Bob doesn t have PCM ulaw encoder. Bob will instead reply with 606 Not Acceptable Reply and list encoders he can use. Alice can then send a new INVITE message, advertising an appropriate encoder. Rejecting the call Bob can reject with replies busy, gone, payment reuired, forbidden. Media can be sent over RTP or some other protocol. 52

27 Example of SIP Message INVITE SIP/2.0 Via: SIP/2.0/UDP From: To: Call-ID: Content-Type: application/sdp Content-Length: 885 c=in IP m=audio RTP/AVP 0 Notes: HTTP message syntax sdp = session description protocol Call-ID is uniue for every call. Here we don t know Bob s IP address. Intermediate SIP servers will be necessary. Alice sends and receives SIP messages using the SIP default port number 5060 Alice specifies in Via: header that SIP client sends and receives SIP messages over UDP 53 Name Translation And User Location Caller wants to call callee, but only has callee s name or address. Need to get IP address of callee s current host, as: User moves around DHCP protocol User has different IP devices (PC, PDA, car device) Result can be based on: Time of day (work, home) Caller (don t want boss to call you at home) Status of callee (calls sent to voic when callee is already talking to someone) Service provided by SIP servers: SIP registrar server SIP proxy server 54

28 SIP Registrar When Bob starts SIP client, client sends SIP REGISTER message to Bob s registrar server (similar function needed by Instant Messaging) Register Message: REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP From: sip:bob@domain.com To: sip:bob@domain.com Expires: SIP Proxy Alice send s invite message to her proxy server Contains address sip:bob@domain.com Proxy responsible for routing SIP messages to callee Possibly through multiple proxies Often called session border controller (SBC) when also proxying data stream Callee sends response back through the same set of proxies. Proxy returns SIP response message to Alice Contains Bob s IP address Note: proxy hierarchies somewhat similar DNS servers 56

29 Example Caller places a call to keith@upenn.edu (1) Jim sends INVITE message to umass SIP proxy. (2) Proxy forwards reuest to upenn registrar server. (3) upenn server returns redirect response, indicating that it should try keith@eurecom.fr SIP proxy umass.edu 1 8 SIP client SIP registrar upenn.edu SIP registrar eurecom.fr SIP client (4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrar forwards INVITE to , which is running keith s SIP client. (6-8) SIP response sent back (9) media sent directly between clients. Note: also a SIP ack message, which is not shown Comparison with H.323 H.323 is another signaling protocol for real-time, interactive applications H.323 is a complete, vertically integrated suite of protocols for multimedia conferencing: Signaling Registration Admission control Transport Codecs. SIP is a single component. Works with RTP, but does not mandate it. Can be combined with other protocols and services. H.323 comes from the ITU (telephony) SIP comes from IETF: Borrows much of its protocol concepts from HTTP. SIP has a web flavor, whereas H.323 has a telephony flavor SIP uses the KISS principle : Keep it simple stupid 58

30 H.323 A standard for real-time audio / video teleconferencing on the Internet Network Components: End points: end-host H.323-compliant application Gateways: interface between H.323-compliant communication and prior technology (e.g. phone network) Gatekeepers: provide services at gateway (e.g., address translation, billing, authorization, etc.) Audio Apps Video Apps Gateway System Control G.711 G.722 G.729 etc. H.261 H.263 etc. RTP / RTCP RAS Channel H.225 Call Signaling Channel Q.931 Call Control Channel H.245 H.323 UDP TCP 59 H.323 cont d H.225: notifies gatekeepers of session initiation Q.931: signaling protocol for establishing and terminating calls H.245: out-of-band protocol negotiates the audio/video codecs used during a session (TCP) G.711 G.722 G.729 etc. H.261 H.263 etc. RTP / RTCP RAS Channel H.225 Call Signaling Channel Q.931 Call Control Channel H.245 H

31 Voice-over-IP: Skype proprietary application-layer protocol (inferred via reverse engineering) encrypted msgs P2P components: clients: skype peers connect directly to each other for VoIP call super nodes (SN): skype peers with special functions overlay network: among SNs to locate SCs login server Skype login server Skype clients (SC) supernode (SN) supernode overlay network 61 P2P voice-over-ip: skype Skype client operation: 1. joins skype network by contacting SN (IP address cached) using TCP 2. logs-in (username, password) to centralized skype login server 3. obtains IP address for callee from SN, SN overlay or client buddy list 4. initiate call directly to callee Skype login server 62

32 Skype: peers as relays problem: both Alice, Bob are behind NATs NAT prevents outside peer from initiating connection to insider peer inside peer can initiate connection to outside relay solution: Alice, Bob maintain open connection to their SNs Alice signals her SN to connect to Bob Alice s SN connects to Bob s SN Bob s SN connects to Bob over open connection Bob initially initiated to his SN 63 Streaming From Web Servers Audio: in files sent as HTTP objects Video (interleaved audio and images in one file, or two separate files and client synchronizes the display) sent as HTTP object(s) A simple architecture is to have the Browser reuests the object(s) and after their reception pass them to the player for display Media Application: displays content, typically browser plug-in; e.g. Adobe Flash, Silverlight; typical functions: Decompression Jitter removal Error correction / loss recovery GUI for user control (DRM!) 64

33 Streaming From Web Server (more) Alternative: set up connection between server and player, then download Web browser reuests and receives a Meta File (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 65 Meta file reuests 66

34 Using a Streaming Server This gets us around HTTP, allows a choice of UDP vs. TCP and the application layer protocol can be better tailored to streaming; many enhancements options are possible (see next slides) 67 Streaming Multimedia: UDP or TCP? UDP Server sends at rate appropriate for client (oblivious to network congestion!) Often send rate = encoding rate = constant rate Then, fill rate = constant rate - packet loss Short playout delay (2-5 seconds) to compensate for network delay jitter Error recovery: time permitting TCP Send at maximum possible rate under TCP Fill rate fluctuates due to TCP congestion control Larger playout delay: smooth TCP delivery rate HTTP/TCP passes more easily through firewalls Available from most CDNs 68

35 Streaming Multimedia: Client Rate(s) 1.5 Mbps encoding 28.8 Kbps encoding Q: How to handle different client receive rate capabilities? 28.8 Kbps dialup 100Mbps Ethernet A: Server stores, transmits multiple copies of video, encoded at different rates 69 Real Time Streaming Protocol (RTSP) 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 7826 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 70

36 Meta File Example <title>twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="pcmu/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session> 71 RTSP Operation HTTP protocol RTSP protocol 72

37 RTSP Exchange Example C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=play S: RTSP/ OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: OK 73 Streaming multimedia: DASH DASH: Dynamic, Adaptive Streaming over HTTP server: divides video file into multiple chunks each chunk stored, encoded at different rates manifest file: provides URLs for different chunks client: periodically measures server-to-client bandwidth consulting manifest, reuests one chunk at a time chooses maximum coding rate sustainable given current bandwidth can choose different coding rates at different points in time (depending on available bandwidth at time) 74

38 Streaming multimedia: DASH intelligence at client: client determines when to reuest chunk (so that buffer starvation, or overflow does not occur) what encoding rate to reuest (higher uality when more bandwidth available) where to reuest chunk (can reuest from URL server that is close to client or has high available bandwidth) No other protocol needed Allows for usage of content distribution networks! CDNs take control of where! 75 Chapter Summary Multimedia applications and reuirements Audio, video, streaming Delay, jitter, packet loss Making the best of today s best effort service: Client side buffering Multiple encodings (choose stream with lower rate) Common Internet protocols for multimedia applications: RTP SIP H.323 Skype RTSP DASH 76

39 Open Issues Some applications do not work well on top of the IP best-effort model: Cannot control loss rates Cannot control packet delay No way to protect other sessions from demanding bandwidth reuirements Problem Different applications have so many different kinds of service reuirements: File transfer: rate-adaptive, but too slow is annoying Uncompressed audio: low delay, low loss, constant rate MPEG video: low delay, low loss, high variable rate Distributed gaming: low delay, low variable rate Can one Internet service model satisfy all app s reuirements? Apparently not, so let us see in next chapter... 77