SIPinteroperabilityandextensions

SIP interoperability and extensionsHenning SchulzrinneDept.of Computer ScienceColumbia University,New YorkNGN(Boston,MA)November 20041OutlinenSIP state of affairsnSIP extensions and mechanismnCommon interoperability problemsnintentional vs.unintentionalnHow to encourage interoperability2SIP is PBX/Centrex readycall waiting/multiple callsRFC 3261holdRFC 3264transferRFC 3515/ReplacesconferenceRFC 3261/callee capsmessage waitingmessage summary packagecall forwardRFC 3261call parkRFC 3515/Replacescall pickupReplacesdo not disturbRFC 3261call coverageRFC 3261from Rohan Mahys VON Fall 2003 talksimultaneous ringingRFC 3261basic shared linesdialog/reg.packagebarge-inJoin“Take”ReplacesShared-line“privacy”dialog packagedivert to adminRFC 3261intercom URI conventionauto attendantRFC 3261/2833attendant consoledialog packagenight serviceRFC 3261centrex-style featuresboss/admin featuresattendant features3A constellation of SIP RFCsResource 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&privacyConfigurationCoreMostly PSTNContent typesRequest routing4SIP,SIPPING&SIMPLE 00 draftsincludes draft-ietf-*-00 and draft-personal-*-005When are we going to get there?nIn 2003,6 SIP+2 SIPPING RFCs publishednIn 2002,14 SIP+4 SIPPING RFCsnCurrently,24 SIP+25 SIPPING+18 SIMPLE WG Internet Draftsndoes not count individual drafts likely to be“promoted”to WG statusnT consultant linear extrapolation techniquenpessimist 8.5 more years if no new work is added to the queuenoptimist 4 more years6SIP:designed for managed extensionsnEngineered for managed long-term extensibility:ncannot assume that all implementations implement everythingndescribe what to do with unknown protocol elementsnregistry of header fieldsnindication and discovery of featuresnNew SIP header fields:nignored if unknownnprovide more information,dont change behaviornavoid silly x-headersnprivate,limited-users headers(branded with“P-”)nmost common extension todaynNew SIP methodsnrarely done outside standardsndiscovery via OPTIONS requestnSIP behavior changes via Require,Proxy-Require,Supported,Unsupported header fieldsnnames behaviors,not fields7How to ensure protocol interoperabilitynClassical Internet approach:pairwise lab testingnInteroperability tests(“plug fests”)nmultiple implementation,in various stages of maturitynresults(and embarrassment)remain privatenCertification by neutral third partiesncan never be completenLab tests by consulting and publishing companiesn SIP is using all of these8Interoperability effortsnIETF SIPPING working groupncall flow examples for basic(RFC 3665),telephony(RFC 3666)and services(draft)nSIPit and SIMPLEtnheld every 6 monthsn15th instance just completednETSInTTCN specsnSIP Forum Certification Working Group9SIPit 14(Feb.2004)n128 attendees from 55 organizationsnUS,Canada,Israel,Japan,Taiwan,France,Germany,Belgium,UK,Turkey,India,Sweden,Finland,Norwayn“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.”10Protocol interoperability problemsnThree core interoperability problems:nsyntactic robustnessn“You mean you could have a space there?”noften occurs when testing only against common reference implementationsnneed“stress test”(also for buffer overflows)nimplementation by protocol examplenlimiting assumptions(e.g.,user name format)nsee“SIP Robustness Testing for Large-Scale Use”,First International Workshop on Software Quality(SOQA)nsemantic assumptionsn“I didnt expect this error”nmutually incompatible extensionsnexpect extension to make something work11Protocol interoperabilitynProprietary protocolnExample:SkypenCan only reverse-engineer only backwards-compatibility problemsnincentive to force upgrades(see Microsoft Word)nquicker evolution,but limited product selectionnless Metcalfes law valuenOpen standard,but dominant vendornExample:H.323ndoesnt matter what the standard saysnNetMeeting and H.323 test with Microsoft implementationnlimits feature evolution to dominant vendor speednOpen standard,multiple large and many small vendorsnExample:SIPnhardware vs.software,UA vs.proxy,phones vs.gatewaysninteroperability problems until product maturitynharder to test internally against all(competing)productsnbetter long-term outcome,but slower12Why SIP extensions?nGood interoperability in basic call setupnExtensions are sometimes indications where work is needednor“I didnt know this existed”nunfortunately,no good SIP Roadmap documentnsome“wrong protocol,buddy”nsome“I dont have the resources to participate in standardization”ncurrently,68 SIP/SIPPING/SIMPLE I-Dsn26 SIP RFCs(+13 SIPPING RFCs)13SIP proprietary extensionsnExamples based on informal email surveynShared line support to emulate key systems:nnot dialogs,but state of AORsnsee SIMPLEnTCAP over SIPnfor LNPngeneral:pick up information along the waynAuto-answer support(intercom)nCaller-indicated ringing preferencesnvisual ringingnBilling and dialing plannTone for charged vs.free callsnCaller name identification added by proxiesnP-Asserted-Identity extensionnCall routing diagnostics14SIP proprietary extensions,contdn“upgrade your endpoint!”nCaller time zonenNAT supportnSTUN servers not widely available no incentivensome use simple HTTP query(just needs cgi-bin)nprobably biggest advantage that Skype hasn many,make SIP work well in old world on phone look-alikesnreason given:nlocal interest onlyntakes too long to standardize15SIP 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 16The SIP complexity fallacynIAX(for example)is simpler than SIPnbut you could build the IAX functionality in SIP at just about the same complexity:nno proxiesnno codec negotiationnno distributed servicesnDifficulty:extracting those simple pieces from 269 pages of specification nSIP still more complex due to signaling-data separationSignaling&MediaSignaling&MediaSignalingSignalingMediaIAX modelSIP,H.323,MCGP model17Operational complexitynSIP design user only need to know their SIP address(AOR)and a registration secretnfamiliar to users from web loginnNot:noutbound proxynSTUN servernregistrar addressnbackup server addressesnDigest authentication user namenmedia port rangent HTTP server for image updatesnnConfiguration failures hard to diagnosenBad“out of the box”experiencenMade worse by limited UI of end systemsnMisleading or inconsistent terminologyn“communication server”n“user name”nCant have a manually configured configuration server18VoIP end system configurationAORMACaddressregistrar addressSTUN/TURN local and globalgeneral configuration document(media,UI,protocol behavior,)geographical location(for 911)outbound proxyDNSSIP SUBSCRIBE/NOTIFYDHCPthats all it should take19NAT and VPN troublesnUnplanned transition from Internet=one global address space to clouds(“realms”)of unknown scopenCant know without help whether directly reachablenAny number of concentric spacesnThere is no universally workable NAT solutionnalways problems with inbound callsnmay need to maintain and refresh permanent connections to globally routable entitynmay need relay agent for media(TURN)?home NATISP NATInternet20NAT solutionswell-defined NAT behavior allow informed deployment decisionsavoid“evil”NATsNAT boxes with built-in address discovery and allocationfind STUN and TURN servers easilyIPv621ConclusionnSIP is a mature protocolnAlmost all of the core features necessary for common services are RFCs or well-baked Internet draftsnInteroperability more difficult in a multi-vendor environmentnOn-going efforts in multiple forums to improve interoperability22