Adaptive Voice over IP

Transcription

1 Adaptive Voice over IP C. Casetti ½,J.C.DeMartin ¾,M.Meo ½ ½ Dipartimento di Elettronica, Politecnico di Torino, Italy ¾ CENS-CNR, Politecnico di Torino, Italy Submitted to: IEEE Communications Magazine Special Issue on Internet Telephony N.B. Sections in italic denote additions w.r.t. submitted version. Abstract We discuss the technical viability of transporting real-time voice over IP networks when the output rate of the speech encoder is adjusted to match the characteristics of the network: speech is coded at low bit rates when the network is congested; at higher bit rates, otherwise. First, issues affecting perceptual QoS are analyzed. The rationale for Adaptive Voice over IP (AVoIP) is explained and possible architectures described. The problem of estimating the state of the network is then discussed. A rate control algorithm is introduced. Finally, measurements of AVoIP performance over the Internet are presented. Adaptive voice over IP solutions allow more efficient use of network resources, offer the operator greater flexibility and pave the way for new services. 1 Introduction Although the value of integrating voice and data transport on the same network has been perceived for many years now, it is only recently, with the huge and still rapidly growing expansion of IP networks, that the issue has seized the attention of individuals, companies and academic institutions worldwide. To accomplish such integration, voice, so far transported predominantly by circuit-switched networks, is digitized, the resulting samples compressed to save bandwidth, then packetized and sent through the network. At the receiver side, voice packets are reordered, decompressed and then played back to the listener. This work was supported in part by a contract with CSELT 1

2 Several challenging problems need to be solved to achieve the same level of quality offered by the traditional PSTN s in the context of a packet network like the Internet. Delay. A first major issue is that of delay. In a generic IP network, in fact, delays are not bounded nor predictable. Interactive, two-way telephony, however, imposes strict limits on the allowable overall mouth-to-ear delay. Delay contributions due to the network primarily, propagation time and average time spent in router queues can be controlled by ad hoc engineering of the network. Other contributions to the overall delay depend, instead, on the specific Voice over IP architecture employed: parameters like packet size, speech coding algorithm, and playout buffer size all play a role in determining the final delay budget. Delay Variations. Even in the context of carefully engineered networks, however, delay remains variable. The effects of such variability can be controlled by using a buffer, commonly called the playout buffer, that allows the receiver to wait for all packets arriving within an acceptable time limit. Smooth playback of the incoming speech signal is then possible. The issue is further discussed in Section 3. Packet Losses. A third issue is that, in networks based on the best-effort model, packets can be lost. Generally, packet losses occur when a congested router drops the tail of its queues. Effective ways to replace missing speech packets at the receiver are, therefore, needed; some of them are reviewed in Section 2. Speech Compression. Transport of voice over data networks is generally made possible by speech compression techniques. Typical bit rates range from 64 kb/s for companding PCM to 2.4 kb/s for some vocoders. Each speech coding algorithm implements a different tradeoff between output speech quality, algorithmic delay, bit rate, computational complexity and robustness to background noise. The optimal speech coder for VoIP depends on the specific scenario. No speech coding standard has been yet developed with VoIP as primary application. Usually, fixed-rate speech coders are employed. Such coders generate a constant output bit rate, independently of network conditions. If the network cannot sustain the traffic, packets will be delayed and/or dropped. Issues affecting speech quality are further addressed in Section 2. The overall objective of voice transmission over IP networks is to find an array of technical solutions to these challenges that guarantees the desired level of perceptual quality under most network conditions. A new approach to reaching this overall objective is presented in this work. The fundamental idea is that of linking the operation of the source coder to the current state of the network. If the network is congested, speech is coded at lower bit rates; if the network, instead, is lightly loaded, the speech coder is allowed to operate at higher bit rates. This approach, which may be called Adaptive Voice over IP (or AVoIP, for short), relies on variable bit rate speech coders to generate only the bandwidth that the network is capable of carrying with a given quality of service at any instant in time. Voice over IP is known to offer several advantages over traditional switched-circuit telephony. In our view, Adaptive Voice over IP enhances these advantages. Firstly, more efficient use of network resources is granted since AVoIP applications do not need a rigid partitioning of the link bandwidth (as plain Voice over IP does); instead, it can exploit statistical rather than deterministic 2

