Summary

In this chapter, a new setting up conference mechanism which integrates the benefits of the centralized server model, and end-user mixing models has been presented. This mechanism not only takes the advantages of existing models but also utilizes the advantages of the Peer-to-Peer network. But the previous existing models did not utilize these advantages. Utilizing the Peer-to-Peer network (Chord) in the audio conference is rare in many related researches. Our new mechanism for setting up a conference is not operated individually like three separate modes: dial-in mode, dial-out mode (centralized server) and P2P mode (end-user mixing); instead, these modes will interact with each other.

Second, an improved conferencing control protocol extended from Mutualcast audio conferencing control protocol solves some problems such as packets loss and congestion in the original Mutualcast over the Internet. And it comes with a simple

mathematical analysis of our improved conferencing control protocol, and analysis points out the improvement on reducing the total number of packets by separating the mixed packets from original path to another path. The performance verification will be presented in Chapter 4 including packets drop, throughput and packet delay.

Chapter 4 Simulation and Numerical Results

Simulation will show the performance of our proposed scheme, and observation of the results of simulation will reflect the improvement between our proposed scheme and the original Mutualcast. The audio conference setting up is difficult to measure, so we focus on the audio conferencing media streaming control protocol only. In this chapter, simulation environment will be introduced first and then the simulation results and analysis will be interpreted in turn.

4.1 Simulation Environment

In order to demonstrating the performance of our proposed scheme, we use NS-2 (version 2.31) tool [21] and the ns2VoIP module [22] which has been developed by the Computer Networking Group of the Information Engineering Department of the Pisa University, Italy. For simulation convenience, it has to fix and adjust the NS-2 and the ns2VoIP module to match the original Mutualcast conferencing control protocol and our improved Mutualcast. Our simulation network topology is presented in Figure 4.1. Our proposed improved conferencing control protocol will utilize the relay nodes to retransmit mixed frames from mixers.

There are some simulation assumptions to be set constantly to compare the difference between two protocols. The ns2VoIP will be tuned to constant bit rate (CBR) like in order to build multiple sessions of audio conferencing without silence

suppression. VoIP traffic without silence suppression, with format of G.711 codec, 160 bytes payload and 20ms intervals (64kbs) will be the basis for the encode/decode media streams in both original Mutualcast and our proposed improved conferencing control protocol, and numbers of relay nodes used by members of the audio conferencing is listed in Table 4.1. The number of relay nodes will grow up with the increasing members of the audio conferencing. Additional relay nodes are used in order to separate the traffic load on a network bottleneck and to reduce the individual upload bandwidth. And the simulation results will be presented and analyzed in Section 4.2.

Figure 4.1 Simulation network environment.

Table 4.1 Simulation of using relay nodes parameters

Protocol 3 4 5 6 7 8 9 10

4.2 Simulation Results

It should be clear in our simulations environment of NS-2 and ns2VoIP before addressing simulation results and analysis. Since Mutualcast audio conferencing control protocol is a rough prototype presented on a conference and Mutualcast is proprietary, we imitated the Mutualcast protocol according to its algorithm and encode/decode of ns2VoIP module. Although there might be some deviations in our simulations from actual scenarios, the subsequent simulation results will show the performance improvement of our proposed conferencing control protocol.

4.2.1 Packets drop

The unmixed packets and mixed packets will both be counted into total amount of the packet loss. If the unmixed packets are lost, the mixed packets will not be delivered in original Mutucalcast and will cause long packet delay in our proposed scheme. If the mixed packets are lost, the quality of service will be intolerable in both original protocol and our proposed scheme.

In our packets drop simulation, the members of the audio conference will start from 4 members to 10 members. It is the same for 3 members in original protocol and our proposed protocol. And our proposed protocol will use relay nodes (in Table 4.1) for distributing upload traffic load on user nodes switching to relay nodes.

Table 4.2 illustrates the comparison of the packets drop between the original scheme and our proposed scheme. Packet loss rate are calculated as the ratio of total packets dropped divided by total packets sent. It will be the index of the quality of

service of voice delivery.

Table 4.2 Simulation Result of Packet Drop Packet Drop (%)

