challenges of voice over ip the second quarter century
Skip this Video
Download Presentation
Challenges of Voice-over-IP – The Second Quarter Century

Loading in 2 Seconds...

play fullscreen
1 / 51

Challenges of Voice-over-IP – The Second Quarter Century - PowerPoint PPT Presentation

  • Uploaded on

Challenges of Voice-over-IP – The Second Quarter Century. Henning Schulzrinne Dept. of Computer Science Columbia University. Outline. A brief history Challenges: QoS Security NATs Service creation Scaling Interworking Emergency calls CINEMA project at Columbia. A brief history.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Challenges of Voice-over-IP – The Second Quarter Century' - carson

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
challenges of voice over ip the second quarter century

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

Henning Schulzrinne

Dept. of Computer Science

Columbia University

  • A brief history
  • Challenges:
    • QoS
    • Security
    • NATs
    • Service creation
    • Scaling
    • Interworking
    • Emergency calls
  • CINEMA project at Columbia
a brief history
A brief history
  • August 1974
    • Realtime 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)
a brief history1
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)
voip applications
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, ...
where are we
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, …
status in 2002
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
where are we1
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”
where are we2
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
voip at home
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
sip phones
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
voip protocol components
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
challenges qos
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
challenges qos1
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
challenges security
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
sip security
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
system model
System model

outbound proxy

SIP trapezoid

[email protected]:


  • 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?
  • 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
l3 l4 security options
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
hop by hop security tls
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
http digest authentication
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
http digest authentication1
HTTP Digest authentication


To: sip:[email protected]

401 Unauthorized

WWW-Authenticate: Digest

realm="[email protected]",




To: sip:[email protected]

Authorization: Digest






To: sip:[email protected]

Authorization: Digest





end to end authentication
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
end to end authentication1
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
end to end authentication and confidentiality
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
ssh style authentication
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
dos attacks
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
dos attacks amplification
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
dos attacks memory
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
challenges nats and firewalls
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
challenges nat and firewalls
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
challenges service creation
Challenges: service creation
  • Can’t win by (just) recreating PSTN services
  • Programmable services:
    • equipment vendors, operators: JAIN
    • local sysadmin, vertical markets: sip-cgi
    • proxy-based call routing: CPL
    • voice-based control: VoiceXML
emergency calls
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
emergency calls1
Emergency calls

common emergency identifier: [email protected]


REGISTER sip:sos

Location: 07605

302 Moved

Contact: sip:[email protected]

Contact: tel:+1-201-911-1234

SIP proxy

INVITE sip:sos

Location: 07605

INVITE sip:[email protected]

Location: 07605

scaling and redundancy
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
scaling and redundancy1
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
large system
Large system

stateless proxies

sip:[email protected]

sip:[email protected]

_sip._udp SRV 0 0

0 0

_sip._udp SRV 0 0

0 0

0 0

enterprise voip
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
  • 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
migration strategy
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
example columbia dept of cs
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:[email protected]
  • Ethernet phones, soft phones and conference room
  • CINEMA set of servers, running on 1U rackmount server
cinema components
CINEMA components

Cisco 7960




user database

LDAP server












proxy/redirect server

















PhoneJack interface





  • Need flexible name mapping
  • 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
  • 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
event notification
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
event notification1
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
sip event notification
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
  • 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