March 5, 2004

Henning Schulzrinne

Columbia University(Sprint Labs, Burlingame, CA)

Global UbiquitousComputing

2March 5, 2004

Agenda

SIP overview SIP for ubiquitous computing Location-based services Emergency calling Services, carriers and service creation Security issues

3March 5, 2004

SIP Overview

4March 5, 2004

Internet services – the missing entry

Service/delivery synchronous asynchronous

push instant messaging

presence

event notification

session setup

media-on-demand

messaging

pull data retrieval

file download

remote procedure call

peer-to-peer file sharing

5March 5, 2004

Filling in the protocol gapService/delivery synchronous asynchronous

push SIP

RTSP, RTP

SMTP

pull HTTP

ftp

SunRPC, Corba, SOAP

(not yet standardized)

6March 5, 2004

SIP as service enabler Rendezvous protocol

lets users find each other by only knowing a permanent identifier

Mobility enabler: personal mobility

one person, multiple terminals

terminal mobility one terminal, multiple IP

addresses session mobility

one user, multiple terminals in sequence or in parallel

service mobility services move with user

7March 5, 2004

What is SIP? Session Initiation Protocol protocol that establishes,

manages (multimedia) sessions also used for IM, presence & event notification uses SDP to describe multimedia sessions

Developed at Columbia U. (with others) Standardized by

IETF (RFC 3261-3265 et al) 3GPP (for 3G wireless) PacketCable

About 60 companies produce SIP products Microsoft’s Windows Messenger (≥4.7) includes SIP

8March 5, 2004

Philosophy Session establishment & event notification Any session type, from audio to circuit emulation Provides application-layer anycast service Provides terminal and session mobility Based on HTTP in syntax, but different in protocol operation Peer-to-peer system, with optional support by proxies

even stateful proxies only keep transaction state, not call (session, dialogue) state

transaction: single request + retransmissions proxies can be completely stateless

9March 5, 2004

Basic SIP message flow

10March 5, 2004

SIP trapezoid

SIP trapezoid

outbound proxy

a@foo.com: 128.59.16.1

registrar

1st request

2nd, 3rd, … request

voice trafficRTP

destination proxy(identified by SIP URI domain)

11March 5, 2004

SIP message format

SDP

INVITE sip:bob@there.com SIP/2.0

Via: SIP/2.0/UDP here.com:5060From: Alice <sip:alice@here.com>To: Bob <sip:bob@there.com>Call-ID: 1234@here.comCSeq: 1 INVITESubject: just testingContact: sip:alice@pc.here.comContent-Type: application/sdpContent-Length: 147

v=0o=alice 2890844526 2890844526 IN IP4 here.coms=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000

SIP/2.0 200 OK

Via: SIP/2.0/UDP here.com:5060From: Alice <sip:alice@here.com>To: Bob <sip:bob@there.com>Call-ID: 1234@here.comCSeq: 1 INVITESubject: just testingContact: sip:alice@pc.here.comContent-Type: application/sdpContent-Length: 134

v=0o=bob 2890844527 2890844527 IN IP4 there.coms=Session SDPc=IN IP4 110.111.112.113t=0 0m=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000m

essa

ge b

ody

head

er fi

elds

requ

est l

ine

request response

12March 5, 2004

RFC 3261 Backward compatible with RFC 2543 – no new version Major changes:

specification behavior-oriented, not header-oriented e.g., separation into ‘layers’

mandate support for UDP and TCP formal offer/answer model for media negotiation uses both SRV and NAPTR for server location, load balancing and

redundancy much more complete security considerations

“sips:’’ for secured (TLS) path PGP removed due to lack of use Basic authentication removed as unsafe S/MIME added for protecting message bodies (and headers, via

encapsulation) Route/Record-Route simplified

13March 5, 2004

PSTN vs. Internet Telephony

Signaling & Media Signaling & Media

Signaling Signaling

Media

PSTN:

Internettelephony:

China

Belgian customer,currently visiting US

Australia

