A Virtual and Distributed Control Layer with ProximityAwareness for Group Conferencing in P2PSIP ∗

Alexander Knauf1 Gabriel Hege1 Thomas C. Schmidt1 Matthias Wählisch2

1HAW Hamburg, Dept. Informatik, Berliner Tor 7, D–20099 Hamburg, Germany2Freie Universität Berlin, Inst. für Informatik, Takustr. 9, D–14195 Berlin, Germany

alexander.knauf@haw-hamburg.de hege@fhtw-berlin.de {t.schmidt,waehlisch}@ieee.org

ABSTRACTThere is an increasing demand to access voice or video groupconferences without the burden of a dedicated infrastruc-ture, but at any place and in an ad hoc fashion. Corre-sponding solutions require a lightweight, fully distributedcooperation among parties that share and manage the con-ference in an efficient, self-adaptive way. The technologyframework of P2PSIP can be seen as a promising startingpoint to meet these objectives. In this paper, we make sev-eral contributions towards such a distributed, virtualizedcontrol layer based on P2PSIP that seamlessly scales andadapts to the user needs. We propose a P2P-signaling pro-tocol scheme for a distributed conference control with SIP,that splits the semantic of Identifier and Locator of a SIPconference URI in a standard-compliant manner. This pro-tocol scheme serves as further basis for a virtualization inRELOAD. We further design and evaluate a self-organizingcommunication layer that provides load sharing and churnresilience with proximity-awareness. Finally, we address keyaspects of security and trust, as well as compatibility forconference unaware clients.

Categories and Subject DescriptorsC.2.2 [Network Protocols]: Applications—SIP ; C.2.4 [Dis-tributed Systems]: Distributed applications—Conferenc-ing

General TermsScalability, Reliability, Security

KeywordsOverlay virtualization, ID locator split, tightly coupled SIPconferencing, distributed conference control

