VoIP - beyond replicating the limitations of the past

Henning SchulzrinneDept. of Computer Science, Columbia University, New York

(based on work in collaboration with IRT students including Salman Baset, Jae Lee, Kundan Singh, Xiaotao Wu, Jonathan Lennox, Vishal Singh & staff, as well as the IETF SIP,

GEOPRIV and SIMPLE WGs)

hgs@cs.columbia.edu

Oracle

October 30, 2007

Oct. 2007 2

Outline

• VoIP maturing: vision vs. reality• Advanced VoIP services

– user-programmable services– presence and location-based services– peer-to-peer systems

• VoIP challenges– scaling– spam/SPIT– emergency calling– complexity & interoperability

Oct. 2007 3

The three Cs of Internet applications

communications communitycommerce

grossly simplified...

researchfocus

what users care aboutwhat users care about

Oct. 2007 4

Killer Application

• Carriers looking for killer application– justify huge infrastructure investment– “video conferencing” (*1950 – †2000)– ?

• “There is no killer application”– Network television block buster YouTube hit– “Army of one”– Users create their own custom applications that are important to

them– Little historical evidence that carriers (or equipment vendors) will

find that application if it exists

• Killer app = application that kills the carrier

Oct. 2007 5

Evolution of VoIP

“amazing – the

phone rings”

“does it docall transfer?”

“How can I make it

stop ringing?”

1996-2000 2000-2003 2004-2005

catching upwith the digital PBX

long-distance calling,ca. 1930

going beyondthe black phone

2006-

“Can it really

replace the phone

system?”

replacing theglobal phone system

Oct. 2007 6

IETF VoIP efforts

SIP(protocol)

BLISS(common services)

ECRIT(emergency calling)

AVT(RTP, SRTP, media)

ENUM(E.164 translation)

IPTEL(tel URL)

SIMPLE(presence)

GEOPRIV(geo + privacy)

usesmay use

uses

provides

usually

used with

IETF RAI area

MMUSIC(SDP, RTSP, ICE)

XCON(conf. control)

SPEERMINT(peering)

uses

SPEECHSC(speech services)

SIGTRAN(signaling transport)

usesSIPPING(usage, requirements)

P2PSIP(peer-to-pper)

Oct. 2007 7

Old vs. new

old reality new idea new reality

service provider

ILEC, CLEC email-like, run by enterprise, homes

E.164-driven; MSOs, some ILECs, Skype, European SIP providers, Vonage, SunRocket

media 4 kHz audio wideband audio, video, IM, shared apps, …

4 kHz audio

services CLASS (CLID, call forwarding, 3-way calling, ...)

user-created services

(web model)

presence

still CLASS

user IDs E.164 email-like E.164

IM handles

Oct. 2007 8

SIP Overview

Oct. 2007 9

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

Oct. 2007 10

Filling in the protocol gap

Service/delivery synchronous asynchronous

push SIP

RTSP, RTP

SMTP

pull HTTP

ftp

SunRPC, Corba, SOAP

(not yet standardized)

Oct. 2007 11

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

Oct. 2007 12

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 100 companies produce SIP products• Verizon FiOS, Vonage, Yahoo, ...

Oct. 2007 13

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

Oct. 2007 14

Basic SIP message flow

Oct. 2007 15

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)

Oct. 2007 16

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

Oct. 2007 17

PSTN vs. Internet Telephony

Signaling & Media Signaling & Media

Signaling Signaling

Media

PSTN:

Internettelephony:

China

Belgian customer,currently visiting US

Australia

Oct. 2007 18

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

Oct. 2007 19

3G Architecture (Registration)

visited IM domain

home IM domain

servingCSCF

interrogating

proxy

interrogating

mobility managementsignaling

registration signaling (SIP)_

Oct. 2007 20

SIP is PBX/Centrex ready

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

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

Oct. 2007 21

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

Service Creation

Oct. 2007 23

Overview

• Communication services and where to run the services• Call Processing Language (CPL)• End system services

– Programmable – Service creation– Analyzable – Feature interaction handling– Intelligent – Feature learning– Ubiquitous – Context-based services

• Implementations

Oct. 2007 24

Where to run services?

Internet

Oct. 2007 25

Service creation

programmer, carrier end user

network servers SIP servlets, sip-cgi, echarts

CPL

end system VoiceXML VoiceXML (voice),

LESS

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

Oct. 2007 26

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

Oct. 2007 27

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

Oct. 2007 28

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

Oct. 2007 29

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>

Oct. 2007 30

Service creation environment for CPL and LESS

Oct. 2007 31

Run services on end systems

End devices End servers Net UAs Proxy Back-to-back user agent

Number of users Call states

Media ?

Number of devices User interaction

Direct Indirect* Indirect Indirect Indirect

Managing End user End user Admin. Admin. Admin.

IPTS ‘00

Oct. 2007 32

End system service programming

• What do we need?– A language and a tool

• End system service creation language– Easy to understand– Automatic service creation– Portable