14March 5, 2004

SIP addressing Users identified by SIP or tel URIs

sip:alice@example.com tel: URIs describe E.164 number, not dialed digits

(RFC 2806bis) tel URIs SIP URIs by outbound proxy A person can have any number of SIP URIs The same SIP URI can reach many different

phones, in different networks sequential & parallel forking

SIP URIs can be created dynamically: GRUUs conferences device identifiers (sip:foo@128.59.16.15)

Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR)

tel:110 sip:sos@domain

domain 128.59.16.17via NAPTR + SRV

15March 5, 2004

3G Architecture (Registration)

visited IM domain

home IM domain

servingCSCF

interrogating

proxy

interrogating

mobility managementsignaling

registration signaling (SIP)_

16March 5, 2004

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

17March 5, 2004

Example SIP phones

about $85

18March 5, 2004

SIP architecture biases International no national

variants Internet = intranet separation of data and

signaling signaling nodes can be

anywhere end-to-end security where

possible, hop-by-hop otherwise S/MIME bodies TLS (sips:)

end system control of information

proxies can inspect, modify and add

headers may be able to inspect the

message body (if not encrypted)

should not modify the message body may break end-to-end integrity

no security by obscurity don’t rely on address or

network hiding

19March 5, 2004

SIP, SIPPING & SIMPLE –00 drafts

0

10

20

30

40

50

60

70

1999 2000 2001 2002 2003

SIPSIPPINGSIMPLE

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

20March 5, 2004

Ubiquitous computing Location-based services Emergency calling

21March 5, 2004

What is ubiquitous computing? “Ubiquitous computing has as its goal the enhancing computer use by

making many computers available throughout the physical environment, but making them effectively invisible to the user.” (Weiser, 1993)

“Ubiquitous computing is not virtual reality, it is not a Personal Digital Assistant (PDA) such as Apple's Newton, it is not a personal or intimate computer with agents doing your bidding. Unlike virtual reality, ubiquitous computing endeavers to integrate information displays into the everyday physical world. It considers the nuances of the real world to be wonderful, and aims only to augment them.” (Weiser, 1993)

22March 5, 2004

Ubiquitous computing aspects Also related to pervasive computing Mobility, but not just cell phones Computation and communications Integration of devices

“borrow” capabilities found in the environment composition into logical devices

seamless mobility session mobility adaptation to local capabilities environment senses instead of explicit user interaction from small dumb devices to PCs

light switches and smart wallpaper

23March 5, 2004

Context-aware communications Traditional emphasis: communicate anywhere, anytime, any media largely

possible today New challenge: tailor reachability Context-aware communications

modify when, how, where to be reached machine: context-dependent call routing human: convey as part of call for human usage

context-aware services leveraging local resources awareness of other users

sources of location information voluntary and automatic

location-based services privacy concerns applies to other personal information activity, reachability, capabilities, bio sensor data, …

emergency services as a location-based service

24March 5, 2004

Context

context = “the interrelated conditions in which something exists or occurs”

anything known about the participants in the (potential) communication relationship

both at caller and callee

time CPL

capabilities caller preferences

location location-based call routing

location events

activity/availability presence

sensor data (mood, bio) not yet, but similar in many aspects to location data

25March 5, 2004

“Legacy” IM & presence systems SIP-based systems centralized systems (single name space)

federated systems, similar to email mostly instant text messages

media-agnostic – transmit any media object separate from session-based services (VoIP, video

conferencing)integrated:

use IM as part of media sessionsuse presence to facilitate session setup

limited presence status, mostly manually setrich presence, with time informationimported from sensors, calendars, backend systems, …

proprietary systems (AOL, Yahoo!, MSN, ICQ, …)standards-based systems

26March 5, 2004

Presence and event notification Presence = special case of

event notification “user Alice is available for

communication” Human users:

multiple contacts per presentity device (cell, PDA, phone, …) service (“audio”)

activities, current and planned surroundings (noise, privacy,

vehicle, …) contact information composing (typing, recording

audio/video IM, …)

