Transcript SIP – growing up - Columbia University

VoIP and SIP – growing up
Henning Schulzrinne
(with Wenyu Jiang)
Columbia University
VON Spring 2003 – March/April 2003
San Jose, CA
Overview

What happened in 2002?



Outlook for 2003







standards milestones
deployment
substantial completion?
addressing the VASA challenges
rich presence and conferencing
SIP services
multi-network wireless
SIP challenges
Recent measurement results:


How good is end system QoS?
How reliable is the current Internet?
What happened in 2002?

New revision of SIP RFCs published


RFC 3261: basic protocol specification
RFC 3262: Reliability of Provisional
Responses



RFC 3263: Locating SIP Servers
RFC 3264: An Offer/Answer Model with the
Session Description Protocol (SDP)
RFC 3265: SIP-specific Event Notification
RFC 3261


Backward compatible with RFC 2543 – no new version
Major changes:

specification behavior-oriented, not header-oriented





mandate support for UDP and TCP
formal offer/answer model for media negotiation
uses both SRV and NAPTR for server location, load balancing and
redundancy
much more complete security considerations





e.g., separation into ‘layers’
“sips:’’ for secured (TLS) path
PGP removed due to lack of use
Basic authentication removed as unsafe
S/MIME added for protecting message bodies (and headers, via
encapsulation)
Route/Record-Route simplified
SIP and 3G wireless networks



In July, 3GPP adopts SIP as signaling
protocol for Release5
increased collaboration between
organizations
still somewhat different perspectives:
3GPP
IETF
network doesn’t trust
user
user only partially trusts network
L1/2-specific
generic
walled garden
open access
SIP adoption in 2002

IBM, Novell support SIMPLE for group
communications in the enterprise



but still confusion by Microsoft: MSN Messenger 5.0 (no SIP)
vs. Windows Messenger 4.7 (SIP + MSN, but mostly for XP)
AOL backing off from interoperability
IETF adds Jabber to the IM standards confusion



PRIM concluded without spec, APEX fading
3GPP adopts SIMPLE as IM/presence mechanism for
Release6
commercial services for consumers and businesses


Vonage, Denwa, eStara, …
MCI Worldcom, DeltaThree
SIP products



Still no/few cheap
(< $100) phones,
but getting closer
video-conferencing
equipment still
lacking
turn-key “IP PBX-ina-box” available
from multiple
vendors



many good software
clients
PDA clients emerging
despite industry
“issues”, robust set of
participants at
Major SIP standardization items
left to do

Conferencing







Debugging and call history
Content indirection
Emergency (911) calls
Presence and IM:


Application interaction



conference creation – adhoc and pre-arranged
call leg events 
conference membership
tracking
floor control = SIP events +
SOAP


DTMF control (instead of
INFO, complementary to
RFC 2833)
e.g., KPML for causing HTTP
POST on digit combinations



User identity via S/MIME

session mode (INVITEinitiated)
UPDATE for presence
updates
is-composing event while
typing
limit message rate
delivery confirmation
more detailed presence
status
SIMPLE Java APIs
Rich presence


Most presence systems only show basic
in/out information
Manually maintained  often not accurate
everything
watcher
PUA
PA
watcher
PUBLISH
NOTIFY
"vague"
watcher
INVITE
CPL
Rich presence: RPIDS

Extension to basic SIMPLE/CPIM presence:









What kind of presentity?
What activity? (driving, travel, vacation, …)
What kind of place?
Is there privacy?
When was this status valid?
When was the user last active?
If out, who else might be available? (Assistant,
colleague, family, …)
What are the device capabilities?
Generated from calendars, keyboard activity,
location beacons
Rich presence: locations



In progress: adding location information to SIP
Also needed for "911" services
Mechanisms:



GPS – doesn't work indoors
DHCP location beacons
Leverage the privacy mechanism in SIP presence to
restrict access:




explicit approval
mutual trust
"fuzzy" data for some (e.g., time zone only)
restrict by time-of-day
Integrating 2G, 3G and 802.11
wireless


SIP is ideal integration tool
One identifier, many devices



802.11 at work, home, VON, airport, …
2G/2.5G/3G while traveling
Automatically switch between networks



invisible to callers
can hand-off during mid-call
can add and delete media:

video while in 802.11 hotspot
Creating services






The web does not have a killer application,
but does enable local, decentralized service
development
JAIN APIs in progress and helpful, but need
end user and vertical-market services
VoiceXML for voice (IVR) services
CPL for proxy routing services
LESS for end system services (with abstract
UI)
Extensions of CPL for presence and IM
VASA challenges


VASA "SIP in carrier networks"
Assumes traditional business model


ignores SIP enterprise interconnection
Challenges:





interoperability  SIPit, SIP Forum certification
(soon)
Gov't issues: CALEA, 911  in IETF
Scalability  SIPstone for sessions; still needed
for IM &P
NAT and firewalls  can solve, but adds
complexity  need NAT recommendations
QoS  call setup times of <= 20 ms achievable
CALEA



Not a VoIP problem, but rather an Internet "problem"
Except for precedent, why different from email and
IM?
Extreme position:





must disallow all end-to-end encryption (except with key
escrow)  security risks
thus, only government approved proxies and end systems
either ISP must intercept all packets or VoIP provider must
force voice packets through intercept device
Thus, not just equal treatment to PSTN
See (e.g.,) SLEM Internet-Draft (published today)
Is SIP still simple?

25 SIP RFCs (+ SDP), 823 pages


RFC 3261 is longest RFC ever


