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? 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?

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

SIP and 3G wireless networks In July, 3GPP adopts SIP as signaling protocol for Release5 increased collaboration between organizations still somewhat different perspectives: 3GPPIETF network doesn’t trust useruser only partially trusts network L1/2-specificgeneric walled gardenopen 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-in- a-box” available from multiple vendors many good software clients PDA clients emerging despite industry “issues”, robust set of participants at

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 WGRFCsIESG or RFC editor WG I-Ds SIP SIPPING4912 SIMPLE060

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

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

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

Rich presence Most presence systems only show basic in/out information Manually maintained  often not accurate PA watcher PUA watcher PUBLISH NOTIFY everything "vague" CPL INVITE

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 wireless SIP is ideal integration tool One identifier, many devices 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 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 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 and the call flows RFCs aren’t 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

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

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

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 Aend-point BA  BB  A GSMPSTN115 ms109 ms 3ComCisco51 ms63 ms NetMeeting 401 ms421 ms Messenger XP 109 ms120 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 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

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, it’s 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: % (“5 nines”)  5 minutes/year AT&T: 99.98% availability (1997) IP frame relay SLA: 99.9% UK mobile phone survey: %

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

Call success probability 62,027 calls succeeded, 292 failed  99.53% availability roughly constant across I2, I2+, commercial ISPs All99.53% Internet299.52% Internet % Commercial99.51% Domestic (US)99.45% International99.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% loss0%5%10%20% All ISP I I US Int US ISP Int. ISP

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)

Network outages

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 all1.53% I21.16% I2+1.15% ISP1.82% US0.99% Int.1.78% US ISP0.86% Int. ISP2.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-SIP- good-at” emerging, but different visions