VoIP%20-%20Moving%20from%20protocols%20to%20architecture(s)

About This Presentation

Title:

VoIP%20-%20Moving%20from%20protocols%20to%20architecture(s)

Description:

allows direct routing of latency-sensitive media packets (10 ms matters) without constraining service delivery (1s matters) facilitates mobility ... – PowerPoint PPT presentation

Number of Views:118

Avg rating:3.0/5.0

Slides: 106

Provided by: csCol

Learn more at: http://www.cs.columbia.edu

Category:

more less

Transcript and Presenter's Notes

Title: VoIP%20-%20Moving%20from%20protocols%20to%20architecture(s)

1
VoIP - Moving from protocols to architecture(s)

Henning Schulzrinne
Dept. of Computer Science
Columbia University
January 2006

2
Overview

The big transitions in VoIP
An Internet protocol framework
Open issues in VoIP and interactive multimedia
communications
service creation
VoIP poll model ? presence model
SIP architecture and design philosophy
Philosophies Skype, IETF, NGS,
Reflections on standardization
Integration of cellular and IP end systems

3
Philosophy transition
PC era cell phone era
One computer/phone, many users
One computer/phone, one user
mainframe era home phone party line
Many computers/phones, one user
ubiquitous computing
anywhere, any time any media
right place (device), right time, right media
4
Evolution of VoIP
how can I make it stop ringing?
does it do call transfer?
long-distance calling, ca. 1930
going beyond the black phone
amazing the phone rings
catching up with the digital PBX
1996-2000
2000-2003
2004-
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
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
7
Filling in the protocol gap
Service/delivery synchronous asynchronous
push SIP RTSP, RTP SMTP
pull HTTP ftp SunRPC, Corba, SOAP (not yet standardized)
8
A constellation of SIP RFCs
Non-adjacent (3327) Symmetric resp.
(3581) Service route (3608) User agent caps
(3840) Caller prefs (3841)
Request routing
Resource mgt. (3312) Reliable prov. (3262) INFO
(2976) UPDATE (3311) Reason (3326)
SIP (3261) DNS for SIP (3263) Events (3265) REFER
(3515)
ISUP (3204) sipfrag (3240)
Mostly PSTN
Core
Content types
Digest AKA (3310) Privacy (3323) P-Asserted
(3325) Agreement (3329) Media auth. (3313) AES
(3853)
DHCP (3361) DHCPv6 (3319)
Configuration
Security privacy
9
An eco system, not just a protocol
configures
XCAP (config)
SIMPLE policy RPID .
XCON (conferencing)
initiates
carries
SIP
RTSP
SDP
carries
controls
provide addresses
STUN TURN
RTP
10
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
11
RFC publication
12
SIP a bi-cultural protocol

multimedia
IM and presence
location-based service
user-created services
decentralized operation
everyone equally suspect

overlap dialing
DTMF carriage
key systems
notion of lines
per-minute billing
early media
ISUP BICC interoperation
trusted service providers

13
SIP design objectives

new features and services
support features not available in PSTN
e.g., presence and IM, session mobility
not a PSTN replacement
not just SS7-over-IP
even similar services use different models (e.g.,
call transfer)
client heterogeneity
clients can be smart or dumb (terminal adapter)
mobile or stationary
hardware or software
client multiplicity
one user multiple clients one address
multimedia
nothing in SIP assumes a particular media type

Rosenberg/Schulzrinne draft-rosenberg-sipping-sip
-arch-00
14
SIP architectural principles (1)

proxies are for routing
do not maintain call state
availability
scalability
flexibility
extensibility (new methods, services)
end point call state and features
dialog models, not call models
does not standardize features

endpoint fate sharing
call fails only if endpoints fail
component-based design
building blocks
call features notification and manipulation
logical components, not physical
UA, proxy, registrar, redirect server
can be combined into one box

Rosenberg/Schulzrinne draft-rosenberg-sipping-sip
-arch-00
15
SIP architectural principles (2)

designed for the (large) Internet
does not assume particular network topology
congestion-controlled
deals with packet loss
uses core Internet services
DNS for load balancing
DHCP for configuration
S/MIME for e2e security
TLS for channel security

generality over efficiency
focuses on algorithm efficiency, not
constant-factor encoding efficiency
efficiency penalty is temporary, generality is
permanent
text encoding
extensibility
use shim layer for compression where needed
allow splitting of functionality for scaling

16
SIP architectural principles (3)

