Transcript lucent - Computer Science, Columbia University

VoIP - Moving from
protocols to architecture(s)
Henning Schulzrinne
Dept. of Computer Science
Columbia University
January 2006
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
June 2005
2
Philosophy transition
One computer/phone,
many users
mainframe era
home phone
party line
PC era
cell phone era
One computer/phone,
one user
Many computers/phones,
one user
~ ubiquitous computing
anywhere,
any time
any media
June 2005
right place (device),
right time,
right media
3
Evolution of VoIP
“how can I make it
stop ringing?”
long-distance calling,
ca. 1930
“amazing – the
phone rings”
1996-2000
June 2005
“does it do
call transfer?”
going beyond
the black phone
catching up
with the digital PBX
2000-2003
20044
Collaboration in transition
inter-organization
multiple
technology
generations
diverse end points
intra-organization;
small number of
systems (meeting
rooms)
standards-based
solutions
proprietary (singlevendor) systems
June 2005
5
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
June 2005
6
Filling in the protocol gap
Service/delivery
synchronous
asynchronous
push
SIP
RTSP, RTP
SMTP
pull
HTTP
ftp
SunRPC, Corba, SOAP
(not yet standardized)
June 2005
7
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)
SIP (3261)
DNS for SIP (3263)
Events (3265)
REFER (3515)
ISUP (3204)
sipfrag (3240)
Content types
Reliable prov. (3262)
INFO (2976)
UPDATE (3311)
Reason (3326)
Mostly PSTN
Core
Digest AKA (3310)
Privacy (3323)
P-Asserted (3325)
Agreement (3329)
Media auth. (3313)
AES (3853)
June 2005
Security & privacy
DHCP (3361)
DHCPv6 (3319)
Configuration
8
An eco system, not just a
protocol
configures
XCAP
(config)
SIMPLE
XCON
(conferencing)
policy
RPID
….
initiates
SIP
RTSP
SDP
carries
provide addresses
controls
RTP
June 2005
carries
STUN
TURN
9
SIP, SIPPING & SIMPLE –00 drafts
70
60
50
40
SIP
SIPPING
SIMPLE
30
20
10
0
1999 2000 2001 2002 2003 2004 2005
includes draft-ietf-*-00 and draft-personal-*-00
June 2005
10
RFC publication
14
12
10
8
SIP
SIPPING
SIMPLE
6
4
2
0
2001
June 2005
2002
2003
2004
2005
11
SIP – a bi-cultural protocol
• overlap dialing
• DTMF carriage
• key systems
• notion of lines
• per-minute billing
• early media
• ISUP & BICC interoperation
• trusted service providers
June 2005
• multimedia
• IM and presence
• location-based service
• user-created services
• decentralized operation
• everyone equally suspect
12
SIP design objectives

new features and services



not a PSTN replacement





clients can be smart or dumb (terminal adapter)
mobile or stationary
hardware or software
client multiplicity


not just SS7-over-IP
even similar services use different models (e.g., call transfer)
client heterogeneity


support features not available in PSTN
e.g., presence and IM, session mobility
one user – multiple clients – one address
multimedia

nothing in SIP assumes a particular media type
Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00
June 2005
13
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


component-based
design



call fails only if endpoints
fail
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
June 2005
14
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






June 2005
focuses on algorithm
efficiency, not constantfactor 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
15
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)


facilitates mobility


without constraining service delivery (1s matters)
avoid “hair pinning”, “tromboning”
facilitates vertical split between ISP and VSP
June 2005
16
SIP design principles (1)

Proxies are method, body
and header independent




Full-state nature of INVITE

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: AcceptContact and RequestDisposition
may use anything to guide
routing decision
June 2005



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
17
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, AcceptEncoding and Unsupported
“asking permission”






UTF-8 for freeform text
negotiation of languages
Explicit intermediaries


= SIP proxies
unlike transparent HTTP proxies
or NAT boxes, announce
themselves

OPTIONS, dialog establishment

use extension without asking
(Proxy)-Require: “please reject
if you don’t understand it”

Via, Record-Route
only involved if asked by UA or
proxy
should ask endpoints, rather
than just do

e.g., session policy
“use if you like”


Internationalization
“asking forgiveness”



allow recipients to safely ignore
information
must provide fallback!
June 2005
18
SIP design principles (3)

