1. VoIP - Moving from protocols to architecture(s) Henning Schulzrinne Dept. of Computer Science Columbia University September 2005

2. 2 Overview The big transitions in VoIP An Internet protocol framework Open issues in VoIP and interactive multimedia communications service creation and programmable systems VoIP: poll model  presence model application sharing SIP architecture and design philosophy Philosophies: Skype, IETF, NGS, …

3. September 2005 3 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 mainframe era home phone party line PC era cell phone era

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

5. September 2005 5 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

6. September 2005 6 Current challenges Protocol (point) challenges 9-1-1 support location mapping presence configuration and policy automated system configuration System challenges 9-1-1 reliability (incl. consistent QoS) manageability by non-experts cross-domain AAA inter-domain trust

7. September 2005 7 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

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

9. September 2005 9 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

10. September 2005 10 A constellation of SIP RFCs Resource mgt. (3312) Reliable prov. (3262) INFO (2976) UPDATE (3311) Reason (3326) SIP (3261) DNS for SIP (3263) Events (3265) REFER (3515) DHCP (3361) DHCPv6 (3319) Digest AKA (3310) Privacy (3323) P-Asserted (3325) Agreement (3329) Media auth. (3313) AES (3853) Non-adjacent (3327) Symmetric resp. (3581) Service route (3608) User agent caps (3840) Caller prefs (3841) ISUP (3204) sipfrag (3240) Security & privacy Configuration Core Mostly PSTN Content types Request routing

11. September 2005 11 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

12. September 2005 12 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

13. September 2005 13 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

14. September 2005 14 SIP architectural principles (1) proxies are for routing do not maintain call state availability scalability flexibility extensibility (new methods, services) end point call state and features dialog models, not call models does not standardize features endpoint fate sharing call fails only if endpoints fail component-based design building blocks call features = notification and manipulation logical components, not physical UA, proxy, registrar, redirect server can be combined into one box Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

15. September 2005 15 SIP architectural principles (2) designed for the (large) Internet does not assume particular network topology congestion-controlled deals with packet loss uses core Internet services: DNS for load balancing DHCP for configuration S/MIME for e2e security TLS for channel security generality over efficiency focuses on algorithm efficiency, not constant- factor encoding efficiency “efficiency penalty is temporary, generality is permanent” text encoding extensibility use shim layer for compression where needed allow splitting of functionality for scaling

16. September 2005 16 SIP architectural principles (3) separation of signaling and media path followed by media packets independent of signaling path allows direct routing of latency-sensitive media packets (10 ms matters) without constraining service delivery (1s matters) facilitates mobility avoid “hair pinning”, “tromboning” facilitates vertical split between ISP and VSP

17. September 2005 17 SIP design principles (1) Proxies are method, body and header independent does not depend on method except CANCEL, ACK can add new methods without upgrading proxies primarily rely on URI, Via, Route and Record-Route header fields extensions: Accept- Contact and Request- Disposition may use anything to guide routing decision Full-state nature of INVITE each (re)INVITE contains full session state facilitates MIDCOM-style interactions allows session transfer SIP URIs identify resources can be device instance, service, person but cannot tell from URI which (good!) can specify services and service parameters

18. September 2005 18 SIP design principles (2) Extensibility and compatibility can define new methods, header fields, body types, parameters supported by OPTIONS, Accept, Accept-Language, Allow, Supported, Require, Proxy-Require, Accept- Encoding and Unsupported “asking permission” OPTIONS, dialog establishment “asking forgiveness” use extension without asking (Proxy)-Require: “please reject if you don’t understand it” “use if you like” allow recipients to safely ignore information must provide fallback! Internationalization UTF-8 for freeform text negotiation of languages Explicit intermediaries = SIP proxies unlike transparent HTTP proxies or NAT boxes, announce themselves Via, Record-Route only involved if asked by UA or proxy should ask endpoints, rather than just do e.g., session policy

19. September 2005 19 SIP design principles (3) Guided proxy routing predetermine a set of downstream proxy resource that must be visited supported by Record- Route, Path, Service- Route Transport protocol independence can use UDP, TCP, SCTP, … only requires packet-based (unreliable) delivery design decision that comes with some regret Protocol reuse MIME for body transport S/MIME for end-to-end security HTTP header field and semantics HTTP digest authentication URI framework non-SIP URIs (e.g., tel:) re-use TLS for channel security use DNS SRV and NAPTR for server failover and reliability

20. September 2005 20 SIP division of labor proxyB2BUAUA Statestateless transaction- stateful call stateful Headersinspect insert modify (rarely) inspect insert modify inspect reflect Bodiesignore some inspect inspect insert modify inspect Forkyesseparate call legsno Medianomaybeyes Servicesrendezvous call routing call statefulmedia-related

21. September 2005 21 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

