VoIP%20-%20beyond%20replicating%20the%20limitations%20of%20the%20past

1
VoIP - beyond replicating the limitations of the
past

• Henning Schulzrinne
• Dept. 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_at_cs.columbia.edu
• Oracle
• October 30, 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

3
The three Cs of Internet applications
grossly simplified...
communications
community
commerce
what users care about
what users care about
research focus
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

5
Evolution of VoIP
Can it really replace the phone system?
How can I make it stop ringing?
long-distance calling, ca. 1930
does it do call transfer?
replacing the global phone system
going beyond the black phone
amazing the phone rings
catching up with the digital PBX
1996-2000
2000-2003
2004-2005
2006-
6
IETF VoIP efforts
ECRIT (emergency calling)
ENUM (E.164 translation)
SIMPLE (presence)
SPEERMINT (peering)
uses
GEOPRIV (geo privacy)
uses
uses
may use
XCON (conf. control)
SIPPING (usage, requirements)
SIP (protocol)
uses
provides
IPTEL (tel URL)
BLISS (common services)
SPEECHSC (speech services)
usually used with
P2PSIP (peer-to-pper)
AVT (RTP, SRTP, media)
SIGTRAN (signaling transport)
MMUSIC (SDP, RTSP, ICE)
IETF RAI area
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
8
SIP Overview
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
10
Filling in the protocol gap
Service/delivery synchronous asynchronous
push SIP RTSP, RTP SMTP
pull HTTP ftp SunRPC, Corba, SOAP (not yet standardized)
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

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

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

14
Basic SIP message flow
15
SIP trapezoid
destination proxy (identified by SIP URI domain)
outbound proxy
1st request
SIP trapezoid
2nd, 3rd, request
a_at_foo.com 128.59.16.1
registrar
voice traffic RTP
16
SIP message format
SDP
17
PSTN vs. Internet Telephony
PSTN
Signaling Media
Signaling Media
China
Internet telephony
Signaling
Signaling
Media
Australia
Belgian customer, currently visiting US
18
SIP addressing

• Users identified by SIP or tel URIs
• sipalice_at_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 (sipfoo_at_128.59.16.15)
• Registration binds SIP URIs (e.g., device
  addresses) to SIP address-of-record (AOR)

tel110
sipsos_at_domain
domain ? 128.59.16.17 via NAPTR SRV
19
3G Architecture (Registration)
mobility management
signaling
serving
interrogating
interrogating
CSCF
proxy
home IM domain
registration signaling (SIP)_
visited IM domain
20
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
21
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

22
Service Creation
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

24
Where to run services?
25
Service creation

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

programmer, carrier end user
network servers SIP servlets, sip-cgi, echarts CPL
end system VoiceXML VoiceXML (voice), LESS
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

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

28
CPL example
29
CPL example

• lt?xml version"1.0" ?gt
• lt!DOCTYPE call SYSTEM "cpl.dtd"gt
• ltcplgt
• ltincominggt
• ltlookup source"http//www.example.com/cgi-bin
  /locate.cgi?userjones"
• timeout"8"gt
• ltsuccessgt
• ltproxy /gt
• lt/successgt
• ltfailuregt
• ltmail url"mailtojones_at_example.comSubjec
  tlookup20failed" /gt
• lt/failuregt
• lt/lookupgt
• lt/incominggt
• lt/cplgt

30
Service creation environment for CPL and LESS
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
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

33
How to represent services?

• ECA (event condition action)

Natural thinking of a decision making a
policy/rule set
Using decision trees to represent policy/rule
sets (O(logN) execution time)
When I am in a conference, I will vibrate my
device for my bosss calls and reject all the
other calls.
34
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

IEEE ICC03 RFC3880
35
LESS elements
trigger
an incoming call
36
CUTE (Columbia University Telecommunication
service Editor)
37
Survey on end user service creation
Group1 IRT members, Group2 CS undergraduates,
Group3 Other people
85 would like to create their own services, 90
like to use CUTE to create services 90 can
correctly create service-1, 65 srv-2, 80 srv-3,
65 easy to understand LESS code
38
What is FI and how to handle it?

• Tree merging

