Home >Documents >Peer-to-Peer audio conferencing using SIP: Overall ... · 5/11/2007  · Peer-to-Peer audio...

Peer-to-Peer audio conferencing using SIP: Overall ... · 5/11/2007  · Peer-to-Peer audio...

Date post:19-May-2020
Category:
View:5 times
Download:0 times
Share this document with a friend
Transcript:
  • Peer-to-Peer audio conferencing using SIP:

    Overall introduction

    Luca Maccari, Gabriele Violino, Max Weltz

    May 11, 2007

    We have decided to take the context of an audio conferencing application to discuss severalissues on P2P/SIP. Audio conferencing is nowadays a widely use service on the Internet, whichmakes it a concrete frame of work. Many points are important when it comes to softwaresaddressed to a large public: look and feel, quality of the background service, security, hypeand others. We chose here to address the issue of security, as the past as often proved thatthe more common a system is, the more it is likely to be attacked, especially when like inP2P systems it is easy to join it ; the issue of quality (QoS) as people are more and moredemanding in terms of quality when it comes to communications and finally the issue of theP2P architecture itself, not visible to the end-user but an important part of the application.The security issue was addressed by Luca Maccari, the QoS issue by Gabriele Violino and theP2P architecture issue, as well as the introduction, was address by Max Weltz.

    In the end, we hope to have demonstrated that a P2P audio conferencing solution was doable andcould offer the same services as a traditional SIP network, maybe not in a pure P2P solution butrather with a hierarchical system. With the increase of bandwidth and of QoS use on the Internetand with the solutions discussed for security, we think that a P2P/SIP conferencing system is viableon the long term for a wide public.

    1

    maguireCross-Out

    maguireReplacement TextAn

    maguireInserted Textis used as the context

    maguireCross-Out

    maguireInserted Textconcerning

    maguireCross-Out

    maguireReplacement Textcurrently

    maguireInserted Textd

    maguireCross-Out

    maguireInserted Textof reference

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textissues

    maguireInserted Text,

    maguireCross-Out

    maguireInserted Texthas

    maguireCross-Out

    maguireInserted Textn

    maguireCross-Out

    maguireReplacement Textas

    maguireCross-Out

    maguireInserted Textin

    maguireInserted Textof service

    maguireInserted Textis important

    maguireInserted Texttheir

    maguireInserted Text;

    maguireInserted Textwhile

    maguireCross-Out

    maguireReplacement Textit is

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textfeasible

    maguireCross-Out

    maguireReplacement Textwhile perhaps the result is not

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textavailable

    maguireInserted Textproposed

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textin

  • Peer-to-Peer audio conferencing using SIP:

    P2P Architecture

    Max Weltz

    May 11, 2007

    Abstract

    This report is part of a collection of three report describing several aspects of Peer-to-Peer audioconferencing using SIP: security, Quality of Service and P2P architecture. This particular report willdetail the P2P architecture that can be used for an audio conferencing solution. Here will be described thedifferences between a pure SIP solution and a P2P/SIP solution, in terms of architecture and messages.We will see what issues are solved by that system and what other issuers are raised and how they canbe circumvented.

  • Contents

    1 Introduction 1

    2 Peer-to-Peer Architecture 12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Preliminaries on P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Audioconferencing basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4 Existing works on P2P/SIP solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

    2.4.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4.2 Characteristics of a P2P/SIP solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4.3 SIP using DHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4.4 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    2.5 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Other aspects of a P2P solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    3 Conclusion 10

    References 11

    1 Introduction

    Peer-to-Peer (P2P) is one of the current trends on the Internet with up to 90% [San05] of the traffic share,depending on countries and sources. P2P is praised for its scalability and as the size of the communicationnetworks increases - for instance Skype has 80 million users [SJ06] and more than 8 million users online atpeak hours [Sky07], clearly demonstrating the capacities of P2P infrastructures - it is with no surprise thatSIP developers have turned towards this new solution, whether the P2PSIP working group1 or the Damaka2

    company. In section 2 we will see what attempts were made to adapt the SIP protocol to be fully functionalin a P2P audio conferencing context and what is left to be done in that area.

    2 Peer-to-Peer Architecture

    2.1 Introduction

    This whole section is devoted to the integration of P2P in SIP solutions. We will first discuss briefly P2Pprinciples and audioconferencing basics. We will then have a closer look at existing works on P2P/SIP lookingat the solutions they offer and the choices they made. We will wrap up with a quick look at alternativessolutions and name a few other aspects that deserve to be mentioned when it comes to P2P/SIP solutions.We will not give exhaustive definitions of SIP or P2P in that part as it is assumed they are already in themind of the readers. In case the reader needs or wants to go deeper into the subject, RFC 2543 and RFC3261 relates to SIP and Stoica et al. in [MKL+04] provide a comprehensive guide to P2P.

    1http://www.p2psip.org/2http://damaka.com/

    1

    http://www.p2psip.org/http://damaka.com/maguireNoteWhen you put the three papers together you should also make a common table of contents.

    maguireCross-Out

    maguireReplacement Textgenerating

    maguireCross-Out

    maguireInserted Textthe

    maguireCross-Out

    maguireReplacement Texty

    maguireCross-Out

    maguireCross-Out

    maguireInserted Textvia

    maguireCross-Out

    maguireReplacement Text desribe the

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Text. Finally we state

    maguireCross-Out

    maguireCross-Out

    maguireInserted Textwork,

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textsome

    maguireCross-Out

    maguireReplacement Textregarding

    maguireCross-Out

    maguireReplacement Text,

    maguireCross-Out

    maguireReplacement Textthat both

    maguireCross-Out

    maguireReplacement Textknow to

    maguireCross-Out

    maguireInserted Text [x]

    maguireInserted Text [x]

    maguireCross-Out

    maguireReplacement Textdefine

    maguireCross-Out

  • 2.2 Preliminaries on P2P

    Peer-to-Peer has proven over the past years its qualities in terms of scalability, reliability and flexibility asit can be used to address various resources such as files or audio communication and be used on multiple OSand platforms. The clear success of Skype, which is partially based on the P2P technology, is particularlyinteresting in the context of this paper. However we cannot stop there and be satisfied of the success of aP2P VoIP solution as Skype does not use SIP and therefore will be of no further interest us. P2P providesan alternative to the usual client-server model on the edge of Internet. Therefore P2P fits well into the SIPmodel as SIP itself delegates a great deal to end points even though SIP communications often go throughproxies and servers. In fact, except for resource location, SIP is end-to-end and the communication thatresults afterwards is also end-to-end [BL07], so why not make it all, end-to-end, P2P? Numerous benefitswould result including the possibility to allow SIP-communications on ad-hoc wireless networks, and moregenerally in the cases where accessing to distant servers is not possible or not preferable [BLJ05].

    √ √

    √ Member of the P2P overlay network

    a) Physical connections between the nodes

    b) Overlay network between the nodes

    Figure 1: Difference between physical and overlay networks

    Peer-to-Peer networks are based on overlay networks, that’s to say virtual networks of devices notnecessarily matching the lower-level connections between them (cf Figure 1). This overlay network canbe of two types: unstructured or structured. Only the latter will be of interest for the rest of this studybut we need to explain both to have a clear view of the subject. An unstructured network is built whennew nodes are placed anarchically into the pre-existing overlay network and when there is no better way tocontact a node than to flood the overlay network. On the other hand, a structured overlay network has aspecific handling of new nodes joining or leaving the network and provides an easy access to resources, oftenvia the use of a Distributed Hash Table. We will discuss the use of DHT later on.

    2.3 Audioconferencing basis

    Our objective is to propose a solution viable for an audioconferencing purpose. We should first describewhat are the specificities of audioconferencing. SIP audioconferencing should allow users to lead a chattingsession with audio support with more than two parties involved, a party being a SIP terminal.

    2

    maguireNoteWhy all of this wasted vertical space at the top of the page (and all the subsequent pages of your section))?

    maguireCross-Out

    maguireReplacement TextBrief introduction to Peer-.to-peer

    maguireInserted Text(P2P)

    maguireCross-Out

    maguireInserted Text,

    maguireCross-Out

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Text. In addition, it has been

    maguireCross-Out

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textsimply

    maguireCross-Out

    maguireReplacement Textwith predicting

    maguireInserted Text,

    maguireInserted Textnor is it actually a fully P2P system, hence it

    maguireCross-Out

    maguireInserted Textto

    maguireInserted Text in the scope of this paper

    maguireCross-Out

    maguireInserted Textwell,

    maguireInserted Text,

    maguireInserted Textsession

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textstrictly

    maguireInserted Texti.e., purely

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textad hoc

    maguireNotetwo words from Latin

    maguireCross-Out

    maguireReplacement Textpotentially

    maguireCross-Out

    maguireReplacement Textcorresponding to

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textrandomly

    maguireCross-Out

    maguireReplacement Texta

    maguireInserted Textmetod of

    maguireCross-Out

    maguireInserted Textnodes

    maguireCross-Out

    maguireReplacement Text, thus it

    maguireInserted Textway to

    maguireCross-Out

    maguireInserted Text (DHT) see section x.y}

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireReplacement TextTherefore, we

    maguireCross-Out

    maguireInserted Text is

    maguireCross-Out

    maguireInserted Texts

    maguireCross-Out

    maguireReplacement Texthave a chat

    maguireHighlightset in bold to emphasize

    maguireInserted Textparticipating

  • As we are going for a P2P solution for the SIP network, it would be logical to go for a P2P solution duringthe actual conference, either with a completely connected network or with a ring-architecture. The problemof a ring architecture is that as we will see later it can take several hundreds milliseconds to go from onenode to another when passing through a number of other nodes, which would cause too much latency duringa speech conversation. A completely connected network would imply many connections established and awaste of resource. Therefore, the conferencing requires a local centralized solution.

    Singh and Schulzrinne propose a good solution in [SS04]. The conferencing nodes should elect a centralnode who will do the mixing, resulting in a star-shaped pattern. Singh and Schulzrinne would go for thenode with the best bandwidth and CPU capacity but that is not enough as it does not address the problemof codecs and that of dynamic conferences with members joining and leaving during the actual conference.The chosen node definitely has to have the largest range of codecs (or at least each other participant shouldhave one codec in common with the central node) and to be the most likely to stay in the conference from thebeginning to the end (probably the instigator of the conference). The node with the largest range of codecsis likely to be a computer (as opposed to a SIP phone or a PDA) and dispose of a larger computationalpower, however a SIP phone might have been designed from scratch to enable conferencing and to act asa mixer. Another issue to keep in mind in this model is the question of privacy, which limits the choice tonodes involved in the conference. The determination of the central node is thus an open problem and theresult will most likely depend on assumptions made on the network usage and users.

    Another solution could be to use multicast but that could lead to flooding the network, at least the partof the overlay network involved in the conference. In that case, all nodes have to do the mixing. Becauseof these two drawbacks this solution cannot apply to conferences with many speakers debating at the sametime. The performances can be improved depending on the properties of the overlay network. For instance,some P2P overlay networks, like Pastry, provide proximity informations that can be used to smarten themulticast.

    2.4 Existing works on P2P/SIP solutions

    2.4.1 Objectives

    From the works of Bryan, Lowekamp and Jennings in [BLJ05] and Kundan Singh and Henning Schulzrinnein [SS04], we came with a precise list of objectives to meet for a good P2P/SIP solution:3

    1. Simple lookup: one issue with P2P systems is the problem of bootstrapping, or more clearly, how tojoin a P2P network without any a priori knowledge about its members, and namely, their addresses?

    2. Privacy: often true when in the communication world, users might want their privacy, maybe byconnecting only to a subnetwork only made up of trusted users.

    3. Mobility: with a wider use of P2P/SIP solutions for VoIP, users are likely to wish for mobility, whetherit is service mobility, personal mobility, session mobility or terminal mobility as defined in [SJ06].

    4. Portability: along with mobility raises the issue of portability: users might want to keep the samesolution working, whether they are using their laptop or their PDA.

    3We do not list here previously acknowledged advantages of P2P systems.

    3

    maguireCross-Out

    maguireReplacement Textlooking

    maguireCross-Out

    maguireReplacement Texta

    maguireCross-Out

    maguireReplacement Textuse

    maguireCross-Out

    maguireReplacement Text,

    maguireInserted Text, is

    maguireCross-Out

    maguireReplacement Textforward traffic

    maguireCross-Out

    maguireReplacement Textto be useful for

    maguireHighlightWhy is there necessarily a waste of resources? You need to say what is being sent, when, and over what paths.

    maguireCross-Out

    maguireHighlightIs this compatible with what we know about multicasting in sparse and dense modes?

    maguireCross-Out

    maguireReplacement Textto

    maguireCross-Out

    maguireReplacement Textnetwork

    maguireCross-Out

    maguireReplacement Textselect

    maguireCross-Out

    maguireReplacement Textmost

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textsufficient

    maguireCross-Out

    maguireReplacement TextCODECs

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textselected conference bridging

    maguireCross-Out

    maguireInserted TextCODECs

    maguireCross-Out

    maguireReplacement TextCODEC

    maguireInserted Textthis node should

    maguireCross-Out

    maguireInserted Texthence it is

    maguireCross-Out

    maguireReplacement TextCODECs

    maguireCross-Out

    maguireReplacement Textit is also likely to have significantly more

    maguireNoteDo you really think that it is likely that lots of different CODECs will be used? Why?

    maguireCross-Out

    maguireReplacement Textof

    maguireCross-Out

    maguireReplacement Textselection

    maguireCross-Out

    maguireReplacement Textchoice

    maguireCross-Out

    maguireReplacement Textabout

    maguireInserted Text,

    maguireHighlightWhy? Doesn't modern multicast avoid flooding?

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textspeaking

    maguireHighlightHow useful is it to mix the audio of more than a small number of simultaneous speakers?

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textsuch as

    maguireInserted Text [x]

    maguireCross-Out

    maguireHighlightCan't the multicast protocols do this themselves?

    maguireInserted Text,

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textdeveloped

    maguireCross-Out

    maguireInserted Textthe

    maguireNoteRather than use numbered paragraphs, it would be better to use a description environment - as it would emphasis the key features.

    maguireCross-Out

    maguireReplacement Textproblem

    maguireCross-Out

    maguireReplacement Textspecifically

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text for their communication

    maguireCross-Out

    maguireReplacement Textperhaps only

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text,

    maguireCross-Out

    maguireInserted Text, there is

    maguireCross-Out

    maguireReplacement Textutilize

    maguireCross-Out

  • 5. Compatibility: SIP products and solutions are already widely spread and it would be confusingand damageable to hinder the communications between P2P and non-P2P SIP products. Moreovercompatibility with former solutions is likely to lead to a larger reuse of existing code-snippets

    6. Easy configuration: which is not dependent of the P2P/SIP choice but must be kept in mind asnowadays people are used to plug and play solutions when it comes to P2P and communications, whichmeans the developer is in charge of the inherent issues of NAT transversal, among others.

    2.4.2 Characteristics of a P2P/SIP solution

    Compatible characteristics

    SIP in itself is not causing many problems for integrating it into a P2P solution. Namely, intermediateservers are optional and the SIP protocol allows user agents (UA) to communicate with each other with noother party involved. This means that the messages inherent at a P2P protocol can be transported in SIPmessages (cf. 2.4.3).

    Modification needs

    Presence Not only should we be aware of what does or does not change inside SIP’s core aspects,but also on services often associated with it, such as presence. The classical presence management overSIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) requires all UA to update theirpresence information on a remote centralized server. A system based on event packages has been proposedin RFC 3265 to deal with presence between nodes, using no external server but this solution might not beimplemented in all existing SIP products and so might not be suitable for all SIP devices and applicationsalready on the market.

    Voicemail Another problematic aspect is that of voicemail when the callee’s machine is not connected(if the callee is connected but not answering her machine can store the resulting file). While voicemail canbe stored, and is actually stored, on the centralized server in most SIP implementations, there is no suchserver in our P2P/SIP model and adding one would break our efforts to bring SIP to a fully P2P modusoperandi. Instead, we have to designate a node, but more likely a set of nodes to improve chances thatthe voicemail message will be available when the node reconnect4, on the overlay network to store the filecontaining the voicemail message. Encrypting the message could guarantee privacy using the callee’s publickey and integrity using the caller’s private key. At this point, we have to further explain DHT to determinewhat node should stock the voicemail file.

    4This problem is close to that of data replication on MANETs, except that all messages eventually need to be stored onlyby their legitimate recipient. Hayashi, Hara and Nishio in [HHN05] give good ideas on the subject.

    4

    maguireCross-Out

    maguireCross-Out

    maguireInserted Texting

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textearlier

    maguireCross-Out

    maguireReplacement Textgreater

    maguireCross-Out

    maguireReplacement Textwhile the issue of configuration is independent

    maguireCross-Out

    maguireReplacement Textchoosing to use

    maguireCross-Out

    maguireInserted Text, it

    maguireCross-Out

    maguireInserted Textother types of

    maguireInserted Textthat

    maguireCross-Out

    maguireReplacement Textmust address the

    maguireCross-Out

    maguireReplacement Textdoes

    maguireCross-Out

    maguireInserted Textwhen

    maguireCross-Out

    maguireReplacement TextAs

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textas

    maguireInserted Textsection

    maguireInserted Text(including those needed for the P2P protocol)

    maguireCross-Out

    maguireReplacement Texts

    maguireCross-Out

    maguireInserted Textwe must

    maguireCross-Out

    maguireReplacement Textexamine

    maguireHighlightNo, there is no requirement that this server be centralized, only that each of the UAs that wants to know about the presence informaition has to know where to subscribe to get it.

    maguireInserted Text [x]

    maguireInserted Text,

    maguireHighlightNot all SIP products implement SIP presence. So the real question is of those that do, how many are compatible with RFC 3265?

    maguireInserted Textproviding

    maguireInserted Text,

    maguireInserted Textsimply

    maguireInserted Text- then

    maguireInserted Textvoicemail

    maguireCross-Out

    maguireReplacement Texta

    maguireCross-Out

    maguireReplacement Textmake

    maguireCross-Out

    maguireInserted Texts

    maguireInserted Text,

    maguireInserted Text(s)

    maguireCross-Out

    maguireReplacement Textstore

  • 2.4.3 SIP using DHT

    Principles of a DHT architecture

    Many implementations of DHT are available, Chord5 and Bamboo6 being the main ones, but they allrely on the same model that we are to explain here. As the name indicates, DHT makes use of a hash function,associating a variable-length string (a SIP AoR in our case) representing one resource of the network (a SIPuser) to a unique fixed-length identifier. To be more precise, a good hash function is one that minimizes risksof collision, therefore the identifier is not unique but has great probabilities to be so. Some P2P networks arehierarchical in that they distinguish super-nodes from regular nodes. Those super-nodes exchange messagesto manage the P2P network and act often like an entry point in the network. Those super-nodes make up asuper-overlay network. They are not fixed, nor do they have to belong to the institution responsible for theP2P network and technology used.

    Every UA being associated with an identifier, all UAs are organized as a ring network, ordered byascending identifiers. This addressed the problem of identification so we now have to face the problem ofdestination lookup. Each node knows the location to its predecessor and successor in the ring. Furthermoreeach node stores the location of a small amount of other nodes, along with their identifiers. That amountis generally O log(n), which tops the lookup time at O log(n) [SS04] (see Figure 2 a). The case ofaudioconferencing narrows the assumptions on the network so we might decide to optimize the choice ofthe nodes, whose locations are stored. Namely, a node can store the locations of a few nodes from theoverlay network and fetch preferentially the location of nodes present in the user’s buddy list.

    A

    B

    Lookup

    A

    M

    a) Example of resource lookup using DHT

    Access

    B

    b) Example of resource lookupwith a single URI associated to several terminals

    Figure 2: Example of resource lookups using DHT5http://pdos.csail.mit.edu/chord/6http://bamboo-dht.org/

    5

    http://pdos.csail.mit.edu/chord/http://bamboo-dht.org/maguireCross-Out

    maguireInserted Texts

    maguireInserted Text,

    maguireCross-Out

    maguireInserted Texte

    maguireCross-Out

    maguireReplacement Textas

    maguireCross-Out

    maguireReplacement Textto

    maguireCross-Out

    maguireReplacement Textis

    maguireCross-Out

    maguireReplacement Texts

    maguireCross-Out

    maguireReplacement Textof

    maguireCross-Out

    maguireReplacement Textnumber

    maguireCross-Out

    maguireReplacement Textreduces

    maguireCross-Out

    maguireReplacement Textdemands

    maguireHighlightspell out on first use

  • This leaves the problem of several devices associated to a single user. This issue is also logically noticedin [SS04], as the choices we made above are similar to those of Singh and Schulzrinne. Here is a suggestionwe make to deal with that issue.

    To locate a node on the network, one needs to know to what value apply the hash function. On onehand, if we consider applying the hash value to the SIP AoR, then how do we know all URIs associated tothat AoR have been alerted? On the other hand, if we decide to apply the hash value to the IP or phonenumber of a particular device, we then need to know it beforehand, which would then make any sort oflookup useless. A solution would be to have all devices associated to the same AoR elect a representing nodeand let the other nodes pick different hashes known by the master node M. This is no longer strict, flatlystructured P2P (see Figure 2 b). Bryan, Lowekamp and Jennings in [BLJ05] propose to use the IP addressas input value for the hash function but in that case we need to maintain a parallel mapping between IPaddresses and AoRs.

    SIP exchanges in the DHT architecture Singh and Schulzrinne in [SS04] develop explanations onappropriate SIP exchanges using their P2P model that we will detail and comment here. We also would liketo remind that the use of a P2P overlay network does not mean that the same SIP client cannot use a SIPonly network based on servers and proxies, especially since it was decided in this model to carry the P2Pmessages using SIP.

    Node Joining For a node to join the network, two phases are to be observed:

    1. Network discovery: to be able to join the network, the node has to find an entry point, quite often thismeans a super-node7. This can be achieved using the Service Location Protocol (SLP) or by flooding thelocal network for super-nodes or nodes that can provide useful information on their location. Otherwise,the cache of the joining node can be used for super-nodes lookup. In the worst case scenario, there canbe a few fixed super-nodes, for instance super-nodes belonging to the protocol’s creators that mightbe used for statistical purposes.

    2. Node registration:8 suppose Alice wants to join the network. She will send:

    REGISTER sip:123.234.1.1:5060 SIP/2.0

    To: [email protected]

    From: [email protected]

    where sip:123.234.1.1:5060 is the address of the super-node Alice is contacting. The super-nodecan now calculate the hash of Alice’s AoR and register the new node in the DHT table. The P2Pnetwork will handle the registration following its own fashion. Namely, the P2P network still has toinform Alice she has been accepted and who and where are her neighbors. Alice is also still lackingthe addresses of the above-mentioned nodes used to reduce the lookup time. All this depends on theP2P network solution chosen. In the case of Chord, informations on successors and predecessors areobtained by looking-up for yourself on the network. This message is also used in [SS04] to make surethat the connection is alive between the node and its supernode.

    7Singh and Schulzrinne consider a Chord network and the use of super-nodes. A regular Chord network is flat and does notinclude super-nodes. This means we have to consider adding a super-Chord network made of super-nodes only as in [JW06] orreplace Chord by another system.

    8We will only discuss the registration of the node on the P2P network here.

    6

    maguireCross-Out

    maguireReplacement Textwith

    maguireCross-Out

    maguireReplacement Textnoted

    maguireCross-Out

    maguireReplacement Textto input to

    maguireCross-Out

    maguireReplacement Texthashing

    maguireInserted Textthat

    maguireCross-Out

    maguireReplacement Textpointless

    maguireCross-Out

    maguireReplacement Textwith

    maguireInserted Textsingle

    maguireInserted Texta

    maguireInserted Text,

    maguireCross-Out

    maguireInserted Textan

    maguireCross-Out

    maguireReplacement Textto

    maguireInserted Text,

    maguireHighlightBut if you have a mapping between AoRs and IP addresses what do you need the DHT for?

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textof

    maguireCross-Out

    maguireReplacement Texton below

    maguireInserted Textthe reader

    maguireCross-Out

    maguireReplacement Textoccur

    maguireInserted Textlooking

    maguireCross-Out

    maguireReplacement Textabout

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textmay

    maguireInserted Text or as last resort seeds for others to build P2P networks

    maguireCross-Out

    maguireReplacement Textin

    maguireCross-Out

    maguireInserted Text are and where they are located

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Texts

    maguireCross-Out

    maguireReplacement Textthese

    maguireInserted Text, which could be

    maguireCross-Out

    maguireReplacement TextThe details of this process

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text is alive

  • More evolved scenarios can be considered when a node is joining the network. For instance, super-nodes may have been designed to split to the task of incoming nodes’ management depending on areas,functionalities or client versions. In that case a REGISTER message might be forwarded betweennodes. Similarly, for one reason or another, a REGISTER message might be received by a node thatis not a super-node (because it has lost this status recently for instance) and in that case again, theREGISTER message might be forwarded. The forwarding may be done by a REFER message. AlanB. Johnston and Henry Sinnreich claims in [JS06] that this solution is not suitable as some existingsolutions might not tolerate the forwarding of REGISTER messages. More generally they are opposedto the transport of P2P message on SIP for reasons of performances (cf. paragraph 2.4.4).

    Node quitting A node quitting abnormally will be detected by the process above, but a node quittingnormally has to unregister from the P2P overlay network. This can be achieved by sending a REGISTERmessage with an expiry time set at zero. However due to their specific roles, super-nodes cannot just leaveon an unregistering message.

    In the specific case of a super-node leaving the network, it has to communicate with its fellow super-nodes on the super-network the information concerning the nodes it was in charge of. This can be achieved bythe mean of REGISTER messages exchanged between the two super-nodes. The authors of [SS04] considerthat nodes will notice the departure of their super-node during the next refresh and then look for the newsuper-node responsible for them.The resulting delay can be avoided if the leaving super-node warns the nodesit is in charge of with a REFER message for instance.

    This question of warning other nodes leads us to discuss the case of node failure. The failure of asuper-node matters especially and in such a case the remaining super-nodes will notice it and redistributeamong themselves the dropped nodes. Once again, the dropped nodes might be notified of the change bythe mean of a REFER message or wait until they realize the change, like in [SS04].

    As we will see later, if some information is to be stored on the network, the failure of any node canbecome a serious issue. When online storage of information is considered, a disconnecting node has to passon its data to other nodes before the actual disconnection to allow the information to remain availableafterwards. This can be a problem and cause a long time between the request for disconnection and theactual disconnection.

    Interaction between two nodes Here comes the aspect that interest the users the most: openingsessions with another node. Just like in non-P2P SIP, it consists of two parts: 1) finding the requested node,2) establishing a session with that node. Once again, using a P2P/SIP solution does not mean that thissolution is isolated from the pure SIP world, for instance, instead of the P2P lookup phase we are going todescribe further down, the node might successfully use a traditional SIP lookup.

    1. Node lookup: The initiating node sends an INVITE message to its super-node that will forward it tothe called party. The super-node might have to act as a proxy in specific cases, for NAT-transversal forinstance. The lookup is done by the super-node using the DHT mechanism. Note that a node mightalso be a super-node and in that case it can issue directly the INVITE message to the called node.

    2. Session: After the lookup is done, the SIP exchange can go on like a normal SIP exchange, eitherincluding the super-node as a proxy or as an end-to-end exchange.

    7

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Texts

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text,

    maguireInserted Text,

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textvia

    maguireCross-Out

    maguireInserted Text,

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textwith simply

    maguireCross-Out

    maguireReplacement Textin

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text,

    maguireInserted Textthey will

    maguireCross-Out

    maguireReplacement Textcan be particularly severe

    maguireCross-Out

    maguireReplacement Textmust

    maguireInserted Texts departure

    maguireCross-Out

    maguireInserted Texts

    maguireCross-Out

    maguireReplacement Textas

    maguireCross-Out

    maguireReplacement Textin

    maguireCross-Out

    maguireHighlightIN what networks does the node actually know in advance that it is going to be disconnected and thus have sufficient time to do all of this cleanup before it is disconnected?

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textbelow

    maguireCross-Out

    maguireReplacement Textsimply

    maguireCross-Out

    maguireInserted Textissue

    maguireCross-Out

    maguireReplacement Textcontinues

  • Voicemail storage As we discussed before, the voicemail message has to be stored as long as the nodeconcerned by the message has not fetched it. The most intuitive way is probably to assign that messageto the super-node that should be in charge of the recipient node. ”Be in charge” can either mean store itand send it to the recipient node when it connects or manage the replication of the message on the overlaynetwork and alert the recipient node it has a message once it is connected. It is possible that at somepoint the super-node disconnects, in that case it has to pass its duty to another super node. Once that themessage has been delivered, the question of the confirmation creates another issue. If the sender is online,an acknowledging message can be sent and if it is not online, a system similar to the one described abovecan be used.

    Device independence and presence Using a P2p network implies a greater facility to connect tothe P2P so it is likely that users might roam and connect from distant places, not having their main devicewith them. Therefore some settings, and especially the contact list, can be stored on the network, just likefor a voicemail message. Once again, privacy and integrity can be achieved by the mean of encryption asnowadays most people are used to entering passwords when they connect to an online service. The mainproblem remains availability in that model as there is no guarantee any replicates of the data will be onlineat any moment, especially if a node has a failure and cannot pass on the information to another node beforedisconnecting.

    Once the issue of contact list retrieval is addressed, fetching presence information can be done directlyby requesting it from the concerned nodes, via the super-node. The super-node could store presenceinformation for all its associated nodes but it is preferable not to add to the burden of super-nodes somethingthat is not of primary priority.

    More on SIP messages In [Bry05], David A. Bryan gives some smart hints on how to use existingheaders and parameters of SIP messages to convey P2P information:

    • Supported/Require: respectively to specify the ability of a node to handle P2P interaction and ifthe current message is of that kind

    • alg:9 to convey information on the hash algorithm used by the DHT

    • user:9 to specify if the message is relative to a user-to-user SIP exchange or to a P2P message overSIP

    Obviously those are just suggestions and P2P/SIP solutions are likely to use them differently even thoughan overall agreement would be an important towards unification, which is the current drawback of allwidespread IM and voice solutions.

    2.4.4 Performances

    Singh and Schulzrinne in [SS05] provide ”performance predictions” using the Chord DHT system basedon the work of Stoica et al. in [SMLN+03] and claims the following:

    • with weak assumptions on the network and the nodes and strong assumptions on the use of thenetwork10, the maximum number of nodes on the network is of 2300,

    9Used inside a To, From or Contact header1010 requests per second per node, one call per minute per node

    8

    maguireHighlightIn which case it has to pass all of the voice messages which it is storing!

    maguireCross-Out

    maguireReplacement TextP"P

    maguireInserted Text network

    maguireInserted Textuser's

    maguireCross-Out

    maguireInserted Text, just as today

    maguireCross-Out

    maguireInserted Textthat

    maguireCross-Out

    maguireReplacement Textfailed

    maguireCross-Out

    maguireReplacement Textcould not

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textavoid adding

    maguireCross-Out

    maguireReplacement Textimportance

    maguireInserted Text,

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text (~1010)

  • • considering a network of 10,000 nodes using chord, six hops is the mean lookup path length, takingapproximately 200 ms.

    This latter assumption of 10,000 nodes is pretty weak compared to a network like Skype with 8 millionusers online [Sky07]. Based on the results found in [SMLN+03], such a network would require a mean lookuppath length of 10 hops, or approximately 350 ms. Compared with the actual values observed on the Skypenetwork (three to eight seconds according to Baset and Schulzrinne in [BS04]), this probably means theassumptions made are not realistic for such a wide network. With optimization those values could be lowered,especially considering the large bandwidth of current networks, one hop lookup is conceivable [GLR03] andeven if not all nodes11 do not have that capacity, the delay would still be greatly reduced. In any case, thelatency in a P2P network is longer than that of a classic centralized network.

    2.5 Alternatives

    Alternatives in the domain of P2P/SIP The different papers studied above list several alternativesto P2P/SIP, each with their drawbacks and advantages. Other solutions have been designed that were notdiscussed above:

    • Damaka12 is offering a P2P/SIP client as a non-open source software.

    • In [SBC06], Stiemerling, Brunner and Cassini discuss the use of Service-Aware Transport Overlay(SATO), a technology relative to ambient networks defining another way to handle overlay networksand DHTs.

    Alternatives to P2P/SIP Other projects exists that do not use SIP, or P2P or non of them, but thatcan still be applied for an audio conferencing solution:

    • Skype, which is a commercial, proprietary, non-disclosed solution but widely in use. The model isnot strictly P2P and includes central servers for authentication and charging. Skype also adds IMsupport and NAT transversal functionalities and more generally enjoys a larger support thanks to itscommercial nature.

    • vop2p, a currently inactive project, based on JXTA, a Java-based P2P technology which is howeverlisted as inactive on the JXTA projects’ list13. Such a project could have been promising as JXTAprovides service discovery functionalities, among others.

    • Solutions using a Dynamic DNS are also considered as a solution mixing the P2P and server-basedapproaches. The use of a REGISTER message can then be avoided by the using of Dynamic DNS toresolve SIP URIs. Another solution is to have servers joining and leaving dynamically and still use theDynamic DNS resolving to access them.

    11Namely mobile devices might not have all 384 kbps (in the case of a network with 106 nodes) of bandwidth to give away.12We contacted Damaka to have further information on their system but they did not reply.13http://vop2p.jxta.org/

    9

    http://vop2p.jxta.org/maguireCross-Out

    maguireReplacement Textlarge

    maguireCross-Out

    maguireReplacement Texthigh

    maguireInserted TextSIP

    maguireInserted Text/SIP

    maguireInserted Textown

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textproprietary

    maguireCross-Out

    maguireReplacement Textrelated to

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textwhich defines

    maguireCross-Out

    maguireReplacement Textfor

    maguireInserted Text,

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text,

    maguireInserted Textis

    maguireCross-Out

    maguireInserted Textd

    maguireCross-Out

    maguireReplacement Textas it

    maguireCross-Out

    maguireCross-Out

    maguireInserted Textconsiderable

    maguireCross-Out

    maguireInserted Textalso

    maguireCross-Out

    maguireReplacement Text's

    maguireNoteSee also the report: ftp://ftp.it.kth.se/Reports/DEGREE-PROJECT-REPORTS/030211-Gustav_Soderstrom.pdf

    maguireCross-Out

    maguireReplacement Textto be

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Text, but

    maguireCross-Out

    maguireHighlightThere is also the problems of who is going to pay for all of this traffic across the mobile network and the related problem of this cost versus the cost of some centralized servers!

  • 2.6 Other aspects of a P2P solution

    The use of P2P in SIP solutions sharpens some pre-existing problems that are that of security and privacy, ofNAT transversal and QoS. When non-trusted machines are involved, users get worried about their personalinformations. Finally, a larger public often means more chances to encounter NAT on the path of the messageand also means great constraints in term of quality of service, or at least a sufficient quality/price ratio. Thislatter issue is addressed in [Vio07] and the security issue is addressed in [Mac07].

    3 Conclusion

    Many solutions are actually studied to implement SIP communication on a P2P network. Some like theone we presented here send P2P-related messages using SIP, some do not. We also tried to discuss some issuesthat were not, or not sufficiently, discussed by Singh and Schulrzinne in [SS04] on which we based our report.The darkest spot for the future of P2P/SIP solutions seem to be the availability of some information, suchas contact list and voicemail messages, inherent to pure P2P systems. One solution could be to have hybridssystems using private nodes and super-nodes but including a few servers ran by the company promoting thesolution, or possibly some service providers. Nevertheless we feel confident that a P2P/SIP solution for voiceand audio conferencing is not impossible to deploy at a large scale and for a common public use.

    10

    maguireCross-Out

    maguireInserted Textrelated to

    maguireInserted Text,

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textbecome

    maguireCross-Out

    maguireInserted Text(and should worry)

    maguireInserted Texter

    maguireInserted Texts

    maguireInserted Textquestion of being able to achieve a

    maguireCross-Out

    maguireReplacement Textwere

    maguireCross-Out

    maguireReplacement Textother important

    maguireInserted Textthe user's

    maguireCross-Out

    maguireReplacement Textw

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textrun

    maguireCross-Out

    maguireReplacement Texta

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Texton

  • References

    [BL07] David A. Bryan and Bruce B. Lowekamp. Decentralizing sip. ACM Queue, March 2007.

    [BLJ05] David A. Bryan, Bruce B. Lowekamp, and Cullen Jennings. SOSIMPLE: A serverless, standards-based, P2P SIP communication system. Technical report, College of William and MaryWilliamsburg, Vancouver, 2005.

    [Bry05] David A. Bryan. Peer-to-peer SIP. 2005.

    [BS04] Salman A. Baset and Henning Schulzrinne. An analysis of the Skype peer-to-peer internettelephony protocol. Technical report, Columbia University, September 2004.

    [GLR03] Anjali Gupta, Barbara Liskov, and Rodrigo Rodrigues. One hop lookups for peer-to-peeroverlays. Technical report, MIT, 2003.

    [HHN05] Hideki Hayashi, Takahiro Hara, and Shojiro Nishio. A replica allocation method adapting totopology changes in ad hoc networks. Technical report, Osaka University, 2005.

    [JS06] Alan B. Johnston and Henry Sinnreich. SIP, P2P, and Internet Communications. Technicalreport, IETF, SIPPING Working Group, 2006.

    [JW06] Yuh-Jzer Joung and Jiaw-Chang Wang. Chord2: A two-layer Chord for reducing maintenanceoverhead via heterogeneity. Technical report, National Taiwan University, 2006.

    [Mac07] Luca Maccari. Peer-to-peer audio conferencing using SIP: Security issues. Technical report,Kungliga Tekniska Högskolan, 2007.

    [MKL+04] Dejan S. Milojicic, Vana Kalogeraki, Rajan Lukose, Kiran Nagaraja, Jim Pruyne, BrunoRichard, Sami Rollins, and Zhichen Xu. Peer-to-peer computing. Technical report, HP, 2004.

    [San05] Sandvine. EDonkey - still king of P2P in France and Germany. Technical report, Sandvine,2005.

    [SBC06] M. Stiemerling, M. Brunner, and M. Cassini. Peer-to-peer SIP Implementation Report.Technical report, IETF, P2PSIP, 2006.

    [SJ06] Henry Sinnreich and Alan B. Johnston. Internet Communications Using SIP - Delivering VoIPand Multimedia Services with Session Initiation Protocol. Wiley, 2006.

    [Sky07] Skype. Skype statistics. http://share.skype.com/stats_rss.xml, 2007.

    [SMLN+03] Ion Stoica, Robert Morris, David Liben-Nowell, David R. Karger, M. Frans Kaashoek, FrankDabek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup protocol for internetapplications. Technical report, IEEE, February 2003.

    [SS04] Kundan Singh and Henning Schulzrinne. Peer-to-peer internet telephony using SIP. Technicalreport, Columbia University, 2004.

    [SS05] Kundan Singh and Henning Schulzrinne. Peer-to-peer internet telephony using SIP. Technicalreport, Columbia University, 2005.

    [Vio07] Gabriele Violino. Peer-to-peer audio conferencing using SIP: QoS issues. Technical report,Kungliga Tekniska Högskolan, 2007.

    11

    http://share.skype.com/stats_rss.xmlmaguireNoteYou should put all the references together in a single reference section at the end of the report. In addition, you should all three have used the same style of citing these references!

    maguireNoteWhen, where, who was the publisher?

  • Peer-to-Peer audio conferencing using SIP:

    QoS issues

    Gabriele Violino

    May 10, 2007

    Abstract

    This report is part of a collection of three reports describing several aspects of Peer-to-Peer audio conferencing using SIP: security, Quality of Service and P2P architecture. This particular report will focus on possible QoS issues in an audio conferencing solutions.

    maguireCross-Out

    maguireReplacement TextS

    maguireInserted Text,

  • QoS in audio conferencing

    What is QoS? How can it be evaluated? QoS is a delicate matter: for years it has been misused in commercials for ISP or VoIP companies. In fact there is no formal definition of QoS: in 1994 IETF in [2] tried for the first time to define QoS inside integrated services. According to this document many years ago (10 circa), there was no QoS at all, internet was just a best effort network that means no more than a network based on IP packets could offer. It is easy to understand why 10 years ago there was no support for QoS: there was no need of it because internet at that time was not used to carry multimedia data. But QoS originally was not born to fit quality requirements such as for audio and video streams. Originally the ISPs needed to distinguish different classes of service to accomplish the quality requirements (mostly bandwidth) inside the agreements with the users. That is a general problem also nowadays, that means that if a user pays more, it will be offered to him a better QoS (e.g. guaranteed minimum bandwidth, low probability to be out of service, etc..). The kinds of applications that the end-user utilizes can be very heterogeneous: there are some applications like web browser, FTP, mail client, etc.. that can adapt to situations, that means if a resource in the network is temporally unavailable they can wait so they are flexible, other applications need always a minimum amount of resources to work properly, otherwise the user will experience an unacceptable service. Thus it seems clear that there should be a way to distinguish between different kinds of packets within a network.

    Audio and voice quality criteria and parameters

    During the last past years several techniques have been proved to be efficient in improving the quality in packeted audio. However when one deals with voice (or audio in general) it is difficult to define some objective parameters to evaluate the audio quality. In [19] there are three different definitions of QoS that are interesting for clarify a term that has a use that is often abused:

    1. Preferential QoS (classes of service)2. Intrinsic QoS (latency, jitter, dropped packet rate)3. Perceived QoS (QoS perceived by the end user)

    I would say that the most important one is the (3) and for it to be improved, both (1) and (2) have to be improved. (1) and (2) can be easily established/measured because are objective parameters. The third highly depends on the user: when the user likes the sound that means that the quality is good, when the user dislikes it then the quality is bad so this is clearly a subjective parameter. How to measure a subjective parameter? The only feasible way seems to be statistical methods based on observations: if in repeated experiments has been observed that the users like that sound, that

    maguireNoteYou should use a serif font for the body of the report, as it is much easier to read large amounts of text in such a font face.

    maguireNotepages should be numbered in the same style as the earlier sections of the report.

    maguireNoteUse section and subsection numbers, as it is easier to introduce cross references to the report.

    maguireCross-Out

    maguireHighlightFalse the network has been carrying multimedia data for far longer than this - even before it was called internet and before the IP protocols.

    maguireCross-Out

    maguireReplacement Textdesigned to specify

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textmeet

    maguireInserted Textwith respect to

    maguireCross-Out

    maguireReplacement Textof

    maguireCross-Out

    maguireReplacement Texttheir

    maguireCross-Out

    maguireReplacement Texttheir

    maguireCross-Out

    maguireInserted Text, even today,

    maguireCross-Out

    maguireReplacement TextThere

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textthe user should

    maguireCross-Out

    maguireInserted Texta certain

    maguireCross-Out

    maguireInserted Text outage,

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textsuch as

    maguireCross-Out

    maguireInserted Texting

    maguireCross-Out

    maguireReplacement Textthe network's current conditions

    maguireCross-Out

    maguireInserted Textwhile

    maguireCross-Out

    maguireInserted Text need

    maguireInserted Textcertain

    maguireCross-Out

    maguireInserted Text or that the network must provide sufficient resources that contention for resources is never a problem

    maguireCross-Out

    maguireReplacement Textseveral

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textof

    maguireCross-Out

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textthe meaning of a

    maguireCross-Out

    maguireInserted Textbeen

    maguireCross-Out

    maguireReplacement Textthird

    maguireCross-Out

    maguireReplacement Textthe first and second

    maguireCross-Out

    maguireReplacement Textaddressed

    maguireCross-Out

    maguireReplacement TextThe second

    maguireCross-Out

    maguireReplacement Textit is

    maguireCross-Out

    maguireReplacement Textthe

  • means that, with high probability, that sound has high quality. Nowadays the most rated method to measure the user perception of voice is called MOS (Mean Opinion Scores). There are some sessions where some persons are invited to participate and listen to audio traces. Every person can evaluate the sound on a scale from 0 to 4 with the following description: unsatisfactory/bad, poor, fair, good, excellent. When all the people have expressed their opinion then all the values are collected and averaged, the average will be the rounded and the final result will be expressed as an integer [0-4] (or [1-5] with the ITU convention). An other subjective test that can be performed is the PSQM (Perceptual Speech Quality Measure) it has been made by ITU-T to measure the quality of speech codecs. MOS tests are performed in “laboratory conditions” that means no background noise: in the every day life there is always a background noise and this is what PSQM tries to emulate during the tests: results of the experiments with and without noise are then compared. PAMS (Perceptual Analysis Measurement System) is a method that performs calculations on the spectrum (also PSQM does that) of the audio signal with some sophisticated waveforms (ASTS) and also gives some additional information about the effort (to understand the meaning of the speech) made by the user listening to the audio signal. In addition, in PAMS, there are some attempts to take in consideration also the jitter so that the original signals and signals with variable delay are compared. PESQ (Perceptual Evaluation of Speech Quality) instead is a more objective criterion born to be applicable in the “real world” in end-to-end communications in VoIP, GSM, POTS (Plain Old Telephone Service), ISDN, etc... Other useful methods for VoIP qualitative measurements are PSQM+, ITU-T´s P.563 (non-intrusive voice quality testing), psyVoIP2 by Psytechnics and “E-model” by ITU for passive monitoring.

    P2P bottlenecks

    As we have defined nodes and super nodes in our P2P scenario for voice conferencing the super nodes should be connected with high bandwidth links and have much more computational power than regular nodes. However if one of this super nodes is performing an action, say sending a big packet with priority x, and then a small packet containing some voice samples with priority x+1 has to be delivered to n nodes then what happens? Should the transmission of the lower priority packet be preempted to let the voice packet be delivered with an acceptable delay? This is a general problem and does not affect only the case of P2P communications: every time a node (router) should decide which packet deliver (schedule) problems such as head of the line blocking and all the other queuing problems occur. In the case of P2P communications these problems can be much worse since usually regular PC/workstations cannot send and transmit more than one packet per unit of time (this is due to the limited number of interfaces that usually is 1). Figure (1) can highlight some of the problems that can occur.

    maguireCross-Out

    maguireReplacement Textcommon

    maguireHighlightspell out first and then abbreviate

    maguireCross-Out

    maguireReplacement TextThese scores are determine by using

    maguireCross-Out

    maguireReplacement Textrecordings

    maguireCross-Out

    maguireReplacement Textinterpretations

    maguireCross-Out

    maguireReplacement Textdefined

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textas

    maguireCross-Out

    maguireCross-Out

    maguireInserted Textto

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textdesigned

    maguireCross-Out

    maguireReplacement Textfor

    maguireCross-Out

    maguireInserted Text,

    maguireNoteThese methods should probably each have references or you should indicate where the reader can learn more about them.

    maguireCross-Out

    maguireReplacement Textutilize

    maguireInserted Text;

    maguireInserted Text,

    maguireHighlightWhich networks allow preemption in the middle of a frame? Shouldn't you be talking about objects instead of simply packets?

    maguireCross-Out

    maguireReplacement Textmust

    maguireInserted Textto

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textbeing one

    maguireCross-Out

    maguireReplacement Text1

    maguireInserted Text

    maguireInserted Texts

    maguireNoteIs it really better for routers? Since most usually only have a single route for a given destination.

    maguireNoteIs there really a problem if the link is high speed, since the waiting time for the large packet is then going to be very small? Since super nodes are likely to be attach to very high speed (more than 10Mbps) links the delay will be very small.

    So this does not seem like a significant issue.

  • Figure 1. Possible bottleneck in router: if the router is forwarding big IP packets from WAN2 to WAN then VoIP packet with source address node 1 and destination address node 2 may be delayed (even if the VoIP packet has higher priority).

    Figure 2.

    How to achieve QoS

    In this section I will analyse the possible solutions to the problem of granting a certain level of QoS:● Over provisioning● TOS field inside IP packet● Intserv● Diffserv● RSVP● Future evolution

    Over provisioning

    Over provisioning is the simplest method to provide high QoS. Over provisioning is typical in circuit switching solutions (e.g. classical telephony where 1 call = 1 link). As it is shown in Figure 2, there is always a trade-off between the quality (wanted by the user) and hight utilization-efficiency (wanted by the service provider). In an ideal world there are enough resources to fulfil all the requests of all the users at the same time however, since the service providers want to minimize

    node1 node

    supernode

    WAN

    node node2

    supernode

    router

    WAN2

    Quality

    High utilization

    Service provider

    User

    maguireCross-Out

    maguireReplacement TextThis

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textpotential

    maguireCross-Out

    maguireReplacement Textguaranteeing

    maguireCross-Out

    maguireInserted Text;

  • the cost of the service, they tend to “overbook” links since it is not supposed that all the users need the service at the same time: this fact leads to unpredictable behaviour of the data flows that are not any more deterministic and become dependent to stochastic models! Thus the question is how much should we do over provisioning? According to [3] it seems that doing over provisioning equal to the double of the maximum possible load on the aggregate band in the backbone areas is enough to guarantee low delay, jitter and loss. Many times this is the only type of optimization possible for low delay since, if we don´t know the queuing policies in every router of the network the only possibility is to raise the capacity of the backbone so that, since there will not be a high load in the queues, the queues will be almost empty and then there will be no risk of starvation for the packets.

    TOS field inside IP packet

    Figure 3. IP header. Source: [4]

    TOS is a 8-bits field in IP packet - see Figure (3). As defined in the original RFC [4], TOS should “provides an indication of the abstract parameters of the quality of service desired”. So this should allow to mark an IP packet with a desired priority: the source could choose to minimize the delay, maximize the throughput or maximize the reliability. Of course the major problem in real time systems such audio conferencing is the delay: in fact if the delay is greater than a certain threshold it is equivalent to a lost packet. Unfortunately not a lot of service providers and router manufacturers have implemented in their systems a way to treat packets with different TOS codes in different manners: this causes the packet to be treated in different ways in the path from the source to the destination and so the QoS cannot be guaranteed. Nowadays TOS is either ignored,

    0 1 2 3 4 5 6 7 | reservedTOS FIELD

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textsufficient

    maguireInserted Text,

    maguireInserted Text,

    maguireCross-Out

    maguireHighlightWhat is this?

    maguireNoteWhy not draw your own figure?

    maguireCross-Out

    maguireInserted Textoriginally

    maguireCross-Out

    maguireInserted Texta sender

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textfew

    maguireCross-Out

    maguireInserted Text, i.e.,

    maguireCross-Out

    maguireReplacement Textalong

    maguireCross-Out

    maguireInserted Text, thus

    maguireInserted Text,

  • used for explicit congestion notification [5] or to store DiffServ code point (see next paragraphs).

    Intserv

    Intserv, as specified in [6] allow the source to specify different QoS parameters for each data flow: the routers in the networks reserve resources for each flow, each call (or session) is started by signalling so that each application in the source node opens a session that can eventually be refused by the destination node. The data flow is characterized by a “T-spec” array and the desired QoS by a “R-spec” array for each flow. Unfortunately, due to scalability problems, Intserv solution fits only small LAN and not WAN such internet; this is the reason why nowadays it is not very used.

    Diffserv

    Diffserv allows different kinds of over provisioning on different classes of service. In [13] are defined some provisioning classes and different policy domains (so that it is possible to specify different policies in different domains). With Diffserv it is possible to do packet classification, traffic shaping, marking the packets using the field TOS (see Figure 3) with DSCP (Differentiated Services Code Point), doing CAC (Connection Admission Control) and traffic dropping and classification of the traffic in queues with different priorities. Special tables called PIB (Policy Information Base) are sent over the network to the nodes that perform QoS controls. In [14] a comparison between DiffServ and IntServ is made, nowadays DiffServ is much more used than IntServ however IntServ can be used inside a LAN so the typical scenario is LAN with IntServ connected to WAN with DiffServ.

    RSVP

    RSVP stands for Resource reSerVation Protocol [15]. This protocol is designed for both unicast and multicast traffic, it allows to book resources on the path on which the data is being transferred. In addition it is possible to send requests with QoS requirements to the nodes on that path: each node try to reserve a much resources as are needed to satisfy the QoS requirements. RSVP does no routing, however, given many routing possibilities it can decide which packets, according to the priorities and groups, should be on the same path. The packets are classified by a packet classifier and then sent to the packet scheduler that will send the packets on a path or another according to the type of the packet (class). A RSVP process continuously exchanges informations with the scheduler, the routing process and the policy control.

    maguireInserted Text,

    maguireInserted Texta

    maguireInserted Texts

    maguireCross-Out

    maguireInserted Textsome node along the path to

    maguireCross-Out

    maguireInserted Texts

    maguireInserted Texts

    maguireCross-Out

    maguireReplacement Textthus

    maguireCross-Out

    maguireInserted Text much in practice

    maguireCross-Out

    maguireReplacement Textfor the

    maguireInserted Textsome provisioning classes

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textalong with

    maguireInserted Text,

    maguireInserted Text function

    maguireCross-Out

    maguireInserted Textused

    maguireInserted Text;

    maguireInserted Text a

    maguireCross-Out

    maguireReplacement Textwhich uses

    maguireNoteBut is there really a resource problem within the LAN?

    maguireCross-Out

    maguireInserted Texting of

    maguireCross-Out

    maguireReplacement Textalong

    maguireCross-Out

    maguireReplacement Textto be

    maguireCross-Out

    maguireReplacement Texttries

    maguireCross-Out

    maguireReplacement Textthe

    maguireCross-Out

    maguireReplacement Textwhich

  • Future evolution

    Since the QoS is a quite new research field it can be interesting to take a look to the possible future evolution of the technology. To do that it can be interesting to see what are the practical solutions that are provided by companies around the world. One interesting solution is that provided by Sprint in [16]: Virtual Private Network and MPLS to provide guaranteed QoS to business customers. For sure not all the users are supposed to support the cost of a VPN just because they want to make audio conferencing but it can be interesting for big companies that need to have worldwide communications among employees and need to be sure that those communications will, with high probability, never be interrupted or having very bad quality. Traffic in the backbone is divided in classes of service with different priorities (and fees), this leads also to a different queuing policies insides the nodes resulting to a deterministic maximum end to end delay known a priori! These characteristics are fundamental when one has to deal with real time applications such voice conferencing. It is also interesting to note that there is a direct level-3 (IP) support to multicasting and some performance guarantees like: “Packet Loss performance metric: 0.1% or less globally” or “Jitter performance metric: 2 ms or less globally”. VPNs can also add end-to-end security to the network, for related security issues see [21].

    SDP

    Session Description Protocol [12] is often used to format SIP session descriptions, in addition it can be used by RTSP during a media streaming and for multicasting announcements.STP session descriptions may (it is recommended) include some informations about the available bandwidth to be used by the session, the transport protocol (RTP, UDP...), the type and the format of media for the session.

    RTP and RTCP [8][9]

    RTP is an application level protocol born to efficiently transfer multimedia data. After P2P-SIP has performed the resolution of addresses, negotiated the compression type and codec, then multimedia data is transferred end to end. Both UDP and TCP are not suitable to transfer multimedia data since: UDP is fast but does not guarantee anything in terms of data loss recovery, jitter and packets´s sequence, TCP is reliable but slow because of delays in case of loss (retransmissions) and congestion control can cause variations in the available bandwidth. These are the motivations for a new transport protocol: Real Time Protocol. RTP is designed for

    maguireCross-Out

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textmay

    maguireCross-Out

    maguireReplacement Textat the potential

    maguireCross-Out

    maguireReplacement TextQoS

    maguireCross-Out

    maguireReplacement Textdescribed

    maguireCross-Out

    maguireReplacement TextWhile

    maguireCross-Out

    maguireReplacement Textexpected

    maguireCross-Out

    maguireReplacement Textpay for

    maguireCross-Out

    maguireReplacement Textconduct

    maguireInserted Text,

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textmay

    maguireCross-Out

    maguireInserted Texthave

    maguireInserted Textto different

    maguireCross-Out

    maguireReplacement Textuse of

    maguireCross-Out

    maguireReplacement Textin

    maguireCross-Out

    maguireReplacement Textend-to-end

    maguireCross-Out

    maguireCross-Out

    maguireReplacement Textnetwork layer

    maguireCross-Out

    maguireReplacement Textfor

    maguireCross-Out

    maguireReplacement Textsuch as

    maguireNoteTry to avoid single sentence paragraphs.

    maguireInserted Text,

    maguireCross-Out

    maguireInserted TextTCP, SCTP,

    maguireCross-Out

    maguireReplacement Textdesigned

    maguireNoteMere with previous paragraph to avoid the single sentence paragraph.

    maguireCross-Out

    maguireReplacement Text (if any)

    maguireCross-Out

    maguireReplacement TextCODEC

    maguireHighlightThese are transport layer protocols, which RTP and others can use.

    maguireCross-Out

    maguireReplacement Textwas

  • interactive audio/video so theoretically fits at 100% the audio conferencing problem. Unfortunately it does not directly support QoS so, again we don´t know a priori the QoS that a conference will have. However practically it seems to work quite well and that is why nowadays is the most used protocol to carry real time multimedia data. RTCP is a protocol that works together with RTP: with RTCP the destination of a multimedia flow periodically sends feedback informations to the source to report the quality of the multimedia flow. RTP has been designed for many purposes, one of them is simple multicast audio conference, in this case RTP headers contain informations about the audio codec (PCM, ADPCM, CELP...) and the codec can be changed at any time since eventually each packet can specify a different codec so that new users can join the discussion at any moment and the source can accommodate them by simply switching the codec in the packet header. RTP packets contain also a timestamp so that if the destination receive packets in the wrong order they can be sorted and then processed. However if a packet is delayed too much (parameters like these are freely configurable by the programmer) that packet should be discarded and the processing of the other packets should go on. RTP does not support directly multicast, so if the network does not support multicast, a unicast connection should be established for each pair of peers and then this solution could not scale if there are too many peers since too many connections on the same host means bandwidth division (theoretically by the number of peers) and also not enough computational power.

    SIP and QoS

    According to [1], during the SIP session setup, the INVITE message let the destination pick the audio protocol within a set of specified audio/video codecs. However this it the typical behaviour of the re-invitation message since the first invitation message (sent before the re-invitation) has the purpose of establish a best effort session. To do that the TOS field inside IP header is set to best effort = |000000|. Even SIP is media-independent a SIP session establishment can fail because of lack of resources (usually bandwidth). Generally SDP is used to avoid that a call is established if there are not enough resources to perform the call. Since when one deals with P2P communications she does not know a priori how big is the latency and the capacity of the channels among nodes, it could be very useful to compress SIP messages applying signalling compression (SigComp) as specified in [17]. This technique of compressing SIP messages has proven in [18] to be essential when one deals with the radio channel (high latency) and has to be taken in consideration to avoid high delays caused by a portion of peers to be connected via radio.SIP protocol (RFC [7]) does not specify explicitly which protocol to use for QoS support. However Iit does exist a “warning field”, inside the header of the response messages that can contain important information about the protocol used to grant QoS. These warning messages contain a code, a human readable message (explaining the reason of the warning) and the host name. I will

    maguireCross-Out

    maguireReplacement Textit is suitable for carrying the audio traffc for

    maguireCross-Out

    maguireInserted Text,

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement TextCODEC

    maguireCross-Out

    maguireReplacement TextCODEC

    maguireCross-Out

    maguireCross-Out

    maguireReplacement TextCODEC

    maguireCross-Out

    maguireReplacement TextCODEC

    maguireCross-Out

    maguireInserted Textcontain

    maguireInserted Texts

    maguireHighlightNo, the destination can use the sequence number for this!

    maguireInserted Text,

    maguireCross-Out

    maguireInserted Textdirectly

    maguireCross-Out

    maguireInserted Text, but

    maguireCross-Out

    maguireInserted Textcan

    maguireInserted Text,

    maguireCross-Out

    maguireReplacement Textto

    maguireCross-Out

    maguireReplacement Text will divide up the

    maguireCross-Out

    maguireHighlightWhy? Not all are active at the same time.

    maguireInserted Texts

    maguireInserted Textfrom

    maguireCross-Out

    maguireReplacement TextCODECs

    maguireInserted Text,

    maguireHighlightIs this really true?

    maguireCross-Out

    maguireReplacement Textestablishing a call

    maguireCross-Out

    maguireReplacement Textthe user agent

    maguireCross-Out

    maguireReplacement Textgreat

    maguireInserted Textis nor

    maguireCross-Out

    maguireInserted Texthence

    maguireInserted Textby

    maguireInserted Textbeen

    maguireInserted Textto

    maguireInserted Text,

  • not describe in detail all the warning codes and relatives messages but it is interesting to analyse the warning codes in the range [370,379] since they are related to the quantitative parameters of QoS requested in the session description. Messages are reported in figure 3.

    370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media exceeds that known to be available.

    Figure 3. warning messages It can be noticed that there is only one warning message: this means that most of the QoS management is demanded to the protocols SIP is supposed to work with, according to the RFC: RTP [8] and RTCP [9], RTSP [10], MEGACO (now Gateway Control Protocol Version 1) [11] and SDP [12].

    Conclusion

    It seems that nowadays the QoS in general is still largely dependant on the low level layers and the contract agreements with the service providers. However for big companies it is not difficult to build up entire audio conferencing infrastructures that uses the Session Initiation Protocol since they often own big LANs or afford the cost for VPN or dedicated infrastructures. Due to the heterogeneous and unpredictable speeds and computational capacity in the nodes, it seems unlikely to see in the future systems with guaranteed QoS built on plain P2P systems but, instead on hierarchical sets of P2P sub-systems.

    References

    [1] Henry Sinnreich and Alan B. Johnston. Internet Communications Using SIP - Delivering VoIP and Multimedia Services with Session Initiation Protocol. Wiley, 2006.[2] RFC 1633 - Integrated Services in the Internet Architecture: an Overview. IETF, 1994. http://www.ietf.org/rfc/rfc1633.txt[3] Tim Szigeti and Christina Hattingh. End-to-End QoS Network Design. Cisco Press. November 09, 2004 ISBN : 1-58705-176-1. 768 pages[4] RFC 0791 – Internet Protocol: protcol specification. IETF, 1981. http://www.ietf.org/rfc/rfc0791.txt[5] RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP. IETF, September 2001. http://www.ietf.org/rfc/rfc3168.txt[6] RFC 2115 - General Characterization Parameters for Integrated Service Network Elements. IETF, 1997. http://www.ietf.org/rfc/rfc2215.txt[7] RFC 3261 - SIP: Session Initiation Protocol. IETF, June 2002. http://www.ietf.org/rfc/rfc3261.txt

    http://www.ietf.org/rfc/rfc1633.txthttp://www.ietf.org/rfc/rfc3261.txthttp://www.ietf.org/rfc/rfc3261.txthttp://www.ietf.org/rfc/rfc3261.txthttp://www.ietf.org/rfc/rfc2215.txthttp://www.ietf.org/rfc/rfc2215.txthttp://www.ietf.org/rfc/rfc2215.txthttp://www.ietf.org/rfc/rfc3168.txthttp://www.ietf.org/rfc/rfc3168.txthttp://www.ietf.org/rfc/rfc3168.txthttp://www.ietf.org/rfc/rfc0791.txthttp://www.ietf.org/rfc/rfc0791.txthttp://www.ietf.org/rfc/rfc0791.txthttp://www.ietf.org/rfc/rfc1633.txthttp://www.ietf.org/rfc/rfc1633.txtmaguireCross-Out

    maguireReplacement TextA sample of such a message is shown

    maguireCross-Out

    maguireReplacement Textoccurs with

    maguireCross-Out

    maguireReplacement Textthat

    maguireInserted Text,

    maguireInserted Textan

    maguireCross-Out

    maguireReplacement Textsuch companies

    maguireInserted Textcan

  • [8] RFC 3550 - RTP: A Transport Protocol for Real-Time Applications. IETF, July 2003. http://www.ietf.org/rfc/rfc3550.txt[9] RFC 3550 - RTPCP: RTP Control Protocol. IETF, July 2003. http://www.ietf.org/rfc/rfc3550.txt[10] RFC 2326 - Real Time Streaming Protocol (RTSP). IETF, 1998. http://www.ietf.org/rfc/rfc2326.txt[11] RFC 3525 - Gateway Control Protocol Version 1. IETF, June 2003. http://www.ietf.org/rfc/rfc3525.txt[12] RFC 4566 - SDP: Session Description Protocol. IETF, July 2006. http://www.ietf.org/rfc/rfc4566.txt[13] RFC 3317 - Differentiated Services Quality of Service Policy Information Base. IETF, March 2003. http://www.ietf.org/rfc/rfc3317.txt[14] Harju, J.; Kivimaki, P. - Co-operation and comparison of DiffServ and IntServ: performance measurements. IEEE. Digital Object Identifier 10.1109/LCN.2000.891025[15] RFC 2205 - Resource ReSerVation Protocol (RSVP). IETF, 1997. http://www.ietf.org/rfc/rfc2205.txt[16] Sprint MPLS VPN. IP Whitepaper. January 2005http://www.sprintworldwide.com/english/contact/MPLS_VPN_WP.pdf[17] Draft. IETF. Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP). March 2007. http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-05.txt[18] Research paper. Performance Analysis of SigComp for 3G Cellular Networks. W. Han, K.-j. Lee, H.-h. Park, K.-g. Lee, and J. Jang. http://www.actapress.com/PaperInfo.aspx?PaperID=30368[19] William C. Hardy. VoIP Service Quality: Measuring and Evaluating Packet-Switched Voice. McGraw-Hill. 2003.[20] Max Welz. Peer-to-Peer audio conferencing using SIP: P2P Architecture. Technical report, Kungliga Tekniska Högskolan, 2007.[21] Luca Maccari. Peer-to-Peer audio conferencing using SIP: Security issues. Technical report, Kungliga Tekniska Högskolan, 2007.

    FiguresAll figures/graphics have been realized with open source tools such as Dia and OpenOffice:http://www.gnome.org/projects/dia/ http://www.openoffice.org

    http://www.openoffice.org/http://www.openoffice.org/http://www.openoffice.org/http://www.gnome.org/projects/dia/http://www.gnome.org/projects/dia/http://www.gnome.org/projects/dia/http://www.actapress.com/PaperInfo.aspx?PaperID=30368http://www.actapress.com/PaperInfo.aspx?PaperID=30368http://www.actapress.com/PaperInfo.aspx?PaperID=30368http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-05.txthttp://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-05.txthttp://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-05.txthttp://www.sprintworldwide.com/english/contact/MPLS_VPN_WP.pdfhttp://www.ietf.org/rfc/rfc2205.txthttp://www.ietf.org/rfc/rfc2205.txthttp://www.ietf.org/rfc/rfc2205.txthttp://www.ietf.org/rfc/rfc3317.txthttp://www.ietf.org/rfc/rfc3317.txthttp://www.ietf.org/rfc/rfc3317.txthttp://www.ietf.org/rfc/rfc2327.txthttp://www.ietf.org/rfc/rfc2327.txthttp://www.ietf.org/rfc/rfc2327.txthttp://www.ietf.org/rfc/rfc3525.txthttp://www.ietf.org/rfc/rfc3525.txthttp://www.ietf.org/rfc/rfc3525.txthttp://www.ietf.org/rfc/rfc2326.txthttp://www.ietf.org/rfc/rfc2326.txthttp://www.ietf.org/rfc/rfc2326.txthttp://www.ietf.org/rfc/rfc3550.txthttp://www.ietf.org/rfc/rfc3550.txthttp://www.ietf.org/rfc/rfc3550.txthttp://www.ietf.org/rfc/rfc1889.txthttp://www.ietf.org/rfc/rfc1889.txthttp://www.ietf.org/rfc/rfc1889.txtmaguireNoteIsn't there an author?

  • Peer-to-Peer audio conferencing using SIP:

    P2P security issues

    Luca Maccari

    May 11, 2007

    Abstract

    This report is part of a collection of three report describing several aspects of Peer-to-Peeraudio conferencing using SIP: security, Quality of Service and P2P architecture. This particularreport will detail in the P2P security; in this paper it will be analyze the solutions that someother P2P architecture use and then we will try to give the best solution for making secureaudio-conferencing using SIP.

    maguireInserted Textexamine in

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

    maguireCross-Out

  • Contents

    1 Introduction 2

    2 Security in overlay network 22.1 Overlay network : briefly introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Typology of overlay network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Sybil attack : an overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4 MITM (Man In The Middle) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.5 Self certifying SIP URIs in P2P SIP network . . . . . . . . . . . . . . . . . . . . . . 42.6 Alternative way of autentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.7 Conferencing consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

    3 Conclusion 6

    References 7

    1

  • 1 Introduction

    The typology of information exchanged over Internet is various ( HTTPS, ssh and many more);it is proved that most of the Internet traffic is generated by peer-to-peer network [San05]. If wethink that most of the VoiceOverIP traffic between peers is uncrypted,the risk of caption of reservedinformation (that a company,an institutions or two friends exchange) by a malicious peers is veryhigh. VoIP introduce others type of problems that involve,for example, SPIT (SPam Over Internettelephony); if we think about how tedious is spam email,shall we even imagine voice spam in ourconversation? The problem in P2P application for handling secure conversation is : ”who canmanage a policy for accepting/rejecting a peer?”. This is a really hard problem to solve if we don’tintroduce centralized strument for monitoring the access of users;our goal is to realize secure P2Paudio conferencing utilizying super-peer networks,as is explained in next chapter 2.

    2 Security in overlay network

    2.1 Overlay network : briefly introduction

    In this paper we assume that the concept of P2P network overlay as well as DHT are very wellknow concept; we aren’t going to explain on how a overlay network is working. The problem thatwe are going to try to resolve is : how secure will be built this solution?Basic, we are going to apply the solution onto a overlay network like Chord2 [YJJ06] ;this overlayis composed by peers and super peers; we assume that these last peers from now have the onlytask to act as entry point for peers that want to join in the ring,forwarding incoming request andgive response to peers. A peer is elegible to be super-peer whenever it has good quality for improvethe performance of the overlay network;this kind of quality are availability of bandwidth,averagesession time,CPU/memory and latency.

    2.2 Typology of overlay network

    Recently the use of product using VoiceOverIP for phone all around the world is increasingexponentially. The predominant structure used for VOIP up-to-now is client-server,with SIP serversmanaging the traffic and the clients that just need to sign in. What we want,instead of this typologyof architecture, is building a P2P SIP network that supports audio-conferencing;we would be able tomanage the reserved conversation of the nodes in any case. The overlay network that our solutionis going to work is Chord2, a typology of network that is based onto overlay network based usingDHT and the super peer nodes.

    2

    maguireCross-Out

    maguireCross-Out

    maguireInserted Text current

    maguireInserted Texts

    maguireCross-Out

    maguireReplacement TextVoice over IP (VoIP)

    maguireCross-Out

    maguireInserted Text being disclosed

    maguireInserted Texti.e., information

    maguireCross-Out

    maguireInserted Text,

    maguireInserted Text will be visible

    maguireCross-Out

    maguireReplacement Textto

    maguireCross-Out

    maguireInserted Texts

    maguireCross-Out

Click here to load reader

Reader Image
Embed Size (px)
Recommended