3 QoS guarantees: as such, AVoIP is a natural candidate for Intserv/Diffserv networks [1]. Also, by adapting gracefully to network congestion, AVoIP flows leave more room to signaling and critical in-band flow management sharing the same network facilities. Furthermore, operators can enjoy greater flexibility: by trading off perceived QoS and monetary cost, they can increase the range of services they are offering, e.g., fixed-high-bit-rate calls, fixed-low-bit-rate calls, adaptive bitrate calls, etc. Finally, new services can be implemented, especially in environments where both data and voice share a narrowband link. For example, technical support being provided through a modem link could use AVoIP to allow customer-salesperson interaction while patches are uploaded on the customer s workstation. To achieve such adaptivity, however, an additional set of problems needs to be solved. Primarily, network congestion needs to be estimated, a rate control algorithm developed and a variable bit rate speech coder integrated into the system. Network State Estimation. Making the source rate that is, the rate at which the speech compressor operates depend on the state of the network, requires some way of estimating such state, since the IP service model does not offer congestion notification. The focus is on two main measures: the effective capacity of the link, largely determined by the bottlenecks along the connection, and the detection of temporary congestions. Based on such measures, the rate control algorithm will select bit rates compatible with the estimated capacity and respond to short-term clogging of the link. Rate control algorithm. Given estimates of the state of the network, appropriate ways to adapt the source rate are then needed. In the case of IP telephony, typical networking objectives, such as maximum throughput and stability, must be considered together with perceptual constraints linked to the desired perceptual quality of service. An increase in bit rate, for instance, generally results in increased speech quality, but only if the network can sustain the increased traffic. If it cannot, the quality increase will be attenuated, or even transformed into a decrease, by greater average delays and more frequent packet losses. Variable Bit Rate Speech Coding. Although most speech coding standards are fixed rate, several variable bit rate speech coders are available. A recent example of a variable bit rate solution is the new GSM Adaptive Multi-Rate speech coding standard [3]. In GSM-AMR one of 8 rates ranging from 4.75 kb/s to 12.2 kb/s is selected, depending on the instantaneous condition of the wireless channel. Another example is the new ISO MPEG-4 audio standard, which includes a variable bit rate CELP speech coder operating at bit rates between 3.85 kb/s and 12.2 kb/s [4]. The remaining part of this paper is organized as follows: Section 2 summarizes the issues affecting perceptual QoS, including speech coding techniques. Section 3 explains the rationale for Adaptive Voice over IP (AVoIP) and illustrates possible architectures. The problem of estimating the state of the network is then discussed in subsection 3.1. Finally, a rate control algorithm and measurements of AVoIP performance over the Internet are presented in Section 4. 2 Perceptual Quality of Service Perceptual quality of service is a function of many variables. We describe the main contributors in this section. 3

