A Detailed Measurement of Skype Network TrafficDario Rossi Marco Mellia, Michela Meo

ENST ParisTech – INFRES Politecnico di Torino – DELENemail: dario.rossi@enst.fr email: name.surname@polito.it

Abstract—The last few years witnessed peer-2-peer(P2P) and VoIP telephony gaining a tremendous popu-larity: Skype is beyond doubt the most amazing exampleof this new phenomenon, as its 170 millions users testify.In this paper, we propose a detailed measurement of Skypesources: we adopt a twofold methodology, using activeexperiments and passive measurement to gain knowledgeabout the traffic Skype generates, in a controlled andrealistic environment, respectively.

The analysis considers both signaling traffic as wellas voice calls. Furthermore, we address the descriptionof Skype sources at both packet- and flow-levels: wedescribe fine-grained dynamics of the interaction betweenSkype and the network, as well as provide a macroscopiccharacterization of Skype traffic.

I. INTRODUCTION

In the last years, the Peer-2-Peer (P2P) paradigmgained popularity to the point that P2P application areresponsible for vast portion of Internet traffic, which notonly involves residential broadband Internet accesses,but also enterprise networks. Indeed, many different P2Papplications exist, such as chat, file-sharing, telephony,video-streaming, backup systems, etc. Furthermore, evenwithin the same target application, there are many dif-ferent application and protocols available–such as struc-tured vs unstructured overlays– that translate into verydifferent types of traffic from the network viewpoint.

The ability to measure, understand and model thenetwork traffic has been a fundamental activity sincethe time when Web was the Internet application [1]:indeed, this knowledge is instrumental for a wide rangeof network operations such as performance evaluation,traffic engineering, capacity planning. As a consequenceof P2P widespread adoption, the research activitiesrelated to P2P traffic identification, classification andmeasurement acquired importance. File-sharing, beingthe first example of new application exploiting the P2Pparadigm, has been studied for a relatively long time [2]:as a result, many details concerning the file popularity[3], user churn [4], and query process [5] are avail-able. At the same time, we point out that while thefirst applications such as KaZaa were proprietary and

unknown, many currently popular applications (such asBitTorrent, Gnutella, eMule) are implemented as open-source software and their protocol internals are welldocumented. Conversely, more recent P2P applications(such as Internet telephony, videoconferencing, videostreaming, etc.), have enjoyed an enormous successamong the Internet users but protocols details remainrelatively unknown.

The best example is represented by Skype – whichis beyond any doubtthe VoIP application in the currentInternet application spectrum: developed in 2002 by thecreators of KaZaa, it recently reached over 170 millionsof users, and accounts for more than 4.4% of total VoIPtraffic [6]. As such, Skype is attracting the attention ofthe research community and of the telecom operator aswell, and a great deal of valuable work can already befound in the literature [7], [8], [9], [10], [11], [12], [13].Yet, due to Skype proprietary protocols and obfuscatednature, due to traffic encryption and due to the useof reverse-engineering techniques [7], many interestingquestions remain, to date, unanswered. Besides, Skypeimplements a number of techniques to circumvent NATand firewall limitations [8], which add further complexityto an already blurred picture.

In this paper, we develop a complete characterizationof the traffic Skype generates, considering both signalingtraffic and voice/video calls, providing several insightsat both packet- and flow-levels. The analysis relies ontwo complementary approaches. On the one hand, weexamine Skype activities in a controlled environment,using an active testbed methodology. On the other hand,building over our previous work [10] that allows us toprecisely identify Skype clients, we resort to passivemeasurements in order to reveal those aspects that apurely active methodology alone cannot capture.

II. SKYPE PREMIER AND SOURCE MODEL

This section provides a high-level description of theSkype model we adopt in this paper. Information aboutSkype can be gathered by works dealing with its inter-nals [7], [8], with the issue of Skype identification [9],[10], and with the characterization of its traffic and

Skype

Voice/Video/Data/Instant Messaging M

U

X

Skype Signaling

Skype Codecs and Network Awareness

Skype Overlay Maintenance Param

Skype

M

U

XSkype Signaling:Peer discovery,

Contact refreshing

Skype Codecs and Network Awareness

Users’ Behaviorand

Network Performance

Skype Overlay Maintenance Param

M

U

X

Skype

Voice/Video/Data/Instant Messaging M

U

X

Skype Signaling

Skype Codecs and Network Awareness

Skype Overlay Maintenance Param

Skype

