VoIP:%20Not%20your%20grandmother's%20phone%20any%20more

1
VoIP Not your grandmother's phone any more

• Henning Schulzrinne
• Dept. of Computer Science, Columbia University,
  New York
• (based on work in collaboration with IRT students
  staff, as well as the IETF GEOPRIV and SIMPLE
  WGs)
• hgs_at_cs.columbia.edu
• Rutgers University
• April 2009

2
Outline

• VoIP maturing vision vs. reality
• presence and location-based services
• user-programmable services
• VoIP challenges
• scaling
• peer-to-peer systems
• spam/SPIT
• emergency calling
• The state of SIP standardization, year 11
• developments in 2006 upcoming highlights
• trouble in standards land
• 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
Collaboration in transition
inter-organization multiple technology
generations diverse end points
intra-organization small number of systems
(meeting rooms)
standards-based solutions
proprietary (single-vendor) systems
6
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-
7
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)
SIP (protocol)
SIPPING (usage, requirements)
uses
provides
IPTEL (tel URL)
SPEECHSC (speech services)
usually used with
MMUSIC (SDP, RTSP, ICE)
AVT (RTP, SRTP, media)
SIGTRAN (signaling transport)
IETF RAI area
8
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
9
SIP Overview
10
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
11
Filling in the protocol gap
Service/delivery synchronous asynchronous
push SIP RTSP, RTP SMTP
pull HTTP ftp SunRPC, Corba, SOAP (not yet standardized)
12
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

13
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
• Microsofts Windows Messenger (4.7) includes SIP

14
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

15
Basic SIP message flow
16
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
17
SIP message format
SDP
18
PSTN vs. Internet Telephony
PSTN
Signaling Media
Signaling Media
China
Internet telephony
Signaling
Signaling
Media
Australia
Belgian customer, currently visiting US
19
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
20
3G Architecture (Registration)
mobility management
signaling
serving
interrogating
interrogating
CSCF
proxy
home IM domain
registration signaling (SIP)_
visited IM domain
21
Presence and event notification
22
We need glue!

• Lots of devices and services
• cars
• household
• environment
• Generally, stand-alone
• e.g., GPS cant talk to camera
• Home
• home control networks have generally failed
• cost, complexity
• Environment
• Internet of things
• tag bus stops, buildings, cars, ...

23
Left to do event notification

• 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

24
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

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
25
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
26
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
27
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
28
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

29
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
30
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
31
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
32
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, )

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

35
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

36
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
37
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
38
Privacy policy relationships
common policy
geopriv-specific
presence-specific
future
RPID
CIPID
39
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

40
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
41
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

42
Location-based services
43
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

44
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

45
Location delivery
GPS
HELD
HTTP
wire map
DHCP
LLDP-MED
46
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
47
Program location-based services
48
(No Transcript)
49
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
50
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

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

52
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
53
SABIT PALS Supervisor Application
54
Communications Webpage
55
Roadmap

• Introduction
• Presence
• Location-based services
• Server scaling
• P2P SIP
• Standardization and interoperability

56
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

57
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
58
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
59
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
60
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

61
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
62
Roadmap

• Introduction
• Presence
• Location-based services
• Server scaling
• P2P SIP
• Standardization and interoperability

63
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
64
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

65
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

66
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
67
z2z Zeroconf-to-Zeroconf interconnection
rendezvous point - OpenDHT
Import/export services
Import/export services


z2z
z2z
Zeroconf subnet A
Zeroconf subnet B
68
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

69
How z2z works (exporting)
70
How z2z works (importing)
71
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

72
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

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

74
Peer-to-Peer Protocol (P2PP)

• Salman Abdul Baset, Henning Schulzrinne
• Columbia University

75
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

76
Practical issues in peer-to-peer systems

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

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

79
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
80
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

81
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
82
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
83
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)

84
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
85
Chord (Strict routing-table management)
idx
Neighbor table(successor)
Routing table
x2i
x2i1
x2i2
x2i3
Immediately succeeds routing-table id
Node
86
Peer-to-Peer Protocol (P2PP)

• A 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)

87
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

88
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
89
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
90
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

91
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
92
Screen snapshot

• Alice and Bob are part of Kademlia network
• Alice calls Bob
• The lookup is performed using P2PP
• Call is established using SIP

93
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

94
Roadmap

• Introduction
• Presence
• Location-based services
• Server scaling
• P2P SIP
• Standardization and interoperability

95
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
96
RFC publication
97
IETF WG SIP in 2006 2007

