Evolution and Design of SIP Architecture in VoIP Communications

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

2. Overview • The big transitions in VoIP • An Internet protocol framework • Open issues in VoIP and interactive multimedia communications • service creation • VoIP: poll model  presence model • SIP architecture and design philosophy • Philosophies: Skype, IETF, NGS, … • Reflections on standardization • Integration of cellular and IP end systems

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. Internet services – the missing entry

7. Filling in the protocol gap

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

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. SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

11. RFC publication

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

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. UMTS Reference Architecture by KimmoRaatikainen

22. 3G Architecture (Registration) describes deployment architecture mobility management signaling serving interrogating interrogating CSCF proxy home IM domain registration signaling (SIP)_ visited IM domain

23. Classical IETF interfaces “UNI” “NNI” router proxy server SIP SIP signaling DNS DNS name mapping host end system UA DHCP, PPP BGP OSPF L3 config IPv4/IPv6 IPv4/IPv6 L3 Ethernet SONET L2

24. IETF interface approach • Essentially, only two types of entities • end systems (user agents, hosts, clients, …) • network systems (proxies, routers, servers, …) • No functional definitions or assumptions • SIP UA can be PSTN gateway or cell phone • (Mostly) strong separation of layers • IP-layer interface can change without SIP changing • Can replace routing protocol without affecting HTTP • Function defined by protocol actions • not general behavior (“gateway”) • Does not describe functional entities as such • web server + SIP UAC + router

25. IP “hourglass” email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio... Steve Deering, IETF Aug. 2001

26. The real Internet hourglass (slightly simplified) p2p (port 80) web web services HTTP TCP IP Ethernet

27. Interconnection approaches

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

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

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

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

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

33. 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…

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

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

36. P2P for autonomic computing • Autonomic at the application layer: • Robust against partial network faults • Resources grow as user population grows • Self-configuring • Traditional p2p systems • file storage • motivation is often legal, not technical, efficiency • usually unstructured, optimized for Zipf-like popularity • Other p2p applications: • Skype demonstrates usefulness for VoIP  • identifier lookup • NAT traversal: media traversal • OpenDHT (and similar) as emerging common infrastructure? • Non-DHT systems with smaller scope  web hotspot rescue • Network management (see our IRTF slides)

37. (1) REGISTER (2) INVITE alice Peer-to-peer network Alice 128.59.19.194 (3) 128.59.19.194 No central server, but more lookup latency What is SIP? Why P2P-SIP? (1) REGISTER alice@columbia.edu =>128.59.19.194 (2) INVITE alice@columbia.edu (3) Contact: 128.59.19.194 Alice’s host 128.59.19.194 Bob’s host columbia.edu Problem in client-server: maintenance, configuration, controlled infrastructure

38. SIP-using-P2P Replace SIP location service by a P2P protocol P2P-over-SIP Additionally, implement P2P using SIP messaging How to combine SIP + P2P? P2P network REGISTER INVITE alice FIND INSERT P2P-SIP overlay Alice 128.59.19.194 INVITE sip:alice@128.59.19.194 Alice 128.59.19.194

39. Deployment scenarios P P P P P P P P P P P P P P P P2P database P2P proxies P2P clients Zero-conf server farm; Trusted servers and user identities Global, e.g., OpenDHT; Clients or proxies can use; Trusted deployed peers (?) Plug and play; May use adaptors; Untrusted peers Interoperate among these!

40. Hybrid architecture • Cross register, or • Locate during call setup • DNS, or • P2P-SIP hierarchy

41. What else can be P2P? • Rendezvous/signaling (SIP) • Configuration storage • Media storage (e.g., voice mail) • Identity assertion (?) • PSTN gateway (?) • NAT/media relay (find best one) Trust models are different for different components!

42. What is our P2P-SIP? • Unlike server-based SIP architecture • Unlike proprietary Skype architecture • Robust and efficient lookup using DHT • Interoperability • DHT algorithm uses SIP communication • Hybrid architecture • Lookup in SIP+P2P • Unlike file-sharing applications • Data storage, caching, delay, reliability • Disadvantages • Lookup delay and security

43. Implementation: SIPpeer • Platform: Unix (Linux), C++ • Modes: • Chord: using SIP for P2P maintenance • OpenDHT: using external P2P data storage • Scenarios: • P2P client, P2P proxies • Adaptor for existing phones • Cisco, X-lite, Windows Messenger, SIPc • Server farm

44. Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP Implementation: SIPpeer Signup, Find buddies IM, call On reset Signout, transfer On startup Leave Find Join REGISTER, INVITE, MESSAGE Peer found/ Detect NAT Multicast REGISTER REGISTER SIP-over-P2P P2P-using-SIP

45. Advantages Out-of-box experience Robust catastrophic failure-unlikely Inherently scalable more with more nodes Status IETF involvement Columbia SIPpeer Security issues Trust, reputation malicious node, sybil attack SPAM, DDoS Privacy, anonymity (?) Other issues Lookup latency,proximity P2P-SIP vs SIP-using-P2P Why should I run as super-node? SIP p2p summary and open issues http://www.p2psip.org and http://www.cs.columbia.edu/IRT/p2p-sip

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

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

48. The role of presence • “Is the callee likely to be reachable?”  user-level presence • glue logic for loosely-coupled systems • events related to calls: • voicemail notification • call transfer notification • Events are a superset of presence: • publish, subscribe & notify • in SIMPLE, just differ in their • event type and bodies (typically, XML) • privacy policies • unlike other event systems, cross-domain, with security • but no content-dependent replication (Siena, Elvin, …)

49. 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?” • note: may not be continuous subscription, but rather on-demand (when trying to reach somebody) • 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

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