1. INTRODUCTION ABSTRACT

Transcription

1 Deployment Issues of a VoIP Conferencing System in a Virtual Conferencing Environment R. Venkatesha Prasa i Richar Hurni ii H.S. Jamaagni iii H.N. Shankar iv i, iii {vprasa, hsjam}@cet.iisc.ernet.in i, iii Centre for Electronics Design an Technology Inian Institute of Science, Bangalore, Inia Telephone: ii hurni@ieee.org iv hn_shankar@yahoo.com ABSTRACT Real-time services have been supporte by an large on circuitswitche networks. Recent trens favour services porte on packet-switche networks. For auio conferencing, we nee to consier many issues scalability, quality of the conference application, floor control an loa on the clients/servers to name a few. In this paper, we escribe an auio service framework esigne to provie a Virtual Conferencing Environment (VCE). The system is esigne to accommoate a large number of en users speaking at the same time an sprea across the Internet. The framework is base on Conference Servers [14], which facilitate the auio hanling, while we exploit the SIP capabilities for signaling purposes. Client selection is base on a recent quantifier calle "Louness Number" that helps mimic a physical face-to-face conference. We eal with eployment issues of the propose solution both in terms of scalability an interactivity, while explaining the techniques we use to reuce the traffic. We have implemente a Conference Server (CS) application on a campus-wie network at our Institute. Categories an Subjects Descriptors C.2.4 [Computer-Communication Networks]: Distribute Systems Client / Server, istribute applications. General Terms Algorithms, Performance, Design, Theory. Keywors VCE, VoIP, Real-Time Auio, Simultaneous Speakers, SIP, Conference Server. ii Swiss Feeral Institute of Technology, Lausanne. Former visitor at CEDT. iv PESIT an NIAS, Bangalore, Inia. Permission to make igital or har copies of all or part of this work for personal or classroom use is grante without fee provie that copies are not mae or istribute for profit or commercial avantage an that copies bear this notice an the full citation on the first page. To copy otherwise, to republish, to post on servers or to reistribute to lists, requires prior specific permission an/or a fee. VRST'03, October 1-3, 2003, Osaka JAPAN. Copyright 2003 ACM /03/ $ INTRODUCTION Toay's Internet uses the IP protocol suite that was primarily esigne for the transport of ata an provies best effort ata elivery. Delay-constraints an characteristics separate traitional ata on the one han from voice & vieo applications on the other. Hence, as progressively time-sensitive voice an vieo applications are eploye on the Internet, the inaequacy of the Internet is expose. Further, we seek to port telephone services on the Internet. Among them, virtual conference (teleconference) facility is at the cutting ege. Auio an vieo conferencing on Internet are popular [25] for the several avantages they inhere [3,6]. Clearly, the banwith require for a teleconference over the Internet increases rapily with the number of participants; reucing banwith without compromising auio quality is a challenge in Internet Telephony. Aitional critical issues are: (a) packet elay, (b) echo, (c) mixing of auio from selecte clients, () automatic selection of clients to participate in the conference, (e) playout of mixe auio for every client, (f) hanling clients not capable of mixing auio streams (such clients are known as umb clients ), an (g) eciing the number of simultaneously active clients in the conference without compromising voice quality. While all the above requirements are from the technology point of view, the user's perspective an interactions are also essential factors. There is plenty of iscussion amongst HCI an CSCW community on the use of Ethnomethoology for esign of CSCW applications. The basic approach is to provie larger banwith, more facilities an more avance control mechanisms, looking forwar to better quality of interaction. This approach ignores the functional utility of the environment that is use for collaboration. Eckehar Doerry [4] criticizes this approach by saying "it is keeping form before function". Thus, the nee is to take an approach that consiers both aspects the technical an the functional. Regaring the functional aspect, we refer to [15] where it has been ealt with in some etail. In this work, we o not iscuss vieo conferencing; its inclusion oes not significantly benefit conference quality [4]. Our focus is on virtual auio environments. We first outline the challenges encountere in virtual auio conferences. Then we look into the motivations followe by relevant literature. In Section 5, we explain the architecture of our system. Section 6 comprises escription of the various algorithms use in our setup. We aress eployment issues. A iscussion on