According to the packet drop data illustrated in Figure 4.2, our proposed audio conferencing control protocol has a significant improvement compared to the packet drop in original Mutualcast. In Figure 4.2, our proposed scheme causes the packet drop in 8 nodes and strikingly packets drop from 9 nodes to 10 nodes. In contrast, the original Mutualcast has strikingly packets drop from 6 nodes to 10 nodes and it is consistent with the report of the original Mutualcast conferencing media stream control protocol [15]. The original Mutualcast are capable of tolerating the members of the audio conference up to seven members. In original Mutualcast, when the members of the audio conference grow up to 10 members, its packet drop rate will rise up to 10.27% and that means out of 9 unmixed packets delivered to appointed mixer on the network, one packet will get lost. It is a serious problem because the mixer in turn could not receive all appropriate unmixed packets, and one way to solve this problem is to drop all unmixed packets in buffer at a time for the original Mutualcast, and another is buffering all unmixed packets until the time we consider the packet(s) lost expires. Even though it is not always the unmixed packet loss, the

0 2 4 6 8 10 12

1 2 3 4 5 6 7 8 9 10 11

數列1 數列2

Figure 4.2 Simulation result of packet drop.

10 members participating in an audio conference is a bottleneck in our proposed conferencing scheme (in the original Mutualcast as well) because excess of packets will be delivered on the simulation network and handled by the appointed mixers. The peer nodes upload bandwidth and the bottleneck of the simulation network will be congested with the excess of packets. Packet loss for both unmixed packets and mixed packets, will affect mixed-packet loss and voice delivery quality of the audio conference. And packet loss will also affect the throughput of the audio conference in both original Mutualcast and our proposed scheme. The next section focuses on the throughput which is also an index for quality of service in audio conference.

Improved Original

nodes

Packet Lost Rate (%)

4.2.2 Throughput

In this section, the throughput and the behavior of mixed packets are analyzed only to simplify the simulations because the mixed packets play an important role in original Mutualcast and our proposed conferencing control scheme. And relations are analyzed between the throughput and numbers of members in the audio conference and packets dropped.

Table 4.3 Simulation result of throughput Throughput (Kbit/s)

Nodes Original Proposed

4 767.1496 769.3552

5 1278.5827 1281.5329

6 1571.2307 1920.6115

7 1304.0548 2688.0913

8 1195.3364 3136.2000

9 775.3169 2305.7397

10 489.4176 1353.2886

Table 4.3 illustrates comparison of throughput of the mixed packets delivered on the simulation network between the original scheme and our proposed scheme. In Table 4.3, the throughput is the total sum of the mixed packets which all nodes received, and it uses kilo bits per second as the unit of the throughput measurement in our throughput simulation. Analysis of 4 and 5 members in audio conference shows that the original Mutualcast conferencing control protocol and our proposed scheme are similar for a smooth traffic on the simulation network until 6 to 10 members in the original Mutualcast and 9 to 10 members in our proposed scheme, and it is consistent

According to the throughput data illustrated in Figure 4.3, our proposed audio conferencing control protocol has a much better throughput improvement compared to the original Mutualcast until the members in the audio conference is close to 9 and 10.

When the participants of an audio conference come to 7, 8 and 9, it is apparent that there is a great difference in the throughput. Even though the throughput of 10 members participating in an audio conference is not excellent as before (less members in an audio conference), our proposed conferencing control protocol features doubled throughput of the original Mutualcast protocol.

0

Figure 4.3 Simulation result of throughput.

The inferior throughput follows the packet drop and comparison of Figure 4.2 and Figure 4.3, it should be clear that the relation of the throughput and the packet loss. With high packet loss rate, it will result in the inferior throughput especially at 10 participants in an audio conference with an excess of the unmixed and mixed packets.

Improved Original

Throughput

nodes

4.2.3 Packet delay

Packet delay is important for the VoIP traffic and its advanced application in audio conferencing because the longer the packet delay, the lower the quality of service that users can feel. The long packet delay also leads to the asynchronous communication in an audio conference with a large number of participants.

Table 4.4 Simulation result of packet delay Packet Delay (ms)

Nodes Original Proposed 4 37.047 43.832 5 36.755 44.538 6 43.885 46.117 7 43.383 48.407 8 43.709 48.640 9 42.321 46.130 10 42.245 46.316

Table 4.4 illustrates comparison of packet delay of the mixed packets delivered on the simulation network between the original scheme and our proposed scheme.

