Chapter 5 VoIP. Computer Networking: A Top Down Approach. 6 th edition Jim Kurose, Keith Ross Addison-Wesley March Multmedia Networking

Transcription

1 Chapter 5 VoIP Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Multmedia Networking

2 audio signal amplitude Multimedia: audio analog audio signal sampled at constant rate telephone: 8,000 samples/sec CD music: 44,100 samples/sec each sample quantized, i.e., rounded e.g., 2 8 =256 possible quantized values each quantized value represented by bits, e.g., 8 bits for 256 values quantization error sampling rate (N sample/sec) quantized value of analog value analog signal time Multmedia Networking 7-2

3 audio signal amplitude Multimedia: audio example: 8,000 samples/sec, 256 quantized values: 64,000 bps receiver converts bits back to analog signal: some quality reduction quantization error quantized value of analog value analog signal example rates CD: Mbps MP3: 96, 128, 160 kbps Internet telephony: 5.3 kbps and up sampling rate (N sample/sec) time Multmedia Networking 7-3

4 Voice-over-IP Real-time conversational voice over the Internet is often referred to as Internet telephony. It is also commonly called Voice-over-IP (VoIP) Multmedia Networking 7-4

5 Limitation of the Best-Effort IP Service The Internet s network-layer protocol, IP, provides best-effort service. makes its best effort to move each datagram from source to destination as quickly as possible makes no promises whatsoever about getting the packet to the destination within some delay bound or about a limit on the percentage of packets lost. The lack of such guarantees poses significant challenges to the design of real-time conversational applications, which are acutely sensitive to packet delay, jitter, and loss. Multmedia Networking 7-5

6 VoIP example The sender generates bytes at a rate of 8,000 bytes per second; every 20 msecs the sender gathers these bytes into a chunk. A chunk and a special header encapsulated in a UDP segment, via a call to the socket interface. Thus, the number of bytes in a chunk is (20 msecs) (8,000 bytes/sec) = 160 bytes, and a UDP segment is sent every 20 msecs. If each packet makes it to the receiver with a constant end-to-end delay, then packets arrive at the receiver periodically every 20 msecs. Multmedia Networking 7-6

7 Voice-over-IP (VoIP) VoIP end-end-delay requirement: needed to maintain conversational aspect higher delays noticeable, impair interactivity < 150 msec: good > 400 msec bad includes application-level (packetization,playout), network delays session initialization: how does callee advertise IP address, port number, encoding algorithms? value-added services: call forwarding, screening, recording emergency services: 911 Multmedia Networking 7-7

8 VoIP characteristics speaker s audio: alternating talk spurts, silent periods. 64 kbps during talk spurt pkts generated only during talk spurts 20 msec chunks at 8 Kbytes/sec: 160 bytes of data application-layer header added to each chunk chunk+header encapsulated into UDP or TCP segment application sends segment into socket every 20 msec during talkspurt Multmedia Networking 7-8

9 VoIP: packet loss network loss: IP datagram lost due to network congestion (router buffer overflow) Loss could be eliminated by sending the packet over TCP. most existing VoIP applications run over UDP by default. UDP is used by Skype unless a user is behind a NAT or firewall that blocks UDP segments (in which case TCP is used) Multmedia Networking 7-9

10 Reason of using UDP retransmission mechanisms are often considered unacceptable for conversational real-time audio applications such as VoIP, because they increase end-to-end delay due to TCP congestion control, packet loss may result in a reduction of the TCP sender s transmission rate to a rate that is lower than the receiver s drain rate, possibly leading to buffer starvation. Multmedia Networking 7-10

11 VoIP: loss tolerance loss tolerance: depending on voice encoding, loss concealment, packet loss rates between 1% and 10% can be tolerated. for example: forward error correction (FEC) can help conceal packet loss. We ll see below that with FEC, redundant information is transmitted along with the original information so that some of the lost original data can be recovered from the redundant information. Nevertheless, if one or more of the links between sender and receiver is severely congested, and packet loss exceeds 10 to 20 percent (for example, on a wireless link), then there is really nothing that can be done to achieve acceptable audio quality. Clearly, best-effort service has its limitations.

12 VoIP: End-to-End Delay End-to-end delay is the accumulation of transmission, processing, and queuing delays in routers; propagation delays in links; and end-system processing delays. For example: VoIP, end-to-end delays smaller than 150 msecs are not perceived by a human listener; delays between 150 and 400 msecs can be acceptable but are not ideal; and delays exceeding 400 msecs can seriously hinder the interactivity in voice conversations. The receiving side of a VoIP application will typically disregard any packets that are delayed more than a certain threshold, for example, more than 400 msecs. Thus, packets that are delayed by more than the threshold are effectively lost.