4 2.1 Speech Coding Voice over IP, like all forms of digital telephony, relies on speech coders to convert speech waveforms into bitstreams. The discipline that studies how to optimally perform such conversion under a given set of constraints is known as speech coding (see, for instance, [5].) Speech Signal. Speech is a nonstationary signal with fairly rich frequency content (up to 10 khz) and wide dynamic range (up to 60 db of sound pressure level.) For telephone applications, only about 3 khz of the frequency components are transmitted, resulting in what is commonly called narrowband, or telephone-bandwidth, speech (sampling frequency of 8 khz). Since the transmitted frequencies, however, are in the perceptually crucial region between, roughly, 300 and 3300 Hz, telephone speech is highly intelligible and natural sounding. A richer speech signal can be obtained by sampling at 16 khz, thus preserving about 7 khz of the speech spectrum (50-7,000 Hz). The resulting signal, called wideband speech, is more intelligible and perceptually more satisfying than narrowband speech, and is currently considered for new telephony services in voice over IP and wireless scenarios. Digital Coding of Speech. Digital narrowband speech is normally obtained by sampling the analog input signal 8,000 times per second and then linearly representing each samples with bits, resulting in data rates of the order of 100 kb/s. International standard ITU-T G.711 provides the same quality of bit linear PCM at 64 kb/s, with very little complexity and delay, by means of companding (or log) PCM. G.711 is the default speech coder for many applications; it is, for instance, the mandatory audio codec for ITU H.323-compliant multimedia applications. However, 64 kb/s is a fairly high bit rate, even with today s high capacity networks. To reduce the bit rate, more complex algorithms are needed, usually involving models of human speech production and, to a more limited extent, of human hearing. The additional complexity usually implies significantly more delay and computation than PCM; the resulting quality can be close to PCM, but often not as robust to different input signals (such as noisy speech, signaling tones or music). Nonetheless, the persistent need for lower bit rates, together with the advent of fast digital signal processors (DSP s), has motivated the development of speech coders that offer very good speech quality at continuously decreasing bit rates. Most of today s state of the art speech coders working at bit rates between 5 and 16 kb/s (e.g, G.723.1, G.729 and GSM-EFR) are based on the CELP (Code Excited Linear Prediction) paradigm. 2.2 Speech Coding and Perceptual Quality The performance of a speech coder can be defined by five main attributes: output speech quality, bit rate, algorithmic delay, computational complexity and robustness to background noise. The ideal speech coder generates very high quality speech at very low bit rate, with no delay, little complexity and great robustness to background noise. In practice, instead, speech quality will be a constrained function of the other four attributes. Speech Quality. Output speech quality is usually assessed by subjective tests, most commonly the Mean Opinion Score (MOS) test, where a large number of listeners are asked to rate speech samples on a scale from 1 (poor) to 5 (excellent). For telephone-bandwidth speech, an MOS score of about 4 is usually considered equivalent to toll-quality, i.e., the quality of commercial wireline telephony. 4

5 Bit Rate. Currently, state of the art speech coders can achieve toll-quality at bit rates as low as 6 kb/s, with a good degree of overall robustness. Speech coders can be classified depending on whether they operate at fixed or at variable bit rates. Variable bit rate speech coders, in turn, can be source-driven or network-driven. In the first case, the rate depends on the instantaneous characteristics of the input signal (for instance, more bits are used to represent voiced sounds, such as vowels, and less for background noise); in the second, the rate is imposed from the outside. In many cases, a simple form of source-driven, variable bit rate operation is achieved by placing a voice activity detector (VAD) in front of a fixed rate speech coder. When the VAD detects silence, few bits, or no bits at all, are sent, allowing bandwidth savings in the order of 40 50% for a typical two-way conversation. Delay. A speech coder usually operates on segments of speech, called frames, not on individual samples. A delay is, therefore, necessarily introduced between the instant a sample enters the speech coder and the instant when the corresponding synthesized sample exits the decoder. The delay introduced by the speech coder is usually called algorithmic delay. Since an interactive, two-way conversation requires speech to be perceived by the listener no more than about 250 ms after the sounds have been uttered by the speaker (see, for instance, ITU- T Rec. G.114), delay must be carefully controlled. If the overall average delay (algorithmic, transmission, queueing, buffering, decoding, etc.) is greater than 250 ms, the perceptual quality decreases, until the conversation switches to half-duplex mode. Complexity. Computational complexity is usually measured in number of instructions per second on a commercially available DSP processor. The amount of ROM and RAM required by a typical hardware implementation is frequently considered as part of the complexity figure as well. Robustness to background noise. The more speech coders rely on models of speech production, the more they risk becoming vulnerable to noisy speech, where noise can be anything from car noise to interfering talkers to background music. Subjective tests specifically targeted at measuring performance in background noise conditions allow assessment of the overall robustness of speech coders. 2.3 Perceptual Quality with Lossy Channels When the compressed bitstream is transmitted over lossy channels, another attribute of a speech coder becomes important, that is, its robustness to bit errors and frame losses, (or frame erasures.) In the first case, individual bits in the compressed bit stream are corrupted, resulting in more or less pronounced degradation of the synthesized speech. Generally, at random error rates below 0.1% no significant speech degradation is expected. In the second case, a whole frame (5 to 25 ms of speech) is either unavailable or declared unusable. A frame is deemed unusable, and therefore discarded, when bit errors are detected in the perceptually crucial bits (e.g., the most significant bits of the frame energy) of the frame. A frame, instead, is not available when the decoder cannot access it when needed for playback. The first case is typical of wireless applications, where the channel becomes occasionally very noisy due to fading. The second case is typical of speech transmission over packet networks, where frames can arrive too late for timely playback, or even not arrive at all. 5

