SIP and Beyond

1. SIP and Beyond Henning Schulzrinne Department of Computer Science Columbia University hgs@cs.columbia.edu Collaboration in the Enterprise February 10, 2005 (Leesburg, VA) Collaboration in the Enterprise

2. Overview • SIP as the glue for collaboration • Context-aware communications • The need for standards in collaboration • Interoperability & extensibility • The future of standards-based collaboration: • session mobility • central-server conferences • application sharing Collaboration in the Enterprise

3. (Early) Adulthood • “fully developed and mature” • Not quite yet, but no longer a teenager • probably need another 6 years to be grown up… • Responsibilities: • Dealing with elderly relatives  POTS • Financial issues  payments, RADIUS • Family emergencies  911 Collaboration in the Enterprise

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- Collaboration in the Enterprise

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 Collaboration in the Enterprise

6. What is SIP? • Session Initiation Protocol  protocol that establishes, manages (multimedia) sessions • also used for IM, presence & event notification • uses SDP to describe multimedia sessions • Developed at Columbia U. (with others) • started approximately 1996, first standard 1999 • Standardized by • IETF (RFC 3261-3265 et al), ca. 2002 • 3GPP (for 3G wireless) • PacketCable (DCS) • About 100 companies produce SIP products • Microsoft’s Windows Messenger (≥4.7) includes SIP Collaboration in the Enterprise

7. Origins and evolution of SIP multicast IM & presence 3G (mobile voice) voice (PSTN replacement) multimedia cable VoIP centralized conferencing Collaboration in the Enterprise

8. Filling in the protocol gap Collaboration in the Enterprise

9. Rendezvous protocol lets users find each other by only knowing a permanent identifier Mobility enabler: personal mobility one person, multiple terminals terminal mobility one terminal, multiple IP addresses session mobility one user, multiple terminals in sequence or in parallel service mobility services move with user SIP as service enabler Collaboration in the Enterprise

10. Philosophy • Session establishment & event notification • Any session type, from audio to circuit emulation • Provides application-layer anycast service • Provides terminal and session mobility • Based on HTTP in syntax, but different in protocol operation • Peer-to-peer system, with optional support by proxies • even stateful proxies only keep transaction state, not call (session, dialogue) state • transaction: single request + retransmissions • proxies can be completely stateless Collaboration in the Enterprise

11. Basic SIP message flow Collaboration in the Enterprise

12. SIP trapezoid destination proxy (identified by SIP URI domain) outbound proxy 1st request SIP trapezoid 2nd, 3rd, … request a@foo.com: 128.59.16.1 registrar voice traffic RTP Collaboration in the Enterprise

13. response request request line INVITE sip:bob@there.com SIP/2.0 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:alice@here.com> To: Bob <sip:bob@there.com> Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 147 Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:alice@here.com> To: Bob <sip:bob@there.com> Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 134 header fields v=0 o=alice 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 v=0 o=bob 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 messagebody SIP message format Collaboration in the Enterprise SDP

14. 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 Collaboration in the Enterprise Security & privacy

15. 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 Collaboration in the Enterprise

16. Presence as communication facilitator Collaboration in the Enterprise

17. 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 Collaboration in the Enterprise

18. 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?” • 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 Collaboration in the Enterprise

19. 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 Collaboration in the Enterprise

20. Presence = special case of event notification “user Alice is available for communication” Human users: 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, …) Events in multimedia systems: REFER (call transfer) message waiting indication conference floor control conference membership push-to-talk system configuration General events: emergency alert (“reverse 911”) industrial sensors (“boiler pressure too high”) business events (“more than 20 people waiting for service”) Presence and event notification Collaboration in the Enterprise

21. IETF efforts • SIP, SIPPING and SIMPLE working groups • but also XCON (conferencing) • Define SIP methods PUBLISH, SUBSCRIBE, NOTIFY • GEOPRIV: • geospatial privacy • location determination via DHCP • information delivery via SIP, HTTP, … • privacy policies • SIMPLE: • architecture for events and rich presence • configuration (XCAP) • session-oriented IM (↔ page mode) • filtering, rate limiting and authorization Collaboration in the Enterprise

22. Presence data model “calendar” “cell” “manual” person (presentity) (views) alice@example.com audio, video, text r42@example.com video services devices Collaboration in the Enterprise

23. 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 Collaboration in the Enterprise

24. 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 Collaboration in the Enterprise

25. Composition program: complex conditions and transformations complexity rule-based: most recent; source quality union of tuples capability Collaboration in the Enterprise

26. Future work: sources • Composition may need to resolve conflicts • calendar says meeting, but user is driving • Composition relies on source information: • information gathering: sensor, manual, calendar • relative trustworthiness (sensor vs. manual) • how recently updated? • does place and time make activity likely? • Will likely add source information to presence data • already started for geo data Collaboration in the Enterprise

27. GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) target location server location recipient notification interface publication interface GEOPRIV SUBSCRIBE presentity presence agent watcher SIP presence PUBLISH NOTIFY caller callee SIP call INVITE INVITE Collaboration in the Enterprise

28. RPID = rich presence • Provide watchers with better information about the what, where, how of presentities • facilitate appropriate communications: • “wait until end of meeting” • “use text messaging instead of phone call” • “make quick call before flight takes off” • designed to be derivable from calendar information • or provided by sensors in the environment • allow filtering by “sphere” – the parts of our life • don’t show recreation details to colleagues Collaboration in the Enterprise

29. 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 Collaboration in the Enterprise

30. RPID: rich presence Collaboration in the Enterprise