2 performance follows. We conclue taking alongsie some implementation issues. 2. CHALLENGES IN VoIP CONFERENCING Many challenges arise in builing a VoIP application. The following are of particular concern in the process: Ease of use: Conferencing must be simple; users nee no omain expertise. Management (aition/removal) of clients an servers must be uncomplicate. Application evelopment shoul not presuppose specific characteristics of the unerlying system or of network layers. Ease of use may inclue leveraging reaily available, technically feasible an economically viable technologies. Scalability: Conferencing must seem uninterrupte uner heavy loas, i.e., when many aitional users are ae on. Traffic on WAN shoul not grow appreciably with the total number of clients; else, this has lea to congestion. So a means to regulate traffic to a minimum is neee for this kin of real-time applications. Interactivity: In Virtual Conferencing Environments (VCEs), we inten a face-to-face-like conferencing application that mimics a "real" conference, where more vocal participants invite attention. Turn-taking in floor occupation by participants must be aapte gracefully to give a feel of natural transition. Stanarization: The solution must conform to establishe stanars so as to gain interoperability an peer acceptance. The above requirements are place in the perspective of observations mae in earlier works (vie Sections 3 an 4) an will steer the VCE esign. 3. THE MOTIVATION Ramanathan an Rangan [20] have stuie in etail the architectural configurations comparing many conferencing architecture schemes taking into consieration the network elay an computation requirements for mixing. Functional ivision an object-oriente architecture esign that ai in implementation is presente in [1]. An overview of many issues involve in supporting a large conference is ealt in [8]. H. P. Dommel [5] an many others highlight floor control as another pivotal aspect to be taken into account in esigning a conferencing tool. Tightly couple conference control protocols in Internet belong to the ITU-T H.323 family [9]; however, they are mainly for small conferences. The latest IETF raft by Rosenberg an Schulzrinne [23] iscusses conferencing moels with SIP [22] in the backgroun. Aspects of implementation for centralize SIP conferencing are reporte in [26]. A new approach calle partial mixing by Raenkovic [18] allows for mixe an non-mixe streams to coexist. In all the above proposals, while there are some very useful suggestions, they share one or more of the following limitations: In an auio conference, streams from all the clients nee not be mixe. Actually, mixing many arbitrary streams [24] from clients egraes the quality of the conference ue to the reuction in the volume (spatial aspect of speech). The number of streams mixe varies ynamically epening on the number of active participants. This woul lea to fluctuations in the volume of every iniviual participant causing severe egraation in quality. Customize mixing of streams is not possible when many clients are active. There is a threshol on the number of simultaneous speakers above which increasing the number of speakers becomes counterprouctive to conference quality. Fixing the maximum number of simultaneous speakers is ealt in a recent work [15] using Ethnomethoology, an is conjecture to be three. Thus it is avisable to honour that constraint. There cannot be many intermeiate mixers (similarly, Conference Servers as in [10]) in stages as in [20] because it brings in inorinate elay by increasing the number of hops an is not scalable with interactivity in focus. Floor Control for an auio conference (even vieo conference) with explicit turn-taking instructions to participants reners the conference essentially a one-speakerat-a-time affair, not a live an free-to-interrupt one. This way, the conference becomes markely artificial an its quality egraes. Schulzrinne et al. [24], assume only one participant is speaking at a time. In this case, if applications are implemente with some control [5], the service becomes gagging for the users. Partial mixing [18] has a similar problem as that of mixing when more streams are mixe. Moreover, in [18], to allow impromptu speech, mixing is not one when the network can affor high banwith requirements for sening/receiving all the streams, but it is unnecessary [15]. For large conferences [23, 10] a centralize conference cannot scale up. With multicasting, clients will have to parse many streams an traffic on a client s network increases unnecessarily. Eviently, ifferent particular issues, all of which are a subset of requirements (efine in [14] an [16]) for a VoIP conferencing support, are tackle. Thus there is a nee to aress conferencing as a whole with all its requirements consiere concurrently. Towars this goal, the VoIP conferencing system we propose is intene to be scalable an interactive. We make use of the "Louness Number" for implementing floor control. This permits a participant to freely get into the speaking moe to interrupt the current speaker as in a natural face-to-face meeting. An upper limit on the number of floors (i.e., the number of speakers allowe to speak at the same time) is fixe using a conjecture propose in [15]. The work presente here is in continuation of our stuies into conferencing base on the Session Initiation Protocol in [14] an [16]. SIP, efine in [22] is now the most popular stanar for VoIP eployment an has been chosen for its strength, ease of use, extensibility an compatibility. This is the reason it will be in the backgroun of all controlling messages that will implicitly arise between the entities in our architecture. The actual messages are escribe in [16] an, as such, we o not present a complete escription of them here. 4. RELATED WORK The SIP stanar efine in RFC 3261 [22] an in later extensions such as [21] oes not offer conference control services such as floor control or voting an oes not prescribe how a