Guided proxy routing



predetermine a set of
downstream proxy resource
that must be visited
supported by RecordRoute, Path, ServiceRoute
Transport protocol
independence



can use UDP, TCP, SCTP, …
only requires packet-based
(unreliable) delivery
design decision that comes
with some regret 
June 2005

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
19
SIP division of labor
proxy
B2BUA
UA
State
stateless
transactionstateful
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
June 2005
20
UMTS Reference Architecture
Alternative
Access
Network
Legacy mobile
signallingNetwork
Applications &
Services *)
SCP
R-SGW *)
Mw
Ms
Mh
CAP
TE
MT
R
Um
Iu
TE
R
Gb
Uu
Mr
Mg
MRF
Gi
Gc
Gi
MGCF
Gi
Gn
Iu
MGW
MGW
Nb
Iu
T-SGW *)
Mc
GGSN
SGSN
A
UTRAN
MT
Gf
Iu
CSCF
Gi
EIR
BSS/
GERAN
Mm
Cx
HSS *)
Gr
Multimedia
IP Networks
CSCF
Mc
PSTN/
Legacy/External
Mc
Nc
MSC server
GMSC server
T-SGW *)
CAP
CAP
Applications
& Services *)
Signalling
Interface
Signalling and Data Transfer
Interface
D
C
HSS *)
R-SGW *)
Mh
*) those elements are duplicated for figure
layout purpose only, they belong to the same
logical element in the reference model
by Kimmo Raatikainen
June 2005
21
3G Architecture (Registration)
describes
deployment
architecture
mobility management
signaling
serving
CSCF
interrogating
proxy
interrogating
home IM domain
registration signaling (SIP)_
visited IM domain
June 2005
22
Classical IETF interfaces
“UNI”
host
end system
UA
signaling
name
mapping
L3 config
L3
L2
June 2005
router
proxy
server
“NNI”
SIP
SIP
DNS
DNS
DHCP, PPP
BGP
OSPF
IPv4/IPv6
IPv4/IPv6
Ethernet
SONET
23
IETF interface approach

Essentially, only two types of entities



No functional definitions or assumptions



IP-layer interface can change without SIP changing
Can replace routing protocol without affecting HTTP
Function defined by protocol actions


SIP UA can be PSTN gateway or cell phone
(Mostly) strong separation of layers


end systems (user agents, hosts, clients, …)
network systems (proxies, routers, servers, …)
not general behavior (“gateway”)
Does not describe functional entities as such

web server + SIP UAC + router
June 2005
24
IP “hourglass”
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
June 2005
Steve Deering,
IETF Aug. 2001
25
The real Internet hourglass
(slightly simplified)
p2p (port 80)
web
web services
HTTP
TCP
IP
Ethernet
June 2005
26
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 adsupported
billing arrangement
clearing house
sender keeps
independent
June 2005
27
IETF “4G” (access-neutral) model
Check
reputation of
columbia.edu
sip:[email protected] 
sip:[email protected]
TLS
columbia.edu
example.com
Visited
network
NSIS NTLP
for QoS
802.1x
AP
DIAMETER
server
[email protected]
isp.net
June 2005
28
Session Border Controllers (SBCs)


Provider border element
SIP terms: either B2BUA or proxies


Functions differ


but often ill-defined (may change roles)
similar definitional problem as “soft
switches”
May force convergence of media and
signaling path
June 2005
29
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 today’s 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

June 2005
not an issue for email and web
30
SBC functionality, cont’d

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
June 2005

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
31
SBC: Network evolution
stand-alone networks
(Vonage, Skype)
media
earlier: email, IM
SBC
only IP-level
(with filter)
June 2005
32
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…
June 2005
33
SBC: The dangers

May not be present in all instances


SBCs are a box description, not a
function description
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

Lack of security

Lack of visibility



not all features make it through SBC
header support
copying content
routing loops

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

June 2005
rather than stateless or
transaction-stateful
34
What’s left to do?



Transition from “poll” model to context-based
communications
Higher-level service creation in end systems
Dealing with NATs



The role of intermediaries






STUN (and SIP modifications) as first step
ICE and BEHAVE WG as longer-term solutions
session-border controllers
end-to-middle security
session policies
Conference control
Application sharing
Security issues (spam, spit --> identity and
reputation management)
June 2005
35
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 





