SIP-Summit-2004.ppt

SIP Summit (Chicago, June 22, 2004) 1

SIP in 2004 – The Challenge of Being a Successful Protocol

Henning Schulzrinne

Columbia University


Outline

Successes: hardware 3GPP residential VOIP sip.edu PTT

Standardization 80/20 rule

Challenges ahead: A cross-cultural protocol Perception and reality of

complexity NAT and firewall issues Large-scale mixed-vendor

deployment Inter-domain deployment SIP spam

Opportunities Improving the user

experience beyond PSTN


(Early) Adulthood

“fully developed and mature” Not quite yet, but no

longer a teenager probably need another

6 years to be grown up…

Responsibilities: Dealing with elderly

relatives POTS Financial issues

payments, RADIUS Family emergencies

911


SIP products beyond $600 office phones

Finally, basic IP phones below $100

802.11 phones video conferencing speakerphones $65


SIP deployments – landline

Consumer broadband: Vonage (165,000 lines), Packet8, … buckets of minutes or unlimited

long-distance SIP invisible, but it just works

Time-Warner: “Time Warner Cable, the second-largest US cable group, will [in 2004] roll out a national internet-based telephone service.”

AT&T: “The long-distance giant plans to offer VoIP-enabled services to 1 million consumers in the next two years, beginning with a roll-out in major cities across the U.S. in the first quarter of 2004.”

Verizon MCI Advantage (for business) Focused on hosted SIP services, rather than just SIP termination Few midsize-to-large companies still considering traditional circuit-

switched PBX for replacement


SIP deployments – wireless

Usage for controlling new push-to-talk services not user-visible, but may emerge from hiding first step to presence-enabled voice services

Sprint PCS Readylink service “first commercial deployment of SIP by a wireless

carrier”

3G (R5) services much slower in coming


Deployment example: SIP.edu

Deploy SIP and VoIP across Internet2 educational institutions

Transition E.164 SIP URIs But don’t wait for VoIP end system deployment

“+1-617-637-8562, come here. I need you!”

(from slides by Ben Teitelbaum)

A. G. Bell did not say:


SIPProxy

DNSSIP-PBXGateway

PBX

INVITE (sip:[email protected])

INVITE(sip:[email protected])

DNS SRV query sip.udp.bigu.edu

telephoneNumberwhere mail=”bob”

PRI / CASbigu.edu

CampusDirectory

SIP User Agent

Bob's Phone

SIP.edu Architecture (Phase 1)

© Ben Teitelbaum, with permission


DNS

INVITE (sip:[email protected])DNS SRV query

sip.udp.bigu.edu

bigu.edu

SIP User Agent

SIP.edu Architecture (Phase 2)

locationDB

If Bob has registered, ring his SIP phone; Else, call his extension through the PBX.

REGISTER(Contact: 207.75.164.131)

INVITE (sip:[email protected])

SIPProxy

SIPRegistrar

Bob's SIP Phone

© Ben Teitelbaum, with permission


SIP.edu growth

http://voip.internet2.edu/SIP.edu/

e.g., sip:[email protected] +1 212 939 7042


Overview

SIP in 2003 Standardization – a long, hard

slog Filling in the product palette

finally, cheap phones VoIP (and SIP) over WiFi

(802.11) Real deployments

commercial (wireless, consumer, enterprise)

Embedded (push-to-talk) Internet2

SIP as a brand: SIPphone, SIPura, SIPtele, SIPquest, SIPCPE, …

SIP in 2004 Large-scale consumer

usage How much regulation

for VoIP? Emergency calling Standardized IM &

presence Better auto-

configuration


Major RFCs published recently Third-party call control (RFC 3275)

allows non-media entity to control sessions Event package for registrations (RFC 3680) Security mechanism agreement (RFC 3329)

negotiate algorithms with next hop Requirements for resource priority (RFC 3487)

prioritization of calls in military networks and emergencies REFER method (RFC 3515)

call transfer DHCPv6 for SIP (RFC 3319)

automatic outbound proxy configuration Proxy-to-proxy extensions for PacketCable (RFC 3603) Symmetric response routing (RFC 3581)

