1. U Twente1 Advanced Multimedia and Presence Services using Classical and P2P SIP Henning Schulzrinne (with Kundan Singh, Ron Shacham, Xiaotao Wu, Jonathan Lennox and others) Department of Computer Science Columbia University hgs@cs.columbia.edu University of Twente May 20, 2005

2. U Twente2 Overview Quick overview of SIP Ring-and-hope  presence-mediated communications Uses for presence: Old: “I’m on-line” Location-based services Presence-derived call handling Presence-derived trust Presence and privacy Peer-to-peer SIP Service and session mobility Application sharing

3. U Twente3 Philosophy transition One computer, many users One computer, one user Many computers, one user anywhere, any time any media right place (device), right time, right media ~ ubiquitous computing mainframe era

4. U Twente4 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

5. U Twente5 SIP Overview

6. U Twente6 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

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

8. U Twente8 SIP as service enabler 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

9. U Twente9 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) Standardized by IETF (RFC 3261-3265 et al) 3GPP (for 3G wireless) PacketCable About 100 companies produce SIP products Microsoft’s Windows Messenger (≥4.7) includes SIP

10. U Twente10 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

11. U Twente11 Basic SIP message flow

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

13. U Twente13 SIP message format SDP INVITE sip:bob@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 147 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 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 134 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 message body header fields request line request response

14. U Twente14 PSTN vs. Internet Telephony Signaling & Media Signaling Media PSTN: Internet telephony: China Belgian customer, currently visiting US Australia

15. U Twente15 SIP addressing Users identified by SIP or tel URIs sip:alice@example.com tel: URIs describe E.164 number, not dialed digits (RFC 2806bis) tel URIs  SIP URIs by outbound proxy A person can have any number of SIP URIs The same SIP URI can reach many different phones, in different networks sequential & parallel forking SIP URIs can be created dynamically: GRUUs conferences device identifiers (sip:foo@128.59.16.15) Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR) tel:110 sip:sos@domain domain  128.59.16.17 via NAPTR + SRV

16. U Twente16 3G Architecture (Registration) visited IM domain home IM domain serving CSCF interrogating proxy interrogating mobility management signaling registration signaling (SIP)_

17. U Twente17 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

18. U Twente18 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

19. U Twente19 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

20. U Twente20 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

21. U Twente21 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

22. U Twente22 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

23. U Twente23 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

24. U Twente24 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

25. U Twente25 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

26. U Twente26 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, …)

27. U Twente27 RPID: rich presence

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

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

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

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

32. U Twente32 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

33. U Twente33 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

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

35. U Twente35 Program location-based services

36. U Twente36 Example: user-adaptive device configuration “all devices that are in the building” RFC 3082? PA device controller SUBSCRIBE to each room SUBSCRIBE to configuration for users currently in rooms 1.discover room URI 2.REGISTER as contact for room URI tftp HTTP SLP 802.11 signal strength  location REGISTER To: 815cepsr Contact: alice@cs SIP room 815

37. U Twente37 Session mobility Walk into office, switch from cell phone to desk phone call transfer problem  SIP REFER related problem: split session across end devices e.g., wall display + desk phone + PC for collaborative application assume devices (or stand-ins) are SIP- enabled third-party call control

38. U Twente38 How to find services? Two complementary developments: smaller devices carried on user instead of stationary devices devices that can be time-shared large plasma displays projector hi-res cameras echo-canceling speaker systems wide-area network access Need to discover services in local environment SLP (Service Location Protocol) allows querying for services “find all color displays with at least XGA resolution” slp://example.com/SrvRqst?public?type=printer SLP in multicast mode SLP in DA mode Need to discover services before getting to environment “is there a camera in the meeting room?” SLP extension: find remote DA via DNS SRV

39. U Twente39 Internet Correspondent Node (CN) SIP UA SLP UA SIP SM Local Devices SLP SA SLP UA SIP SM SIP UA SLP DA Mobile Node (MN) SLP SIP RTP SIP UA Transcoder Session mobility

40. U Twente40 Presence for spam prevention VoIP spam (“spit”) and IM spam (“spim”) likely to be more annoying than email spam Subscription to another person is indication of mutual trust other person allows me to see their status  trusts me Thus, use watcher list (who is watching me) as trust vector

