Kundan Singh [please remove this page after merging] P2P-SIP using external DHT Thread and event models Conference server scalability

SIP-using-P2P P2P-SIP using an external distributed hash table (DHT) Data vs service modes Data: treat DHT as data storage using put/get/remove Service: join DHT to provide registrar/presence service using join/leave/lookup Logical operations Contact management put (user id, signed contact) Cryptographic key storage User certificates and private configurations Presence put (subscribee id, signed encrypted subscriber id) Composition needs service model Offline message put (recipient, signed encrypted message) NAT and firewall traversal STUN and TURN server discovery needs service model P2P-SIP design consists of many logical operations. The contact management deals with storing and retrieving user contacts as in SIP location service. The contacts are signed by the user on put and verified on get before making a call. Key storage deals with storing the certificate and encrypted private key of the user. The caller uses this certificate to verify. Presence deals with the subscribers updating the watcher list of the given subscribee such that only he can read the identifiers of the subscribers. Similarly, offline message deals with putting the signed and encrypted messages for the recipient such that only he can read and delete it. For NAT and firewall traversal, it provides P2P service discovery of a STUN or TURN server. Proposed an XML-based data format

SIP-using-P2P Implementation in SIPc with the help of Xiaotao Wu OpenDHT Trusted nodes Robust Fast enough (<1s) Identity protection Certificate-based SIP id == email P2P for Calls, IM, presence, offline message, STUN server discovery and name search P2P clients better than proxies: Less DHT calls OpenDHT quota for fairness imposes limit on proxies We have implemented P2P-SIP in our multimedia collaboration client, sipc, using OpenDHT running on Planetlab with about 200 nodes. The advantage of using an externally managed DHT is that we can trust to some extent that the nodes are not malicious and perform the DHT operations (get/put) correctly. Thus the security problem is mostly avoided. The identity protection is provided using a well known CA such as ours which gives out the certificate to the user for her email address, so that the user can securely use her email address as the SIP identifier in P2P-SIP. The implementation includes the P2P modes for calls, IM, presence, offline message storage, STUN server discovery and name search (find the user identifier for “Firstname Lastname”) OpenDHT is robust and fast enough for our needs. Lookups on an average take less than a second. We implemented redundancy and failover so that if one OpenDHT node is unavailable it uses another randomly choosen closer node. Should this be made open source?

SIP proxy performance Effect of software architecture and multi-processor hardware Both Pentium and Sparc took approx 2 MHz CPU cycles per call/s on single-processor Calls/s for stateless proxy, UDP, no DNS, 6 msg/call Architecture /Hardware 1 PentiumIV 3GHz, 1GB, Linux2.4.20 (1xP) 4 pentium, 450MHz, 512 MB, Linux2.4.20 (4xP) 1 ultraSparc-IIi, 300 MHz, 64MB, Solaris (1xS) 2 ultraSparc-II, 300 MHz, 256MB, Solaris (2xS) Event-based 1550 400 150 600 Thread per msg 1300 500 100 Pool-thread per msg (sipd) 1400 850 110 Thread-pool 1500 152 750 Process-pool 1600 1350 160 1000 Better performance as this includes mempool changes Calls/s for stateful proxy, UDP, no DNS, 8 msg/call Sipd architecture is in blue. Earlier measurements gave lower numbers for sipd, because they were done without mempool. Mempool improves the performance by about 30%. Another 30% using a better event-based architecture. Software architecture further improves performance: S3P3 can support 16 million BHCA Architecture /Hardware 1 PentiumIV 3GHz, 1GB, Linux2.4.20 (1xP) 4 pentium, 450MHz, 512 MB, Linux2.4.20 (4xP) 1 ultraSparc-IIi, 360MHz, 256 MB, Solaris5.9 (1xS) 2 ultraSparc-II, 300 MHz, 256 MB, Solaris5.8 (2xS) Event-based 1150 300 160 400 Thread per msg 600 175 90 Thread-pool (sipd) 850 340 120 2 stage thread-pool 1100 550 155 500

Should sipd use 2-stage thread pool architecture? Not much concurrency in stateful mode: needs more investigation

SIP conference server performance For G SIP conference server performance For G.711 audio mixing on a 3 GHz Pentium 4 with 1 GB memory About 480 participants in a single conference with one active speaker (CPU is bottleneck) About 40 four-party conferences, each with one active speaker (CPU is bottleneck) Memory usage: 20 kB/participant Mixer delay: less than 20 ms Increasing the packetization interval to 40 ms improves performance to 700 participants, but also increases mixer delay Both Pentium and Sparc take about 6 MHz/participant

Cascaded conference server SIP REFER message is used to create cascading       Assuming each server supports N participants, the two architectures can support N.(N-1) and N^2/4 participants respectively. The first has higher delay, whereas the second has 2/3 to ¾ times delay of the first. I measured the CPU usage for two cascaded servers: supports about 1000 participants in a single conference. The cascaded architecture scales to tens of thousands of participants.