• Create once, run on different devices

– Easy to manage• Facilitate feature interaction handling

– CPL, CCXML, APPEL, SPL…

Oct. 2007 33

How to represent services?

• ECA (event – condition – action)

Natural thinking of a decision making – a policy/rule set

When I am in a conference, I will vibrate my device for my boss’s calls and reject all the other calls.

Using decision trees to represent policy/rule sets(O(logN) execution time)

For an incoming call

If I am in a conference

Vibratemy device

Rejectthe call

YES

YES

NO

If the call is from my boss

Oct. 2007 34IEEE ICC’03RFC3880

Use LESS effort to create more services

• LESS: Language for End System Services – CPL: Call Processing Language (Jonathan, Henning, and myself)

• Simplicity– Four kinds of elements: trigger, switch, action, modifier– Tree-like structure, easy for feature interaction analysis

• Safety– Type safety: XML-based, no user defined variables– Control flow safety: tree-like structure without back-reference– No direct memory access– Default behavior for every tree branch

• Portability• Handle user interactions and media operations• Extensibility

– not just new elements, but can apply existing algorithms

Oct. 2007 35

LESS elements

trigger an incoming call

switch

check the caller

switchcheck time

switch

check priority

action

redirect

action

accept

action

reject

modifier

to Bob

= ≠

= ≠ ≠

Oct. 2007 36

CUTE (Columbia University Telecommunication service Editor)

Oct. 2007 37

Use CUTE to create services

0%

20%

40%

60%

80%

100%

Overall Group 1 Group 2 Group 3

Group

Percentage ofparticipants

Other

Don't know how

Some difficulties

Easily

Very comfortable

Survey on end user service creation

Group1: IRT members, Group2: CS undergraduates, Group3: Other people85% would like to create their own services,

90% like to use CUTE to create services90% can correctly create service-1, 65% srv-2, 80% srv-3, 65% easy to understand LESS code

Oct. 2007 38

ring

ring

What is FI and how to handle it?

• Tree merging

+ =If time is between

10:00AM and 11:00AMIf address is hgs

Forward to conf

Incoming call Incoming call

Incoming call

If time is between 10:00AM and 11:00AM

If address is hgs

rejectForward to conf

rejectaccept

Take actions from both scripts. Simply setting precedence rules cannot work.

Oct. 2007 39

FI handling for LESS

• Action conflict tables– Services conflict only if their actions conflict

• Tree merging algorithm– Detect and help to resolve

• Resolve conflicts

ICFI’05 (FIW)JCN

Oct. 2007 40

Pre-condition and expected results

pre-condition expected results

accept Call setup pending.

Audio device available.

Call setup is finalize.

Session is setup.

Audio device busy.

reject Call setup pending. Call setup finalized.

redirect Call setup pending. Call setup finalized on current UA.

call Audio device available. If callee accepts call, session is setup, audio device is busy.

Oct. 2007 41

Action conflict table

accept reject redirect call

accept A(media) C C R

reject C A(reason) C -

redirect C C A(target) -

call R - - A(target)

-: no interaction, A: attribute conflict, C: action conflict,E: enabling, R: resource competition

Oct. 2007 42

Resolving interactions

condition

decision

options withlower risks

Oct. 2007 43

No idea about services?

• Learning burden caused by new services– What and how– Help, not bypass

• Causal relationship between call information and call decisions– SIP headers– Different information sources– Examples

• Spam filtering, calendar-based services

Oct. 2007 44

What (learn from), what (generate), how

• Users’ communication history – LESS decision trees – decision tree induction

– find switches that can best partition actions

• Algorithm– Incremental– Prune– Quality measurement

30*3+10*2+7=117 30*2+3*2+10*3+4*3=108

Oct. 2007 45

Incremental Tree Induction

• Incremental– Incorporating– Transposition

• Virtual prune• Direct metrics

– Expected number of tests– Leaf counts– Minimum description length– Expected misclassification cost

address=a1

time=t1 time=t1

B DCA

Y N

Y N Y N

time=t1

address=a1 address=a1

A DCB

Y N

Y N Y N

Oct. 2007 46

Simulation

40 servicesEach for 300 calls80% match10% different way10% mismatch

Oct. 2007 47

Performance

Fast vs. incremental (20 samples) training

IBM ThinkPad, Linux 1GHz PIII Mobile256MB memory

Oct. 2007 48

How to handle service risks?

• Identify– Lose connection: reject, redirect, transfer, accept on wrong branch

– Lose privacy: accept, call, notify

– Lose money: accept, transfer to higher rate endpoint

– Lose attention: alert, accept, appliance control

• Analyze– Possibility: number of occurrence in the decision tree

– Impact: (connection, privacy) > money > attention, customizable

• Resolve– Change communication methods– Change communication targets– Reduce overall risk: avoiding high impact risks, though may cause low impact risks

• Contingency plan– Backup

Presence and event notification

Oct. 2007 50

Event notification as service enabler

