VoIP and SIP

1
VoIP and SIP growing up

• Henning Schulzrinne
• (with Wenyu Jiang)
• Columbia University
• VON Spring 2003 March/April 2003
• San Jose, CA

2
Overview

• What happened in 2002?
• standards milestones
• deployment
• Outlook for 2003
• 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?

3
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

4
RFC 3261

• Backward compatible with RFC 2543 no new
  version
• Major changes
• specification behavior-oriented, not
  header-oriented
• e.g., separation into layers
• 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
• 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

5
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 doesnt trust user user only partially trusts network
L1/2-specific generic
walled garden open access
6
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

7
SIP products

• Still no/few cheap (lt 100) phones, but getting
  closer
• video-conferencing equipment still lacking
• turn-key IP PBX-in-a-box available from
  multiple vendors

• many good software clients
• PDA clients emerging
• despite industry issues, robust set of
  participants at

8
SIP standardization in 2002

• Probably point of maximum activity for SIP work
• There have been at least (in my collection of
  6428 distinct IETF I-Ds)
• 210 distinct I-Ds with sip (not counting -00,
  -01, etc.)
• 83 with sipping
• 34 with simple
• Current status somewhat difficult to track
• not all WG I-Ds are draft-ietf-
• many drafts start as draft-somebody-
• IETF draft tracking is iffy (complete only after
  WG done)
• JAIN activities in 2002
• SIP servlet API
• JAIN SIP lite

WG RFCs IESG or RFC editor WG I-Ds
SIP 17 11 10
SIPPING 4 9 12
SIMPLE 0 6 0
9
Other SIP RFCs published in 2002

• DHCP options for SIP servers
• The Session Initiation Protocol (SIP) UPDATE
  Method
• Integration of Resource Management and Session
  Initiation Protocol (SIP)
• Internet Media Type message/sipfrag
• A Privacy Mechanism for the Session Initiation
  Protocol (SIP)
• Private Extensions to the Session Initiation
  Protocol (SIP) for Asserted Identity within
  Trusted Networks
• Session Initiation Protocol (SIP) Extension for
  Instant Messaging
• The Reason Header Field for the Session
  Initiation Protocol (SIP)
• Session Initiation Protocol (SIP) Extension
  Header Field for Registering Non-Adjacent
  Contacts
• User Requirements for the Session Initiation
  Protocol (SIP) in Support of Deaf, Hard of
  Hearing and Speech-impaired Individuals
• Session Initiation Protocol for Telephones
  (SIP-T) Context and Architectures
• Short Term Requirements for Network Asserted
  Identity
• Integrated Services Digital Network (ISDN) User
  Part (ISUP) to Session Initiation Protocol (SIP)
  Mapping

10
Major SIP standardization items left to do

• Conferencing
• conference creation ad-hoc and pre-arranged
• call leg events ? conference membership tracking
• floor control SIP events SOAP
• Application interaction
• DTMF control (instead of INFO, complementary to
  RFC 2833)
• e.g., KPML for causing HTTP POST on digit
  combinations
• User identity via S/MIME

• Debugging and call history
• Content indirection
• Emergency (911) calls
• Presence and IM
• session mode (INVITE-initiated)
• UPDATE for presence updates
• is-composing event while typing
• limit message rate
• delivery confirmation
• more detailed presence status
• SIMPLE Java APIs

11
SIP standardization

• After this, mostly into maintenance mode
• track bugs and eventually issue RFC 3261bis
• Will SIP progress to Draft Standard?
• hardly unique
• 883 Proposed Standard RFCs, 99 Draft Standard, 66
  Standard
• unlikely ? too many external dependencies (TLS,
  S/MIME, SRV, NAPTR, )
• lots of work (interop statements) ? too little
  motivation

12
Rich presence

• Most presence systems only show basic in/out
  information
• Manually maintained ? often not accurate

13
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

14
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

15
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

16
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

17
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 lt 20 ms achievable

18
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)

19
Is SIP still simple?

• 25 SIP RFCs ( SDP), 823 pages
• and the call flows RFCs arent out yet ?
• RFC 3261 is longest RFC ever
• 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

20
What has SIP become?

• Session Initiation Protocol 2 out of 3 words
  are wrong (or too narrow)
• Plesiosynchronous end-to-end message delivery
• with real-time confirmation (unlike email)
• but modest rates (unlike RTP)
• either as session or stand-alone (page-mode)
• Rendezvous find end point via abstract address
• Components for specific functionality
• session setup and negotiation
• event notification sessions
• page-mode message delivery
• binding management
• Transport from UDP ? UDP TCP ? TCP SCTP UDP

21
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 doesnt scale
• tftp is insecure and for LAN only
• need configuration for identities, protocol
  parameters

22
Performance metrics for VoIP end-points

• Mouth-to-ear (M2E) delay
• compare network delay
• Clock skew
• whether it causes any voice glitches
• amount of clock drift
• Silence suppression behavior
• whether the voice is clipped (depends much on
  hangover time)
• robustness to non-speech input, e.g., music
• Robustness to packet loss
• voice quality under packet loss
• Acoustic echo cancellation
• Jitter adaptation delay gt max(jitter)?

23
Example mouth-ear delay

• 3Com to Cisco, shown with gaps gt 1sec
• Delay adjustments correlate with gaps, despite
  3Com phone has no silence suppression

24
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

end-point A end-point B A ? B B ? A
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
25
Summary of QoS findings

• Average mouth-to-ear delay
• Low (mostly lt 80ms) for hardware IP phones
• Software clients lowest for Messenger 2000
  (68.5ms)
• Application (receiver) most vital in determining
  delay
• Poor implementation easily undoes good network
  QoS
• Clock skew high on some software clients
• Packet loss concealment quality
• Acceptable in all 3 IP phones tested
• Silence detector behavior
• 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

26
Service availability

• Users do not care about QoS
• at least not about packet loss, jitter, delay
• FEC and PLC can deal with losses up to 5-8
• rather, its service availability ? how likely is
  it that I can place a call and not get
  interrupted?
• availability MTBF / (MTBF MTTR)
• 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
• ATT 99.98 availability (1997)
• IP frame relay SLA 99.9
• UK mobile phone survey 97.1-98.8

27
Availability PSTN metrics

• PSTN metrics (Worldbank study)
• fault rate
• should be less than 0.2 per main line
• fault clearance ( MTTR)
• next business day
• call completion rate
• during network busy hour
• varies from about 60 - 75
• dial tone delay

28
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
29
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
30
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)

31
Network outages
32
Outage-induced call abortion proability

• Long interruption ? user likely to abandon call
• from E.855 survey Pholding 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
33
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 whats-SIP-good-at
  emerging, but different visions