Only mixed packets are emphasized because the mixed packets are more important than the unmixed packets. In Table 4.3, packet delay of the original Mutualcast conferencing control protocol is better than the delay of our proposed conferencing control protocol because of the utilization of relay nodes which receive the mixed packets from mixers and retransmit them to participants. It causes a little longer packet delay in our proposed scheme for using the relay nodes.

According to the throughput data illustrated in Figure 4.4, our proposed audio

Mutualcast in our simulation. It is well known that in order to allow natural conversation, the mouth-to-ear latency of a voice-communication should not exceed 300 ms [20].

30 35 40 45 50 55 60

1 2 3 4 5 6 7 8 9 10 11

nodes

ms

數列1 數列2

Figure 4.4 Simulation result of packet delay.

In our proposed scheme, the packets delay of 9 members in an audio conference descends slightly as compared with the 8 members in an audio conference because the packet loss results in less mixed packets being delivered along the path between mixers and relay nodes. While packets delay of the original Mutualcast conferencing control protocol is mitigating starting from 6 members to 10 members participating in an audio conference because the packet drop occurred, and it means the simulation network is congested by the excess of packets. This makes the packets delay increased to the largest value in the simulation.

Improved Original

4.3 Summary

In Chapter 4, the comparison of the original Mutualcast conferencing control protocol and our proposed improved Mutualcast scheme is presented and the simulation results show the improvement on packet drop and throughput with a little cost of the packet delay.

To reduce the traffic, both received and delivered packets along the path between the mixers and participant is what our proposed scheme addresses, and simulation results of the packets drop and throughput approved our improved approach. Low packet drop rate and high throughput is the major improvement of our proposed scheme and on the other hand the longer packets delay must be solved.

Chapter 5 Conclusion and Future Works

In this thesis, we proposed a simple audio conferencing system including a new mechanism integrated into Peer-to-Peer network for setting up an audio conference and an improved conferencing media streaming control protocol for a pure Peer-to-Peer like media streaming control protocol-Mutualcast.

Setting up an audio conference is a pre-process in our proposed scheme even for all audio conferences, so establishing an audio conference will always take a while and participants are unable to do anything during this period of time. Eliminating or reducing the time wasted on setting up or speeding up the gap between users joining and starting to communicate with other participants is worthy to study, but setting up is ignored by most studies.

Our proposed scheme integrate three major conference modes, dial-in, dial-out (central server mixing) and P2P (end-user mixing), into a new mode with Peer-to-Peer network which is not utilized by previous three modes. In this new mode of setting up an audio conference three previous modes will interact with each other as well as with Peer-to-Peer network, they are not individually operating. It would reduce partial wasted time in certain scenarios.

An improved audio conferencing media streaming control protocol originated from the Mutualcast [15] is proposed. Our proposed protocol reduces the amount of packets a participant has to upload by deploying relay nodes which switch the delivery path of the mixed packets. Our scheme is evaluated by simulation in the aspects of the packet dropped and throughput.

Comparisons of the original Mutualcast and our proposed conferencing control protocol were presented in Chapter 4 including packet drop, throughput and packet delay. Although the method of original Mutualcast is not open to public and no module in NS-2 is available to simulate the protocol, we modified the necessary functions to accommodate our task. As a result, the simulation uses the NS-2.31 and the ns2VoIP module developed by the Computer Networking Group of Pisa University in Italy show that our proposed conferencing control protocol has a superior improvement comparing with the original Mutualcast, but our proposed scheme pays the cost of longer packets delay for using Relay nodes.

In the future, our proposed audio conferencing system faces many issues that should be solved or improved including NAT [25], firewall traversal and security. It is difficult to position the users’ location when a user connects to the network through NAT technology (one IP address allocated to many users). To solve NAT and firewall issue we suggest using the ICE (Interactive Connectivity Establishment) [26] when users connect to a super-node.

On the other hand, a distributed P2P architecture has an open security issues for a long time such as trust (privacy and confidentiality), malicious node behavior (call dropping) and DoS attacks. Hop-by-hop routing of request and responses at which each node changes the source identifier can be used to provide some confidentiality.

In our simulation scenario, it is just a small scope comparing to the original Mutualcast and our proposed conferencing control protocol. We will try to construct an integrated network environment and perform simulation for more accurate packet loss, packets delay and throughput. It will be tested to deliver the real voice on the simulation network and analyze the voice quality of service that end-users may experience in advance.

