VoIP - Moving from protocols to architecture(s)

1
VoIP - Moving from protocols to architecture(s)

• Henning Schulzrinne
• Dept. of Computer Science
• Columbia University
• June 2005

2
Overview

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

3
Philosophy transition
PC era cell phone era
One computer/phone, many users
One computer/phone, one user
mainframe era home phone party line
Many computers/phones, one user
ubiquitous computing
anywhere, any time any media
right place (device), right time, right media
4
Evolution of VoIP
how can I make it stop ringing?
does it do call transfer?
long-distance calling, ca. 1930
going beyond the black phone
amazing the phone rings
catching up with the digital PBX
1996-2000
2000-2003
2004-
5
Collaboration in transition
inter-organization multiple technology
generations diverse end points
intra-organization small number of systems
(meeting rooms)
standards-based solutions
proprietary (single-vendor) systems
6
Internet services the missing entry
Service/delivery synchronous asynchronous
push instant messaging presence event notification session setup media-on-demand messaging
pull data retrieval file download remote procedure call peer-to-peer file sharing
7
Filling in the protocol gap
Service/delivery synchronous asynchronous
push SIP RTSP, RTP SMTP
pull HTTP ftp SunRPC, Corba, SOAP (not yet standardized)
8
A constellation of SIP RFCs
Non-adjacent (3327) Symmetric resp.
(3581) Service route (3608) User agent caps
(3840) Caller prefs (3841)
Request routing
Resource mgt. (3312) Reliable prov. (3262) INFO
(2976) UPDATE (3311) Reason (3326)
SIP (3261) DNS for SIP (3263) Events (3265) REFER
(3515)
ISUP (3204) sipfrag (3240)
Mostly PSTN
Core
Content types
Digest AKA (3310) Privacy (3323) P-Asserted
(3325) Agreement (3329) Media auth. (3313) AES
(3853)
DHCP (3361) DHCPv6 (3319)
Configuration
Security privacy
9
An eco system, not just a protocol
configures
XCAP (config)
SIMPLE policy RPID .
XCON (conferencing)
initiates
carries
SIP
RTSP
SDP
carries
controls
provide addresses
STUN TURN
RTP
10
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
11
RFC publication
12
SIP a bi-cultural protocol

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

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

13
SIP design objectives

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

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

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

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

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

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

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

16
SIP architectural principles (3)

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

17
SIP design principles (1)

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

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

18
SIP design principles (2)

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

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

19
SIP design principles (3)

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

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

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

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

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

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

30
SBCs High-level motivations

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

31
SBC functionality, contd

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

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

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

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

34
SBC The dangers

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

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

35
Whats left to do?

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

36
The role of presence

• Guess-and-ring
• high probability of failure
• telephone tag
• inappropriate time (call during meeting)
• inappropriate media (audio in public place)
• current solutions
• voice mail ? tedious, doesnt scale, hard to
  search and catalogue, no indication of when call
  might be returned
• automated call back ? rarely used, too inflexible
• ? most successful calls are now scheduled by email

• Presence-based
• facilitates unscheduled communications
• provide recipient-specific information
• only contact in real-time if destination is
  willing and able
• appropriately use synchronous vs. asynchronous
  communication
• guide media use (text vs. audio)
• predict availability in the near future (timed
  presence)

Prediction almost all (professional)
communication will be presence-initiated or
pre-scheduled
37
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
38
Basic presence

• Role of presence
• initially can I send an instant message and
  expect a response?
• now should I use voice or IM? is my call going
  to interrupt a meeting? is the callee awake?
• Yahoo, MSN, Skype presence services
• on-line off-line
• useful in modem days but many people are
  (technically) on-line 24x7
• thus, need to provide more context
• simple status (not at my desk)
• entered manually ? rarely correct
• does not provide enough context for directing
  interactive communications

39
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
40
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, )

41
Service creation

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

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

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

43
LESS simplicity

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

modifiers
switches
trigger
actions
44
LESS Decision tree

• No loops
• Limited variables
• Not necessarily
• Turing-complete

45
LESS Safety

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

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

• Use packages to group elements

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

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

49
When I am in a movie theatre,

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

50
(No Transcript)
51
XCON System
52
Conference control

• IETF XCON WG struggling with model and complexity

53
Open issues application sharing

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

54
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

55
Spam and spit
56
SIP unsolicited calls and messages

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

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

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

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

• Interoperability
• Proprietary systems

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

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

62
Protocol interoperability proprietary protocols

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

63
Why is Skype successful?

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

64
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
65
Open standard, dominant vendor

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

66
Open standard, multiple vendors

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

67
Why SIP extensions?

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

68
SIP proprietary extensions

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

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

69
SIP proprietary extensions, contd

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

70
The SIP complexity fallacy

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

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

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

72
Solving the configuration mess

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

73
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

74
VoIP end system configuration
registrar address STUN/TURN local and global
DNS
AOR
SIP SUBSCRIBE/NOTIFY
general configuration document (media, UI,
protocol behavior, )
DHCP
MAC address
geographical location (for 911) outbound proxy
thats all it should take
75
Problems 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
76
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
• 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

77
IETF issue timeliness

• Most drafts spend lots of time in 90-complete
  state
• lack of energy (moved on to new -00)
• optimizers vs. satisfiers
• multiple choices that have non-commensurate
  trade-offs
• Notorious examples
• SIP request history Feb. 2002 May 2005 (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

78
IETF issues timeliness

• WG chairs run meetings, but are not managing WG
  progress
• very little control of deadlines
• e.g., all SIMPLE deadlines are probably a year
  behind
• little push to come to 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

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

80
UMA functional architecture
Unlicensed Mobile Access
81
UMA signaling
82
UMA GSM speech bearer architecture
83
Conclusion

• 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