1. SIP interoperability and extensions Henning Schulzrinne Dept. of Computer Science Columbia University, New York NGN (Boston, MA) November 2004

2. Outline SIP state of affairs SIP extensions and mechanism Common interoperability problems intentional vs. unintentional How to encourage interoperability

3. SIP is PBX/Centrex ready call waiting/multiple calls RFC 3261 holdRFC 3264 transferRFC 3515/Replaces conferenceRFC 3261/callee caps message waitingmessage summary package call forwardRFC 3261 call parkRFC 3515/Replaces call pickupReplaces do not disturbRFC 3261 call coverageRFC 3261 from Rohan Mahy’s VON Fall 2003 talk simultaneous ringing RFC 3261 basic shared linesdialog/reg. package barge-inJoin “Take”Replaces Shared-line “privacy” dialog package divert to adminRFC 3261 intercomURI convention auto attendantRFC 3261/2833 attendant consoledialog package night serviceRFC 3261 centrex-style features boss/admin features attendant features

4. A 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

5. SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

6. When are we going to get 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

7. SIP: designed for managed extensions 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

8. How 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

9. Interoperability 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 15 th instance just completed ETSI TTCN specs SIP Forum Certification Working Group

10. 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.”

11. Protocol 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 didn’t expect this error” mutually incompatible extensions expect extension to make something work

12. Protocol 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

13. 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)

14. SIP 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

15. SIP proprietary extensions, cont’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

16. 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

17. The 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 IAX model SIP, H.323, MCGP model

18. Operational 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

19. VoIP end system configuration AOR MAC address registrar address STUN/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

20. NAT 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

21. NAT 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

22. Conclusion 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 multi- vendor environment On-going efforts in multiple forums to improve interoperability