• notify (small) group of users when something of interest happens– presence = change of communications state– email, voicemail alerts– environmental conditions– vehicle status– emergency alerts

• kludges– HTTP with pending response– inverse HTTP --> doesn’t work with NATs

• Lots of research (e.g., SIENA)

• IETF efforts starting– SIP-based– XMPP

Oct. 2007 51

Context-aware communication

• 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

parameter used by

time CPL

capabilities caller preferences

location location-based call routing

location events

activity/availability presence

sensor data (mood, bio) privacy issues similar to location data

Oct. 2007 52

The role of presence

• Guess-and-ring– high probability of failure:

• “telephone tag”• inappropriate time (call during

meeting)• inappropriate media (audio in

public place)– current solutions:

• voice mail tedious, doesn’t scale, hard to search and catalogue, no indication of when call might be returned

• automated call back rarely used, too inflexible

most successful calls are now scheduled by email

• Presence-based– facilitates unscheduled

communications– provide recipient-specific

information– only contact in real-time if

destination is willing and able– appropriately use synchronous

vs. asynchronous communication

– guide media use (text vs. audio)

– predict availability in the near future (timed presence)

Prediction: almost all (professional) communication will be presence-initiated or

pre-scheduled

Oct. 2007 53

GEOPRIV and SIMPLE architectures

targetlocationserver

locationrecipient

rulemaker

presentity

caller

presenceagent

watcher

callee

GEOPRIV

SIPpresence

SIPcall

PUBLISHNOTIFY

SUBSCRIBE

INVITE

publicationinterface

notificationinterface

XCAP(rules)

INVITE

DHCP

Oct. 2007 54

Presentity and Watchers

Bob’s status, location

Watchers

Available, Busy, Somewhat available,

InvisibleInvisible

wife

son

externalworld

PUBLISH SUBSCRIBE

NOTIFY

Bob’sPresentity WatchersWatchers

Bob’s Presence User Agents (PUA)

PC-IM Client

R u there ?

Bob’s play station

Cell

Phone

BUZZ

PUBLISH

Bob’s Filters

(Rules), PIDF *)

PresenceServer(PS)

*) - PIDF = Presence Information Data Format

friend

Oct. 2007 55

Basic presence

• Role of presence– initially: “can I send an instant message and expect a

response?”– now: “should I use voice or IM? is my call going to interrupt a

meeting? is the callee awake?”

• Yahoo, MSN, Skype presence services:– on-line & off-line

• useful in modem days – but many people are (technically) on-line 24x7

• thus, need to provide more context

– + simple status (“not at my desk”)• entered manually rarely correct• does not provide enough context for directing interactive

communications

Oct. 2007 56

Presence data architecture

rawpresencedocument

createview

(compose)

privacyfiltering

draft-ietf-simple-presence-data-model

compositionpolicy

privacypolicy

presence sources

XCAP XCAP

(not defined yet)

depends on watcherselect best sourceresolve contradictions

PUBLISH

Oct. 2007 57

Presence data architecture

candidatepresencedocument

watcherfilter

rawpresencedocument

post-processingcomposition(merging)

finalpresencedocument

differenceto previous notification

SUBSCRIBE

NOTIFY

remove data not of interest

watcher

Oct. 2007 58

Presence data model

“calendar” “cell” “manual”

alice@example.comaudio, video, text

r42@example.comvideo

person(presentity)

(views)

services

devices

Oct. 2007 59

Rich presence

• More information• automatically derived from

– sensors: physical presence, movement– electronic activity: calendars

• Rich information:– 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, …)

Oct. 2007 60

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

Oct. 2007 61

RPID: rich presence

<person> <tuple> <device>

<activities>

<class>

<mood>

<place-is>

<place-type>

<privacy>

<relationship>

<service-class>

<sphere>

<status-icon>

<time-offset>

<user-input>

Oct. 2007 62

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

Oct. 2007 63

The role of presence for call routing

• Two modes:– watcher uses presence

information to select suitable contacts

• advisory – caller may not adhere to suggestions and still call when you’re in a meeting

– user call routing policy informed by presence

• likely less flexible – machine intelligence

• “if activities indicate meeting, route to tuple indicating assistant”

• “try most-recently-active contact first” (seq. forking)

LESS

translateRPID

CPL

PA

PUBLISH

NOTIFY

INVITE

Oct. 2007 64

Presence and privacy

• All presence data, particularly location, is highly sensitive

• Basic location object (PIDF-LO) describes– distribution (binary)– retention duration

• Policy rules for more detailed access control– who can subscribe to

my presence– who can see what

when

<tuple id="sg89ae">

<status>

<gp:geopriv>

<gp:location-info>

<gml:location>

<gml:Point gml:id="point1“

srsName="epsg:4326">

<gml:coordinates>37:46:30N 122:25:10W

</gml:coordinates>

</gml:Point>

</gml:location>

</gp:location-info>

<gp:usage-rules>

<gp:retransmission-allowed>no

</gp:retransmission-allowed>

<gp:retention-expiry>2003-06-23T04:57:29Z