22. September 2005 22 IETF “4G” (access-neutral) model columbia.eduexample.com sip:alice@columbia.edu  sip:bob@example.com TLS DIAMETER server 802.1x NSIS NTLP for QoS Visited network AP Check reputation of columbia.edu alice@isp.net isp.net

23. September 2005 23 Session Border Controllers (SBCs) Provider border element SIP terms: either B2BUA or proxies but often ill-defined (may change roles) Functions differ similar definitional problem as “soft switches” May force convergence of media and signaling path

24. September 2005 24 SBCs: High-level motivations Why application-layer elements in SIP that are not quite proxies? SMTP has various MTAs, but they are just MTAs (e.g., spam filter) Guesses: media vs. control separation good idea in theory, harder in today’s limited-functionality Internet force media through single control point (IP address) rather than from millions of sources see Asterix, Skype proxy model of no content (SDP) inspection or modification too limited CALEA (needs to be invisible) charging for services not an issue for email and web

25. September 2005 25 SBC functionality, cont’d Signaling functionality: Protocol Conversion H.323  SIP Protocol integrity - SIP normalization ENUM – SIP redirect Policy enforcement and access control CDR creation Firewall (dest. port, source) Least-cost routing Certificate handling Caller-ID authorization Signaling encryption S/MIME encapsulation TCP/UDP-TLS bridging DoS attack mitigation Media functionality: Codec conversion SLA enforcement Legal Intercept & CALEA compliance Bandwidth Management Packet marking QoS guarantees Packet steering Media encryption Firewall (pinholes) DoS attack mitigation

26. September 2005 26 SBC: Network evolution SBC earlier: email, IM only IP-level (with filter) stand-alone networks (Vonage, Skype) media

27. September 2005 27 SBC: Concerns Common concerns: may drop some header fields may fail to understand some request methods may modify headers inserted by others may modify session descriptions may inspect session descriptions Not all SBCs do this all the time, but some do some of this sometimes…

28. September 2005 28 SBC: The dangers May not be present in all instances SBCs are a box description, not a function description Lack of visibility cannot tell where SBC is located hard to diagnose failures see HTTP “transparent proxy” experience one example: TP thought SIP was HTTP hard to address content cryptographically to such box Lack of transparency not all features make it through SBC header support copying content routing loops Lack of security Inherent conflict between need for media session inspection and session privacy Session description modification removes accountability Lack of scalability needs to handle all media packets often, call stateful rather than stateless or transaction-stateful

29. September 2005 29 What’s left to do? Transition from “poll” model to context-based communications Higher-level service creation in end systems Dealing with NATs STUN (and SIP modifications) as first step ICE and BEHAVE WG as longer-term solutions The role of intermediaries session-border controllers end-to-middle security session policies Conference control Application sharing Security issues (spam, spit --> identity and reputation management)

30. September 2005 30 The role of presence Guess-and-ring 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 email 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

31. September 2005 31 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

32. September 2005 32 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, 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 does not provide enough context for directing interactive communications

33. September 2005 33 Presence data model “calendar”“cell”“manual” alice@example.com audio, video, text r42@example.com video person (presentity) (views) services devices

34. September 2005 34 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

35. September 2005 35 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

36. September 2005 36 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, …)

37. September 2005 37 RPID: rich presence

38. September 2005 38 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

39. September 2005 39 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 2003-06-23T04:57:29Z 2003-06-22T20:57:29Z

40. September 2005 40 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

41. September 2005 41 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 delivery@pizza.com to nearest branchdelivery@pizza.com 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

42. September 2005 42 Program location-based services

43. September 2005 43 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

44. September 2005 44 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 email to the callee  call handling with email

45. September 2005 45 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

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

47. September 2005 47 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.

48. September 2005 48 LESS snapshot <device:turnoff device=“sip:stereo_room1@abc.com”/> incoming call If the call from my boss Turn off the stereo Accept the call with only audio trigger, switch, modifier, action

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

50. September 2005 50 When Tom is online, … ………

51. September 2005 51 When I am in a movie theatre, …

52. September 2005 52

53. September 2005 53 Programming VoIP clients Precursor: CTI but rarely used outside call centers Call external programs e.g., Google 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

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

55. September 2005 55 Interfacing with Google show all files from caller Xiaotao Wu

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

57. September 2005 57 Conference control Setting up parameterized conferences SIP INVITE and NOTIFY suffice for basic dial-in conference functionality and change notification IETF XCON WG struggling with model and complexity

58. September 2005 58 XCON System Logical XCON Server Floor Control Client TEMPLATE Of the SYSTEM: Pre-configured Initial/Default values Conf Event Notification Server Focus CPCP Client CCCP Client CPCP Server CCCP Server Call Signaling Client TEMPLATE Policy: Of TYPE RULES RESERVATION Policy: Of TYPE RULES CURRENT Policy: Of TYPE RULES RESERVATION Of the INSTANCE: Of TYPE CONFERENCE-INFO STATE Of the CURRENT INSTANCE: Of TYPE CONFERENCE-INFO Notification Client Floor Control Server SIP/ PSTN/ H.323 T.120/ Etc. CCCP CPCP SIP NOTIFY/ Etc. BFCP Logical XCON Client