Voice/Video/Data/Instant Messaging M

U

X

Skype Signaling

Skype Codecs and Network Awareness

Skype Overlay Maintenance Param

Skype

Voice/Video/Data/Instant Messaging M

U

X

Skype Signaling

Skype Codecs and Network Awareness

Skype Overlay Maintenance Param

Skype Services:Voice/Video/Data/Instant Messaging

Fig. 1. Synopsis of the Skype source model

users [11], [12], [13]. The main difference betweenSkype and other VoIP clients is that Skype adopts aP2P architecture. Only user authentication is performedusing a classical client-server architecture, via a publickey mechanisms: except for the authentication, all furthersignaling is performed on the P2P overlay. Thus, Skypeuser’s informations (e.g. contact list, status, preferences,etc.) are entirely decentralized and distributed amongP2P nodes – which allow scalability on the one handand cost-effectiveness on the other hand.

Skype offers end users several (free) services: i) voicecommunication, ii) video communication, iii) file trans-fer and iv) chat services. The communication betweenusers is established using a traditional end-to-end IPparadigm, but Skype can also route calls through otherP2P nodes (called supernodes) to ease the traversal ofsymmetric NATs and firewalls. Voice calls can alsobe directed toward the PSTN using Skypein/Skypeoutservice, in which case a fee is applied. In the following,we denote byEnd-to-End (E2E)call any voice/videocommunication occurring between two Skype clients,and by End-to-Out (E2O)call any communication in-volving a Skype peer and a PSTN terminal.

A single random port is selected during applicationinstallation, and it is never changed (unless forced bythe user). Thus we can identify:

• a Skype client, by its socket, i.e., the (host IPaddress, Skype UDP/TCP port) pair.

• a Skypeflow, by using the traditional tuple (IPsource and destination addresses, UDP/TCP sourceand destination ports, IP protocol type), in which atleast one endpoint is known to be a Skype client.

A flow starts when a packet with a new flow tuple isfirst observed, while it is ended by either aninactivity

timeout1 or, in case of TCP, by observing the tear-downsequence if present. Skype clients are identified as in[10], so that it is possible to identify all voice flows thatare originated by or directed to a Skype client.

For what concerns the transport layer, Skype relies onboth TCP and UDP. Both signaling and communicationare preferentially carried over UDP – although whenUDP communication is impossible, Skype falls back toTCP, listening to the same random port whenever possi-ble (or eventually port 80 or 443, which are normally leftopen by network administrators to allow Web browsing).However, irrespectively of the transport layer protocol,the Skype traffic can be divided, as Fig. 1 depicts, intwo components: namelysignaling and services, whichcan be influenced by different external factors (such asuser’s behavior and network status) and as internal Skypesettings (such as Codec preferences).

Signalingtraffic, addressed in Sec. III, can be modeledas a superposition of different “threads,” correspondingto different activities – such as peer discovery, overlaymaintenance and contact refreshment. In the following,we will show that different threads are differently af-fected by external factors: for instance, we anticipate thatpeer discovery islatency driven, whereas the contact-refreshing activity appears to besocial-networkdriven.Servicetraffic is addressed in Sec. IV, where we con-sider voice calls but explicitly neglect video calls, datatransfer and instant messaging. We investigate Skypedynamics at a packet-level granularity through a testbedstudy, unveiling if and how Skype reacts to the inferrednetwork performance– such as packet loss and availablebandwidth.

III. SKYPE SIGNALING TRAFFIC

In this section, we analyze Skype signaling trafficby means of passive measurements, applying the clas-sification framework presented in [10]. Results refer toone week long trace collected during may 2007 at theaccess link of Politecnico’s campus LAN, where about7000 different hosts are used by both students and staffmembers. In the following we focus on signaling flowscarried over UDP only, which are the largest and mostinteresting part of Skype signaling traffic.

A. Signaling activity

Since all signaling traffic is encrypted, we are forcedto adopt a black-box approach. First of all, it is necessary

1Since the largest inter-packet gap we ever observed is 180 s (likelyused by Skype as keep-alive message to force the refresh of possibleNAT entries), in this paper we set the inactivity timer to 200s.

-1500

-1000

-500

0

500

1000

1500

0 4 8 12 16 20 24

Time elapsed [Hr]

Most active signaling client

0 1 2 3 4 5 6

Incr

emen

tal I

dent

ifier

s ID- a

nd ID

+Time elapsed [Hr]

Random active client

(a)

0 0.01 0.02 0.03 0.04 0.05

