SIP Summit (Chicago, June 22, 2004) 1
SIP in 2004 – The Challenge of Being a Successful Protocol
Henning Schulzrinne
Columbia University
SIP Summit (Chicago, June 22, 2004) 2
Outline
Successes: hardware 3GPP residential VOIP sip.edu PTT
Standardization 80/20 rule
Challenges ahead: A cross-cultural protocol Perception and reality of
complexity NAT and firewall issues Large-scale mixed-vendor
deployment Inter-domain deployment SIP spam
Opportunities Improving the user
experience beyond PSTN
SIP Summit (Chicago, June 22, 2004) 3
(Early) Adulthood
“fully developed and mature” Not quite yet, but no
longer a teenager probably need another
6 years to be grown up…
Responsibilities: Dealing with elderly
relatives POTS Financial issues
payments, RADIUS Family emergencies
911
SIP Summit (Chicago, June 22, 2004) 4
SIP products beyond $600 office phones
Finally, basic IP phones below $100
802.11 phones video conferencing speakerphones $65
SIP Summit (Chicago, June 22, 2004) 5
SIP deployments – landline
Consumer broadband: Vonage (165,000 lines), Packet8, … buckets of minutes or unlimited
long-distance SIP invisible, but it just works
Time-Warner: “Time Warner Cable, the second-largest US cable group, will [in 2004] roll out a national internet-based telephone service.”
AT&T: “The long-distance giant plans to offer VoIP-enabled services to 1 million consumers in the next two years, beginning with a roll-out in major cities across the U.S. in the first quarter of 2004.”
Verizon MCI Advantage (for business) Focused on hosted SIP services, rather than just SIP termination Few midsize-to-large companies still considering traditional circuit-
switched PBX for replacement
SIP Summit (Chicago, June 22, 2004) 6
SIP deployments – wireless
Usage for controlling new push-to-talk services not user-visible, but may emerge from hiding first step to presence-enabled voice services
Sprint PCS Readylink service “first commercial deployment of SIP by a wireless
carrier”
3G (R5) services much slower in coming
SIP Summit (Chicago, June 22, 2004) 7
Deployment example: SIP.edu
Deploy SIP and VoIP across Internet2 educational institutions
Transition E.164 SIP URIs But don’t wait for VoIP end system deployment
“+1-617-637-8562, come here. I need you!”
(from slides by Ben Teitelbaum)
A. G. Bell did not say:
SIP Summit (Chicago, June 22, 2004) 8
SIPProxy
DNSSIP-PBXGateway
PBX
INVITE (sip:[email protected])
INVITE(sip:[email protected])
DNS SRV query sip.udp.bigu.edu
telephoneNumberwhere mail=”bob”
PRI / CASbigu.edu
CampusDirectory
SIP User Agent
Bob's Phone
SIP.edu Architecture (Phase 1)
© Ben Teitelbaum, with permission
SIP Summit (Chicago, June 22, 2004) 9
DNS
INVITE (sip:[email protected])DNS SRV query
sip.udp.bigu.edu
bigu.edu
SIP User Agent
SIP.edu Architecture (Phase 2)
locationDB
If Bob has registered, ring his SIP phone; Else, call his extension through the PBX.
REGISTER(Contact: 207.75.164.131)
INVITE (sip:[email protected])
SIPProxy
SIPRegistrar
Bob's SIP Phone
© Ben Teitelbaum, with permission
SIP Summit (Chicago, June 22, 2004) 10
SIP.edu growth
http://voip.internet2.edu/SIP.edu/
e.g., sip:[email protected] +1 212 939 7042
SIP Summit (Chicago, June 22, 2004) 11
Overview
SIP in 2003 Standardization – a long, hard
slog Filling in the product palette
finally, cheap phones VoIP (and SIP) over WiFi
(802.11) Real deployments
commercial (wireless, consumer, enterprise)
Embedded (push-to-talk) Internet2
SIP as a brand: SIPphone, SIPura, SIPtele, SIPquest, SIPCPE, …
SIP in 2004 Large-scale consumer
usage How much regulation
for VoIP? Emergency calling Standardized IM &
presence Better auto-
configuration
SIP Summit (Chicago, June 22, 2004) 12
Major RFCs published recently Third-party call control (RFC 3275)
allows non-media entity to control sessions Event package for registrations (RFC 3680) Security mechanism agreement (RFC 3329)
negotiate algorithms with next hop Requirements for resource priority (RFC 3487)
prioritization of calls in military networks and emergencies REFER method (RFC 3515)
call transfer DHCPv6 for SIP (RFC 3319)
automatic outbound proxy configuration Proxy-to-proxy extensions for PacketCable (RFC 3603) Symmetric response routing (RFC 3581)
improved NAT interaction
SIP Summit (Chicago, June 22, 2004) 13
Major RFCs published
Service route discovery (RFC 3806) REGISTER returns “preloaded route” to be used by UA for services
SIP and SDP compression (RFC 3485/3486) compress SIP headers and body via dynamic dictionary
Call flows (RFC 3665/3666) explain behavior by example useful for testing common cases not a spec replacement
Summary: except for REFER, mostly relevant to subsets of SIP developer community PacketCable 3G Military, emergency response
SIP Summit (Chicago, June 22, 2004) 14
RFCs in the pipeline
Ready & done, but typically waiting for normative references
Examples: message waiting indication caller preferences CPL user agent capabilities ENUM for SIP H.323 interworking requirements presence – events, CPIM, watcher info, …
SIP Summit (Chicago, June 22, 2004) 15
When are we going to get there?
In 2003, 6 SIP + 2 SIPPING RFCs published In 2002, 14 SIP + 4 SIPPING RFCs Currently, 20 SIP + 24 SIPPING + 22 SIMPLE WG
Internet Drafts does not count individual drafts likely to be “promoted” to WG
status The .com consultant linear extrapolation technique®
pessimist 8.5 more years if no new work is added to the queue
optimist 4 more years
SIP Summit (Chicago, June 22, 2004) 16
SIP is PBX/Centrex readycall waiting/multiple calls
RFC 3261
hold RFC 3264
transfer RFC 3515/Replaces
conference RFC 3261/callee caps
message waiting message summary package
call forward RFC 3261
call park RFC 3515/Replaces
call pickup Replaces
do not disturb RFC 3261
call coverage RFC 3261
from Rohan Mahy’s VON Fall 2003 talk
simultaneous ringing
RFC 3261
basic shared lines dialog/reg. package
barge-in Join
“Take” Replaces
Shared-line “privacy”
dialog package
divert to admin RFC 3261
intercom URI convention
auto attendant RFC 3261/2833
attendant console dialog package
night service RFC 3261
centr
ex-s
tyle
featu
res
boss/admin features
attendant features
SIP Summit (Chicago, June 22, 2004) 17
SIP, SIPPING & SIMPLE –00 drafts
0
10
20
30
40
50
60
70
1999 2000 2001 2002 2003
SIPSIPPINGSIMPLE
includes draft-ietf-*-00 and draft-personal-*-00
SIP Summit (Chicago, June 22, 2004) 18
SIPit 14 (Feb. 2004)
128 attendees from 55 organizations US, Canada, Israel, Japan, Taiwan, France,
Germany, Belgium, UK, Turkey, India, Sweden, Finland, Norway
“The biggest strides between this event and the last were around correct support for TLS. The biggest weakness continues to be proper construction of offers and answers.”
SIP Summit (Chicago, June 22, 2004) 19
SIP proprietary extensions Good interoperability in basic call setup Indications where work is needed
or “I didn’t know this existed” some “wrong protocol, buddy” currently, 68 SIP/SIPPING/SIMPLE I-Ds 22 SIP RFCs
Based on informal email survey Shared line support to emulate key
systems: not dialogs, but state of AORs see SIMPLE
TCAP over SIP for LNP general: pick up information along the
way Auto-answer support (intercom) Caller-indicated ringing preferences
Caller name identification added by proxies
Caller time zone NAT support
STUN servers not widely available – no incentive
some use simple HTTP query (just needs cgi-bin)
probably biggest advantage that Skype has
make SIP work well in old world on phone look-alikes
SIP Summit (Chicago, June 22, 2004) 20
Competition Old competition: H.323 no longer active
development but still in wide use (including CallManager)
New competition: IAX Skype Cisco SCCP (Skinny) ~ MGCP Jabber (IM)
Usually, dominated by single company faster (fewer “what is a tuple discussions”…) concentrated company resources usually
make-or-break for company H.323 = Microsoft NetMeeting compatible
tend to favor efficiency over generality and protocol niceties (internationalization, congestion control, XML, …)
had NAT story from very beginning Skype NAT solution appears to be technically
similar to STUN
Limited focus, e.g.,: silo model
audio only (IAX) for Jabber, classical IM/presence focused
no capability negotiation no proxy support limited security support limited services
call forwarding, transfer, early media, … Unpublished protocols
“trust us, we wouldn’t do anything stupid, would we?”
hard to get protocol eco system variety of end systems diagnostics and protocol analyzers
SIP Summit (Chicago, June 22, 2004) 21
SIP – a bi-cultural protocol
• overlap dialing• DTMF carriage• key systems• notion of lines• per-minute billing• early media• ISUP & BICC interoperation• trusted service providers
• multimedia• IM and presence• location-based service• user-created services• decentralized operation• everyone equally suspect
SIP Summit (Chicago, June 22, 2004) 22
The SIP complexity fallacy
IAX (for example) is simpler than SIP but you could build the IAX
functionality in SIP at just about the same complexity: no proxies no codec negotiation no distributed services
Difficulty: extracting those simple pieces from 269 pages of specification
SIP still more complex due to signaling-data separation
Signaling & Media Signaling & Media
Signaling Signaling
Media
IAX model
SIP, H.323, MCGP model
SIP Summit (Chicago, June 22, 2004) 23
Operational complexity
SIP design user only need to know their SIP address (AOR) and a registration secret familiar to users from web login
Not: outbound proxy STUN server registrar address backup server addresses Digest authentication user name media port range tftp and HTTP server for image
updates …
Configuration failures hard to diagnose
Bad “out of the box” experience Made worse by limited UI of end
systems Misleading or inconsistent
terminology “communication server” “user name”
Can’t have a manually configured configuration server
SIP Summit (Chicago, June 22, 2004) 24
VoIP end system configuration
AOR
MACaddress
registrar addressSTUN/TURN – local and global
general configuration document(media, UI, protocol behavior, …)
geographical location (for 911)outbound proxy
DNS
SIP SUBSCRIBE/NOTIFY
DHCP
that’s all it should take
SIP Summit (Chicago, June 22, 2004) 25
NAT and VPN troubles
Unplanned transition from Internet = one global address space to clouds (“realms”) of unknown scope Can’t know without help whether directly
reachable Any number of concentric spaces
There is no universally workable NAT solution always problems with inbound calls may need to maintain and refresh
permanent connections to globally routable entity
may need relay agent for media (TURN)
?
?
?
home NAT
ISP NAT
Internet
SIP Summit (Chicago, June 22, 2004) 26
NAT solutions
well-defined NAT behavior allow informed deployment decisions
avoid “evil” NATs
NAT boxes with built-in address discovery and allocation
find STUN and TURN servers easily
IPv6
SIP Summit (Chicago, June 22, 2004) 27
SIP spam
Threats: unsolicited (multimedia) calls presence authorization
requests IMs (“spim”)
Could be worse than email and phone telemarketing: immediate interruption “the death of distance”
aluminum siding at 2 am, direct from China
do-not-call list and CAN-SPAM may not apply
Not a SIP problem – Applies to other systems as well
Spam mechanisms have limited applicability can’t do content analysis
(Bayesian filtering) even for IM attention
grabbed after first “Hello” message
human reachability measures interfere with real-time nature
SIP Summit (Chicago, June 22, 2004) 28
SIP spam solutions – some options
Failure of content-based identity-based global, personal PKI tried and failed
economics, liability to scale, must be cheap and easy to get cheap
and easy for spammers, too hard to install on end systems
But domain-level authentication works TLS certificates orders of magnitude fewer servers than phones
Other server ID alternatives: DNS certificate server SPF SRV records for domain servers
Increase value of identity: social networks bonding and warranties identity policy (“we card”) verifiable location information
stranded relative from payphone vs. former rebel leader from Namibia
outbound proxyexample.com
From: [email protected]
shared secret(Digest) verify
example.com
SIP Summit (Chicago, June 22, 2004) 29
Conclusion
SIP making the transition from lab to field push-to-talk residential VoIP some enterprise deployments
Bi-cultural complexity, delay Challenges operational, less protocol
configuration 911 spam