Vo IP and SIP growing up Henning Schulzrinne

Vo. IP and SIP – growing up Henning Schulzrinne (with Wenyu Jiang) Columbia University VON Spring 2003 – March/April 2003 San Jose, CA

Overview n What happened in 2002? n n n Outlook for 2003 n n n n standards milestones deployment substantial completion? addressing the VASA challenges rich presence and conferencing SIP services multi-network wireless SIP challenges Recent measurement results: n n How good is end system Qo. S? How reliable is the current Internet?

What happened in 2002? n New revision of SIP RFCs published n n RFC 3261: basic protocol specification RFC 3262: Reliability of Provisional Responses n n n 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 n n Backward compatible with RFC 2543 – no new version Major changes: n specification behavior-oriented, not header-oriented n n n 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 n n n 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 3 G wireless networks n n n In July, 3 GPP adopts SIP as signaling protocol for Release 5 increased collaboration between organizations still somewhat different perspectives: 3 GPP IETF network doesn’t trust user only partially trusts network L 1/2 -specific generic walled garden open access

SIP adoption in 2002 n IBM, Novell support SIMPLE for group communications in the enterprise n n n 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 n PRIM concluded without spec, APEX fading 3 GPP adopts SIMPLE as IM/presence mechanism for Release 6 commercial services for consumers and businesses n n Vonage, Denwa, e. Stara, … MCI Worldcom, Delta. Three

SIP products n n n Still no/few cheap (< $100) phones, but getting closer video-conferencing equipment still lacking turn-key “IP PBX-ina-box” available from multiple vendors n n n many good software clients PDA clients emerging despite industry “issues”, robust set of participants at

Major SIP standardization items left to do n Conferencing n n n n Debugging and call history Content indirection Emergency (911) calls Presence and IM: n Application interaction n n conference creation – adhoc and pre-arranged call leg events conference membership tracking floor control = SIP events + SOAP n n DTMF control (instead of INFO, complementary to RFC 2833) e. g. , KPML for causing HTTP POST on digit combinations n n n User identity via S/MIME n n 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 n n 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 n Extension to basic SIMPLE/CPIM presence: n n n n n 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 n n n In progress: adding location information to SIP Also needed for "911" services Mechanisms: n n n GPS – doesn't work indoors DHCP location beacons Leverage the privacy mechanism in SIP presence to restrict access: n n explicit approval mutual trust "fuzzy" data for some (e. g. , time zone only) restrict by time-of-day

Integrating 2 G, 3 G and 802. 11 wireless n n SIP is ideal integration tool One identifier, many devices n n n 802. 11 at work, home, VON, airport, … 2 G/2. 5 G/3 G while traveling Automatically switch between networks n n n invisible to callers can hand-off during mid-call can add and delete media: n video while in 802. 11 hotspot

Creating services n n n 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 Voice. XML 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 n n VASA "SIP in carrier networks" Assumes traditional business model n n ignores SIP enterprise interconnection Challenges: n n n 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 Qo. S call setup times of <= 20 ms achievable

CALEA n n n Not a Vo. IP problem, but rather an Internet "problem" Except for precedent, why different from email and IM? Extreme position: n n n 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 Vo. IP 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? n 25 SIP RFCs (+ SDP), 823 pages n n RFC 3261 is longest RFC ever n n and the call flows RFCs aren’t out yet by bytes, RFC 2801 (IOTP) wins by page count However… n n n probably only (3 GPP) 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: n n TLS, digest, S/MIME, AAA, … DOS protection

What has SIP become? n n Session Initiation Protocol – 2 out of 3 words are wrong (or too narrow…) Plesiosynchronous end-to-end message delivery n n n Rendezvous: find end point via abstract address Components for specific functionality: n n n 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 + TCP + SCTP + UDP

General Vo. IP infrastructure n n One cannot build a service on SIP alone Other items still need work: n n AAA for SIP, both RADIUS (widely used, but obsolete) and DIAMETER security infrastructure n n 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: n n 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 Vo. IP end-points n Mouth-to-ear (M 2 E) delay n n Clock skew n n n whether the voice is clipped (depends much on hangover time) robustness to non-speech input, e. g. , music Robustness to packet loss n n whether it causes any voice glitches amount of clock drift Silence suppression behavior n n compare network delay voice quality under packet loss Acoustic echo cancellation Jitter adaptation: delay > max(jitter)?

Example mouth-ear delay n n 3 Com to Cisco, shown with gaps > 1 sec Delay adjustments correlate with gaps, despite 3 Com phone has no silence suppression

Mouth-to-ear delay measurements n 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 B GSM PSTN 115 ms 109 ms 3 Com Cisco 51 ms 63 ms Net. Meeting 401 ms 421 ms Messenger XP 109 ms 120 ms

Summary of Qo. S findings n Average mouth-to-ear delay: n n n Low (mostly < 80 ms) for hardware IP phones Software clients: lowest for Messenger 2000 (68. 5 ms) Application (receiver) most vital in determining delay n n n Clock skew high on some software clients Packet loss concealment quality n n Acceptable in all 3 IP phones tested Silence detector behavior n n Poor implementation easily undoes good network Qo. S 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 n n Users do not care about Qo. S at least not about packet loss, jitter, delay n n n rather, it’s service availability how likely is it that I can place a call and not get interrupted? availability = MTBF / (MTBF + MTTR) n n n 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 n n 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 n n 62, 027 calls succeeded, 292 failed 99. 53% availability roughly constant across I 2, I 2+, commercial ISPs All 99. 53% Internet 2 99. 52% Internet 2+ 99. 56% Commercial 99. 51% Domestic (US) 99. 45% International 99. 58% Domestic commercial 99. 39% International commercial 99. 59%

Overall network loss n PSTN: once connected, call usually of good quality n n exception: mobile phones compute periods of time below loss threshold n n 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 I 2 97. 7 99. 67 99. 79 I 2+ 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 n sustained packet losses n n n n 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. , I 2 and commercial)

Outage-induced call abortion proability n n n 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 12 s 2, 566 have at least one outage 946 of 2, 566 expected to be dropped 1. 53% of all calls all 1. 53% I 2 1. 16% I 2+ 1. 15% ISP 1. 82% US 0. 99% Int. 1. 78% US ISP 0. 86% Int. ISP 2. 30%

Conclusion n SIP standardization nearing completion n core functionality sufficient to build n n n 3 G mobile system corporate PBX but need more operational experience efforts still telephony-centric, but combinations IM + Vo. IP emerging architectural model for “what’s-SIP-good -at” emerging, but different visions