Proposed Quick Conferencing Setup

When an end user is going to create an audio conference in a Peer-to-Peer system, he should already be aware of the information about the members of this audio conference including other members’ locations, the bandwidth of the other members and properties of all media streams. Then this end user will dial-out to all the members he wants to invite into the audio conference. This type for forming an audio conference gets acceptance of the most popular VoIP software－Skype.

All members who intend to participate in this audio conference must pre-know the location or the phone number of this audio conference and then in a particular appointed time all members of the audio conference dial-in to the conference founder to begin an audio conference in contrast.

The last method for creating an audio conference is that participants of the audio conference may join the proceeding conference any time. When an audio conference is activated, each user knowing the location of the members of the audio conference can join the conference or every member of the audio conference can send the invitation to any end users to invite them joining the conference, much similar to full mesh conferencing protocol.

In brief, all the aforementioned modes have one important key in common that is the location of users. No matter dial-in, dial-out or P2P modes they all have to be aware of the location of the participants who intend to join the audio conference, or the founder of the audio conference. Our proposed quick conference setup scheme definitely focuses on the location of the participants of the audio conference including the founder and the others who intend to join the conference.

Three parts of our proposed scheme just resemble the modes mentioned above－

dial-in, dial-out and P2P, but we integrate this three modes into one simple mechanism. It calls the user who creates the audio conference “the founder” which looks more like a rendezvous place.

Figure 3.2 Create an audio conference: (a) super-node (b) founder.

Setting up an audio conference needs to perform functions one by one, initiation, mode verification and start the audio conferencing, and initiation for both the founder

Create an audio

and super-node of the founder, mode verification for the founder to choose a mode and after all the audio conference starts. The next paragraphs explain the details of the functions.

3.1.1 Initiation

This section and next section describe the P2P mode (much similar to full mesh protocol) regarding how this mode works and what the benefits it has. In addition, some initial processes of the founder and super-nodes have to be done in order to create an audio conference using our proposed scheme.

When a particular user wants to create an audio conference, there are two assignments triggered. One is that the founder will send a NOTIFY in SIP message to his super-node of P2P system and the founder information will be stored in the conference list created by DHT. The conference list has duplications in every super-node to inform new users connecting to the P2P network. Another is that super-node will receive the NOTIFY message and begin to arrange the deployment (see the left side of Figure 3.2). These events also happen in other two modes for the initiation of creating an audio conference.

The super-node will send out the NOTIFY message to other super-nodes to notify other users who are under control of other super-nodes that there is an audio conference created when it receives the NOTIFY message, which is from the founder of an audio conference. The super-nodes will also arrange the relay nodes and the relay backup nodes for the audio conference and inform the founder of the audio conference what nodes could be the candidates of the relay nodes.

There are two crucial items to be measured for a candidate:

z Communication tag

The tag labels that the user is busy in communication with another user, including the users in any audio conference.

z RTT

Choose the nodes with the minimal RTT.

At first, the super-nodes will abandon the nodes with the communication tag on, because the nodes are considered too busy to process the works of a relay node. The major norm has to be measured to elect the candidates of the relay nodes in both the DHT side and the founder side. The super-nodes of DHT measure the RTT (Round Trip Time) in OPTIONS message and elect the nodes of the minimal RTT between the super-nodes and nodes to become the candidates of the relay nodes. Then super-node of the founder will inform the founder the candidates in OPTIONS message and the founder will measure these candidates in OPTIONS message to get an appropriate one of the RTT (minimal for sure) and the capacity of the candidate nodes.

The founder receives the relay node list by OPTIONS message from his super-node, and then the founder could choose any nodes in the list or by measuring the nodes of the relay node again to elect the best node. Regarding what situation the system will use the relay nodes for transmitting the media streams is presented in Section 3.2.

3.1.2 P2P Mode

If the founder choose the P2P mode in the initiation of creating an audio conference after sending the NOTIFY message to super-node, the audio conference

the founder will wait for the users sending the JOIN message to him and sending the CONNECT message back to the users, sending the JOIN message to make them becoming the participants of the audio conference. The maximal numbers of the participants is up to 10 for a small-and-medium size audio conference, thus the founder will only allow 10 participants at most in the audio conference the founder created, and discard the subsequent joining users. And our simulation will present that 10 participants is the maximal numbers of the participants in an audio conference.

Figure 3.3 P2P mode signaling delivery.

The participant of the audio conference can invite any users in the Peer-to-Peer network as well as in the Full mesh conferencing model (see the Figure 3.3). The participant can look up the location of the user he intends to invite, and use the JOIN message to inform the user where the founder of the audio conference is. After this occurrence, the permission of joining the audio conference is controlled by the founder who can decide whether to allow a user to participate in the audio conference.

Founder Participant Super-node User I

Lookup for User I

Location of User I

JOIN message CONNECT message

CONNECT OK message

If the user joining is permitted, the founder will send CONNECT OK message including the information of the other participants (such as location and properties of media stream), otherwise it sends CONNECT Reject message to deny the user from the audio conference. The founder will automatically discard the user by using CONNECT Reject message to inform the user intending to join if the number of users in the audio conference reached the limit.

3.1.3 Dial-in and dial-out modes

Dial-in mode and Dial-out mode are much similar to their operations, the only and large difference of these two modes is apparent to their appellations. In contrast, they all need the participants to make an appointment in a particular time, and then they would dial in or out a number simultaneously to form an audio conference at the time they appointed. Thus these two modes will be integrated including the P2P mode into the one scheme we proposed.

It can start the audio conference immediately if the founder dials out a number list of the participants he already knew the locations and it will transform the audio conference into the P2P mode. The founder also can wait for the users signing in even the founder already knew a location list of the users he wants to invite after he send the NOTIFY message to the DHT for notifying the other users on P2P network. The NOTIFY message will inform the users where the founder is and when the audio conference will start. For dial-out mode, the founder will store a member list created at the beginning that the founder started waiting for recording the properties of the signing-in users (the most important one is the location of a user). For dial-in mode, the founder utilizes the NOTIFY message to communicate with users who have the

In the dial-out mode, when the time the founder set at the beginning of creating the audio conference expires, the founder will choose at most 10 members of the audio conference and dial out to them; for the dial-in mode, the users intending to join may dial in simultaneously so the founder should abandon some users if number of dial-in users exceeds 10. For both two modes, once the audio conference is established, the conference will be transformed into P2P mode immediately. If there is no user who intend to join the conference the founder created, the founder has two methods for operation. The founder can just abort the whole audio conference and shut it down. The other method is that the audio conference mode will be transformed into P2P mode regardless of the number of users intending to join.

Figure 3.4 Procedure of dial-in and dial-out mode.

Create an audio conference

A

dial-in and dial-out

dial-in or dial-out Send NOTIFY

Founder

waiting for participants

yes no

P2P

time expire dial-out

What have been addressed in this paragraph is that the users are noticed by NOTIFY message DHT sent in all modes of our proposed mechanism. That is important because many users may not be aware of an audio conference being setup.

And it will cause the users who intend to join the specific audio conference to miss the opportunity of joining.