June 2005
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)
36
What is SIP? Why P2P-SIP?
(1) REGISTER
[email protected] =>128.59.19.194
(2) INVITE [email protected]
(3) Contact: 128.59.19.194
columbia.edu
Bob’s host
Alice’s host
128.59.19.194
Problem in client-server: maintenance, configuration, controlled infrastructure
(2) INVITE alice
(3) 128.59.19.194
Peer-to-peer network
(1) REGISTER
Alice
128.59.19.194
No central server, but more lookup latency
June 2005
37
How to combine SIP + P2P?

SIP-using-P2P

P2P-over-SIP

Replace SIP location
service by a P2P protocol

Additionally, implement P2P
using SIP messaging
SIP-using-P2P
P2P SIP proxies
P2P-over-SIP
Maintenance
P2P
P2P
SIP
Lookup
P2P
SIP
SIP
P2P network
FIND
INSERT
INVITE sip:[email protected]
INVITE alice
REGISTER
P2P-SIP
overlay
Alice
128.59.19.194
Alice
128.59.19.194
June 2005
38
Deployment scenarios
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P2P clients
Plug and play;
May use adaptors;
Untrusted peers
P2P proxies
Zero-conf server farm;
Trusted servers and
user identities
P2P database
Global, e.g., OpenDHT;
Clients or proxies can use;
Trusted deployed peers (?)
Interoperate among these!
June 2005
39
Hybrid architecture


Cross register, or
Locate during call
setup


June 2005
DNS, or
P2P-SIP hierarchy
40
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!
June 2005
41
What is our P2P-SIP?


Unlike server-based SIP architecture
Unlike proprietary Skype architecture


Robust and efficient lookup using DHT
Interoperability


Hybrid architecture


Lookup in SIP+P2P
Unlike file-sharing applications


DHT algorithm uses SIP communication
Data storage, caching, delay, reliability
Disadvantages

June 2005
Lookup delay and security
42
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


June 2005
Cisco, X-lite, Windows Messenger, SIPc
Server farm
43
Implementation: SIPpeer
User interface (buddy list, etc.)
On reset Signout,
transfer
On startup
Leave
Discover
Peer found/
Detect NAT
IM,
call
User location
Find
Join
DHT (Chord)
Multicast REGISTER
ICE
Signup,
Find buddies
REGISTER
Audio devices
REGISTER,
INVITE,
MESSAGE
SIP
Codecs
RTP/RTCP
SIP-over-P2P
P2P-using-SIP
June 2005
44
SIP p2p summary and open
issues

Advantages


Out-of-box
experience
Robust






catastrophic
failure-unlikely
Inherently
scalable
Security issues


Trust, reputation
malicious node,
sybil attack
SPAM, DDoS
Privacy, anonymity
(?)
Other issues
Lookup
latency,proximity
 P2P-SIP vs SIP Status
http://www.cs.columbia.edu/IRT/p2p-sip
45
using-P2P
June 2005
more with more
nodes
http://www.p2psip.org
and


The role of presence

Guess-and-ring

high probability of failure:




current solutions:



“telephone tag”
inappropriate time (call during
meeting)
inappropriate media (audio in
public place)
voice mail  tedious, doesn’t
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
June 2005
46
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
June 2005
47
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



unlike other event systems, cross-domain, with security

June 2005
event type and bodies (typically, XML)
privacy policies
but no content-dependent replication (Siena, Elvin, …)
48
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 ondemand (when trying to reach somebody)
Yahoo, MSN, Skype presence services:

on-line & off-line



useful in modem days – but many people are (technically) online 24x7
thus, need to provide more context
+ simple status (“not at my desk”)


June 2005
entered manually  rarely correct
does not provide enough context for directing interactive
communications
49
The role of presence for call
routing

Two modes:

watcher uses presence
information to select
suitable contacts