∗This work is supported by the German Min-istry for Research and Education within theprojects Mindstone (http://mindstone.hylos.org) andH∀Mcast (http://hamcast.realmv6.org).

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.IPTComm 2010, 2-3 August, 2010 Munich, GermanyCopyright 2010 ACM ...$5.00.

1. INTRODUCTIONVoice and Video over IP (VVoIP) conference applications

follow a trend to become independent tools driven by endusers, since the capabilities at end systems (CPU, Memory)and the connectivity to broadband Internet are increasingcontinuously. They not only offer an alternative to tradi-tional telephony, but liberate users from provider-bound in-frastructure at common service charges. These changes areeven more visible in the mobile domain with its spread of in-telligent smartphones, and a foreseeable decline of operatorcontrol of end systems. In addition to traditional telecom-munication services, VVoIP deployments open the realm toricher and more flexible use cases such as ad-hoc multi-partyconversations of variable sizes.

Popular lightweight group communicators such as Skype[1] are built from proprietary models and protocols, whilemultiuser multimedia conferencing systems based on the Ses-sion Initiation Protocol (SIP) standard [2] are mainly de-ployed on dedicated server systems. Recent IETF activities,though, emerge to a new, infrastructureless session man-agement using P2PSIP overlays and a control layer thatconverges to the form of REsource LOcation And Discov-ery (RELOAD) [3]. Conferencing solutions built by SIPand non-SIP means are still almost exclusively constructedwith the help of one central conference controller per session,which — in a P2P setup — severely limits scalability andreliability of the application. Distributed conference sessionmanagement has not yet been taken up by the P2PSIP com-munity.

In this paper, we propose a virtual and distributed con-ference management architecture and a protocol that oper-ate in a P2P ad-hoc mode independent of infrastructure.By separating the locator from the identifier of the confer-ence controller, the focus [4] or conference Unified ResourceIdentifier (URI), we show how the multi-party session man-agement can be distributed among multiple peers. We in-troduce a simple routing scheme that transparently guidesconference signaling through the focus cloud, but still re-quires a globally routable physical focus instance for an ini-tial conference contact. To overcome the dependence onindividual peers, we virtualize the focus addressing withinRELOAD. The conference URI, which commonly providesglobal routability to a dedicated focus, is published on theP2PSIP overlay network as a key to several end system de-vices. Further on, the transparent routing is transfered tooperate on a proximity-aware overlay identifier space andgives rise to a self-adaptive tuning of the mutual communi-cation flows.

The overall result of this work is a decentralized server-less system for distributed conference management with SIPcoined DisCo. It solves the open problem of organizing con-ferences in a spontaneous, scalable and robust way basedon the emerging standards of P2PSIP technologies. Eval-uations reveal that the use of proximity-aware identifiersin an adaptive routing lead to a seamless self-organizationwith efficient neighborhood selection in our solution. Thesemechanisms are also designed as base implementations for adistributed media mixing which scales up to a large numberof participants, and remains reliable against node departureor failures.

The remainder of this paper is organized as follows. Sec-tion 2 presents an overview of background technologies andrelated work on the subject, followed by a discussion of thedistributed conferencing problem and its requirements. Ourcore distribution mechanisms for a SIP conference focus areoutlined and evaluated in Section 3. Section 4 is dedicatedto the conference virtualization in P2PSIP and its adoptionof the core distribution scheme; RELOAD usages and kindsare defined here along with the self-organizing procedures,authentication and trust aspects and a protocol evaluation.Finally, Section 5 is dedicated to conclusions and an outlook.

2. DISTRIBUTED CONFERENCING: PROB-LEM STATEMENT & RELATED WORK

2.1 Traditional ConferencingThree models of multi-party communication have been

defined in the discussion process at the IETF. The looselycoupled model does not provide a signaling relationship be-tween conference participants. Membership is achieved byjoining multicast groups and control information are learnedout of band or from the application transport protocol (e.g.,RTCP [5]). In a fully distributed model, each participantsomehow manages a signaling dialog to all other remoteparticipants. Finally, in the tightly coupled model signalingrelationships are established between participants and onecentral point of control, that negotiates media parameters toestablish media sessions. In SIP, this central point of controlis called the focus of a conference [6]. It is identified and lo-cated by a conference-specific SIP URI that must be globallyunique and routable. The first two models are not furtherdefined, leaving details and complexity to further specifica-tions. In the tightly coupled approach, a conference-specificURI will be obtained by querying a dedicated conferencingserver. This allocates and publishes a conference URI (e.g.,sip:meeting@muppets.com) and instantiates its correspond-ing focus . The focus then serves as interface towards SIPuser agents that are interested in joining the multimedia ses-sion. In addition to media negotiations, a conference focusmay comprise presence and conference state [7] notificationservices. The focus also enforces a predefined conferencepolicy (e.g., permitted participants) and controls the mediamixing components.

2.2 Peer-to-Peer SIP OverviewThe P2PSIP working group is dedicated to provide a vir-

tualized communication infrastructure for IP-based sessionservices. It decided to rely on a structured peer-to-peer ap-proach. Structured P2P systems are based on DistributedHash Table (DHT) algorithms that can provide resource lo-cation and storage in an application layer overlay network.

The overlay routing and data storage efforts are equally dis-tributed among the participating peers and scales up to avery high number of joining nodes. The benefits of DHTsoriginate form its performance properties of typically O(log(N))routing hops on average, and for a requirement of O(log(N))routing table entries per node, where N is the number ofoverlay members. DHTs such as Chord, Pastry, CAN, andKademlia [8, 9, 10, 11] have proved for their distributed, ro-bust and scalable characteristics and now experience a widerdeployment in various file sharing applications (e.g., BitTor-rent [12]).

Proximity Aware Overlays.Overlay network identifier are typically generated from

hash-functions (e.g., SHA1 in Chord) for maintaining a uni-form flat address space. These IDs normally do not haveany relation to relative network positions of a nodes in theunderlay. Numerical neighbors in the overlay can be phys-ically far apart. Improved structuring of P2P overlays [13,14] therefore may account for proximity information. Oneclass of approaches is built from landmarks. To determinethe relative network position p of a node, the round-triptimes (RTT) are measured against a fixed set of well knownlandmarks l0, l1, .., ln. These measurement results will beordered according to the landmark index with the result ofa landmark vector < l1, l2, .., l3 >. Thereafter, the entireaddress space will be divide into equally sized regions. Thedefinition of a region depends on the DHT and its addressstructure in use. The ring-type address space like in Chordcan be cut into equal slices; subtrees in Pastry can define aregion or an n-dimensional space in CAN. Each landmarkvector permutation produces exactly one related region. Anode then joins the overlay at a ’random’ point in the re-gion, that belongs to its landmark vector permutation. Anode may then be assigned to a relative position according toits overlay ID, since every node has constructed its ID usingthe same calculations. A disadvantage of this ID construc-tion is caused by an uneven population of the address space.This may cause peers to become responsible for much largeraddress ranges than others. Load-balancing algorithms canhandle this problem by relocating responsibilities for overlayspaces to less loaded peers.

Other approaches construct mappings between overlay IDsand position information that are stored in the overlay. As-suming the relative position p for node-ID IDn, then p′ =hash(IDn) is an overlay identifier, for position p of node n.Node n will then be mapped with p′ into the overlay region,stored on the node that is responsible for this address range.The nodes n1 and n2 are close to each other if the differenceof |p1 − p2| is low, with p1 and p2 were retrieved by a lookupoperation on p1

′ and p2′.

P2PSIP approaches.Traditional SIP-oriented service architectures depend on

proxy servers that assist in call routing, user location, NATand Firewall traversal, as well as additional functionalities.This orientation on static infrastructure limits deploymentand motivates approaches to relocate the proxy roles intoa P2P overlay for SIP sessions. Peers query the overlay byusing a P2P signaling protocol, and may contact an addressof the desired user agent without further hindrance. Coreprocedures for call establishment should still be achieved byusing standard SIP mechanisms. K. Singh et al. [15] and D.

Bryan et al [16] presented two different approaches, using aChord overlay network for replacing the SIP client-server in-frastructure. Both are using SIP messages within their P2Psignaling protocol which are routed throughout the overlay.For example, sending REGISTER requests is mapped to themeaning of a DHT join message. Note that the semantics ofthese SIP messages are either changed or extended by newextension-header fields. Fessi et al. [17] presented a hybridmodel, connecting a user agent to a dedicated SIP server,and likewise to a P2P SIP overlay. In this way, the authorsgain the benefits of the traditional SIP of low signaling laten-cies and a trustworthy instance for security considerations.In the case of a SIP server failure, a user agent may regainconnectivity by the P2P SIP overlay. To provide backwardscompatibility, a CoSIP proxy server is proposed as gatewayfrom SIP to the P2P protocol.

The necessity for an P2PSIP storage and lookup serviceoverlay was adopted by the IETF. The P2PSIP workinggroup is now standardizing a signaling protocol for REsourceLOcation and Discovery (RELOAD) [3]. The intention is toestablish a P2P overlay network based on a improved ChordDHT, providing a storage and resource location platform fordifferent kinds of data. It is firstly designed for a usage forSIP [18], but can be extended for new kinds with similar re-quirements. We use this flexibility to define a new Usage forRELOAD for a virtual and distributed conference, mappingcontact data and positioning informations into the overlay.

2.3 Related Decentralized ApproachesSeveral approaches have already dealt with the problem

space of distributed conferences. S. Romano et al. [19] pre-sented a framework that allows to receive information aboutconferences from various distributed conference servers. There-fore, they foresee signaling relations between multiple in-stances of dedicated centralized conferencing servers. A useragent can query its local conference server about multi-partysessions running at remote XCON Servers. The local confer-ence server then requests the remote server for the requiredparameters to participate and passes them to the requestingclient. An approach for a P2P SIP conference constructionwere developed by K. Tirasoontorn et al. [20]. The confer-ence URI, created by a Conference Factory placed on a ded-icated Server, will be announced in an P2P overlay networkincluding the required media and contact information to jointhe conference. The user agent that stored the conference in-formation in the overlay, is responsible to perform conferenceoperations. It remains as a single contact point to managethe multi-party conversation. Y. Cho et al [21] presented adistributed architecture for signaling and media mixing. Inthis hierarchical approach, a dedicated primary focus serverschedules conference participation requests among a set ofregional focus servers. The latter are responsible to includethe new participants and grant their access to the providedmedia data. The encoding effort thereby will be distributedonto several devices providing large-scale multimedia con-ferences.

2.4 Problems and Requirements forVirtualized Distributed Conferences

The traditional way to manage a multi-party conferenceis to create a central point of control. Thereby SIP correctlyidentifies a conference as a single logical entity and maps itsidentity to single point of control. The centrality of the lat-

ter is limited by scalability and stability, and conceptuallyforms the main problem for any approach of distributinga conference architecture [22]. This conference controllerin SIP is called focus and plays the role of an interface toparticipants, serves as negotiator for media parameters, andoften provides conference state notification services. The fo-cus is identified and located by a Globally unique RoutableUser agent URI (GRUU). Each request of a callee will berouted to the physical device behind this address. This re-sults in a single point of failure problem, as the conferencebreaks down with failures in this device or its connections.In a P2P scenario, the reliability of the conference control-ling node cannot be guaranteed and may cause a completefailure of the conference on regular departure. Apart fromsignaling, the chain of decoding, mixing and again encodingof media data demands high computational effort. There-fore, common solutions for multiuser voice and video con-ferencing are placed at dedicated server systems. They arecapable to reliably serve a fixed amount of media streams atlimited numbers (video solutions are typically designed forabout 20 participants). Common end user systems are onlyable to handle a fraction of this amount due to computingefforts. Deployed P2P-streaming (e.g., Zattoo [23]) solutionschallenge the possibilities of using the end-user systems fordistributed media streaming or mixing in pure audio. Cur-rently, many approaches apparently remain at a borderlinequality, but provisioning of reliable media streams will besoon enabled by the continuous dissemination of high speedInternet connections in home networks and the rising com-putational power of consumer computer.

From this perspective, we follow the need to design a dis-tributed conferencing scheme in a P2P fashion as a futurestandard-based solution for fully distributed voice and videoconferences. Therefore we define a set of requirements to bemet by our distributed conferencing protocol DisCo:

• Ad-hoc conference creation Any user agent im-plementing the conferencing scheme, must be able tocreate a multi-party session at any time. The creationmust be independent from a server infrastructure.

• Splitting the central conference control The con-ference focus must be divisible into several indepen-dent end systems. The split of the focus must therebybe transparently achieved with respect to standard-compliant SIP implementations and should appear asone single entity. The focus distribution should beactivated prior to a focus peer management resourceexhaustion. Any party should be enabled to discoverother potential focus peers within among active mem-bers.

• Robustness against focus failure It must be pos-sible to re-arrange (not to re-create) a conference, asone or more controlling peers fail, and thus to increasethe reliability as compared with centralized solutions.

• Availability of a conference To provide accessibil-ity to a distributed conference, it must be announcedon a stable platform. For this purpose, a well-definedconference data structure must be stored redundantin a P2P network, that allows to resolve a conferenceURI, that points to several independent conferencemanagers as entry points.

• Proximity aware participation The proposed con-ference signaling topology should serve road map forthe transfered media data. The media processing peersshould be arranged. New participants should be ableto select the physically closest focus peers, to minimizesignaling and data transfer delays.

• Security and Privacy A distributed conference mustensure that only authorized participants can attendthe conference. Also needs to be ensured that onlydetermined user can change and manage a conferencestate.

• Backwards compatibility A virtualized and distributedconference must be accessible by client implementa-tions that do not support our DisCo Usage.

3. DISTRIBUTING A FOCUS WITH SIP

3.1 Protocol SchemeThe first step for designing a distributed conference is to

separate the central control of the focus at the SIP layer.A conference URI refers per se to a dedicated focus. OurScalable Distributed CONference (SDCON) [24] approachsplits the meaning of the conference URI into identifier andlocater. This is achieved by introducing a source routingapproach, which transparently forwards data among confer-ence controllers that share a common conference URI. Thefocus service of a conference is distributed among severalparticipating user agents supporting the SDCON scheme.This leads to two classes of focus. First, the primary focus,which initially arranged and managed a multi-party confer-ence. Second, the secondary focus, which is a participatinguser agent requested by the primary focus to become partof the distributed conference controllers. There is no func-tional difference between primary and secondary focus. Par-ticipants can have a signaling relation to either a primary orsecondary focus. Both provide the same conferencing opera-tions and notification services based on the same predefinedpolicies. However, the conference URI is bound to the pri-mary focus. We propose the virtualization of the conferenceidentifier in section 4. This allows to completely decouplethe conference URI from dedicated peers.

Conference initiation, control, and management is per-formed by the participating user agents adapting to the sizeof a dynamically growing conference. Therefore, SDCON de-fines a focus discovery procedure, call delegation, and statesynchronization mechanisms. As the primary focus dele-gates a call to a secondary focus, it also transfers the usedSIP Call-ID and session identifier. Using this information,a secondary focus is able to seamlessly send a re-invitationto the transfered user agent and negotiate new media pa-rameters. To implement the source routing, the secondaryfocus inserts a Record-Route header field carrying its Glob-ally unique Routable User agent URI (GRUU). Further sig-naling is thus routed to the secondary focus. An example ofthe SIP re-invite request is shown below:

INVITE sip:elmo@sesamestreet.com SIP/2.0

Call-ID: 0818@141.22.26.55

CSeq: 1 INVITE

From: <sip:puppets.meet@conf.muppets.com>;tag=134652

To: <sip:elmo@sesamestreet.com>;tag=643684

...

Participant Potential Focus

SIPSIP

SIP

SIP

SIP

SIP

State Sync.

Call delegation

Fo

cu

s

dis

co

ve

ry

Focus A Focus B

SIP

Figure 1: A distribute conference control scenario

Contact: <sip:puppets.meet@conf.muppets.com>;isfocus

Record-Route: <sip:kermit@sesamestreet.com>

...

The Record-Route header is usually added by SIP proxiesto force further requests in a SIP dialog to be routed viathese entities [2]. In the example above, the secondary focuskermit adds its own SIP URI into the Record-Route headerand forces the re-invited user elmo to send subsequent SIPrequests via him. Those source-routed requests to secondaryfocus peers are intercepted by them and processed. Only thefocus peers are aware of the distributed fashion of conferencecontrol. Participants do not recognize the ID/Locator split,thus, the compatibility to SIP standard compliant imple-mentations is achieved.

Figure 1 shows the main functionalities supported by SD-CON user agents. The focus peers maintain signaling re-lations mainly by two message flows: the State synchro-nization messages and the Call delegation request messages.Call delegations occur when a focus is fully booked and needsto refer additional calls to less loaded focus peers. This is re-alized by sending standard SIP compliant REFER requests.Plain calls that address the conference URI are routed tothe primary focus. Call delegation, thus, will mainly beperformed for secondary focus peers. Synchronization mes-sages are sent on change of state in any single focus entity,e.g., announcing the arrival of a new participant. Thesemessages have to reach every controller to keep a consistentview on the conference. Synchronizations are sent withinSIP NOTIFY messages carrying an XML document definedby the Event Package for Conference State [7], which is ex-tended for multi-focus demands. The additional elementsinclude information about each focus capacities, list of theparticipants that are connected to it, and shows the signal-ing relation to other focus peers. The capacity informationis used to prevent a call delegation to an already busy fo-cus. In the case that the synchronization process has notbeen completed while a call delegation is performed, eachfocus peer can use SIP 4xx response messages types [2] toadvertise its status as busy. Another function consists in theability to discover focuses capabilities among participatingpeers [24]. The focus discovery procedure is initiated beforea focus reaches its threshold for serving new clients.

0 1 0 2 0 3 0 4 0 5 0 6 0 7 05 0

7 5

1 0 0

1 2 5

1 5 0

1 7 5Av

erage

Sign

aling D

elay [

ms]

P a r t i c i p a n t s [ # ]

F u l l y D i s t r i b u t e d H i e r a r c h i c a l C e n t r a l i z e dC a p a c i t y o f a s i n g l e f o c u s

Figure 2: Time to completion of an INVITE requestfor a newly arriving peer

3.2 EvaluationTo validate the operation and test the scalability of SDCON

signaling, we implemented a prototype application and per-formed experimental measurements. The prototype is basedon the NIST Jain SIP stack [25], which represents the ref-erence implementation for Java. All measurements wereperformed in emulation mode. A minimal SIP proxy im-plementation was executed on a Pentium D 2*2.80 GHz 2with 2 GB RAM. The emulated participants and conferencefocus peers have been executed on an Intel(R) Xeon(R) CPU16*2.33 GHz with 16 GB RAM. The capacity of a single fo-cus was fixed to 10 conference members. Each measurementresult presents the average signaling delay of 50 independentruns.

Figure 2 presents the average signaling delay to partic-ipate a conference, i.e., sending SIP INVITE requests to-wards the conference URI. It compares our fully distributedconference management with a centralized [4] and hierarchi-cal [21] approach. The later implements a recursive calldelegation starting from the primary focus along the fo-cus servers. For small conferences, where all parties canbe served from a single focus, our results agree with delaysof a centralized approach. The redistribution of the focus at-tachment in our scheme causes one additional REFER mes-sage and thus slightly doubles the signaling times. Apartfrom this delay enhancement, the distributed conferencingadmits almost constant delays, in contrast to the hierar-chical scheme. The latter experiences increasing delays ofapproximately linear scale with growing conference size.

The signaling delay for a third-party invitation is pre-sented in Figure 3. In this scenario, each recently joinedconference member initiates a third-party request to its re-lated conference focus peer by sending corresponding SIPREFER messages. The measurements follow our previousobservations. Most third-party participations are handledin a constant signaling delay around 45 ms. Delay peaksreflect overloaded focus peers with a maximum of 10 confer-ence members. On reaching more than 10 members, a focusinitiates the focus discovery procedure and delegates furtherparticipation requests to the new capable focus peer.

0 1 0 2 0 3 0 4 0 5 0 6 0 7 00

1 02 03 04 05 06 07 0

Avera

ge Si

gnalin

g Dela

y [ms

]

P a r t i c i p a n t [ # ]

D i a l - o u t D e l a y

Figure 3: Third-party participation via REFER re-quests

4. VIRTUALIZED CONFERENCE CONTROLWITH P2PSIP

The aim of virtualizing the conference is to separate itslogical ID from any physical instance. The P2PSIP over-lay RELOAD [3] facilitates a corresponding mapping andlookup of currently available conference management peers.By using P2PSIP with RELOAD we gain the benefits ofan open and extensible signaling protocol that provides so-lutions for common problems in traditional SIP and P2Psystems.

RELOAD serves as a P2P service platform providing amessage transport protocol, data storage and lookup func-tionalities, as well as connection establishment for differenttypes of applications. Since connectivity of many peers inan overlay may be limited by NATs or firewalls, Interac-tive Connectivity Establishment (ICE) [26] is supported forNAT and firewall traversal. RELOAD also provides a se-curity framework based on public/private-key certificates toestablish trust relations and message authentication.

Overlay messages are designed with a simple and lightweightforwarding header reducing forwarding effort and increasingthe routing performance. A noteworthy feature of RELOADis that the overlay algorithm to be used is not fixed, but leftto the implementation. However, the current version of theRELOAD draft foresees a deployment on an improved Chorddistributed hash table (DHT). To support different applica-tions, RELOAD allows for the specification of new Usages.A Usage defines the data structures (kinds) to be stored, thecorresponding data identifier (kind-ID), access control rulesto those resources and how the resources’ overlay IDs are tobe formed.

Our concept of a virtual and distributed conference con-trol uses these RELOAD benefits to provide a reliable, flex-ible and scalable conferencing service in a P2P fashion. Wedefine a RELOAD Usage for separating the conference URIfrom any specific focus entity and map it to the set of partic-ipants that act as a focus instance. The proposed RELOADdata structure provides network positioning information toenable a proximity based focus selection. Based on thiskind definition, our Distributed Conference Usage (DisCo)

DisCo Resource

- Focus A; <l1, l2, l3, l4, l5, l6>

- Focus B; <l1, l2, l3, l4, l5, l6>

…

New

Participant

DHT

Focus B

Lookup

Conference URI

Media Stream

Focus A

Figure 4: Discovery of a secondary focus using proximity information

[27] allows for the ad hoc creation of multimedia confer-ences without a dedicated server infrastructure. Conferencesignaling is performed using the call delegation and synchro-nization mechanisms as described in the previous section.

4.1 Distributing a Focus in RELOADDisCo defines a distributed SIP conferencing Usage that

publishes all available entry points to a conference in a P2Pfashion. The inter-focus SIP signaling is performed usingthe SDCON protocol scheme presented in the previous sec-tion. This keeps the conference state in sync and performsload balancing whenever focus peers are reaching their ser-vice threshold for hosting clients. The DisCo Usage allowsa SIP user agent to create a tightly coupled conference inP2P fashion, without assistance of a dedicated conferenceserver. Figure 5 displays the procedure of how to register adistributed conference in a RELOAD instance. The creat-ing peer (CP) of a conference generates the desired confer-ence URI (Conf-ID) and first probes whether this address isavailable. This is performed by using the RELOAD StatReqmessage which is routed to the storing peer (SP) responsiblefor the overlay ID. Overlay storage is organized according tokeys obtained by hashing the conference URIs. The corre-sponding StatAns messages contains all meta data about theRELOAD resources already stored at this resource-id. If noother DisCo or SIP registrations for the selected Conf-IDexist, CP can proceed by querying the enrollment server ofthis RELOAD instance to obtain a new certificate createdfor the conference URI. Using this security certificate, CPthen creates a DisCo kind data structure that comprises tu-ples of two types of information. At first the address wherea joining peer can contact the CP to join the conference,at second a coordinate vector that encodes the relative po-sition of the CP within the underlying network. Using theRELOAD Store operation, CP registers the conference inthe overlay.

The distributed conference registration will be treated as aRELOAD resource of Kind DisCo maintained by the storingpeer. The RELOAD overlay itself acts as a registrar and es-tablishes direct transport connections traversing NATs and

CP probes availabilityof the desired Conf-ID

Conf-ID available:CP registers itselfas first focus for theconference at SP

The registrationof the Conf-IDrequires a newcertificate

StatReq Kinds:DisCo,SIP

Creating

Peer(CP)

Storing

Peer (SP)

StatAns

Certificate Request

New Certificate

Enrollment

Server

Store AoR:Conf-ID Kind: DisCo

StatAns

Figure 5: Creation of a distributed conference

firewalls.DisCo-enabled peers intending to participate in the con-

ference need to look up the hash of the conference URI asdisplayed in figure 4. They retrieve the DisCo conference re-sources, i.e., a RELOAD dictionary data structure in whicheach single dictionary entry points to a distributed confer-ence focus. In a RELOAD dictionary data model, each valuestored is indexed by a key. Using this index scheme, a focuspeer can explicitly update its own contact and coordinatesinformation maintaining its own overlay ID as dictionarykey. The contact information of the conference focus can beof two different types, an Address-of-Record or a RELOADoverlay ID. In the first case, if the retrieved Address-of-Record (AOR) is a GRUU, the participating peer simplyestablishes a regular SIP session by sending a SIP INVITErequest towards the announced contact. Otherwise the re-ceived AOR is registered with the standard SIP Usage forRELOAD and must be resolved following the SIP Usage pro-tocol. If the retrieved contact is a RELOAD overlay ID, aparticipating peer needs to perform a RELOAD appattachrequest to establish a direct connection to the remote over-lay peer. This request will be routed along the overlay withICE parameters and defines the desired application protocol

enum {sip_focus_uri (1), sip_focus_node_id (2)

} SipDistConfRegistrationtType;

struct {

opaque coordinate<0..2^16-1>

select (SipDistConfRegistration.type) {

case sip_focus_uri:

opaque uri<0..2^16-1>

case sip_focus_node_id:

Destination destination_list<0..2^16-1>

}

} SipDistConfRegistrationData

struct {

SipDistConfRegistrationType type;

uint16 length;

SipDistConfRegistrationData data;

} SipDistConfRegistration

Figure 6: Proposed RELOAD data structure for adistributed conferencing kind

as SIP. After the appattach request has succeeded, an ordi-nary SIP session will be build upon the newly created trans-port connection. A new conference member can advertiseits focus ability by adding an allow event to the multi-focusconference state event package in the INVITE request.

Each contact in the data structure is complemented bycoordinate values that indicate the relative position of thepeer within the underlying network. Based on this informa-tion, a joining peer may choose the focus from the dictionaryentries that is closest according to the proximity selectionmechanism explained in the following section.

After a DisCo-enabled peer has established a SIP sessionby sending an INVITE, it is free to decide on advertising itsown capacities. To do so, it registers as a potential focus tothe conference storing its contact and network positioninginformation within the same DisCo resource. Focus func-tions will be activated either by a new joining peer thatchooses this potential focus as (nearest) entry point, or bythe focus discovery procedure explained in section 3. As apotential focus is requested by a user agent to participate viaSIP signaling, it first accepts the call and establishes the re-quested media sessions to this client. Afterwards, the activefocus will advertise its new status to all other active peersmanaging the conference. It subscribes its related focus tothe extendedconference event package while transmitting itsfocus capacities and contact and media information of thenew participants. The request focus will interpret this mes-sage as indication for a new user agent acting in the role of afocus and notifies all remote conference controller about thischange of state. It further responds with a SIP SUBSCRIBE

request to the new focus, transmitting the conference stateXML document. This finishes the focus acceptance and thepotential focus is a known active focus. All focus peers takethe same authorities and responsibilities to manage the dis-tributed conference as the initial focus.

The definition of the distributed conference registrationkind is shown in figure 6. Every focus peer is allowed to storeor update mapping bindings using its node-id as the dictio-nary key. The mappings stored can be of two varieties corre-sponding to the types allowed in the SIP-REGISTRATION:The first type sip focus uri contains the Address-of-Recordof a focus peer and the second sip focus node id returns

Storing

Peer (SP)

Focus

Peer (FP)

By passing theconference certificate JP isenabled to write the data structure

AppAttach establishes a transport connection

JP looks upthe Conf-IDusing FetchRequest

By storing JP's AoR in the data structre, it registers itself as new focus peer

Fetch Conf-ID Kind:DisCo

Joining

Peer (JP)

FetchAns Node-ID:FP

AppAttach app:5060

AppAttach app:5060

ICE Checks

INVITE sip:focus

INFO Body: Conference Certificate

ACK200 OK

Store AoR: JP Kind: DisCo

StoreAns

Figure 7: Joining a distributed conference and ad-vertising focus abilities

the a RELOAD destination list containing overlay node-IDs.The destination list feature in RELOAD is used, to enable arequesting peer to perform a recursive overlay source rout-ing. We define for the DisCo Usage, that the accompanyingcoordinates value belongs to the final target of the destina-tion list. If storing an AoR, the related coordinates valuemust define the relative position of the AoR location. Thecoordinates value is stored as an opaque string containingthe relative network defining a landmark vector. A land-mark vector represents a set of Round-Trip-Times (RTT)measurements against well-known landmarks. A more de-tailed explanation follows in the next section. We use is ex-plicit coordinate value, because it can not be assumed thatused overlay algorithm in an RELOAD P2PSIP instancesupports proximity awareness. The proposed Chord over-lay in the RELOAD base definition for example, does notsupport proximity information.

4.2 Self Organization with Proximity-awareLoad Sharing

The DisCo conference construction is performed using rel-ative network position information. Each joining participantchooses its closest focus, and every new peer managing partsof the conference establishes an SDCON relation to its near-est active focus node. A benefit of this proximity peer selec-tion arises from an optimized mesh build-up causing shortsignaling paths by default. The single steps to joining avirtual and distributed conference are the following as dis-played in figure 7:

1. Determining coordinates: Before a peer joins the multi-party conversation, it determines RTTs against a set of

stable Internet hosts l1, l2, .., ln serving as landmarks.The measurement results are ordered along a landmarkindex that is equal for all parties and focus peers. Or-dered in this manner, the measurement results in mil-liseconds comma-separated define our landmark vectorrepresenting a peers relation network position in ann-dimensional Cartesian space with n is the numberof landmarks (e.g. < 311, 87, 42, 137, 228, 75 , .., 55 >).We thereby follow the landmarking approach from Rat-nasamy et al. for proximity-aware server selection [13]without the explicit binning of peers whose landmarkvectors equal each other. It just serves as am abstractdescriptor for a peer’s relative position in the networkand is not used to identify a peer.

2. DisCo data structure retrieval: To obtain alle avail-able focus peers for a conference the joining peer (JP)achieves a RELOAD fetch request that is routed to thestoring peer thats own the resource-id for the hashedConference URI. It thereby in the sets the kind valuein the request to the DisCo kind-id querying for thecomplete conference dictionary.

3. Calculating the closest entry point: On successful re-ceived the conference information, a peer compareseach retrieved coordinates value representing the focuslandmark vector with its own. Our approach subtractsthe each focus landmark vector with that of the joiningpeer and builds the scalar product over the result of asubstation. The joining peer then chooses that focuswith the smallest scalar product result as entry pointto the conference.

4. Connecting to a Focus: Using contact information de-posited dictionary entry, JP establishes a transportconnection to the selected focus peer (FP) using theRELOAD’s AppAttach operation. It is routed through-out the overlay to FP and indicates a desired SIP sig-naling connection by setting the application field to5060. After FP finalized the AppAttach progress JPand FP perform ICE checks [26] to detect whether anyof them if located behind a NAT and additional TURNserver are needed for application session establishment.

5. SIP Session establishment: The established transportconnection is then used to enter the ordinary SIP sig-naling progress thus JP can successfully join the mul-tiparty conversation. Additionally, JP can pass JPwriting permission to the DisCo registration by trans-mitting the shared certificate within a SIP INFO mes-sage.

6. Advertising focus abilities: JP can optionally adver-tise itself as available focus peer for the distributedconference, by mapping its contact to the existing DisCodata structure at the storing peer.

The joining peer hereby adds its own landmark vectorcoordinates as an URI parameter coord base64 encoded toits URI in the SIP contact header. The coord-parameteris used by the requested focus in case of overloading. Itthen performs the call delegation mechanism and selects afocus candidate according to the new participants networkpositioning. If the selected focus is capable to serve newclients it accepts the SIP call. Further, it published the

new membership by achieving the SDCON synchronizationmechanism explained in section 3, to keep the conferencestate consistent.

Because every new member chooses its closest focus, theconference will be constructed unified distributed among allcontrolling peers, like shown in figure 4. Following this reg-ular construction, participants and focus peers will arrangethemselves to an unbalanced distribution tree. To reducethe diameter of this tree, hence minimizing the delay timesbetween the nodes, it is possible to establish cross connec-tions. This kind of mesh optimization are highly dependenton the types of used media streams, and is therefore out ofscope of this paper.

4.3 Resilience to Focus FailuresA problem in traditional tightly coupled conferences, orig-

inates from the focus that acts as single point of failure. Ifit breaks down, all signaling and media sessions are discon-nected. In our scenario, the distributed structure of theconference prevents the breakdown of the entire multimediasession as one focus peer fails. As a focus fails, it can besubstituted by potential or active focus peers re-collectinglost conference participants.

We use this redundancy to build a recovery mechanism.As a DisCo-enabled participant notices that its related fo-cus does not any more deliver signaling or media packets,it will connect to one of the remaining managers of theconference. It therefore achieves the same DisCo protocolsteps explained previews, however, without redeterminingits landmark vector.

Conference participants not supporting the DisCo Usagewill get a different treatment in case of focus error. A con-ference focus selects one or more active focus peers, thatwill serve as backup focus. The selection is done accordingto the relative network coordinates by choosing the closestpeers. The backup selection will be announced to all otherconference controller within the conference state XML doc-ument. In the case of node appearance, the detecting focusfirstly notifies the conference managing peers about failureto share knowledge. It then immediately refers all discon-nected participants to the backup focus peers. In this way,participants related to the malfunctioning conference con-troller just notice a temporally connection loss and recovervia a re-invitation mechanism. Whenever the malicious fo-cus returns, it re-joins the conference normally. Otherwise,the dictionary entry of this peer will be deleted by the re-source owner, after the lifetime value expires in RELOAD.

New participating peers who try to connect to a disap-peared focus will receive a 404 Not Found response mes-sage, according to the RELOAD protocol. These peers thentry to connect to the focus, whose landmark coordinates arethe second closest to their own. The stored DisCo data isprotected against failure of the resource owner, by the pro-vided replication algorithms in the used DHT running theRELOAD P2P SIP instance.

4.4 Security & Trust AspectsThe DisCo Usage defines a set of security and trust as-

pects in a P2P environment. A common problem in dis-tributed P2P systems arises from the fact, that connectionswill be established, even though the corresponding partnersdo not necessarily trust each other. In our conference sce-nario, we assume that participating peers can authenticate

each other in person based on the received voice and videotransmissions. Built on this, we introduce a graduated trustdelegation system for distributed conferences.

RELOAD provides a set of access control policies, definingwhether a peer is allowed to perform a certain store requestor not. For our distributed conferencing resource, we usethe defined user-match access policy. Each stored data canbe written if the request is signed with a key associated witha certificate whose hashed user name equals the resource’soverlay ID. Since our DisCo resource needs to be updatedby multiple peers, using the user-node-match policy used bythe SIP Usage for RELOAD is not an option. We use ourtrust delegation mechanism, allowing peers to obtain writeaccess to the shared resource. To receive write permissionsfor the distributed conference overlay resource, the privatekey for the certificate of the stored resource will be trans-mitted within a SIP INFO message to allowed focus peers.Using this key, a user is able to authenticate itself againstthe owner of the conference data structure, and can registeras potential focus.

On conference creation, the initiating peer can setup thedistributed conference policy for a layered authentication.In an open access model, every peer interested to join theconference can do so by just inviting one of the multi-partyfocus peers. No authentication is required for participat-ing. An open access model may be suitable for a groupconversation of public interest, for example a political de-bate. Because in this open model, an attacker could easilybecome a focus peer and send malicious packages, we definean open access focus authenticate model. The conferenceinitiator can specify that peers wanting to become a focusneed to authenticate themselves using any of the standardauthentication mechanisms allowed in SIP. The correspond-ing credentials need to be transmitted to those peers bya non-SIP, non-overlay mechanism. As a new participantinvites the conference, it uses ordinary SIP authorization.After validation of the presented credentials the called focusis then allowed to pass the conference’s certificate key to therecently joined conference member. To create a closed multi-media conference, it is also possible to set an authenticationscheme required for participation in a closed access model.Thus, only users who present valid authorization credentialsare allowed to join. By combining the closed access and thefocus authenticate model, our layered access model definesdifferent permissions for clients joining the conference onlyand peers that are allowed to become focus, dependent ontheir credentials. Focus peers obtain the information neededto validate participants’ credentials within the conferenceXML document (e.g. a conference password or certificate),to be able to authorize new members. The used access modelwill be stored in the conference state XML extension, thusevery controlling peer is aware of the used access model.

Providing these access layers, a user initiating a conferenceis able to setup its desired privacy policies for the multi-partyconversation. It can be suggested, that in closed conferencesan unknown conference member will be detected by the par-ticipating users, for example by not recognizing its voice oroutwards appearance in video. Those unsuspected users canbe excluded by a conference focus peer by disconnecting sig-naling and media sessions.

4.5 Supporting Conference-unaware PartiesParticipation a virtual and distributed conference is not

be exclusive for those peers that implemented our RELOADUsage definition. Standard compliant participation is trans-parently provided to peers unaware of the distributed con-ference construction. This section describes the backwardcompatibility to user applications implementing the SIP Us-age [18] for RELOAD, and describes how connectivity toSIP-only user agents is achieved.

The SIP Usage for RELOAD defines a kind data structurefor storing an AoR for a SIP user agent. It likewise uses thedestination list feature in RELOAD and provides the stor-age of GRUUs as contact addresses for SIP session establish-ment. To provide backward compatibility to RELOAD peersonly implementing the SIP Usage, a conference initiator candecide to register the conference URI as SIP-Registrationkind parallel to the DisCo kind. The SIP Usage registrationis then performed using the destination list feature, register-ing the amount of active and potential focus peers as entriesin the destination list. Peers attending to join requesting re-solving conference URI using SIP-Registration kind-ID, re-trieve the destination list containing the conference entrypoints. The connection to a conference focus then will beachieved in accordance with the SIP Usage. Those peers willnot be aware of the distributed structure of the multi-partyconversation.

Because the SIP usage for RELOAD access model is user-node-match, other focus peers will not be able to updatethe stored data. The conference initiator must update theSIP-Registration kind continuously, on appearance or disap-pearance of focus peers. Hence, it depends to the conferenceinitiator to keep the destination list up to date and valid.To achieve maximal accessibility in the case that the lat-ter permanently leaves the multi-party conversation, it hasto set the lifetime value on a high level. By just using theSIP-registration kind, conference joins can not be performedunder proximity selection. However, a conference createdwith DisCo can provide access to the multi-party, althougha client does not implement our usage.

The participation for ordinary SIP user agents is per-formed by another mechanism. Since a virtualized confer-ence URI is stored in a RELOAD overlay, a standard SIPuser agent can not resolve it with traditional mechanismsand a direct participation is not possible. Instead, partic-ipation will be achieved through third-party initiated fromwithin the conference. An established multi-party memberrequests its related focus to invite the new attendees sendingSIP REFER requests. By using the protocol mechanisms fortransparent focus distribution explained in section 3, the re-quested conference manager invites the new attendee send-ing a SIP INVITE request.

4.6 EvaluationTo verify our concept of the proximity-aware focus se-

lection, we conducted experimental measurements based onthe PlanetLab platform [28]. PlanetLab nodes are globallydistributed and thus allows for geographically placement ofconference peers. Although this real-world experimental fa-cility is biased in the sense that significant nodes are lo-cated at well-connected university networks, it gives a goodapproximation of delay characteristics for this part of theInternet.

CAIDA Monitor Location

mnl-ph.ark.caida.orgnrt-jp.ark.caida.org ASIAshe-cn.ark.caida.orgdub-ie.ark.caida.orglej-de.ark.caida.org Europeher-gr.ark.caida.orgpna-es.ark.caida.orgsea-us.ark.caida.orgmty-mx.ark.caida.orgamw-us.ark.caida.org North Americayto-ca.ark.caida.orgwbu-us.ark.caida.orghlz-nz.ark.caida.org Oceaniagig-br.ark.caida.org South Americascl-cl.ark.caida.org

Table 1: Selected landmark nodes chosen fromCAIDA measurement monitors

Experimental SetupThe experiment considers small and medium size confer-ences. The principle setup is the following: We deployedDisCo on a varying number of peers chosen from a prede-fined subset of all PlanetLab nodes. These peers create focusinstances and corresponding relationships based on the land-marking approach described in section 4.2. Relative networkpositions are determined using 15 landmark nodes outsideof the PlanetLab system. The experiment is conducted untilmeasurements are converged.

100 nodes are selected from the overall PlanetLab nodesto create the list of potential DisCo peers. To mitigate localsystem disturbances, we included only hosts that exhibit anappropriate system load. The selected nodes are locatedin Asia, Europe, South and North America to emulate aglobally distributed conference and observe long range delayeffects.

In general, the quality of landmark approaches depends onan appropriate number of landmark nodes and their place-ment. However, there is no common sense on the num-ber of dimensions to create a coordinate system [29]. Theymay range typically of 7 to 9 [30], but also depend on thedataset. In order to evaluate proximity-awareness for an al-most generic scenario with respect to the selected DisCopeer, i.e., without any dedicated landmark optimization,15 landmarks are chosen from the set of CAIDA [31] mon-itor points (cf. Table 1). This has two advantages: First,CAIDA monitors are globally reachable and not located be-hind NATs or firewalls, which is important and a realistic de-ployment assumption for landmark nodes. Second, they areglobally distributed covering different geographic locations.The landmark selection process omits suspicious nodes thatreply unusually on ICMP echos.

Performance MetricsWe analyze the quality of our proximity-aware self organi-zation of (focus) peers based on the following metrics:

Degree corresponds to the number of neighbors. Nodesthat have a degree of 1 only participate in the con-ference without replicate data. Nodes with a largerdegree operate as focus. This metric, thus, reflects

1 2 3 4 5 6 7 8 9 1 0 1 1 1 20 , 0

0 , 1

0 , 2

0 , 3

0 , 4

0 , 5

0 , 6

<Rela

tive Fr

eque

ncy>

D e g r e e [ # N e i g h b o r s ]

L a n d m a r k R a n d o m O p t i m a l

1 2 3 4 5 6 7 8 91 E - 3

0 , 0 1

0 , 1

1

Figure 8: Degree distribution

implicitly the load on a peer.

Delay Stretch measures the ratio of the average delay causedby the overlay and the average delay using native dis-tribution. It follows the idea of the relative averagedelay (RAD) defined by Castro et al. [32]. This met-ric represents the relative delay penalty.

Foci Ratio describes the ratio of overlay peers that attainthe role of a focus. This metric quantifies the distri-bution of conference management load among peers.

The results are compared with a complete random selec-tion of focus nodes, and an optimal solution of the focus andpeer topology.

ResultsThe degree distribution of inter-peer relations was measuredand displayed in Figure 8. For all schemes, the majority ofnodes are single-attached and thus pure leafe nodes. Fo-cus nodes that exhibit a degree ≥ 2 dominantly admit lowdegrees and thus suffer little load of packet replication andforwarding. More significantly and clearly visible from theinsert, the probability of higher degrees exponentially de-creases leaving negligible weight to the occurrence of over-loaded peers or unsuitable conferencing demands.

A more sensitive measure on detailed conference perfor-mance is given by the delays imposed mutually related peerneighborhoods on the overlay. Figure 9 compares the aver-age delay stretch of our landmarking scheme with a randomneighbor selection and the optimal set-up. While a routingvia arbitrary conference neighbors in our global conferenceevaluation may lead to alienating delay enhancements of 15to 30 times, our landmarking scheme remains within favor-able bounds around 2 to 3, which is very close to the opti-mal solution. Most importantly, the delay stretch remainsconstant with respect to the numbers of conferencing par-ties and thus promotes arbitrary scalability of our proposedadaptive self-organization scheme. It should be noted thatrandomized neighbor selection leads to a linearly increasingstretch.

Finally, we examine the relative portion of peers that at-tain the role of a conference controller assuming the absence

1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 00

5

1 0

1 5

2 0

2 5

3 0RA

D

O v e r l a y S i z e [ # P e e r s ]

L a n d m a r k R a n d o m O p t i m a l

Figure 9: Delay stretch based on the Average DelayRatio (RAD)

0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 00

1 02 03 04 05 06 07 08 09 0

1 0 0

Foci R

atio [

%]

O v e r l a y S i z e [ # P e e r s ]

L a n d m a r k R a n d o m O p t i m a l

Figure 10: Ratio of overlay peers attaining the roleof a focus

of NATs and firewalls. As displayed in Figure 10, the relativeportions of focus peers is bound to about 50 %, independentof the conference size, as well as the adaptation scheme inuse. Peers thus encounter a probability of 0.5 to be uti-lized as conference supporters at a scale the remains fullyindependent of conversational parties.

5. CONCLUSION AND OUTLOOKIn this paper, we presented a virtual and distributed con-

ference control solution, self-organizing and adapting to thedemands of a scalable, infrastructure-resilient multi-partyconversation. Presenting a protocol scheme that transpar-ently splits a SIP conference focus onto multiple peers, anaddress virtualization of the conference URI separates thelogical ID from any physical instance. We demonstrate howthis concept is implemented in a RELOAD DHT of P2PSIP,providing independence from any server infrastructure. Tomeet the requirements of a transient P2P environment, thepresented protocol schemes maintain operations for call dele-

gation, load balancing and state synchronization. To reducesignaling delays, we proposed a method for routing with re-spect to relative network position of peers and to enable aproximity-aware focus selection.

The conducted experimental measurements revealed closeto optimal results for our presented concepts. We showedthat the signaling delay remains constant during an increas-ing conference. Furthermore, our measurements on the Plan-etLab platform displayed, that our proximity-aware focusselection achieves a low delay stretch. Reducing the edgedegree per node and diameter of the arising tree-like meshtopology, we expect to apply further optimizing algorithmsfor future work. We propose to bring the concept of a virtu-alized and distributed conference Usage into the IETF stan-dardization process.

6. REFERENCES[1] “The Skype homepage,” http://www.skype.com, 2009.

[2] J. Rosenberg, H. Schulzrinne, G. Camarillo,A. Johnston, J. Peterson, R. Sparks, M. Handley, andE. Schooler, “SIP: Session Initiation Protocol,” IETF,RFC 3261, June 2002.

[3] C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, andH. Schulzrinne, “REsource LOcation And Discovery(RELOAD) Base Protocol,” IETF, Internet-Draft –work in progress 12, November 2010.

[4] J. Rosenberg, “A Framework for Conferencing withthe Session Initiation Protocol (SIP),” IETF, RFC4353, February 2006.

[5] H. Schulzrinne, S. Casner, R. Frederick, andV. Jacobson, “RTP: A Transport Protocol forReal-Time Applications,” IETF, RFC 3550, July 2003.

[6] O. Levin and R. Even, “High-Level Requirements forTightly Coupled SIP Conferencing,” IETF, RFC 4245,November 2005.

[7] J. Rosenberg, H. Schulzrinne, and O. Levin, “ASession Initiation Protocol (SIP) Event Package forConference State,” IETF, RFC 4575, August 2006.

[8] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, andH. Balakrishnan, “Chord: A scalable peer-to-peerlookup service for internet applications,” inSIGCOMM ’01: Proceedings of the 2001 conference onApplications, technologies, architectures, and protocolsfor computer communications. New York, NY, USA:ACM Press, 2001, pp. 149–160.

[9] S. Ratnasamy, M. Handley, R. M. Karp, andS. Shenker, “Application-Level Multicast UsingContent-Addressable Networks,” in Networked GroupCommunication, Third International COST264Workshop, NGC 2001, London, UK, November 7-9,2001, Proceedings, ser. LNCS, J. Crowcroft andM. Hofmann, Eds., vol. 2233. London, UK:Springer–Verlag, 2001, pp. 14–29.

[10] A. Rowstron and P. Druschel, “Pastry: Scalable,distributed object location and routing for large-scalepeer-to-peer systems,” in IFIP/ACM InternationalConference on Distributed Systems Platforms(Middleware), ser. LNCS, vol. 2218. BerlinHeidelberg: Springer–Verlag, Nov. 2001, pp. 329–350.

[11] P. Maymounkov and D. Mazieres, “Kademlia: Apeer-to-peer information system based on the xormetric,” in Proc. of the 1st Int. Workshop on Peer-to

Peer Systems (IPTPS ’02), Cambridge, MA, USA,2002, pp. 53–65.

[12] “The BitTorrent Homepage,”http://www.bittorrent.com/, 2010.

[13] S. Ratnasamy, M. Handley, R. M. Karp, andS. Shenker, “Topologically-aware overlay constructionand server selection,” in Proc. of 21st Annual JointConference of the IEEE Computer andCommunications Societies (INFOCOM ’02),Washington, DC, USA, 2002, pp. 1190–1199.

[14] Z. Xu, C. Tang, and Z. Zhang, “Buildingtopology-aware overlays using global soft-state,” inProc. of the 23rd Int. Conf. on Distributed ComputingSystems (ICDCS ’03). Washington, DC, USA: IEEEComputer Society, 2003, p. 500.

[15] K. Singh and H. Schulzrinne, “Peer-to-peer internettelephony using sip,” in Proc. of the int. workshop onNetwork and operating systems support for digitalaudio and video (NOSSDAV ’05). New York, NY,USA: ACM, 2005, pp. 63–68.

[16] D. A. Bryan, B. B. Lowekamp, and C. Jennings,“Sosimple: A serverless, standards-based, p2p sipcommunication system,” in Proc. of the 1st Int.Workshop on Advanced Architectures and Algorithmsfor Internet Delivery and Applications(AAA-IDEA’05). Washington, DC, USA: IEEE ComputerSociety, 2005, pp. 42–49.

[17] A. Fessi, H. Niedermayer, H. Kinkelin, and G. Carle,“A cooperative sip infrastructure for highly reliabletelecommunication services,” in Proc. of the 1st int.conf. on Principles, systems and applications of IPtelecommunications (IPTComm ’07). New York, NY,USA: ACM, 2007, pp. 29–38.

[18] C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, andH. Schulzrinne, “A SIP Usage for RELOAD,” IETF,Internet-Draft – work in progress 05, July 2010.

[19] S. Romano, A. Amirante, T. Castaldi, L. Miniero, andA. Buono, “A Framework for DistributedConferencing,” IETF, Internet-Draft – work inprogress 08, December 2010.

[20] K. Tirasoontorn, S. Kamolphiwong, and S. Sae-Wong,“Distributed p2p-sip conference construction,” in Int.Conf. on Mobile Technology, Applications, andSystems (Mobility ’08). New York, NY, USA: ACM,2008, pp. 1–5.

[21] Y.-H. Cho, M.-S. Jeong, J.-W. Nah, W.-H. Lee, andJ.-T. Park, “Policy-Based Distributed ManagementArchitecture for Large-Scale Enterprise ConferencingService Using SIP,” Selected Areas inCommunications, IEEE Journal on, vol. 23, no. 10,pp. 1934–1949, Oct. 2005.

[22] T. C. Schmidt and M. Wahlisch, “Group ConferenceManagement with SIP,” in SIP Handbook: Services,Technologies, and Security, S. Ahson and M. Ilyas,Eds. Boca Raton, FL, USA: CRC Press, December2008, pp. 123–158, on invitation. [Online]. Available:http://www.crcpress.com/product/isbn/9781420066036

[23] “The Zattoo Homepage,” http://www.zattoo.com/,2010.

[24] A. Knauf, T. C. Schmidt, and M. Wahlisch, “ScalableDistributed Conference Control in HeterogeneousPeer-to-Peer Scenarios with SIP,” in Mobimedia ’09:

Proc. of the 5th International ICST Mobile MultimediaCommunications Conference, ser. ACM DigitalLibrary. Brussels,Belgium: ICST, Sep. 2009, pp. 1–5. [Online]. Available:http://dx.doi.org/10.4108/ICST.MOBIMEDIA2009.7436

[25] “The NIST JAIN-SIP homepage,”http://jain-sip.dev.java.net/, 2009.

[26] J. Rosenberg, “Interactive Connectivity Establishment(ICE): A Protocol for Network Address Translator(NAT) Traversal for Offer/Answer Protocols,” IETF,RFC 5245, April 2010.

[27] A. Knauf, G. Hege, T. C. Schmidt, and M. Wahlisch,“A RELOAD Usage for Distributed ConferenceControl (DisCo),” individual, IETF Internet Draft –work in progress 01, December 2010. [Online].Available:http://tools.ietf.org/html/draft-knauf-p2psip-disco

[28] “The PlanetLab homepage,” http://planet-lab.org/,2010.

[29] B. Abrahao and R. Kleinberg, “On the Internet DelaySpace Dimensionality,” in Proc. of the 8th ACMSIGCOMM Conf. on Internet Measurement (IMC’08).New York, NY, USA: ACM, 2008, pp. 157–168.

[30] L. Tang and M. Crovella, “Virtual Landmarks for theInternet,” in Proc. of the 3rd ACM SIGCOMM Conf.on Internet Measurement (IMC’03). New York, NY,USA: ACM, 2003, pp. 143–152.

[31] “The Cooperative Association for Internet DataAnalysis homepage,” http://www.caida.org/home/,2010.

[32] M. Castro, M. B. Jones, A.-M. Kermarrec,A. Rowstron, M. Theimer, H. Wang, and A. Wolman,“An Evaluation of Scalable Application-level MulticastBuilt Using Peer-to-peer Overlays,” in Proceedings ofthe Twenty-Second Annual Joint Conference of theIEEE Computer and Communications Societies(Infocom 2003), vol. 2. Washington, DC, USA: IEEEComputer Society, 2003, pp. 1510–1520.