An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol Salman A. Baset and Henning G. Schulzrinne Department of Computer Science Columbia University, New York NY 10027 {salman,hgs}@cs.columbia.edu Abstract—Skype is a peer-to-peer VoIP client developed in 2003 by the organization that created Kazaa. Skype claims that it can work almost seamlessly across NATs and firewalls and has better voice quality than other VoIP clients. It encrypts calls end-to-end, and stores user information in a decentralized fashion. Skype also supports instant messaging and conferencing. This paper analyzes key Skype functions such as login, NAT and firewall traversal, call establishment, media transfer, codecs, and conferencing under three different network setups. Analysis is performed by careful study of the Skype network traffic and by intercepting the shared library and system calls of Skype. We draw a map of super nodes to which Skype establishes a TCP connection at login. I. INTRODUCTION Skype [1] is a peer-to-peer (p2p) VoIP client developed by the organization that created Kazaa [2]. Skype allows its users to place voice calls and send text messages to other users of Skype clients. In essence, it is very similar to the MSN and Yahoo IM applications, as it has capabilities for voice-calls, instant messaging, audio conferencing, and buddy lists. However, the underlying protocols and techniques it employs are quite different. Like its file sharing predecessor Kazaa, Skype uses an overlay peer-to-peer network. There are two types of nodes in this overlay network, ordinary hosts and super nodes (SN). An ordinary host is a Skype application that can be used to place voice calls and send text messages. A super node is an ordinary host’s end-point on the Skype network. Any node with a public IP address having sufficient CPU, memory, and network bandwidth is a candidate to become a super node. An ordinary host must connect to a super node and must authenticate itself with the Skype login server. Although not a Skype node itself, the Skype login server is an important entity in the Skype network as user names and passwords are stored at the login server. This server ensures that Skype login names are unique across the Skype name space. Starting with Skype version 1.2, the buddy list is also stored on the login server. Figure 1 illustrates the relationship between ordinary hosts, super nodes and the login server. Apart from the login server, there are SkypeOut [3] and SkypeIn [4] servers which provide PC-to-PSTN and PSTN-to-PC bridging. SkypeOut and SkypeIn servers do not play a role in PC-to-PC call establishment and hence we do not consider them to be a part of the Skype peer-to-peer network. Thus, we consider the login server to be the only central component in the Skype p2p network. Online and offline user information is stored and propagated in a decentralized fashion. Skype login serverMessage exchangewith the login serverduring loginordinary host (SC)super node (SN)neighbor relationships in the Skype network Figure 1. Skype Network. There are three main entities: supernodes, ordinary nodes, and the login server. We believe that each Skype node uses a variant of the STUN [5] protocol to determine the type of NAT and firewall it is behind. We also believe that there is no global NAT and firewall traversal server because if there was one, the Skype node would have exchanged traffic with it during the login and call establishment phases in the many experiments we performed. The Skype network is an overlay network and thus each Skype client (SC) needs to build and refresh a table of reachable nodes. In Skype, this table is called host cache (HC) and it contains IP address and port number of super nodes. Starting with Skype v1.0, the HC is stored in an XML file. Skype claims to have implemented a ‘3G P2P’ or ‘Global Index’ [6] technology, which is guaranteed to find a user if that user has logged in the Skype network in the last 72 hours. This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the Proceedings IEEE Infocom.1-4244-0222-0/06/$20.00 (c)2006 IEEESkype uses wideband codecs which allows it to maintain reasonable call quality at an available bandwidth of 32 kb/s. It uses TCP for signaling, and both UDP and TCP for transporting media traffic. The rest of this paper is organized as follows. Section II describes key components of the Skype software and the Skype network. Section III describes the experimental setup we used for reverse-engineering the Skype protocol. Section IV discusses key Skype functions like startup, login, user search, call establishment, media transfer and codecs, and presence timers. Flow diagrams based on actual network traffic have been included to elaborate on the details. Section V discusses conferencing. Section VI discusses other experiments and compares aspects of Skype with Yahoo, MSN and Google Talk IM applications. A world map of SNs to which a SC establishes a TCP connection at login is also drawn. II. KEY COMPONENTS OF THE SKYPE SOFTWARE A Skype client listens on particular ports for incoming calls, maintains a table of other Skype nodes called a host cache, uses wideband codecs, maintains a buddy list, encrypts messages end-to-end, and determines if it is behind a NAT or a firewall. This section discusses these components and functionalities in detail. A. Ports A Skype client (SC) opens a TCP and a UDP listening port at the port number configured in its connection dialog box. SC randomly chooses the port number upon installation. In addition, SC also opens TCP listening ports at port number 80 and 443 which, otherwise, are used to listen for incoming HTTP and HTTP-over-TLS requests. Unlike many Internet protocols like SIP [9] and HTTP [10], there is no default TCP or UDP listening port. Figure 14 shows a snapshot of the Skype (v1.4) connection dialog box. This figure shows the ports on which a SC listens for incoming connections. B. Host Cache The host cache (HC) is a list of super node IP address and port pairs that SC builds and refreshes regularly. It is a critical part to the Skype operation. In SC v0.97, at least one valid entry must be present in the HC. A valid entry is an IP address and port number of an online Skype node. At login time, a SC v0.97 tried to establish a TCP connection and exchange information with any HC entry. If it was