Multimedia systems: REFER (call transfer) message waiting indication conference floor control conference membership push-to-talk system configuration

General events: emergency alert (“reverse

911”) industrial sensors (“boiler

pressure too high”) business events (“more than

20 people waiting for service”)

27March 5, 2004

IETF efforts SIP, SIPPING and SIMPLE working groups

but also XCON (conferencing) Define SIP methods PUBLISH, SUBSCRIBE, NOTIFY GEOPRIV:

geospatial privacy location determination via DHCP information delivery via SIP, HTTP, … privacy policies

SIMPLE: architecture for events and presence configuration (XCAP) session-oriented IM (↔ page mode) filtering, rate limiting and authorization

28March 5, 2004

RPID: rich presence

Provide watchers with better information about the what, where, how of presentities

facilitate appropriate communications: “wait until end of meeting” “use text messaging instead of phone call” “make quick call before flight takes off”

designed to be derivable from calendar information or provided by sensors in the environment

allow filtering by “sphere” – the parts of our life don’t show recreation details to colleagues

29March 5, 2004

RPID: rich presence

Classification: contact-type

device, in-person, service, presentity

class for labeling

sphere “work”, “home”, …

relationship “family”, “associate”,

“assistant”, “supervisor”

Activities: activity

“on-the-phone”, “away”, “appointment”, …

idle last usage of device

Surroundings: placetype

“home”, “office”, “industrial”, …

privacy “public”, “private”

30March 5, 2004

CIPID: Contact Information

More long-term identification of contacts Elements:

card – contact Information home page icon – to represent user map – pointer to map for user sound – presentity is available

31March 5, 2004

Timed Status Presence is about here & now but often only have (recent)

past – e.g., calendar or future

“will be traveling in two hours” “will be back shortly”

allows watcher to plan communication

loose synchronization of calendars

<tuple id="7c8dqui">

<contact> sip:bob@example.com</contact><status> <basic>open</basic></status>

<fs:timed-statusfrom="2003-08-15T10:20:00.000-

05:00“until="2003-08-22T19:30:00.000-

05:00"><basic>closed</basic></fs:timed-status></tuple><note>I'll be in Tokyo next

week</note>

32March 5, 2004

GEOPRIV and SIMPLE architectures

targetlocationserver

locationrecipient

rulemaker

presentity

caller

presenceagent

watcher

callee

GEOPRIV

SIPpresence

SIPcall

PUBLISHNOTIFY

SUBSCRIBE

INVITE

publicationinterface

notificationinterface

XCAP(rules)

INVITE

DHCP

33March 5, 2004

Location-based services Finding services based on location

physical services (stores, restaurants, ATMs, …) electronic services (media I/O, printer, display, …) not covered here

Using location to improve (network) services communication

incoming communications changes based on where I am configuration

devices in room adapt to their current users awareness

others are (selectively) made aware of my location security

proximity grants temporary access to local resources

34March 5, 2004

Location-based SIP services Location-aware inbound routing

do not forward call if time at callee location is [11 pm, 8 am] only forward time-for-lunch if destination is on campus do not ring phone if I’m in a theater

outbound call routing contact nearest emergency call center send delivery@pizza.com to nearest branch

location-based events subscribe to locations, not people Alice has entered the meeting room subscriber may be device in room our lab stereo changes

CDs for each person that enters the room

35March 5, 2004

DHCP for locations modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information

DHCPserver

458/17 Rm. 815458/18 Rm. 816

DHCP answer:sta=DC loc=Rm815lat=38.89868 long=77.03723

8:0:20:ab:d5:d

CDP + SNMP8:0:20:ab:d5:d 458/17

36March 5, 2004

SIP URIs for locations

Identify confined locations by a SIP URI, e.g., sip:rm815@cs.columbia.edu

Register all users or devices in room

Allows geographic anycast: reach any party in the room

a@foo.com: 128.59.16.1

Room 815

sip:rm815