PUBLISH
advisory – caller may not
adhere to suggestions
and still call when you’re
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
translate
RPID
CPL
NOTIFY
LESS
INVITE
June 2005
50
GEOPRIV and SIMPLE
architectures
rule
maker
DHCP
XCAP
(rules)
publication
interface
target
presentity
caller
PUBLISH
INVITE
June 2005
location
server
presence
agent
notification
interface
location
recipient
GEOPRIV
watcher
SIP
presence
SUBSCRIBE
NOTIFY
INVITE
callee
SIP
call
51
Presence data architecture
presence sources
PUBLISH
create
view
(compose)
raw
presence
document
XCAP
select best source
resolve contradictions
composition
policy
(not defined yet)
June 2005
privacy
filtering
depends on watcher
XCAP
privacy
policy
draft-ietf-simple-presence-data-model
52
Presence data architecture
candidate
presence
document
remove data not of
interest
watcher
June 2005
watcher
filter
raw
presence
document
post-processing
composition
(merging)
SUBSCRIBE
difference
to previous notification
NOTIFY
final
presence
document
53
Presence data model
person
“calendar”
“cell”
“manual”
(presentity)
(views)
[email protected]
audio, video, text
services
[email protected]
video
devices
June 2005
54
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, …)
June 2005
55
Privacy policy relationships
common policy
geopriv-specific
presence-specific
RPID
June 2005
future
CIPID
56
Privacy rules

Conditions





Actions


identity, sphere
time of day
current location
identity as <uri> or
<domain> +
<except>
watcher confirmation
Transformations



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
include information
reduced accuracy
June 2005
57
<actions>
<conditions>
<transformations>
<ruleset>
Example rules document
<rule id=1>
<identity><id>[email protected]</id></identity>
<sub-handling>allow</sub-handling>
<provide-services>
<service-uri-scheme>sip</service-uri-scheme>
<service-uri-scheme>mailto</service-uri-scheme>
</provide-services>
<provide-person>true</provide-person>
<provide-activities>true</provide-activities>
<provide-user-input>bare</provide-user-input>
June 2005
58
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


configuration


devices in room adapt to their current users
awareness


incoming communications changes based on where I am
others are (selectively) made aware of my location
security

June 2005
proximity grants temporary access to local resources
59
Location-based SIP services

Location-aware inbound routing




outbound call 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 I’m in a theater
contact nearest emergency call center
send [email protected] 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
June 2005
60
Presence Composition

composition = combines multiple presence or event
sources into one view



Tries to resolve information conflicts



remove information: stale, contradictory, redundant
create new information (e.g., new composite services)
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
June 2005
61
Sources of presence data

Reported current



Reported scheduled


communication status
Measured by sensors



from a calendar
Measured device information


added manually a brief time ago
assumed correct when entered, but decays
location, type of location, activity, …
sensors = GPS, acceleration sensors, PIRs, ...
Derived

from other presence data
June 2005
62
Composition steps
discard
closed +
old
source
resolve
ambiguities
source
union with
replacement


combine
identical
contacts
Working on policy language that describes desired
composition policy
Complicated policies will require “real” languages
June 2005
63
Service creation



Tailor a shared infrastructure to individual users
traditionally, only vendors (and sometimes carriers)
learn from web models
end user
network
servers
programmer,
carrier
SIP servlets,
sip-cgi
end system
VoiceXML
VoiceXML (voice),
LESS
June 2005
CPL
64
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 9:00AM 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
June 2005
65
LESS: simplicity


Generality (few and simple concepts)
Uniformity (few and simple rules)






Trigger rule
Switch rule
Action rule
Modifier rule
modifiers
trigger
switches
actions
Familiarity (easy for user to understand)
Analyzability (simple to analyze)
June 2005
66
LESS: Decision tree
No loops
Limited variables
Not necessarily
Turing-complete
June 2005
67
LESS: Safety

Type safety



Control flow safety



No direct memory access
LESS engine safety


No loop and recursion
One trigger appear only once, no feature interaction for a defined
script
Memory access


Strong typing in XML schema
Static type checking
Ensure safe resource usage
Easy safety checking

Any valid LESS scripts can be converted into graphical
representation of decision trees.
June 2005
68
LESS snapshot
incoming call
<less>
If the call from my boss
<incoming>
<address-switch>
<address is=“sip:[email protected]">
Turn off the stereo
<device:turnoff
device=“sip:[email protected]”/>
<media media=“audio”>
<accept/>
Accept the call with only audio
</media>
</address>
</address-switch>
</incoming>
</less>
trigger, switch, modifier, action
June 2005
69
LESS packages
Use packages to group elements