</gp:retention-expiry>

</gp:usage-rules>

</gp:geopriv>

</status>

<timestamp>2003-06-22T20:57:29Z</timestamp>

</tuple>

Oct. 2007 65

Privacy rules

• Conditions– identity, sphere– 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– privacy-safe composition:

removal of a rule can only reduce privileges

• Extendable to new presence data– rich presence– biological sensors– mood sensors

Oct. 2007 66

Example rules document

<identity><id>user@example.com</id></identity>

<sub-handling>allow</sub-handling>

<provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme></provide-services><provide-person>true</provide-person><provide-activities>true</provide-activities><provide-user-input>bare</provide-user-input>

<ru

lese

t>

<rule id=1>

<co

ndit

ions>

<tr

ansf

orm

ati

on

s>

<act

ions>

Oct. 2007 67

Creating and manipulating rules

• Uploaded in whole or part via XCAP• XML not user-visible

– web or application UI– similar to mail filtering

• Can also be location-dependent– “if at home, colleagues don’t get presence information”

• Possibly implementation-defined “privacy levels”

Location-based services

Oct. 2007 69

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

Oct. 2007 70

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

Oct. 2007 71

Location delivery

DHCP

HTTP

GPS

HELD

LLDP-MED

wiremap

Oct. 2007 72

Location-based service language

false

true

NOTIFY

action alert

conditions

proximity

occupancy

time

IM

actions

alert

message

log

call

transfer

join

events

incoming

outgoing

notify

message

subscription

Oct. 2007 73

Program location-based services

Oct. 2007 74

Oct. 2007 75 *) - Verizon Service Assurance Business Intelligence Toolkit

Application: Verizon SABIT PALS

• SABIT = web-based mobile employee productivity management system

• PALS - Presence-Aware Location-Based Service– Advanced communication services based on aggregation of

presence information– Enhanced vehicle management system

• Presence/availability information of a user is combined with the location information (of the vehicle) to achieve an integrated communication environment– “only call when vehicle is stopped”

Oct. 2007 76

SABIT PALS Solution

Integrates:

• Status and diagnostic information of the vehicle

• Mobile employee’s location data obtained from a GPS device in a vehicle

• Mobile employee’s presence information data obtained from his/her cell-phone

• Laptop-based IM/VoIP soft client

Oct. 2007 77

GPSEVDO

WiFi

VZ Data/Real TimeVZ VPN

Field Tech Laptop-Connect

via WiFi or Ethernet

Components of PALS architecture

• Integrated In-Vehicle Device (IIVD – Vehicle Events)

• SABIT System

• HTTP-SIP Gateway (LBS Presence User Agent)

• Media Server

• Watcher or Supervisor Application

• Presence Server (PS)

Oct. 2007 78

SABIT PALS Architecture

PUBLISH PresenceServer

NOTIFY

DB

MSC/HLR

SUBSCRIBE Watcher

Watcher

SABIT System

Mobile Employee’s status is relayed through multiple devices

EVDO

GPS

SIP Proxy

Systems View

DB

HTTP/ SIPGateway

HTTP

Location from vehicle

PUBLISH

Media ServerGateway

SABIT Supervisor “sees” mobile employees via the web-interface

Oct. 2007 79

SABIT PALS Supervisor Application

Oct. 2007 80

Communications Webpage

Server scaling

Oct. 2007 82

SIP server overload

• Proxies will return 503 --> retry elsewhere• Just adds more load• Retransmissions exacerbate the problem

overloaded

overloaded

overloaded

INVITE

503

Springsteen tickets!!earthquake

vote for your favorite…

Oct. 2007 83

Avalanche restart

• Large number of terminals all start at once• Typically, after power outage• Overwhelms registrar• Possible loss of registrations due to retransmission time-out

#300,000

#1

reboot afterpower outage

REGISTER

Oct. 2007 84

Overload control

• Current discussion in design team• Feedback control: rate-based or window-based• Avoid congestion collapse• Deal with multiple upstream sources

capacity

goodput

offered load

S5

S1

S2

S3

S4

UA

UA

Oct. 2007 85

Coordinated Overload Control Architecture

Sending Entity (SE) Receiving Entity (RE)

Load Sample

Feedback

Throttle

SIP SIP

Control Function

MonitorActuator

Control Function

Coordinated overload control with explicit feedback ietf-hilt draft model

SIP

Overload Control

Sending Entity (SE)

SIP

Overload Control

Overload Feedback

Overload DetectionOverload Enforcement

Receiving Entity (RE)

Feedback scope: explicit feedback treated hop-by-hop vs. end-to-end

hop-by-hop feedback is generally believed to be more feasible

Oct. 2007 86

Scaling servers & TCP

• Need TCP– TLS support: customer

privacy, theft of service, …• particularly for WiFi

– many SIP messages now exceed reasonable UDP size (fragmentation)

• e.g., INVITE for IMS: 1182 bytes

• Concern: UA support– improving: 82% of systems at

