Post on 19-Jan-2018
description
VoIP - Moving from VoIP - Moving from protocols to protocols to architecture(s)architecture(s)
Henning SchulzrinneDept. of Computer Science
Columbia UniversityJanuary 2006
June 2005 2
OverviewOverview 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 3
Philosophy transitionPhilosophy transitionOne computer/phone,
many usersOne computer/phone,
one user
Many computers/phones,one user
anywhere,any time
any media
right place (device),right time,right media
~ ubiquitous computing
mainframe erahome phone
party line
PC eracell phone era
June 2005 4
Evolution of VoIPEvolution of VoIP
“amazing – thephone rings”
“does it docall transfer?”
“how can I make itstop ringing?”
1996-2000 2000-2003 2004-
catching upwith the digital PBX
long-distance calling,ca. 1930 going beyond
the black phone
June 2005 5
Collaboration in transitionCollaboration in transition
intra-organization;
small number of systems
(meeting rooms)
inter-organization
multiple technology generationsdiverse end
points
proprietary (single-vendor)
systems
standards-based solutions
June 2005 6
Internet services – the Internet services – the missing entrymissing entry
Service/delivery
synchronous asynchronous
push instant messagingpresenceevent notificationsession setupmedia-on-demand
messaging
pull data retrievalfile downloadremote procedure call
peer-to-peer file sharing
June 2005 7
Filling in the protocol gapFilling in the protocol gap
Service/delivery
synchronous asynchronous
push SIPRTSP, RTP
SMTP
pull HTTPftpSunRPC, Corba, SOAP
(not yet standardized)
June 2005 8
A constellation of SIP RFCsA constellation of SIP RFCs
Resource mgt. (3312)Reliable prov. (3262)INFO (2976)UPDATE (3311)Reason (3326)SIP (3261)
DNS for SIP (3263)Events (3265)REFER (3515)
DHCP (3361)DHCPv6 (3319)
Digest AKA (3310)Privacy (3323)P-Asserted (3325)Agreement (3329)Media auth. (3313)AES (3853)
Non-adjacent (3327)Symmetric resp. (3581)Service route (3608)User agent caps (3840)Caller prefs (3841)
ISUP (3204)sipfrag (3240)
Security & privacy
Configuration
Core
Mostly PSTN
Content types
Request routing
June 2005 9
An eco system, not just a An eco system, not just a protocolprotocol
SIP
XCAP(config)
RTSP
SIMPLEpolicyRPID….
SDP
XCON(conferencing)
STUNTURNRTP
configures
initiates carries
carriescontrols provide addresses
June 2005 10
SIP, SIPPING & SIMPLE –00 draftsSIP, SIPPING & SIMPLE –00 drafts
includes draft-ietf-*-00 and draft-personal-*-00
0
10
20
30
40
50
60
70
1999 2000 2001 2002 2003 2004 2005
SIPSIPPINGSIMPLE
June 2005 11
RFC publicationRFC publication
0
2
4
6
8
10
12
14
2001 2002 2003 2004 2005
SIPSIPPINGSIMPLE
June 2005 12
SIP – a bi-cultural protocolSIP – a bi-cultural protocol
• overlap dialing• DTMF carriage• key systems• notion of lines• per-minute billing• early media• ISUP & BICC interoperation• trusted service providers
• multimedia• IM and presence• location-based service• user-created services• decentralized operation• everyone equally suspect
June 2005 13
SIP design objectivesSIP 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
June 2005 14
SIP architectural principles SIP architectural principles (1)(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
June 2005 15
SIP architectural principles SIP architectural principles (2)(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
June 2005 16
SIP architectural principles SIP architectural principles (3)(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
June 2005 17
SIP design principles (1)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
June 2005 18
SIP design principles (2)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 don’t 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
June 2005 19
SIP design principles (3)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
June 2005 20
SIP division of laborSIP division of laborproxy B2BUA UA
State statelesstransaction-stateful
call stateful call stateful
Headers inspectinsertmodify (rarely)
inspectinsertmodify
inspectreflect
Bodies ignoresome inspect
inspectinsertmodify
inspect
Fork yes separate call legs
no
Media no maybe yesServices rendezvous
call routingcall stateful media-related
June 2005 21
UMTS Reference UMTS Reference Architecture Architecture
by Kimmo Raatikainen
Gf Gi
Iu
GiMr
Gi
Ms
Gi
R UuMGW
Gn
Gc
Signalling and Data TransferInterface
SignallingInterface
TE MT UTRAN
Gr
SGSN GGSN
EIR
MGCF
R-SGW *)
MRF
MultimediaIP Networks
PSTN/Legacy/External
Applications &Services *)
Mm
Mw
Legacy mobilesignallingNetwork
Mc
Cx
AlternativeAccess
Network
Mh
CSCF
CSCFMg
T-SGW *)
T-SGW *)
HSS *)
HSS *)
Applications& Services *)
MSC server GMSC server
McMc
D C
SCP
CAP
MGWNb
Nc
Iu
Iu
R-SGW *)Mh
CAPCAP
R UmTE MT
BSS/GERAN
GbA
*) those elements are duplicated for figurelayout purpose only, they belong to the samelogical element in the reference model
Iu
June 2005 22
3G Architecture 3G Architecture (Registration)(Registration)
visited IM domain
home IM domain
servingCSCF
interrogating
proxy
interrogating
mobility managementsignaling
registration signaling (SIP)_
describesdeploymen
t architectur
e
June 2005 23
Classical IETF interfacesClassical IETF interfaces
L2Ethernet
L3 IPv4/IPv6
L3 config DHCP, PPP
namemapping
BGPOSPF
IPv4/IPv6
SONET
DNS DNS
signaling SIP SIP
“UNI” “NNI”
host
end
syst
emUA
routerproxyserver
June 2005 24
IETF interface approachIETF 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
June 2005 25
IP “hourglass”IP “hourglass”
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...Steve Deering, IETF Aug. 2001
June 2005 26
The real Internet hourglass The real Internet hourglass (slightly simplified)(slightly simplified)
IP
TCP
HTTP
Ethernet
webweb services
p2p (port 80)
June 2005 27
Interconnection Interconnection approachesapproaches
Property NGN, 3GPP “Internet”interconnection per service service neutralend device control carrier-controlled user-providedend device type mostly hardware software, maybe
hardwarestate preference call state-full stateless
transaction-statefulinterconnect arrangement
pre-arranged serendipitous
interconnect discovery
pre-configured DNS
billing preference per serviceusage-based
bandwidth-basedservices fixed-rate or ad-supported
billing arrangement clearing house sender keepsindependent
June 2005 28
IETF “4G” (access-neutral) IETF “4G” (access-neutral) modelmodel
columbia.edu example.com
sip:alice@columbia.edu sip:bob@example.com TLS
DIAMETERserver
802.1xNSIS NTLPfor QoS
Visitednetwork
AP
Checkreputation ofcolumbia.edu
alice@isp.net
isp.net
June 2005 29
Session Border Controllers Session Border Controllers (SBCs)(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
June 2005 30
SBCs: High-level SBCs: High-level motivationsmotivations 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
not an issue for email and web
June 2005 31
SBC functionality, cont’dSBC 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
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
June 2005 32
SBC: Network evolutionSBC: Network evolution
SBC
earlier: email, IM
only IP-level(with filter)
stand-alone networks(Vonage, Skype)
media
June 2005 33
SBC: ConcernsSBC: 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 34
SBC: The dangersSBC: 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
June 2005 35
What’s left to do?What’s 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 --> identity and
reputation management)
June 2005 36
P2P for autonomic P2P for autonomic computingcomputing 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)
June 2005 37
What is SIP? Why P2P-SIP?What is SIP? Why P2P-SIP?
Bob’s hostAlice’s host128.59.19.194
(1) REGISTER alice@columbia.edu =>128.59.19.194
(2) INVITE alice@columbia.edu
(3) Contact: 128.59.19.194
columbia.edu
Problem in client-server: maintenance, configuration, controlled infrastructure
Peer-to-peer network
Alice128.59.19.194
(1) REGISTER(2) INVITE alice
(3) 128.59.19.194
No central server, but more lookup latency
June 2005 38
How to combine SIP + How to combine SIP + P2P?P2P?
SIP-using-P2P Replace SIP location
service by a P2P protocol
P2P-over-SIP Additionally, implement
P2P using SIP messaging
P2P network
Alice128.59.19.194
INSERT
INVITE sip:alice@128.59.19.194
P2P-SIPoverlay Alice
128.59.19.194
REGISTERINVITE aliceFIND
SIP-using-P2P P2P SIP proxies
P2P-over-SIP
Maintenance P2P P2P SIPLookup P2P SIP SIP
June 2005 39
Deployment scenariosDeployment scenarios
P
P
P
P
P
P2P proxies
P
P
P
P
P
P2P database
P
P
P
P
P
P2P clients
Plug and play; May use adaptors;Untrusted peers
Zero-conf server farm; Trusted servers and user identities
Global, e.g., OpenDHT; Clients or proxies can use;Trusted deployed peers (?)
Interoperate among these!
June 2005 40
Hybrid architectureHybrid architecture
Cross register, or Locate during call
setup DNS, or P2P-SIP hierarchy
June 2005 41
What else can be P2P?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 42
What is our P2P-SIP?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 SIP+P2P Unlike file-sharing applications
Data storage, caching, delay, reliability Disadvantages
Lookup delay and security
June 2005 43
Implementation: Implementation: SIPpeerSIPpeer 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
June 2005 44
Implementation: Implementation: SIPpeerSIPpeer
User interface (buddy list, etc.)
SIPICE RTP/RTCPCodecs
Audio devicesDHT (Chord)
On startup
Discover
User location
Multicast REGISTERPeer found/Detect NAT
REGISTERREGISTER, INVITE,MESSAGE
Signup,Find buddies
JoinFind
Leave
On resetSignout,transfer
IM,call
SIP-over-P2P
P2P-using-SIP
June 2005 45
SIP p2p summary and open SIP p2p summary and open issuesissues
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.cs.columbia.edu/IRT/p2p-sip http://www.p2psip.org and
June 2005 46
The role of presenceThe 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, 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 47
Context-aware Context-aware communicationcommunication
context = “the interrelated conditions in which something exists or occurs”
anything known about the participants in the (potential) communication relationship
both at caller and calleetime CPLcapabilities caller preferenceslocation location-based call routing
location eventsactivity/availability presencesensor data (mood, bio)
privacy issues similar to location data
June 2005 48
The role of presenceThe 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, …)
June 2005 49
Basic presenceBasic 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
June 2005 50
The role of presence for call The role of presence for call routingrouting Two modes:
watcher uses presence information to select suitable contacts
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)
LESS
translateRPID
CPL
PA
PUBLISH
NOTIFY
INVITE
June 2005 51
GEOPRIV and SIMPLE GEOPRIV and SIMPLE architecturesarchitectures
target locationserver
locationrecipient
rulemaker
presentity
caller
presenceagent watcher
callee
GEOPRIV
SIPpresence
SIPcall
PUBLISHNOTIFY
SUBSCRIBE
INVITE
publicationinterface
notificationinterface
XCAP(rules)
INVITE
DHCP
June 2005 52
Presence data architecturePresence data architecture
rawpresencedocument
createview
(compose)privacyfiltering
draft-ietf-simple-presence-data-model
compositionpolicy
privacypolicy
presence sources
XCAP XCAP
(not defined yet)
depends on watcherselect best sourceresolve contradictions
PUBLISH
June 2005 53
Presence data architecturePresence data architecture
candidatepresencedocument
watcherfilter
rawpresencedocument
post-processingcomposition(merging)
finalpresencedocument
differenceto previous notification
SUBSCRIBE
NOTIFY
remove data not of interest
watcher
June 2005 54
Presence data modelPresence data model
“calendar” “cell” “manual”
alice@example.comaudio, video, text
r42@example.comvideo
person(presentity)
(views)
services
devices
June 2005 55
Rich presenceRich 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 56
Privacy policy Privacy policy relationshipsrelationships
geopriv-specific presence-specific
common policy
RPID CIPID
future
June 2005 57
Privacy rulesPrivacy rules Conditions
identity, sphere time of day current location identity as <uri> or
<domain> + <except>
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
June 2005 58
Example rules documentExample rules document
<identity><id>user@example.com</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>
<rul
eset
>
<rule id=1>
<con
ditio
ns>
<tra
nsfo
rmat
ion
s><a
ctio
ns>
June 2005 59
Location-based servicesLocation-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
June 2005 60
Location-based SIP Location-based SIP servicesservices 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 I’m in a theater
outbound call routing contact nearest emergency call center send delivery@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
June 2005 61
Presence CompositionPresence 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
June 2005 62
Sources of presence dataSources 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
June 2005 63
Composition stepsComposition steps
Working on policy language that describes desired composition policy
Complicated policies will require “real” languages
source
sourceunion with
replacement
discardclosed +
old
combineidenticalcontacts
resolveambiguities
June 2005 64
Service creationService creation
programmer, carrier
end user
network servers
SIP servlets, sip-cgi
CPL
end system VoiceXML VoiceXML (voice),LESS
Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models
June 2005 65
Automating media Automating media interaction – service interaction – service examplesexamples 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 66
LESS: simplicityLESS: 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)
switchestrigger actions
modifiers
June 2005 67
LESS: Decision treeLESS: Decision treeNo loopsLimited variablesNot necessarily Turing-complete
June 2005 68
LESS: SafetyLESS: 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.
June 2005 69
LESS snapshotLESS snapshot<less> <incoming> <address-switch> <address is=“sip:myboss@abc.com"> <device:turnoff device=“sip:stereo_room1@abc.com”/> <media media=“audio”> <accept/> </media> </address> </address-switch> </incoming></less>
incoming call
If the call from my boss
Turn off the stereo
Accept the call with only audio
trigger, switch, modifier, action
June 2005 70
Device agentx10 vcr
SIP user agentSIP
LESS packagesLESS packages
Basic user agentGeneric Media UI
conference
email web
calendar
im
Presence agent
presenceEvent
Use packages to group elements
locationsession
June 2005 71
When Tom is online, …When Tom is online, …<less><EVENT:notification> <address-switch> <address is="sip:tom@example.com"> <EVENT:event-switch> <EVENT:event is="open"> <location url="sip:tom@example.com"> <IM:im message="Hi, Tom"/> </location> </EVENT:event> </EVENT:event-switch> ………</less>
June 2005 72
When I am in a movie When I am in a movie theatre, …theatre, …<less><incoming> <location-switch> <location placetype=“quiet”> <alert sound=“none”
vibrate=“yes”/> </location> </location-switch></incoming></less>
June 2005 74
XCON SystemXCON SystemLogical XCON Server
Floor ControlClient
TEMPLATEOf the SYSTEM:•Pre-configured•Initial/Default values
Conf EventNotification Server
Focus
CPCP Client
CCCPClient
CPCPServer
CCCPServer
CallSignaling
Client
TEMPLATE Policy:•Of TYPE RULES
RESERVATION Policy:•Of TYPE RULES
CURRENT Policy:•Of TYPE RULES
RESERVATIONOf the INSTANCE:•Of TYPE CONFERENCE-INFO
STATEOf the CURRENT INSTANCE:•Of TYPE CONFERENCE-INFO
NotificationClient
FloorControl Server
SIP/PSTN/H.323T.120/Etc.
CCCPCPCP SIP NOTIFY/Etc. BFCP
Logical XCON Client
June 2005 75
Conference controlConference 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 76
Open issues: application Open issues: application sharingsharing Current: T.120
doesn’t 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 doesn’t
integrate well with control protocols
June 2005 77
IETF effort: standardized IETF effort: standardized application sharingapplication 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 78
Spam and spitSpam and spit
June 2005 79
SIP unsolicited calls and SIP unsolicited calls and messagesmessages 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
home.comDigest
mutualPK authentication (TLS)
June 2005 80
Domain ClassificationDomain 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
June 2005 81
Reputation serviceReputation service
Alice Bob
Carol David
Emily Frank
has sentemail to
has sentIM to
is this a spammer?
June 2005 82
SIP standards & deployment SIP standards & deployment issues and competitionissues and competition Interoperability Proprietary systems
June 2005 83
cableDSL op
CiscoCM
Provider combinationsProvider combinations
software hardware
ISPIAP VSP
Skype
mobileoperators?
June 2005 84
Protocol interoperability Protocol interoperability problemsproblems 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 didn’t expect this error”
mutually incompatible extensions expect extension to make something work
June 2005 85
Protocol interoperability: Protocol interoperability: proprietary protocolsproprietary 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 Metcalfe’s law value
June 2005 86
Why is Skype successful?Why is Skype successful? All the advantages of a proprietary protocol Peer-to-peer coincidental Good out-of-box experience
Software vendor = service provider 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
use TCP if necessary use port 80
Did encryption from the very beginning Kazaa marketing vehicle
June 2005 87
Skype vs. SIP-based Skype vs. SIP-based systemssystems
Skype SIP-based providersProtocol proprietary, encrypted
SIP to gatewaysopen (SIP), often plain-textsometimes 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 closedsome semi-open (*-codes)
Allow federation? not currently yesNAT traversal integrated separated (STUN)User agent software only
(USB phones)software and hardwareprimarily market hardware
User interface presence-like phone-like
June 2005 88
Open standard, dominant Open standard, dominant vendorvendor 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 89
Open standard, multiple Open standard, multiple vendorsvendors 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 90
Why SIP extensions?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 91
SIP proprietary extensionsSIP 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
June 2005 92
SIP proprietary extensions, SIP proprietary extensions, cont’dcont’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 93
The SIP complexity fallacyThe 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
Signaling & Media Signaling & Media
Signaling Signaling
Media
IAX model
SIP, H.323, MCGP model
June 2005 94
Does it have to be that Does it have to be that complicated?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
June 2005 95
Solving the configuration Solving the configuration messmess 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@domain format”
use DNS NAPTR and SRV for STUN server
June 2005 96
Solving the configuration Solving the configuration mess – longer termmess – 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 97
VoIP end system VoIP end system configurationconfiguration
AOR
MACaddress
registrar addressSTUN/TURN – local and global
general configuration document(media, UI, protocol behavior, …)
geographical location (for 911)outbound proxy
DNS
SIP SUBSCRIBE/NOTIFY
DHCP
that’s all it should take
June 2005 98
Problems in Standards Problems in Standards LandLand Proliferation of transition
standards: 2.5G, 2.6G, 3.5G, …
Splintering of standardization efforts across SDOs
primary: IEEE, IETF, W3C, OASIS, ISO
architectural: PacketCable, ETSI, 3GPP,
3GPP2, OMA, UMA, … operational, marketing:
SIP Forum, IPCC, …
OASIS
IEEE
IETF
W3CISO (MPEG)
L2.5-L7protocols
dataexchange
dataformats
L1-L2
3GPP
Pack
etCa
ble
June 2005 99
IETF issuesIETF 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
DNS, IPv4, IPv6, BGP, DHCP; RTP, SIP, RTSP constrained by design choices made long ago
often dealing with transition to hostile network Stale IETF leadership
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 100
IETF issue: timelinessIETF 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 (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
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
June 2005 101
IETF issues: timelinessIETF 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 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
June 2005 102
Interworking VoIP -- Interworking VoIP -- CellularCellular A whole separate talk Options:
registration single tel/SIP URI; forward calls to mobile
integration -- cellular in charge access: UMA -- make look like GSM BSC system: use VoIP as VLR or HLR
cellular as transport treat cellular as another access network
June 2005 103
UMAUMA** functional functional architecturearchitecture
*Unlicensed Mobile Access
June 2005 104
UMA signalingUMA signaling
June 2005 105
UMA GSM speech bearer UMA GSM speech bearer architecturearchitecture
June 2005 106
ConclusionConclusion Slow transition from emulating PSTN to new
services presence-based embedded (e.g., games)
Emphasis moving from protocol mechanics to architecture
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