VoIP Year 10

1
VoIP - Year 10

• Henning Schulzrinne
• Dept. of Computer Science
• Columbia University
• hgs_at_cs.columbia.edu

2
Overview

• VoIP status
• IETF WG status
• Deployment-related issues
• security
• peering
• software
• ossification
• robustness
• configuration
• NATs

3
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-
4
SIP is PBX/Centrex ready
boss/admin features
centrex-style features
attendant features
from Rohan Mahys VON Fall 2003 talk
5
IETF VoIP efforts
ECRIT (emergency calling)
ENUM (E.164 translation)
SIMPLE (presence)
SPEERMINT (peering)
uses
GEOPRIV (geo privacy)
uses
uses
may use
XCON (conf. control)
SIP (protocol)
SIPPING (usage, requirements)
uses
provides
IPTEL (tel URL)
SPEECHSC (speech services)
usually used with
MMUSIC (SDP, RTSP, ICE)
AVT (RTP, SRTP, media)
SIGTRAN (signaling transport)
IETF RAI area
6
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
7
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
8
RFC publication
9
IETF WG SIP

• 44 SIP-related RFCs published
• Activities
• hitchhikers 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/
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

11
VoIP emergency communications
emergency call
dispatch
emergency alert (inverse 911)
civic coordination
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 --gt 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

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)

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

15
ECRIT LoST Functionality

• Satisfies the requirements (draft-ietf-ecrit-requi
  rements) 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

16
LoST Location-to-URL Mapping
VSP1
cluster serving VSP1
replicate root information
cluster serves VSP2
123 Broad Ave Leonia Bergen County NJ US
LoST
root nodes
NY US
NJ US
sippsap_at_leonianj.gov
search referral
Bergen County NJ US
Leonia NJ US
17
LoST Architecture
G
tree guide
G
G
G
broadcast (gossip)
T1 .us T2 .de
G
resolver
T2 (.de)
seeker 313 Westview Leonia, NJ US
T3 (.dk)
T1 (.us)
Leonia, NJ ? sippsap_at_leonianj.gov
18
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
19
SPEERMINT Peering Network Context
Public Peering Function/Federation Entity
Location Function
Enterprise Provider A (L5)
Enterprise Provider B (L5)
Public (L3)
Service Provider C (L5)
Service Provider D (L5)
L3 Peering Point (out of scope)
Enterprise Provider E (L5)
Enterprise Provider F (L5)
Private (L3)
Service Provider G (L5)
Service Provider H (L5)
Private Peering Function/Federation Entity
Location Function
Sohel Khan, Ph.D., Sprint-Nextel
20
SPEERMINT Reference peering architecture
LF
LF
LF
OF
OF
SF
SF
SIP Service Provider Y
SIP Service Provider X
MF
MF
QF
QF
AF
AF
Security
Security
Purpose
Ref.
Enables discovery of the SF or OF
LF
Enables discovery of SF or exchanges
policy/parameters to be used by SF
OF
Enables discovery of endpoints, assists in
discovery and exchange of parameters to be used
with the MF
SF
MF
Enables media paths interconnection between
endpoints
QF
Negotiates and reserves bandwidth resources, as
well as polices/provides measurements for media
paths
Application Function TBD or deleted
AF
Sohel Khan, Ph.D., Sprint-Nextel
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

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 --gt
  multiple addresses depending on context
• STUN
• configure media relay
• STUN with TURN functionality

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

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)

25
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
26
P2P-SIP Implementation in SIPc

• OpenDHT
• Trusted nodes
• Robust
• Fast enough (lt1s)
• Identity protection
• Certificate-based
• SIP id email
• P2P for
• Calls, IM, presence, offline message, STUN
  server discovery and name search

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 theres 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
• cant easily discover timeout --gt need
  high-frequency refresh --gt possibly high REGISTER
  load
• other random optimizations
• BEHAVE WG to define NAT behavioral guidelines

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

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

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 --gt cant prevent
  repeated problems (dentist problems)

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
data formats
W3C ISO (MPEG)
data exchange
IETF
L2.5-L7 protocols
IEEE
L1-L2
PacketCable
3GPP
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

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

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

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