Challenges of VoiceoverIP The Second Quarter Century

1
Challenges of Voice-over-IP The Second Quarter
Century

• Henning Schulzrinne
• Dept. of Computer Science
• Columbia University

2
Credits

• Members of the IRT lab and project students
• Clayton Chen
• Wenyu Jiang
• Jonathan Lennox
• Sankaran Narayanan
• Jonathan Rosenberg
• Kundan Singh
• Xin Wang
• Xiaotao Wu
• IETF SIMPLE, SIP, SIPPING working groups

3
Outline

• A brief history of packet voice
• Challenges
• QoS
• Security
• NATs
• Service creation
• Scaling
• Interworking
• Emergency calls
• CINEMA project at Columbia
• Events as new Internet service

4
A brief history

• August 1974
• Real-time packet voice between USC/ISI and
  MIT/LL, using CVSD and NVP.
• December 1974
• Packet voice between CHI and MIT/LL, using LPC
  and NVP
• January 1976
• Live packet voice conferencing between USC/ISI,
  MIT/LL, SRI, using LPC and NVCP
• Approximately 1976
• First packetized speech over SATNET between
  Lincoln Labs and NTA (Norway) and UCL (UK)
• 1990
• ITU recommendation G.764 (Voice packetization
  packetized voice protocols)

5
A brief history

• February 1991
• DARTnet voice experiments
• August 1991
• LBL's audio tool vat released for DARTnet use
• March 1992
• First IETF MBONE broadcast (San Diego)
• January 1996
• RTP standardized (RFC 1889/1890)
• November 1996
• H.323v1 published
• February/March 1999
• SIP standardized (RFC 2543)

6
VoIP applications

• Trunk replacements between PBXs
• Ethernet trunk cards for PBXs
• T1/E1 gateways
• IP centrex outsourcing the gateway
• Denwa, Worldcom
• Enterprise telephony
• Cisco Avvid, 3Com, Mitel, ...
• Consumer calling cards (phone-to-phone)
• net2phone, iConnectHere (deltathree), ...
• PC-to-phone, PC-to-PC
• net2phone, dialpad, iConnectHere, mediaring, ...

7
VoIP protocol components

• RTP for data transmission
• ROHC, CRTP for header compression
• SIP or H.323 for call setup (signaling)
• sometimes, H.248 (Megaco) for control of gateways
• ENUM for mapping E.164 numbers to (SIP) URIs
• TRIP for large gateway clouds

8
Where are we?

• Variety of robust SIP phones (and lots of
  proprietary ones)
• not yet in Wal-Mart
• SIP carriers terminate LAN VoIP
• number portability?
• 911
• 50 vendors at SIPit
• Building blocks media servers, unified
  messaging, conferencing, VoiceXML,

9
Status in 2002

• 2000 6b wholesale, 15b minutes retail
• 2001 10b worldwide 6 of traffic (only
  phone-to-phone)
• e.g., net2phone 341m min/quarter

10
Where are we?

• Not quite what we had in mind
• initially, SIP for initiating multicast
  conferencing
• in progress since 1992
• still small niche
• even the IAB and IESG meet by POTS conference
• then VoIP
• written-off equipment (circuit-switched) vs. new
  equipment (VoIP)
• bandwidth is (mostly) not the problem
• cant get new services if other end is POTS ??
  why use VoIP if I cant get new services

11
Where are we?

• VoIP avoiding the installed base issue
• cable modems lifeline service
• 3GPP vaporware?
• Finally, IM/presence and events
• probably, first major application
• offers real advantage interoperable IM
• also, new service

12
VoIP at Home

• Lifeline (power)
• Multiple phones per household
• expensive to do over PNA or 802.11
• BlueTooth range too short
• need wireless SIP base station handsets
• PDAs with 802.11 and GSM? (Treo)
• Incentives
• SMS IM services

13
SIP phones

• Hard to build really basic phones
• need real multitasking OS
• need large set of protocols
• IP, DNS, DHCP, maybe IPsec, SNTP and SNMP
• UDP, TCP, maybe TLS
• HTTP (configuration), RTP, SIP
• user-interface for entering URLs is a pain
• see success of Internet appliances
• PCs with handset cost 500 and still have a
  Palm-size display