3 Fig. 1. Conference example 3 omains containing the necessary entities so that the conference can take place. conference is to be manage. However SIP can be use to initiate a session that uses some other conference control protocol. The core SIP specification supports many moels for conferencing [26, 23]. In the server-base moels, a server mixes meia streams, whereas in a server-less conference, mixing is one at the en systems. SDP [7] can be use to efine meia capabilities an provie other information about the conference. We shall now consier a few conference moels in SIP that have been propose recently [23]. First, let us look into server-less moels. In En-System Mixing, only one client (SIP UA) hanles the signaling an meia mixing for all the others, which is clearly not scalable an causes problems when that particular client leaves the conference. In the Users Joining moel, a tree grows, as each invite party constitutes a new branch in the istribution path. This leas to an increasing number of hops for the remote leaves an is not scalable. Another option woul be to use multicast for conferencing but multicast is not enable over Internet an only possible on a LAN presently. Among server-base moels, in a Dial-In Conference, UAs connect to a central server that hanles all the mixing. This moel is not scalable as it is limite by the processing power of the server an banwith of the network. Ahoc Centralize Conferences an Dial-Out Conference Servers have similar mechanisms an problems. Hybri moels involving centralize signaling an istribute meia, with the latter using unicast or multicast, raise scalability problems as before. However an avantage is that the conference control can be a thir party solution. Distribute Partial Mixing, presente in [18], proposes that in case of banwith limitation, some streams are mixe an some are not, leaving interactivity intact. Loss of spatialism when they mix an the banwith increase when they o not are open problems. A relate stuy [19] by the same author proposes conferencing architecture for Collaborative Virtual Environments (CVEs) but oes not provie the scalability angle without the availability of multicasting. With the limitations of propose conferencing systems in min, we will now etail our proposal. 5. SYSTEM ARCHITECTURE This section is eicate to the escription of the propose system architecture. However, as this paper constitutes the continuation of our work starte in [14] an furthere in [16], we will not present here all the etails about the propose entities an invite the reaers to consult the papers mentione above for a full an thorough escription. First, we o not restrict our conferencing system to work on small conferences only, but rather on large auio VCEs that have hunres (or even thousans) of users across a Wie Area Network (WAN) such as the Internet. This view stems from an appraisal that VCEs will gain in importance in the future, as interactive auio conferences will be more popular because of the sprea of the meia culture aroun the worl. Two issues must be taken care of when builing a VoIP conferencing system: (i) the front-en, consisting of the application program running on the en-users computers an (ii) the back-en that provies other application programs that facilitate conferencing an conference. The participating users are groupe into several omains. These omains are Local Area Networks (LANs), such as corporate or eucational networks. This istribute assumption asks for istribute controlling an meia hanling solutions, as centralize systems woul not scale for such very large conferences (vie Section 4). More explicitly, in each omain, we can ientify several relevant logical components of a conferencing facility (Fig. 1): ΠAn arbitrary number of en users (clients) that can take part in at most one auio conference at a time. Every user is