separation of signaling and media
path followed by media packets independent of
signaling path
allows direct routing of latency-sensitive media
packets (10 ms matters)
without constraining service delivery (1s
matters)
facilitates mobility
avoid hair pinning, tromboning
facilitates vertical split between ISP and VSP

17
SIP design principles (1)

Proxies are method, body and header independent
does not depend on method
except CANCEL, ACK
can add new methods without upgrading proxies
primarily rely on URI, Via, Route and
Record-Route header fields
extensions Accept-Contact and Request-Disposition
may use anything to guide routing decision

Full-state nature of INVITE
each (re)INVITE contains full session state
facilitates MIDCOM-style interactions
allows session transfer
SIP URIs identify resources
can be device instance, service, person
but cannot tell from URI which (good!)
can specify services and service parameters

18
SIP design principles (2)

Extensibility and compatibility
can define new methods, header fields, body
types, parameters
supported by OPTIONS, Accept, Accept-Language,
Allow, Supported, Require, Proxy-Require,
Accept-Encoding and Unsupported
asking permission
OPTIONS, dialog establishment
asking forgiveness
use extension without asking
(Proxy)-Require please reject if you dont
understand it
use if you like
allow recipients to safely ignore information
must provide fallback!

Internationalization
UTF-8 for freeform text
negotiation of languages
Explicit intermediaries
SIP proxies
unlike transparent HTTP proxies or NAT boxes,
announce themselves
Via, Record-Route
only involved if asked by UA or proxy
should ask endpoints, rather than just do
e.g., session policy

19
SIP design principles (3)

Guided proxy routing
predetermine a set of downstream proxy resource
that must be visited
supported by Record-Route, Path, Service-Route
Transport protocol independence
can use UDP, TCP, SCTP,
only requires packet-based (unreliable) delivery
design decision that comes with some regret ?

Protocol reuse
MIME for body transport
S/MIME for end-to-end security
HTTP header field and semantics
HTTP digest authentication
URI framework
non-SIP URIs (e.g., tel)
re-use TLS for channel security
use DNS SRV and NAPTR for server failover and
reliability

20
SIP division of labor
proxy B2BUA UA
State stateless transaction-stateful call stateful call stateful
Headers inspect insert modify (rarely) inspect insert modify inspect reflect
Bodies ignore some inspect inspect insert modify inspect
Fork yes separate call legs no
Media no maybe yes
Services rendezvous call routing call stateful media-related
21
UMTS Reference Architecture
by Kimmo Raatikainen
22
3G Architecture (Registration)
describes deployment architecture
mobility management
signaling
serving
interrogating
interrogating
CSCF
proxy
home IM domain
registration signaling (SIP)_
visited IM domain
23
Classical IETF interfaces
UNI
NNI
router proxy server
SIP
SIP
signaling
DNS
DNS
name mapping
host end system UA
DHCP, PPP
BGP OSPF
L3 config
IPv4/IPv6
IPv4/IPv6
L3
Ethernet
SONET
L2
24
IETF interface approach

Essentially, only two types of entities
end systems (user agents, hosts, clients, )
network systems (proxies, routers, servers, )
No functional definitions or assumptions
SIP UA can be PSTN gateway or cell phone
(Mostly) strong separation of layers
IP-layer interface can change without SIP
changing
Can replace routing protocol without affecting
HTTP
Function defined by protocol actions
not general behavior (gateway)
Does not describe functional entities as such
web server SIP UAC router

25
IP hourglass
email WWW phone... SMTP HTTP RTP... TCP
UDP IP ethernet PPP CSMA async
sonet... copper fiber radio...
Steve Deering, IETF Aug. 2001
26
The real Internet hourglass (slightly simplified)
p2p (port 80)
web
web services
HTTP
TCP
IP
Ethernet
27
Interconnection approaches
Property NGN, 3GPP Internet
interconnection per service service neutral
end device control carrier-controlled user-provided
end device type mostly hardware software, maybe hardware
state preference call state-full stateless transaction-stateful
interconnect arrangement pre-arranged serendipitous
interconnect discovery pre-configured DNS
billing preference per service usage-based bandwidth-based services fixed-rate or ad-supported
billing arrangement clearing house sender keeps independent
28
IETF 4G (access-neutral) model
Check reputation of columbia.edu
sipalice_at_columbia.edu ? sipbob_at_example.com
TLS
columbia.edu
example.com
Visited network
NSIS NTLP for QoS
802.1x
DIAMETER server
AP
alice_at_isp.net
isp.net
29
Session Border Controllers (SBCs)

