Challenges of voice over ip the second quarter century
This presentation is the property of its rightful owner.
Sponsored Links
1 / 51

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

  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

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

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

    • filtering [email protected] doesn't prevent calls from [email protected] (new day, sam person)

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

    • [email protected][email protected]

    • 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



  • 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

Sip doesn t have to be in a phone

SIP doesn’t have to be in a phone

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

  • Login