6 In both cases, techniques to fill the gap corresponding to the corrupted or missing frame are needed. In the case of high rate waveform coders, such as PCM, sample-based techniques such as repetition, interpolation and extrapolation are used. In more complex coders, instead, the parameters of the previous, correctly received frame are generally used, often by repeating them, with a muting mechanism activated in case of consecutive frame erasures. Note that some speech coders are quite sensitive to frame erasures; under 3% random frame erasures, for instance, the quality of the widely used G.729 standard drops by about 0.5 MOS, a very significant drop. In the case of packet networks, multiple descriptions of the same frame can be sent in different packets, allowing better reconstruction in case of packet loss. Usually the additional descriptions are at lower bit rates to save bandwidth [6]. This approach can be made adaptive more redundancy is used if the network is congested, less if the network is lightly loaded [7]. 2.4 Perceptual Quality with Time-Varying Channels When the compressed bitstream is transmitted over a time-varying channel, estimating and controlling the perceptual quality becomes particularly demanding. In the specific case of voice over IP, the IP network can be seen as a lossy channel with time-varying capacity, packet loss rate and delay. The instantaneous capacity is determined in part by structural characteristics of the connection, such as its bottlenecks, in part by traffic dynamics. In any case, the basic assumption is that transmission rates above the current capacity result in packet losses and/or increased delays, that is, in potentially significant degradation of the perceptual quality. If a fixed rate source coder is employed and the capacity drops below the operating bit rate, the perceptual quality will be more or less severely affected, with no way of controlling the degradation. In this scenario, countermeasures can only be implemented at system level, e.g., increasing the capacity of the system and implementing mechanisms that ensure that the capacity will never, or very rarely, drop below a certain safety level. If, instead, a network-driven variable bit rate speech coder is used, the time-varying nature of the channel can be, at least to some extent, matched, resulting in greater control of the perceptual QoS and in more efficient use of network resources. 3 The Case for Light-Weight Congestion Control Algorithms in IP Telephony The issue of flow and congestion control for real-time traffic is a delicate one: application-layer coding algorithms and lower-layer rate control schemes should cooperate to respond to critical situations such as network congestions. While a window-based flow control is hardly viable since it would result in stop-and-go source behavior, a light-weight, QoS-aware congestion control scheme that drives the source encoding rate has the potential to lessen the impact of unruly realtime traffic. The main goal of such an algorithm is reducing the load on the network when congestion (i.e., queue build-up at intermediate nodes) occurs. If a large part of network traffic is composed of variable-bit-rate regulated voice traffic, and the algorithm regulating each source is devised so as to react to specific warnings such as increasing delay or sudden packet loss, then a control strategy may successfully reduce the occurrence of congestions. 6