Provider border element
SIP terms either B2BUA or proxies
but often ill-defined (may change roles)
Functions differ
similar definitional problem as soft switches
May force convergence of media and signaling path

30
SBCs High-level motivations

Why application-layer elements in SIP that are
not quite proxies?
SMTP has various MTAs, but they are just MTAs
(e.g., spam filter)
Guesses
media vs. control separation
good idea in theory, harder in todays
limited-functionality Internet
force media through single control point (IP
address)
rather than from millions of sources
see Asterix, Skype
proxy model of no content (SDP) inspection or
modification too limited
CALEA (needs to be invisible)
charging for services
not an issue for email and web

31
SBC functionality, contd

Signaling functionality
Protocol Conversion H.323 ?? SIP
Protocol integrity - SIP normalization
ENUM SIP redirect
Policy enforcement and access control
CDR creation
Firewall (dest. port, source)
Least-cost routing
Certificate handling
Caller-ID authorization
Signaling encryption
S/MIME encapsulation
TCP/UDP-TLS bridging
DoS attack mitigation

Media functionality
Codec conversion
SLA enforcement
Legal Intercept CALEA compliance
Bandwidth Management
Packet marking
QoS guarantees
Packet steering
Media encryption
Firewall (pinholes)
DoS attack mitigation

32
SBC Network evolution
stand-alone networks (Vonage, Skype)
media
earlier email, IM
SBC
only IP-level (with filter)
33
SBC Concerns

Common concerns
may drop some header fields
may fail to understand some request methods
may modify headers inserted by others
may modify session descriptions
may inspect session descriptions
Not all SBCs do this all the time, but some do
some of this sometimes

34
SBC The dangers

May not be present in all instances
SBCs are a box description, not a function
description
Lack of visibility
cannot tell where SBC is located
hard to diagnose failures
see HTTP transparent proxy experience
one example TP thought SIP was HTTP
hard to address content cryptographically to such
box
Lack of transparency
not all features make it through SBC
header support
copying content
routing loops

Lack of security
Inherent conflict between need for media session
inspection and session privacy
Session description modification removes
accountability
Lack of scalability
needs to handle all media packets
often, call stateful
rather than stateless or transaction-stateful

35
Whats left to do?

Transition from poll model to context-based
communications
Higher-level service creation in end systems
Dealing with NATs
STUN (and SIP modifications) as first step
ICE and BEHAVE WG as longer-term solutions
The role of intermediaries
session-border controllers
end-to-middle security
session policies
Conference control
Application sharing
Security issues (spam, spit --gt identity and
reputation management)

36
P2P for autonomic computing

Autonomic at the application layer
Robust against partial network faults
Resources grow as user population grows
Self-configuring
Traditional p2p systems
file storage
motivation is often legal, not technical,
efficiency
usually unstructured, optimized for Zipf-like
popularity
Other p2p applications
Skype demonstrates usefulness for VoIP ?
identifier lookup
NAT traversal media traversal
OpenDHT (and similar) as emerging common
infrastructure?
Non-DHT systems with smaller scope ? web hotspot
rescue
Network management (see our IRTF slides)

37
What is SIP? Why P2P-SIP?
(1) REGISTER alice_at_columbia.edu
gt128.59.19.194
(2) INVITE alice_at_columbia.edu
(3) Contact 128.59.19.194
Alices host 128.59.19.194
Bobs host
columbia.edu
Problem in client-server maintenance,
configuration, controlled infrastructure
38
How to combine SIP P2P?

P2P-over-SIP
Additionally, implement P2P using SIP messaging

SIP-using-P2P
Replace SIP location service by a P2P protocol

SIP-using-P2P P2P SIP proxies P2P-over-SIP
Maintenance P2P P2P SIP
Lookup P2P SIP SIP
P2P network
REGISTER
INVITE alice
FIND
INSERT
P2P-SIP overlay
Alice 128.59.19.194
INVITE sipalice_at_128.59.19.194
Alice 128.59.19.194
39
Deployment scenarios
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P2P database
P2P proxies
P2P clients
Zero-conf server farm Trusted servers and user
identities
Global, e.g., OpenDHT Clients or proxies can
use Trusted deployed peers (?)
Plug and play May use adaptors Untrusted peers
Interoperate among these!
40
Hybrid architecture

