SIP

1
SIP are we there yet?

• Henning Schulzrinne
• (with Kundan Singh)
• Columbia University
• Department of Computer Science
• hgs_at_cs.columbia.edu
• (SIP Summit 2005, Honolulu, Hawaii)

supported by
2
Overview

• SIP state of affairs closing in on done
• Common interoperability problems
• intentional vs. unintentional
• How to encourage interoperability
• The SIP configuration mess
• Peer-to-peer SIP

3
SIP is PBX/Centrex ready
boss/admin features
call waiting/multiple calls RFC 3261
hold RFC 3264
transfer RFC 3515/Replaces
conference RFC 3261/callee caps
message waiting message summary package
call forward RFC 3261
call park RFC 3515/Replaces
call pickup Replaces
do not disturb RFC 3261
call coverage RFC 3261
simultaneous ringing RFC 3261
basic shared lines dialog/reg. package
barge-in Join
Take Replaces
Shared-line privacy dialog package
divert to admin RFC 3261
intercom URI convention
auto attendant RFC 3261/2833
attendant console dialog package
night service RFC 3261
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
An eco system, not just a protocol
configures
XCAP (config)
SIMPLE policy RPID .
XCON (conferencing)
initiates
carries
SIP
RTSP
SDP
carries
controls
provide addresses
STUN TURN
RTP
6
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
7
RFC publication
8
When are we going to get there?

• Currently, 14 SIP 31 SIPPING 19 SIMPLE WG
  Internet Drafts 64 total
• does not count individual drafts likely to be
  promoted to WG status
• The .com consultant linear extrapolation
  technique
• pessimist ? 4 more years if no new work is added
  to the queue and we can keep up productivity
• optimist ? 3 more years (lots of drafts are in
  almost-done stage)

9
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

10
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

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 protocols

• Proprietary protocol
• Example Skype
• quicker evolution not dependent on IETF
  volunteers with day jobs
• can do hacks without IESG objection
• media over TCP
• inefficient search
• bypass routing policies
• circumvent firewall policies
• Can only reverse-engineer ? only
  backwards-compatibility problems
• incentive to force upgrades (see Microsoft Word)
• less Metcalfes law value

13
Why is Skype successful?

• All the advantages of a proprietary protocol
• Peer-to-peer coincidental
• Good out-of-box experience
• Software vendor service provider
• Didnt know that you couldnt do voice quality
  beyond PSTN
• others too focused on PSTN interoperability why
  do better voice than PSTN?
• Simpler solutions for NAT traversal
• use TCP if necessary
• use port 80
• Did encryption from the very beginning
• Kazaa marketing vehicle

14
Open standard, 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
  and interests

15
Open standard, multiple vendors

• Example SIP
• More than just one application
• Software UAs, proxies, phones, gateways, media
  servers, test tools, OAM,
• interoperability problems until product maturity
• harder to test internally against all (competing)
  products
• divergent views and communities in IETF and other
  SDOs
• likely have to support union of requirements
• emphasis on extensibility, modularity and
  protocol re-use
• ? temptation to not implement everything
• security
• SIP generality over efficiency
• better long-term outcome, but slower

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

17
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

18
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

19
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

20
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 ( SDP RTP) ?
• SIP still more complex due to signaling-data
  separation

IAX model
Signaling Media
Signaling Media
Signaling
Signaling
Media
SIP, H.323, MCGP model
21
Does it have to be that complicated?

• highly technical parameters, with differing names
• inconsistent conventions for user and realm
• made worse by limited end systems (configure by
  multi-tap)
• usually fails with some cryptic error message and
  no indication which parameter
• out-of-box experience not good

22
Solving the configuration mess

• Initial development assumed enterprise deployment
• pre-configured via tftp or (rarely) DHCP
• not suitable for residential use, except if box
  is shipped
• pathetic security password accessible to
  anybody who knows MAC address of phone
• Short term
• adopt simple default conventions
• should only need SIP URI (AoR), display name and
  password
• realm URI
• outbound proxy domain
• provide and expose error feedback
• not authentication failure
• but realm not recognized change to user_at_domain
  format
• use DNS NAPTR and SRV for STUN server

23
Solving the configuration mess longer term

• IETF efforts on configuration management
• retrieve via HTTP ( TLS)
• change notification via SIP event notification
• problem of configuring initial secret remains
• probably need embedded public keys
• Still need better diagnostics
• one-way voice issues
• authentication failures

24
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
25
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
26
NAT solutions
and then a miracle occurred
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
27
Server-based vs peer-to-peer

• Server-based
• Cost maintenance, configuration
• Central points of failures
• Managed SIP infrastructure
• Controlled infrastructure (e.g., DNS)
• Peer-to-peer
• Robust no central dependency
• Self organizing, no configuration
• Scalability ?

28
P2P-SIP

• Differences to proprietary Skype architecture
• Robust and efficient lookup using DHT
• Interoperability
• DHT algorithm uses SIP protocol messages
• Hybrid architecture
• First try DNS NAPTR/SRV
• if no SIP server there, then lookup in SIPP2P
• Unlike file-sharing applications
• Data storage, caching, delay, reliability
• Disadvantages
• Lookup delay and security

29
P2P-SIPBackground DHT (Chord)
Key node
81 9 14
82 10 14
84 12 14
88 16 21
81624 32
83240 42
1
54
8
58
10
14
47
21

• Identifier circle
• Keys assigned to successor
• Evenly distributed keys and nodes
• Finger table logN
• ith finger points to first node that succeeds n
  by at least 2i-1
• Stabilization for join/leave

42
38
32
38
24
30
30
P2P-SIPDesign Alternatives
servers
1
54
10
38
24
30
clients
Use DHT in server farm
Use DHT for all clients But some are resource
limited
Use DHT among super-nodes
31
P2P-SIPNode architecture registrar, proxy, user
agent
Signup, Find buddies
IM, call
On reset
Signout, transfer
On startup
Leave
Find
Join
REG, INVITE, MESSAGE
Multicast REG
Peer found/ Detect NAT
REG

• DHT communication using SIP REGISTER
• Known node sip15_at_192.2.1.3
• Unknown node sip17_at_sippeer.net
• User sipalice_at_example.com

32
P2P-SIPImplementation
31
29
31

• sippeer C, Linux, Chord
• Nodes join and form the DHT
• Node failure is detected and DHT updated
• Registrations transferred on node shutdown
• only need extension for avoiding outbound proxy
  confusion
• Co-located classical UA can use sippeer service
  with a P2P adaptor (built)

25
26
15
33
Conclusion

• SIP is now a mature protocol, with a surrounding
  eco system
• 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
• Out-of-box experience needs work
• Can do peer-to-peer SIP without significant
  protocol extensions complementary, does not
  replace existing model