location beacon

Contact: alice

Contact: bob

37March 5, 2004

Presence policy

subscriptionpolicy

event generatorpolicy

subscriberfilter

rate limiter

change to previousnotification?

for eachwatcher

subscriber (watcher)

SUBSCRIBE

NOTIFY

38March 5, 2004

Policy relationships

geopriv-specific presence-specific

common policy

RPID CIPID

future

39March 5, 2004

Privacy rules

Conditions identity, sphere, validity time of day current location identity as <uri> or

<domain> + <except> Actions

watcher confirmation Transformations

include information reduced accuracy

User gets maximum of permissions across all matching rules

Extendable to new presence data rich presence biological sensors mood sensors

40March 5, 2004

Example: user-adaptive device configuration

“all devices that are in the building”RFC 3082?

PA

devicecontroller

SUBSCRIBEto each room

SUBSCRIBE to configurationfor users currently in rooms

1. discover room URI2. REGISTER as contact for room URI

tftp

HTTP

SLP

802.11 signal strength

location

REGISTERTo: 815cepsrContact: alice@cs

SIP

room 815

41March 5, 2004

Location-based services in CINEMA Initial proof-of-concept implementation Integrate devices:

lava lamp via X10 controller set personalized light mood setting

Pingtel phone add outgoing line to phone and register user painful: needs to be done via HTTP POST request

stereo change to audio CD track based on user Sense user presence and identity:

passive infrared (PIR) occupancy sensor magnetic swipe card ibutton BlueTooth equipped PDA IR+RF badge (in progress) RFID (future) biometrics (future)

42March 5, 2004

Location-based IM & presence

43March 5, 2004

Emergency (911) services Old wireline and wireless

models don’t work any more All wireline systems are

potentially mobile (nomadic) device bought in Belgium place call in Canada with VSP in Mexico and maybe a VPN for extra

excitement… Customer may not have a

traditional voice carrier at all corporate residential VSP in a

different country

Needs to work internationally same standards no custom configuration

Components: universal identifier “sos” configure local emergency

numbers find right PSAP identify and verify PSAP

On-going effort in IETF and NENA

44March 5, 2004

Location-based call routing – UA knows its location

GPS

40.86N 73.98ECN=us A1=NJ A2=Bergen

INVITE sips:sos@

DHCP

outboundproxy server

provided by local ISP? 40.86N 73.98E: Leonia, NJ fire dept.

leonia.nj.us.sos.arpaPOLY 40.85 73.97 40.86 73.99NAPTR … firedept@leoniaboro.org

45March 5, 2004

Location-based call routing – network knows location

IP

48° 49' N 2° 29' E

TOA

include locationinfo in 302

INVITE sips:sos@ INVITE sips:sos@paris.gendarme.fr

map location to (SIP) domain

outbound proxy

46March 5, 2004

Service creation

47March 5, 2004

PSTN vs. VoIP and the role of carriers

PSTN: only carriers can get full signaling functionality (SS7) UNI vs. NNI signaling

VoIP: same signaling, same functionality Application-layer service providers (VSP) ≠ network-

layer service provider enterprise may run its own services Columbia doesn’t use an ‘email service provider’…

48March 5, 2004

Network vs. end system services

Really two meanings: services implemented in user agent (instead of proxy) services implemented in server run by end user (instead of

carrier) business residential

Variation on old Centrex vs. PBX argument except that media routing no longer an issue

Often, services require or can use both: e.g., the history of speed dial

CLASS service: translation in CO (semi)intelligent end systems: locally, possibly with hotsync to PC intelligent end system, but network-synchronized

49March 5, 2004

Call routing services

Outsourcing allows temporarily disconnected end users

Staged service:

carrier proxy user proxy

basic call routing

personalpreference

s

50March 5, 2004

Carrier services: Identity management

Identity assertion (notary) services best done by larger organization server certificates name recognition recourse

Anonymity services needs to have large user population to provide effective

hiding Portable services

high availability and universal reachability