4 ΠΠinclue in one an only one omain at a given instant, but can move from omain to omain (nomaism). In our conferencing environment, these clients are regular SIP User Agents (SIP UAs), as efine in [22] so to gain in interoperability with other existing SIP-compatible systems. These clients are thus not aware of the complex setting that supports the conference an this is highlighte below. One SIP Server (SIPS) per omain, taking care of all the signaling aspects of the conference (clients joining, leaving, etc.) [16]. In particular, it is consiere as a physical implementation encompassing ifferent logical roles, namely a SIP Proxy Server, a SIP Registrar Server, a SIP Reirect Server an a SIP B2BUA (Back-to-Back User Agent) [22]. This physical implementation enables the hanling of incoming/outgoing SIP messages by one or another logical entity accoring to the nees. SIPS is entruste with maintaining total service an has many avantages such as (a) it works as a centralize entity that can keep track of the activities of the UAs in a conference; (b) it can o all the switching for proviing PBX features; (c) it can locate the UAs an invite them for a conference; () it can o the billing as well. SIPSs in ifferent omains communicate with each other using SIP messages as escribe in [16]. If the loa on a particular SIPS is too heavy, it can create another SIPS in the same omain so that the loa will be share. One Master Conference Server (M-CS) (simply a Conference Server (CS)) for each conference is create by the local SIPS when a conference starts. This server will be use for hanling meia packets for the clients of the omain. Its mechanism will be escribe in the next section. The M-CS will be able to create a hierarchy of CSs insie a omain by aing one or more Slave CSs (S-CSs) to accommoate all the active clients an prevent its own flooing at the same time. We will see this mechanism in some etail in the sequel. The entities escribe here are exhaustive an conform to the SIP philosophy. Thus, the use of SIP makes this architecture more useful an interoperable with any other SIP clients or servers. 6. ALGORITHMIC ISSUES 6.1 Selecting the Streams Similar to SipConf in [27], a Conference Server (CS) [17] has the function of supporting the conference; it is responsible for hanling auio streams using RTP. It can also ouble to convert auio stream formats for a given client if necessary an can work as Translators/Mixers of RTP specification behin firewalls. We have base the esign of our CS on H.323 Multipoint Processor (MP) [9]. In short, the MP receives auio streams from the enpoints involve in a centralize or hybri multipoint conference, processes them an returns them to the enpoints. An MP that processes auio prepares N Max auio outputs from M input streams after selection, mixing, or both. Auio mixing requires ecoing the input auio to linear signals (PCM or analog), performing a linear combination of the signals an reencoing the result in an appropriate auio format. The MP may eliminate or attenuate some of the input signals in orer to reuce noise an unwante components. Fig. 2. Schematic iagram of a CS The limitation of H.323 is that it oes not aress the scalability of a conference. The architecture proposes a cascae or aisy chain topology [10], which can be shown that it cannot scale up for a large conference. A CS serves many clients in the same conference. Thus it hanles only one conference at a time. Multiple CSs may coexist in a omain, as when there are several conferences uner way. Signaling-relate messages of CSs are ealt in [11]. The working of a CS is illustrate on Fig. 2: For each mixing interval, CS 1 chooses the best N Max auio packets out of the M 1 (using a criterion terme "Louness Number, escribe in the next subsection). It may possibly receive an sens these to CSs 2 to P. The set of packets sent is enote as ToOtherCSs. In the same mixing interval, it also receives the best N Max auio packets (out of possibly M 2 ) from CS 2, similarly the best N Max (out of possibly M P ) from CS P. For simplicity, we ignore propagation elay between CSs which inee can be taken into account; it is beyon the scope of this presentation. The set of packets receive is enote as FromOtherCSs. Finally, it selects the best N Max packets from the set {ToOtherCSs union FromOtherCSs} an passes these packets to its own group. It can be seen that the set {ToOtherCSs union FromOtherCSs} is the same at all CSs. This ensures that any client in the conference finally receives the same set of packets for mixing. Hence all clients obtain a common view of the conference. Similarly, for each time slot (packet time), a subset, F of all clients is selecte (using the same criterion) from the pool of packets from all other CSs plus the N Max clients selecte locally. Their packets are mixe an playe out at the clients. Accoring to [15], the carinality of F, F is N Max an is fixe at three. In our conferencing setup, selection is by the Master Conference Server (M-CS), which comes into the picture exclusively for meia hanling. Note that even if the SIP specification enables irect UA-to-UA meia communication in a one-to-one call, it is also possible to use the Conference Server for two-party calls, especially because it is then more functional to create a real conference by aing a thir an subsequently more participant(s). There are cases wherein the processing capacity of an M-CS is exceee as it may have too many packets from local omains an from remote omains to process. In that case, the M-CS will create one or many S-CS (Fig. 6) an transfer its own clients as well as the new clients to them. In this configuration, the

5 algorithm outline above will be slightly moifie, as the auio packets will go from clients to their eicate S-CS that will select N Max packets to sen to the local M-CS, which will then select N Max packets from all its S-CSs in the omain before sening them to the remote omains. The incoming packets from other omains will be receive by the M-CS, select N Max of them an sen them irectly to the omain clients, bypassing the S- CSs. This change implies that at most three intermeiate entities exist for each auio packet, instea of two in the conventional setup. As the extra hop happens insie the LAN suppose to have a high-spee connectivity, we consier that it shoul not prevent us from using this hierarchy of CSs when there s a nee to o so. 6.2 Louness Number (LN) A basic question to be answere by the CS is the following. In a mixing interval, how shoul it choose N Max packets out of the M it might possibly receive? One way is to rank the M packets receive accoring to their energies, an choose the top N Max. However, this is usually foun to be inaequate because ranom fluctuations in packet energies can lea to poor auio quality. This inicates the nee for a metric ifferent from mere iniviual packet energies. The metric shoul have the following characteristics [12]: A speaker (floor occupant) shoul not be cut off by a spike in the packet energy of another speaker. This implies that a speaker s speech history shoul be given some weight. This is often referre to as Persistence or Hangover. A participant who wants to interrupt a speaker will have to (i) speak louly an (ii) keep trying for a little while. In a face-to-face conference, boy language often inicates the intent to interrupt. But in a blin conference uner iscussion, a participant s intention to interrupt can be conveye effectively through LN. A floor control mechanism empowere to cut off a speaker forcefully must be ensure. These requirements are met by Louness Number [12], which changes smoothly with time so that the selection (aition an eletion) of clients for conference is graceful. LN (= ) is a function of the amplitue of the current auio stream plus the activity an amplitue over a specific winow in the past. Fig. 3. The ifferent winows use for LN computation The Louness Number is upate on a packet-by-packet basis. The basic parameter use here is packet amplitue, which is calculate as root mean square (rms) of the energies in auio samples of a packet, an enote by X K. Three winows are efine as shown in Fig. 3. The present amplitue level of the speaker is foun by calculating the moving average of packet amplitue (X K ) within a winow calle Recent Past Winow starting from the present instant to some past time. The past activity of the speaker is foun by calculating the moving average of the packet amplitue (X K ) within a winow calle Distant Past Winow, which starts at the point where the Recent Past winow ens an stretches back in the past for a pre-efine interval. The activity of the speaker in the past is foun with a winow calle Activity Horizon, which spans the recent past winow as well as the istant past winow an beyon if necessary. Though the contribution of the activity horizon looks similar to the contribution of the recent past an istant past winows, past activity is compute from activity horizon winow in a ifferently. Define the quantities uring these three intervals as L 1, L 2 an L 3. L 1 quantifies the Recent Past speech activity, L 2 the Distant Past speech activity an L 3 gives a number corresponing to the speech activity in the Activity Horizon winow quantifying how active the speaker was in the past few intervals. L 3 yiels a quantity that is proportional to the fraction of packets having energies above a pre-efine threshol (Eq. 3). The threshol is invariant across clients. Where 2 L1 = W = W tp WRP X K RP K = tp tp W RP W DP X K DP K = tp W RP (1) L (2) tp W AH L3 = * W AH K = tp I{ X 1 if K θ } = X K θ = 0, otherwise θ I (3) { X K θ } The threshol is a constant. is set at percent of the amplitue of the voice samples of a packet in our implementation here. Louness Number λ for the present time instant (or the present packet) is calculate as, λ = α1 *L1 + α2*l2 + α3*l (4) 3 Here 1 2DQG 3 are chosen such that: 0< DQG 3=1-1 2) Here, 1 is the weight given to the recent past speech, 2 is the weight given to istant past speech an 3 is the weight given to speech activity in the activity horizon winow consiere. 6.3 Safety, Liveness an Fairness The λ parameter KDV VRPH PHPRU\ GHSHQGLQJ RQ WKH VSUHDG RI the winows. After one conferee becomes silent, another can take the floor. Also, as there is more than one channel, interruption is enable. A lou conferee is more likely to be hear because of elevate λ. This ensures fairness to all conferees. After all, even in a face-to-face conference, a more vocal speaker grabs special attention. All these esirable characteristics are embee into the LN. A comprehensive iscussion on selection of the various parameters an the ynamics of LN are beyon the scope of this paper.