0 10 20 30 40 50 60 70 80 90 100

pdf

Number of peers contacted in 300s

0

0.02

0.04

0.06

0.08

6 12 18 24

pdf

Peer Life and Death Time [h]

LifeDeath

(b)

0

0.004

0.008

0.012

10 100 1000

pdf

Round Trip Time [ms]

Non-Probe

0

0.004

0.008

0.012

10 100 1000

Probe

(c)

Fig. 2. Passive network monitoring: (a) Pictorial representation of Skype activity pattern for two different peers. (b) PDF of the number ofpeers contacted 300 s (top), and inferred peers’ life-time and death-time (bottom); (c) PDF of the round trip time of probe and dialog traffic.

to point out that Skype signaling traffic is very limitedin bitrate: the 95-th percentile tops to about 100 bps,while very few nodes (possibly supernodes) generate,on average, more than 1 kbps. Yet, an intense signalingtask is carried on during all the peer lifetime, as shownin Fig. 2-(a), which depicts the typical Skype activitypattern. We consider two specific peers, namely the mostactive peer that does not perform any call (left plot) anda randomly picked peer exhibiting both signaling andvoice traffic (right plot). Letp be the observed peer.Each dot in the picture corresponds to a packet in thetrace: the x-axis represents the packet arrival time (sincethe first packet observed forp). A positive value on they-axis reports an identifier, ID, of a peer that receiveda message fromp; similarly, negative values representpeers that sent messages top.

Several remarks can be gathered from Fig. 2-(a):indeed, though thesemanticof the signaling activitycannot be inferred from purely passive measurements,the form of signaling activity can be further differ-entiated. Interestingly, the number of contacted peersexhibits an almost linear growth with time, hinting toP2P network discovery and maintenance being carriedon during most of the peer lifetime. Moreover, the rangeof the y-values corresponds to the number of differentSkype peers whom the selected peerp is exchangingmessage with: the plot shows that the most active peerhas contacted (was contacted by) about 1100 other peersduring 28h, whereas the random peer by about 450during 6h. Then, notice that signaling is mainly builtby single message probes, to which (most of the times)some kind of acknowledgment follows. The fact thatp

knows the address and ports of valid (but previously un-contacted) Skype peers means that the above informationis carried in the encrypted portion of previous signalingmessages. Some peers are instead contacted on a regular

basis: in the activity pattern plot, horizontal segmentsstate that the same peer is periodically contacted dur-ing p lifetime. On the contrary, vertical patterns hintto the presence of timers that trigger an informationrefreshment, which involves both old peers, and probediscoveries toward new peers (this behavior is clearlyvisible in the right-hand side of Fig. 2-(a) every hour).The above observations suggest the existence of two verydifferent kinds of the Skype signaling, namely:

• Probe traffic, which aims at network discovery:probe flows are made of a single packet sent towarda peer, to which a single reply packet possibly fol-lows, butno further messageis exchanged betweenthe pair of peers.

• Non-probe traffic, which aims at the network main-tenance, including overlay and contact informa-tion management: non-probe flows are either flowslonger than one packet or sequence of single-packetprobe flows, separated by a time gap larger than theinactivity timeout.

Finally, in order to gauge a relationship among theamount of signaling flows and the number of contacts inthe buddy list, we performed a simple active experiment.We used three Skype accounts and measured 8 hoursof their idle activity: one account had a single onlinecontact, the second account had 5 online contacts, andthe third had 10 online contacts. The experimental re-sults suggest the existence of asuper-lineardependencybetween the number of contacts and the number ofsignaling packets exchanged, although a larger scaleexperiment would be needed to more precisely quantifythe relationship.

B. Signaling flows

As Fig. 2-(a) already showed, many signaling flowsare single-packet probes that create new temporary soft-state entries, rarely used later on. At the same time, it is

possible to observe persistent signaling activity transfer-ring a few MBytes of information over several thousandsof packets: indeed, probes account for less than 5% of theexchanged signalingbytes. A possible reason behind thisempirical evidence could be the presence ofsuper-nodesamong our internal clients, that generate intense andlong-lasting signaling activity – though this statementrequires further investigation.

Further insight about Skype signaling is given inFig. 2-(b), which quantifies the peer contact rate, as wellas the peer life-time and death-time. More precisely, letus focus on the numberN of differentpeers contacted bypeerp considering a time interval of 300s.N is closelyrelated to the number of signaling flows thatp generatesin the time unit. Considering all internal peers and thewhole analysis week, the distribution ofN is shown inthe top portion of Fig. 2-(b). In 90% of the cases,N