SIP user agent
im
email
web
Presence presence
agent
Event
calendar conference
session
June 2005
location
SIP
Basic user agent
Generic Media UI
x10
vcr
Device agent
70
When Tom is online, …
<less>
<EVENT:notification>
<address-switch>
<address is="sip:[email protected]">
<EVENT:event-switch>
<EVENT:event is="open">
<location url="sip:[email protected]">
<IM:im message="Hi, Tom"/>
</location>
</EVENT:event>
</EVENT:event-switch>
………
</less>
June 2005
71
When I am in a movie theatre, …
<less>
<incoming>
<location-switch>
<location placetype=“quiet”>
<alert sound=“none” vibrate=“yes”/>
</location>
</location-switch>
</incoming>
</less>
June 2005
72
XCON System
Logical XCON Server
TEMPLATE
Of the SYSTEM:
TEMPLATE Policy:
•Of TYPE RULES
•Pre-configured
•Initial/Default values
RESERVATION
RESERVATION Policy:
Of the INSTANCE:
•Of TYPE RULES
•Of TYPE CONFERENCE-INFO
STATE
Of the CURRENT INSTANCE:
CURRENT Policy:
•Of TYPE RULES
CPCP
Server
CPCP
CPCP
Client
Logical
June
2005
•Of TYPE CONFERENCE-INFO
CCCP
Server
CCCP
CCCP
Client
XCON Client
Focus
SIP/
PSTN/
H.323
T.120/
Etc.
Call
Signaling
Client
Conf Event
Notification
Server
SIP NOTIFY/
Etc.
Notification
Client
Floor
Control
Server
BFCP
Floor
Control
Client
74
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
June 2005
75
Open issues: application sharing

Current: T.120




Current: web-based sharing




doesn’t integrate well with other conference control
mechanisms
hard to make work across platforms (fonts)
ill-defined security mechanisms
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 doesn’t integrate well
with control protocols
June 2005
76
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
June 2005
77
Spam and spit
June 2005
78
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

mutual
PK authentication (TLS)
Digest
home.com
SIP identity work
June 2005
79
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


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: Employees, students, bank customers
Example: Hotmail
Open, rate limited domains

Open but limits the number of messages per time unit and prevents account creation by
bots

June 2005
Example: Yahoo
80
Reputation service
Carol
has sent
IM to
David
has sent
email to
Emily
Frank
is this a spammer?
Alice
June 2005
Bob
81
SIP standards & deployment
issues and competition


Interoperability
Proprietary systems
June 2005
82
Provider combinations
Skype
software
ISP
IAP
June 2005
Cisco
CM
cable
DSL op
hardware
mobile
operators?
VSP
83
Protocol interoperability problems

Three core interoperability problems:

syntactic robustness

“You mean you could have a space there?”






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


often occurs when testing only against common reference
implementations
need “stress test” (also for buffer overflows)
“I didn’t expect this error”
mutually incompatible extensions

June 2005
expect extension to make something work
84
Protocol interoperability:
proprietary protocols

Proprietary protocol



Example: Skype
quicker evolution – not dependent on IETF
“volunteers” with day jobs
can do “hacks” without IESG objection:





Can only reverse-engineer  only backwardscompatibility problems


media over TCP
inefficient search
bypass routing policies
circumvent firewall policies
incentive to force upgrades (see Microsoft Word)
less Metcalfe’s law value
June 2005
85
Why is Skype successful?



All the advantages of a proprietary protocol
Peer-to-peer coincidental
Good out-of-box experience


Didn’t know that you couldn’t do voice quality beyond
PSTN




others too focused on PSTN interoperability – why do
better voice than PSTN?
Simpler solutions for NAT traversal


Software vendor = service provider
use TCP if necessary
use port 80
Did encryption from the very beginning
Kazaa marketing vehicle
June 2005
86
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
June 2005
87
Open standard, dominant
vendor




Example: H.323
doesn’t matter what the standard says
NetMeeting and H.323  test with
Microsoft implementation
limits feature evolution to dominant
vendor speed and interests
June 2005
88
Open standard, multiple
vendors





Example: SIP
More than just one application:

Software UAs, proxies, phones, gateways, media servers,
test tools, OA&M, …
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



June 2005
89
Why SIP extensions?


Good interoperability in basic call setup
Extensions are sometimes indications where
work is needed

or “I didn’t know this existed”





