Title: VoIP%20-%20Moving%20from%20protocols%20to%20architecture(s)
1VoIP - Moving from protocols to architecture(s)
- Henning Schulzrinne
- Dept. of Computer Science
- Columbia University
- January 2006
2Overview
- 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
3Philosophy 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
4Evolution 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-
5Collaboration 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
6Internet 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
7Filling in the protocol gap
Service/delivery synchronous asynchronous
push SIP RTSP, RTP SMTP
pull HTTP ftp SunRPC, Corba, SOAP (not yet standardized)
8A 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
9An 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
10SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
11RFC publication
12SIP 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
13SIP 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
14SIP 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
15SIP 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
16SIP 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
17SIP 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
18SIP 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
19SIP 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
20SIP 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
21UMTS Reference Architecture
by Kimmo Raatikainen
223G Architecture (Registration)
describes deployment architecture
mobility management
signaling
serving
interrogating
interrogating
CSCF
proxy
home IM domain
registration signaling (SIP)_
visited IM domain
23Classical 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
24IETF 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
25IP hourglass
email WWW phone... SMTP HTTP RTP... TCP
UDP IP ethernet PPP CSMA async
sonet... copper fiber radio...
Steve Deering, IETF Aug. 2001
26The real Internet hourglass (slightly simplified)
p2p (port 80)
web
web services
HTTP
TCP
IP
Ethernet
27Interconnection 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
28IETF 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
29Session 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
30SBCs 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
31SBC 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
32SBC Network evolution
stand-alone networks (Vonage, Skype)
media
earlier email, IM
SBC
only IP-level (with filter)
33SBC 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
34SBC 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
35Whats 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)
36P2P 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)
37What 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
38How 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
39Deployment 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!
40Hybrid architecture
- Cross register, or
- Locate during call setup
- DNS, or
- P2P-SIP hierarchy
41What 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!
42What 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
43Implementation 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
44Implementation 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
45SIP 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
46The 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
47Context-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
48The 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, )
49Basic 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
50The 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
51GEOPRIV 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
52Presence 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
53Presence 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
54Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
55Rich 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, )
56Privacy policy relationships
common policy
geopriv-specific
presence-specific
future
RPID
CIPID
57Privacy 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
58Example 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
59Location-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
60Location-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
61Presence 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
62Sources 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
63Composition 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
64Service 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
65Automating 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
66LESS 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
67LESS Decision tree
- No loops
- Limited variables
- Not necessarily
- Turing-complete
68LESS 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.
69LESS 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
70LESS packages
- Use packages to group elements
email
web
im
conference
calendar
location
session
71When 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
72When 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)
74XCON System
75Conference control
- IETF XCON WG struggling with model and complexity
- Web services?
- Specialized (binary) protocol?
- API or document modification?
- Inheritance model blue prints and templates
76Open 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
77IETF 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
78Spam and spit
79SIP 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
80Domain 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
81Reputation service
David
Carol
has sent IM to
has sent email to
Frank
Emily
is this a spammer?
Bob
Alice
82SIP standards deployment issues and competition
- Interoperability
- Proprietary systems
83Provider combinations
Cisco CM
Skype
software
hardware
mobile operators?
cable DSL op
ISP IAP
VSP
84Protocol 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
85Protocol 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
86Why 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
87Skype 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
88Open 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
89Open 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
90Why 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)
91SIP 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
92SIP 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
93The 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
94Does 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
95Solving 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
96Solving 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
97VoIP 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
98Problems in Standards Land
- 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
data formats
W3C ISO (MPEG)
data exchange
IETF
L2.5-L7 protocols
IEEE
L1-L2
PacketCable
3GPP
99IETF 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
100IETF 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
101IETF 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
102Interworking VoIP -- Cellular
- 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
103UMA functional architecture
Unlicensed Mobile Access
104UMA signaling
105UMA GSM speech bearer architecture
106Conclusion
- 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