14
Challenges QoS

• Bottlenecks access and interchanges
• Backbones e.g., Worldcom Jan. 2002
• 50 ms US, 79 ms transatlantic RTT
• 0.067 US, 0.042 transatlantic packet loss
• Keynote 2/2002 almost all had error rates less
  then 0.25 (but some up to 1)
• LANs generally, less than 0.1 loss, but beware
  of hubs

15
(No Transcript)
16
Challenges QoS

• Not lack of protocols RSVP, diff-serv
• Lack of policy mechanisms and complexity
• which traffic is more important?
• how to authenticate users?
• cross-domain authentication
• may need for access only bidirectional traffic
• DiffServ need agreed-upon code points
• NSIS WG in IETF currently, requirements only

17
RNAP price-based admission and adaptation

• Model users adjust multimedia bandwidth
  according to price sensitivity
• Generally, automatically based on profile
• DiffServ or IntServ model

18
RNAP network model
19
RNAP performance
20
RNAP performance
21
QoS Voice quality evaluation

• Traditional use lots of human subjects to rate
  speech quality (mean-opinion score) or
  signal-processing approximations
• We Use automatic speech recognizer to do the job

22
QoS voice-quality
23
QoS voice quality
24
QoS voice quality
25
Challenges Security

• Classical model of restricted access systems -gt
  cryptographic security
• Objectives
• identification for access control billing
• phone/IM spam control (black/white lists)
• call routing
• privacy

26
SIP security

• Bar is higher than for email telephone
  expectations (albeit wrong)
• SIP carries media encryption keys
• Potential for nuisance phone spam at 2 am
• Safety prevent emergency calls

27
System model
outbound proxy
SIP trapezoid
a_at_foo.com 128.59.16.1
registrar
28
SIP session setup
INVITE
REGISTER
BYE
29
Threats

• Bogus requests (e.g., fake From)
• Modification of content
• REGISTER Contact
• SDP to redirect media
• Insertion of requests into existing dialogs BYE,
  re-INVITE
• Denial of service (DoS) attacks
• Privacy SDP may include media session keys
• Inside vs. outside threats
• Trust domains can proxies be trusted?

30
Threats

• third-party
• not on path
• can generate requests
• passive man-in-middle (MIM)
• listen, but not modify
• active man-in-middle
• replay
• cut-and-paste

31
Challenges NATs and firewalls

• NATs and firewalls reduce Internet to web and
  email service
• firewall, NAT no inbound connections
• NAT no externally usable address
• NAT many different versions -gt binding duration
• lack of permanent address (e.g., DHCP) not a
  problem -gt SIP address binding
• misperception NAT security

32
Challenges NAT and firewalls

• Solutions
• longer term IPv6
• longer term MIDCOM for firewall control?
• control by border proxy?
• short term
• NAT STUN and SHIPWORM
• send packet to external server
• server returns external address, port
• use that address for inbound UDP packets

33
Challenges service creation

• Cant win by (just) recreating PSTN services
• Programmable services
• equipment vendors, operators JAIN Java API
• web-like (Perl scripts) sip-cgi
• proxy-based call routing CPL
• voice-based interaction VoiceXML

34
Call Processing Language

• XML rule set for handling calls
• Intentionally not Turing-complete
• ltcplgt
• ltsubaction id"voicemail"gt
• ltlocation url"sipjones_at_voicemail.example.co
  m" gtltproxy /gt
• lt/locationgt
• lt/subactiongt
• ltincominggt
• ltlocation url"sipjones_at_jonespc.example.com"
  gt
• ltproxy timeout"8"gt
• ltbusygtltsub ref"voicemail" /gtlt/busygt
• ltnoanswergtltsub ref"voicemail"
  /gtlt/noanswergt
• lt/proxygt
• lt/locationgt
• lt/incominggt
• lt/cplgt

35
sip-cgi scripting phone calls