recent SIPit’19 had TCP support

– only 45% support TLS

• Concern: TCP (and TLS) much less efficient than UDP

– running series of tests to identify differences

– difference mainly in• connection setup cost

• message splitting (may need pre-parsing or incremental parsers)

• thread count (one per socket?)

• Our model: – 300,000 customers/servers

• 0.1 Erlang, 180 sec/call

– 600,000 BHCA --> 167 req/sec– 300,000 registrations --> 83

req/sec– $0.001/subscriber

Oct. 2007 87

SIP server measurements

• Initial INVITE measurements– OpenSER

– 400 calls/sec for TCP

– roughly 260 calls/sec for TLS

sipd REGISTER test

Kumiko Ono, Charles Shen, Erich Nahum

TCP

Oct. 2007 88

Roadmap

• Introduction

• Service creation

• Presence

• Location-based services

• Server scaling

• P2P SIP

Oct. 2007 89

LAN

P2P SIP

• Why?– no infrastructure available: emergency

coordination– don’t want to set up infrastructure: small

companies– Skype envy :-)

• P2P technology for– user location

• only modest impact on expenses• but makes signaling encryption cheap

– NAT traversal• matters for relaying

– services (conferencing, …)• how prevalent?

• New IETF working group formed– likely, multiple DHTs– common control and look-up protocol?

P2P provider A

P2P provider B

p2p network

traditional provider

DNS

zeroconf

generic DHT service

Oct. 2007 90

P2P SIP -- components

• Multicast-DNS (zeroconf) SIP enhancements for LAN– announce UAs and their

capabilities

• Client-P2P protocol– GET, PUT mappings– mapping: proxy or UA

• P2P protocol– get routing table, join, leave, …– independent of DHT?– replaces DNS for SIP, not proxy

Oct. 2007 91

Zeroconf: solution for bootstrapping

• Three requirements for zero configuration networks:1) IP address assignment without a DHCP server

2) Host name resolution without a DNS server

3) Local service discovery without any rendezvous server

• Solutions and implementations:– RFC3927: Link-local addressing standard for 1)

– DNS-SD/mDNS: Apple’s protocol for 2) & 3)

– Bonjour: DNS-SD/mDNS implementation by Apple

– Avahi: DNS-SD/mDNS implementation for Linux and BSD

Oct. 2007 92

DNS-SD/mDNS overview

• DNS-Based Service Discovery (DNS-SD) adds a level of indirection to SRV using PTR:_daap._tcp.local. PTR Tom’s Music._daap._tcp.local._daap._tcp.local. PTR Joe’s Music._daap._tcp.local.

Tom’s Music._daap._tcp.local. SRV 0 0 3689 Toms-machine.local.

Tom’s Music._daap._tcp.local. TXT "Version=196613" "iTSh Version=196608" "Machine ID=6070CABB0585" "Password=true”

Toms-machine.local. A 160.39.225.12

• Multicast DNS (mDNS)– Run by every host in a local link– Queries & answers are sent via multicast– All record names end in “.local.”

1:n mapping

Oct. 2007 93

z2z: Zeroconf-to-Zeroconf interconnection

rendezvous point - OpenDHT

z2z

Import/exportservices

Zeroconf subnet A

z2z

Import/exportservices

Zeroconf subnet B

Oct. 2007 94

Demo: global iTunes sharing

• Exporting iTunes shares under key “columbia”:$ z2z --export:opendht _daap._tcp --key “columbia”

• Importing services stored under key “columbia”:$ z2z --import:opendht --key “columbia”

Oct. 2007 95

How z2z works (exporting)

OpenDHT

z2z

Send browse request (i.e., PTR query) for service type: _daap._tcp

1)

Tom’s Music._daap._tcp.local

Joe’s Music._daap._tcp.local

Send resolve request (i.e., SRV, A, and TXT query) for each service

2)

160.39.225.12Tom’s ComputerPassword=true……

160.39.225.13Joe’s ComputerPassword=false……

Export them by putting into OpenDHT

3)

put:key= z2z._daap._tcp.columbiavalue= Tom’s Music 160.39.225.12:3689 Password=true ……

Oct. 2007 96

How z2z works (importing)

OpenDHT

z2z

Issue get call into OpenDHT

1)

Add “A” record into mDNS

2)

Import services by registering them (i.e., add PTR, SRV, TXT records to the local mDNS)

3)

get:key=z2z._daap._tcp.columbiavalue=Tom’s Music

160.39.225.12:3689……

value=Joe’s Music…… mDNS

“A” record for 160.39.225.12

Tom’s Music._daap._tcp.local_remote-160.39.225.12.local……

Oct. 2007 97

z2z implementation

• C++ Prototype using xmlrpc-c for OpenDHT access– Proof of concept– Porting problem due to Bonjour and Cygwin incompatibility

