1. Reliable, Scalable and Interoperable Internet Telephony
First practice talk for thesis defense
by Kundan Singh
Advisor: Henning Schulzrinne
Computer Science Department, Columbia University, New York
March 28, 2006

2. Outline of the presentation
Introduction
What is the problem? Why important?
My contributions
Server redundancy
Load sharing and failover in SIP telephony
Comparison of thread models for SIP server
Peer-to-peer (P2P)
SIP servers using external P2P network
Additionally, P2P maintenance using SIP
Enterprise IP telephony
Multi-platform collaboration using SIP
Scalable centralized conferencing architecture
Interworking between SIP/SDP and H.323
Conclusion
46 slides

3. Telephone reliability & scalability (PSTN: Public Switched Telephone Network)
database (SCP) for freephone, calling card, …
signaling network
(SS7)
signaling router (STP)
local telephone switch (class 5 switch) 10,000 customers
20,000 calls/hour
database (SCP) 10 million customers
2 million lookups/hour
signaling router (STP) 1 million customers
1.5 million calls/hour
regional telephone switch (class 4 switch) 100,000 customers
150,000 calls/hour
% availability for equipment. Long distance 3-4 nines (AT&T’97). Mobile about 98% (study in europe).
Current VoIP: call success probability 99.5 and abortion due to poor quality 1.5%, giving 98% availability (wenyu’03).
Cannot lose in-progress calls
Preserving billing data is important
Can lose calls during call-setup
SCP: service control point; STP: signal transfer point
“bearer” network
telephone switch (SSP)
Switches strive for % availability.
Lucent’s 5E-XC supports 4 million BHCA.

4. Internet telephony (SIP: Session Initiation Protocol)
yahoo.com
example.com
REGISTER
INVITE
DNS DB
Unlike PSTN, call stateless proxies.
DNS
Routing (BGP, OSPF)
Link connection
Software failure
QoS

5. What are the problems?
Can SIP server provide carrier-grade reliability and scalability using commodity hardware?
What affects the server performance?
How can we build a server-less self-organizing peer-to-peer VoIP network?
Can this be done in standards compliant way?
Can communication be extended to multi-platform collaboration using existing protocols?
How well multi-party conferencing scales?
How to interoperate between SIP and H.323?
100 requests/s, 1hr=3600s refresh interval => users.
Complicated by mobility (higher registration rate), authentication
Our proxy server does 300 registrations and 90 calls/s.
Same infrastructure can be used for generic multimedia communication on the Internet.

6. My contributions Server redundancy Peer-to-peer (P2P)
Implemented failover using database replication
Two-stage architecture for SIP load sharing
Comparison of thread models for SIP server
Peer-to-peer (P2P)
SIP servers using external P2P network
Additionally, P2P maintenance using SIP
Enterprise IP telephony
Multi-platform collaboration using SIP
Scalable centralized conferencing architecture
Interworking between SIP/SDP and H.323
MTTR depends on a number of components such as DNS TTL, ARP cache, DHCP timers, SIP registration and call setup latency depending on the failover architecture
100 requests/s, 1hr=3600s refresh interval => users.
Complicated by mobility (higher registration rate), authentication
Our proxy server does 300 registrations and 90 calls/s.
Same infrastructure can be used for generic multimedia communication on the Internet.

7. Outline of the presentation
Introduction
What is the problem? Why important?
My contributions
Server redundancy
Load sharing and failover in SIP telephony
Comparison of thread models for SIP server
Peer-to-peer (P2P)
SIP servers using external P2P network
Additionally, P2P maintenance using SIP
Enterprise IP telephony
Multi-platform collaboration using SIP
Scalable centralized conferencing architecture
Interworking between SIP/SDP and H.323
Conclusion

8. Server redundancy The problem: failure or overload
REGISTER
INVITE
REGISTER
INVITE
Replicate registration or search on call
Tradeoff:
registration traffic
Call setup latency

9. High availability Failover implementation in our test-bed - CINEMA
MySQL: No locking protocol between master and slave. Race if insert into D1 and remove from D2
Web
scripts
Web
scripts D1 D2
Master/
slave
Slave/
master
replication P1 P2
sipd has in-memory cache: REGISTER refresh much before expiry; web gets delayed data; not an issue for cisco phones
Known techniques: Client-based (Cisco phones: primary and backup proxy); DNS (NAPTR, SRV); IP address takeover (Requires same subnet); Database redundancy
MySQL 4.0 has no locking protocol between master and slave. They proposed for 5.0 but not done yet. So only master should be updated. But if slave is updated when master is running, there may be problem. Mostly not visible: SIP register are additive.
If contact is added to D1 and removed from D2, race condition. But primary is preferred over secondary so all replication happens D1 to D2 unless D1 is down.
Make sure DB are consistent before failed server is brought up.
MySQL Cluster has delivered five 9s—in other words, percent—availability in testing, according to company officials. That works out to five minutes of downtime per year. The technology has been tested on as many as 48 nodes, with failover response times running between five and 10 milliseconds, according to MySQL Vice President of Marketing Zack Urlocker.
Reducing refresh interval much before expiry makes user appear available when he is not (Phone dies without un-registering)
e.g., refresh interval = (Expires/2)-e
Database replication causes problem for
Redundant voic different vmail contacts for P1 and P2=>don’t replicate. Or use DNS NAPTR/SRV.
conference server: must be tied with conference server state replication also.
phone.cs.columbia.edu
sip2.cs.columbia.edu
REGISTER
_sip._udp
SRV phone.cs.columbia.edu
SRV sip2.cs.columbia.edu
proxy1 = phone.cs
backup = sip2.cs
INVITE to P2 either on
ICMP error or after 10 s

10. High availability Analysis
Master/
slave
Slave/
master D1 D2
System reliability
(1-(1-R)2)
Call setup latency
TR (1-R) P[tM<TD]
where TD is DNS TTL,
tM is time-to-repair, and
P[tM<TD] = 1 – e-TD/TM
User unavailability
None (refresh; double register)
For first time registration, probability that the server goes down before replication is:
1 – e-(Td/+Tc)/TF
where TF is mean-time-to-failure
Redundant servers
Tradeoff: reliability vs capacity
DNS
Caller P1 P2 TR
Callee P1 D1 P2 D2
R is the single server reliability (probability that the system is up).
Latency equation assumes no network delay; R is approx 1; and MTTF is much larger than MTTR.
TODO: Web access latency to work out. Tc Td Tc A Tr TR A Tc

11. Scalability Load sharing: redundant proxies and databases
REGISTER
Write to D1 & D2
INVITE
Read from D1 or D2
Database write/ synchronization traffic becomes bottleneck P1
REGISTER D1 P2 D2
With MySQL 4.0 not possible to do database replication since write can happen to any. So each SIP server must write to all Ds.
INVITE P3

12. Scalability Load sharing: divide the user space
Proxy and database on the same host
Hashing
Static vs dynamic
Stateless proxy can become overloaded
Use many P1 D1
a-h P2 D2
i-q
Any study on dynamic hashing for web?
What are the issues with dynamic hashing: transfer registrations to new DB. P3 D3
r-z

13. Scalability Comparison of the two designs
a-h D1 D1 P2 P2
i-q D2 D2 P3 P3
r-z D2
Total time per DB
=((tr/D)+1)TN
=(A/D) + B
=((tr+1)/D)TN
=(A/D) + (B/D)
System reliability
=(1-(1-Rp)P).(1-(1-Rd)D)
=R0.(RP)D.(Rd)D
How derived:
(a) writes = NT, total read = rN.tT
(b) total writes = NT, total read = rN.tT
D = number of database servers
N = number of writes (REGISTER)
r = #reads/#writes = (INV+REG)/REG
T = write latency
t = read latency/write latency
P = number of proxy servers
Rp = reliability of the proxy server
Rd = reliability of the database server
Low Scalability
High Reliability
High Scalability
Low Reliability

