VoIP - Moving from protocols to architecture(s)

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

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. Philosophy transition PC era cell phone era One computer/phone, many users One computer/phone, one user mainframe era home phone party line Many computers/phones, one user ~ ubiquitous computing anywhere, any time any media right place (device), right time, right media

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

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

6. 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 Current challenges

7. Internet services – the missing entry

8. Filling in the protocol gap

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

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

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

12. SIP is PBX/Centrex ready boss/admin features centrex-style features attendant features from Rohan Mahy’s VON Fall 2003 talk

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. 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 SIP architectural principles (1) Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

15. 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 SIP architectural principles (2)

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. 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 SIP design principles (1)

18. 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 SIP design principles (2)

19. 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 SIP design principles (3)

20. SIP division of labor

21. Interconnection approaches

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

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. 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. 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 SBC functionality, cont’d

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

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. 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 SBC: The dangers

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. 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) The role of presence Prediction: almost all (professional) communication will be presence-initiated or pre-scheduled

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

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. Presence data model “calendar” “cell” “manual” person (presentity) (views) alice@example.com audio, video, text r42@example.com video services devices

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

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

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. RPID: rich presence

38. The role of presence for call routing PUBLISH • 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) PA NOTIFY translate RPID CPL LESS INVITE

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 <tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1“ srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W </gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no </gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z </gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple>

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. 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 branch • 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. Program location-based services

43. Service creation • Tailor a shared infrastructure to individual users • traditionally, only by vendors (and sometimes carriers) • learn from web models: killer app vertical apps

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. 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) modifiers trigger switches actions

46. LESS: Decision tree • No loops • Limited variables • Not necessarily • Turing-complete

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. LESS snapshot incoming call <less> <incoming> <address-switch> <address is=“sip:myboss@abc.com"> <device:turnoff device=“sip:stereo_room1@abc.com”/> <media media=“audio”> <accept/> </media> </address> </address-switch> </incoming> </less> If the call from my boss Turn off the stereo Accept the call with only audio trigger, switch, modifier, action

49. SIP user agent SIP Device agent Presence agent Basic user agent presence Generic Media UI Event x10 vcr LESS packages • Use packages to group elements im email web calendar conference session location

50. When Tom is online, … <less> <EVENT:notification> <address-switch> <address is="sip:tom@example.com"> <EVENT:event-switch> <EVENT:event is="open"> <location url="sip:tom@example.com"> <IM:im message="Hi, Tom"/> </location> </EVENT:event> </EVENT:event-switch> ……… </less>