is smaller than 30, with an average of 16; in 1% of thecases,N exceeds 75. Note that this metric is of particularinterest since it is related to the burden a Skype clientposes in any device operating at flow level, e.g., a entryin a NAT table, a look-up in a firewall ACL table, etc.

Bottom portion of Fig. 2-(b) reports the PDF of thepeer life-time and death-time, inferred from the signalingactivity during the week long observation period: inparticular, a peer is considered dead if no packet is sentfor a period of time longer than an idle timeτ . Since weverified that valuesτ > 200 s have a minimal impact onthe result, we conservatively setτ = 500 s. Interestingly,except for very short sessions, most of the peers are alivefor about one third of the day (i.e., during working hours)and remain dead for the rest of time (i.e., during thenight). Thus, it seems as though peers’ lifetime followsthe Personal Computers’ lifetime, which suggests thatmost of the people runs Skype by default. An importantconsequence is that Skype churning rate is very low,which explains the modest bitrate requirement for P2Poverlay maintenance.

C. Signaling locality

We now investigate whether further, important, differ-ences exist between probe and non-probe traffic. Indeed,it would be reasonable for Skype to implement somemechanism that privileges data traffic between nearbyhosts, so as to minimize network latency. Therefore,we focus on the locality properties of probe and non-probe peers, and depict in Fig. 2-(c) the PDF of theRound Trip Time (RTT) between any two peers. Moreprecisely, in the case of probe traffic, we define RTTas the time elapsed between the packet probe going out

from the campus LAN and the probe response packet.For non-probe traffic, we consider only the first sent-received packet pair as a measure of the RTT. Clearly,this measurement takes into account both the networkand the application layer latencies.

The information in the picture confirms our previousintuition: the latency of probing traffic is lower than thatof non-probing traffic. Given our measurement location,RTT smaller than 100ms are typical of nodes withinthe European Union, while RTT larger than 100msare typical of nodes outside it. Measurement resultsallow us to conjecture that the probing mechanism islatency driven: Skype client probes for peers based onthe information received by other peers so that lowlatency peers are more likely selected than high latencyones. Conversely, non-probe traffic RTT tends to belarger: considering that users resort to Skype to lowercommunication fees and to keep contacts with otherfaraway users, this is rather unsurprising. The contactselection mechanism is reflected into the peer selectionmechanisms so that it seems to bepreference driven,i.e., the Skype overlay is modeled over the user socialnetwork. On the contrary, the peer discovery mechanismsimplemented by means of single-packet probes is drivenby the physical properties of the underlying network.

IV. SKYPE SERVICE TRAFFIC

The characteristics of voice/video service traffic gener-ated by the Skype source are driven by the voice encoderand the network performance, to which Skype adaptsduring a call in order to provide users with high QoS.

For what concerns voice/video Codecs, Skype choosesvia an unknown algorithm among ISAC, ILBC, G.729,iPCM-WB, E-G.711A, PCM A/U, VP7 that are allstandard except ISAC and VP7, proprietary solutions ofGlobalIPSound [14] and On2 [15], respectively. ISACis the preferred Codec for End-to-end calls, while theG.729 Codec is preferred for End-to-Out calls and True-Motion VP7 is used for streaming video. As a sidenode, due to the different characteristics of each Codec, aSkype voice call can consume up to 230 kbps and as fewas 11 kbps. Also, variable bit rate Codecs (VBR), such asISAC and iPCM-wb, exhibit larger message size variancewith respect to constant bitrate (CBR) ones (e.g., G.729,iLBC and PCM).

However, irrespectively of the Codec, in order tocope with the potential loss of a voice block or tomodify the message generation rate, the source may mul-tiplex one or more blocks of encoded voice in a singlemessage [10]. Therefore, to better observe the Skype

0

100

200

300

400

500

0 180 360 540 0

2

4

6

8

10

L [B

ytes

]

Loss

[%]

Time [s]

Loss rate

0 10 20 30 40 50 60

0

2

4

6

8

10

IPG

[ms]

(a)

0

20

40

60

80

100

0

20

40

60

80

100

IPG

[ms]

Ban

dwid

th li

mit

[kbp

s]

Bandwidth limit

0 50

100 150 200 250 300

0 30 60 90 120 150 180 210 240 0 20 40 60 80 100

L [B

ytes

]