• 44 SIP-related RFCs published in 2006
• BFCP, conferencing
• SDP revision
• rich presence
• Activities
• hitchhikers guide
• infrastructure
• GRUUs (random identifiers)
• URI lists
• XCAP configuration
• SIP MIB
• services
• rejecting anonymous requests
• consent framework
• location conveyance
• session policy

• security
• end-to-middle security
• certificates
• SAML
• sips clarification
• NAT
• connection re-use
• SIP outbound
• ICE (in MMUSIC)

see http//tools.ietf.org/wg/sip/
98
IETF WG SIPPING

• 31 RFCs published in 2006
• Policy
• media policy
• SBC functions
• Services
• service examples
• call transfer
• configuration framework
• spam and spit
• text-over-IP
• transcoding

• Testing and operations
• IPv6 transition
• race condition examples
• IPv6 torture tests
• SIP offer-answer examples
• overload requirements
• configuration
• voice quality reporting

99
Interoperability
SIPREAL BOF at IETF 70?

• Generally no interoperability problems for basic
  SIP functionality
• basic call, digest registration (mostly...), call
  transfer, voice mail
• Weaker in advanced scenarios and backward
  compatibility
• handling TCP, TLS
• NAT support (symmetric RTP, ICE, STUN, ...)
• multipart bodies
• SIP torture tests
• call transfer, call pick-up
• video and voice codec interoperability (H.264,
  anything beyond G.711)
• SIPit useful, but no equivalent of WiFi
  certification
• most implementations still single-vendor
  (enterprise, carrier) or vendor-supplied (VSP)
• SFTF (test framework) still limited
• Need profiles to guide implementers

100
Trouble in Standards Land

• Proliferation of transition standards 2.5G,
  2.6G, 3.5G,
• true even for emergency calling
• Splintering of standardization efforts across
  SDOs
• primary
• IEEE, IETF, W3C, OASIS, ISO
• architectural
• PacketCable, ETSI, 3GPP, 3GPP2, OMA, UMA, ATIS,
• specialized
• NENA
• operational, marketing
• SIP Forum, IPCC,

OASIS
data formats
W3C ISO (MPEG)
data exchange
IETF
L2.5-L7 protocols
IEEE
L1-L2
PacketCable
3GPP
101
IETF issues

• SIP WGs small number (dozen?) of core authors
  (80/20)
• some now becoming managers
• or moving to other topics
• IETF research ? engineering ? maintenance
• many groups are essentially maintaining standards
  written a decade (or two) ago
• DNS, IPv4, IPv6, BGP, DHCP RTP, SIP, RTSP
• constrained by design choices made long ago
• often dealing with transition to hostile
  random network
• network ossification

• Stale IETF leadership
• often from core equipment vendors, not software
  vendors or carriers
• fair amount of not-invented-here syndrome
• late to recognize wide usage of XML and web
  standards
• late to deal with NATs
• security tends to be per-protocol (silo)
• some efforts such as SAML and SASL
• tendency to re-invent the wheel in each group

102
IETF issue timeliness

• Most drafts spend lots of time in 90-complete
  state
• lack of energy (moved on to new -00)
• optimizers vs. satisfiers
• multiple choices that have non-commensurate
  trade-offs
• Notorious examples
• SIP request history Feb. 2002 May 2005 (RFC
  4244)
• Session timers Feb. 1999 May 2005 (RFC 4028)
• Resource priority Feb. 2001 Feb 2006 (RFC
  4412)
• New framework/requirements phase adds 1-2 years
  of delay
• Three bursts of activity/year, with silence
  in-between
• occasional interim meetings

• IETF meetings are often not productive
• most topics gets 5-10 minutes ? lack context,
  focus on minutiae
• no background ? same people as on mailing list
• 5 people discuss, 195 people read email
• No formal issue tracking
• some WGs use tools, haphazardly
• Gets worse over time
• dependencies increase, sometimes undiscovered
• backwards compatibility issues
• more background needed to contribute

103
IETF issues timeliness

• WG chairs run meetings, but are not managing WG
  progress
• very little control of deadlines
• e.g., all SIMPLE deadlines are probably a year
  behind
• little push to come to working group last call
  (WGLC)
• limited timeliness accountability of authors and
  editors
• chairs often provide limited editorial feedback
• IESG review can get stuck in long feedback loop
• author AD WG chairs
• sometimes lack of accountability (AD-authored
  documents)
• RFC editor often takes 6 months to process
  document
• dependencies IANA editor queue author delays
• e.g., session timer Aug. 2004 May 2005

104
Conclusion

• Even after 10 years, VoIP mostly still cheaper
  calls
• New services and models
• (rich) presence
• location-based services
• user-programmable services
• P2P SIP
• Scaling to carrier-scale and under duress
• Current standardization processes slow and
  complexity-inducing