Internet2 VoIPJanuary 11, 2007

VoIP - Year 10+

Henning SchulzrinneDept. of Computer Science

Columbia Universityhgs@cs.columbia.edu

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 example@psap1.org

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

sip:psap@leonianj.gov

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:psap@leonianj.gov

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