Transcript Document 7280296

VoIP - Year 10+
Henning Schulzrinne
Dept. of Computer Science
Columbia University
[email protected]
January 11, 2007
Internet2 VoIP
Overview
• VoIP status
• IETF WG status
• Deployment-related issues
– security
– peering
– software
– ossification
– robustness
– configuration
– NATs
Internet2 VoIP
2
Evolution of VoIP
“how can I make it
stop ringing?”
long-distance calling,
ca. 1930
“amazing – the
phone rings”
1996-2000
“does it do
call transfer?”
going beyond
the black phone
catching up
with the digital PBX
2000-2003
Internet2 VoIP
20043
SIP is PBX/Centrex ready
centrex-style features
boss/admin features
call waiting/multiple calls
RFC 3261
simultaneous ringing
RFC 3261
hold
RFC 3264
basic shared lines
dialog/reg. package
transfer
RFC 3515/Replaces
barge-in
Join
conference
RFC 3261/callee caps
“Take”
Replaces
message waiting
message summary package
Shared-line “privacy”
dialog package
call forward
RFC 3261
divert to admin
RFC 3261
call park
RFC 3515/Replaces
intercom
URI convention
call pickup
Replaces
auto attendant
RFC 3261/2833
do not disturb
RFC 3261
attendant console
dialog package
call coverage
RFC 3261
night service
RFC 3261
attendant features
from Rohan Mahy’s VON Fall 2003 talk
Internet2 VoIP
4
IETF VoIP efforts
ECRIT
ENUM
SIMPLE
(emergency calling)
(E.164 translation)
(presence)
uses
GEOPRIV
uses
SPEERMINT
(geo + privacy)
may use
XCON
uses
(conf. control)
uses
SIP
IPTEL
(protocol)
provides
(peering)
SIPPING
(usage, requirements)
SPEECHSC
(tel URL)
(speech services)
usually
used
with
AVT
MMUSIC
(RTP, SRTP, media)
(SDP, RTSP, ICE)
SIGTRAN
(signaling transport)
IETF RAI area
Internet2 VoIP
5
A constellation of SIP RFCs
Non-adjacent (3327)
Symmetric resp. (3581)
Service route (3608)
User agent caps (3840)
Caller prefs (3841)
Request routing
Resource mgt. (3312)
SIP (3261)
DNS for SIP (3263)
Events (3265)
REFER (3515)
ISUP (3204)
sipfrag (3240)
Content types
Reliable prov. (3262)
INFO (2976)
UPDATE (3311)
Reason (3326)
Mostly PSTN
Core
Digest AKA (3310)
Privacy (3323)
P-Asserted (3325)
Agreement (3329)
Media auth. (3313)
AES (3853)
DHCP (3361)
DHCPv6 (3319)
Configuration
Security & privacy
Internet2 VoIP
6
SIP, SIPPING & SIMPLE –00 drafts
80
70
60
50
SIP
SIPPING
SIMPLE
40
30
20
10
0
1999 2000 2001 2002 2003 2004 2005 2006
includes draft-ietf-*-00 and draft-personal-*-00
Internet2 VoIP
7
RFC publication
14
12
10
8
SIP
SIPPING
SIMPLE
6
4
2
0
2001
2002
2003
2004
Internet2 VoIP
2005
2006
8
IETF WG: SIP
•
•
~ 44 SIP-related RFCs
published
Activities:
– hitchhiker’s guide
– infrastructure:
• GRUUs (random
identifiers)
• URI lists
• XCAP configuration
• SIP MIB
– services:
• rejecting anonymous
requests
• consent framework
• location conveyance
• session policy
– security:
• end-to-middle security
• certificates
• SAML
• sips clarification
– NAT:
• connection re-use
• SIP outbound
see http://tools.ietf.org/wg/sip’/
Internet2 VoIP
9
IETF WG: SIPPING
•
•
•
31 RFCs published
Policy
– media policy
– SBC functions
Services
– service examples
– call transfer
– configuration framework
– spam and spit
– text-over-IP
– transcoding
•
Internet2 VoIP
Testing and operations
– IPv6 transition
– race condition examples
– IPv6 torture tests
– SIP offer-answer examples
– overload requirements
10
VoIP emergency communications
emergency call
emergency alert
(“inverse 911”)
dispatch
civic coordination
Internet2 VoIP
11
IETF ECRIT working group
•
•
•
•
Emergency Contact Resolution with Internet Technologies
Solve four major pieces of the puzzle:
– location conveyance (with SIP & GEOPRIV)
– emergency call identification
– mapping geo and civic caller locations to PSAP URI
– discovery of local and visited emergency dial string
Not solving
– location discovery --> GEOPRIV
– inter-PSAP communication and coordination
– citizen notification
Current status:
– finishing general and security requirements
– agreement on mapping protocol (LoST) and identifier (sos URN)
– working on overall architecture and UA requirements
Internet2 VoIP
12
ECRIT: Options for location delivery
• GPS
• L2: LLDP-MED (standardized version of CDP + location
data)
– periodic per-port broadcast of configuration
information
– currently implementing CDP
• L3: DHCP for
– geospatial (RFC 3825)
– civic (RFC 4676)
• L7: proposals for retrievals: HELD, RELO, LCP, SIP, …
– for own IP address
– by IP address
– by MAC address
– by identifier (conveyed by DHCP or PPP)
Internet2 VoIP
13
ECRIT: Finding the correct PSAP
•
Which PSAP should the e-call go to?
– Usually to the PSAP that serves the geographic area
– Sometimes to a backup PSAP
– If no location, then ‘default’ PSAP
I am at "Otto-Hahn-Ring 6, 81739
München"
I need contact the ambulance.
(Emergency Identifier)
Mapping
Client
Mapping
Server
Contact URI [email protected]
Internet2 VoIP
14
ECRIT: LoST Functionality
•
•
•
•
•
•
Satisfies the requirements (draft-ietf-ecrit-requirements) for mapping
protocols
Civic as well as geospatial queries
– civic address validation
Recursive and iterative resolution
Fully distributed and hierarchical deployment
– can be split by any geographic or civic boundary
– same civic region can span multiple LoST servers
Indicates errors in civic location data  debugging
– but provides best-effort resolution
Supports overlapping service regions
Internet2 VoIP
15
LoST: Location-to-URL Mapping
VSP1
cluster serving VSP1
replicate
root information
cluster
serves VSP2
123 Broad Ave
Leonia
Bergen County
NJ US
LoST
NJ
US
root
NY
US
sip:[email protected]
nodes
search
referral
Bergen County
NJ US
Leonia
NJ US
Internet2 VoIP
16
LoST Architecture
G
tree guide
G
G
G
T1: .us
G
broadcast (gossip)
T2: .de
resolver
seeker
313 Westview
Leonia, NJ US
T2
T1
(.us)
(.de)
T3
(.dk)
Leonia, NJ  sip:[email protected]
Internet2 VoIP
17
SPEERMINT: Session interconnect
E.164
number
peer discovery
ENUM lookup of NAPTR in DNS
SIP
URI
aka call routing data (CRD)  derived from ENUM record
service location (lookup of NAPTR and SRV) in DNS
host name
addressing and session establishment
lookup of A and AAAA in DNS
IP
address
routing protocols, ARP, …
MAC
address
Internet2 VoIP
18
SPEERMINT: Peering Network Context
Enterprise
Provider A
Public Peering Function/Federation Entity
Location Function
Enterprise
Provider B
(L5)
Service
Provider C
(L5)
Public
(L3)
Service
Provider D
(L5)
(L5)
L3 Peering Point
(out of scope)
Enterprise
Provider E
(L5)
Enterprise
Provider F
Private
(L3)
Service
Provider G
(L5)
Service
Provider H
(L5)
(L5)
Private Peering Function/Federation Entity
Location Function
VoIPSprint-Nextel
Sohel Internet2
Khan, Ph.D.,
19
SPEERMINT: Reference peering architecture
LF
LF
SIP Service Provider
X
LF
OF
OF
SF
SF
MF
MF
QF
QF
AF
AF
Security
SIP Service Provider
Y
Security
Ref.
LF
Purpose
OF
Enables discovery of SF or exchanges policy/parameters to be used by SF
SF
MF
QF
AF
Enables discovery of the SF or OF
Enables discovery of endpoints, assists in discovery and exchange of
parameters to be used with the MF
Enables media paths interconnection between endpoints
Negotiates and reserves bandwidth resources,
as well as polices/provides measurements for media paths
Application Function: TBD or deleted
Sohel Khan, Ph.D., Sprint-Nextel
Internet2 VoIP
20
IETF WG: AVT
•
•
Audio and video transport
– media transport: RTP &
SRTP
– encapsulating media
within RTP
• “RTP payload formats”
One of the longest-running
working groups in the IETF
– 59 RFCs (not counting
those replaced)
•
•
Internet2 VoIP
Current efforts:
– codec control messages
– extended RTCP QoS
reporting
– JPEG 2000
– SMPTE (video) sync
– TFRC (congestion control)
– unequal error protection
(ULP)
SRTP key management
– SRTP = encrypted &
authenticated version of
RTP
21
IETF WG: MMUSIC
•
•
•
•
•
Original home of SIP
Now mainly deals with SDP
Efforts to replace SDP with
SDPng apparently failed
– SDPng: XML-based, more
structure
Offer-answer model
Discussions on better discovery
of end point capabilities
•
Internet2 VoIP
NAT traversal story:
– alternative network
addresses in SDP
– permanent outbound TCP
connections from UA to
proxy
– discover end point
addresses
• IP addresses are no
longer globally unique -> multiple addresses
depending on context
• STUN
– configure media relay
• STUN with TURN
functionality
22
IETF WG: P2P-SIP
• Several BOF sessions, now likely to become IETF working
group
• Provide peer-to-peer model for SIP-based interactive
communications
– based on distributed hash table (DHT) as
replacement for DNS and possibly SIP registrar
– (1) protocol for constructing DHT
• hopefully, independent of DHT algorithm
– (2) protocol for accessing DHT nodes
• get/put/delete key-value pairs
Internet2 VoIP
23
P2PSIP: Applications & Motivation
•
•
•
Small stand-alone networks
– 2-50
– SOHO, events, emergency
coordination
– may not have access to
Internet infrastructure
Corporate size networks
– 50-1000
– single administrator
Global-scale networks
– 1000-100 million
– consumer applications
– serious trust issues
•
•
Internet2 VoIP
Motivation
– no need to pay for servers
• users are kind enough to
pay!
– SIP proxy less of issue
• 1 server/100,000 users?
– but also:
• media relay for NAT
traversal
• media bridge for
conferencing
Issues
– trust - members may abuse
system or actively subvert it
– reliability
– monitoring and control (SOX,
HIPAA)
24
Three basic approaches
•
•
•
Full distribution and search
– similar to Bonjour
– scales to small, local networks
DHT built using SIP
– see Kundan/Schulzrinne and
Cao/Bryan/Lowekamp
– dedicated to VoIP
– Skype model
Using an external DHT (Columbia)
– using OpenDHT as generic service
• used by multiple applications
– can provide mapping or pointer to mapping
SIP-managed
DHT
OpenDHT
Internet2 VoIP
25
P2P-SIP: Implementation in SIPc
• OpenDHT
– Trusted nodes
– Robust
– Fast enough (<1s)
• Identity protection
– Certificate-based
– SIP id == email
• P2P for
Calls, IM, presence,
offline message,
STUN server discovery
and name search
Internet2 VoIP
26
Open issues: NATs
•
•
•
NATs fundamentally change the nature of the Internet
– no longer a single, global address space
– cannot deploy new transport protocols (e.g., SCTP, DCCP)
– more like old UUNET model (decvax!wustl!columbia)
• except that there’s no path, just mappings
• another analogy: ATM and MPLS label rewriting
NAT behavior unspecified and implicit
– what part of incoming packet is used for mapping
• just destination address & port
• or protocol and source address?
– how long is the binding maintained?
• some hotel NATs time out active TCP connections after a few
seconds
• can’t easily discover timeout --> need high-frequency refresh
--> possibly high REGISTER load
– other random “optimizations”
BEHAVE WG to define NAT behavioral guidelines
Internet2 VoIP
27
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
Internet2 VoIP
28
Open issues: Configuration
•
•
•
•
•
•
Ideally, should only need a user name and some credential
– password, USB key, host identity (MAC address), …
More than DHCP: device needs to get
– SIP-level information (outbound proxy, timers)
– policy information (“sorry, no video”)
Multiple sources of configuration information
– local network (hotel proxy)
– voice service provider (off-network)
Configuration information may change
Needs to allow no-touch deployment of thousands of devices
SIP configuration framework
– has been languishing for years
– currently being rewritten to reduce complexity
Internet2 VoIP
29
Open issues: summary
• Basic interoperability is generally good
– call setup/teardown
– transfer
• Advanced features less so
– e.g., bridged call appearance
• Configuration too painful
– “out of the box experience”
• Unreliable (98 to 99.5% instead of 99.999%):
– BGP disruptions
– NAT problems
– local interference
– hard to tell what went wrong --> can’t prevent
repeated problems (“dentist problems”)
Internet2 VoIP
30
Trouble in Standards Land
OASIS
W3C
ISO (MPEG)
Internet2 VoIP
data
formats
data
exchange
IETF
L2.5-L7
protocols
IEEE
L1-L2
PacketCable
•
Proliferation of transition standards:
2.5G, 2.6G, 3.5G, …
– true even for emergency calling…
Splintering of standardization efforts
across SDOs
– primary:
• IEEE, IETF, W3C, OASIS, ISO
– architectural:
• PacketCable, ETSI, 3GPP, 3GPP2,
OMA, UMA, ATIS, …
– specialized:
• NENA
– operational, marketing:
• SIP Forum, IPCC, …
3GPP
•
31
IETF issues
•
•
•
•
•
SIP WGs: small number (dozen?) of core authors (80/20)
– some now becoming managers…
– or moving to other topics
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 & “random” network
– network ossification
Stale IETF leadership
– often from core equipment vendors, not software vendors or carriers
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
Internet2 VoIP
32
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 (RFC 4244)
– Session timers: Feb. 1999 – May 2005 (RFC 4028)
– Resource priority: Feb. 2001 – Feb 2006 (RFC 4412)
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
Gets worse over time:
– dependencies increase, sometimes undiscovered
– backwards compatibility issues
– more background needed to contribute
Internet2 VoIP
33
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 working group last call (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
Internet2 VoIP
34
Conclusion
• Core standards for media and signaling are finished
– can build PBX-equivalent devices and services on a
large scale
• see BT, FiOS, Vonage
• Lots of decent server implementations (various vendors;
SER, openSER, Asterisk)
– but lack of good soft clients for major OS platforms
• Ossification of Internet requires application complexity
– kludge around NATs, lack of QoS
– lack of credential infrastructure
• Intersection with policy and business models
– NGN, 3G: maintain voice as high-value monopoly
service
• Not a protocol engineering effort, systems engineering
Internet2 VoIP
35