5aca9caa110c475748071bf7146b30b8.ppt
- Количество слайдов: 22
SIP interoperability and extensions Henning Schulzrinne Dept. of Computer Science Columbia University, New York NGN (Boston, MA) November 2004
Outline n n n SIP state of affairs SIP extensions and mechanism Common interoperability problems n n intentional vs. unintentional How to encourage interoperability
SIP is PBX/Centrex ready boss/admin features RFC 3261 simultaneous ringing hold centrex-style features call waiting/multiple RFC 3261 calls RFC 3264 basic shared lines dialog/reg. package transfer RFC 3515/Replaces barge-in Join conference RFC 3261/callee caps “Take” Replaces message waiting message summary package Shared-line “privacy” dialog package call forward RFC 3261 divert to admin RFC 3261 call park RFC 3515/Replaces intercom URI convention call pickup Replaces auto attendant RFC 3261/2833 do not disturb RFC 3261 attendant console dialog package call coverage RFC 3261 night service RFC 3261 attendant features from Rohan Mahy’s VON Fall 2003 talk
A 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) SIP (3261) DNS for SIP (3263) Events (3265) REFER (3515) ISUP (3204) sipfrag (3240) Content types Reliable prov. (3262) INFO (2976) UPDATE (3311) Reason (3326) Mostly PSTN Core Digest AKA (3310) Privacy (3323) P-Asserted (3325) Agreement (3329) Media auth. (3313) AES (3853) DHCP (3361) DHCPv 6 (3319) Configuration Security & privacy
SIP, SIPPING & SIMPLE – 00 drafts includes draft-ietf-*-00 and draft-personal-*-00
When are we going to get there? n n n 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 n n does not count individual drafts likely to be “promoted” to WG status The. com consultant linear extrapolation technique® n n pessimist 8. 5 more years if no new work is added to the queue optimist 4 more years
SIP: designed for managed extensions n Engineered for managed long-term extensibility: n n n 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: n ignored if unknown n n avoid silly x- headers private, limited-users headers (branded with “P-”) most common extension today New SIP methods n n n provide more information, don’t change behavior rarely done outside standards discovery via OPTIONS request SIP behavior changes via Require, Proxy-Require, Supported, Unsupported header fields n names behaviors, not fields
How to ensure protocol interoperability n n Classical Internet approach: pairwise lab testing Interoperability tests (“plug fests”) n n n Certification by neutral third parties n n n multiple implementation, in various stages of maturity results (and embarrassment) remain private can never be complete Lab tests by consulting and publishing companies SIP is using all of these
Interoperability efforts n IETF SIPPING working group n n SIPit and SIMPLEt n n n held every 6 months 15 th instance just completed ETSI n n call flow examples for basic (RFC 3665), telephony (RFC 3666) and services (draft) TTCN specs SIP Forum Certification Working Group
SIPit 14 (Feb. 2004) n 128 attendees from 55 organizations n n 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 problems n Three core interoperability problems: n syntactic robustness n “You mean you could have a space there? ” n n n 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 n n often occurs when testing only against common reference implementations need “stress test” (also for buffer overflows) “I didn’t expect this error” mutually incompatible extensions n expect extension to make something work
Protocol interoperability n Proprietary protocol n n Example: Skype Can only reverse-engineer only backwards-compatibility problems n n quicker evolution, but limited product selection less Metcalfe’s law value Open standard, but dominant vendor n n n incentive to force upgrades (see Microsoft Word) Example: H. 323 doesn’t matter what the standard says Net. Meeting and H. 323 test with Microsoft implementation limits feature evolution to dominant vendor speed Open standard, multiple large and many small vendors n n n 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? n n Good interoperability in basic call setup Extensions are sometimes indications where work is needed n or “I didn’t know this existed” n n n 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 extensions n n Examples based on informal email survey Shared line support to emulate key systems: n n n TCAP over SIP n not dialogs, but state of AORs see SIMPLE for LNP general: pick up information along the way Auto-answer support (intercom) n Caller-indicated ringing preferences n n Billing and dialing plan Tone for charged vs. free calls Caller name identification added by proxies n n visual ringing P-Asserted-Identity extension Call routing diagnostics
SIP proprietary extensions, cont’d n n n “upgrade your endpoint!” Caller time zone NAT support n STUN servers not widely available – no incentive n n 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: n n local interest only takes too long to standardize
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
The SIP complexity fallacy n n IAX (for example) is simpler than SIP but you could build the IAX functionality in SIP at just about the same complexity: n n 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 IAX model Signaling & Media Signaling Media SIP, H. 323, MCGP model
Operational complexity n SIP design user only need to know their SIP address (AOR) and a registration secret n n familiar to users from web login Not: n n n n outbound proxy STUN server registrar address backup server addresses Digest authentication user name media port range tftp and HTTP server for image updates … n n Configuration failures hard to diagnose Bad “out of the box” experience Made worse by limited UI of end systems Misleading or inconsistent terminology n n n “communication server” “user name” Can’t have a manually configured configuration server
Vo. IP end system configuration AOR DNS SIP SUBSCRIBE/NOTIFY MAC address DHCP registrar address STUN/TURN – local and global general configuration document (media, UI, protocol behavior, …) geographical location (for 911) outbound proxy that’s all it should take
NAT and VPN troubles n Unplanned transition from Internet = one global address space to clouds (“realms”) of unknown scope n n n ? Can’t know without help whether directly reachable Any number of concentric spaces There is no universally workable NAT solution n Internet 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
NAT solutions avoid “evil” NATs well-defined NAT behavior allow informed deployment decisions find STUN and TURN servers easily NAT boxes with built-in address discovery and allocation IPv 6
Conclusion n n SIP is a mature protocol Almost all of the core features necessary for common services are RFCs or well-baked Internet drafts Interoperability more difficult in a multivendor environment On-going efforts in multiple forums to improve interoperability
5aca9caa110c475748071bf7146b30b8.ppt