unfortunately, no good SIP Roadmap document
some “wrong protocol, buddy”
some “I don’t have the resources to participate in
standardization”
currently, 68 SIP/SIPPING/SIMPLE I-Ds
26 SIP RFCs (+ 13 SIPPING RFCs)
June 2005
90
SIP proprietary extensions


Examples based on
informal email survey
Shared line support to
emulate key systems:



TCAP over SIP



not dialogs, but state
of AORs
see SIMPLE
for LNP
general: pick up
information along the
way
Auto-answer support
(intercom)
June 2005

Caller-indicated ringing
preferences




Billing and dialing plan
Tone for charged vs.
free calls
Caller name
identification added by
proxies


visual ringing
P-Asserted-Identity
extension
Call routing diagnostics
91
SIP proprietary extensions, cont’d



“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
June 2005
92
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
Signaling & Media
Signaling
Media
SIP, H.323, MCGP model
June 2005
93
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
94
•June
out-of-box
experience not good
2005
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



provide and expose error feedback



realm = URI
outbound proxy = domain
not “authentication failure”
but “realm not recognized – change to user@domain format”
use DNS NAPTR and SRV for STUN server
June 2005
95
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
June 2005
96
VoIP end system configuration
DNS
AOR
SIP SUBSCRIBE/NOTIFY
MAC
address
DHCP
registrar address
STUN/TURN – local and global
general configuration document
(media, UI, protocol behavior, …)
geographical location (for 911)
outbound proxy
that’s all it
should take
June 2005
97
Problems in Standards Land

IEEE, IETF, W3C, OASIS, ISO
architectural:


W3C
ISO (MPEG)
primary:


OASIS
June 2005
data
exchange
IETF
L2.5-L7
protocols
IEEE
L1-L2
PacketCable, ETSI, 3GPP,
3GPP2, OMA, UMA, …
operational, marketing:

data
formats
SIP Forum, IPCC, …
PacketCable

Proliferation of transition
standards: 2.5G, 2.6G, 3.5G,
…
Splintering of standardization
efforts across SDOs
3GPP

98
IETF issues

SIP WGs: small number (dozen?) of core authors (80/20)


some now becoming managers…
IETF: research  engineering  maintenance

many groups are essentially maintaining standards written a
decade (or two) ago




often dealing with transition to hostile network
Stale IETF leadership


DNS, IPv4, IPv6, BGP, DHCP; RTP, SIP, RTSP
constrained by design choices made long ago
often from core equipment vendors, not software vendors
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
June 2005
99
IETF issue: timeliness

Most drafts spend lots of time in 90%-complete state


lack of energy (moved on to new -00)
optimizers vs. satisfiers


Notorious examples:





occasional interim meetings
IETF meetings are often not productive




SIP request history: Feb. 2002 – May 2005 (no RFC yet)
Session timers: Feb. 1999 – May 2005 (RFC 4028)
Resource priority: Feb. 2001 – now (LC)
New framework/requirements phase adds 1-2 years of delay
Three bursts of activity/year, with silence in-between


multiple choices that have non-commensurate trade-offs
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
June 2005
100
IETF issues: timeliness

WG chairs run meetings, but are not managing WG
progress

very little control of deadlines





little push to come to WGLC
limited timeliness accountability of authors and editors
chairs often provide limited editorial feedback
IESG review can get stuck in long feedback loop



e.g., all SIMPLE deadlines are probably a year behind
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
June 2005
101
Interworking VoIP -- Cellular


A whole separate talk
Options:

registration


integration -- cellular in charge



single tel/SIP URI; forward calls to mobile
access: UMA -- make look like GSM BSC
system: use VoIP as VLR or HLR
cellular as transport

June 2005
treat cellular as another access network
102
UMA* functional architecture
June 2005
*Unlicensed
Mobile Access
103
UMA signaling
June 2005
104
UMA GSM speech bearer architecture
June 2005
105
Conclusion

Slow transition from emulating PSTN to new services



Emphasis moving from protocol mechanics to
architecture




presence-based
embedded (e.g., games)
slow transition to open systems
different combinations of software vendors, IAP/ISP, VSP,
hardware vendors
Still need to fill out infrastructure for collaboration
and presence
Standardization bodies face challenges of overlap
and resource exhaustion
June 2005
106