1 / 22

SIP interoperability and extensions

SIP interoperability and extensions. Henning Schulzrinne Dept. of Computer Science Columbia University, New York NGN (Boston, MA) November 2004. Outline. SIP state of affairs SIP extensions and mechanism Common interoperability problems intentional vs. unintentional

Faraday
Download Presentation

SIP interoperability and extensions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 boss/admin features centrex-style features attendant features from Rohan Mahy’s VON Fall 2003 talk

  4. 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) Reliable prov. (3262) INFO (2976) UPDATE (3311) Reason (3326) SIP (3261) DNS for SIP (3263) Events (3265) REFER (3515) ISUP (3204) sipfrag (3240) Mostly PSTN Content types Core Digest AKA (3310) Privacy (3323) P-Asserted (3325) Agreement (3329) Media auth. (3313) AES (3853) DHCP (3361) DHCPv6 (3319) Configuration Security & privacy

  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 • 15th 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. 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

  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 • multimedia • IM and presence • location-based service • user-created services • decentralized operation • everyone equally suspect • overlap dialing • DTMF carriage • key systems • notion of lines • per-minute billing • early media • ISUP & BICC interoperation • trusted service providers

  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 IAX model Signaling & Media Signaling & Media Signaling Signaling Media SIP, H.323, MCGP model

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

  19. VoIP end system configuration DNS registrar address STUN/TURN – local and global AOR SIP SUBSCRIBE/NOTIFY general configuration document (media, UI, protocol behavior, …) DHCP MAC address geographical location (for 911) outbound proxy 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) Internet ? home NAT ? ? ISP NAT

  21. NAT solutions avoid “evil” NATs find STUN and TURN servers easily IPv6 NAT boxes with built-in address discovery and allocation well-defined NAT behavior  allow informed deployment decisions

  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

More Related