Title: SIP
1SIP are we there yet?
- Henning Schulzrinne
- (with Kundan Singh)
- Columbia University
- Department of Computer Science
- hgs_at_cs.columbia.edu
- (SIP Summit 2005, Honolulu, Hawaii)
supported by
2Overview
- SIP state of affairs closing in on done
- Common interoperability problems
- intentional vs. unintentional
- How to encourage interoperability
- The SIP configuration mess
- Peer-to-peer SIP
3SIP is PBX/Centrex ready
boss/admin features
call 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
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
centrex-style features
attendant features
from Rohan Mahys VON Fall 2003 talk
4A constellation of SIP RFCs
Non-adjacent (3327) Symmetric resp.
(3581) Service route (3608) User agent caps
(3840) Caller prefs (3841)
Request routing
Resource mgt. (3312) Reliable prov. (3262) INFO
(2976) UPDATE (3311) Reason (3326)
SIP (3261) DNS for SIP (3263) Events (3265) REFER
(3515)
ISUP (3204) sipfrag (3240)
Mostly PSTN
Core
Content types
Digest AKA (3310) Privacy (3323) P-Asserted
(3325) Agreement (3329) Media auth. (3313) AES
(3853)
DHCP (3361) DHCPv6 (3319)
Configuration
Security privacy
5An eco system, not just a protocol
configures
XCAP (config)
SIMPLE policy RPID .
XCON (conferencing)
initiates
carries
SIP
RTSP
SDP
carries
controls
provide addresses
STUN TURN
RTP
6SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
7RFC publication
8When are we going to get there?
- Currently, 14 SIP 31 SIPPING 19 SIMPLE WG
Internet Drafts 64 total - does not count individual drafts likely to be
promoted to WG status - The .com consultant linear extrapolation
technique - pessimist ? 4 more years if no new work is added
to the queue and we can keep up productivity - optimist ? 3 more years (lots of drafts are in
almost-done stage)
9How to ensure protocol interoperability
- Classical Internet approach pairwise lab testing
- Interoperability tests (plug fests)
- multiple implementation, in various stages of
maturity - results (and embarrassment) remain private
- Certification by neutral third parties
- can never be complete
- Lab tests by consulting and publishing companies
- ? SIP is using all of these
10Interoperability efforts
- IETF SIPPING working group
- call flow examples for basic (RFC 3665),
telephony (RFC 3666) and services (draft) - SIPit and SIMPLEt
- held every 6 months
- 15th instance just completed
- ETSI
- TTCN specs
- SIP Forum Certification Working Group
11Protocol interoperability problems
- Three core interoperability problems
- syntactic robustness
- You mean you could have a space there?
- often occurs when testing only against common
reference implementations - need stress test (also for buffer overflows)
- implementation by protocol example
- limiting assumptions (e.g., user name format)
- see SIP Robustness Testing for Large-Scale Use,
First International Workshop on Software Quality
(SOQA) - semantic assumptions
- I didnt expect this error
- mutually incompatible extensions
- expect extension to make something work
12Protocol interoperability proprietary protocols
- Proprietary protocol
- Example Skype
- quicker evolution not dependent on IETF
volunteers with day jobs - can do hacks without IESG objection
- media over TCP
- inefficient search
- bypass routing policies
- circumvent firewall policies
- Can only reverse-engineer ? only
backwards-compatibility problems - incentive to force upgrades (see Microsoft Word)
- less Metcalfes law value
13Why is Skype successful?
- All the advantages of a proprietary protocol
- Peer-to-peer coincidental
- Good out-of-box experience
- Software vendor service provider
- Didnt know that you couldnt do voice quality
beyond PSTN - others too focused on PSTN interoperability why
do better voice than PSTN? - Simpler solutions for NAT traversal
- use TCP if necessary
- use port 80
- Did encryption from the very beginning
- Kazaa marketing vehicle
14Open standard, dominant vendor
- Example H.323
- doesnt matter what the standard says
- NetMeeting and H.323 ? test with Microsoft
implementation - limits feature evolution to dominant vendor speed
and interests
15Open standard, multiple vendors
- Example SIP
- More than just one application
- Software UAs, proxies, phones, gateways, media
servers, test tools, OAM, - interoperability problems until product maturity
- harder to test internally against all (competing)
products - divergent views and communities in IETF and other
SDOs - likely have to support union of requirements
- emphasis on extensibility, modularity and
protocol re-use - ? temptation to not implement everything
- security
- SIP generality over efficiency
- better long-term outcome, but slower
16Why SIP extensions?
- Good interoperability in basic call setup
- Extensions are sometimes indications where work
is needed - or I didnt know this existed
- unfortunately, no good SIP Roadmap document
- some wrong protocol, buddy
- some I dont have the resources to participate
in standardization - currently, 68 SIP/SIPPING/SIMPLE I-Ds
- 26 SIP RFCs ( 13 SIPPING RFCs)
17SIP proprietary extensions
- Examples 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
- visual ringing
- Billing and dialing plan
- Tone for charged vs. free calls
- Caller name identification added by proxies
- P-Asserted-Identity extension
- Call routing diagnostics
18SIP proprietary extensions, contd
- upgrade your endpoint!
- 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
- ? many, make SIP work well in old world on phone
look-alikes - reason given
- local interest only
- takes too long to standardize
19SIP a bi-cultural protocol
- multimedia
- IM and presence
- location-based service
- user-created services
- decentralized operation
- everyone equally suspect
- overlap dialing
- DTMF carriage
- key systems
- notion of lines
- per-minute billing
- early media
- ISUP BICC interoperation
- trusted service providers
20The 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 ( SDP RTP) ? - SIP still more complex due to signaling-data
separation
IAX model
Signaling Media
Signaling Media
Signaling
Signaling
Media
SIP, H.323, MCGP model
21Does it have to be that complicated?
- highly technical parameters, with differing names
- inconsistent conventions for user and realm
- made worse by limited end systems (configure by
multi-tap) - usually fails with some cryptic error message and
no indication which parameter - out-of-box experience not good
22Solving the configuration mess
- Initial development assumed enterprise deployment
- pre-configured via tftp or (rarely) DHCP
- not suitable for residential use, except if box
is shipped - pathetic security password accessible to
anybody who knows MAC address of phone - Short term
- adopt simple default conventions
- should only need SIP URI (AoR), display name and
password - realm URI
- outbound proxy domain
- provide and expose error feedback
- not authentication failure
- but realm not recognized change to user_at_domain
format - use DNS NAPTR and SRV for STUN server
23Solving the configuration mess longer term
- IETF efforts on configuration management
- retrieve via HTTP ( TLS)
- change notification via SIP event notification
- problem of configuring initial secret remains
- probably need embedded public keys
- Still need better diagnostics
- one-way voice issues
- authentication failures
24VoIP end system configuration
registrar address STUN/TURN local and global
DNS
AOR
SIP SUBSCRIBE/NOTIFY
general configuration document (media, UI,
protocol behavior, )
DHCP
MAC address
geographical location (for 911) outbound proxy
thats all it should take
25NAT and VPN troubles
- Unplanned transition from Internet one global
address space to clouds (realms) of unknown
scope - Cant 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)
Internet
?
home NAT
?
?
ISP NAT
26NAT solutions
and then a miracle occurred
avoid evil NATs
find STUN and TURN servers easily
IPv6
NAT boxes with built-in address discovery and
allocation
well-defined NAT behavior ? allow informed
deployment decisions
27Server-based vs peer-to-peer
- Server-based
- Cost maintenance, configuration
- Central points of failures
- Managed SIP infrastructure
- Controlled infrastructure (e.g., DNS)
- Peer-to-peer
- Robust no central dependency
- Self organizing, no configuration
- Scalability ?
28P2P-SIP
- Differences to proprietary Skype architecture
- Robust and efficient lookup using DHT
- Interoperability
- DHT algorithm uses SIP protocol messages
- Hybrid architecture
- First try DNS NAPTR/SRV
- if no SIP server there, then lookup in SIPP2P
- Unlike file-sharing applications
- Data storage, caching, delay, reliability
- Disadvantages
- Lookup delay and security
29P2P-SIPBackground DHT (Chord)
Key node
81 9 14
82 10 14
84 12 14
88 16 21
81624 32
83240 42
1
54
8
58
10
14
47
21
- Identifier circle
- Keys assigned to successor
- Evenly distributed keys and nodes
- Finger table logN
- ith finger points to first node that succeeds n
by at least 2i-1 - Stabilization for join/leave
42
38
32
38
24
30
30P2P-SIPDesign Alternatives
servers
1
54
10
38
24
30
clients
Use DHT in server farm
Use DHT for all clients But some are resource
limited
Use DHT among super-nodes
31P2P-SIPNode architecture registrar, proxy, user
agent
Signup, Find buddies
IM, call
On reset
Signout, transfer
On startup
Leave
Find
Join
REG, INVITE, MESSAGE
Multicast REG
Peer found/ Detect NAT
REG
- DHT communication using SIP REGISTER
- Known node sip15_at_192.2.1.3
- Unknown node sip17_at_sippeer.net
- User sipalice_at_example.com
32P2P-SIPImplementation
31
29
31
- sippeer C, Linux, Chord
- Nodes join and form the DHT
- Node failure is detected and DHT updated
- Registrations transferred on node shutdown
- only need extension for avoiding outbound proxy
confusion - Co-located classical UA can use sippeer service
with a P2P adaptor (built)
25
26
15
33Conclusion
- SIP is now a mature protocol, with a surrounding
eco system - Almost all of the core features necessary for
common services are RFCs or well-baked Internet
drafts - Interoperability more difficult in a multi-vendor
environment - Out-of-box experience needs work
- Can do peer-to-peer SIP without significant
protocol extensions complementary, does not
replace existing model