Cross register, or
Locate during call setup
DNS, or
P2P-SIP hierarchy

41
What else can be P2P?

Rendezvous/signaling (SIP)
Configuration storage
Media storage (e.g., voice mail)
Identity assertion (?)
PSTN gateway (?)
NAT/media relay (find best one)

Trust models are different for different
components!
42
What is our P2P-SIP?

Unlike server-based SIP architecture
Unlike proprietary Skype architecture
Robust and efficient lookup using DHT
Interoperability
DHT algorithm uses SIP communication
Hybrid architecture
Lookup in SIPP2P
Unlike file-sharing applications
Data storage, caching, delay, reliability
Disadvantages
Lookup delay and security

43
Implementation SIPpeer

Platform Unix (Linux), C
Modes
Chord using SIP for P2P maintenance
OpenDHT using external P2P data storage
Scenarios
P2P client, P2P proxies
Adaptor for existing phones
Cisco, X-lite, Windows Messenger, SIPc
Server farm

44
Implementation SIPpeer
Signup, Find buddies
IM, call
On reset
Signout, transfer
On startup
Leave
Find
Join
REGISTER, INVITE, MESSAGE
Multicast REGISTER
Peer found/ Detect NAT
REGISTER
SIP-over-P2P
P2P-using-SIP
45
SIP p2p summary and open issues

Advantages
Out-of-box experience
Robust
catastrophic failure-unlikely
Inherently scalable
more with more nodes
Status
IETF involvement
Columbia SIPpeer

Security issues
Trust, reputation
malicious node, sybil attack
SPAM, DDoS
Privacy, anonymity (?)
Other issues
Lookup latency,proximity
P2P-SIP vs SIP-using-P2P
Why should I run as super-node?

http//www.p2psip.org and
http//www.cs.columbia.edu/IRT/p2p-sip
46
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
47
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
48
The role of presence

Is the callee likely to be reachable? ?
user-level presence
glue logic for loosely-coupled systems
events related to calls
voicemail notification
call transfer notification
Events are a superset of presence
publish, subscribe notify
in SIMPLE, just differ in their
event type and bodies (typically, XML)
privacy policies
unlike other event systems, cross-domain, with
security
but no content-dependent replication (Siena,
Elvin, )

49
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?
note may not be continuous subscription, but
rather on-demand (when trying to reach somebody)
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

50
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
51
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
52
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
53
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
54
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
55
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, )

56
Privacy policy relationships
common policy
geopriv-specific
presence-specific
future
RPID
CIPID
57
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

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

60
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

61
Presence Composition

composition combines multiple presence or event
sources into one view
remove information stale, contradictory,
redundant
create new information (e.g., new composite
services)
Tries to resolve information conflicts
update diligence, multiple devices in different
places, no sensor data,
Focus on PIDF/RPID, but probably applicable to
other event sources
Depends on presentity, but not on watcher
i.e., provides maximum information set for later
stages

62
Sources of presence data

Reported current
added manually a brief time ago
assumed correct when entered, but decays
Reported scheduled
from a calendar
Measured device information
communication status
Measured by sensors
location, type of location, activity,
sensors GPS, acceleration sensors, PIRs, ...
Derived
from other presence data

63
Composition steps
source
discard closed old
resolve ambiguities
source
union with replacement
combine identical contacts

Working on policy language that describes desired
composition policy
Complicated policies will require real languages

64
Service creation

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

programmer, carrier end user
network servers SIP servlets, sip-cgi CPL
end system VoiceXML VoiceXML (voice), LESS
65
Automating media interaction service examples

If call from my boss, turn off the stereo ? call
handling with device control
As soon as Tom is online, call him ? call
handling with presence information
Vibrate instead of ring when I am in movie
theatre ? call handling with location information
At 900AM on 09/01/2005, find the multicast
session titled ABC keynote and invite all the
group members to watch ? call handling with
session information
When incoming call is rejected, send email to the
callee ? call handling with email

66
LESS simplicity

Generality (few and simple concepts)
Uniformity (few and simple rules)
Trigger rule
Switch rule
Action rule
Modifier rule
Familiarity (easy for user to understand)
Analyzability (simple to analyze)

modifiers
switches
trigger
actions
67
LESS Decision tree

No loops
Limited variables
Not necessarily
Turing-complete

68
LESS Safety

