Moving VoIP beyond the phone Henning Schulzrinne Dept. of Computer Science Columbia University September 2005

2 Overview The big transitions in VoIP Voice, media  meta data rich presence, caller preferences, events, … Programmable VoIP services servers and end systems Spam and spit Emergency calling (“9-1-1”) beyond PSTN replacement Maintaining reliable systems administratively distributed systems

September Philosophy transition One computer/phone, many users One computer/phone, one user Many computers/phones, one user anywhere, any time any media right place (device), right time, right media ~ ubiquitous computing  embedded VoIP mainframe era home phone party line PC era cell phone era

September Collaboration in transition intra-organization; small number of systems (meeting rooms) inter-organization multiple technology generations diverse end points proprietary (single- vendor) systems standards-based solutions

September Evolution of VoIP “amazing – the phone rings” “does it do call transfer?” “how can I make it stop ringing?” catching up with the digital PBX long-distance calling, ca going beyond the black phone

September Internet services – the missing entry Service/deliverysynchronousasynchronous pushinstant messaging presence event notification session setup media-on-demand messaging pulldata retrieval file download remote procedure call peer-to-peer file sharing

September Filling in the protocol gap Service/deliverysynchronousasynchronous pushSIP RTSP, RTP SMTP pullHTTP ftp SunRPC, Corba, SOAP (not yet standardized)

September An eco system, not just a protocol SIP XCAP (config) RTSP SIMPLE policy RPID …. SDP XCON (conferencing) STUN TURN RTP configures initiatescarries controls provide addresses

September SIP – a bi-cultural protocol overlap dialing DTMF carriage key systems notion of lines per-minute billing early media ISUP & BICC interoperation trusted service providers multimedia IM and presence location-based service user-created services decentralized operation everyone equally suspect

September SIP is PBX/Centrex ready call waiting/multiple calls RFC 3261 holdRFC 3264 transferRFC 3515/Replaces conferenceRFC 3261/callee caps message waitingmessage summary package call forwardRFC 3261 call parkRFC 3515/Replaces call pickupReplaces do not disturbRFC 3261 call coverageRFC 3261 from Rohan Mahy’s VON Fall 2003 talk simultaneous ringing RFC 3261 basic shared linesdialog/reg. package barge-inJoin “Take”Replaces Shared-line “privacy” dialog package divert to adminRFC 3261 intercomURI convention auto attendantRFC 3261/2833 attendant consoledialog package night serviceRFC 3261 centrex-style features boss/admin features attendant features

September SIP design objectives new features and services support features not available in PSTN e.g., presence and IM, session mobility not a PSTN replacement not just SS7-over-IP even similar services use different models (e.g., call transfer) client heterogeneity clients can be smart or dumb (terminal adapter) mobile or stationary hardware or software client multiplicity one user – multiple clients – one address multimedia nothing in SIP assumes a particular media type Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

September Interconnection approaches PropertyNGN, 3GPP“Internet” interconnectionper serviceservice neutral end device controlcarrier-controlleduser-provided end device typemostly hardwaresoftware, maybe hardware state preferencecall state-fullstateless transaction-stateful interconnect arrangement pre-arrangedserendipitous interconnect discoverypre-configuredDNS billing preferenceper service usage-based bandwidth-based services fixed-rate or ad- supported billing arrangementclearing housesender keeps independent

September The role of presence Guess, ring and annoy high probability of failure: “telephone tag” inappropriate time (call during meeting) inappropriate media (audio in public place) current solutions: voice mail  tedious, doesn’t scale, hard to search and catalogue, no indication of when call might be returned automated call back  rarely used, too inflexible  most successful calls are now scheduled by Presence-based facilitates unscheduled communications provide recipient-specific information only contact in real-time if destination is willing and able appropriately use synchronous vs. asynchronous communication guide media use (text vs. audio) predict availability in the near future (timed presence) Prediction: almost all (professional) communication will be presence-initiated or pre-scheduled

September Context-aware communication context = “the interrelated conditions in which something exists or occurs” anything known about the participants in the (potential) communication relationship both at caller and callee timeCPL capabilitiescaller preferences locationlocation-based call routing location events activity/availabilitypresence sensor data (mood, bio)privacy issues similar to location data