• z2z v1.0 released – Rewritten in Java from scratch– Open-source (BSD license)– Available in SourceForge (https://sourceforge.net/projects/z2z)

• Paper describing design and implementation detail– z2z: Discovering Zeroconf Services Beyond Local Link

• Lee, Schulzrinne, Kellerer, and Despotovic

– Submitted to IEEE Globecom’07 Workshop on Service Discovery

Oct. 2007 98

Zeroconf for SIP

• Enable SIP communication when proxy and registrar are not available– Good use case for z2z– Fill in the gap of P2P-SIP effort:

• local & small scale (10s to 100s)• high mobility• avoid construction of DHT

• Internet Draft published and presented at IETF-68– SIP URI Service Discovery using DNS-SD

• Lee, Schulzrinne, Kellerer, and Despotovic• http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-01

Oct. 2007 99

SIP URI advertisement

• Example_sipuri._udp.local. PTR sip:bob@a.com._sipuri._udp.local. _sipuri._udp.local. PTR sip:joe@a.com._sipuri._udp.local. sip:bob@a.com._sipuri._udp.local. SRV

0 0 5060 bobs-host.local. sip:bob@a.com._sipuri._udp.local. TXT txtvers=1 name=Bob contact=sip:bob@bobs-host.local.

• Service instance name: Instance.Service.Domain– Instance = ( SIP-URI / SIPS-URI ) [ SP description ]– Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp”– E.g.) sip:bob@example.com - PDA._sipuri._udp.local.

• Contact TXT record attribute– Similar to Contact SIP header except:

• It contains only a single URI• Non-SIP URIs are not allowed

– UA capabilities advertised via field parameters (RFC3840)

Peer-to-Peer Protocol (P2PP)

Salman Abdul Baset, Henning SchulzrinneColumbia University

Oct. 2007 101

Overview

• Objective: key (opaque) data– distributed data structure with O(log N) or O(1) [rarely]

• Practical issues in peer-to-peer systems• Peer-to-peer systems

– file sharing– VoIP– streaming

• P2PSIP architecture• Peer-to-peer protocol (P2PP)• P2PP design issues• Implementation

Oct. 2007 102

Practical issues in p2p systems

• Bootstrap / service discovery• NAT and firewall traversal• TCP or UDP?• Routing-table management• Operation during churn• Availability and replication• Identity and trust management

Oct. 2007 103

Peer-to-peer systems

File sharing VoIP Streaming

Low

Medium

High

NAT

NAT

NAT

Data size

Data size

Data size

Pe

rfo

rman

ce im

pa

ct /

req

uire

me

nt

Service discovery

Replication

Replication

Replication

Oct. 2007 104

P2PSIP: Concepts

• Decentralized SIP– Replace SIP proxy and registrar with p2p

endpoints

• Supernode architecture– P2PSIP peers

• participate in the p2p overlay

– P2PSIP clients• use peers to locate users and resources

Oct. 2007 105

P2PSIP architecture

SIP

P2P STUN

TLS / SSL

A peer in P2PSIP

NAT

NAT

A client

alice@example.com

bob@example.com

[ Bootstrap / authentication server ]

Overlay1

Overlay2

Oct. 2007 106

Peer-to-Peer Protocol (P2PP)

• P2P applications have common requirements such as discovery, NAT traversal, relay selection, replication, and churn management.

• Goals– A protocol to potentially implement any structured or unstructured

protocol.– Not dependent on a single DHT or p2p protocol

• Not a new DHT!

• It is hard!– Too many structured and unstructured p2p protocols– Too many design choices!

• Lets consider DHTs

Oct. 2007 107

DHTs

DHT GeometryDistance function

Lookup correctness

(neighbor table)

Lookup performance

(routing table)

ChordAccordion

RingModulo numeric

differenceSuccessor list Finger table

Tapestry, Pastry,

Bamboo

Hybrid =

Tree + Ring

Prefix match. If fails, then modulo

numeric difference

Leaf-set (Pastry) Routing table

Kademlia XOR XOR of two IDs None Routing table

Oct. 2007 108

Kademlia

XOR

Finger table

Parallel requests

Recursive routing Pastry

Bamboo

ChordSuccessor

Modulo additionPrefix-match

Leaf-set

Routing-table stabilization

Lookup correctness

Lookup performanceProximity neighbor selection

Proximity route selection

Routing-table size

Strict vs. surrogate routing

OneHop

Bootstrapping

Updating routing-table from lookup requests

Tapestry Ring

Tree

HybridReactive recovery

Periodic recovery Accordion

Routing-table exploration

Oct. 2007 109

How to design P2PP?

• Structured– Identify commonalities in DHTs

• Routing table (finger table)• Neighbor table (successor list, leaf-set)

– Separate core routing mechanisms from from DHT-independent issues.• Unstructured

– may not always find all keys• Incorporate mechanisms for

– discovery– NAT / firewall traversal– churn, identity and trust management– request routing (recursive / iterative / parallel)

Oct. 2007 110

Parallel requests

Recursive routing

Routing-table stabilization

Proximity neighbor selection

Proximity route selection

Bootstrapping

Reactive vs. periodic recovery