Type safety
Strong typing in XML schema
Static type checking
Control flow safety
No loop and recursion
One trigger appear only once, no feature
interaction for a defined script
Memory access
No direct memory access
LESS engine safety
Ensure safe resource usage
Easy safety checking
Any valid LESS scripts can be converted into
graphical representation of decision trees.

69
LESS snapshot
incoming call
ltlessgt ltincominggt ltaddress-switchgt
ltaddress issipmyboss_at_abc.com"gt
ltdeviceturnoff devicesipstereo_room
1_at_abc.com/gt ltmedia mediaaudiogt
ltaccept/gt lt/mediagt lt/addressgt
lt/address-switchgt lt/incominggt lt/lessgt
If the call from my boss
Turn off the stereo
Accept the call with only audio
trigger, switch, modifier, action
70
LESS packages

Use packages to group elements

email
web
im
conference
calendar
location
session
71
When Tom is online,

ltlessgt
ltEVENTnotificationgt
ltaddress-switchgt
ltaddress is"siptom_at_example.com"gt
ltEVENTevent-switchgt
ltEVENTevent is"open"gt
ltlocation url"siptom_at_example.com"gt
ltIMim message"Hi, Tom"/gt
lt/locationgt
lt/EVENTeventgt
lt/EVENTevent-switchgt
lt/lessgt

72
When I am in a movie theatre,

ltlessgt
ltincominggt
ltlocation-switchgt
ltlocation placetypequietgt
ltalert soundnone vibrateyes/gt
lt/locationgt
lt/location-switchgt
lt/incominggt
lt/lessgt

73
(No Transcript)
74
XCON System
75
Conference control

IETF XCON WG struggling with model and complexity
Web services?
Specialized (binary) protocol?
API or document modification?
Inheritance model blue prints and templates

76
Open issues application sharing

Current T.120
doesnt integrate well with other conference
control mechanisms
hard to make work across platforms (fonts)
ill-defined security mechanisms
Current web-based sharing
hard to integrate with other media, control and
record
generally only works for Windows
mostly limited to shared PowerPoint
Current vnc
whole-screen sharing only
can be coerced into conferencing, but doesnt
integrate well with control protocols

77
IETF effort standardized application sharing

Remote access application sharing
Four components
window drawing ops ? PNG
keyboard input
mouse input
window operations (raise, lower, move)
Uses RTP as transport
synchronization with continuous media
but typically, TCP
allow multicast ? large group sessions

78
Spam and spit
79
SIP unsolicited calls and messages

Possibly at least as large a problem
more annoying (ring, pop-up)
Bayesian content filtering unlikely to work
? identity-based filtering
PKI for every user unrealistic
Use two-stage authentication
SIP identity work

mutual PK authentication (TLS)
home.com
Digest
80
Domain Classification

Classification of domains based on their identity
instantiation and maintenance procedures plus
other domain policies.
Admission controlled domains
Strict identity instantiation with long term
relationships
Example Employees, students, bank customers
Bonded domains
Membership possible only through posting of bonds
tied to a expected behavior
Membership domains
No personal verification of new members but
verifiable identification required such as a
valid credit card and/or payment
Example E-bay, phone and data carriers
Open domains
No limit or background check on identity creation
and usage
Example Hotmail
Open, rate limited domains
Open but limits the number of messages per time
unit and prevents account creation by bots
Example Yahoo

81
Reputation service
David
Carol
has sent IM to
has sent email to
Frank
Emily
is this a spammer?
Bob
Alice
82
SIP standards deployment issues and competition

Interoperability
Proprietary systems

83
Provider combinations
Cisco CM
Skype
software
hardware
mobile operators?
cable DSL op
ISP IAP
VSP
84
Protocol interoperability problems

Three core interoperability problems
syntactic robustness
You mean you could have a space there?
often occurs when testing only against common
reference implementations
need stress test (also for buffer overflows)
implementation by protocol example
limiting assumptions (e.g., user name format)
see SIP Robustness Testing for Large-Scale Use,
First International Workshop on Software Quality
(SOQA)
semantic assumptions
I didnt expect this error
mutually incompatible extensions
expect extension to make something work

85
Protocol interoperability proprietary protocols

Proprietary protocol
Example Skype
quicker evolution not dependent on IETF
volunteers with day jobs
can do hacks without IESG objection
media over TCP
inefficient search
bypass routing policies
circumvent firewall policies
Can only reverse-engineer ? only
backwards-compatibility problems
incentive to force upgrades (see Microsoft Word)
less Metcalfes law value

86
Why is Skype successful?