7 The topic of variable-rate adaptive schemes for multimedia streams has been addressed by several researchers in the past. In a general framework [8], Shenker compared the benefits of rigid and adaptive applications, pointing out that rate-adaptive applications are more robust to network congestion than other classes of adaptive applications (i.e., delay-adaptive applications, which are tolerant of occasional delay bound violations, but whose generation rate is independent of the network congestion). In [9], Cox and Crochiere foreshadow adaptive schemes for variable-bit-rate coders by analyzing the behavior of a buffer control mechanism that has sources react to buffer overflows and underflows. The idea of an end-to-end feedback control is already present in the work by Bially et al. [10], where network-driven voice source based on embedded speech coding schemes are studied, although the involvement of intermediate nodes is still required; in [11], Yin and Hluchyj developed an analytical model for an end-to-end feedback control mechanism for variable bit-rate coders. Bolot and Turletti in [12] proposed and tested an adaptive video coder based on the state of the network, while in [13], they introduced a polling mechanism that allowed a real-time content transmitter to elicit feedback information from receivers and use it to control its own rate. Similar in spirit to our approach, the works by Busse et al. [14] and Sisalem and Schulzrinne [15], employ a sender-based packet loss rate estimation scheme to drive the transmission rate of the realtime source; the latter, in particular, also attempts to have the adaptive real-time source behave fairly towards concurring TCP connections. Adaptive algorithms can act upon several aspects of a voice connection, i.e. the coding algorithm, the packet length, or the playout delay at the receiver. The first two parameters can be chosen by the transmitter, while the latter can be adjusted by the receiver. The coding algorithm affects the source transmission rate, and other aspects, as discussed in Section 2, while the packet length trades off transmission overhead and packetization time (and thus, delay). The playout delay can be controlled at the receiver by proper regulation of the playout buffer length. The size of the playout buffer can be fixed, determined at call start-up and then kept constant, or allowed to change in the course of the conversation to adapt to variations of the behavior of the network. The main trade-off is between degradation due to delay versus degradation due to packet losses: on the one hand, longer buffers decrease the number of packet discarded because of late arrival (packets are discarded at the receiver if they are too late), at the expense of increased delay; on the other hand, shorter buffers can curb the playout delay, but at the expense of increased packet loss rates. In this paper, we will focus our attention on providing adaptability to IP telephony applications through variable bit-rate coding algorithms. Application-level congestion avoidance must be accomplished by looking at end-to-end metrics, such as packet loss, latency, and jitter. Packet losses are an indication of a severe network congestion: any action taken following this notification may be belated, thus leading to a prolonged congestion. However, preemptive measures may also be undertaken by acting over an increasing-delay notification. Since the delay experienced by packets traveling from a source to a destination is a function of the number of hops, and of the queue length at intermediate nodes, a sudden increase in the delay observed by the receiver (and relayed to the sender, through periodic receiver s reports) is often followed by packet loss within the next few round-trip times. Section 4.2 outlines an adaptive algorithm that tries to capture the guidelines set forth so far. 7

8 3.1 Monitoring of Network Congestion In order to implement an effective adaptive algorithm, estimates of quantities related to the ongoing connection and needed by the adaptive algorithm are to be carried out. Such a procedure involves several aspects: 1. since delay estimates are essentially based upon a correct alignment of both the source s and the receiver s clocks, the skew between these clocks should be estimated; 2. while single delay estimates can be made on the reception of every RTP packet, the loss rate estimates should reflect the ratio between lost and expected packets, computed over a time span; 3. some quantities require averaging in order to compare the current estimates with the expected behavior: moreover, the average should be weighted so as to smooth out fluctuations; 4. what information to exchange between source and receiver (i.e. who computes the estimates, who averages the quantities, etc.) should be determined. Clearly, since sampling and averaging must be done in real time, procedures ought to be as simple as possible. 4 AVoIP: Implementation and Testing In this Section, we present an AVoIP application developed by the authors. Following the reasoning outlined in Section 3, we will describe an adaptive algorithm that, relying on loss and delay indications, drives the application s transmission rate; both the application and the algorithm have been tested over a wide range of network configurations: in this Section, we will include results from a few challenging scenarios. 4.1 RTPFone, an AVoIP Application The AVoIP principles presented in the previous sections were the guidelines for the implementation of RTPFone, a real-time adaptive Internet Telephony application, running over Windows 9x/NT. RTP and RTCP were implemented following the relevant RFC s [2]. Audio recording and playback rely on standard Windows API s. Variable bit rate speech coding between 8 and 64 kb/s is achieved through delta modulation, with little complexity, minimal delay and generally acceptable quality (given enough processing power and less system overhead, however, state-of-the-art variable bit rate coders could be employed instead). The size of the playout buffer is dynamically controlled depending on the state of the network. 4.2 The Adaptive Algorithm We will focus on a simple algorithm that, starting from delay and loss measurements relayed by RTCP reports, tries to regulate the output rate of several voice sources. The rate control algorithm described in this paper does not rely on explicit congestion indications by either the intermediate nodes or by receivers. Rather, it uses the information that can be carried by cyclic RTCP receiver 8

