SIP interoperability and extensions

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 Mahys 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
Core
Content types
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, dont 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 didnt 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 Metcalfes law value
• Open standard, but dominant vendor
• Example H.323
• doesnt 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 didnt know this existed
• unfortunately, no good SIP Roadmap document
• some wrong protocol, buddy
• some I dont 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, contd

• 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
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
• Cant have a manually configured configuration
  server

19
VoIP end system configuration
registrar address STUN/TURN local and global
DNS
AOR
SIP SUBSCRIBE/NOTIFY
general configuration document (media, UI,
protocol behavior, )
DHCP
MAC address
geographical location (for 911) outbound proxy
thats all it should take
20
NAT and VPN troubles

• Unplanned transition from Internet one global
  address space to clouds (realms) of unknown
  scope
• Cant 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