voip year 10
Download
Skip this Video
Download Presentation
VoIP - Year 10+

Loading in 2 Seconds...

play fullscreen
1 / 35

VoIP - Year 10 - PowerPoint PPT Presentation


  • 48 Views
  • Uploaded on

VoIP - Year 10+. Henning Schulzrinne Dept. of Computer Science Columbia University [email protected] Overview. VoIP status IETF WG status Deployment-related issues security peering software ossification robustness configuration NATs. Evolution of VoIP. “how can I make it

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'VoIP - Year 10' - aldon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
voip year 10

VoIP - Year 10+

Henning Schulzrinne

Dept. of Computer Science

Columbia University

[email protected]

Internet2 VoIP

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

Internet2 VoIP

evolution of voip
Evolution of VoIP

“how can I make it

stop ringing?”

long-distance calling,

ca. 1930

“does it do

call transfer?”

going beyond

the black phone

“amazing – the

phone rings”

catching up

with the digital PBX

1996-2000

2000-2003

2004-

Internet2 VoIP

sip is pbx centrex ready
SIP is PBX/Centrex ready

boss/admin features

centrex-style features

attendant features

from Rohan Mahy’s VON Fall 2003 talk

Internet2 VoIP

ietf voip efforts
IETF VoIP efforts

ECRIT

(emergency calling)

ENUM

(E.164 translation)

SIMPLE

(presence)

uses

SPEERMINT

(peering)

GEOPRIV

(geo + privacy)

uses

may use

uses

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

Internet2 VoIP

a constellation of sip rfcs
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

Content types

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

sip sipping simple 00 drafts
SIP, SIPPING & SIMPLE –00 drafts

includes draft-ietf-*-00 and draft-personal-*-00

Internet2 VoIP

rfc publication
RFC publication

Internet2 VoIP

ietf wg sip
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

ietf wg sipping
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

voip emergency communications
VoIP emergency communications

emergency call

emergency alert

(“inverse 911”)

dispatch

civic coordination

Internet2 VoIP

ietf ecrit working group
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

ecrit options for location delivery
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

ecrit finding the correct psap
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

Internet2 VoIP

ecrit lost functionality
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

lost location to url mapping
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

NJ

US

NY

US

sip:[email protected]

search

referral

Bergen County

NJ US

Leonia

NJ US

Internet2 VoIP

lost architecture
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  sip:[email protected]

Internet2 VoIP

speermint session interconnect
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

speermint peering network context
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

Internet2 VoIP

Sohel Khan, Ph.D., Sprint-Nextel

speermint reference peering architecture
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

Ref.

Purpose

LF

Enables discovery of the SF or OF

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

Internet2 VoIP

ietf wg avt
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

ietf wg mmusic
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

ietf wg p2p sip
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

p2psip applications motivation
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

three basic approaches
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

p2p sip implementation in sipc
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

open issues nats
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

does it have to be that complicated
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

open issues configuration
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

open issues summary
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

trouble in standards land
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

Internet2 VoIP

ietf issues
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

ietf issue timeliness
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

ietf issues timeliness
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

conclusion
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

ad