VoIP - beyond replicating the limitations of the past - PowerPoint PPT Presentation

Loading...

PPT – VoIP - beyond replicating the limitations of the past PowerPoint presentation | free to download - id: 69ba15-NWUyY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

VoIP - beyond replicating the limitations of the past

Description:

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 ... – PowerPoint PPT presentation

Number of Views:33
Avg rating:3.0/5.0
Slides: 92
Provided by: HenningSc7
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
  • IIT VoIP Conference and Expo
  • Wheaton, Illinois
  • October 25, 2007

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

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

31
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

32
Location delivery
GPS
HELD
HTTP
wire map
DHCP
LLDP-MED
33
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
34
Program location-based services
35
(No Transcript)
36
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
37
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

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

39
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
40
SABIT PALS Supervisor Application
41
Communications Webpage
42
Roadmap
  • Introduction
  • Presence
  • Location-based services
  • Server scaling
  • P2P SIP
  • Standardization and interoperability

43
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

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

48
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
49
Roadmap
  • Introduction
  • Presence
  • Location-based services
  • Server scaling
  • P2P SIP
  • Standardization and interoperability

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

52
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

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


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

56
How z2z works (exporting)
57
How z2z works (importing)
58
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

59
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

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

61
Peer-to-Peer Protocol (P2PP)
  • Salman Abdul Baset, Henning Schulzrinne
  • Columbia University

62
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

63
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

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

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

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

71
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
72
Chord (Strict routing-table management)
idx
Neighbor table(successor)
Routing table
x2i
x2i1
x2i2
x2i3
Immediately succeeds routing-table id
Node
73
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)

74
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

75
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
76
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
77
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

78
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
79
Screen snapshot
  • Alice and Bob are part of Kademlia network
  • Alice calls Bob
  • The lookup is performed using P2PP
  • Call is established using SIP

80
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

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

82
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
83
RFC publication
84
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/
85
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

86
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

87
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
88
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

89
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

90
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

91
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
About PowerShow.com