SIP presence

1
SIP presence event notificationLocation-based
services

• 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

2
Outline

• VoIP maturing vision vs. reality
• presence
• location-based services
• VoIP challenges
• scaling
• peer-to-peer systems

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

4
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

5
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

6
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
7
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
8
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
9
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

10
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
11
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
12
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
13
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, )

14
RPID rich presence
15
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

16
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

17
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
18
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
19
Privacy policy relationships
common policy
geopriv-specific
presence-specific
future
RPID
CIPID
20
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

21
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
22
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

23
Location-based services
24
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

25
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

26
Location delivery
GPS
HELD
HTTP
wire map
DHCP
LLDP-MED
27
Location determination options
28
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
29
Program location-based services
30
(No Transcript)
31
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
32
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

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

34
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
35
SABIT PALS Supervisor Application
36
Communications Webpage
37
Roadmap

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

38
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

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

43
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
44
Roadmap

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

45
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
46
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

47
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

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


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

51
How z2z works (exporting)
52
How z2z works (importing)
53
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

54
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

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

56
Peer-to-Peer Protocol (P2PP)

• Salman Abdul Baset, Henning Schulzrinne
• Columbia University

57
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

58
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

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

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

63
DHTs
64
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
65
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)

66
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
67
Chord (Strict routing-table management)
idx
Neighbor table(successor)
Routing table
Immediately succeeds routing-table id
Node
68
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)

69
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

70
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
71
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
72
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

73
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
74
Screen snapshot

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

75
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