51March 5, 2004

Service creation

programmer, carrier

end user

network servers SIP servlets, sip-cgi

CPL

end system VoiceXML VoiceXML (voice),

LESS

Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models

52March 5, 2004

Call Processing Language (CPL) XML-based “language” for processing requests intentionally restricted to branching and subroutines no variables (may change), no loops thus, easily represented graphically

and most bugs can be detected statically termination assured

mostly used for SIP, but protocol-independent integrates notion of calendaring (time ranges) structured tree describing actions performed on call setup event top-level events: incoming and outgoing

53March 5, 2004

CPL Location set stored as implicit global variable

operations can add, filter and delete entries Switches:

address language time, using CALSCH notation (e.g., exported from Outlook) priority

Proxy node proxies request and then branches on response (busy, redirection, noanswer, ...)

Reject and redirect perform corresponding protocol actions Supports abstract logging and email operation

54March 5, 2004

CPL example

String-switchfield: from

match:*@example.com

otherwise

proxytimeout: 10s

locationurl: sip:jones@

example.comvoicemail.

merge: clear

locationurl: sip:jones@

example.com

redirect

Call

busy

timeout

failure

55March 5, 2004

CPL example<?xml version="1.0" ?><!DOCTYPE call SYSTEM "cpl.dtd">

<cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:jones@example.com&Subject=lookup%20failed" /> </failure> </lookup> </incoming></cpl>

56March 5, 2004

Service creation environment for CPL and LESS

57March 5, 2004

Security issues

58March 5, 2004

Security issues: Threats

Fraud authentication (Digest) VSP-provided customer

certificates for S/MIME authenticated identity body

SIP spam domain-based

authentication trait-based authentication

(future) return calls reputation systems

DOS attacks layered protection

User privacy and confidentiality TLS and S/MIME for

signaling SRTP for media streams IPsec unlikely (host vs.

person) Needs to work across

domains and administrations

59March 5, 2004

DOS attack prevention

authentication

return routability

port filtering (SIP only)address-based rate limiting

UDP: SIPTCP: SYN attack precautions neededSCTP: built-in

60March 5, 2004

Denial-of-service attacks – signaling attack targets:

DNS for mapping SIP proxies SIP end systems at PSAP

types of attacks: amplification only if no routability

check, no TCP, no TLS state exhaustion no state until

return routability established bandwidth exhaustion no defense

except filters for repeats one defense: big iron & fat

pipe danger of false positives

unclear: number of DOS attacks using spoofed IP addresses mostly for networks not

following RFC 2267 (“Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”)

limit impact of DOS: require return routability built-in mechanism for SIP

(“null authentication”) also provided by TLS allow filtering of attacker IP

addresses (pushback)

61March 5, 2004

TLS End-to-end security

S/MIME but PKI issues proxy inspection of

messages TLS as convenient

alternatives need only server

certificates allows inspection for 911

services and CALEA hop-by-hop

home.comDigest

62March 5, 2004

TLS performance

63March 5, 2004

TLS performance

Key Size vs Time taken to initiate, setup and complete a SSL connection

0

200

400

600

800

1000

1200

1400

1600

1800

1024 2048 4096

Key size (bits)

Tim

e (

milliseco

nd

s)

Time taken to send connection request to serverTime taken to accept connection request from clientTime taken to send connection accept to client over network

64March 5, 2004

TLS performanceKey Size Vs Total time taken to set up a SSL connection

0

200

400

600

800

1000

1200

1400

1600

1800

1024 2048 4096

Key Size (Bits)

Tim

e (

Milliseco

nd

s)

Total time taken to setup SSL connection at the client Total time taken to setup SSL connection at the server

65March 5, 2004

Conclusions SIP: missing piece for

session-based services general event notification presence

Location-based and context-aware services e.g., emergency calling

Service creation from global to local killer app challenge: automated configuration and deployment

Security: layered approach email and web approaches apply can hopefully offer stronger caller authentication TLS as deployable version of PKI