13 VoIP: Packet Jitter A crucial component of end-to-end delay is the varying queuing delays that a packet experiences in the network s routers. Because of these varying delays, the time from when a packet is generated at the source until it is received at the receiver can fluctuate from packet to packet. This phenomenon is called jitter.

14 buffered data Delay jitter constant bit rate transmission variable network delay (jitter) client reception constant bit rate playout at client client playout delay time end-to-end delays of two consecutive packets: difference can be more or less than 20 msec (transmission time difference) Multmedia Networking 7-14

15 VoIP: Packet Jitter scenarios 1 Consider 2 consecutive packets in our VoIP application. The sender sends the second packet 20 msecs after sending the first packet. But at the receiver, the spacing between these packets can become greater than 20 msecs. To see this, suppose the first packet arrives at a nearly empty queue at a router, but just before the second packet arrives at the queue a large number of packets from other sources arrive at the same queue. Because the first packet experiences a small queuing delay and the second packet suffers a large queuing delay at this router, the first and second packets become spaced by more than 20 msecs. The spacing between consecutive packets can also become less than 20 msecs.

16 VoIP: Packet Jitter scenarios 2 Consider two consecutive packets. Suppose the first packet joins the end of a queue with a large number of packets, and the second packet arrives at the queue before this first packet is transmitted and before any packets from other sources arrive at the queue. In this case, our two packets find themselves one right after the other in the queue. If the time it takes to transmit a packet on the router s outbound link is less than 20 msecs, then the spacing between first and second packets becomes less than 20 msecs. Multmedia Networking 7-16

17 VoIP: fixed playout delay receiver attempts to playout each chunk exactly q msecs after chunk was generated. chunk has time stamp t: play out chunk at t+q chunk arrives after t+q: data arrives too late for playout: data lost tradeoff in choosing q: large q: less packet loss small q: better interactive experience Multmedia Networking 7-17

18 Removing Jitter at the Receiver for Audio For VoIP application, where packets are being generated periodically, the receiver should attempt to provide periodic playout of voice chunks in the presence of random network jitter. This is typically done by combining the following two mechanisms: 1. Prepending each chunk with a timestamp. 2. Delaying playout of chunks at the receiver Multmedia Networking 7-18

19 1. Prepending each chunk with a timestamp The sender stamps each chunk with the time at which the chunk was generated. Multmedia Networking 7-19

20 2. Delaying playout of chunks at the receiver. the playout delay of the received audio chunks must be long enough so that most of the packets are received before their scheduled playout times. This playout delay can either be fixed throughout the duration of the audio session or vary adaptively during the audio session lifetime. Multmedia Networking 7-20

21 VoIP: fixed playout delay the receiver attempts to play out each chunk exactly q msecs after the chunk is generated. So if a chunk is timestamped at the sender at time t, the receiver plays out the chunk at time t + q, assuming the chunk has arrived by that time. Packets that arrive after their scheduled playout times are discarded and considered lost. Multmedia Networking 5-21

22 VoIP: q choice VoIP can support delays up to about 400 msecs, although a more satisfying conversational experience is achieved with smaller values of q. if q is made much smaller than 400 msecs, then many packets may miss their scheduled playback times due to the network-induced packet jitter. if large variations in end-to-end delay are typical, it is preferable to use a large q; on the other hand, if delay is small and variations in delay are also small, it is preferable to use a small q, perhaps less than 150 msecs. Multmedia Networking

23 VoIP: fixed playout delay sender generates packets every 20 msec during talk spurt. first packet received at time r first playout schedule: begins at p second playout schedule: begins at p packets packets generated packets received loss playout schedule p' - r playout schedule p - r time r p p' Multmedia Networking 5-23

24 Issue of fixed playout delay By making the initial playout delay large, most packets will make their deadlines and there will therefore be negligible loss; however, for conversational services such as VoIP, long delays can become bothersome if not intolerable. Ideally, we would like the playout delay to be minimized subject to the constraint that the loss be below a few percent.

25 Adaptive playout delay (1) The natural way to deal with this trade-off is to estimate the network delay and the variance of the network delay, and to adjust the playout delay accordingly at the beginning of each talk spurt. This adaptive adjustment of playout delays at the beginning of the talk spurts will cause the sender s silent periods to be compressed and elongated; however, compression and elongation of silence by a small amount is not noticeable in speech. Multmedia Networking

