When%20will%20the%20telephone%20network%20disappear?

1
When will the telephone network disappear?

• Henning Schulzrinne
• Columbia University
• June 2002

2
Overview

• What is Internet telephony?
• Why Internet telephony?
• When?
• How to transition to IP telephony?
• What remains to be done?

3
What is Internet telephony?

• Using Internet protocols to transmit voice in
  real-time
• but multimedia (and Internet radio and TV) is
  almost the same ? every telephone can become a
  "broadcaster"
• not necessarily public Internet
• similar to streaming media, but typically human
  on both ends
• also known as VoIP, IP telephony
• related voice-over-packet ATM, FR, MPLS

4
What is Internet telephony?
PSTN phones
soft phones
Ethernet phones
5
VoIP protocols

• Mostly reuse existing protocols, from IP to LDAP
• RTP for transporting audio and video
• SIP for setting up sessions (calls)
• web-like protocol for negotiation and user
  location
• TRIP for finding gateways

6
IP PBX
7
IP Centrex
8
Why Internet telephony?

• Residential user perspective
• cheaper international calls
• U.S. to India, China, Mexico
• video calls to relatives
• integration with IM and presence no phone tag
• (packaged) programmable services
• single number, regardless of medium
• mobile phone
• home phone
• office phone
• easy identifier portability
• multiple lines cheaper via cable modem, DSL
• video monitoring ? don't pay for connect time

9
Why Internet telephony?

• Business user perspective
• no feature set differences between large and
  small businesses
• automatic call distribution (VoiceXML)
• programmable phone services
• like web programming (sip-cgi, CPL, servlets)
• every company own web page ? every company own
  phone services
• easy integration of email, web, IM, databases
• single CAT5 Ethernet wiring plant
• PBX maintenance costs
• PBX growth limits

10
Why Internet telephony?

• Carrier/ISP perspective
• classical switches stagnant
• but still expensive
• Ethernet switch 0.04/"circuit"
• PBX 218/circuit
• Local telephone switch 270/circuit
• avoid separate management infrastructure for
  voice
• new PSTN services hard to deploy
• avoid dog-legged routing for mobile calls
• mobile wireline infrastructure

11
Why should carriers worry?

• Application-specific infrastructure ?
  content-neutral bandwidth delivery
• GPRS 4-10/MB
• SMS gt 62.50/MB
• voice (mobile and landline) 1.70/MB
• anybody can offer phone service
• only need to handle signaling, not media traffic
• no regulatory hurdles

12
Some differences VoIP vs. PSTN

• Separate signaling from media data path
• But, unlike SS7, same network ? lower call setup
  delay
• Avoid CTI complexity of "remote control"
• Mobile and wireline very similar
• Any media as session
• any media quality (e.g., TV and radio circuits)
• interactive games

13
Differences VoIP vs. PSTN

• "Switches" ( SIP proxy servers) are
  service-transparent
• dialog transparency
• media transparency
• security transparency
• topology transparency
• functional transparency
• May not be true in 3GPP

14
When will it happen?

• Took much longer than anticipated in 1995
• standards (signaling) not really ready until this
  year
• not just a protocol, but a whole industry and
  infrastructure eco system
• OSS
• billing
• testing
• features conferences, voicemail

15
Technology evolution of PSTN
SS7 1987-1997
16
When will it happen?

• Not too soon by traditional phone companies
• Billions of / deployed infrastructure
• 41 billion (est.) for local switches in U.S.
• debt-laden carriers
• U.S. CLECs killed by monopolies
• But others
• (business) ISPs
• cable TV companies

17
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)

18
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)

19
Status in 2002

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

20
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

21
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

22
How to transition?

• Several directions at once
• inside out
• inter-PBX trunks
• PSTN backbones
• signaling links
• outside in
• PBX and IP phones
• PC-based soft phones

23
How to transition?

• 3GPP and 3GPP2 have chosen SIP and packet
  audio/video as the technology for 3G Internet
  multimedia subsystem (IMS)
