View
218
Download
2
Tags:
Embed Size (px)
Citation preview
Internet2 VoIPJanuary 11, 2007
VoIP - Year 10+
Henning SchulzrinneDept. of Computer Science
Columbia [email protected]
Internet2 VoIP 2
Overview• VoIP status• IETF WG status• Deployment-related issues
– security– peering– software– ossification– robustness– configuration– NATs
Internet2 VoIP 3
Evolution 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
Internet2 VoIP 4
SIP is PBX/Centrex ready
call waiting/multiple calls
RFC 3261
hold RFC 3264
transfer RFC 3515/Replaces
conference RFC 3261/callee caps
message waiting message summary package
call forward RFC 3261
call park RFC 3515/Replaces
call pickup Replaces
do not disturb RFC 3261
call coverage RFC 3261
from Rohan Mahy’s VON Fall 2003 talk
simultaneous ringing RFC 3261
basic shared lines dialog/reg. package
barge-in Join
“Take” Replaces
Shared-line “privacy” dialog package
divert to admin RFC 3261
intercom URI convention
auto attendant RFC 3261/2833
attendant console dialog package
night service RFC 3261
centr
ex-s
tyle
featu
res
boss/admin features
attendant features
Internet2 VoIP 5
IETF VoIP efforts
SIP(protocol)
SIPPING(usage, requirements)
ECRIT(emergency calling)
AVT(RTP, SRTP, media)
ENUM(E.164 translation)
IPTEL(tel URL)
SIMPLE(presence)
GEOPRIV(geo + privacy)
usesmay use
uses
provides
usually
used with
IETF RAI area
MMUSIC(SDP, RTSP, ICE)
XCON(conf. control)
SPEERMINT(peering)
uses
SPEECHSC(speech services)
SIGTRAN(signaling transport)
uses
Internet2 VoIP 6
A 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
Internet2 VoIP 7
SIP, SIPPING & SIMPLE –00 drafts
includes draft-ietf-*-00 and draft-personal-*-00
0
10
20
30
40
50
60
70
80
19992000200120022003200420052006
SIPSIPPINGSIMPLE
Internet2 VoIP 8
RFC publication
0
2
4
6
8
10
12
14
2001 2002 2003 2004 2005 2006
SIPSIPPINGSIMPLE
Internet2 VoIP 9
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 10
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
• Testing and operations– IPv6 transition– race condition
examples– IPv6 torture tests– SIP offer-answer
examples– overload requirements
Internet2 VoIP 11
VoIP emergency communications
emergency call
dispatch
civic coordination
emergency alert(“inverse 911”)
Internet2 VoIP 12
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 13
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 14
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)
MappingClient
MappingServer
Contact URI [email protected]
Internet2 VoIP 15
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 16
LoST: Location-to-URL Mapping
clusterserves VSP2
NYUS
NJUS
Bergen CountyNJ US
123 Broad AveLeoniaBergen CountyNJ US
cluster serving VSP1
replicateroot information
searchreferral
rootnodes
LeoniaNJ US
VSP1
LoST
Internet2 VoIP 17
LoST Architecture
T1
(.us)
T2
(.de) T3
(.dk)
G
G
GG
G broadcast (gossip)T1: .us
T2: .de
resolver
seeker313 Westview
Leonia, NJ US
Leonia, NJ sip:[email protected]
tree guide
Internet2 VoIP 18
SPEERMINT: Session interconnect
E.164number
SIPURI
host name
IPaddress
MACaddress
peer discovery
ENUM lookup of NAPTR in DNS
aka call routing data (CRD) derived from ENUM record
service location (lookup of NAPTR and SRV) in DNS
lookup of A and AAAA in DNS
addressing and session establishment
routing protocols, ARP, …
Internet2 VoIP 19
SPEERMINT: Peering Network Context
Public (L3)
Private (L3)
L3 Peering Point(out of scope)
EnterpriseProvider A (L5)
EnterpriseProvider B (L5)
ServiceProvider C (L5)
ServiceProvider D (L5)
EnterpriseProvider E (L5)
ServiceProvider G (L5)
EnterpriseProvider F (L5)
ServiceProvider H (L5)
Public Peering Function/Federation Entity Location Function
Sohel Khan, Ph.D., Sprint-Nextel
Private Peering Function/Federation Entity Location Function
Internet2 VoIP 20
SPEERMINT: Reference peering architecture
Enables media paths interconnection between endpoints MFSF
Enables discovery of SF or exchanges policy/parameters to be used by SF OF
Enables discovery of the SF or OFLF
PurposeRef.
Security
QF Negotiates and reserves bandwidth resources, as well as polices/provides measurements for media paths
SIP Service Provider Y
SIP Service Provider X
OF OF
SF SF
MF MF
QF QF
AFAF
Security
Sohel Khan, Ph.D., Sprint-Nextel
LF LFLF
Enables discovery of endpoints, assists in discovery and exchange of parameters to be used with the MF
AF Application Function: TBD or deleted
Internet2 VoIP 21
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)
• 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
Internet2 VoIP 22
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
• 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
Internet2 VoIP 23
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 24
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
• 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)
Internet2 VoIP 25
SIP-managed
DHT
OpenDHT
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
Internet2 VoIP 26
P2P-SIP: Implementation in SIPc
• OpenDHT– Trusted nodes– Robust– Fast enough (<1s)
• Identity protection– Certificate-based– SIP id == email
• P2P forCalls, IM, presence, offline message, STUN server discovery and name search
Internet2 VoIP 27
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 28
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 29
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 30
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 31
Trouble in Standards Land• 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, …
OASIS
IEEE
IETF
W3CISO (MPEG)
L2.5-L7protocols
dataexchange
dataformats
L1-L2
3G
PP
Pack
etC
abl
e
Internet2 VoIP 32
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 33
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 34
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 35
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