Time [s](b)

Fig. 3. Active testbed measurement: Skype inter-packet-gap and message size for (a) increasing packet loss rates and (b) decreasingbottleneck bandwidth.

message generation process, and to further investigatehow Skype reacts to different network conditions, wesetup a testbed involving several PCs connected by aLinux box. Restricting our attention to the default ISACCodec, we perform a set of experiments by generatingvoice calls between two PCs directly connected by aLAN, with no interfering traffic. In order to emulatedifferent network conditions, we control the packet lossrate and the available bottleneck bandwidth by runningNIST Net [16] on the Linux box.

A. Reaction to Losses

To analyze Skype reaction to packet losses, we imposea Bernoulli message loss probability increasing from 1%to 10%, with 1% step increment every 45 s, and recordthe corresponding packet level trace. Fig. 3-(a) reportsthe inter-packet-gapIPG (top) and the message sizeL

(bottom) observed during a voice call encoded by ISAC;for reference purposes, the solid line reports the enforcedloss probability.

During the first 45 seconds, no artificial loss is en-forced. At the very beginning of the connectiont < 20 s,the message size alternates between small (around 125Bytes) and large (around 250 Bytes) values; then, during20 ≤ t < 45 s, Skype emits only small-sized messages.Thus, whenever a Skype call starts and network condi-tions are still unknown, Skype possibly multiplexes twovoice blocks into the same message – so to reduce theimpact of possible packet losses and to proactively en-force a good QoS for the end-user (still, amix of double-sized and single-sized messages are present, meaningthat not all voice blocks are sent twice). Then, onceSkype detects that no losses occur in the network, itstops retransmitting old voice blocks along with newer

ones, so that the message size stabilizes around smallvalues. Whent > 45 s, the link starts discarding packets:as it can be seen, Skype starts retransmitting old-blocksalong with new ones as soon as the loss probabilityexceeds 0%. The old-blocks retransmission probabilitychanges along with loss probability: the vast majorityof messages have no old-blocks multiplexed until lossesexceed 4%, in which case multiplexing is used with fewexceptions. When no losses are detected any more, atthe end of the trace, old-blocks retransmission suddenlystops. Interestingly, the inter-packet-gapIPG measuredbefore the loss point is not affected at all by the lossrate, meaning that Skype do not change neither the VBRcodec state nor the framing time to react to packet loss.

B. Reaction to Bandwidth Limit

Let us now investigate the impact of the availableend-to-end bandwidth onIPG and L. Fig. 3-(b) re-ports the results obtained by restricting the availablebandwidth according to the pattern shown by the solidline. When the available bandwidth is larger than theactual bitrate, no changes are observed with respectto the behavior previously shown in Fig. 3-(a): at thebeginning of the connection, Skype aggressively probesthe network conditions, then stops multiplexing old voiceblocks. However, as soon as the bandwidth limit kicksin (at about 150 s), Skype adapts the bitrate to the newconstraint: the message size pattern changes andL takessmaller values, which means that the Codec is working ata lower bitrate. At the same time, theIPG values changeto 20, 30 or 60 ms, suggesting that the Skype frameralso modifies the framing time to reduce the protocoloverhead.

V. D ISCUSSION ANDCONCLUSIONS

This paper proposes a detailed analysis of Skypesources, via both active experiments in a controlledtestbed and passive measurements from a real network.We considersignaling and service traffic: the first isrelated to the maintenance of the P2P overlay, whereasthe second is due to voice and video calls among peers.

In the case of signaling traffic, bitrate is not a concernwhile the number of contacted peers over time couldbe. Signaling traffic can be discriminated inprobe andnon-probetraffic: the first type of signaling activity iscomposed of a pair of packets exchanged between twopeers, and it is used throughout the whole peer lifetimeto discover new nodes. Non-probe traffic, instead, isused periodically to exchange information about thestatus of peers of interest, and to support the overlaynetwork maintenance. Interestingly, the wide majorityof signaling flows are single packet probes: yet, anexiguous number of non-probe signaling flows carriesthe most relevant part of the exchanged signaling bytes.Concerning the Skype overlay, we have shown thatthe probing mechanism is latency driven, whereas thenon-probe peers selection is driven by user habits: theSkype overlay is jointly shaped by the the combinationof the this two mechanisms. Thus, peers with whomnon-probe traffic is exchanged are selected on the topof the user social network – so to cluster friends.Conversely, the network discovery is carried on with aprobing mechanism that takes into account the networkcharacteristics as well – so to minimize the networklatency. Finally, active testbed experiments suggest theamount of signaling traffic to be tied to the number ofcontacts in the user buddy lists, although a larger scaleexperiment would be needed in order to gather moreprecise quantitative relationship: an interesting directionthat we plan to analyze in the future is to explorethe correspondence of social-networks graphs versus theamount of observable Skype signaling flows.