and the call flows RFCs aren’t out yet 
by bytes, RFC 2801 (IOTP) wins by page count
However…



probably only (3GPP) proxy writers need to worry
about most of these
can still build a simple user agent in a (long)
evening
most effort is likely to be for security:


TLS, digest, S/MIME, AAA, …
DOS protection
What has SIP become?


Session Initiation Protocol – 2 out of 3 words are wrong (or too
narrow…)
Plesiosynchronous end-to-end message delivery





Rendezvous: find end point via abstract address
Components for specific functionality:





with real-time confirmation (unlike email)
but modest rates (unlike RTP)
either as session or stand-alone (“page-mode”)
session setup and negotiation
event notification sessions
page-mode message delivery
binding management
Transport: from UDP  UDP + TCP  TCP + SCTP + UDP
General VoIP infrastructure


One cannot build a service on SIP alone
Other items still need work:


AAA for SIP, both RADIUS (widely used, but obsolete) and
DIAMETER
security infrastructure




how to authenticate to callee?
cheap identities  even PKI mainly helps to identify caller on
second call
use OPTION to get callee certificate?
configuration of SIP devices:




configuring by keypad is a pain
configuration by web page doesn’t scale
tftp is insecure and for LAN only
need configuration for identities, protocol parameters
Performance metrics for VoIP
end-points

Mouth-to-ear (M2E) delay


Clock skew





whether the voice is clipped (depends much on hangover
time)
robustness to non-speech input, e.g., music
Robustness to packet loss


whether it causes any voice glitches
amount of clock drift
Silence suppression behavior


compare network delay
voice quality under packet loss
Acoustic echo cancellation
Jitter adaptation: delay > max(jitter)?
Example mouth-ear delay

3Com to Cisco, shown with gaps > 1sec
Delay adjustments correlate with gaps,
despite 3Com phone has no silence
suppression 60 experiment
1-1
experiment 1-2
silence gaps
M2E delay (ms)

55
50
45
40
35
0
50
100
150 200
time (sec)
250
300
350
Mouth-to-ear delay
measurements

We measured mouth-to-ear one-way delay of a range
of commercial SIP phones and software applications,
in a LAN
AB
BA
end-point A
end-point B
GSM
PSTN
115 ms
109 ms
3Com
Cisco
51 ms
63 ms
NetMeeting
NetMeeting
401 ms
421 ms
Messenger XP
Messenger XP
109 ms
120 ms
Summary of QoS findings

Average mouth-to-ear delay:



Low (mostly < 80ms) for hardware IP phones
Software clients: lowest for Messenger 2000 (68.5ms)
Application (receiver) most vital in determining delay



Clock skew high on some software clients
Packet loss concealment quality




Acceptable in all 3 IP phones tested
Silence detector behavior


Poor implementation easily undoes good network QoS
Long hangover time, works well for speech input
But may falsely predict music as silence
Acoustic echo cancellation: good on most IP phones
Playout delay behavior: good based on initial tests
Service availability


Users do not care about QoS
at least not about packet loss, jitter, delay



rather, it’s service availability  how likely is it that I
can place a call and not get interrupted?
availability = MTBF / (MTBF + MTTR)



FEC and PLC can deal with losses up to 5-8%
MTBF = mean time between failures
MTTR = mean time to repair
availability = successful calls / first call attempts




equipment availability: 99.999% (“5 nines”)  5
minutes/year
AT&T: 99.98% availability (1997)
IP frame relay SLA: 99.9%
UK mobile phone survey: 97.1-98.8%
Call success probability


62,027 calls
succeeded, 292
failed  99.53%
availability
roughly constant
across I2, I2+,
commercial ISPs
All
99.53%
Internet2
99.52%
Internet2+
99.56%
Commercial
99.51%
Domestic (US)
99.45%
International
99.58%
Domestic
commercial
99.39%
International
commercial
99.59%
Overall network loss

PSTN: once connected,
call usually of good
quality


exception: mobile phones
compute periods of time
below loss threshold


5% causes degradation
for many codecs
others acceptable till
20%
loss
0%
5%
10%
20%
All
82.3
97.48
99.16
99.75
ISP
78.6
96.72
99.04
99.74
I2
97.7
99.67
99.77
99.79
I2+
86.8
98.41
99.32
99.76
US
83.6
96.95
99.27
99.79
Int.
81.7
97.73
99.11
99.73
US
ISP
73.6
95.03
98.92
99.79
Int.
ISP
81.2
97.60
99.10
99.71
Network outages

sustained packet losses







arbitrarily defined at 8 packets
far beyond any recoverable loss (FEC,
interpolation)
23% outages
make up significant part of 0.25%
unavailability
symmetric: AB  BA
spatially correlated: AB   AX
not correlated across networks (e.g., I2 and
commercial)
Outage-induced call abortion
proability





Long interruption  user likely
to abandon call
from E.855 survey: P[holding]
= e-t/17.26 (t in seconds)
 half the users will abandon
call after 12s
2,566 have at least one
outage
946 of 2,566 expected to be
dropped  1.53% of all calls
all
1.53%
I2
1.16%
I2+
1.15%
ISP
1.82%
US
0.99%
Int.
1.78%
US ISP
0.86%
Int. ISP
2.30%
Conclusion

SIP standardization nearing completion

core functionality sufficient to build





3G mobile system
corporate PBX
but need more operational experience
efforts still telephony-centric, but
combinations IM + VoIP emerging
architectural model for “what’s-SIPgood-at” emerging, but different visions