• mostly "real" SIP, with extensions
• walled garden mentality trying to prevent users
  from choosing other SIP carriers

24
What remains to be done?

• NAT and firewall traversal
• cheaper end systems
• naming and addressing
• quality of service
• reliability
• security
• emergency (112) features
• full IM/presence architecture
• conferencing

25
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

26
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

27
Naming and addressing

• Users will have three types of identifiers,
  several of each
• phone numbers random within city ? random
  within country for mobile
• easy to transcribe key in on 12-button phones
• hard to remember
• portability across carriers iffy
• email addresses SIP URIs
• user_at_domain, sipuser_at_domain
• portable if own domain (20/year) or separate
  from carrier
• a pain for existing devices
• but need better alpha input in any event

28
Naming and addressing

• Web URLs http//www.cs.columbia.edu/hgs
• personal domains?
• mostly easy to find (Google), but hard to type

29
Naming and addressing

• Have any one of three, need others

phone email/SIP web
phone -- ENUM ENUM
email/SIP LDAP? SIP -- LDAP? SIP
web tel sip --
30
Naming and addressing

• ENUM translate 358 8 883 9111 to
  1.1.1.9.3.8.8.8.8.5.3.e164.arpa and look up
• SIP-to-x Return on OPTIONS or 302
• Web-to-x defined business card rather than text
  search

31
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, ...

32
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
• voice can tolerate 10 random loss
• averages are misleading impairments are bursty
  ? really reliability problem

33
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

34
(No Transcript)
35
Challenges Security

• PSTN model of restricted access systems ?
  cryptographic security
• Dumb end systems ? PCs with a handset
• Objectives
• identification for access control billing
• phone/IM spam control (black/white lists)
• call routing
• privacy

36
SIP security

• Bar is higher than for email telephone
  expectations (albeit wrong)
• Potential for nuisance phone spam at 2 am
• Safety attacker can prevent emergency calls
• Denial of service attacks a billion more
  sources of traffic

37
System model
outbound proxy
SIP trapezoid
a_at_foo.com 128.59.16.1
registrar
38
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?

39
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

40
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

41
Challenges service creation

• Cant 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

42
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

43
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
44
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
• Reliability single expensive 99.999 system ?
  two cheap 99.7 systems
• typical reliability of good ISP 99.5 ?
  dual-homing
• For larger system and redundancy, replicate proxy
  server

45
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

46
Reliability power

• In US, typically about 1.5-4 hours/year of power
  outage (SAIDI, 99.95)
• plus 3 short (lt 5 min) outages (MAIFIe)
• Alternatives
• cell phone ?
• UPS in Ethernet switches
• Ethernet power on spare pairs

47
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
48
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

49
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

50
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
51
Experiences

• T1/E1's are painful
• dialing plans prefixes, special codes
• billing integration
• probably best to keep separate (web-based
  billing)
• voice mail
• web-based voicemail major reason for switching
• difficult to impossible to integrate fully
• but can retrieve and forward

52
SIP doesnt have to be in a phone
53
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

54
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

55
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

56
Controlling devices
57
Standardization

• Organizations
• IETF for core protocols
• SIP for protocol extensions
• SIPPING for BCPs, requirements
• SIMPLE for IM presence
• MMUSIC for SDP SDPng
• 3GPP (3GGP2) for requirements
• PacketCable for residential requirements

58
Recent SIP developments

• SIP revision (RFC2534bis) done
• semantically-oriented rewrite
• layers message, transport, transaction,
  transaction user
• SDP extracted into separate draft
• UA and proxy have the same state machinery
• better Route/Record-Route spec for loose routing
• no more Basic authentication
• few optional headers (In-Reply-To, Call-Info,
  Alert-Info, )
• Integration of reliable provisional responses and
  server features
• DNS SRV modifications

59
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

60
For more information...

• SIP http//www.cs.columbia.edu/sip
• CINEMA http//www.cs.columbia.edu/IRT/cinema