Concerning the service traffic, we explored Skypereaction to network conditions in a controlled testbed:more in detail, our experiments suggest that Skypeimplements a “network aware” algorithm that measuresthe available bandwidth and the packet loss and reactsaccordingly. Specifically, the possible Skype reactionsto adverse network conditions include the tuning of:i) the message framing time, ii) the VBR Codecs bi-trate and iii) the amount of redundant old-voice blocksmultiplexed into new messages. More precisely, Skypeinternal algorithms react differently to path losses and

network congestion: in the first case, Skype aggres-sively adds redundancy to encounter the effect of losses,whereas, in case of congestion, it conservatively tries toreduce its bitrate.

We acknowledge that the proposed measurement isforcibly incomplete as a consequence of both ourmethodology (e.g., single measurement point, small scaleof the active testbed) and of the proprietary and ob-fuscated nature of Skype. Still, we believe this workto be a valuable contribution with two respects: on theone hand, to the understanding of a very popular P2Papplication and of its traffic dynamics; on the otherhand, the provided Skype source description could bereadily implemented on one of the many available P2Psimulators, enriching the simulation realism.

REFERENCES

[1] P. Barford , M. Crovella, “Generating representative Web work-loads for network and server performance evaluation,”ACMSIGMETRICS’98Madison, Wisconsin, USA, Jun. 1998

[2] K. P. Gummadi, R. J. Dunn, S. Saroiu, S. D. Gribble, H. M.Levy, J. Zahorjan. “Measurement, Modeling and Analysis of aPeer-to-Peer File-Sharing Workload.”In Proc. ACM SOSP’03,NY, USA, Oct 2003.

[3] D. Stutzbach, S. Zhao, R. Rejaie, “Characterizing Filesin theGnutella Network,”Multimedia Systems Journal, 2007.

[4] D. Stutzbach, R. Rejaie, “Understanding Churn in Peer-to- PeerNetworks,” In Proc. of ACM Internet Measurement ConferenceIMC’06, Brazil, Oct. 2006.

[5] A. Klemm, C. Lindemann, M. K. Vernon, O. P. Waldhorst.“Characterizing the query behavior in peer-to-peer file sharingsystems,”In Proc. of ACM Internet Measurement ConferenceIMC’04, Italy, Oct. 2004.

[6] “International carriers’ traffic grows despite Skype popularity”,http://www.telegeography.com/, Dec. 2006.

[7] P. Biondi, F. Desclaux, “Silver Needle in the Skype.”Black HatEurope’06, Amsterdam, the Netherlands, Mar. 2006.

[8] S. A., Baset, H. Schulzrinne, “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol.”IEEE Infocom’06, Spain,Apr. 2006.

[9] K. Suh, D. R. Figuieredo, J. Kurose, D. Towsley, “Character-izing and detecting relayed traffic: A case study using Skype.”,IEEE Infocom’06, Barcelona, Spain, Apr. 2006.

[10] D.Bonfiglio, M.Mellia, M. Meo, D.Rossi, P.Tofanelli, “Reveal-ing Skype Traffic: when randomness plays with you”,ACMSigcomm’07, Kyoto, Japan, Aug. 2006.

[11] S. Guha, N. Daswani and R. Jain, “An Experimental Study ofthe Skype Peer-to-Peer VoIP System”,International Workshopon Peer-to-Peer Systems, Santa Barbara, CA, Feb. 2006.

[12] K. Ta Chen, C. Y. Huang, P. Huang, C. L. Lei “QuantifyingSkype User Satisfaction”,ACM Sigcomm’06, Italy, Sep. 2006.

[13] D.Rossi, M.Mellia, M.Meo, “Following Skype Signalling Foot-step”, IEEE IT-NEWS (QOS-IP) 2008, Venice, Italy, Feb. 2008.

[14] GlobalIPSound web site, http://www.globalipsound.com[15] On2 web site, http://www.on2.com[16] M. Carson, D. Santay, “NIST Net: a Linux-based network

emulation tool.” ACM SIGCOMM Computer CommunicationReview, July 2003.