• use DB_File
• sub fail
• my(status, reason) _at__
• print "SIP/2.0 status reason\n\n"
• exit 0
• tie addresses, 'DB_File', 'addresses.db'
• or fail("500", "Address database failure")
• to ENV'HTTP_TO'
• if (! defined( to ))
• fail("400", "Missing Recipient")

36
Emergency calls

• Opportunity for enhanced services
• video, biometrics, IM
• Finding the right emergency call center (PSAP)
• VoIP admin domain may span multiple 911 calling
  areas
• Common emergency address
• User location
• GPS doesnt work indoors
• phones can move easily IP address does not help

37
Emergency calls
common emergency identifier sos_at_domain
EPAD
REGISTER sipsos Location 07605
302 Moved Contact sipsos_at_psap.leonia.nj.us Conta
ct tel[phone]
SIP proxy
INVITE sipsos Location 07605
INVITE sipsos_at_psap.leonia.nj.us Location 07605
38
Scaling and redundancy

• Single host can handle ?10-100 calls
  registrations/second ? 18,000-180,000 users
• 1 call, 1 registration/hour
• Conference server about 50 small conferences or
  large conference with 100 users
• For larger system and redundancy, replicate proxy
  server

39
Scaling and redundancy

• DNS SRV records allow static load balancing and
  fail-over
• but failed systems increase call setup delay
• can also use IP address stealing to mask failed
  systems, as long as load lt 50
• Still need common database
• can separate REGISTER
• make rest read-only

40
Large system
stateless proxies
a1.example.com
sip1.example.com
a2.example.com
sip2.example.com
sipbob_at_example.com
b1.example.com
sipbob_at_b.example.com
sip3.example.com
b2.example.com
_sip._udp SRV 0 0 b1.example.com 0
0 b2.example.com
_sip._udp SRV 0 0 sip1.example.com
0 0 sip2.example.com 0 0
sip3.example.com
41
Enterprise VoIP

• Allow migration of enterprises to IP multimedia
  communication
• Add capacity to existing PBX, without upgrade
• Allow both
• IP centrex hosted by carrier
• PBX-style locally hosted
• Unlike classical centrex, transition can be done
  transparently

42
Motivation

• Not cheaper phone calls
• Single number, follow-me even for analog phone
  users
• Integration of presence
• person already busy better than callback
• physical environment (IR sensors)
• Integration of IM
• no need to look up IM address
• missed calls become IMs
• move immediately to voice if IM too tedious

43
Migration strategy

• Add IP phones to existing PBX or Centrex system
  PBX as gateway
• Initial investment ?2k for gateway
• Add multimedia capabilities PCs, dedicated video
  servers
• Reverse PBX replace PSTN connection with
  SIP/IP connection to carrier
• Retire PSTN phones

44
Example Columbia Dept. of CS

• About 100 analog phones on small PBX
• DID
• no voicemail
• T1 to local carrier
• Added small gateway and T1 trunk
• Call to 7134 becomes sip7134_at_cs
• Ethernet phones, soft phones and conference room
• CINEMA set of servers, running on 1U rackmount
  server

45
CINEMA components
Cisco 7960
MySQL
rtspd
sipconf
user database
LDAP server
plug'n'sip
RTSP
conferencing
media
server
server
(MCU)
wireless
sipd
802.11b
RTSP
proxy/redirect server
unified
messaging
server
Pingtel
sipum
Cisco
Nortel
2600
Meridian
VoiceXML
PBX
server
T1
T1
SIP
sipvxml
PhoneJack interface
sipc
SIP-H.323
converter
sip-h323
46
Experiences

• Need flexible name mapping
• Alice.Cueba_at_cs ? alice_at_cs
• sources database, LDAP, sendmail aliases,
• Automatic import of user accounts
• In university, thousands each September
• /etc/passwd
• LDAP, ActiveDirectory,
• much easier than most closed PBXs
• Integrate with Ethernet phone configuration
• often, bunch of tftp files
• Integrate with RADIUS accounting

47
Experiences

• Password integration difficult
• Digest needs plain-text, not hashed
• Different user classes students, faculty, admin,
  guests,
• Who pays if call is forwarded/proxied?
• authentication and billing behavior of PBX and
  SIP system may differ