6 6.4 Selection Algorithm using the LN Following the evelopments in subsections 6.1 an 6.2, we present the simple algorithm that runs at each Master-Conference Server (Algorithm. 1). This algorithm is base on the iscussions in section 6.1. The globally unique set F is foun using this proceure. Repeat for each time slot at each M-CS { 1. Get all the packets from the Clients that belong to it. 2. Fin at most N Max Clients that have PD[LPXP RXWRI0&OLHQWVLQLWVGRPDLQ 3. Store a copy of packets from those N Max Clients in atabase DB Sen these N Max packets to other M-CSs (on Unicast or Multicast, epening on the configuration). 5. Similarly, receive packets from all other M-CSs an store them in atabase DB Now compare the packets in DB 1 an DB 2 on WKHEDVLVRI DQGVHOHFWDPD[LPXPRI N Max amongst them (to form set F) that shoul be playe out at each Client. 7. Sen the N Max packets in set F to the Clients in its omain. 8. Mix these N Max auio packets in set F after linearising an sen it to umb Clients in the omain. } Algorithm 1. Selection algorithm The mechanism propose here is also epicte on Fig. 6, where a single conference takes place between three omains. The shae clients are the ones selecte in their local omains; their auio streams will be sent to other CSs. 7. DEPLOYMENT ISSUES We now analyze eployment issues associate with conference management. How are omains to be organize to maximize the number of participants able to join? To aress this, we efine some useful parameters. ΠLet be the number of ifferent omains in which there are active clients in a given conference. ΠLet M i be the number of active clients present in omain i ( 1 i ) in a given conference. The total number of active clients in the conference is thus M = Mi. i= 1 ΠLet C be the maximum number of auio streams a Conference Server can hanle in a packet time, also calle capacity. C is set accoring to the processing power of the weakest CS in the conference but as it cannot be assume that we know it a-priori, it can be set accoring to some minimum system requirement a machine must meet in orer to take part in a conference. ΠLet N Max be the number of output streams a CS has to sen to other CSs in remote omains (see section 6.1). We will set N Max =3 (= F ), accoring to [15]. The optimization problem is now to fin the value of that maximizes the total number of clients M i serve by one CS in a omain with capacity C. We first ispose the case where the capacity is not exceee (the existing CS is not overloae), an then procee to the case where there exists a nee to create more CSs when a single CS is overloae. We assume that clients are equally istribute amongst the omains, as we may not have information to assume an a-priori istribution of the clients. We can specify no more than an upper boun on the number of clients acceptable, given the number of active omains. 7.1 Conferencing with only One Level of CSs In this subsection, we consier that we have only one CS, i.e., a unique M-CS in each omain. Thus it cannot be overloae. We consier that the system works as outline in section 6.1: The Clients sen their auio packets to their local CS, which selects N Max streams, before sening them to other CSs. In parallel, it also receives N Max streams for every other CSs before taking a ecision on which N Max streams will be selecte, sent an playe out at each iniviual clients. For system stability, any CS in the conference shoul be able to hanle its local clients in aition to the auio packets from other omains. Clearly then, the following inequality must hol for every omain: M C + NMax ( 1) (5) The limiting case of (5) (taking the equality) takes the form 2 M = ( C + NMax) NMax (6) To optimize with respect to M, we set M = 2 NMax ( C + NMax) = 0 (7) C + NMax yieling = (8) 2 N Max * = Rouning to nearest integer) an hence, M from (6). ([ ] C M Table 1. Values of an M compute for some values of C with N Max = 3. In Table 1, we give the values of an M that were compute using (8) an (6) with N Max = 3. We see that the values of an M, being epenent of C, are therefore base on the weakest CS. We see that there is a trae-off between M an. We coul amit

7 more omains in the conference, but at the expense of restricting the total number of clients M in the conference. While implementing an testing the Conference Servers on a Pentium III 1.4 GHz running Winows NT, we were able to set C=300. But with the avent of faster computers (> 3 GHz), one can easily set C to higher values an etermine an M accoringly. Fig. 4 shows a contour plot an Fig. 5, a 3D-mesh showing optimize solutions for CSs of ifferent capacities. These lea us to maximize the number of omains, an hence, to maximize the total number of clients base on the capacity of various CSs. In Fig. 4, the iniviual curves represent the total number of clients targete, an we select a lower value of, for capacity C, for targete M to reuce traffic on WAN. Fig. 5 represents a ifferent perspective of the same ata in 3D. to the other omains. Each newly create S-CS must run on a separate machine. The M-CS has to create more S-CSs if the number of active clients excees C in the course of the conference after the transfer. With this mechanism, the M-CS will be able to create utmost C NMax U = N ( 1) Max S-CSs, (10) as it must hanle 3 (= N Max ) packets for each local S-CSs an 3 (= N Max ) packets from each other remote omains. We can then calculate the maximum theoretical number of active clients Mi = U C in each omain as well as M, for the whole conference as M = U C. Fig. 4. Contour Plot of Capacity versus Optimum number of omains for various conference sizes 7.2 Conferencing with Two Levels of CSs Now consiering the case where the number of clients in a M particular omain is too large, i.e., Mi (9) one has to avoi the enial of service for new clients ue to overloaing of Conference Server. This problem can be solve by introucing a secon level of CSs insie the given omain, as in Fig. 6. The existing M-CS creates a Slave CS (S-CS) that can hanle up to C en-users an to which it transfers all its active clients. Here, the system works ifferently as outline in section 6.1: The Clients sen their auio packets to their local S-CS, which selects N Max streams, before sening them to a local M-CS, which will procee in the same way, before sening N Max streams Fig. 5. 3D Plot of Capacity versus Optimum number of omains for various conference sizes Of course, one coul further create a thir level in the hierarchy, giving the possibility of accommoating even more clients. This may be unnecessary as the number of possible clients is large enough with two levels. 8. PERFORMANCE DISCUSSION We now analyze the performance of the algorithm presente in subsection 6.3, i.e., the one taking care of the exchange of auio packets between the ifferent omains. Note that the packets that are transiting within the LAN take avantage of the higher capacity (generally couple with multicast capabilities) an therefore o not require a performance analysis.

8 Fig. 6. Example of a 2-level hierarchy of Conference Servers; the shae Clients are the one selecte by the M-CS an will be sent to other omains CSs. Thus we have to look only at the RTP packets over the WAN, i.e., between participating M-CSs. As each M-CS from a omain will be sening only N Max out of M packets to the other CSs M ( >> N Max ), the banwith use by the application over a WAN is upper-boune by the following expression. The total number of auio packets transiting over the WAN for each time slot is = = NMax which is quaratic in the i 1 j 1, j i number of omains (i.e., O( 2 )). However, it is inepenent of the total number of active clients. This woul not have been the case ha all packets been sent over the network in each time slot. The saving is tremenous. Yet, one may conten that sening three packets to an from all omains is a waste of resources, as most of these streams will not be selecte. If just one client is active, selecting a subset of clients in that omain is unnecessary. Pessimistic an optimistic algorithms as presente in the sequel aim at reucing the traffic further by harnessing the slow varying nature of the LN. 8.1 Pessimistic algorithm Consier a scenario wherein the lowest LN (calle LN t ) of the three globally selecte streams (set F of Section 6.1) excees the LN of the most ominant stream of a omain. Eviently, the chances that the next two ominant streams of that omain being selecte to F in the next packet perio are less. Here, we sen this most ominant stream an withhol the other two. There may be an error in unique selection across all omains for one packet perio only. As LN varies slowly, the error woul get automatically rectifie in a subsequent packet perio (slot). In this algorithm, there is at least one stream in each perio. The net network traffic in a packet perio in the best case is ( 1), 2 i.e., O ( ) using unicast, instea of ( 1) NMax. Consierable valuable banwith can be save using this heuristic. The resulting traffic complexity reuces from O( 2 ) to O() in multicast-enable networks. Initialize LN t = 0 at an M-CS/S-CS A. In the first time slot (packet time), each CS sens the top N Max streams (base on their LN) to all other CSs. At each M-CS/S-CS an for each packet time: B. Fin the value of lowest LN of the N Max globally selecte streams (set F) from the previous time slot. Set LN t with this value. C. At each CS omain, select the N Max local streams that have maximum value of LN (ToOtherCSs set). D. Select streams that have LN > LN t. IF there are >= N Max streams with LN > LN t then sen top N Max to other CSs. ELSE IF there are (N Max -1) streams with LN>LN t then sen top (N Max -1) plus the one lower than LN t (i.e., top N Max ) to other CSs. ELSE IF there are (N Max -2) streams with LN>LN t then sen top (N Max -2) plus the one lower than LN t (i.e. top (N Max -1)) to other CSs. ELSE IF there are NO streams with LN> LN t then sen top 1 stream to other CSs. E. Packets sent in step D form DB 1. Packets receive from other CSs form DB 2. F. For this time slot, fin global N Max streams base on LN from DB 1 U DB 2 (set F) G. Sen set F to the clients in its omain. Upate LN t for the next perio. Algorithm 2. Pessimistic algorithm to reuce the number of packets sent over the Internet.

9 In this algorithm the saving in traffic is at the cost of relaxing the conition of formation of globally unique set F. However, the iscrepancies in selecte streams at ifferent omains remain for a short perio of time epening on the transportation elay between any two omains. Even for a total elay of 400ms, for only 10 packet time slots the uniqueness is lost. This uration in a real-time interactive conversation is non-perceivable by the listener. In the case that there is a joke an every one laughs, then there woul be suen rise in the number of packets an it woul be upper boune by O ( 2 ) N for a short perio. Max 8.2 Optimistic Algorithm The traffic can be reuce further. The scheme in the following algorithm (Algorithm. 3) is withholing all the streams that have less value of LN compare to the least of the three in the set F. We can fin the correct an unique three streams after a few time slots epening on the transportation elay between the omains. As the packet perio is of the orer of 40ms, the error in the selection is unnoticeable. The number of streams on network in this case is always restricte to N Max (=3). Even without Voice Activity Detection (VAD), there will be no more than three streams in the network in the best case, thus the total traffic is constant. A suen burst of traffic, as escribe in 8.1, is a particular case. These avantages are ue to exploitation of the characteristics of LN. Initialize LN t = 0 at an M-CS/S-CS A. In the first time slot (packet time), each CS sens the top N Max streams (base on their LN) to all other CSs. At each M-CS/S-CS an for each packet time: B. Fin the value of lowest LN of the N Max globally selecte streams (set F) from the previous time slot. Set LN t with this value. C. At each CS omain, select the N Max local streams that have maximum value of LN (ToOtherCSs set) D. Select streams that have LN > LN t IF there are >= N Max streams with LN > LN t then sen top N Max to other CSs. ELSE IF there are (N Max -1) streams with LN>LN t then sen top (N Max -1) an see E. ELSE IF there are (N Max -2) streams with LN>LN t then sen top (N Max -2) an see E. ELSE IF there are NO streams with LN> LN t then on t sen any stream. E. Exceptions: IF the stream that was in F in the last interval belongs to this CS then select an sen that stream even if its LN is now < LN t. (Note this occurs only at that CS which ha the stream that was the last of the three in the previous packet perio.) F. Packets sent in step D an E form DB 1. Packets receive from other CSs form DB 2. G. For this time slot, fin global N Max streams base on LN from DB 1 U DB 2 (set F). H. Sen set F to the clients in its omain. Upate LN t for the next perio. Algorithm 3. Optimistic algorithm to reuce the number of packets sent over the Internet Furthermore, when VAD is use [13], it woul further reuce the traffic by sening the heaer part of the RTP packet only an not the whole packet, thus in orer to keep upating the LN across. The traffic here in this case is O(N Max ) for multicast an O() for unicast. We see that the above algorithms save banwith an computation at each CS, an leas to a scalable architecture with multiple CSs mainly because clients are groupe in omains. The necessary banwith is not epenent on the total number of active clients. As the CS always chooses the best three clients out of all the clients assigne to it in the omain, aition of new clients to the existing conference will not cause any scalability problem. 8.3 Availability of Multicasting In the architecture that has been propose, no assumption was mae about the availability of multicasting support from the network. The traffic will be further reuce if multicasting is available over WAN. It is simple to show that the orer of traffic woul ten to become O() from O( 2 ). This is an approximation as saving in multicasting epens also on the topology. The analysis was one for the case wherein multicast is not available (a realistic assumption in toay s Internet). The avantage of this set up is that we can use it even if multicasting is partially available. We can instruct CSs uring the set-up phase to sen unicast packets to those CSs that cannot receive multicast packets whereas CSs on multicast enable routers can exchange packets on a multicast aress. The ata structures an conference objects insie a CS is given in [14]. Fig. 7. User Interface for setting the weight for N Max auio streams (setting Self-bar to zero avois echo). 8.4 Quality Improvement The observe improvement in the perceive quality of the conference service is ue to: (1) limiting the number of concurrent speakers to a low number such as three. Generally, in a conference if more than two participants speak the intelligibility is lost. The conversational analysis emonstrates that there woul be a repair mechanism [15] in such a case. (2) Delay: The auio stream between any two clients will pass through at most two CSs thus reucing the en-to-en elay. For a large conference there might be three CSs however, one hop is within the omain

10 incurring negligible elay. (3) As the streams are mixe only at the clients, there can be a customize mix of the streams. The iniviual tuning of mixing with weights the spatialism is preserve. Fig. 7 shows the user interface for the same. The echo when self-stream is selecte can be avoie by reucing the weight. Nonetheless, feeback helps in reassuring speaker that he/she is hear by all. 9. CONCLUSION In this paper, we have presente a iscussion on a voice-only virtual conferencing environment. We have argue that the istribute nature of eployment here makes it scalable. Interactivity is achieve by aapting a recent stream selection scheme base on Louness Number. Aitionally, we incorporate a result from a more recent work [15] where the sufficiency of three simultaneous speakers has been emonstrate. Thus, there is significantly effective utilization of banwith. A mixe stream is playe out at each client; each client may choose to have a customize mix since mixing is one at the local terminal of each client. These rener impromptu speech in a virtual teleconference over VoIP a reality, as in a real face-to-face conference. Compatibility is assure thanks to the use of SIP, the most soughtafter signaling protocol. To ensure a satisfying performance, we o not eman the availability of multicast, but use it if an when available. The traffic in the WAN (Internet) is upper-boune by the square of the number of omains, -- further reuce by using heuristic algorithms -- which is far below the total number of clients in the conference. This is ue to the use of a Conference Server local to each omain. VAD techniques help further traffic reuction. Using SIP stanar for signaling makes this solution highly interoperable. We have implemente a CS application on a campus-wie network. We believe this new generation of virtual conferencing environments will gain more popularity in the future as their ease of eployment is assure thanks to reaily available technologies an scalable frameworks. 10. REFERENCES [1] L Aguilar et al., Architecture for a Multimeia Teleconferencing System, in Proceeings of the ACM SIGCOMM, Aug 1986, pp [2] Carsten Bormann, Joerg Ott et al., Simple Conference Control Protocol, Internet Draft, Dec [3] M. Decina an V. Trecori, "Voice over Internet Protocol an Human Assiste E-Commerce", IEEE Comm. Magazine, Sept. 1999, pp [4] Eckehar Doerry, "An Empirical Comparison of Copresent an Technologically-meiate Interaction base on Communicative Breakown", Ph Thesis, Grauate School of the University of Oregon, [5] H. P. Dommel an J.J. Garcia-Luna-Aceves, "Floor Control for Multimeia Conferencing an Collaboration", J. Multimeia Systems, Vol. 5, No. 1, January 1997, pp [6] Amitava Dutta-Roy, "Virtual Meetings with esktop conferencing", IEEE Spectrum, July 1998, pp [7] M. Hanley an V. Jacobson, "SDP: Session Description Protocol", RFC 2327, IETF, April [8] M. Hanley, J. Crowcroft et al., "Very large conferences on the Internet: the Internet multimeia conferencing architecture", Journal of Computer Networks, vol. 31, No. 3, Feb 1999, pp [9] ITU-T Rec. H.323, Packet base Multimeia Communications Systems, vol. 2, [10] P. Koskelainen, H. Schulzrinne an X. Wu, "A SIP-base Conference Control Framework", NOSSDAV 02, May 2002, pp [11] R Venkatesha Prasa et al., Control Protocol for VoIP Auio Conferencing Support, International Conference on Avance Communication Technology, Mu-Ju, South Korea, Feb 2001, pp [12] R Venkatesha Prasa et al., "Automatic Aition an Deletion of Clients in VoIP Conferencing", 6 th IEEE Symposium on Computers an Communications, July 2001, Hammamet, Tunisia, pp [13] R Venkatesha Prasa, H S Jamaagni, Abjijeet, et al Comparison of Voice Activity Detection Algorithms, 7th IEEE Symposium on Computers an Communications. July 2002, Sicily, Italy, pp [14] R. Venkatesha Prasa, Richar Hurni, H S Jamaagni, A Scalable Distribute VoIP Conferencing using SIP, Proc. of the 8 th IEEE Symposium on Computers an Communications, Antalya, Turkey, June [15] R Venkatesha Prasa, H S Jamaagni an H N Shankar, "On Problem of Specifying Number of Floors in a Voice Only Conference", To appear in IEEE ITRE [16] R. Venkatesha Prasa, Richar Hurni, H S Jamaagni, "A Proposal for Distribute Conferencing on SIP using Conference Servers", To appear in the Proc. of MMNS 2003, Belfast, UK, September [17] R. Venkatesha Prasa, H.S. Jamaagni, J. Kuri, R.S. Varchas, A Distribute VoIP Conferencing Support Using Louness Number, Tech. Rep. TR-CEDT-TE [18] M. Raenkovic et al, "Scaleable an Aaptable Auio Service for Supporting Collaborative Work an Entertainment over the Internet", SSGRR 2002, L'Aquila, Italy, Jan [19] M. Raenkovic, C. Greenhalgh, S. Benfor, Deployment Issues for Multi-User Auio Support in CVEs, ACM VRST 2002, Nov. 2002, pp [20] Srinivas Ramanathan, P. Venkata Rangan, Harrick M. Vin, Designing Communication Architectures for Interorganizational Multimeia Collaboration, Journal of Organizational Computing, 2 (3&4), pp , [21] A. B. Roach, " Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, IETF, June [22] J. Rosenberg, H. Schulzrinne et al., "SIP: Session Initiation Protocol", RFC 3261, IETF, June [23] J. Rosenberg, H. Schulzrinne, Moels for Multy Party Conferencing in SIP, Internet Draft, IETF, July [24] H. Schulzrinne et al., "RTP: a transport protocol for realtime applications", RFC 1889, IETF, Jan [25] Lisa R. Silverman, "Coming of Age: Conferencing Solutions Cut Corporate Costs", White Paper, [26] Kunan Singh, Gautam Nair an Henning Schulzrinne, "Centralize Conferencing using SIP", Proceeings of the 2n IP-Telephony Workshop (IPTel), April [27] D. Thaler, M. Hanley an D. Estrin, "The Internet Multicast Aress Allocation Architecture", RFC 2908, IETF, Sept