Incoming call
Incoming call
Incoming call
If time is between 1000AM and 1100AM
If address is hgs
If address is hgs
If time is between 1000AM and 1100AM


ring
accept
ring
reject
Forward to conf
Forward to conf
reject
Take actions from both scripts. Simply setting
precedence rules cannot work.
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

ICFI05 (FIW) JCN
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.
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
42
Resolving interactions
condition
decision
options with lower risks
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

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

45
Incremental Tree Induction

• Incremental
• Incorporating
• Transposition
• Virtual prune
• Direct metrics
• Expected number of tests
• Leaf counts
• Minimum description length
• Expected misclassification cost

46
40 services Each for 300 calls 80 match 10
different way 10 mismatch
Simulation
47
Performance
IBM ThinkPad, Linux 1GHz PIII Mobile 256MB memory
Fast vs. incremental (20 samples) training
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) gt money gt
  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

49
Presence and event notification
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 --gt doesnt work with NATs
• Lots of research (e.g., SIENA)
• IETF efforts starting
• SIP-based
• XMPP

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
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, doesnt 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
53
GEOPRIV and SIMPLE architectures
rule maker
DHCP
XCAP (rules)
target
location server
location recipient
notification interface
publication interface
GEOPRIV
SUBSCRIBE
presentity
presence agent
watcher
SIP presence
PUBLISH
NOTIFY
caller
callee
SIP call
INVITE
INVITE
54
Presentity and Watchers
Presence Server (PS)
Bobs Presentity
Watchers
SUBSCRIBE
Watchers
Watchers
PUBLISH

NOTIFY
Available, Busy, Somewhat available, Invisible
Bobs status, location
Bobs Filters (Rules), PIDF )
wife
PUBLISH
son
R u there ?
friend
BUZZ
Cell
PC-IM Client
Bobs play station
Phone
external world
Bobs Presence User Agents (PUA)
) - PIDF Presence Information Data Format
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

56
Presence data architecture
presence sources
PUBLISH
raw presence document
privacy filtering
create view (compose)
depends on watcher
XCAP
XCAP
select best source resolve contradictions
composition policy
privacy policy
(not defined yet)
draft-ietf-simple-presence-data-model
57
Presence data architecture
candidate presence document
raw presence document
post-processing composition (merging)
watcher filter
SUBSCRIBE
remove data not of interest
difference to previous notification
final presence document
watcher
NOTIFY
58
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
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, )

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
• dont show recreation details to colleagues

61
RPID rich presence
ltpersongt lttuplegt ltdevicegt
ltactivitiesgt
ltclassgt
ltmoodgt
ltplace-isgt
ltplace-typegt
ltprivacygt
ltrelationshipgt
ltservice-classgt
ltspheregt
ltstatus-icongt
lttime-offsetgt
ltuser-inputgt
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

63
The role of presence for call routing
PUBLISH

• Two modes
• watcher uses presence information to select
  suitable contacts
• advisory caller may not adhere to suggestions
  and still call when youre 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)

PA
NOTIFY
translate RPID
LESS
CPL
INVITE
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

lttuple id"sg89ae"gt ltstatusgt ltgpgeoprivgt
ltgplocation-infogt ltgmllocationgt
ltgmlPoint gmlid"point1 srsName"ep
sg4326"gt ltgmlcoordinatesgt374630N
1222510W lt/gmlcoordinatesgt
lt/gmlPointgt lt/gmllocationgt
lt/gplocation-infogt ltgpusage-rulesgt
ltgpretransmission-allowedgtno lt/gpretransmissi
on-allowedgt ltgpretention-expirygt2003-06-2
3T045729Z lt/gpretention-expirygt
lt/gpusage-rulesgt lt/gpgeoprivgt lt/statusgt
lttimestampgt2003-06-22T205729Zlt/timestampgt lt/tupl
egt
65
Privacy rules

• Conditions
• identity, sphere
• time of day
• current location
• identity as lturigt or ltdomaingt ltexceptgt
• 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

