Presentation is loading. Please wait.

Presentation is loading. Please wait.

When will the telephone network disappear? Henning Schulzrinne Columbia University June 2002.

Similar presentations

Presentation on theme: "When will the telephone network disappear? Henning Schulzrinne Columbia University June 2002."— Presentation transcript:

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? soft phones PSTN 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


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 , 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: > $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, voic

15 Technology evolution of PSTN SS7:

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 : 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 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 addresses = SIP URIs 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 – personal domains? mostly easy to find (Google), but hard to type

29 Naming and addressing Have any one of three, need others phone /SIPweb phone--ENUM /SIPLDAP? SIP --LDAP? SIP webtel:sip:--

30 Naming and addressing ENUM: translate to 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 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


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 – 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 SIP trapezoid outbound proxy 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 EPAD INVITE Location: REGISTER sip:sos Location: Moved Contact: Contact: tel: SIP proxy INVITE sip:sos Location: common emergency identifier:

44 Scaling and redundancy Single host can handle calls + registrations/second 18, ,000 users 1 call, 1 registration/hour Conference server: about 50 small conferences or large conference with 100 users Reliability: single expensive % 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 < 50% Still need common database can separate REGISTER make rest read-only

46 Reliability: power In US, typically about hours/year of power outage (SAIDI, 99.95%) plus ~3 short (< 5 min) outages (MAIFIe) Alternatives: cell phone UPS in Ethernet switches Ethernet power on spare pairs

47 Large system _sip._udp SRV 0 0 0 0 0 0 _sip._udp SRV 0 0 0 0 stateless proxies

48 Migration strategy 1. Add IP phones to existing PBX or Centrex system – PBX as gateway Initial investment: $2k for gateway 2. Add multimedia capabilities: PCs, dedicated video servers 3. Reverse PBX: replace PSTN connection with SIP/IP connection to carrier 4. Retire PSTN phones

49 Example: Columbia Dept. of CS About 100 analog phones on small PBX DID no voic T1 to local carrier Added small gateway and T1 trunk Call to 7134 becomes Ethernet phones, soft phones and conference room CINEMA set of servers, running on 1U rackmount server

50 CINEMA components RTSP sipum Cisco 7960 sipvxml SIP rtspdsipconf LDAP server MySQL PhoneJack interface sipc T1 sipd media server RTSP SIP-H.323 converter messaging server unified server (MCU) user database conferencing sip-h323 VoiceXML server proxy/redirect server Cisco 2600 Pingtel wireless b PBX Meridian Nortel plug'n'sip

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 voic 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: CINEMA:

Download ppt "When will the telephone network disappear? Henning Schulzrinne Columbia University June 2002."

Similar presentations

Ads by Google