All the advantages of a proprietary protocol
Peer-to-peer coincidental
Good out-of-box experience
Software vendor service provider
Didnt know that you couldnt do voice quality
beyond PSTN
others too focused on PSTN interoperability why
do better voice than PSTN?
Simpler solutions for NAT traversal
use TCP if necessary
use port 80
Did encryption from the very beginning
Kazaa marketing vehicle

87
Skype vs. SIP-based systems
Skype SIP-based providers
Protocol proprietary, encrypted SIP to gateways open (SIP), often plain-text sometimes IAX to gateway
Business model prepaid outbound PSTN calls (SkypeOut) monthly fee (Vonage) free (FWD) prepaid (SIPgate.de)
Protocol model single network, bridge to PSTN some closed some semi-open (-codes)
Allow federation? not currently yes
NAT traversal integrated separated (STUN)
User agent software only (USB phones) software and hardware primarily market hardware
User interface presence-like phone-like
88
Open standard, dominant vendor

Example H.323
doesnt matter what the standard says
NetMeeting and H.323 ? test with Microsoft
implementation
limits feature evolution to dominant vendor speed
and interests

89
Open standard, multiple vendors

Example SIP
More than just one application
Software UAs, proxies, phones, gateways, media
servers, test tools, OAM,
interoperability problems likely until product
maturity
harder to test internally against all (competing)
products
divergent views and communities in IETF and other
SDOs
likely have to support union of requirements
emphasis on extensibility, modularity and
protocol re-use
? temptation to not implement everything
security
SIP generality over efficiency
better long-term outcome, but slower

90
Why SIP extensions?

Good interoperability in basic call setup
Extensions are sometimes indications where work
is needed
or I didnt know this existed
unfortunately, no good SIP Roadmap document
some wrong protocol, buddy
some I dont have the resources to participate
in standardization
currently, 68 SIP/SIPPING/SIMPLE I-Ds
26 SIP RFCs ( 13 SIPPING RFCs)

91
SIP proprietary extensions

Examples based on informal email survey
Shared line support to emulate key systems
not dialogs, but state of AORs
see SIMPLE
TCAP over SIP
for LNP
general pick up information along the way
Auto-answer support (intercom)

Caller-indicated ringing preferences
visual ringing
Billing and dialing plan
Tone for charged vs. free calls
Caller name identification added by proxies
P-Asserted-Identity extension
Call routing diagnostics

92
SIP proprietary extensions, contd

upgrade your endpoint!
Caller time zone
NAT support
STUN servers not widely available no incentive
some use simple HTTP query (just needs cgi-bin)
probably biggest advantage that Skype has
? many, make SIP work well in old world on phone
look-alikes
reason given
local interest only
takes too long to standardize

93
The SIP complexity fallacy

IAX (for example) is simpler than SIP
but you could build the IAX functionality in SIP
at just about the same complexity
no proxies
no codec negotiation
no distributed services
Difficulty extracting those simple pieces from
269 pages of specification ( SDP RTP) ?
SIP still more complex due to signaling-data
separation

IAX model
Signaling Media
Signaling Media
Signaling
Signaling
Media
SIP, H.323, MCGP model
94
Does it have to be that complicated?

highly technical parameters, with differing names
inconsistent conventions for user and realm
made worse by limited end systems (configure by
multi-tap)
usually fails with some cryptic error message and
no indication which parameter
out-of-box experience not good

95
Solving the configuration mess

Initial development assumed enterprise deployment
pre-configured via tftp or (rarely) DHCP
not suitable for residential use, except if box
is shipped
pathetic security password accessible to
anybody who knows MAC address of phone
Short term
adopt simple default conventions
should only need SIP URI (AoR), display name and
password
realm URI
outbound proxy domain
provide and expose error feedback
not authentication failure
but realm not recognized change to user_at_domain
format
use DNS NAPTR and SRV for STUN server

96
Solving the configuration mess longer term

IETF efforts on configuration management
retrieve via HTTP ( TLS)
change notification via SIP event notification
problem of configuring initial secret remains
probably need embedded public keys
Still need better diagnostics
one-way voice issues
authentication failures

97
VoIP end system configuration
registrar address STUN/TURN local and global
DNS
AOR
SIP SUBSCRIBE/NOTIFY
general configuration document (media, UI,
protocol behavior, )
DHCP
MAC address
geographical location (for 911) outbound proxy
thats all it should take
98
Problems in Standards Land