1 / 57

Advanced Multimedia and Presence Services using Classical and P2P SIP

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

kbrooks
Download Presentation

Advanced Multimedia and Presence Services using Classical and P2P SIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 U Twente

  2. 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 U Twente

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

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

  5. SIP Overview U Twente

  6. Internet services – the missing entry U Twente

  7. Filling in the protocol gap U Twente

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

  9. 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 U Twente

  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 U Twente

  11. Basic SIP message flow U Twente

  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 U Twente

  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 U Twente SDP

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

  15. 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 U Twente

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

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

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

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

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

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

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

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

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

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

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

  27. RPID: rich presence U Twente

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

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

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

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

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

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

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

  35. Program location-based services U Twente

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

  37. 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 U Twente

  38. 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 U Twente

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

  40. 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 U Twente

  41. 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?)? U Twente

  42. Peer-to-peer SIP U Twente

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

  44. 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 U Twente

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

  46. 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(*) U Twente

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

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

  49. Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP Architecture 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 U Twente

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

More Related