66
Example rules document
ltrule id1gt
ltidentitygtltidgtuser_at_example.comlt/idgtlt/identitygt
ltconditionsgt
ltsub-handlinggtallowlt/sub-handlinggt
ltactionsgt
ltprovide-servicesgt ltservice-uri-schemegtsiplt/ser
vice-uri-schemegt ltservice-uri-schemegtmailtolt/se
rvice-uri-schemegt lt/provide-servicesgt ltprovide-per
songttruelt/provide-persongt ltprovide-activitiesgttrue
lt/provide-activitiesgt ltprovide-user-inputgtbarelt/pr
ovide-user-inputgt
ltrulesetgt
lttransformationsgt
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 dont get presence
  information
• Possibly implementation-defined privacy levels

68
Location-based services
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

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 Im in a theater
• outbound call routing
• contact nearest emergency call center
• send delivery_at_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

71
Location delivery
GPS
HELD
HTTP
wire map
DHCP
LLDP-MED
72
Location-based service language
NOTIFY
true
false
action
alert
IM
alert
incoming
proximity
message
outgoing
log
conditions
occupancy
actions
events
notify
call
message
time
transfer
subscription
join
73
Program location-based services
74
(No Transcript)
75
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

) - Verizon Service Assurance Business
Intelligence Toolkit
76
SABIT PALS Solution

• Integrates
• Status and diagnostic information of the vehicle
• Mobile employees location data obtained from a
  GPS device in a vehicle
• Mobile employees presence information data
  obtained from his/her cell-phone
• Laptop-based IM/VoIP soft client

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

78
SABIT PALS Architecture
DB
DB
Location from vehicle
GPS
SABIT System
EVDO
Watcher
SUBSCRIBE
Presence Server
HTTP/ SIP Gateway
Watcher
PUBLISH
NOTIFY
HTTP
Media Server Gateway
MSC/HLR
PUBLISH
SIP Proxy
SABIT Supervisor sees mobile employees via the
web-interface
Mobile Employees status is relayed through
multiple devices

Systems View
79
SABIT PALS Supervisor Application
80
Communications Webpage
81
Server scaling
82
SIP server overload
overloaded
Springsteen tickets!! earthquake vote for your
favorite
INVITE
503
overloaded
overloaded

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

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

1
REGISTER
300,000
reboot after power outage
84
Overload control

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

goodput
capacity
offered load
85
Coordinated Overload Control Architecture
Coordinated overload control with explicit
feedback
ietf-hilt draft model
Feedback scope explicit feedback treated
hop-by-hop vs. end-to-end hop-by-hop feedback is
generally believed to be more feasible
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 SIPit19 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 --gt 167 req/sec
• 300,000 registrations --gt 83 req/sec
• 0.001/subscriber

87
SIP server measurements
TCP

• Initial INVITE measurements
• OpenSER
• 400 calls/sec for TCP
• roughly 260 calls/sec for TLS

sipd REGISTER test
Kumiko Ono, Charles Shen, Erich Nahum
88
Roadmap

• Introduction
• Service creation
• Presence
• Location-based services
• Server scaling
• P2P SIP

89
P2P SIP
generic DHT service

• Why?
• no infrastructure available emergency
  coordination
• dont 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 network
P2P provider B
DNS
P2P provider A
traditional provider
zeroconf
LAN
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

91
Zeroconf solution for bootstrapping

• Three requirements for zero configuration
  networks
• IP address assignment without a DHCP server
• Host name resolution without a DNS server
• Local service discovery without any rendezvous
  server
• Solutions and implementations
• RFC3927 Link-local addressing standard for 1)
• DNS-SD/mDNS Apples protocol for 2) 3)
• Bonjour DNS-SD/mDNS implementation by Apple
• Avahi DNS-SD/mDNS implementation for Linux and
  BSD

92
DNS-SD/mDNS overview

• DNS-Based Service Discovery (DNS-SD) adds a level
  of indirection to SRV using PTR
• _daap._tcp.local. PTR Toms Music._daap._tcp.loc
  al.
• _daap._tcp.local. PTR Joes Music._daap._tcp.loc
  al.
• Toms Music._daap._tcp.local. SRV
• 0 0 3689
  Toms-machine.local.
• Toms Music._daap._tcp.local. TXT
• "Version196613" "iTSh Version196608"
  
• "Machine ID6070CABB0585"
  "Passwordtrue
• 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.

1n mapping
93
z2z Zeroconf-to-Zeroconf interconnection
rendezvous point - OpenDHT
Import/export services
Import/export services


