VoIP beyond replicating the limitations of the past

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
  staff, as well as the IETF GEOPRIV and SIMPLE
  WGs)
• hgs_at_cs.columbia.edu
• Lucent-Alcatel
• Stuttgart
• January 31, 2008

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
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)
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
7
Old vs. new
8
Presence and event notification
9
Left to do glue protocols

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

10
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

11
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

12
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
13
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
14
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
15
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

16
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
17
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
18
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
19
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, )

20
RPID rich presence
21
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

22
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

23
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
24
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
25
Privacy policy relationships
common policy
geopriv-specific
presence-specific
future
RPID
CIPID
26
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

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

29
Location-based services
30
Location-based services
directions
indoor routing
car park assistance
traffic management
people vehicle tracking
emergency calls
Tracking
product tracking
Emergency
Navigation
automotive assistance
shopping guides
banners alerts
Advertising
travel tourist guides
location-based services
Information
mobile yellow pages
road tolling
Billing
travel planner
facility
Games
Infrastructure
geocaching
Management
Leisure
customer relationship
mobile games
fleet (scheduling)
Communications
buddy finder
instant messaging
location-aware call handling
security
environmental
Foundations of Location-based Services (Steinger,
Neun, Edwardes), modified)
31
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

32
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

33
Location determination options
34
Location delivery
GPS
HELD
HTTP
wire map
DHCP
LLDP-MED
35
Local Switch
Automatic Number Identification
Automatic Location Identification
Collaboration between local phone providers and
local public safety agencies
36
What makes VoIP 112/911 hard?
37
UA recognition UA resolution
location information
mapping
mapping may recurse
DHCP LLDP-MED
9-1-1 (dial string)
leonianj.gov
INVITE urnservicesos To urnservicesos Route
sipfire_at_leonianj.gov ltlocationgt
INVITE urnservicesos To urnservicesos Route
sippsap_at_leonianj.gov ltlocationgt
identification TBD
38
LoST Location-to-URL Mapping
VSP1
cluster serving VSP1
replicate root information
cluster serves VSP2
123 Broad Ave Leonia Bergen County NJ US
LoST
root nodes
NY US
NJ US
sippsap_at_leonianj.gov
search referral
Bergen County NJ US
Leonia NJ US
39
Program location-based services
40
(No Transcript)
41
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
42
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

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

44
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
45
SABIT PALS Supervisor Application
46
Communications Webpage
47
Roadmap

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

48
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

49
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
50
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
51
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
52
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

53
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
54
Roadmap

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

55
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
56
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

57
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

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


z2z
z2z
Zeroconf subnet A
Zeroconf subnet B
60
How z2z works (exporting)
61
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

62
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

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

64
Peer-to-Peer Protocol (P2PP)

• Salman Abdul Baset, Henning Schulzrinne
• Columbia University

65
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

66
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

67
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
68
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

69
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
70
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

71
DHTs
72
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
73
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)

74
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
75
Chord (Strict routing-table management)
idx
Neighbor table(successor)
Routing table
Immediately succeeds routing-table id
Node
76
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)

77
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

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

81
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
82
Screen snapshot

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

83
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

84
Roadmap

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

85
Issues for VoIP over WiFi
template-based compression
L7 (SIP)
personal service mobility
vertical hand-off (VCC)
cooperative roaming
pDAD
duplicate address detection
L3 (IP)
network attachment detection
caching
selective scanning
AP discovery
cooperative roaming
L2 (MAC)
L2 authentication authorization
DPCF
MAC for delay-sensitive traffic
APC
admission control
QP-CAT
IBIT
L1 (PHY)
fading
interference by other APs
86
Fast Layer 2 HandoffMeasurement Results
Handoff time
87
Passive DAD Overview
Address Usage Collector (AUC)
DHCP server
TCP Connection
Broadcast-ARP-DHCP
Router/Relay Agent
SUBNET

• AUC builds DUIDMAC pair table (DHCP traffic
  only)
• AUC builds IPMAC pair table (broadcast and ARP
  traffic)
• The AUC sends a packet to the DHCP server when
• a new pair IPMAC is added to the table
• a potential duplicate address has been detected
• a potential unauthorized IP has been detected
• DHCP server checks if the pair is correct or not
  and it records the IP address as in use. (DHCP
  has the final decision!)

88
Cooperative Roaming Measurement Results
89
Dynamic PCF (DPCF)Simulation Results
Delay and throughput of 28 VoIP traffic and data
traffic
3000
600
FTP Throughput
VoIP Throughput
VoIP Delay (90)
2500
500
2000
400
End-to-End Delay (ms)
Throughput (kb/s)
1500
300
1000
200
500
100
0
0
0
1
2
3
Number of Data Sessions
90
QP-CATBasic flow of QP-CAT
91
QP-CATSimulation results
16 calls 1 virtual call (predicted by QP-CAT)
17 calls 1 virtual call (predicted by QP-CAT)
17th call is admitted
16 calls (actual)
17 calls (actual)

• VoIP traffic with 34kb/s 20ms Packetization
  Interval

92
Template-based Compression Incoming INVITE
Compression
93
Roadmap

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

94
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
95
RFC publication
96
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/
97
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

98
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

99
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
100
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

101
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

102
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

103
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