DHT-independent

Kademlia

XOR

Pastry

Bamboo Chord

Modulo addition

Prefix-match

OneHop

Tapestry

Ring

Tree

Hybrid

DHT-specific

Accordion

Finger table / routingtable

Successor / leaf-set

Lookup correctness

Lookup performance

Routing-table size

Strict vs. surrogate routing

Updating routing-table from lookup requests

DHT-specific Not restricted toone DHT

Routing-table exploration

Geometry

How to design P2PP?

Oct. 2007 111

Chord (Strict routing-table management)

Neighbor table(successor)

Node

x+2i

x+2i+1

x+2i+2

x+2i+3

id=x

Routing table

Immediately succeeds routing-table id

Oct. 2007 112

Peer-to-Peer Protocol (P2PP)

• binary protocol• Geared towards IP telephony but equally applicable to file sharing,

streaming, and p2p-VoD• Multiple DHT and unstructured p2p protocol support• Application API• NAT traversal

– using STUN, TURN and ICE– ICE encoding in P2PP

• Request routing– recursive, iterative, parallel– per message

• Supports hierarchy (super nodes [peers], ordinary nodes [clients])• Reliable or unreliable transport (TCP or UDP)

Oct. 2007 113

Peer-to-Peer Protocol (P2PP)

• Security– DTLS, TLS, signatures

• Multiple hash function support– SHA1, SHA256, MD4, MD5

• Diagnostics– churn rate, messages sent/received

• Node capabilities– bw determination, CPU utilization, number of neighbors, mobility

Oct. 2007 114

Join

JP BS P5 P71. Query

2. 200

P5, P30, P2P-Options

4. Join

9. 200

N(P9, P15)

5. Join

7. 200

P9

JP(P10)

8. Join

6. 200

N(P9, P15)

10. Transfer

11. 200

3+. STUN (ICE candidate gathering)

Oct. 2007 115

Call establishment

P1 P3 P5 P71. Lookup-Peer (P7)

5. 200 (P7 Peer-Info)

2. Lookup-Peer (P7) 3. Lookup-Peer (P7)

4. 200 (P7 Peer-Info)

6. 200 (P7 Peer-Info)

7. INVITE

8. 200 Ok

9. ACK

Media

Oct. 2007 116

Implementation

• Chord, Kademlia, Bamboo (in-progress)• SHA1, SHA256, MD5, MD4• Windows, Linux• Integrated with OpenWengo (VoIP phone)

• Available for download (Linux + Windows)http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html

Oct. 2007 117

Implementation

Transport / timers

Node

BigInt

Parser / encoder

UDP TCP

Transactions

ClientBootstrap ChordPeer KadPeer OtherPeer

Sys

insert (key, value, callback)callback (resp)

lookup (key, callback)

Routing table

Neighbor table

Distance

Oct. 2007 118

OpenWengo implementation

• Alice and Bob are part of Kademlia network

• Alice calls Bob• The lookup is

performed using P2PP

• Call is established using SIP

Oct. 2007 119

P2P summary

• P2P techniques now becoming mainstream– motivated by low opex, ease of deployment– building block, rather than application

• Many operational issues– interconnection: z2z– local peering: Bonjour for SIP– start-up and recovery: cf. Skype failure

• P2PP: Common platform protocol– application-neutral– extensible mechanism

Oct. 2007 120

Conclusion

• Even after 10+ years, VoIP mostly still “cheaper calls”• New services and models:

– user-programmable services– (rich) presence– location-based services– P2P SIP

• Scaling to carrier-scale and under duress• Current standardization processes slow and complexity-

inducing

Backup slides

Oct. 2007 122

Timer triggered outgoing call <?xml version="1.0" encoding="UTF-8"?>

<less xmlns="urn:ietf:params:xml:ns:less“

xmlns:IM="urn:ietf:params:xml:ns:less:im“

xmlns:xsi=“…" xsi:schemaLocation=“…">

<timer dtstart="20050307T110000Z">

<status-switch uri="sip:bob@example.com"

status-name="presence">

<status is="open">

<location url="sip:bob@example.com">

<call>

<busy>

<location url="sip:bob@example.com">

<IM:sendmsg>

Hi, please call me back. I am in office

</IM:sendmsg>

</location>

…………….

Oct. 2007 123

LESS elements (triggers)

• Triggers– incoming: incoming call handling– outgoing: user invoked outgoing call – timer: timer triggered actions– UI:command: user interaction commands– IM:message: incoming instant messaging– Event:subscription: incoming subscription– Event:notification: incoming notification

Oct. 2007 124

LESS elements (switches)

• Switches– time-switch: make decisions based on time– address-switch: make decisions based on caller, callee– priority-switch: make decisions based on call priority– string-switch: make decisions based on subject, …– language-switch: make decisions based on languages– status-switch: make decisions based on users’ status (remote user or

local user, status includes presence, activity, mood, …, as listed in RPID)

– Event:event-switch: check values in event notifications– LOC:where-switch: check users’ physical location information