z2z
z2z
Zeroconf subnet A
Zeroconf subnet B
94
Demo global iTunes sharing

• Exporting iTunes shares under key columbia
• z2z --exportopendht _daap._tcp --key
  columbia
• Importing services stored under key columbia
• z2z --importopendht --key columbia

95
How z2z works (exporting)
96
How z2z works (importing)
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 Globecom07 Workshop on Service
  Discovery

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-ur
  i-01

99
SIP URI advertisement

• Example
• _sipuri._udp.local. PTR sipbob_at_a.com._sipuri._u
  dp.local. _sipuri._udp.local. PTR
  sipjoe_at_a.com._sipuri._udp.local.
  sipbob_at_a.com._sipuri._udp.local. SRV
• 0 0 5060
  bobs-host.local.
• sipbob_at_a.com._sipuri._udp.local. TXT
• txtvers1 nameBob contactsipbob_at_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.) sipbob_at_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)

100
Peer-to-Peer Protocol (P2PP)

• Salman Abdul Baset, Henning Schulzrinne
• Columbia University

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

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

103
Peer-to-peer systems
Service discovery
High
NAT
Data size
Data size
Replication
NAT
Performance impact / requirement
Medium
Replication
Replication
Data size
Low
NAT
File sharing
VoIP
Streaming
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

105
P2PSIP architecture
Bootstrap / authentication server
alice_at_example.com
Overlay2
SIP
NAT
Overlay1
P2P
STUN
TLS / SSL
NAT
A peer in P2PSIP
bob_at_example.com
A client
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

107
DHTs
DHT Geometry Distance function Lookup correctness (neighbor table) Lookup performance (routing table)
ChordAccordion Ring Modulo numeric difference Successor 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
108
Periodic recovery
Accordion
Routing-table stabilization
Finger table
Tree
Kademlia
Lookup correctness
Parallel requests
Prefix-match
Modulo addition
Routing-table size
OneHop
Leaf-set
Recursive routing
Pastry
Bootstrapping
Updating routing-table from lookup requests
Bamboo
Ring
Tapestry
XOR
Proximity neighbor selection
Lookup performance
Successor
Reactive recovery
Chord
Hybrid
Proximity route selection
Strict vs. surrogate routing
Routing-table exploration
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)

110
How to design P2PP?
DHT-specific
DHT-specific Not restricted toone DHT
Bamboo
Chord
Lookup performance
Kademlia
Tapestry
Lookup correctness
Pastry
OneHop
Accordion
Successor / leaf-set
Finger table / routingtable
Modulo addition
Prefix-match
Routing-table size
XOR
Geometry
Updating routing-table from lookup requests
Ring
Hybrid
Strict vs. surrogate routing
Tree
Routing-table exploration
111
Chord (Strict routing-table management)
idx
Neighbor table(successor)
Routing table
x2i
x2i1
x2i2
x2i3
Immediately succeeds routing-table id
Node
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)

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

114
Join
JP
BS
P5
P7
P9
1. Query
2. 200
P5, P30, P2P-Options
3. STUN (ICE candidate gathering)
4. Join
5. Join
JP (P10)
6. 200
7. 200
N(P9, P15)
N(P9, P15)
8. Join
9. 200
10. Transfer
11. 200
115
Call establishment
P1
P3
P5
P7
1. Lookup-Peer (P7)
2. Lookup-Peer (P7)
3. Lookup-Peer (P7)
4. 200 (P7 Peer-Info)
5. 200 (P7 Peer-Info)
6. 200 (P7 Peer-Info)
7. INVITE
8. 200 Ok
9. ACK
Media
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/setupp2p
  p.html

117
Implementation
insert (key, value, callback)
callback (resp)
lookup (key, callback)
Client
Bootstrap
ChordPeer
KadPeer
OtherPeer
Node
Parser / encoder
Routing table
Distance
Neighbor table
BigInt
Transactions
Transport / timers
Sys
UDP
TCP
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

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

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

121
Backup slides
122
Timer triggered outgoing call

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltless xmlns"urnietfparamsxmlnsless
• xmlnsIM"urnietfparamsxmlnslessim
• xmlnsxsi" xsischemaLocation"gt
• lttimer dtstart"20050307T110000Z"gt
• ltstatus-switch uri"sipbob_at_example.com"
• status-name"presenc
  e"gt
