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


  • 97 Views
  • 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


Outline

Outline

  • 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]: 128.59.16.1

registrar


Threats

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?


Threats1

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


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

REGISTER

To: sip:[email protected]

401 Unauthorized

WWW-Authenticate: Digest

realm="[email protected]",

qop=auth,

nonce="dcd9"

REGISTER

To: sip:[email protected]

Authorization: Digest

username="alice",

nc=00000001,

cnonce="defg",

response="9f01"

REGISTER

To: sip:[email protected]

Authorization: Digest

username="alice",

nc=00000002,

cnonce="abcd",

response="6629"


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]

EPAD

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

sip1.example.com

a1.example.com

a2.example.com

sip2.example.com

sip:[email protected]

b1.example.com

sip:[email protected]

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


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


Motivation

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


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

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


Experiences

Experiences

  • 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


Experiences1

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


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


Conclusion

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


  • Login