SIP interoperability and extensions Henning Schulzrinne Dept of

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