• ltstatus is"open"gt
• ltlocation url"sipbob_at_example.com"gt
• ltcallgt
• ltbusygt
• ltlocation url"sipbob_at_example.com"gt
• ltIMsendmsggt
• Hi, please call me back. I am in
  office
• lt/IMsendmsggt
• lt/locationgt
• .

123
LESS elements (triggers)

• Triggers
• incoming incoming call handling
• outgoing user invoked outgoing call
• timer timer triggered actions
• UIcommand user interaction commands
• IMmessage incoming instant messaging
• Eventsubscription incoming subscription
• Eventnotification incoming notification

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)
• Eventevent-switch check values in event
  notifications
• LOCwhere-switch check users physical location
  information (remote or local user)
• LOCwhere-relation-switch check relative
  physical locations between two people

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
• Mediamediaupdate update media attributes
• Midcalltransfer transfer a call

• Midcallmerge merge multiple calls
• UIalert alert user
• UIgetinput get user input
• IMsendmsg send an instant message
• Eventapprove approve subscription
• Eventdeny deny event subscription
• Eventdefer defer the decision on event
  subscription
• Eventsubscribe send subscription out
• Eventnotify send notification out
• Queueenqueue put a call and its context into a
  queue
• Queuedequeue get a call and its context from a
  queue

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
• Mediamedia provide media attributes

127
(No Transcript)
128
LESS script customization
LESS editor
less.xsl
service.less (template)
xslif
address isvar
XSLT
configuration editor
service.html
translate.cgi
service_foo.less
129
LESS elements
130
Example Automatic Call Back (ACB)

• ltless xmlns"urnietfparamsxmlnsless
• xmlnsEvent"urnietfparamsxmlnslessevent
• xmlnsQueue"urnietfparamsxmlnslessqueue
• xmlnsxsi.
• xsischemaLocation"gt
• ltincominggt
• ltstatus-switch
• status-nameactivitygt
• ltstatus ison-the-phone"gt
• ltreject reasonbusygt
• ltnextgt
• ltQueueenqueue
• queue"callback"/gt
• lt/nextgt
• lt/rejectgt
• lt/statusgt
• lt/status-switchgt
• lt/incominggt

Use Event and Queue extension
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
If I am on-the-phone Reject and enqueue
131
Automatic Call Back (ACB) (cont.)
A event notification for myself
ltEventnotificationgt ltaddress-switch
field"origin"gt ltaddress uri"agent.uri"gt
ltEventevent-switchgt
ltEventevent packagepresence"
nameactivity" isnormal"gt
ltQueuedequeue
queue"callback"gt ltQueuesuccessgt
ltcall/gt
lt/Queuesuccessgt lt/Queuedequeuegt
lt/Eventeventgt lt/Eventevent-switchgt
lt/addressgt lt/address-switchgt
lt/Eventnotificationgt lt/lessgt
I am available
Dequeue and make a call
132
(No Transcript)
133
lt?xml version"1.0"?gt ltlessgt ltincominggt
ltaddress-switch field"origin"gt ltaddress
is"siphgs_at_cs.columbia.edu"gt ltaccept/gt
lt/addressgt ltotherwisegt
ltlocation url"sipfoo_at_example.com"gt
ltredirect/gt lt/locationgt
lt/otherwisegt lt/address-switchgt
lt/incominggt lt/lessgt
134
Rich signaling information

• Rich signaling information
• SIP headers
• Caller preference and callee capabilities
• MIME contents
• Event notification
• Other means
• Web calendar, Directory services

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

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 ICC05
137
Decision tree induction

• Entropy -S P log2P
• 30 rejects, 17 accepts-30/47log2(30/47)-17/47l
  og2(17/47) 0.944087
• Split on callerBob-30/33log2(30/33)-3/33log2(
  3/33)-14/14log2(14/14) 0.439497
• Information gain entropy change after splitting
• Information gain on the splitting is 0.50459

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

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 Im 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 whos willing and able to do
  that work.
• Lower the bar for understanding the low-level
  innards