59. September 2005 59 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

60. September 2005 60 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

61. September 2005 61 Spam and spit

62. September 2005 62 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)

63. September 2005 63 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

64. September 2005 64 Reputation service Alice Bob Carol David Emily Frank has sent email to has sent IM to is this a spammer?

65. September 2005 65 SIP standards & deployment issues and competition Interoperability Proprietary systems

66. September 2005 66 cable DSL op Cisco CM Provider combinations software hardware ISP IAP VSP Skype mobile operators?

67. September 2005 67 VoIP service providers Google MSN Yahoo! Xbox mostly IM no PSTN (now) AT&T (Vantage) Verizon (VoiceWing) JP SoftBank (8.3m) Cable (911,000): ComCast primary line replacement voice only Skype Vonage (1m)

68. September 2005 68 Protocol interoperability problems Three core interoperability problems: syntactic robustness “You mean you could have a space there?” often occurs when testing only against common reference implementations need “stress test” (also for buffer overflows) implementation by protocol example limiting assumptions (e.g., user name format) see “SIP Robustness Testing for Large-Scale Use”, First International Workshop on Software Quality (SOQA) semantic assumptions “I didn’t expect this error” mutually incompatible extensions expect extension to make something work

69. September 2005 69 Protocol interoperability: proprietary protocols Proprietary protocol Example: Skype quicker evolution – not dependent on IETF “volunteers” with day jobs can do “hacks” without IESG objection: media over TCP inefficient search bypass routing policies circumvent firewall policies Can only reverse-engineer  only backwards- compatibility problems incentive to force upgrades (see Microsoft Word) less Metcalfe’s law value

70. September 2005 70 Why is Skype successful? All the advantages of a proprietary protocol Peer-to-peer coincidental Good out-of-box experience Software vendor = service provider Didn’t know that you couldn’t do voice quality beyond PSTN others too focused on PSTN interoperability – why do better voice than PSTN? Simpler solutions for NAT traversal use TCP if necessary use port 80 Did encryption from the very beginning Kazaa marketing vehicle

71. September 2005 71 Skype vs. SIP-based systems SkypeSIP-based providers Protocolproprietary, encrypted SIP to gateways open (SIP), often plain-text sometimes IAX to gateway Business modelprepaid outbound PSTN calls (SkypeOut) monthly fee (Vonage) free (FWD) prepaid (SIPgate.de) Protocol modelsingle “network”, bridge to PSTNsome closed some semi-open (*-codes) Allow federation?not currentlyyes NAT traversalintegratedseparated (STUN) User agentsoftware only (USB phones) software and hardware primarily market hardware User interfacepresence-likephone-like

72. September 2005 72 Open standard, dominant vendor Example: H.323 doesn’t matter what the standard says NetMeeting and H.323  test with Microsoft implementation limits feature evolution to dominant vendor speed and interests

73. September 2005 73 Open standard, multiple vendors Example: SIP More than just one application: Software UAs, proxies, phones, gateways, media servers, test tools, OA&M, … interoperability problems likely until product maturity harder to test internally against all (competing) products divergent views and communities in IETF and other SDOs likely have to support union of requirements emphasis on extensibility, modularity and protocol re-use  temptation to not implement everything security SIP: generality over efficiency better long-term outcome, but slower

74. September 2005 74 The SIP complexity fallacy IAX (for example) is simpler than SIP but you could build the IAX functionality in SIP at just about the same complexity: no proxies no codec negotiation no distributed services Difficulty: extracting those simple pieces from 269 pages of specification (+ SDP + RTP) SIP still more complex due to signaling-data separation Signaling & Media Signaling Media IAX model SIP, H.323, MCGP model

75. September 2005 75 Does it have to be that complicated? highly technical parameters, with differing names inconsistent conventions for user and realm made worse by limited end systems (configure by multi-tap) usually fails with some cryptic error message and no indication which parameter out-of-box experience not good

76. September 2005 76 Solving the configuration mess Initial development assumed enterprise deployment pre-configured via tftp or (rarely) DHCP not suitable for residential use, except if box is shipped pathetic security – password accessible to anybody who knows MAC address of phone Short term adopt simple default conventions should only need SIP URI (AoR), display name and password realm = URI outbound proxy = domain provide and expose error feedback not “authentication failure” but “realm not recognized – change to user@domain format” use DNS NAPTR and SRV for STUN server

77. September 2005 77 Solving the configuration mess – longer term IETF efforts on configuration management retrieve via HTTP (+ TLS) change notification via SIP event notification problem of configuring initial secret remains probably need embedded public keys Still need better diagnostics one-way voice issues authentication failures

78. September 2005 78 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 Standardization bodies face challenges of overlap and resource exhaustion