9 reports to let the source know the state of the on-going connection. The control algorithm runs at the source itself. An alternative scheme would be one where the algorithm runs at the receiver, where all the raw estimates are available, not only down-sampled, smoothed versions of the same. Such receiver based scheme, however, would require a signaling mechanism to convey rate increase/decrease commands to the source. The basic idea is that the source coder should reduce its rate when packet loss and/or delay have been observed to have considerably increased above a high-mark threshold. Besides, it should switch to higher rates if no packets are lost and if the delay decreases below a low-mark threshold. Clearly, since we are looking at an IP telephony scenario, both parties can, at different times, be considered source and destination. In order to simplify the description, we will decouple these interactions and only consider a communication between a generic source and a receiver. Throughout the algorithm description, the following parameters are used: curr time: current time; dec int: minimum time between back-to-back decrements; inc int: minimum time between back-to-back increments; var time: time when the last rate decrement/increment occurred; Max Loss: loss ratio that triggers the algorithm s rate decrement; Min Loss: loss ratio that triggers the algorithm s rate increment; peer SLR: smoothed loss ratio; avg delay: average (smoothed) delay; latency thresh: minimum relative latency increase that triggers a rate decrement (i.e., latency thresh = 0.1 indicates that the rate should be lowered if the latest delay measure is 10% higher than the mean so far computed; peer delay: latest measure of delay. Smoothed quantities are computed through an exponential averaging function: Ü Òµ «Ü Ò ½µ ½ «µü Òµ where Ü Òµ is the averaged quantity and Ü Òµ is the Ò Ø sample; «is a positive real number smaller than 1 and determines speed and accuracy with which the average Ü Òµ follows the trend of Ü Òµ. The algorithm is described in Figure 1. It is periodically executed by the source, whenever a receiver report reaches it. It is to be observed that the adaptive algorithm does not follow the additive increase/multiplicative decrease paradigm that is successfully employed by many congestion control algorithms, such as TCP or ABR. However, a similar behavior can be attained through a careful selection of the algorithm s parameters, i.e. by setting a smaller dec int with respect to inc int. Also, being a second-order estimate, and thus more delicate to be properly accounted for, the jitter is not used in this algorithm. However, we plan to extend the scope of our adaptive algorithms to take into account the jitter in the future. 9

10 decrement = increment = FALSE; /* Compare loss rates */ if (peer SLR Max Loss) then if (curr time var time + dec int) then decrement =TRUE; var time = curr time; endif else if (peer SLR Min Loss) then if (curr time var time + inc int) then increment =TRUE; var time = curr time; endif endif /* Compare delay estimates */ if (peer delay avg delay + avg delay * latency thresh) then if (curr time var time + dec int) then decrement =TRUE; var time = curr time; endif else if (peer delay avg delay + avg delay * latency thresh) then if (curr time var time + inc int) then increment =TRUE; var time = curr time; endif endif /* Change rate according to choice (decrement has priority)*/ if (decrement =TRUE)then DecreaseRate(); else if (increment =TRUE)then IncreaseRate(); endif Figure 1: Pseudo-code for the adaptive algorithm 10

11 4.3 Testbed and Results The performance of RTPFone and of the algorithm just described were evaluated over a great number of settings. When both hosts were connected to the same LAN, or to adjacent LANs, the quality of the conversation carried through RTPFone is excellent: the adaptive algorithm promptly reacts to the occasional network congestions, with usually no audible impact on the speech; when no congestion is present, the algorithm allows a stable performance at the highest possible bit rate. Three significantly different scenarios, all of them involving a long-distance communication over the public Internet, were considered: LAN-LAN: the communicating hosts were connected to 10 Mb/s Ethernet LANs, the one at Politecnico di Torino, Italy, the other at University of Vigo, Spain. The tests were performed on a weekday morning during regular business hours. Seventeen hops in either direction separated the two hosts. LAN-modem: one host was connected using a 33.6 kb/s modem, through a dial-up access at the Politecnico di Torino; the other end was located on an Ethernet LAN at Carnegie Mellon University, USA. These tests were performed on a weekday, at 22:00 CET (corresponding to 16:00 ET). The two hosts sat 20 hops apart. modem-modem: hosts were connected using a 33.6 kb/s modem as in the previous scenario, and a 28.8 kb/s modem through a public ISP in Irving, Texas, USA. The tests were run on a Sunday, at 18:00 CET, corresponding to 11:00 in Irving. 16 hops separated the two hosts. It should be pointed out that, for obvious reasons, these tests were performed over the public Internet, i.e., in a hostile environment, were many flows do not employ any backoff strategy. Under these assumptions, AVoIP is mainly looking for an appropriate operating point, characterizing the transmission rate at which it performs best in terms of loss rate and delay. Clearly, it does not affect the congestion level of the network, either positively or negatively. With reference to the definitions listed in Section 4.2, the parameters common to all three scenarios were: Loss thresholds: 3% (Min Loss), 7% (Max Loss) Delay threshold (latency threshold): 20% (for exp. 2: 30%) Minimum time before decrease(dec int): 1 s Minimum time before increase(inc int): 5 s 1 frame per packet Buffer size: min = 2, max = 16 (frames.) In each scenario, the performance of the algorithm is analyzed through the evolution in time of three indicators, as perceived by either connection end: the bit rate (in kb/s) at which the source is transmitting, the smoothed loss rate for packets of that source (as reported back by periodic RTCP packets), and the playout delay of voice packets sent by that source (in ms, but scaled by 10 for readability s sake). 11

12 Spain TX Statistics (lat th = 20%) bit rate (kb/s) SLR (%) delay*0.1 (ms) 50 Avg. Bit Rate = 19kb/s Avg. Delay = 164ms Avg. SLR = 7% time (s) Figure 2: experiment 1 (LAN-LAN) Transmitting rate, Smoothed Loss Rate (SLR) and Playout Delay referring to the Spanish host 12

13 Italy TX Statistics (lat th = 20%) 60 bit rate (kb/s) SLR (%) delay*0.1 (ms) Avg. Bit Rate = 58kb/s Avg. Delay = 74ms Avg. SLR = 1% time (s) Figure 3: experiment 1 (LAN-LAN) Transmitting rate, Smoothed Loss Rate (SLR) and Playout Delay referring to the Italian host 13

14 150 bit rate (kb/s) SLR (%) delay*0.1 (ms) 100 Avg. Bit Rate = 23kb/s Avg. Delay = 568ms Avg. SLR = 11% time (s) Figure 4: experiment 2 (LAN modem) Transmitting rate, Smoothed Loss Rate (SLR) and Playout Delay referring to the USA host Results from scenario LAN-LAN are showninfigures 2 and3 and refer tothe data collected by the transmitting host in Spain and in Italy, respectively. Since the hosts had virtually no bandwidth limitation, the full output range 16 to 64 Kb/s was employed. Note that the two links were not symmetric in terms of performance: from Italy to Spain, the average network delay (74 ms) was less than half the delay experienced in the other direction (164 ms), and it was also much more stable. Consequently, the Italian host could operate at very high bit rates, while the Spanish host only occasionally ventured above 16 kb/s. In both cases, the communication dynamically adapted to the condition of the network: the Italian host bit rate dropped from 64 kb/s to 40 kb/s in response to the delay and packet loss spike towards the beginning of the conversation, while the Spanish host managed to push the bit rate up to 32 kb/s during the relatively uncongested period around Ø ¼. Results from the second scenario (LAN-modem) are presented in Figures 4 and 5. Owing to bandwidth limitation at one end, the transmitting rate was allowed to fluctuate in the kb/s range. Data referring to the USA host, Figure 4, show that the algorithm was often responding to delay, rather than loss rate. Indications of this can be found by observing that several delay spikes brought the transmission bit rate down to the lowest possible value, which in turn resulted in smaller delays. A less bursty delay pattern is shown in Figure 5, referring to the Italian host: in this case the loss rate is actually driving the transmission rate. In the modem-modem experiment, both hosts were limited by the speed of the modems (different at the two ends), which again imposed the use of a subset of the available bit rates. Figures 6 shows the data collected by the transmitting host in the USA, while Figure 7 shows the same information as estimated at the transmitting host in Italy. As was observed in the LAN-LAN scenario, the performance was not symmetric in the two directions, i.e., a much greater delay variability was 14

15 35 bit rate (kb/s) SLR (%) delay*0.1 (ms) 30 Avg. Bit Rate = 21kb/s Avg. Delay = 113ms Avg. SLR = 10% time (s) Figure 5: experiment 2 (LAN modem) Transmitting rate, Smoothed Loss Rate (SLR) and Playout Delay referring to the Italian host detected from the USA towards Italy than vice versa. This condition was reflected by a much more stable algorithm behavior at the Italian hosts, while the delay fluctuations as perceived by the USA host gave rise to an oscillating output bit rate. 5 Conclusions A new approach to voice over IP, called Adaptive Voice over IP (AVoIP) has been introduced. Our discussion has focused on both coding and networking aspects of the problem. At first, we have outlined the main technical issues influencing speech quality in transmission of voice over packet networks. Then, we have discussed the issue of flow control needed by AVoIP applications over the current IP service model. Finally, we described a complete AVoIP solution implemented into an actual PC application and reported experiments under a variety of conditions, showing the technical viability of the new approach. Acknowledgements The authors would like to thank Victoria Abreu Sernández at the University of Vigo, Spain, and Marco Mellia, at Carnegie Mellon University, USA, who kindly agreed to run the long-distance AVoIP tests. Also, the authors acknowledge the work done by Sven Cotella and Paolo Cagnotti for the development of RTPFone. 15

16 USA TX Statistics (lat th =?%) 100 bit rate (kb/s) SLR (%) delay*0.1 (ms) 80 Avg. Bit Rate = 19kb/s Avg. Delay = 470ms Avg. SLR = 0% time (s) Figure 6: experiment 3 (modem-modem) Transmitting rate, Smoothed Loss Rate (SLR) and Playout Delay referring to the USA host 16

17 Italy TX Statistics (lat th =?%) Avg. Bit Rate = 31kb/s Avg. Delay = 455ms Avg. SLR = 2% bit rate (kb/s) SLR (%) delay*0.1 (ms) time (s) Figure 7: experiment 3 (modem-modem) Transmitting rate, Smoothed Loss Rate (SLR) and Playout Delay referring to the Italian host 17

18 References [1] J. Wroclawski. Specification of the Controlled-Load Network Element Service. RFC [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 1889, January [3] E. Ekudden, R. Hagen, I. Johansson, and J. Svedberg. The Adaptive Multi-Rate Speech Coder, In Proceedings IEEE Workshop on Speech Coding Proceedings. Haikko Manor, Porvoo, Finland, June [4] ISO/IEC. Information technology - coding of audiovisual objects, part 3: Audio, subpart 3: Celp FDIS, December [5] W.B. Kleijn and K.K. Paliwal (editors). Speech Coding and Synthesis. 1995, Elsevier Science. [6] V. Hardman et al. Reliable Audio for use over the Internet. In Proceedings INET 95, Honolulu, HI, pp , June [7] J.C. Bolot, S. Fosse-Parisis and D. Towsley. Adaptive FEC-Based Error Control for Internet Telephony. In Proceedings INFOCOM 99, pp , [8] S. Shenker. Fundamental Design Issues for the Future Internet. IEEE Journal on Selected Areas in Communications, September [9] R.V. Cox and R.E. Crochiere. Multiple User Variable Rate Coding for tasi and Packet Transmission Systems. IEEE Transactions on Communications, 28(3): , March [10] T. Bially, B. Gold, and S. Seneff. A Technique for Adaptive Voice Flow Control in Integrated Packet Networks IEEE Transactions on Communications, Vol. COM-28, pp , Mar [11] N. Yin and M.G. Hluchyj. A Dynamic Rate Control Mechanism for Source Coded Traffic in a Fast Packet Network. IEEE Journal on Selected Areas in Communications, 9(7): , September [12] J.C. Bolot and T. Turletti. A Rate Control Mechanism for Packet Video in the Internet. In Proceedings of IEEE INFOCOM 94, Toronto, Canada, June [13] J.C. Bolot, T. Turletti, and I. Wakeman. Scalable Feedback Control for Multicast Video Distribution in the Internet. In Proceedings of SIGCOMM 94, London, UK, August [14] I. Busse, B. Deffner and H. Schulzrinne. Dynamic QoS Control of Multimedia Applications Based on RTP. In Proceedings of 1st Int. Workshop on High Speed Networks and Open Distributed Platforms, St. Petersburg, Russia, June [15] D. Sisalem and H. Schulzrinne. The Loss-Delay Adjustment Algorithm: A TCP-Friendly Adaptation Scheme. In Proceedings of International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), Cambridge, England, July