Embed Size (px)
Citation preview
hgs/IEEE 2001 1
The phone is ringing - now what?Henning Schulzrinne
Dept. of Computer ScienceColumbia UniversityNew York, New York
(sip:)[email protected]
Computer and Communications Societies Joint Chapter – IEEE NJ Coast Section
March 2, 2001
March 2001
hgs/IEEE 2001 2
Overview
• A brief history
• VoIP service models
• The IETF VoIP architecture
• Peer-to-peer and master-slave architectures
• The Session Initiation Protocol (SIP)
• What makes VoIP difficult?
• Columbia CS prototype and trial
• The dangers of VoIP
• Instant messaging & presence➠ generic event service
• Killer application➠ programmable services
March 2001
hgs/IEEE 2001 3
Historical perspective
1876 invention of telephone
1915 first transcontinental telephone (NY–SF)
1920’s first automatic switches
1956 TAT-1 transatlantic cable (35 lines)
1962 digital transmission (T1)
1965 1ESS analog switch
1977 4ESS digital switch
1980s Signaling System #7 (out-of-band)
March 2001
hgs/IEEE 2001 4
Internet Telephony Service Models
• Internet “PBX”
• Internet Centrex
• Internet Carrier
➠ same basic equipment, but size of gateway varies
March 2001
hgs/IEEE 2001 5
Internet PBX
1
IP
0 0
T1, ISDN (BRI/PRI) or analog lines
SIP proxy server
Ethernet
ISP
March 2001
hgs/IEEE 2001 6
IP Centrex
Internet Heads Up Barber
IP
PSTNISP
Ralph’s Pretty Good Grocery
Chatterbox Cafe
March 2001
hgs/IEEE 2001 7
IP Carrier
0 0
IP
1
MGCPH.248
SIP
SS7
GW
GW
GW
GWGW
GW
GW
GW
El Paso
San Francisco
Bell Canada
Montreal
Verizon
PacificBell
DallasQwest
MCI
BellSouth
New York
Chicago
PacificBell
Denver
BellSouth
LA
March 2001
hgs/IEEE 2001 8
IETF VoIP Protocol Architecture
Signaling
TLSSCTP
IntServDiffServ
SLP
Directory/Discovery
master−slave
peer−to−peerRTSP
QoS Transport
SPIRITS
PINTLDAPDNS/enum TRIP
SIP MGCPH.248
RTP
Languages/APIsvoiceXMLCPL
servletssip−cgi
JAINParlay
March 2001
hgs/IEEE 2001 9
IETF VoIP Architecture Characteristics
• universal identifieruser@domain: SIP URL= email= NAI
• separation of transport of services
• media-neutral, including beyond audio and video
• emphasis on user-programmable services
• web integration: content, mutual referral
• integration with IM and presence
March 2001
hgs/IEEE 2001 10
Master-Slave Architecture
• master-slave: MGC controls one or more gateways
• allows splitting of signaling and media functionality
• “please send audio from circuit 42 to 10.1.2.3”
• uses MGCP (implemented) or Megaco/H.248 (standardized, but just beginning tobe implemented)
• gateway can be residential
• basis of PacketCable NCS (network control system) architecture
• service creation similar to digital PBX or switch
• −→ can charge for caller id, call waiting
March 2001
hgs/IEEE 2001 11
MGCP Architecture
MGCP/Megaco SS7
SIP SIP
H.323 H.323 ISUP
MGCP/Megaco
TCAP
RTP
TGW
SCP
STP
RGW
RGW
MG controller SS7 gwycall agent call agent
MG controller
InternetPSTN
• for all but small system, need peer-to-peer!
• MGCP system can call SIP or H.323 end system
• all use RTP to transfer data
March 2001
hgs/IEEE 2001 12
Peer-to-Peer Architecture
• “IP telephones”, gateways, PCs with software = IP hosts
• mayuse servers (H.323 gatekeepers, SIP proxy servers)
• end system fully state-aware
• protocols for call setup: H.323 or SIP
• more flexible user interface
March 2001
hgs/IEEE 2001 13
SIP Overview
• protocol for establishing, modifying, tearing down (multimedia) sessions
• IETF Proposed Standard since March 1999
• multimedia = audio, video, shared applications, text, . . .
• also used for “click-to-dial” (PINT wg) and possibly Internet call waiting(SPIRITS wg)
• to be used for PacketCable Distributed Call Signaling
• to be used for Third-Generation Wireless (3GPP, 3GPP2)
March 2001
hgs/IEEE 2001 14
SIP Components
entity does examples
proxy server forward calls firewall controller, “call router”
redirect server “application server”
user agent end system SIP phone, gateway, “softswitch”
registrar location mgt. mobility support
Roles are changeable, on a request-by-request basis
March 2001
hgs/IEEE 2001 15
SIP Example: Redirection
1
4
32
6
7
8
5
?
henn
ing
INVITE [email protected]
302 Moved temporarily colu
mbi
a.ed
u
locationserver
columbia.edu
hgs
tu-berlin.de
INVITE [email protected]
200 OK
ieee.org
Contact: [email protected]
March 2001
hgs/IEEE 2001 16
SIP Example: Proxying
9 media stream
4
8
7
1
6
5
3
?
henn
ing
hgs@
play
tune
play
cs.columbia.edu
200 OK
location server
200 [email protected]−berlin.de
cs.tu−berlin.de INVITE hgs@play
ACK hgs@play
2
March 2001
hgs/IEEE 2001 17
SIP Forking Proxies
INVITE [email protected]
INVITE bob@b
200 OK
INVITE carol@c
ACK
200 OK
a.wonderland.com
macrosoft.com
CANCEL bob@c
March 2001
hgs/IEEE 2001 18
SIP Advanced Features
• forking
• extensibility: new headers, methods, bodies
• security: web-like, PPP/CHAP or PGP
• multicast-capable
• support for personal, session, terminal, service mobility
• caller preferences: direct calls based on properties
March 2001
hgs/IEEE 2001 19
SIP Mobility
terminal cross-provider REGISTER, re-INVITEpersonal different terminals, same addressREGISTERservice different terminals, same services upload
session move sessions across terminalsREFER
March 2001
hgs/IEEE 2001 20
SIP Personal Mobility
[email protected]:12015551234
tel:12128541111
(also used by [email protected])
yahoo.com
columbia.edu
March 2001
hgs/IEEE 2001 21
SIP years
Year development trade rags
1996-1998 R&D “academic exercise’, “distraction from H.323”
1999 standard & skunk works “what does SIP stand for again?”
2000 product development “SIP cures common cold!”
2001 pioneer deployment “Where are the SIP URLs?”
2002 kmart.com/sip SIP product comparisons
March 2001
hgs/IEEE 2001 22
SIP Status Early 2001
• almost all telecom equipment vendors working on SIP products
• first general-availability SIP hardware (Ethernet phones, small gateways), butlimited
• number of SIP proxy servers in customer trials
• ready for field trials and early-adopter “PBX-free” enterprises
• but can’t buy couple of SIP phones from web page
March 2001
hgs/IEEE 2001 23
So I Want to Build a SIP Network. . .
Ready for trials, but probably not quite for shrink-wrap status:
• installation and operation still requires fair amount of expertise
• lots of web and email experts, few SIP experts
• needs some external infrastructure: DHCP and SRV, possibly AAA
• inconsistent configuration for Ethernet phones (being worked on)
• SIP phones still more expensive than analog phones➠ hard to justify PBXreplacement (incremental cost)
• no just-download or ship-with-OS “soft” clients
March 2001
hgs/IEEE 2001 24
Why aren’t we junking switches right now?
What made other services successful?
email: available within self-contained community (CS, EE)
web: initially used for local information
IM: instantly available for all of AOL
All of these . . .
• work with bare-bones connectivity (≥ 14.4 kb/s)
• had few problems with firewalls and NATs
• don’t require a reliable network
March 2001
hgs/IEEE 2001 25
Why aren’t we junking switches right now?
Telephone services are different:
• reliability expectation 99.9%↗ 99.999%
• PC not well suited for making/receiving calls – most residential handsets arecordless or mobile
• business sets: price incentive minor for non-800 businesses
• services, multimedia limited by PSTN interconnection
• initial incentive of access charge bypass fading (0.5c/min.)
• international calls only outside Western Europe and U.S.
March 2001
hgs/IEEE 2001 26
Prognosis
• much less cable telephony than predicted, mostly boring GR303
• greenfield PBX installations for net-savvy enterprises
• enhancements for maxed-out PBXs – need PBX Ethernet interfaces
• tie-line replacements for branch offices
• backbones for some carriers
• maybe DSL and cable modems, but lifeline? replacement of cordless phones?
• 3G deployment, assuming any 3G companies not bankrupted by license fees
March 2001
hgs/IEEE 2001 27
Prognosis, cont’d.
• BICC & ISUP-carriage for legacy-burdened carriers
• H.323 for conferencing (until Microsoft ships Windows SIP client . . . )
• need T.120-equivalent for cross-platform screen sharing, e.g., VNC
March 2001
hgs/IEEE 2001 28
Standardization
• interaction with resource reservation
• caller preferences (“no mobile phones, please”)
• interoperation with ISUP (“SIP-T”)
• call transfer and third-party control
• conferencing: central server, end system, full mesh
• server benchmarking and scaling
• requirements for deaf users
• call processing language: coordination with iCal
March 2001
hgs/IEEE 2001 29
Status of SIP working group items
reliable provisional IESG review
caller preferences WG last call done
call flows ready for last call
SIP guidelines WG last call done
ISUP over MIME ready for IESG
SIP MIB needs update
server feature ann. revisions based on IESG feedback
service examples needs work
session timer ready for WG last call
call transfer in revision
state maintenance ready for last call
DHCP IESG revisions done
March 2001
hgs/IEEE 2001 30
SIP Bake-Off
• takes place every four months, 7th at ETSI March 2001
• 45 organizations from 11 countries
• about 50-60 implementations:
– IP telephones and PC apps
– proxy, redirect, registrar servers
– conference bridges
– unified messaging
– protocol analyzers
• first IM/presence interop test
• emphasis on advanced services (multi-stage proxying, tel URLs, call transfer,IVR, . . . )
March 2001
hgs/IEEE 2001 31
PSTN legacies to avoid
• E.164 numbers – might as well wear bar codes
• tones and announcements
• in-band signaling for features (DTMF)
• systems with user-interface knowledge (12 keys, voice)
• voice-only orientation (BICC, MGCP/Megaco)
• integration of bit transport and services
• service-specific billing➠ separate signaling & billing
• trusted networks without crypto
➠ confine PSTN knowledge to edge of network
March 2001
hgs/IEEE 2001 32
The Dangers of VoIP
• focus on single service: voice, fax, . . .
• PSTN: service orientation←→ Internet: neutral transport
• APIs as least common denominator across POTS, ISDN, SS7−→ 100-year oldfunctionality
• carbon-copy replication of existing services
• terminology overload
March 2001
hgs/IEEE 2001 33
Replication of Existing Services
• “user is familiar with PSTN services”
• but how many users actually know how to use call transfer or directed pick-up?
• user interface is often just legacy of key systems or other ancient technology
• avoid binding of identifiers to devices – call person or group of people, regardlessof location
• instead, model desired behavior
• single-server features don’t need standardization
• find general mechanisms (e.g.,REFER for three-party calls and various calltransfers)
March 2001
hgs/IEEE 2001 34
Terminology Overload
Invasion of the meaningless technical-sounding terms, attempting to familiar mimicPSTN boxes:
• CO switch−→ soft switches = gateway + SIP UA + ?
• SCP−→ application servers = proxy? web server? media server?
• PBX−→ Internet PBX = proxy? + gateway?
• . . .
Temptation: new name−→ new protocols, APIs, . . . – the old boxboundaries don’tnecessarily make sense!
March 2001
hgs/IEEE 2001 35
It’s That Simple. . .
We really only have a few basic components:
• PSTN gateway, with some combination of FXO/FXS
• SIP proxy/redirect/registrar servers (or H.323 gatekeepers)
• SIP user agents (or H.323 terminals): PCs, phones
• media storage servers
• DNS, directory, web, email, news, . . . servers
March 2001
hgs/IEEE 2001 36
Invisible Internet telephony
“VoIP” technology will appear in
• Internet appliances
• home security cameras, web cams
• 3G mobile terminals
• fire alarms and building sensors
• chat/IM tools
• interactive multiplayer games
• 3D worlds: proximity triggers call
March 2001
hgs/IEEE 2001 37
Internet Telephony – as Part of Internet
• universal identifier: email address = SIP address = IM address
• SIP URLs in web pages
• forward to email, web page, chat session, . . .
• include web page in invitation response (“web IVR”)
• third-party control of calls via scripts,
• include vCard, photo URL in invitation
• user-programmable services: CGI (RFC 3050), CPL, servlets
March 2001
hgs/IEEE 2001 38
Example: Columbia CS phone system
Expand existing PBX via IP phones, with transparent connectivity
IP
010
7130 − 7139
T1
7000
departmental
7199
(about 110 phones)
10/100 Mb/s switched Ethernet
sipdCisco 2600
NortelMeridian
T1
212 9397xxx
March 2001
hgs/IEEE 2001 39
CINEMA
request, responsetransactioncgi scriptsbasic authenticationdigest authentication
libsip
sipum
SIP UAcall stateREGISTERendpoint classSDP
siph323 sipconf
lipsip++
sipdrtspd
PGP
LDAP
SIP proxy server
libNT
SIP conferencing server
NT versions of aliases crypt
PGPPWLresparse
libdict
dictionary
hash tables
libmixer
hashtable inet regex getopt utilities
dstringhost2ip
mix RTP audio
SIP/RTSP unified messagingSIP/H.323 gateway
MySQLMySQL
SIP/MGCP gatewayRTSP media server
GSM, DVI codecs
msgflow
OpenH323 AT&T MGCP
CINEMA
sipgw
Xerces
config./DB access
libcine
parserURIsloggingMD5
software licensingTCPUDP
RTPlib
March 2001
hgs/IEEE 2001 40
sipd single sign-on for account creation and modification
March 2001
hgs/IEEE 2001 41
sipd contact management
March 2001
hgs/IEEE 2001 42
sipd user configuration
March 2001
hgs/IEEE 2001 43
The largest signaling network does not run SS7
• AT&T: 280 million calls a day
• AOL: 110 million emails/day, total about 18 billion/day
• total> 1 billion instant messages/day (AOL: 500 million)
• telephony signaling≈ IM, presence
March 2001
hgs/IEEE 2001 44
Commonalities between signaling and events
• presence is just a special case of an event: “Alice logged in”≈ “house temperaturedropped below 50 deg.”
• need to locate mobile end points (for notifications)
• may need to find several different destinations
• same addressing for users
• presence often precursor to calls
• may replace call back, call waiting and voice mail tag
• likely to be found in same devices
• events already in VoIP: message alert, call events, conf. joins
March 2001
hgs/IEEE 2001 45
SIP as a presence & event platform
• minimal SIP extension:SUBSCRIBE to request notifcations,NOTIFY whenevent occurs
• also,MESSAGE for IM, sessions for multi-party chats
• transition to true “chat” (and video)
• services such as reaching mobile phone while in meeting
March 2001
hgs/IEEE 2001 46
Architecture proposal
• integrate into common architecture for Internet-wide notification and messaging➠ new basic internet service:
Asynchronous messaging with pickupSMTP + POP/IMAP
Data retrieval HTTP, ftp, tftp
Export computer UI telnet, ssh, X11, vnc
Synchronous messaging SIP
March 2001
hgs/IEEE 2001 47
Observations
• single-valued (light-switch) to complex (CD changer) to multi-valued(temperature samples)
• both built-in and mediated (X10)
• often combined with audio/video in same system: security, industrial control,home entertainment
• notification rates vary➠ gradual transition to continuous media
1001010.10.01
IR detector control audio/videosensortemperature process packet
events (packets) / second
March 2001
hgs/IEEE 2001 48
Events: SIP for appliances
SUBSCRIBE [email protected]
NOTIFY [email protected]
INVITE [email protected]
DO [email protected] user agentSIP proxy
(RGW)
March 2001
hgs/IEEE 2001 49
Programming Internet multimedia services
Primarily, creation, forwarding, proxying, rejection of calls
APIs (Parlay, JAIN): protocol-neutral (SIP, H.323, ISUP), but may be least commondenominator
SIP CGI: use Perl and other scripting languages; easy to learn
Servlets: Java only; faster than cgi; limited functionality
CPL: = XML-based language foruserservice creation; portable across providers, butnot all services
• Protocol-neutral: Parlay, JAIN, CPL
• Call creation: Parlay, JAIN
• VoiceXML is for voice-service creationafter call setup
March 2001
hgs/IEEE 2001 50
Example Call Processing Language script
<?xml version="1.0" ?><!DOCTYPE cpl SYSTEM "cpl.dtd">
<cpl><subaction id="voicemail">
<location url="sip:[email protected]">
<redirect /></location>
</subaction>
<incoming><address-switch field="origin"
subfield="host"><address
subdomain-of="cs.columbia.edu"><location url=
"sip:[email protected]">
<proxy><busy>
<sub ref="voicemail" /></busy><noanswer>
<sub ref="voicemail" /></noanswer><failure>
<sub ref="voicemail" /></failure>
</proxy></location>
</address><otherwise>
<sub ref="voicemail" /></otherwise>
</address-switch></incoming>
</cpl>
March 2001
hgs/IEEE 2001 51
Conclusion
• basic IETF-based architecture in place
• SIP as foundation for services
• extensions for mobility, emergency services,. . . in progress
• first (and last?) chance to recover from 120 years of legacy
• avoid replication of PSTN on packets
• most VoIP applications won’t look like telephones
• range of engagement and asynchronicity, from call to IM to email
• challenge of mobile services
March 2001
hgs/IEEE 2001 52
For more information. . .
SIP: http://www.cs.columbia.edu/sip
RTP: http://www.cs.columbia.edu/˜hgs/rtp
Papers: http://www.cs.columbia.edu/IRT
March 2001