implement our proposed system in practice. It also should be added more simulation scenarios to enhance the authenticity of the simulation results of our proposed system.

References

[1] Jackson, Barry. "History of VoIP", University of Texas at Dallas. Retrieved on 2007-11-07.

[2] H.323, International Telecommunication Union, “Packet based multimedia communications system.” Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

[3] J. Rosenberg, Henning Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R.

Sparks, M. Handley, and E. Schooler. "SIP: session initiation protocol", RFC 3261, Internet Engineering Task Force, June 2002.

[4] 賈文康, Session Initiation Protocol (SIP) Methodology Handbook, 松岡文魁出版 社,2005 first edition.

[5] Skype, http://www.skype.com/intl/en/welcomeback/

[6] “The 10 that Established VoIP (Part 2: Level 3).” iLocus (July 13, 2007).

Retrieved on 2007-11-07.

[7] Homepage of the BitTorrent project. http://bittorrent.com/.

[8] M. Castro, P. Druschel, A. Kermarrec, A. Nandi, A. Rowstron, and A. Singh.

"SplitStream: High-bandwidth content distribution in a cooperative environment", In IPTPS’03, February 2003.

[9] X. Jiang, Y. Dong, D. Xu, and B. Bhargava. "GnuStream: A P2P Media Streaming System Prototype", In Proceedings of the International Conference on Multimedia and Expo(ICME),volume 2, pages 325–328, July 2003.

[10] B. Knutsson, H. Lu, W. Xu, and B. Hopkins. "Peer-to-Peer support for massively multiplayer games", In IEEE Infocom, March 2004.

[11] Kundan Singhand Henning Schulzrinne. "Peer-to-Peer internet telephony using sip", In NOSSDAV, pages63–68, 2005.

[12] David A. Bryan, Bruce B. Lowekamp, and Cullen Jennings. "Sosimple: A serverless, standards-based, p2p sip communication system", Appears in AAA-IDEA, 2005.

[13] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger, M. Frans Kaashoek, F. Dabek, and H. Balakrishnan. "Chord: A scalable Peer-to-Peer lookup protocol for Internet applications" IEEE/ACM Transactions on Networking, 11(1):17-32, Feb 2003.

[14] J. Lennox, H. Schulzrinne, "A protocol for reliable decentralized conferencing", In Proc of 13th international workshop on network and operating systems support for digital audio and video, (NOSS-DAV’2003), pp. 72-81, 2003,

[15] Li, J., "MutualCast: A Serverless Peer-to-Peer Multiparty Real-Time Audio Conferencing System", Multimedia and Expo, ICME 2005. IEEE International Conference on , pp. 602 – 605, July 2005, Microsoft Res., Commun. &

Collaboration Syst., Redmond, WA.

[16] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[17] Dawen Song, Yijun Mo, Furong Wang, "Architecture of multiparty conferencing using SIP", Wireless Communications, Networking and Mobile Computing, 2005.

Proceedings. 2005 International Conference on, pp. 1361- 1364, Sept. 2005 [18] 2.J.Rosenberg and H.Schulzrinne, "Models for Multi Party Conferencing in SIP",

Internet-Draft, IETF, November 5, 2004. Work in progress.

[19] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC3550, Internet Engineering Task Force, July 2003.

[20] Boutremans, C.,Le Boudec, J.-Y., "Adaptive Delay Aware Error Control For Internet Telephony", In Proceedings of the 2nd IP-Telephony Workshop, New York, April 2001.

[21] ns-2: http://www.isi.edu/nsnam/ns/

[22] Andrea Bacioccola, Claudio Cicconetti, Giovanni Stea, "User-level Performance Evaluation of VoIP Using ns-2", Workshop on Network Simulation Tools (NSTools) 2007, Nantes, France, October 22, 2007.

[23] Andy Oram, "Peer-to-Peer: Harnessing the Power of Disruptive Technologies", O’reilly, March 2001

[24] http://free.napster.com/

[25] P. Srisuresh, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, Internet Engineering Task Force, January 2001

[26] J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-15, Internet Engineering Task Force, May 2007.

[27] http://www.nuvio.com/images/voip-how-it-works-diagram.png