31. Rich presence – describing presentity • class: label elements for grouping and selection • i-belong-to: AOR contact in tuple belongs to • proposed element • status-icon • icon URL with hint for watcher user interface Collaboration in the Enterprise

32. Rich presence – describing service • relationship • a communication service offered by • a family member • associate (colleague) • assistant • supervisor • service-class: type of service offered • electronic • delivery (courier) • postal • in-person Collaboration in the Enterprise

33. Rich presence – describing state • mood of presentity • afraid, amazed, angry, annoyed, anxious, ashamed, bored, brave, calm, cold, confused, contented, cranky, curious, depressed, disappointed, disgusted, distracted, embarrassed, excited, flirtatious, frustrated, grumpy, guilty, happy, hot, humbled, humiliated, hungry, hurt, impressed, in_awe, in_love, indignant, interested, invincible, jealous, lonely, mean, moody, nervous, neutral, offended, playful, proud, relieved, remorseful, restless, sad, sarcastic, serious, shocked, shy, sick, sleepy, stressed, surprised, thirsty, worried • likely derived from • game state • manual input • lie detector + fMRI (later) Collaboration in the Enterprise

34. Rich presence – describing activities • sphere • current state and role • free text • e.g., “work”, “home”, “soccer club”, “PTA” • activities: what is the person doing • away, appointment, busy, holiday, in-transit, meal, meeting, on-the-phone, performance, permanent-absence, sleeping, steering, travel, vacation Collaboration in the Enterprise

35. Rich presence – describing place and surroundings • place-type: type of surroundings • aircraft, airport, bus, car, home, hotel, industrial, library, mall, office, outdoors, public, public-transport, restaurant, school, ship, station, street, theater, train, truck • place-is: communication properties • video: bright, dark • audio: noisy, quiet • privacy:communication that is private • audio, video, text • time-offset: minutes from UTC • for avoiding middle-of-the-night calls Collaboration in the Enterprise

36. Rich presence – describing user—device interactions • How long has the user not provided input to the device? • e.g., microphone input, keyboard, mouse activity idle active idle-threshold Collaboration in the Enterprise

37. CIPID: Contact Information • More long-term identification of contacts • Elements: • card – contact Information • home page • icon – to represent user • map – pointer to map for user • sound – presentity is available Collaboration in the Enterprise

38. Rich presence: time information • Presence is currently about here and now • but often only have (recent) past – e.g., calendar • or future • “will be traveling in two hours” • “will be back shortly” • allows watcher to plan communication RPID from until time timed-status timed-status now Collaboration in the Enterprise

39. 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> Collaboration in the Enterprise

40. Privacy policy relationships common policy geopriv-specific presence-specific future RPID CIPID Collaboration in the Enterprise

41. Conditions identity, sphere time of day current location identity as <uri> or <domain> + <except> Actions watcher confirmation Transformations include information reduced accuracy User gets maximum of permissions across all matching rules privacy-safe composition: removal of a rule can only reduce privileges Extendable to new presence data rich presence biological sensors mood sensors Privacy rules Collaboration in the Enterprise

42. Example rules document <rule id=1> <identity><id>user@example.com</id></identity> <conditions> <sub-handling>allow</sub-handling> <actions> <provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme> </provide-services> <provide-person>true</provide-person> <provide-activities>true</provide-activities> <provide-user-input>bare</provide-user-input> <ruleset> <transformations> Collaboration in the Enterprise

43. Creating and manipulating rules • Uploaded in whole or part via XCAP • XML not user-visible • Web or application UI, similar to mail filtering • Can also be location-dependent • “if at home, colleagues don’t get presence information” • Possibly implementation-defined “privacy levels” Collaboration in the Enterprise

44. Program location-based services Collaboration in the Enterprise

45. SIP extensions and interoperability Collaboration in the Enterprise

46. SIP: designed for managed extensions • Engineered for managed long-term extensibility: • cannot assume that all implementations implement everything • describe what to do with unknown protocol elements • registry of header fields • indication and discovery of features • New SIP header fields: • ignored if unknown • provide more information, don’t change behavior • avoid silly x- headers • private, limited-users headers (branded with “P-”) • most common extension today • New SIP methods • rarely done outside standards • discovery via OPTIONS request • SIP behavior changes via Require, Proxy-Require, Supported, Unsupported header fields • names behaviors, not fields Collaboration in the Enterprise

47. How to ensure protocol interoperability • Classical Internet approach: pairwise lab testing • Interoperability tests (“plug fests”) • multiple implementation, in various stages of maturity • results (and embarrassment) remain private • Certification by neutral third parties • can never be complete • Lab tests by consulting and publishing companies •  SIP is using all of these Collaboration in the Enterprise

48. Interoperability efforts • IETF SIPPING working group • call flow examples for basic (RFC 3665), telephony (RFC 3666) and services (draft) • basic user agent capabilities (draft-sinnreich-sipdev-req) • SIPit and SIMPLEt • held every 6 months • 15th instance of SIPit (and 3rd of SIMPLEt) just completed • 200 people from ~75 organizations tested around 100 implementations • ETSI • TTCN specs • SIP Forum Certification Working Group Collaboration in the Enterprise

49. SIPit 15 (Aug. 2004) • 128 attendees from 55 organizations • US, Canada, Israel, Japan, Taiwan, France, Germany, Belgium, UK, Turkey, India, Sweden, Finland, Norway • “The biggest strides between this event and the last were around correct support for TLS. The biggest weakness continues to be proper construction of offers and answers.” Collaboration in the Enterprise

50. 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 Collaboration in the Enterprise