improved NAT interaction


Major RFCs published

Service route discovery (RFC 3806) REGISTER returns “preloaded route” to be used by UA for services

SIP and SDP compression (RFC 3485/3486) compress SIP headers and body via dynamic dictionary

Call flows (RFC 3665/3666) explain behavior by example useful for testing common cases not a spec replacement

Summary: except for REFER, mostly relevant to subsets of SIP developer community PacketCable 3G Military, emergency response


RFCs in the pipeline

Ready & done, but typically waiting for normative references

Examples: message waiting indication caller preferences CPL user agent capabilities ENUM for SIP H.323 interworking requirements presence – events, CPIM, watcher info, …


When are we going to get there?

In 2003, 6 SIP + 2 SIPPING RFCs published In 2002, 14 SIP + 4 SIPPING RFCs Currently, 20 SIP + 24 SIPPING + 22 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


SIP is PBX/Centrex readycall 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

from Rohan Mahy’s VON Fall 2003 talk

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

centr

ex-s

tyle

featu

res

boss/admin features

attendant features


SIP, SIPPING & SIMPLE –00 drafts

0

10

20

30

40

50

60

70

1999 2000 2001 2002 2003

SIPSIPPINGSIMPLE

includes draft-ietf-*-00 and draft-personal-*-00


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


SIP proprietary extensions Good interoperability in basic call setup Indications where work is needed

or “I didn’t know this existed” some “wrong protocol, buddy” currently, 68 SIP/SIPPING/SIMPLE I-Ds 22 SIP RFCs

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

Caller name identification added by proxies

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

make SIP work well in old world on phone look-alikes


Competition Old competition: H.323 no longer active

development but still in wide use (including CallManager)

New competition: IAX Skype Cisco SCCP (Skinny) ~ MGCP Jabber (IM)

Usually, dominated by single company faster (fewer “what is a tuple discussions”…) concentrated company resources usually

make-or-break for company H.323 = Microsoft NetMeeting compatible

tend to favor efficiency over generality and protocol niceties (internationalization, congestion control, XML, …)

had NAT story from very beginning Skype NAT solution appears to be technically

similar to STUN

Limited focus, e.g.,: silo model

audio only (IAX) for Jabber, classical IM/presence focused

no capability negotiation no proxy support limited security support limited services

call forwarding, transfer, early media, … Unpublished protocols

“trust us, we wouldn’t do anything stupid, would we?”

hard to get protocol eco system variety of end systems diagnostics and protocol analyzers


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


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

Signaling Signaling

Media

IAX model

SIP, H.323, MCGP model


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


VoIP end system configuration

AOR

MACaddress

registrar addressSTUN/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


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


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


SIP spam

Threats: unsolicited (multimedia) calls presence authorization

requests IMs (“spim”)

Could be worse than email and phone telemarketing: immediate interruption “the death of distance”

aluminum siding at 2 am, direct from China

do-not-call list and CAN-SPAM may not apply

Not a SIP problem – Applies to other systems as well

Spam mechanisms have limited applicability can’t do content analysis

(Bayesian filtering) even for IM attention

grabbed after first “Hello” message

human reachability measures interfere with real-time nature


SIP spam solutions – some options

Failure of content-based identity-based global, personal PKI tried and failed

economics, liability to scale, must be cheap and easy to get cheap

and easy for spammers, too hard to install on end systems

But domain-level authentication works TLS certificates orders of magnitude fewer servers than phones

Other server ID alternatives: DNS certificate server SPF SRV records for domain servers

Increase value of identity: social networks bonding and warranties identity policy (“we card”) verifiable location information

stranded relative from payphone vs. former rebel leader from Namibia

outbound proxyexample.com

From: [email protected]

shared secret(Digest) verify

example.com


Conclusion

SIP making the transition from lab to field push-to-talk residential VoIP some enterprise deployments

Bi-cultural complexity, delay Challenges operational, less protocol

configuration 911 spam

SIP-Summit-2004.ppt

Documents

sip rfc

services sip

internet2 sip

sip uris

invite sip

sip termination

overview sip

sip products