SIP MusingsSIP Musings

Henning Schulzrinne SIP Summit – Las Vegas

May 8, 2002

OutlineOutline

Where is SIP in 2002? challenges:

multimedia conferencing binding SIP to other protocols privacy and identity emergency services

SIP tenets challenged by the real ($) world

Where in the world is SIP?Where in the world is SIP? SIP as the signaling protocol for future

applications 3GPP Cable modems (DOCSIS DCS) IM: AOL interworking (eventually...),

Windows Messenger but: H.323 dominates videoconferencing,

trunk replacement Proprietary protocols dominate for Ethernet

phones Slow uptake of VoIP

How did we get there?How did we get there? Not quite what we had in mind

initially, for initiating multicast conferencing in progress since 1992 still small niche even the IAB and IESG meet by POTS

conference… then VoIP

written-off equipment (circuit-switched) vs. new equipment (VoIP)

bandwidth is (mostly) not the problem “can’t get new services if other end is POTS’’

“why use VoIP if I can’t get new services”

How did we get here?How did we get here?

VoIP: avoiding the installed base issue cable modems – lifeline service 3GPP – vaporware?

Finally, IM/presence and events probably, first major application offers real advantage: interoperable

IM also, new service

SIP developments in SIP developments in 2001/022001/02 SIP revision (“RFC2543bis”, RFC3261) almost

done: semantically-oriented rewrite

layers: message, transport, transaction, transaction user SDP extracted into separate draft UA and proxy have the same state machinery

better Route/Record-Route spec for loose routing no more Basic authentication few optional headers (In-Reply-To, Call-Info, Alert-

Info, …) Integration of reliable provisional responses and

server features DNS SRV modifications

SIP developments in SIP developments in 2001/022001/02 SIP revision backwards compatible

“new” messages work with RFC 2543 implementations

some odd allowed RFC 2543 behavior no longer allowed

CPL finished – merger with iCal sip-cgi published IM & presence mostly done, except for

IM sessions (over TCP) separate message stream

SIP developments in SIP developments in 2001/022001/02 Work continues on staples:

early media (announcements) resource reservation (COMET) SIP security SIP events User identification: "network asserted identity",

privacy Call transfer and call control

Now three SIP working groups: SIP for protocol definition and extensions SIPPING for applications and “vetting” SIMPLE for IM & presence

ConferencingConferencing SIP designed for (multicast) multimedia

conferences most conferences are small (~5)

central-server ("star") conferences may be star of stars single-source multicast (SSM)

need supporting infrastructure: conference management user management floor management user management

ConferencingConferencing Conference management

create, delete properties (visibility, duration, ...)

User management mass invitation automated and manual user admission join and leave notification membership lists

Floor control request and release floor re-order queue

Binding SIP to other Binding SIP to other protocolsprotocols SIP not a universal data transport

protocol connect SIP to other protocols via URLs get more data

Call-Info, Error-Info, Alert-Info NOTIFY: pointer to message content obtain configuration information signed (long) version of SDP

publish data presence document buddy lists CPL, sip-cgi, servlet conference (user, floor) management

Binding SIP to other Binding SIP to other protocolsprotocols

Sometimes needed for address-of-record REGISTER addresses AOR

sometimes for particular UA only OPTIONS addresses endpoint(s)

clients need to obtain URIs & set them service mobility

Identity and privacyIdentity and privacy Conflicting goals:

caller may want privacy callee wants real identity SIP as telemarketer's

dream? FBI wants CALEA

Traditional "caller-ID" doesn't work well in SIP: user, not device identity iffy notion of trusted providers SIP direct no need for carrier

Proposal in SIP* WG: asserted identity without authentication signed identity based on first-hop authentication

Emergency servicesEmergency services Two types of emergency services:

emergency calls ("911", "112") emergency notification ("inverse 911")

emergency calls are hard: PSTN gateway dialing 911 may be

located anywhere, far away from IP phone

VPNs IP address may not reveal network location

Emergency servicesEmergency services Work for both "legacy" PSAPs and IP-

based PSAPs1. find location of phone based on

street address geocoding long/lat longitude, latitude

2. find appropriate PSAP for jurisdiction3. find ESR (routing number) call

appears like 911 call convey location

911 deployment911 deployment

SIP registration

Leonia

Fort Lee

"sos"

"911"

Bergen County

ISDN B

SIP call setup

audio (IP or circuit)

ISDN DSS7 ISUP

c1.leonia.us

c2.leonia.us

c1.fortlee.us

SIP

IP

UDP, TCP

IP

0

0

0

10

1

IP

Leonia, NJ400 Broad Avenue

"Bergen County"

Bob

IP phone

Alice

analog phone

C@B@A@

UDP

RTP

IP

Emergency notificationEmergency notification notify public officials and citizens of

emergencies: "tornado coming" "fugitive alert"

current systems are typically single-mode (fax, telex, phone, TV, loudspeaker)

don't scale well very limited information content don't reach citizens outside calling area

people at work hard to authenticate

SIP-based emergency SIP-based emergency notificationnotification SIP has scalable event notification feature use for hierarchical notification reflecting civil

lines of authority use XML/WSDL message bodies to

semantically describe emergency: location type of emergency instructions ...

allow automated reaction: routing to legacy systems (pagers, police radios) translation

Emergency notificationEmergency notification

Bergen

Wisconsin WyomingAlaska

Atlantic

Alabama New Jersey

NJState Govt.

United StatesFederal Govt.

NOTIFY

SUBSCRIBE

Domesticating SIP Domesticating SIP Temptation to make it look like SIP on the

wire, but lacks core SIP design properties SIP is designed as a common carrier

protocol: content-neutral application-neutral plausible deniability in proxies

proxy as minimally aware entities: pass unknown SIP headers handle any method don't touch bodies

SIP design principlesSIP design principles

SIP design: extensibility in all elements

methods, headers, content types disclosure of message handling to

user Via user influence over message handling

Require, caller preferences

SIP: mind-changingSIP: mind-changing

"network" services end-system services proxies as willing helpers, not service

disablers trusted network or network

federations PKI, distributed trust, "tunneled" trust

media-neutrality

3G: Falling into the WAP 3G: Falling into the WAP trap?trap? "3G adopts SIP" "3G adapts SIP" if just another IP transport, should not

need to explicitly do anything wireless-specific: bandwidth scarcity

compression overspecified no need for C/S/P-CSCF as

standard just one of many possible architectures

allow roofed + walled garden with customed characters and "forever wild" national park

The fallacy of topology The fallacy of topology hidinghiding "don't reveal server structure" infinite ways to leak to a determined

"spy" proxies don't reveal IP-layer connectivity

or bandwidths knowing proxy addresses doesn't reveal

proxy capacity security through obscurity? costs of hiding:

lack of diagnosability of faults extensibility decreases

SIP doesn’t have to be in a SIP doesn’t have to be in a phonephone

sip:lava@cs.columbia.edu

ConclusionConclusion Goal of single world-wide, transport-

independent session setup protocol within reach

Danger of non-interoperable islands repeat of mobile signaling division ISDN

Need to address operational issues not signaling load, administrator load emergency calls trust & privacy