View
213
Download
0
Tags:
Embed Size (px)
Citation preview
SIP interoperability and SIP interoperability and extensionsextensions
Henning SchulzrinneDept. of Computer Science
Columbia University, New YorkNGN (Boston, MA)November 2004
OutlineOutline
SIP state of affairs SIP extensions and mechanism Common interoperability problems
intentional vs. unintentional How to encourage interoperability
SIP is PBX/Centrex readySIP 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
A constellation of SIP RFCsA constellation of SIP RFCs
Resource mgt. (3312)Reliable prov. (3262)INFO (2976)UPDATE (3311)Reason (3326)SIP (3261)
DNS for SIP (3263)Events (3265)REFER (3515)
DHCP (3361)DHCPv6 (3319)
Digest AKA (3310)Privacy (3323)P-Asserted (3325)Agreement (3329)Media auth. (3313)AES (3853)
Non-adjacent (3327)Symmetric resp. (3581)Service route (3608)User agent caps (3840)Caller prefs (3841)
ISUP (3204)sipfrag (3240)
Security & privacy
Configuration
Core
Mostly PSTN
Content types
Request routing
SIP, SIPPING & SIMPLE –00 draftsSIP, 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
When are we going to get When are we going to get there?there? In 2003, 6 SIP + 2 SIPPING RFCs published In 2002, 14 SIP + 4 SIPPING RFCs Currently, 24 SIP + 25 SIPPING + 18
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: designed for managed SIP: designed for managed extensionsextensions Engineered for managed long-term extensibility:
cannot assume that all implementations implement everything describe what to do with unknown protocol elements registry of header fields indication and discovery of features
New SIP header fields: ignored if unknown
provide more information, don’t change behavior avoid silly x- headers private, limited-users headers (branded with “P-”) most common extension today
New SIP methods rarely done outside standards discovery via OPTIONS request
SIP behavior changes via Require, Proxy-Require, Supported, Unsupported header fields
names behaviors, not fields
How to ensure protocol How to ensure protocol interoperabilityinteroperability 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
Interoperability effortsInteroperability 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
SIPit 14 (Feb. 2004)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.”
Protocol interoperability Protocol interoperability problemsproblems 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 didn’t expect this error”
mutually incompatible extensions expect extension to make something work
Protocol interoperabilityProtocol interoperability Proprietary protocol
Example: Skype Can only reverse-engineer only backwards-compatibility
problems incentive to force upgrades (see Microsoft Word)
quicker evolution, but limited product selection less Metcalfe’s law value
Open standard, but dominant vendor Example: H.323 doesn’t matter what the standard says NetMeeting and H.323 test with Microsoft implementation limits feature evolution to dominant vendor speed
Open standard, multiple large and many small vendors Example: SIP hardware vs. software, UA vs. proxy, phones vs. gateways interoperability problems until product maturity harder to test internally against all (competing) products better long-term outcome, but slower
Why SIP extensions?Why SIP extensions? Good interoperability in basic call setup Extensions are sometimes indications
where work is needed or “I didn’t know this existed”
unfortunately, no good SIP Roadmap document some “wrong protocol, buddy” some “I don’t have the resources to
participate in standardization” currently, 68 SIP/SIPPING/SIMPLE I-Ds 26 SIP RFCs (+ 13 SIPPING RFCs)
SIP proprietary extensionsSIP 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
SIP proprietary extensions, SIP proprietary extensions, cont’dcont’d “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
SIP – a bi-cultural protocolSIP – 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
The SIP complexity fallacyThe 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
Operational complexityOperational 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
VoIP end system VoIP end system configurationconfiguration
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
NAT and VPN troublesNAT 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
NAT solutionsNAT 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