14. Scalability (and reliability) Two stage architecture
I stage
II stage a1
Master
a.example.com
_sip._udp
SRV 0 0 a1.example.com
SRV 1 0 a2.example.com s1 a2
Slave s2
Master
b.example.com
_sip._udp
SRV 0 0 b1.example.com
SRV 1 0 b2.example.com
One group can become backup for other group. s3 b1
Slave
example.com
_sip._udp
SRV 0 40 s1.example.com
SRV 0 40 s2.example.com
SRV 0 20 s3.example.com
SRV 1 0 ex.backup.com ex b2
Capacity = f(#stateless, #groups)

15. Load Sharing Performance result (UDP, stateless, no DNS, no mempool)
This means 10 million BHCA (busy hour call attempts) using S3P3.
I(s) II(p) calls/s
Stateful proxy gave similar graphs with 650 CPS for single server.
Line segments due to non-uniform distribution in II stage; I have verified uniform distribution also.
Regitration test also gave similar graphs with about 2400 RPS (no auth). This means 10 million subscribers using S3P3.
On commodity hardware:
3 GHz, Pentium 4,
1 GB memory

16. Server performance What happens inside a server
Server performance What happens inside a server? What thread/event models possible?
recvfrom or
accept/recv
Match
transaction
Modify
response
Update DB
Lookup DB
Build
Request
DNS
sendto,
send or
sendmsg
parse
Response
Stateless proxy
Found
stateful
REGISTER
other
Redirect/reject
Proxy
Pure event-based (one thread)
Thread-per-msg or transaction
Pool-thread per msg
Two stage thread pool
Process pool
(Blocking) I/O
Critical section (lock)
Critical section (r/w lock)

17. Server performance Results of my measurements; effect of multi-processor
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
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
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
850
340
120
2 stage thread-pool
1100
550
155
500

18. Not much concurrency in stateful mode: needs more investigation

19. Problem with servers Server-based Peer-to-peer
Cost: maintenance, configuration
Central points of failures, catastrophic failures
Controlled infrastructure (e.g., DNS)
Peer-to-peer
Robust: no central dependency
Self organizing, no configuration
Scalability C S P
IETF Zeroconf: without DHCP/DNS, do IPv4 address allocation, DNS resolution, service discovery (SRV), Multicast address allocation.
/16 ( ) can be used for other devices in local network. Not simultaneously.

20. Outline of the presentation
Introduction
What is the problem? Why important?
My contributions
Server redundancy
Load sharing and failover in SIP telephony
Comparison of thread models for SIP server
Peer-to-peer (P2P)
SIP servers using external P2P network
Additionally, P2P maintenance using SIP
Enterprise IP telephony
Multi-platform collaboration using SIP
Scalable centralized conferencing architecture
Interworking between SIP/SDP and H.323
Conclusion

21. We built: P2P-SIP Unlike proprietary Skype architecture
Robust and efficient lookup using DHT
Interoperability
DHT algorithm uses SIP communication
Hybrid architecture
Lookup in SIP+P2P
Inter-domain P2P-SIP
Unlike file-sharing applications
Data storage, caching, delay, reliability
Disadvantages
Lookup delay and security
Problems with skype: proprietary architecture, single service, centralized component.
Zipf: straight line on double log axes.

22. How to combine SIP + P2P? P2P-over-SIP SIP-using-P2P
Additionally, implement P2P using SIP messaging
SIP-using-P2P
Replace SIP location service by a P2P protocol
SIP-using-P2P
P2P SIP proxies
P2P-over-SIP
Maintenance
P2P
SIP
Lookup
SIP-using-P2P:
Reuse optimized and well-defined external P2P network
Define P2P location service interface to be used in SIP
Extends to other signaling protocols (H.323)
Don’t overload SIP or REGISTER
Lookup is separate from call signaling
P2P-over-SIP
No change in semantics of SIP
No dependence on external P2P network
Reuse existing features such as forking (for voice mail)
Built-in NAT/media relays.
Additional message overhead due to SIP.
P2P network
REGISTER
FIND
INVITE alice
P2P-SIP
overlay
INSERT
Alice
INVITE
Alice

23. Deployment scenarios? Interoperate among these! P2P proxies
Different scenarios have different trust models!
P2P proxies
P2P clients
Plug and play;
May use adaptors;
Untrusted peers;
Super-nodes
Zero-conf server farm;
Trusted servers and
user identities
Interoperate among these!

24. SIP-using-P2P Using an External P2P network (distributed hash table - DHT)
Data model
Treat DHT as database
Service model
Join DHT to provide service
[5]
bob
bob
[3]
[1]
[2]
[1]
[3]
DHT
DHT
Service
node
( )
There are two approaches to do the P2P-SIP operations. In the data model, the DHT is treated as a database with put, get, remove API, and performs all operations using this. In the service model, the every P2P-SIP node joins the DHT as a service node and serves as registrar, proxy, presence agent and STUN/TURN server for other nodes. It uses lookup, join and leave API.
It is possible to layer them on one another: data model on top of service model is straight forward. Additionally OpenDHT shows that service model on top of data model is also possible using the ReDiR interface.
[4]
[2]
[5]
alice
alice
[1] join( )
[2] lookup(H(bob)) gives
[3] REGISTER sip:bob to
[4] lookup(H(bob)) gives
[5] INVITE sip:bob to
[1] put(k, ), k is H(bob)
[2] get(k) gives
[3] INVITE sip:bob to

25. SIP-using-P2P Logical Operations
Contact management
put (user id, signed contact)
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.
XML-based data format

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

27. P2P-over-SIP Node architecture: registrar, proxy, user agent
User interface (buddy list, etc.)
Signup,
Find buddies
IM,
call
On reset
Signout,
transfer
On startup
User location
Leave
Find
Discover
Join
Audio devices
DHT (Chord)
REGISTER,
INVITE,
MESSAGE
Codecs
Peer found/
Detect NAT
Multicast REGISTER
REGISTER
ICE
SIP
RTP/RTCP
SIP-over-P2P
P2P-using-SIP
DHT communication using SIP REGISTER
Known node:
Unknown node:
User:

28. P2P-over-SIP Implementation31
sippeer: C++, Linux, Chord
Node join and form the DHT
Node failure is detected and DHT updated
Registrations transferred on node shutdown
Co-located sipc can use sippeer service 29 1 31 30 25 26 26 9 19 11 15

29. P2P-over-SIP Analysis: scalability
Number of messages depends on
Number of peer nodes (N)
Keep-alive (rs) and finger table refresh rate (rf)
Call arrival distribution (c)
Node join, leave, failure rates ()
Number of users (k.N)
User registration refresh rate (t)
M={rs+ rf(log(N))2} + c.log(N) + (k/t)log(N) + (log(N))2/N
Number of nodes = f(node-capacity)
Nmax  min[2M/(r+c),2M/r] for large N
Measured M = 800 reg/s and assuming aggressive refresh and call rate of 1/min, it gives 2219 nodes.
Even for a conservative 10 req/s capacity, it gives more than 16 million nodes (super nodes) in the network.

30. P2P-over-SIP Analysis: availability and call setup latency
To increase user availability:
Increase keep-alive rate (fast failure detection)
Increase user registration refresh rate (reduce unavailability)
Replicate user and node registrations
Call setup latency:
Same as DHT lookup latency: O(log(N))
Calls to known locations (“buddies”) is direct
DHT optimization further reduces latency
Chord: nodes => 6 hops
At most a few seconds
User availability and retransmission timers
Advanced services also possible.
the ConChord system for certificate storage, the Tarzan system for anonymous communications, and the proposal to use Chord as replacement of standard DNS hierarchies by
Cox, Muthitacharoen, and Morris -- this last proposal is most similar in
spirit to your work

31. SIP-using-P2P vs P2P-over-SIP
Low transport and transaction overhead
Not SIP-specific, hence no implementation overhead for non-VoIP but P2P applications
No P2P security burden on SIP
Single DHT implementation
Reuse SIP naming, routing, security, NAT/firewall traversal
Easily reuse existing SIP components without change
voic , conference
Readily supports service model

32. Outline of the presentation
Introduction
What is the problem? Why important?
My contributions
Server redundancy
Load sharing and failover in SIP telephony
Comparison of thread models for SIP server
Peer-to-peer (P2P)
SIP servers using external P2P network
Additionally, P2P maintenance using SIP
Enterprise IP telephony
Multi-platform collaboration using SIP
Scalable centralized conferencing architecture
Interworking between SIP/SDP and H.323
Conclusion

33. Internet telephony infrastructure CINEMA: Columbia InterNet Extensible Multimedia Architecture
CINEMA servers
Telephone
switch
Local/long distance
sipconf:
Conference server
rtspd: media server
Quicktime
RTSP
PSTN
RTSP clients
Department
PBX
sipum:
Unified
messaging
sipd:
Proxy, redirect,
Registrar server
Internal
Telephone
Extn: 7040
713x
SQL
database
cgi
Web server
SIP/PSTN Gateway
vxml
Web based
configuration
SIP
VXML
My work
H.323
siph323:
SIP-H.323
translator
NetMeeting

34. Communication to collaboration
Comprehensive
Personalized view
Calendar, address book, groups and access control
Synchronous (tightly-coupled) collaboration
Conferencing: audio, video, IM, white-board, screen sharing, shared web browsing
Asynchronous (loosely-coupled) collaboration
Unified messaging, shared files, discussion forum, notification
Multi-platform (device)
Telephone: touch tone input and audio (IVR)
PC: multimedia client, , IM
Reuse existing protocols and tools
Unified messaging
The gaps among different media (audio, video, text), devices (PC, phone) and means of communications ( , SIP, IM) disappear for messaging
Current practice is to use and telephone conference, or use vendor specific or platform dependent tools, or use application specific collaboration.
Our goal is to provide synchronous and asynchronous collaboration and alternate between the two, and access from variety of devices such as telephone and PC using tools such as , IM, PC client or audio client.

35. Implementation: voicemail
(1) INVITE
INVITE OK
CANCEL
(3) OK
(2) SETUP
(4) RTP
(5) BYE
rtspd
sipum
Goals
Universal access
Scalability
Provider independent
Why SIP and RTSP?
Reuse existing infrastructure and tools
Design goals: Message recording and playback, Answering machine and voic , Universal access: web, , VoIP, PSTN, notification, Scalability for large domains, Separable from ITSP or ISP, Reuse existing infrastructure, Media-agnostic, Tool-agnostic, Telephony interface - DTMF

36. Implementation: web interface
Retrieval
Web interface
rtsp://server/alice /inbox/1677.au,
press 1 to listen…
Configuration
Folders
Options
Retrieval or deletion
Retrieval using RTSP clients (Quicktime), SIP user agent (e*phone) or Web browser.
Features
Integration with web/ for more control over voic configuration (e.g., folder management, notification.)
Web based voice mail accounts for users (Similar to Hotmail)

37. Conferencing models (non-multicast)B C D 
A+C+D A B C D  A B C
B+C+D
A+B+D D
A+B+C 
Topology star full-mesh ad-hoc
Advantages
Heterogeneous
simple clients
No central point of
failure
Disadvantages
External server with high bandwidth link
Complex endpoints
Complex signaling
Typically only three party conferences

38. Implementation: conference

39. Implementation: conferenceD E A B C
G711
DVI
GSM
Linear
Playout delay
Periodic
timer
M=A+B+C
Mixed linear
M - A=B+C
M - B
M - C
Receive
Send
G.711, GSM, DVI, Speex, G.722 mixing (decode-mix-encode)
Video replication; IM; text; VNC screen sharing; floor control; IVR for joining
Optimization possible for same codecs

40. Performance evaluation
Increase in parameter value
CPU
Bandwidth
Delay
Packetization interval (T)
Reduces
Increases
Codec bitrate (B)
N/A
Codec complexity (M)
Network jitter (J)
CPU usage = (.P + ).C
 = (Me+a.B’+b) and  = (Md+c.B’+d)
B’ = B + 320/T
For C conferences, each with P participants. a,b,c,d are constants; b,d are comparatively insignificant
For G.711 codec Me and Md are insignificant (5.5 and 1.7 s), thus CPU = C.(a.P+c).(B+320/T)
For GSM, G.722, (or G.723.1), Me and Md are dominant (70 and 30/50 s), thus CPU = C.(Me.P+Md)

41. Performance evaluation
Delay less than 20 ms: increases from first to last participant in a conference
About 480 participants in a single conference with one speaker
Packetization interval of 40 ms gives better performance: 720, but increases delay too
About 80 four-party conferences
Memory used 20 kB per call or participant
Both Pentium and Sparc took about 6 MHz/participant

42. Cascaded conference server
SIP REFER message is used to create cascading      
N.(N-1) participants
Higher delay
N2/4 participants
2/3 to ¾ lower delay
I measured the CPU usage for two cascaded servers: supports about 1000 participants

43. Interworking between SIP and H.323
Transport Layer
SIP
SDP
RTP
Codecs
RTCP
Terminal Control/Devices
IP and lower layers
TCP
UDP
TPKT
Q.931
H.245
RAS
RTCP
RTP
Codecs
Terminal Control/Devices
Both use RTP for media thus allows scalable translator
SDP is simple. H.245 is very exhaustive and can represent inter-codec dependencies.
H.323 has multi-stage call setup. SIP has single stage. H.323 single step fast connect is optional
Basic calls are possible to translate. Complete interworking is not possible without modifying (conference, security).

44. Outline of the presentation
Introduction
What is the problem? Why important?
My contributions
Server redundancy
Load sharing and failover in SIP telephony
Comparison of thread models for SIP server
Peer-to-peer (P2P)
SIP servers using external P2P network
Additionally, P2P maintenance using SIP
Enterprise IP telephony
Multi-platform collaboration using SIP
Scalable centralized conferencing architecture
Interworking between SIP/SDP and H.323
Conclusion

45. Revisiting the problems
Developed a two stage scalable and reliable SIP server architecture: linear scaling. Use event-based.
Can SIP server provide carrier-grade reliability and scalability using commodity hardware?
What affects the server performance?
How can we build a server-less self-organizing peer-to-peer VoIP network?
Can this be done in standards compliant way?
Can communication be extended to multi-platform collaboration using existing protocols?
How well multi-party conferencing scales?
How to interoperate between SIP and H.323?
Developed P2P-SIP architecture: SIP-using-P2P and P2P-over-SIP
100 requests/s, 1hr=3600s refresh interval => users.
Complicated by mobility (higher registration rate), authentication
Our proxy server does 300 registrations and 90 calls/s.
Same infrastructure can be used for generic multimedia communication on the Internet.
Multi-platform collaboration using existing protocols and tools, unified messaging, centralized conferencing (cascaded), SIP-H.323 interworking.

46. My publications Conference, workshop, technical report, magazine/journal
K. Singh and H. Schulzrinne, “Using an external DHT as a SIP location service", Columbia University Technical Report CUCS , NY, Feb’06.
K. Singh and H. Schulzrinne, “Peer-to-peer Internet telephony using SIP", NOSSDAV, Skamania, Washington, Jun
K. Singh and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", New York Metro Area Networking Workshop, CUNY, NY, Sep 2004.
K. Singh and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", Columbia University Technical Report CUCS , NY, Oct 2004.
K. Singh and H. Schulzrinne, “Failover and load sharing in SIP telephony", SPECTS (Symposium on performance evaluation of computer and telecommunication systems). Philadelphia, PA, Jul 2005.
K. Singh and H. Schulzrinne, "Failover and Load Sharing in SIP Telephony", Columbia University Technical Report CUCS , NY, May 2004.
H. Schulzrinne, K. Singh and X. Wu, "Programmable Conference Server", Columbia University Technical Report CUCS , NY, Oct 2004.
K. Singh, Xiaotao Wu, J. Lennox and H. Schulzrinne, "Comprehensive Multi-platform Collaboration", MMCN SPIE Conference on Multimedia Computing and Networking, Santa Clara, CA, Jan 2004.
K. Singh, Xiaotao Wu, J. Lennox and H. Schulzrinne, "Comprehensive Multi-platform Collaboration", Columbia University Technical Report CUCS , NY, Nov 2003.
M. Buddhikot, A. Hari, K. Singh and S. Miller, "MobileNAT: A new Technique for Mobility across Heterogeneous Address Spaces", ACM MONET journal, March 2005.
M. Buddhikot, A. Hari, K. Singh and S. Miller, "MobileNAT: A new Technique for Mobility across Heterogeneous Address Spaces", WMASH ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots, San Diego, CA, Sep 2003.
K. Singh, A. Nambi and H. Schulzrinne, "Integrating VoiceXML with SIP services", ICC Global Services and Infrastructure for Next Generation Networks, Anchorage, Alaska, May 2003.
K. Singh, A. Nambi and H. Schulzrinne, "Integrating VoiceXML with SIP services", Second New York Metro Area Networking Workshop, Columbia University, NY, Sep 2002.
K. Singh, W. Jiang, J. Lennox, S. Narayanan and H. Schulzrinne, "CINEMA: Columbia InterNet Extensible Multimedia Architecture", Columbia University Technical Report CUCS , NY, May 2002.
W. Jiang, J. Lennox, H. Schulzrinne and K. Singh, "Towards Junking the PBX: Deploying IP Telephony", NOSSDAV 2001.
W. Jiang, J. Lennox, S. Narayanan, H. Schulzrinne, K. Singh and X. Wu, "Integrating Internet Telephony Services", IEEE Internet Computing (magazine), May/June 2002 (Vol. 6, No. 3).
K. Singh, Gautam Nair and H. Schulzrinne, "Centralized Conferencing using SIP", 2nd IP-Telephony Workshop (IPTel'2001), April 2001.
K. Singh and H. Schulzrinne, "Unified Messaging using SIP and RTSP", IP Telecom Services Workshop 2000, Atlanta, Georgia, U.S.A, Sept 2000.
K. Singh and H. Schulzrinne, "Unified Messaging using SIP and RTSP", Columbia University Technical Report CUCS , NY, Oct 2000.
K. Singh, H.Schulzrinne, "Interworking Between SIP/SDP and H.323", 1st IP-Telephony Workshop (IPTel'2000), April 2000.
K. Singh and H. Schulzrinne, "Interworking Between SIP/SDP and H.323", Columbia University Technical Report CUCS , NY, May 2000.

47. Backup slides

48. My research timeline Conference evaluation SIP Failover/load sharing
P2P VoIP using SIP
SIP Failover/load sharing
Multimedia collaboration
CINEMA user interface
Enterprise VoIP infrastructure
Interactive voice response
Mobile NAT
Libsip++ (SIP library)
SIP conferencing
SIP-RTSP voice mail
SIP-H.323 translator
H.323 client
gateway
Reliability and scalability
India
VoIP infrastructure
India

49. VoIP infrastructure CINEMA: multi-platform multimedia collaboration
Beyond voice: video, text, IM, presence, screen sharing, shared web browsing, …
Beyond SIP phone: regular telephone, , web, …
Beyond synchronous communication: offline mails, discussion forum, file sharing, …
Program
Call
routing
SIP
SAP
RSVP
RTCP
RTP
Media
G.711
MPEG
RTSP
Signaling
Quality of service
Media transport
Internet
Telephony
Radio/TV
Messaging
and Presence
Interactive
voice response
Unified
messaging
Video
conferencing
Physical layer
Link layer
Network (IPv4, IPv6)
Transport (TCP, UDP)
Application layer
Voice
XML
DTMF
Mixing
Speech/
text
SDP

50. VoIP infrastructure Reliability and scalability
Failover: redundancy
Load sharing: scalability P1
a-h P2
i-q
INVITE
REGISTER
Use DNS P3
r-z
Combine the two in a two stage architecture
Infinite scalability (linear with #servers)
High availability

51. VoIP infrastructure Peer-to-peer Internet telephony
Server-based
Maintenance and configuration cost: dedicated administrator
Central point of failures: catastrophic failures
Depends on controlled infrastructure (e.g., DNS)
Peer-to-peer
Self adjusting, robust against catastrophic failures, highly scalable, and no configurations
Call setup and user search latency is higher: O(log(N))
Security: how to handle malicious peers? Identity protection?
Our P2P-SIP
Hybrid architecture: works with both P2P and server-based
Built-in P2P network: acts as a service node for proxy, registrar, presence, offline storage, and media relay
External P2P network: managed and trusted peer nodes
Identity protection: identifier == SIP identifier

52. SIP network architecture Scalability requirement depends on role
Cybercafe
ISP
IP network
IP phones GW
ISP MG
SIP/MGC MG
SIP/PSTN GW
SIP/MGC
Carrier network MG
Mention about requirements in #customers. GW IP
PSTN
PBX
PSTN phones
T1 PRI/BRI
PSTN
A mobile service provider in 3GPP with millions of subscribers

53. Reliability and scalability for call routing, registration, conferencing, voicemails
Requirements
Reliable
Mean Time Between Failures (MTBF), Mean Time To Recover (MTTR), percentage availability
Scalable
Registration rate, call rate, #requests/s
Server and network components
Proposed solutions
Server redundancy
Apply existing web-redundancy designs
Evaluate quantitatively
Peer-to-peer
Novel P2P-SIP architecture
MTTR depends on a number of components such as DNS TTL, ARP cache, DHCP timers, SIP registration and call setup latency depending on the failover architecture
100 requests/s, 1hr=3600s refresh interval => users.
Complicated by mobility (higher registration rate), authentication
Our proxy server does 300 registrations and 90 calls/s.
Same infrastructure can be used for generic multimedia communication on the Internet.

54. Server redundancy Known techniques
Client-based
Cisco phones: primary and backup proxy
DNS
NAPTR, SRV
IP address takeover
Database redundancy

55. Reliability and scalability Analysis, simulation and measurement proposal
Rp Mp a1
Master
Rs Ms
P=1+1 s1 a2
Slave
S=3
 = R + P
REGISTER+
INVITE, etc
B=2 s2
/B
Master
r, p s3 s b1
Slave ex b2
When is stateless proxy stage needed
What are the optimal values for S,B,P
for required scalability (1-10 million BHCA) and reliability (99.999%)
using commodity hardware

56. Scalability Requirements Depends on traffic type
Registration (uniform)
Authentication, mobile users
Call routing (Poisson)
stateful vs stateless proxy, redirect, programmable scripts
Beyond telephony (Don’t know)
Instant message, presence (including sensors), device control
Stateful calls (Poisson arrival, exponential call duration)
Firewall, conference, voic
Transport type
UDP/TCP/TLS (cost of security)
100 requests/s, 1hr=3600s refresh interval => users.
Our proxy server does 300 registrations and 90 calls/s.
Same infrastructure can be used for generic multimedia communication on the Internet.

57. SIPstone SIP server performance metrics
SQL
database
Steady state rate for
successful registration, forwarding and unsuccessful call attempts measured using 15 min test runs.
Measure: #requests/s with given delay constraint.
Performance=f(#user,#DNS,UDP/TCP,g(request),L) where g=type and arrival pdf (#request/s), L=logging?
For register, outbound proxy, redirect, proxy480, proxy200.
Parameters
Measurement interval, transaction response time, RPS (registers/s), CPS (calls/s), transaction failure probability<5%,
Delay budget: R1 < 500 ms, R2 < 2000 ms
Shortcomings:
does not consider forking, scripting, Via header, packet size, different call rates, SSL. Is there linear combination of results?
Whitebox measurements: turnaround time
Extend to SIMPLEstone
Server
Loader
Handler
REGISTER R1
200 OK
INVITE
User population: BHCA=f(#users,%active,call interval); f(20000,1/4,3min)=100,000/hr=28c/s
Request modeling: poison arrival, INVITE transaction duration (20s=.7x8.5s+.3x38s), UAS latency<100ms
Transaction response time<200ms for register and <100ms for 1xx, <2s for 2xx of INVITE,
At 100c/s with 1500 bytes each, signaling requires 1.2Mb/s
E721 says at most 6s, 8s, 11s respectively for local,toll,international call setup delay.
100 Trying
INVITE R2
180 Ringing
180 Ringing
200 OK
200 OK
ACK
ACK
BYE
BYE
200 OK
200 OK

58. Lessons Learnt (sipd) In-memory database
Call routing involves ( 1) contact lookups
10 ms per query (approx)
Cache (FastSQL)
Loading entire database is easy
Periodic refresh
Potentially useful for DNS lookups
Web config
SQL
database
Periodic
Refresh
Cache
< 1 ms
[2002:Narayanan]
Single CPU Sun Ultra10
Turnaround time vs RPS

59. Lessons Learnt (sipd) Thread-per-request does not scale
One thread per message
Doesn’t scale
Too many threads over a short timescale
Stateless: 2-4 threads per transaction
Stateful: 30s holding time
Thread pool + queue
Thread overhead less; more useful processing
Pre-fork processes for SIP-CGI
Overload management
Graceful failure, drop requests over responses
Not enough if holding time is high
Each request holds (blocks) a thread
Incoming
Requests
R1-4
Fixed number of threads R1 R2 R3 R4
Incoming
Requests
R1-4
Thread pool with
overload control
Throughput
Thread per request
Load

60. What is the best architecture?
Event-based
Reactive system
Process pool
Each pool process receives and processes to the end (SER)
Thread pool
Receive and hand-over to pool thread (sipd)
Each pool thread receives and processes to the end
Staged event-driven: each stage has a thread pool
recvfrom or
accept/recv
Match
transaction
Modify
response
Update DB
Lookup DB
Build
Request
DNS
sendto,
send or
sendmsg
parse
Response
Stateless proxy
Found
stateful
REGISTER
other
Redirect/reject
Proxy

61. Stateless proxy UDP, no DNS, six messages per call
Match
transaction
Modify
response
stateful
Stateless proxy
Response
sendto,
send or
sendmsg
recvfrom or
accept/recv
Found
Update DB
parse
Redirect/reject
REGISTER
Match
transaction
Build
response
Request
other
Lookup DB
Stateless proxy
Proxy
16 processes or threads in the pool
Modify
Request
DNS

62. Stateful proxy UDP, no DNS, eight messages per call
Event-based
single thread: socket listener + scheduler/timer
Thread-per-message
pool_schedule => pthread_create
Thread-pool1 (sipd)
Thread-pool2
N event-based threads
Each handles specific subset of requests (hash(call-id))
Receive & hand over to the correct thread
poll in multiple threads => bad on multi-CPU
Process pool
Not finished yet

63. Lessons Learnt What is the best architecture?
Stateless
CPU is bottleneck
Memory is constant
Process pool is the best
Event-based not good for multi-CPU
Thread/msg and thread-pool similar
Thread-pool2 close to process-poll
Stateful
Memory can become bottle-neck
Thread-pool2 is good
But not N x CPU
Not good if P  CPU
Process pool may be better (?)

64. Lessons Learnt (sipd) Avoid blocking function calls
DNS
10-25 ms (29 queries)
Cache
110 to 900 CPS
Internal vs external
non-blocking
Logger
Lazy logger as a separate thread
Date formatter
Strftime() 10% REG processing
Update date variable every second
random32()
Cache gethostid()- 37s
Logger:
while (1) {
lock;
writeall;
unlock;
sleep; }

65. Lessons Learnt (sipd) Resource management
Socket management
Problems: OS limit (1024), “liveness” detection, retransmission
One socket per transaction does not scale
Global socket if downstream server is alive, soft state – works for UDP
Hard for TCP/TLS – apply connection reuse
Socket buffer size
64KB to 128KB; Tradeoff: memory per socket vs number of sockets
Memory management
Problems: too many malloc/free, leaks
Memory pool
Transaction specific memory, free once; also, less memcpy
About 30% performance gain
Stateful: 650 to 800 CPS; Stateless: 900 to 1200 CPS
For 64KB: packet drop started at 1200 CPS, and throughput saturated at 1600 CPS for process pool
For 128KB: packet drop started and saturated at 1700 CPS.
Stateless processing time (s)
INV
180
200
ACK
BYE
REG
W/o mempool
155 67 95
139 62
237 70
W/ mempool
111 49 48 64
106 41
202
Improvement (%) 28 27 33 24 34 15 31

66. Lessons Learnt (SER) Optimizations
Reduce copying and string operations
Data lumps, counted strings (+5-10%)
Reduce URI comparison to local
User part as a keyword, use r2 parameters
Parser
Lazy parsing (2-6x), incremental parsing
32-bit header parser (2-3.5x)
Use padding to align
Fast for general case (canonicalized)
Case compare
Hash-table, sixth bit
Database
Cache is divided into domains for locking
[2003:Jan Janak] SIP proxy server effectiveness, Master’s thesis, Czech Technical University

67. Lessons Learnt (SER) Protocol bottlenecks and other scalability concerns
Parsing
Order of headers
Host names vs IP address
Line folding
Scattered headers (Via, Route)
Authentication
Reuse credentials in subsequent requests
TCP
Message length unknown until Content-Length
Other scalability concerns
Configuration:
broken digest client, wrong password, wrong expires
Overuse of features
Use stateless instead of stateful if possible
Record route only when needed
Avoid outbound proxy if possible

68. Load Sharing Distribute load among multiple servers
Single server scalability
There is a maximum capacity limit
Multiple servers
DNS-based
Identifier-based
Network address translation
Same IP address

69. Lessons Learnt Load sharing
Non-uniform distribution
Identifier distribution (bad hash function)
Call distribution => dynamically adjust
Stateless proxy
S=1050, P=900 CPS
S3P3 => 10 million BHCA (busy hour call attempts)
Stateful proxy
S=800, P=650 CPS
Registration (no auth)
S=2500, P=2400 RPS
S3P3 => 10 million subscribers (1 hour refresh)
Memory pool and thread-pool2/event-based further increase the capacity (approx 1.8x)

70. SIP server Comparison with HTTP server
Signaling (vs data) bound
No File I/O (exception: scripts, logging)
No caching; DB read and write frequency are comparable
Transactions
Stateful wait for response
Depends on external entities
DNS, SQL database
Transport
UDP in addition to TCP/TLS
Goals
Carrier class scaling using commodity hardware
Try not to customize/recompile OS or implement (parts of) server in kernel (khttpd, AFPA)

71. Related work Scalability for (web) servers
Existing work
Connection dispatcher
Content/session-based redirection
DNS-based load sharing
HTTP vs SIP
UDP+TCP, signaling not bandwidth intensive, no caching of response, read/write ratio is comparable for DB
SIP scalability bottleneck
Signaling (chapter 4), real-time media data, gateway
302 redirect to less loaded server, REFER session to another location, signal upstream to reduce
Multi-homing.
Geographic load balancing.
Round-robin DNS – no account of server load, and server failure.
Load balancer – can use server response time, with damping. Or load information is pushed.
Active content verification by load balancer
Session and context – use external DB or sticky session in load balancer

72. Related work 3GPP (release 5)’s IP Multimedia core network Subsystem uses SIP
Proxy-CSCF (call session control function)
First contact in visited network. 911 lookup. Dialplan.
Interrogating-CSCF
First contact in operator’s network.
Locate S-CSCF for register
Serving-CSCF
User policy and privileges, session control service
Registrar
Connection to PSTN
MGCF and MGW

73. Server-based vs peer-to-peer
Reliability, failover latency
DNS-based. Depends on client retry timeout, DB replication latency, registration refresh interval
DHT self organization and periodic registration refresh. Depends on client timeout, registration refresh interval.
Scalability, number of users
Depends on number of servers in the two stages.
Depends on refresh rate, join/leave rate, uptime
Call setup latency
One or two steps.
O(log(N)) steps.
Security
TLS, digest authentication, S/MIME
Additionally needs a reputation system, working around spy nodes
Maintenance, configuration
Administrator: DNS, database, middle-box
Automatic: one time bootstrap node addresses
PSTN interoperability
Gateways, TRIP, ENUM
Interact with server-based infrastructure or co-locate peer node with the gateway

74. Comparison of sipd and SER
Thread pool
Events (reactive system)
Memory pool
PentiumIV 3GHz, 1GB, 1200 CPS, 2400 RPS (no auth)
SER
Process pool
Custom memory management
PentiumIII 850 MHz, 512 MB => 2000 CPS, 1800 RPS

75. P2P-SIP Background: DHT (Chord)
Key
node
8+1 = 9 14
8+2 = 10
8+4 = 12
8+8 = 16 21
8+16=24 32
8+32=40 42 1 54 8 58 10 14 47 21
Lookup in finger table for the furthest node that precedes the key
In a system with N nodes and K keys, with high probability,
each node receives at most K/N keys
each node maintains information about O(logN) other nodes
lookups resolved with O(logN) hops
No network locality.
Replicas need to have explicit consistency.
Optimizations:
location: weight neighbor nodes by RTT.
When routing choose the neighbor who is closer to destination with lowest RTT from me.
Reduce path latency.
Multiple physical nodes per virtual node.
What if a node leaves?
Identifier circle
Keys assigned to successor
Evenly distributed keys and nodes
Finger table: logN
ith finger points to first node that succeeds n by at least 2i-1
Stabilization for join/leave 42 38 32 38 24 30

76. P2P-SIP Design Alternatives1 8 14 21 32 38 58 47 10 24 30 54 42
65a1fc
d13da3
d4213f
d462ba
d467c4
d471f1
d46a1c
Route(d46a1c)
servers 1 54 10 38 24 30
Hierarchy
Dynamically adapt
clients
Use DHT in server farm
Use DHT for all clients; But some are resource limited
Use DHT among super-nodes

77. CINEMA My contribution in design and implementation
CINEMA Applications
RTSP media
server
SIP/VoiceXML
browser
SIP/H.323
gateway
SIP/RTP
conferencing
SIP/RTSP
unified messaging
SIP proxy
server
rtspd
sipvxml
sip323
sipconf
sipum
sipd
Flite
Xerces-C
Xerces-C
OpenH323
CINEMA Libraries
libsip
Basic SIP library
rtplib++
RTP library
libcine
Utilities parsing
IPv6
librtsp
RTSP
client
libsipapi
SIP UA library
libconf
RTP audio mixer
libmedia
Recording, files
libNT
Win32 stub
libdict
Hash table
libdb++
mySQL interface
libsnmp
SIP MIB
libcanon
canonicalize
MySQL
PWLib
Resparse
… and web-based GUI
C/C++: 58K out of 187 KLOC
Tcl: 30 KLOC

78. Related work IP telephony and multimedia communication
Unlike low cost VoIP: Vonage, AT&T
We provide enterprise infrastructure
There are enterprise IPtel: Cisco, Nortel
But redundancy architecture, interoperability, distributed components model differ
Collaboration: CSCW, SIGGROUP
Unlike web-centric, or application specific
We provide standard-based multimedia collaboration platform
Multimedia conferencing: Mbone, H.323
Ours is SIP-based infrastructure, reuse existing tools and protocols such as RTSP, media server
Distributed software development – CHIME (kaiser)

79. Related work Comprehensive multi-platform collaboration
Goal: Alternate between synchronous and asynchronous communication, and access from different devices and clients.
Synchronous (tightly coupled)
Video conference, IM, screen sharing, floor control, …
Asynchronous (loosely coupled)
File sharing, message board, …
Messaging and notifications
Personalized view
Per-user calendar, access control, address book
We try to incorporate…
Long lived groups
Design teams, committees, college classes
Asymmetric events
Lecture and lecture series
Short-lived spontaneous interaction
Current practice
, teleconference
Vendor specific tools, platform dependence
Application specific
E.g., collaborative software development

80. Multi-party collaboration What is done, and what is left.
Sipconf: conference server
Audio, video, IM, screen, shared browsing, floor control
No XCON yet: use web interface
Small to medium size conferences
Cascaded conference mixer
#participants, audio delay
Failover
State sharing between servers

81. Related work Availability for (web) servers
Availability = f(reliability,maintainability)
Reliability: time to failure pdf
Maintainability: time to recover pdf
Existing work on failover
TCP connection migration
IP address takeover
MAC address takeover
Reliable server pooling
Requires new protocol support in clients
Reliability analysis tools (
Availability in the face of (DoS) attacks
Standby – hot (same data on both), cold (bring only when primary fails), warm (periodically send data to secondary; both running)
Scalability of web servers:
Same IP (L4/2 cluster): Bell labs ONE-IP, IBM eNetwork Dispatcher (2000/s), Alteon ACEdirectory (in switch, 25000/s)
NAT (L4/3 cluster): server IP is that of NAT. Cisco localdirector (25Mb/s with 8000 cluster nodes), LSNAT (30Mb/s)
L7: Locality aware request distributor (Rice Univ; uses connection migration – non-commodity OS,Content based – less cache.) (2000/s, 280Mb/s)
IBM web accelerator - cache in dispatcher (but low performance for bigger response). Arrowpoint (hardware; cache; sticky; 20000/s,20Gb/s)
Client based – DNS server rotates list of IP addresses returned.
Redirecting to less loaded server (SWED from UCSB) – application layer. Proxy becomes the bottleneck.
Remapping in the network: scheduler (L3) or link (L2)

82. Related work Scalability for (web) servers
Existing work
Connection dispatcher
Content/session-based redirection
DNS-based load sharing
HTTP vs SIP
UDP+TCP, signaling not bandwidth intensive, no caching of response, read/write ratio is comparable for DB
SIP scalability bottleneck
Signaling (chapter 4), real-time media data, gateway
302 redirect to less loaded server, REFER session to another location, signal upstream to reduce
Multi-homing.
Geographic load balancing.
Round-robin DNS – no account of server load, and server failure.
Load balancer – can use server response time, with damping. Or load information is pushed.
Active content verification by load balancer
Session and context – use external DB or sticky session in load balancer

83. Related work SIPStone: SIP server performance metric
Steady state rate for
successful registration, forwarding and unsuccessful call attempts measured using 15 min test runs.
Measure: #requests/s with given delay constraint.
Performance=f(#user,#DNS,UDP/TCP,g(request),L) where g=type and arrival pdf (#request/s), L=logging?
For register, outbound proxy, redirect, proxy480, proxy200.
Parameters
Measurement interval, transaction response time, register/s, calls/s, transaction failure probability<5%,
Shortcomings:
does not consider forking, scripting, Via header, packet size, different call rates, SSL. Is there linear combination of results?
User population: BHCA=f(#users,%active,call interval); f(20000,1/4,3min)=100,000/hr=28c/s
Request modeling: poison arrival, INVITE transaction duration (20s=.7x8.5s+.3x38s), UAS latency<100ms
Transaction response time<200ms for register and <100ms for 1xx, <2s for 2xx of INVITE,
At 100c/s with 1500 bytes each, signaling requires 1.2Mb/s
E721 says at most 6s, 8s, 11s respectively for local,toll,international call setup delay.

84. Related work 3GPP (release 5)’s IP Multimedia core network Subsystem uses SIP
Proxy-CSCF (call session control function)
First contact in visited network. 911 lookup. Dialplan.
Interrogating-CSCF
First contact in operator’s network.
Locate S-CSCF for register
Serving-CSCF
User policy and privileges, session control service
Registrar
Connection to PSTN
MGCF and MGW

85. Related work: Skype From the KaZaA community
Host cache of some super nodes
Bootstrap IP addresses
Auto-detect NAT/firewall settings
Similar to STUN and TURN
Protocol among super nodes – ??
Allows searching a user (e.g., kun*)
History of known buddies
All communication is encrypted
Promote to super node
Based on availability, capacity
Conferencing
Problems:
Proprietary, single service, centralized login P
Super-nodes Election: capacity (bandwidth, storage, CPU) and availability (connection time,public address)
Read on STUN and TURN – what kind of NAT they support etc.
Symmetric NAT (different outbound connection from internal IP:port to different destination use different external address)
Full cone, restricted and port restricted cone: same internal IP:port has same external address for any destination, same destination IP, same destination IP:port
TURN: acts as a relay for UDP or TCP
ICE: caller collects all external address, sends to callee, callee tries STUN to all, sends packets to whichever works, callee also collects all external address, sends to caller, caller reuses callees address or tries STUN. Periodically keep trying STUN.

86. Related work P2P P2P networks Skype and related systems
Unstructured (Kazaa, Gnutella,…)
Structured (DHT: Chord, CAN,…)
Skype and related systems
Flooding based chat, groove, Magi
P2P-SIP telephony
Proprietary: NimX, Peerio,
File sharing: SIPShare
Mercora – legal music sharing
S2S – science to science is a p2p search engine built using JXTA
SOS – source->access point->beacon->secret servlet->filter/firewall->target. Target picks secret servlets. Beacon know abt secret servlets.

87. Why we chose Chord? Chord can be replaced by another
As long as it can map to SIP
High node join/leave rates
Provable probabilistic guarantees
Easy to implement
X proximity based routing
X security, malicious nodes

88. Related work JXTA vs Chord in P2P-SIP
Protocol for communication (peers, groups, pipes, etc.)
Stems from unstructured P2P
P2P-SIP
Instead of SIP, JXTA can also be used
Separate search (JXTA) from signaling (SIP)
JXTA: peer discovery, resolver, information, rendezvous, pipe binding, endpoint routing protocols.
Peers, groups, messages, pipes, advertisement,

89. P2P-SIP Node Startup SIP DHT Dialing out REGISTER with SIP registrar
columbia.edu DB
sipd
SIP
REGISTER with SIP registrar
DHT
Discover peers: multicast REGISTER
Join DHT using node-key=Hash(ip)
REGISTER with DHT using
Dialing out
Call, instant message, etc.
INVITE
MESSAGE
Last seen, SIP NAPTR/SRV, DHT
REGISTER
Detect peers
REGISTER alice=42 42 58 12 14
REGISTER bob=12 32

90. P2P-SIP Node Leaves Graceful leave Failure Un-REGISTER
Transfer registrations
Failure
Attached nodes detect and re-REGISTER
New REGISTER goes to new super-nodes
Super-nodes adjust DHT accordingly
REGISTER key=42
REGISTER
DHT
OPTIONS 42 42

91. P2P-SIP Advanced services
Offline messages
INVITE or MESSAGE fails => Responsible node stores voic , instant message.
Conferencing
Mixer, full mesh, multicast

92. P2P-SIP Security – open issues (threats, solutions, issues)
More threats than server-based
Privacy, confidentiality
Malicious node
Don’t forward all calls, log call history (spy),…
“free riding”, motivation to become super-node
Existing solutions
Focus on file-sharing (non-real time)
Centralized components (boot-strap, CA)
Assume co-operating peers (
works for server farm in DHT
Collusion
Hide security algorithm (e.g., yahoo, skype)
Chord
Recommendations, design principles, …
Design principles:
define verifiable system invariants and verify them
Allow querier to observe the lookup progress
Assign keys to nodes in a verifiable manner
Server selection in routing may be abused
Cross check routing tables using random queries
Avoid single point of responsibility
Pastry - exclude untrusted nodes with help of central certificate authority.
Incorrect data served: verify by self certifying path names

93. Server-based vs peer-to-peer
Reliability, failover latency
DNS-based. Depends on client retry timeout, DB replication latency, registration refresh interval
DHT self organization and periodic registration refresh. Depends on client timeout, registration refresh interval.
Scalability, number of users
Depends on number of servers in the two stages.
Depends on refresh rate, join/leave rate, uptime
Call setup latency
One or two steps.
O(log(N)) steps.
Security
TLS, digest authentication, S/MIME
Additionally needs a reputation system, working around spy nodes
Maintenance, configuration
Administrator: DNS, database, middle-box
Automatic: one time bootstrap node addresses
PSTN interoperability
Gateways, TRIP, ENUM
Interact with server-based infrastructure or co-locate peer node with the gateway

94. IP telephony services (PSTN)
Call routing services: pre-call, one party
speed dial
call forwarding
“follow me”
call filtering/blocking (in/out)
do not disturb
distinctive ringing
Call handling features
autoanswer
Multi-party features
call waiting
call transfer (blind, consultative)
conference call
call park
call pickup
music on hold
call monitoring
Services modify call behavior. Can be invoked by user, pre-programmed or programmable feature logic. PSTN its typically pre-subscribed or built-in, but not programmable.
IP telephony can’t win by just providing what PSTN has.
IP-telephony can’t win by just providing what PSTN has

95. IP telephony services (Internet)
Presence-enabled calls
place call only if callee is available
Presence-enabled conferencing
call conference participants when all are online and not busy
IM conference alerts
receive IM when someone joins a conference
Unified messaging
receive , IM alert for new voic s
Anything that deals with media becomes media services. Usually media and signaling services closely interact with each other, e.g., interactive voice response can invite new participants to join a conference.

96. Why do we need signaling?
What is the IP address of Alice’s host?
What audio/video encoding can it support?
REGISTER as
alice=>
Call alice
Alice’s host
bob’s host
home.com
Session Initiation Protocol
-like address:
DNS
Proxy, redirect

97. My contribution in CINEMA Sip-h323: signaling translator
Background: ITU-T’s H.323
Binary ASN.1 PER, collection of protocols (H.245, H.225.0, Q.931, RAS, H.450.x)
H.323 gatekeeper similar but not same as SIP server
Problems in interworking
Multi-stage dialing in H.323v1
Fast start in v2 is optional
User registration
Both SIP and H.323 users should be reachable
Session description is more complex
End system should select the codecs
Security and QoS: end-to-end or not?
Solution
List different scenarios
No modification in SIP or H.323
Direct RTP traffic if possible
Implementation

98. My contribution in CINEMA Sipum: Unified messaging using SIP and RTSP
Problem
Existing systems have voic with PBX or phone, or send voice attachments in
Downloading the whole message is not desirable
Solution
Using existing standards (RTSP, SIP) and tools (web, media player)
Distributed components for different architectures (PBX, phone, service provider)
Many ways to retrieve your message (RTSP, SIP, phone, web)
Message deletion issues
Call reclaiming
Implementation

99. My contribution in CINEMA Sipconf: Centralized conferencing using SIP/RTP
Problem
Multicast is not available and ad hoc conference is useful for small number of users
Heterogeneous clients (some have video also; or different audio codecs)
Solution
Audio mixer, video forwarder
IM, VNC screen sharing, shared web browsing
Playout delay adjustments
Web based configuration, floor control
G.711 A/Mu, G.721, DVI, ADPCM, G.722, …
Modular: libconf, libmedia, rtplib++
Implementation and performance evaluation

100. My contribution in CINEMA Sipvxml: SIP-based VoiceXML browser
Background
VoiceXML for touch tone-based service programming
Backend scripts (CGI) or servlets
Problem
Then existing solutions were PSTN based
Solution
First SIP-VoiceXML implementation
SIP interface (works with PSTN via a gateway)
Example cgi scripts
Calling card service
Joining a conference (Ajay)
Accessing voice mail (Ajay)
by phone (Pimrampai)
Auto attendant (Sean)

101. My contribution in CINEMA libsip++: SIP user agent library in C++
All the applications (sipum, sipconf, siph323, sipvxml) use a common underlying library
Similar API for H.323 defined using wrapper around openH323
Unlike JAIN-SIP or SIP servlet, libsip++ is more high level with facility to access low level features
Dialog, call, endpoint, registration are defined as objects (JAIN-SIP 1.1 added dialog as object)
Uses underlying transaction and parsing library shared with sipd
Test user agent (sipua) is used as tools, e.g., for sipconf testing
Documentation is at

102. My contribution in CINEMA GUI: web-based user interface
Configuration, user profile, etc., stored in SQL DB
Front end as web-based GUI
CGI scripts in Tcl
About 100 pages for various configuration
User friendly (beginner vs advanced, context help)
Asynchronous collaboration
Voic , file sharing, IM archive, groups, address book, calendar
Undergone three iterations
See current version at

103. SIP vs H.323 Both use RTP/RTCP over UDP/IP Binary ASN.1 PER encoding
Text based request response
SDP (media types and media transport address)
Server roles: registrar, proxy, redirect
Binary ASN.1 PER encoding
Sub-protocols: H.245, H.225 (Q.931, RAS, RTP/RTCP), H.450.x...
H.323 Gatekeeper
SIP and H.323 are different, particularly, in terms of complexity, scope of feature definitions and session description.
Both use RTP/RTCP over UDP/IP

104. Interworking Problems Call setup translation
H.323
SIP
Q.931 SETUP
INVITE
Destination address
Q.931 CONNECT
200 OK
Terminal Capabilities
Media capabilities
(audio/video)
Terminal Capabilities
ACK
Open Logical Channel
Media transport address
(RTP/RTCP receive)
Open Logical Channel
Problems in call setup translation:
Three pieces of information needed for call setup :
Destination signaling address
Self and remote media capabilities
Self and remote media transport address
SIP carries these in INVITE and its response.
H.323 spreads them across different stages.
Mapping multistage dialing in H.323 to single stage in SIP is not trivial.
H.323 v2 Fast-Start supports single stage dialing, but it is optional..
Multi-stage dialing
H.323v2 Fast-start is optional

105. Interworking Problems User Registration?
H.323
H.323 Gatekeeper
SIP registrar
SIP
H.323 terminal
SIP user agent
Alias: Henry
E164: 7040
Problems in user registration:
User may be registered in either H.323 or SIP network, and should be callable from either H.323 or SIP endsystems.
Location independent user identifier ?
Use information from both networks

106. Interworking Problems Media Description
SIP/SDP (dynamically choose from listed modes)
List of alternative set of algorithms.
audio G.711 Mu law, G.723.1, G.728
video H.261
H.323/H.245 (declare your exact modes)
Supports inter-media constraints
{ [G.711 Mu law, G.711 A law][H.261 video]}
{ [G.723.1] [no video] }
H.245 can represent media constraints as shown in the example.
SDP is very simple and can not specify such constraints.
How do we translate H.245 capabilities to SDP ?
One approach is to use multiple SDP in SIP message.
Our approach of “maximal intersection” does not need such things.
Other problem, how to allow selection of audio/video algorithms by the end-systems, instead of by the signaling gateway.
Translation in both directions
Algorithm selection by end-systems

107. Interworking Problems Call Services
H.323 Conferencing: centralized signaling control, MC (Multi-point Controller)
Supplementary services, like call transfer: H.450.x
SIP Conferencing: centralized bridged + decentralized distributed
REFER, 3pcc
H.323 has centralized control for conferencing.
SIP supports both centralized and distributed conferencing.
H.323 invents new protocols (H for call transfer, H for call diversion, H for call hold) and so on.
In SIP, crucial pieces are identified (e.g., REFER) and additional services are built upon them.

108. Interworking Problems Security and QoS
H.323 uses H.235, whereas SIP uses Basic, Digest, PGP
Media Traffic end-to-end; QoS ?
SIP relies on external protocol for QoS. In H.323 QoS goes hand-in-hand with call establishment. Since, QoS requires end-to-end RSVP signaling (if RSVP) is used, you may not be able to have direct RTP channels between SIP and H.32 entities.

109. What we want ? Transparent translation
Minimum modification in SIP or H.323
Use features from both SIP and H.323
Direct RTP/RTCP traffic; end-to-end
User should be able to dial an internet address or an alias address or an URI and should be able to reach the intended destination, no matter whether it is in SIP or H.323 (or PSTN) network.
Interworking should be able to utilize the services of SIP servers (with CGI/CPL capabilities) as well as that of H.323 gatekeepers. If an H.320-H.323 gateway is available somewhere, then a SIP user should be able to reach an H.320 user via sip-h323 and H.323-H.320 gateways, for example.
Since both SIP and H.323 use RTP/RTCP for media, it is desirable to have direct media connection without routing media packets through the signaling gateway, to reduce delay.

110. User registration Registration info to foreign network
REGISTER
Contact:pc1
SIP registrar server
H.323 Gatekeeper + SGW
pc1.office.com
home.com
INVITE
RRQ
Contact:
3xx Moved
Contact:pc1
SIP user agent
H.323 terminal
To solve the user registration problem:
registration information should be transported to the foreign network.
This allows for three different architectures:
Signaling gateway co-located with H.323 gatekeeper
Signaling gateway co-located with SIP registrar/proxy
Independent signaling gateway.
The first scenario is shown in an example.
H.323 terminal’s registration information is transported to SIP network. Now any SIP entity can also reach the H.323 terminal.
In the second architecture, SIP registration information is transported to H.323 gatekeepers, which can then resolve the SIP addresses also.
If the signaling gateway is independent of the registration servers, it can use SIP OPTIONS and/or H.323 Location Request (LRQ) to check the validity of the address in SIP and H.323 networks respectively.
use SIP REGISTER and/or H.323 RRQ/RCF

111. SIP registrar server + SGW
User registration Registration info from foreign network
LRQ/LCF
SIP registrar server + SGW
H.323 Gatekeeper
pc1.office.com
home.com
INVITE
RRQ
Contact:
200 OK
SIP user agent
H.323 terminal
use SIP OPTIONS and/or H.323 LRQ/LCF

112. User registration Different Architectures
SGW co-located with H.323 gatekeeper
SGW co-located with SIP registrar/proxy server
Independent SGW

113. Call Setup with H.323v2 Fast Start
(Almost) One-to-one mapping between SIP and H.323 messages.
H323
SIP
Setup/FastStart
INVITE
Connect/FastStart
200 OK.
ACK
With H.323 fast start, there is a one-to-one mapping between the SIP and H.323 messages, as the media description is also carried in H.323 Setup and Connect messages.
Translation is simple.
RTP/RTCP
Reverse direction is similar

114. Call Setup without Fast Start
SIP
Q.931 SETUP
INVITE
Destination address
Q.931 CONNECT
200 OK
Terminal Capabilities
Media capabilities
(audio/video)
Terminal Capabilities
ACK
Open Logical Channel
Media transport address
(RTP/RTCP receive)
Open Logical Channel
Remember the three pieces of information for call setup.
Accept the call from H.323, forward to SIP after OLC ? Not desirable.

115. Call Setup without Fast Start, SIP to H.323
Setup/Q931
INVITE
Signaling
Gateway
Connect/Q931
Capabilities/H245
Capabilities/H245.
Media Transport
Address
200 OK.
Open Logical Channel/ H245
Without Fast start, translation is simple in SIP to H.323 direction, because all three pieces of information needed for call setup are available in SIP INVITE message. This can be split across multiple messages of H.323. Once the media transport addresses of H.323 endpoint is known in OpenLogicalChannelAck, a confirmation can be sent to SIP endpoint.
RTP and RTCP are carried directly between endsystems, since both endsystems know about the media transport address of the other.
Acknowledgement
Open Logical Channel / H245
ACK
Acknowledgement
RTP/RTCP

116. Call Setup without Fast Start, H.323 to SIP
Setup/Q931
INVITE
Signaling
Gateway
Connect/Q931
200 OK
Capability Exchange
ACK
Media Transport
Address
Open Logical Channel
Re-INVITE/SIP+SDP
Without Fast start in H.323 to SIP direction:
The signaling gateway forwards INVITE to SIP on receipt of Setup from H.323. This INVITE contains dummy SDP. Once the confirmation is received from SIP endpoint, Connect is sent on H.323.
Since the INVITE response from SIP contains the SDP of SIP side, it can be used to send and acknowledge H.323 capability negotiation and logical channel messages.
Once the acknowledgements for all the logical channel messages in SIP to H.323 direction, are received, the signaling gateway knows the media transport address of H.323 endpoint and it can send re-INVITE with new SDP to SIP endpoint.
RTP and RTCP are carried directly between endsystems, since both endsystems know about the media transport address of the other.
Acknowledgement
Open Logical Channel
Acknowledgement
RTP/RTCP

117. Media Capability Modify SIP/SDP : multiple capability sets, or...
Let the SGW choose a sub-set of capabilities for SIP side
Re-INVITE or change in H.323 mode or logical channels, whenever it changes
The signaling gateway maintains capability sets of both SIP and H.323 endpoints in each direction. These capability sets are used to calculate maximal intersection of capability sets in each direction.
Then an operating mode is derived for each direction (for each media type) by selecting one algorithm from the alternative set in the maximal intersection.
The H.323 logical channnels and SIP SDP are formatted using these operating modes.
Whenever there is a change in operating modes, SIP reINVITE and/or H.323 ModeRequest/Open and CloseLogicalChannel are sent as appropriate.

118. Streaming media Messages RTSP vs HTTP Applications Web server HTTP WebY
Streaming media
Web
browser
Media
player
file
Web server
HTTP
meta
RTSP
RTP
Media server
RTP is used for audio/video content.
RTSP for streaming commands like PLAY, RECORD, PAUSE, TEARDOWN.
Stream description can be done using SDP, SMIL (W3C), RTSL, …
RTSP can be over TCP like traditional HTTP, or over UDP (like passing around the remote). There are a number of similarities between RTSP and HTTP: similar message format, status code, security, content negotiation, URL format. Differences include: stateful, server initiated requests. It can support multicast delivery, with either server or client choosing the address. It can be added as a conference participant, or used as live streaming. The streaming can be aggregate control or per-stream control, even across different servers.
The timed playback allows remote editing, or synchronizing from different servers. It can also allow playing at different speed, e.g., FFwd. Load balancing using REDIRECT or 3xx class response.
Recording allows creating new or writing existing. New URL returned in Location header.
Messages
RTSP vs HTTP
UDP, Stateful, Control, Timed
Applications
Recording, Playback, Live media, Conference

119. Columbia rtspd Existing PlannedY
Columbia rtspd
Existing
Playback/recording of -law (Sun .au files) and raw
Unicast address
Multi-threaded;
Portable (Unix/win32)
Works with Apple QuickTime client
UDP + TCP
IPv4 + IPv6
Planned
Multicast
MPEG video
Mp3, wav audio
Media over TCP
Live media

120. Why do we need signaling?
What is the IP address of Alice’s host?
What audio/video encoding can it support?
REGISTER as
alice=>
Call alice
Alice’s host
bob’s host
home.com
Session Initiation Protocol
-like address:
DNS
Proxy, redirect

121. Session description INVITE alice@home.comY
Session description
INVITE
I can support -law and G.729
Send me audio at :6780
Bob
Alice
OK; I can support -law
Send me audio at :8000
RTP
To port 8000
RTP
To port 6780

122. Presence/event notificationY
Presence/event notification
office.com
Presence server
PUA PA
REGISTER
SUBSCRIBE
PUA + PA
NOTIFY
PUA
registrar
General event notification method for Internet
presence, conferencing, device control
Instant messaging
MESSAGE with text body

123. Columbia IM and presenceY
Columbia IM and presence

124. Network call control SIP-CGI CPL SIP servlets SIP proxy Y Urgent
Priority.pl
SIP_FROM
SIP_TO
stdin
CGI-PROXY-REQUEST
stdout
SIP-CGI
CPL
SIP servlets
SIP proxy
Urgent
Low-priority
Voic
Phone
if (defined $ENV{SIP_FROM} &&
$ENV{SIP_FROM} =~ {
foreach $reg (get_regs())
print "CGI-PROXY-REQUEST $reg SIP/2.0\n";
print "Priority: urgent\n\n"; }
SIP-CGI: Programming language independent. Maintains state via an opaque token. For SIP proxies and endpoints: call routing, controlling forking, call rejection, call modification (Priority, Call-Info). RFC Upload via web or REGISTER

125. Call transfer REFER Blind/ consultation/ attended A B C active call
REFER C
Referred-By: B
INVITE C
Referred-By: B
BYE A
active call

126. B2BUA and third-party call control
Back-to-back UA
Incoming call triggers outgoing call
Services
Calling card
Anonymizer B
SIP A C
INVITE
OK (SDP1)
ACK
INVITE (SDP1)
OK (SDP2)
ACK
INVITE (SDP2) OK
ACK

127. Voicemail Problems in PSTN Design alternatives IssuesY
Voic
Endpoint redirects
Problems in PSTN
Design alternatives
Issues
Redirect after 10s
Proxy controls
Voic acts like a phone
vmail.pl
CFB=call forward busy
Problems in PSTN:
Voice mail system tied to PBX or phone company
Integration of video, fax, whiteboard?
How to integrate with Internet telephony?
How to integrate with , web and other user applications?
Existing solutions
Voice Profile for Internet Messaging (VPIM)
Web-based unified messaging systems with personalized PSTN voice mail number
Issues
Call reclaiming
Deleting voice/video mail
Integration with PSTN phone
Integration with VPIM, IMAP, POP3
SIP_FROM
SIP_TO
stdin
CGI-PROXY-REQUEST
stdout
If no response
accept after 15s

128. VoiceXML PSTN Internet Gateway sipvxml Telephone Internet user
Voice gateway
Web server
Service logic (CGI, servlet, JSP)
Voice and telephony functions
VoiceXML browser
Internet user
VXML
HTML
Internet
Telephone
IVR platform
Voice and telephony functions
(ASR, TTS, DTMF)
Service logic (application specific)

129. Y
VoiceXML contd.
<form>
<field name=‘id’>
<prompt>
Your ID, please.
</prompt>
</field>
<block>
<submit next=“url”/>
</block>
</form>
<form action=“url”>
Enter your Id:
<input name=‘id’>
<input type=‘submit’>
</form>
Telephony, speech synthesis or audio output, user input and grammar, program flow, variable and properties, error handling, …

130. DTMF PSTN D D Internet Telephone SIP/PSTN Internet user gateway Audio
SIP INFO D
RTP/ RFC2833

131. Columbia sipvxml PSTN Internet Unified messaging access Email by phone
Telephone
SIP/PSTN
gateway
Unified messaging access
by phone
Event notification and scheduling
Audio volume control for conference
Advanced conference control
TTS, ASR,
DTMF, XML, HTTP, RTSP
sipvxml
SIP phone
Media server
rtspd
Web server
.tcl

132. Email + phone Email by phone Email procmail important mails Email to
Inbox
procmail
important
mails
Internet to IM
Login
formatting
Listen, reply, delete, compose, forward
Navigation -next, previous, jump
SIP
SIP
formatting
SIP based
Text-to-speech
VoiceXML
browser
TTS IM
Call
SIP
HTTP
Internet
JSP
servlet
Inbox DB
to phone

133. IM + voice call Who can initiate? Feedback Talk-spurt detectionY
IM + voice call
Who can initiate?
authentication, billing, …
Feedback
to voice user
to IM user
initial IM greeting
Talk-spurt detection
Speech recognition
SIP
MESSAGE
TTS
ASR IM
Call
SIP
INVITE
RTP

134. Notification Calendar Events Conferences Schedule from a browser
SIP call IM
Web server
Calendar.cgi
“at 6:00pm”

135. Phone announcement serverY
Phone announcement server
Destinations
Text or audio
Input
Range:93970??
List: A, B, C
Example
Announcement
Emergency
Issues
Voic
Failure detection
TTS
PAS
SIP
. . .

136. RTSP + TTS + ASR TTS ASR Media server SETUP rtsp://server/tts.cgiO
RTSP + TTS + ASR
TTS
ASR
Media server
SETUP rtsp://server/tts.cgi
?text=How+are+you.
SETUP rtsp://server/asr.cgi
PLAY
RECORD
Ask the server to stream converted speech to client.
TTS text can be in URL, in body of play or as a http file name in URL.
Also useful for SIP based component.
RTP
RTP
SET_PARAMETER
Text=I am fine, thank you.

137. Centralized conferencing
Conference as URL
On the fly conferences
Basic task: join/leave
Dial in, Refer dial in
Dial out, Refer dial out
INVITE
INVITE
REFER
INVITE
server
REFER

138. Conference + VoiceXML Call transfer vs bridged mode 1. INVITE sipvxmlY
Conference + VoiceXML
1. INVITE sipvxml
2. Call accepted
3. Enter your four digit PIN
4. Entered
5. Authenticate user, 4683=>Alice
6. Enter the conference identifier
7. Entered 2-3-#
sipvxml
8. Permission to join, 23=>meet
9. REFER
10.Terminate the old call
Caller
11.INVITE
sipconf
Call transfer vs bridged mode

139. New conference applicationsY
New conference applications
The ease & flexibility of sipvxml enables us to build
custom telephonic applications to suit our needs.
e.g., Volume Check Application
1. INVITE sipvxml
2. Menu 1. Vol Check 2. Mic Check
3. User enters 2
sipvxml
4. User speaks out a voice sample
5. Voice sample is analyzed
6. SipVXML: Vol level too high/low/…
Caller
7. User adjusts the vol level.
sipconf
8. User now joins conference.

140. Conferencing Netmeeting Automatic volume adjustmentsY
Conferencing
SIP323
Netmeeting
Automatic volume adjustments
Automatic load balancing
Delay adjustments
Conference recording
Local or RTSP
sipc
SIP/PSTN
Recording in
a media server

141. Summary of media services
Streaming media
Playback, recording, live-media
Unified messaging
Voic , video/IM integration, ...
Conferencing
Mixing, load-balancing
Interactive voice response
Tele-banking, VoiceXML

142. CINEMA Columbia InterNet Extensible Multimedia ArchitectureY
CINEMA Columbia InterNet Extensible Multimedia Architecture
Distributed
component
architecture
User-agent
(client)
applications
CINEMA
Application
and proxy
servers
Libraries and
APIs
Management
and control

143. What’s next? from multimedia communications to collaboration
Synchronous communications
Conferencing, IM
Asynchronous communications
Voic s, message board, file sharing
Ubiquitous computing
i-button, ID-card
Service creation
User friendly, end-point/network
one of the most important advantages of Internet Telephony is that it can provide more innovative services and can create the service more efficiently.

144. PSTN interworking Translating audio (PCMU/PCMA)
Telephone
network
Telephone
subscriber
SIP/PSTN
gateway
SIP server
IP endpoint
Translating audio (PCMU/PCMA)
Translating signaling (PRI/T1,ISUP)
Overlap signaling
Advanced features in SIP are lost in PSTN
Translating identifiers (phone number)
Determining transition points

145. PSTN to IP Gateway knows the SIP server ENUM DNS
ENUM
DNS
=> e164.arpa =>
Suitable for relatively “static” contacts

146. IP to PSTN Static mapping ITGW information is dynamic: TRIP
xxxx
ITGW information is dynamic:
Overlapping networks
Multiple providers
Load balancing
TRIP
Route advertisement
Can be implemented in outbound proxy
Suitable for current hierarchical network
@service.mci.com at 4¢/min
@nyc.gw.com at 1¢/min
@itgw1.columbia.edu free