(remote or local user)– LOC:where-relation-switch: check relative physical locations between

two people

Oct. 2007 125

LESS elements (actions)

• Actions– accept: accept an incoming call– reject: reject an incoming call– redirect: redirect an incoming call– authenticate: authenticate an incoming request– call: make an outgoing call– terminate: disconnect a call– wait: wait for a certain time before next

action

– mail: send email– log: log request handling process– Media:mediaupdate: update media attributes– Midcall:transfer: transfer a call

– Midcall:merge: merge multiple calls– UI:alert: alert user– UI:getinput: get user input– IM:sendmsg: send an instant message– Event:approve: approve subscription– Event:deny: deny event subscription– Event:defer: defer the decision on event

subscription

– Event:subscribe: send subscription out– Event:notify: send notification out– Queue:enqueue: put a call and its context into a

queue

– Queue:dequeue: get a call and its context from a queue

Oct. 2007 126

LESS elements (modifiers)

• Two smaller concepts might be simpler and more flexible than one more powerful but complicated concept

• Modifiers– location: to which a request to be directed– lookup: lookup locations from a source– remove-location: remove locations from location set– Media:media: provide media attributes

Oct. 2007 127

Oct. 2007 128

LESS script customization

xsl:if

LESS editor

service.less(template)

XSLT

less.xsl

configurationeditor

service.html

translate.cgi

service_foo.less

address is=$var

Oct. 2007 129

LESS elements

Oct. 2007 130

Example: Automatic Call Back (ACB)

<less xmlns="urn:ietf:params:xml:ns:less“ xmlns:Event="urn:ietf:params:xml:ns:less:event“ xmlns:Queue="urn:ietf:params:xml:ns:less:queue“ xmlns:xsi=“….“ xsi:schemaLocation=“……"><incoming> <status-switch status-name=“activity”> <status is=“on-the-phone"> <reject reason=“busy”> <next> <Queue:enqueue queue="callback"/> </next> </reject> </status> </status-switch></incoming>

In ITU Q.1211

“This feature allows the called party to automatically call back the calling party of the last call directed to the called party.”

Check my activity for an incoming call

Use Event and Queue extension

If I am on-the-phoneReject and enqueue

Oct. 2007 131

<Event:notification> <address-switch field="origin"> <address uri="{agent.uri}"> <Event:event-switch> <Event:event package=“presence" name=“activity" is=“normal"> <Queue:dequeue queue="callback"> <Queue:success> <call/> </Queue:success> </Queue:dequeue> </Event:event> </Event:event-switch> </address> </address-switch> </Event:notification></less>

A event notification for myself

I am available

Dequeue and make a call

Automatic Call Back (ACB) (cont.)

Oct. 2007 132

Oct. 2007 133

<?xml version="1.0"?><less> <incoming> <address-switch field="origin"> <address is="sip:hgs@cs.columbia.edu"> <accept/> </address> <otherwise> <location url="sip:foo@example.com"> <redirect/> </location> </otherwise> </address-switch> </incoming></less>

Oct. 2007 134

Rich signaling information

• Rich signaling information– SIP headers– Caller preference and callee capabilities– MIME contents– Event notification– Other means

• Web calendar, Directory services

Oct. 2007 135

Rich services

• Be able to handle services in PSTN networks– ITU Q.1211

• ABD, ACB, CFC, CHA, QUE, CRG, OCS, …– Services in 5ESS switches

• Attendant camp-on, Automatic recall, …– Services in CSTA Phase III

• defined as signaling actions in LESS, e.g., mediaupdate– Emergency

• provide location information

• New services– Interact with existing Internet services

• web, email, SLP, SAP, IM, presence, location, networked appliance control, directory service, calendar service, conferencing

– Not named services, but programmable services– Programmable conferencing services

Oct. 2007 136

Definition

• What is service learning– Automatically generate user desired services– Help users, not bypass users– Services on both proxy servers and end systems

• What is service risk management– Risk caused by automation– How to reduce the overall risks

IEEE ICC’05

Oct. 2007 137

Decision tree induction

• Entropy: -Σ P log2P – 30 rejects, 17 accepts

-30/47*log2(30/47)-17/47*log2(17/47) = 0.944087

– Split on caller=Bob-30/33*log2(30/33)-3/33*log2(3/33)-14/14*log2(14/14) = 0.439497

• Information gain: entropy change after splitting– Information gain on the splitting is 0.50459

Oct. 2007 138

Decision tree induction

• Find the splitting that can get the largest information gain• Repeat for all sub-trees until no more information gain• Noisy data and prune

– Splitting causes higher error

Oct. 2007 139

Why not just a service creation tool

• Portability– Java and scripting languages are also “portable”

• “I am happy to see a piece of technology that works so well that I’m free to ignore its inner details.”– Maybe not some complicated work

• ”I also want to have the low-level innards visible, controllable when possible, and modifiable by anyone who’s willing and able to do that work.”– Lower the bar for understanding the low-level innards