41. U Twente41 Open issues for conferencing standardization Multi-device systems and session mobility Conference floor control  BFCP simple RPC-like protocol Centralized conference control (XCON WG) still struggling with control model set + get variables (~SNMP) RPC-like model (  SOAP, XML-RPC, NETCONF) send descriptions? forms (XForms?)?

42. U Twente42 Peer-to-peer SIP

43. U Twente43 What is P2P? Share the resources of individual peers CPU, disk, bandwidth, information, … C C C C C S P P P P P Computer systems CentralizedDistributed Client-server Peer-to-peer FlatHierarchicalPureHybrid mainframes workstations DNS mount RPC HTTP Gnutella Chord Napster Groove Kazaa File sharing Communication and collaboration Distributed computing SETI@Home folding@Home Napster Gnutella Kazaa Freenet Overnet Magi Groove Skype

44. U Twente44 P2P goals Resource aggregation - CPU, disk, … Cost sharing/reduction Improved scalability/reliability Interoperability - heterogeneous peers Increased autonomy at the network edge Anonymity/privacy Dynamic (join, leave), self organizing Ad hoc communication and collaboration

45. U Twente45 P2P goals [re-visited] Query time, number of messages, network usage, per node state P2P systems Unstructured Structured Data availability Decentralization Scalability Load balancing Fault tolerance Maintenance Join/leave Repair Efficient searching Proximity Locality If present => find it Flooding is not scalable Blind search is inefficient

46. U Twente46 Distributed Hash Table (DHT) Types of search Central index (Napster) Distributed index with flooding (Gnutella) Distributed index with hashing (Chord) Basic operations find(key), insert(key, value), delete(key), but no search(*) Properties/typesEvery peer has complete table ChordEvery peer has one key/value Search time or messages O(1)O(log(N))O(n) Join/leave messagesO(n)O(log(N) 2 )O(1)

47. U Twente47 Why P2P-SIP? Bob’s host Alice’s host 128.59.19.194 REGISTER alice@columbia.edu =>128.59.19.194 INVITE alice@columbia.edu Contact: 128.59.19.194 columbia.edu Client-server=> maintenance, configuration, controlled infrastructure P2P overlay Alice 128.59.19.194 REGISTER INVITE alice 128.59.19.194 No central server, search latency

48. U Twente48 Background: DHT (Chord) Identifier circle Keys assigned to successor Evenly distributed keys and nodes Finger table: logN i th finger points to first node that succeeds n by at least 2 i-1 Stabilization for join/leave 1 8 14 21 32 38 58 47 10 24 30 54 38 42 Keynode 8+1 = 914 8+2 = 1014 8+4 = 1214 8+8 = 1621 8+16=2432 8+32=4042 0 1 2 3 4 5 6 7 8

49. U Twente49 Architecture User interface (buddy list, etc.)SIPICERTP/RTCPCodecsAudio devicesDHT (Chord) On startup DiscoverUser location Multicast REGISTERPeer found/ Detect NAT REGISTER REGISTER, INVITE, MESSAGE Signup, Find buddies Join Find Leave On reset Signout, transfer IM, call SIP-over-P2P P2P-using-SIP

50. U Twente50 Adaptor for existing phones Use P2P-SIP node as an outbound proxy ICE for NAT/firewall traversal STUN/TURN server in the node

51. U Twente51 P2P vs. server-based SIP Prediction: P2P for smaller & quick setup scenarios Server-based for corporate and carrier Need federated system multiple p2p systems, identified by DNS domain name with gateway nodes

52. U Twente52 Conferencing issues

53. U Twente53 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

54. U Twente54 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

55. U Twente55 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

56. U Twente56 Conclusion Basic multimedia communication solutions available scalable, secure, good quality Media delivery  controlled interaction Binary presence  rich presence Presence as enabler of loosely-coupled advanced services location-based services serve as service script inputs trust indicator for spit/spim prevention Application sharing as missing link Harder to maintain focus in the IETF exhaustion, moving on to other things

57. U Twente57 Backup slides