September Basic presence Role of presence initially: “can I send an instant message and expect a response?” now: “should I use voice or IM? is my call going to interrupt a meeting? is the callee awake?” Yahoo, MSN, Google, Skype presence services: on-line & off-line useful in modem days – but many people are (technically) on- line 24x7 thus, need to provide more context + simple status (“not at my desk”) entered manually  rarely correct if user has time to update presence, they are not busy enough to use presence does not provide enough context for directing interactive communications

September Presence data model “calendar”“cell”“manual” audio, video, text video person (presentity) (views) services devices

September Presence data architecture raw presence document create view (compose) privacy filtering draft-ietf-simple-presence-data-model composition policy privacy policy presence sources XCAP (not defined yet) depends on watcher select best source resolve contradictions PUBLISH

September Presence data architecture candidate presence document watcher filter raw presence document post-processing composition (merging) final presence document difference to previous notification SUBSCRIBE NOTIFY remove data not of interest watcher

September Rich presence More information automatically derived from sensors: physical presence, movement electronic activity: calendars Rich information: multiple contacts per presentity device (cell, PDA, phone, …) service (“audio”) activities, current and planned surroundings (noise, privacy, vehicle, …) contact information composing (typing, recording audio/video IM, …)

September RPID: rich presence

September The role of presence for call routing Two modes: watcher uses presence information to select suitable contacts advisory – caller may not adhere to suggestions and still call when you’re in a meeting user call routing policy informed by presence likely less flexible – machine intelligence “if activities indicate meeting, route to tuple indicating assistant” “try most-recently-active contact first” (seq. forking) LESS translate RPID CPL PA PUBLISH NOTIFY INVITE

September Presence and privacy All presence data, particularly location, is highly sensitive Basic location object (PIDF-LO) describes distribution (binary) retention duration Policy rules for more detailed access control who can subscribe to my presence who can see what when <gml:Point gml:id="point1“ srsName="epsg:4326"> 37:46:30N 122:25:10W no T04:57:29Z T20:57:29Z

September Location-based services Finding services based on location physical services (stores, restaurants, ATMs, …) electronic services (media I/O, printer, display, …) not covered here Using location to improve (network) services communication incoming communications changes based on where I am configuration devices in room adapt to their current users awareness others are (selectively) made aware of my location security proximity grants temporary access to local resources

September Location-based SIP services Location-aware inbound routing do not forward call if time at callee location is [11 pm, 8 am] only forward time-for-lunch if destination is on campus do not ring phone if I’m in a theater outbound call routing contact nearest emergency call center send to nearest location-based events subscribe to locations, not people Alice has entered the meeting room subscriber may be device in room  our lab stereo changes CDs for each person that enters the room

September Program location-based services

September Service creation programmer, carrier end user network servers SIP servlets, sip-cgi CPL end systemVoiceXML scripting, RPC VoiceXML (voice), LESS Tailor a shared infrastructure to individual users traditionally, only by vendors (and sometimes carriers) learn from web models: killer app  vertical apps

September A different view of presence Presence is problematic for facilitating calls rapid changes + large watcher lists  high notification volume privacy: don’t want to tell whole life story to all watchers  on-demand presence information just before communication = SUBSCRIBE with zero duration aggregate presence  synchronized calendars either centralized or peer-to-peer Likely uses shifting to true events environment changes (traffic, weather, …) people changes (visitor stuck in traffic)

September Programming VoIP clients Precursor: CTI but rarely used outside call centers Call external programs e.g., Google/MSN maps, local search Scripting APIs e.g., call Tcl or PHP scripts  sip-cgi Controllable COM, XML RPC used for media agents in sipc Embeddable no UI, just signaling and media

September Automating media interaction – service examples If call from my boss, turn off the stereo  call handling with device control As soon as Tom is online, call him  call handling with presence information Vibrate instead of ring when I am in movie theatre  call handling with location information At 9:00AM on 09/01/2005, find the multicast session titled “ABC keynote” and invite all the group members to watch  call handling with session information When incoming call is rejected, send to the callee  call handling with

September LESS: simplicity Generality (few and simple concepts) Uniformity (few and simple rules) Trigger rule Switch rule Action rule Modifier rule Familiarity (easy for user to understand) Analyzability (simple to analyze) switchestriggeractions modifiers

September LESS: Decision tree  No loops  Limited variables  Not necessarily Turing-complete