26 Adaptive playout delay (1) goal: low playout delay, low late loss rate approach: adaptive playout delay adjustment: estimate network delay, adjust playout delay at beginning of each talk spurt silent periods compressed and elongated chunks still played out every 20 msec during talk spurt adaptively estimate packet delay: (EWMA - exponentially weighted moving average, recall TCP RTT estimate): d i = (1-a)d i-1 + a (r i t i ) delay estimate after ith packet small constant, e.g. 0.1 time received - time sent (timestamp) measured delay of ith packet Multmedia Networking 7-26

27 Adaptive playout delay (1) let: ti = the timestamp of the ith packet = the time the packet was generated by the sender ri = the time packet i is received by receiver pi = the time packet i is played at receiver The end-to-end network delay of the ith packet is ti. Due to ri network jitter, this delay will vary from packet to packet. Let di denote an estimate of the average network delay upon reception of the ith packet. adaptively estimate packet delay: (EWMA - exponentially weighted moving average, recall TCP RTT estimate): d i = (1-u)d i-1 + u (r i t i ) delay estimate after ith packet small constant, e.g. 0.1 time received - time sent (timestamp) measured delay of ith packet

28 Adaptive playout delay (1) Let di denote an estimate of the average network delay upon reception of the ith packet. This estimate is constructed from the timestamps as follows: d i = (1-u)d i-1 + u (r i t i ) delay estimate after ith packet small constant, e.g. 0.1 time received - time sent (timestamp) measured delay of ith packet where u is a fixed constant (for example, u = 0.01). Thus di is a smoothed average of the observed network delays r1 t1,..., ri ti. The estimate places more weight on the recently observed network delays than on the observed network delays of the distant past. This form of estimate should not be completely unfamiliar; a similar idea is used to estimate round-trip times in TCP

29 Adaptive playout delay (2) also useful to estimate average deviation of delay, v i : v i = (1-b)v i-1 + b r i t i d i estimates d i, v i calculated for every received packet, but used only at start of talk spurt for first packet in talk spurt, playout time is: playout-time i = t i + d i + Kv i remaining packets in talk spurt are played out periodically Multmedia Networking 5-29

30 Adaptive playout delay (3) Q: How does receiver determine whether packet is first in a talkspurt? if no loss, receiver looks at successive timestamps difference of successive stamps > 20 msec -->talk spurt begins. with loss possible, receiver must look at both time stamps and sequence numbers difference of successive stamps > 20 msec and sequence numbers without gaps --> talk spurt begins. Multmedia Networking 7-30

31 loss recovery schemes attempt to preserve acceptable audio quality in the presence of packet loss. A packet is lost : either if it never arrives at the receiver or if it arrives after its scheduled playout time. For example retransmitting lost packets may not be feasible in a realtime conversational application such as VoIP. Indeed, retransmitting a packet that has missed its playout deadline serves absolutely no purpose. Multmedia Networking 7-31

32 loss anticipation scheme VoIP applications often use some type of loss anticipation scheme. Two types of loss anticipation schemes are: forward error correction (FEC) Simple FEC Alternative FEC interleaving. Multmedia Networking 7-32

33 Forward Error Correction (FEC) The basic idea of FEC is to add redundant information to the original packet stream. For the cost of marginally increasing the transmission rate, the redundant information can be used to reconstruct approximations or exact versions of some of the lost packets. Two simple FEC mechanisms: The first mechanism sends a redundant encoded chunk after every n chunks. The second FEC mechanism is to send a lower-resolution audio stream as the redundant information. Multmedia Networking 7-33

34 VoiP: recovery from packet loss (1) Challenge: recover from packet loss given small tolerable delay between original transmission and playout each ACK/NAK takes ~ one RTT alternative: Forward Error Correction (FEC) send enough bits to allow recovery without retransmission (recall two-dimensional parity in Ch. 5) Multmedia Networking 7-34

35 Simple FEC scheme for every group of n chunks, create redundant chunk by exclusive OR-ing n original chunks send n+1 chunks, increasing bandwidth by factor 1/n. if n = 3, then the transmission rate increases by 33 percent. can reconstruct original n chunks if at most one lost chunk from n+1 chunks, with playout delay Multmedia Networking 7-35

36 Second FEC scheme the sender might create a nominal audio stream and a corresponding low-resolution, low-bit rate audio stream. For example: (The nominalstream could be a PCM encoding at 64 kbps, and the lower-quality stream could be a GSM encoding at 13 kbps.) The low-bit rate stream is referred to as the redundant stream. whenever there is non consecutive packet loss, the receiver can conceal the loss by playing out the low-bit rate encoded chunk that arrives with the subsequent packet. low-bit rate chunks give lower quality than the nominal chunks. However, a stream of mostly high-quality chunks, occasional low-quality chunks, and no missing chunks gives good overall audio quality.

