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

2. 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

3. 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 ==
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 address, so that the user can securely use her 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?

4. 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

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

6. 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

7. 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.