• but much better real-time rating

48
SIP doesnt have to be in a phone
49
Event notification

• Missing new service in the Internet
• Existing services
• get put data, remote procedure call HTTP/SOAP
  (ftp)
• asynchronous delivery with delayed pick-up SMTP
  ( POP, IMAP)
• Do not address asynchronous (triggered)
  immediate

50
Event notification

• Very common
• operating systems (interrupts, signals, event
  loop)
• SNMP trap
• some research prototypes (e.g., Siena)
• attempted, but ugly
• periodic web-page reload
• reverse HTTP

51
SIP event notification

• Uses beyond SIP and IM/presence
• Alarms (fire on Elm Street)
• Web page has changed
• cooperative web browsing
• state update without Java applets
• Network management
• Distributed games

52
Conclusion

• Transition to VoIP will take much longer than
  anticipated ? replacement service
• digital telephone took 20 years...
• 3G (UMTS R5) as driver?
• combination with IM, presence, event notification
• Emphasis protocols ?operational infrastructure
• security
• service creation
• PSTN interworking

53
L3/L4 security options

• IPsec
• Provides keying mechanism
• but IKE is complex and has interop problems
• works for all transport protocol (TCP, SCTP, UDP,
  )
• no credential-fetching API
• TLS
• provides keying mechanism
• good credential binding mechanism
• no support for UDP SCTP in progress

54
Hop-by-hop security TLS

• Server certificates well-established for web
  servers
• Per-user certificates less so
• email return-address (class 1) certificate not
  difficult (Thawte, Verisign)
• Server can challenge client for certificate ?
  last-hop challenge

55
HTTP Digest authentication

• Allows user-to-user (registrar) authentication
• mostly client-to-server
• but also server-to-client (Authentication-Info)
• Also, Proxy-Authenticate and Proxy-Authorization
• May be stacked for multiple proxies on path

56
HTTP Digest authentication
REGISTER To sipalice_at_example.com
401 Unauthorized WWW-Authenticate Digest
realm"alice_at_example.com", qopauth,
nonce"dcd9"
REGISTER To sipalice_at_example.com Authorization
Digest username"alice", nc00000001,
cnonce"defg", response"9f01"
REGISTER To sipalice_at_example.com Authorization
Digest username"alice", nc00000002,
cnonce"abcd", response"6629"
57
End-to-end authentication

• What do we need to prove?
• Person sending BYE is same as sending INVITE
• Person calling today is same as yesterday
• Person is indeed "Alice Wonder, working for
  Deutsche Bank"
• Person is somebody with account at MCI Worldcom

58
End-to-end authentication

• Why end-to-end authentication?
• prevent phone/IM spam
• nuisance callers
• trust is this really somebody from my company
  asking about the new widget?
• Problem generic identities are cheap
• filtering bozo_at_aol.com doesn't prevent calls from
  jerk_at_yahoo.com (new day, sam person)

59
End-to-end authentication and confidentiality

• Shared secrets
• only scales (N2) to very small groups
• OpenPGP chain of trust
• S/MIME-like encapsulation
• CA-signed (Verisign, Thawte)
• every end point needs to have list of Cas
• need CRL checking
• ssh-style

60
Ssh-style authentication

• Self-signed (or unsigned) certificate
• Allows active man-in-middle to replace with own
  certificate
• always need secure (against modification) way to
  convey public key
• However, safe once established

61
DOS attacks

• CPU complexity get SIP entity to perform work
• Memory exhaustion SIP entity keeps state (TCP
  SYN flood)
• Amplification single message triggers group of
  message to target
• even easier in SIP, since Via not subject to
  address filtering

62
DOS attacks amplification

• Normal SIP UDP operation
• one INVITE with fake Via
• retransmit 401/407 (to target) 8 times
• Modified procedure
• only send one 401/407 for each INVITE
• Suggestion have null authentication
• prevents amplification of other responses
• E.g., user "anonymous", password empty

63
DOS attacks memory

• SIP vulnerable if state kept after INVITE
• Same solution challenge with 401
• Server does not need to keep challenge nonce, but
  needs to check nonce freshness