37 VoiP: recovery from packet loss (2) another FEC scheme: piggyback lower quality stream send lower resolution audio stream as redundant information e.g., nominal stream PCM at 64 kbps and redundant stream GSM at 13 kbps non-consecutive loss: receiver can conceal loss generalization: can also append (n-1)st and (n-2)nd low-bit rate chunk Multmedia Networking 7-37

38 Interleaving As an alternative to redundant transmission, a VoIP application can send interleaved audio. the sender resequences units of audio data before transmission, so that originally adjacent units are separated by a certain distance in the transmitted stream. Interleaving can mitigate the effect of packet losses. Multmedia Networking 7-38

39 VoiP: recovery from packet loss (3) interleaving to conceal loss: audio chunks divided into smaller units, e.g. four 5 msec units per 20 msec audio chunk packet contains small units from different chunks if packet lost, still have most of every original chunk no redundancy overhead, but increases playout delay Multmedia Networking 7-39

40 Advantages and disavantages of using interleaving Interleaving can significantly improve the perceived quality of an audio stream It also has low overhead. The obvious disadvantage of interleaving is that it increases latency. This limits its use for conversational applications such as VoIP, although it can perform well for streaming stored audio. A major advantage of interleaving is that it does not increase the bandwidth requirements of a stream. Multmedia Networking 7-40

41 Error Concealment Error concealment schemes attempt to produce a replacement for a lost packet that is similar to the original. this is possible since audio signals, and in particular speech, exhibit large amounts of short-term selfsimilarity. these techniques work for relatively small loss rates (less than 15 percent), and for small packets (4 40 msecs). When the loss length approaches the length of a phoneme (5 100 msecs) these techniques break down, since whole phonemes may be missed by the listener. Multmedia Networking 7-41

42 2 methods of received-based recovery 1. Packet repetition replaces lost packets with copies of the packets that arrived immediately before the loss. It has low computational complexity and performs reasonably well. 2. Another form of receiver-based recovery is interpolation, which uses audio before and after the loss to interpolate a suitable packet to cover the loss. Interpolation performs somewhat better than packet repetition but is significantly more computationally intensive Multmedia Networking

43 Voice-over-IP: Skype Skype is an immensely popular VoIP application with over 50 million accounts active on a daily basis. In addition to providing host-to-host VoIP service, Skype offers host-to-phone services, phone-tohost services, and multi-party host-to-host video conferencing services. Skype was acquired by Microsoft in 2011 for over $8 billion. Multmedia Networking 7-43

44 Voice-over-IP: Skype For both voice and video, the Skype clients have at their disposal many different codecs, which are capable of encoding the media at a wide range of rates and qualities. For example, video rates for Skype have been measured to be as low as 30 kbps for a low-quality session up to almost 1 Mbps for a high quality session Typically, Skype s audio quality is better than the POTS (Plain Old Telephone Service) quality provided by the wire-line phone system. Multmedia Networking

45 Voice-over-IP: Skype example (Skype codecs typically sample voice at 16,000 samples/sec or higher, which provides richer tones than POTS, which samples at 8,000/sec. By default, Skype sends audio and video packets over UDP. However, control packets are sent over TCP, and media packets are also sent over TCP when firewalls block UDP streams. Skype uses FEC for loss recovery for both voice and video streams sent over UDP. The Skype client also adapts the audio and video streams it sends to current network conditions, by changing video quality and FEC overhead Multmedia Networking 7-45

46 Voice-over-IP: Skype proprietary applicationlayer 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 Skype login server Skype clients (SC) supernode (SN) supernode overlay network overlay network: among SNs to locate SCs login server Application Layer 2-46

47 Voice-over-IP: Skype Skype are organized into a hierarchical overlay network, with each peer classified as a super peer or an ordinary peer. Skype maintains an index that maps Skype usernames to current IP addresses (and port numbers). This index is distributed over the super peers. When Alice wants to call Bob, her Skype client searches the distributed index to determine Bob s current IP address. Because the Skype protocol is proprietary, it is currently not known how the index mappings are organized across the super peers, although some form of DHT organization is very possible. Multmedia Networking

48 P2P voice-over-ip: skype skype client operation: 1. joins skype network by contacting SN (IP address cached) using TCP 2. logs-in (usename, 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 Application Layer 2-48

49 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 Application Layer 2-49