September LESS: Safety Type safety Strong typing in XML schema Static type checking Control flow safety No loop and recursion One trigger appear only once, no feature interaction for a defined script Memory access No direct memory access LESS engine safety Ensure safe resource usage Easy safety checking Any valid LESS scripts can be converted into graphical representation of decision trees.

September LESS snapshot <device:turnoff incoming call If the call from my boss Turn off the stereo Accept the call with only audio trigger, switch, modifier, action

September Device agent x10vcr SIP user agent SIP LESS packages Basic user agent GenericMediaUI conference web calendar im Presence agent presence Event Use packages to group elements locationsession

September When Tom is online, … ………

September When I am in a movie theatre, …

September

September Interfacing with Google 911: caller location IM/presence: location of friends call: “I’m here”

September Interfacing with Google show all files from caller Xiaotao Wu

September Embedding VoIP: FAA training controls pilot and ATC agents – using multicast and unicast (“landlines”)

September Open issues: application sharing Current: T.120 doesn’t integrate well with other conference control mechanisms hard to make work across platforms (fonts) ill-defined security mechanisms Current: web-based sharing hard to integrate with other media, control and record generally only works for Windows mostly limited to shared PowerPoint Current: vnc whole-screen sharing only can be coerced into conferencing, but doesn’t integrate well with control protocols

September IETF effort: standardized application sharing Remote access = application sharing Four components: window drawing ops  PNG keyboard input mouse input window operations (raise, lower, move) Uses RTP as transport synchronization with continuous media but typically, TCP allow multicast  large group sessions

September SIP unsolicited calls and messages Possibly at least as large a problem more annoying (ring, pop-up) Bayesian content filtering unlikely to work  identity-based filtering PKI for every user unrealistic Use two-stage authentication SIP identity work home.com Digest mutual PK authentication (TLS)

September Domain Classification Classification of domains based on their identity instantiation and maintenance procedures plus other domain policies. Admission controlled domains Strict identity instantiation with long term relationships Example: Employees, students, bank customers Bonded domains Membership possible only through posting of bonds tied to a expected behavior Membership domains No personal verification of new members but verifiable identification required such as a valid credit card and/or payment Example: E-bay, phone and data carriers Open domains No limit or background check on identity creation and usage Example: Hotmail Open, rate limited domains Open but limits the number of messages per time unit and prevents account creation by bots Example: Yahoo

September Reputation service (“Trust paths”) Alice Bob Carol David Emily Frank has sent to has sent IM to is this a spammer? for people and domains

September Emergency calling FCC mandate: all interconnected VoIP providers must provide E911 service by 11/05 switch calls to right PSAP (via ESGW attached to switches) deliver location information to PSAP for dispatch location entered manually Problems: user-entered location  no nomadic, mobile users PSAP infrastructure brittle (38 PSAPs out after Katrina)  fully IP-based allow relocation

September What makes VoIP 112/911 hard? POTSPSTN-emulation VoIPend-to-end VoIP (landline) phone number limited to limited area landline phone number anywhere in US (cf. German 180) no phone number or phone number anywhere around the world regional carriernational or continent-wide carrierenterprise “carrier” or anybody with a peer-to-peer device voice provider = line provider (~ business relationship) voice provider ≠ ISP national protocols and call routing probably North America + EUinternational protocols and routing location = line locationmostly residential or small business stationary, nomadic, wireless

September Location, location, location Location  locate right PSAP & speed dispatch In the PSTN, local calls remain geographically local In VoIP, no such locality for VSPs most VSPs have close to national coverage Thus, unlike landline and wireless, need location information from the very beginning Unlike PSTN, voice service provider doesn’t have wire database information VSP needs assistance from access provider (DSL, cable, WiMax, , …)

September Options for location delivery L2: LLDP-MED (standardized version of CDP + location data) periodic per-port broadcast of configuration information L3: DHCP for geospatial (RFC 3825) civic (draft-ietf-geopriv-dhcp-civil) L7: proposals for retrievals by IP address by MAC address by identifier (conveyed by LLDP, DHCP or PPP) via HTTP or maybe SIP

September Architecture DHCP home ISP SIP config outbound proxy VSP PSAPs

September LUMP mapping architecture flooding nj.us ny.us bergen.nj.us leonia.bergen.nj.us RR R R R R knows all trees; caches results carrier X customers generalizes to other location-based services

