Challenges of Voice-over-IP – 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 • “can’t get new services if other end is POTS’’  “why use VoIP if I can’t 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

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. Local Resource Negotiator RNAP Messages HRN LRN LRN LRN LRN LRN LRN LRN LRN LRN HRN LRN LRN Access Domain - A LRN LRN Edge Router Access Domain - B Internal Router Transit Domain 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 -> 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@foo.com: 128.59.16.1 registrar

28. a@foo.com: 128.59.16.1 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 -> binding duration • lack of permanent address (e.g., DHCP) not a problem -> 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 • Can’t 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 <cpl> <subaction id="voicemail"> <location url="sip:jones@voicemail.example.com" ><proxy /> </location> </subaction> <incoming> <location url="sip:jones@jonespc.example.com"> <proxy timeout="8"> <busy><sub ref="voicemail" /></busy> <noanswer><sub ref="voicemail" /></noanswer> </proxy> </location> </incoming> </cpl>

35. sip-cgi: scripting phone calls use DB_File; sub fail { my($status, $reason) = @_; 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 doesn’t work indoors • phones can move easily – IP address does not help

37. Emergency calls common emergency identifier: sos@domain EPAD REGISTER sip:sos Location: 07605 302 Moved Contact: sip:sos@psap.leonia.nj.us Contact: tel:+1-201-911-1234 SIP proxy INVITE sip:sos Location: 07605 INVITE sip:sos@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 < 50% • Still need common database • can separate REGISTER • make rest read-only

40. Large system stateless proxies sip1.example.com a1.example.com a2.example.com sip2.example.com sip:bob@example.com b1.example.com sip:bob@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 sip:7134@cs • Ethernet phones, soft phones and conference room • CINEMA set of servers, running on 1U rackmount server

45. CINEMA components Cisco 7960 MySQL sipconf rtspd 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 Nortel Cisco Meridian 2600 VoiceXML PBX server T1 T1 SIP sipvxml PhoneJack interface sipc SIP-H.323 converter sip-h323

46. Experiences • Need flexible name mapping • Alice.Cueba@cs alice@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 doesn’t 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