September Emergency call conferencing INVITE 3 rd party call control INVITE REFER Conference server PSAP Recorder Fire department Hospital PSAP brings all related parties into a conference call INVITE media info INVITE media info Caller INVITE

Managing (VoIP) Applications – DYSWIS Henning Schulzrinne Dept. of Computer Science Columbia University July 2005

September Overview User experience for VoIP still inferior Existing network management doesn’t work for VoIP and other modern applications Need user-centric rather than operator- centric management Proposal: peer-to-peer management “Do You See What I See?” Also use for reliability estimation and statistical fault characterization

September VoIP user experience Only % call attempt success “Keynote was able to complete VoIP calls 96.9% of the time, compared with 99.9% for calls made over the public network. Voice quality for VoIP calls on average was rated at 3.5 out of 5, compared with 3.9 for public-network calls and 3.6 for cellular phone calls. And the amount of delay the audio signals experienced was 295 milliseconds for VoIP calls, compared with 139 milliseconds for public-network calls.” (InformationWeek, July 11, 2005) Mid-call disruptions Lots of knobs to turn Separate problem: manual configuration

September Traditional network management model SNMP X “management from the center”

September Assumptions Single provider (enterprise, carrier) has access to most path elements professionally managed Typically, hard failures or aggregate problems element failures substantial packet loss Mostly L2 and L3 elements switches, routers rarely APs Indirect detection MIB variable vs. actual protocol performance

September Managing the protocol stack RTP UDP/TCP IP SIP no route packet loss TCP neg. failure NAT time-out firewall policy protocol problem playout errors media echo gain problems VAD action protocol problem authorization asymmetric conn (NAT)

September Call lifecycle view get addresses SIP INVITE get 200 OK REGISTER exchange media terminate call STUN failure auth? registrar ? outbound proxy? dest. proxy? loss? gain? silence suppression?

September Types of failures Hard failures connection attempt fails no media connection NAT time-out Soft failures (degradation) packet loss (bursts) access network? backbone? remote access? delay (bursts) OS? access networks? acoustic problems (microphone gain, echo)

September Diagnostic undecidability symptom: “cannot reach server” more precise: send packet, but no response causes: NAT problem (return packet dropped)? firewall problem? path to server broken? outdated server information (moved)? server dead? 5 causes  very different remedies no good way for non-technical user to tell Whom do you call?

September Additional problems ping and traceroute no longer works reliably WinXP SP 2 turns off ICMP some networks filter all ICMP messages Early NAT binding time-out initial packet exchange succeeds, but then TCP binding is removed (“web-only Internet”)

September “Do You See What I See?” Each node has a set of active measurement tools Nodes can ask others for their view possibly also dedicated “weather stations” Iterative process, leading to: user indication of cause of failure in some cases, work-around (application-layer routing)  TURN server, use remote DNS servers Nodes collect statistical information on failures and their likely causes

September Failure detection tools STUN server what is your IP address? ping and traceroute Transport-level liveness open TCP connection to port send UDP ping to port media RTP UDP/TCP IP

September Failure statistics Which parts of the network are most likely to fail (or degrade) access network network interconnects backbone network infrastructure servers (DHCP, DNS) application servers (SIP, RTSP, HTTP, …) protocol failures/incompatibility Currently, mostly guesses End nodes can gather and accumulate statistics

September How to find management peers? Use carrier-provided bootstrap list Previous session partners e.g., address book Watcher list

September What’s missing? Request diagnostic “send this message”; return result do specific high-level operation (ping, traceroute, DNS resolution) Failure statistics protocol and data exchange format Algorithm specification for steps “if no response to REGISTER, check server liveness” “if bad voice QoS, ask subnet neighbor; then ask somebody close to destination”

September Security issues Indirect denial-of-service attacks limit per-requestor rate return cached results to querier Lying Non-participation (“leechers”) usual P2P mechanisms such as blacklists

September Conclusion Slow transition from emulating PSTN to new services presence-based embedded (e.g., games) Emphasis moving from protocol mechanics to architecture slow transition to open systems different combinations of software vendors, IAP/ISP, VSP, hardware vendors Still need to fill out infrastructure for collaboration and presence Protocols  systems  infrastructure replacement Management from the center  management from the edges