The Intersection of Real-Time Communications and Web Services

1. The Intersection of Real-Time Communications and Web Services Henning Schulzrinne Department of Computer Science Columbia University WISE'05

2. Overview • The transformation of protocol design • Domain-specific languages for service creation • Mapping locations to URLs: LUMP • emergency services & pizza delivery • Event notification as the missing piece • Remotely manipulating XML documents: XCAP WISE'05

3. The transformation of protocol design • Traditional Internet application protocols (IETF et al.): • one protocol for each type of application: • SMTP for email, ftp for file transfer, HTTP for web access, POP for email retrieval, NNTP for netnews, … • slow protocol development process • re-do security (authentication) for each • each new protocol has its own text encoding • similarity across protocols: SMTP-style headers • Content-Type: text/plain; charset="us-ascii"; format=flowed • large parsing exposure  new buffer overflows for each protocol application SOAP application HTTP TCP TCP IP IP WISE'05

4. The transformation of protocol design • One application, one protocol  common infrastructure for new application • Old model: • RPC for corporate “one-off” applications • custom protocols for common Internet-scale applications • Far too many new applications • and not enough protocol engineers • network specialist  application specialist • new IETF application protocol design takes ~5 years • Many of the applications (email to file access) could be modeled as RPC custom text protocol (ftp) ASN.1-based (SNMP, X.400) RFC 822 protocol (SMTP, HTTP, RTSP, SIP, …) use XML for protocol bodies (IETF IM & presence) SOAP and other XML protocols WISE'05

5. Why are web services succeeding(*) after RPC failed? • SOAP = just another remote procedure call mechanism • plenty of predecessors: SunRPC, DCE, DCOM, Corba, … • “client-server computing” • all of them were to transform (enterprise) computing, integrate legacy applications, end world hunger, … • Why didn’t they? • Speculation: • no web front end (no three-tier applications) • few open-source implementations • no common protocol between PC client (Microsoft) and backend (IBM mainframes, Sun, VMS) • corporate networks local only (one site), with limited backbone bandwidth Corba DCOM SunRPC (*) we hope WISE'05

6. Why did web services succeed after RPC failed? • More speculation: • Corba, DCOM, SunRPC: no real security story • had custom-made security instead of TLS • Many initially designed for LAN only • e.g., use of UDP, service naming by ports only • Limited language support • e.g., no PHP or Perl support for Corba • Limited platform support • Perception: Corba = all-but-Microsoft; DCOM = Microsoft WISE'05

7. Technical challenges for web services • Resistance to common protocol infrastructure • “Yet another RPC fad” • SOAP overhead = the price of generality: • SOAP envelope • inefficient binary encoding (images, etc.) compared to MIME multipart • klumsy load-balancing and redundancy • inefficient implementations • high start-up costs • XML problems • XML schema hard to work with • Namespace clutter • hard to extend among multiple independent parties ( RelaxNG) • can only do <any ##other> SOAP PHP servlets WISE'05

8. Services for VoIP WISE'05

9. 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- WISE'05

10. Internet services – the missing entry WISE'05

11. Filling in the protocol gap WISE'05

12. 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 WISE'05

13. Brief introduction of SIP-based Internet telephony systems INVITE 200 OK ACK BYE REGISTER INVITE INVITE INVITE REGISTER • Session Initiation Protocol (SIP) • RFC 3261: INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS • RFC2327: SDP for media description WISE'05

14. 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 WISE'05

15. 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 WISE'05

16. Presence data model “calendar” “cell” “manual” person (presentity) (views) alice@example.com audio, video, text r42@example.com video services devices WISE'05

17. 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) PUBLISH PA NOTIFY translate RPID CPL LESS INVITE WISE'05

18. 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> WISE'05

19. 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 WISE'05

20. Services can be everywhere End user Organization/ Community Service provider End user WISE'05

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

22. Easy service creation and analysis • CPL: Call Processing Language • LESS: Language for End System Services • Simple • Four kinds of elements: trigger, switch, action, modifier • Tree-like structure, easy for feature interaction analysis • Safe • Type safety: XML-based, no user defined variables • Control flow safety: tree-like structure without back-reference • No direct memory access • Default behavior for every tree branch • Portability • Handle user interactions and media operations • Beyond call control • presence, IM, Web, mid-call handling, location WISE'05

23. CPL example: DAG WISE'05

24. CPL example <?xml version="1.0" ?> <!DOCTYPE call SYSTEM "cpl.dtd"> <cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:jones@example.com&Subject=lookup%20failed" /> </failure> </lookup> </incoming> </cpl> WISE'05

25. LESS elements: Triggers • incoming: incoming call handling • timer: timer triggered actions • UI:command: user interaction commands • IM:message: incoming instant messaging • Event:subscription: incoming subscription • Event:notification: incoming notification WISE'05

26. LESS elements: Switches • time-switch: make decisions based on time • address-switch: make decisions based on caller, callee • priority-switch: make decisions based on call priority • string-switch: make decisions based on subject, … • language-switch: make decisions based on languages • status-switch: make decisions based on users’ status (remote user or local user, status includes presence, activity, mood, …, as listed in RPID) • Event:event-switch: check values in event notifications • LOC:where-switch: check users’ physical location information (remote or local user) • LOC:where-relation-switch: check relative physical locations between two people WISE'05

27. LESS elements (Cont.) • Actions • accept: accept an incoming call • reject: reject an incoming call • redirect: redirect an incoming call • authenticate: authenticate anincoming request • call: make an outgoing call • terminate: disconnect a call • wait: wait for a certain time before next action • mail: send email • log: log request handling process • Media:mediaupdate: update media attributes • Midcall:transfer: transfer a call • Midcall:merge: merge multiple calls • UI:alert: alert user • UI:getinput: get user input • IM:sendmsg: send an instant message • Event:approve: approve subscription • Event:deny: deny event subscription • Event:defer: defer the decision on event subscription • Event:subscribe: send subscription out • Event:notify: send notification out • Queue:enqueue: put a call and its context into a queue • Queue:dequeue: get a call and its context from a queue WISE'05

28. LESS elements (Cont.) • Modifiers • location: to which a request to be directed • lookup: lookup locations from a source • remove-location: remove locations from location set • Media:media: provide media attributes WISE'05

29. Timer triggered outgoing call <?xml version="1.0" encoding="UTF-8"?> <less xmlns="urn:ietf:params:xml:ns:less“ xmlns:IM="urn:ietf:params:xml:ns:less:im“ xmlns:xsi=“…" xsi:schemaLocation=“…"> <timer dtstart="20050307T110000Z"> <status-switch uri="sip:bob@example.com" status-name="presence"> <status is="open"> <location url="sip:bob@example.com"> <call> <busy> <location url="sip:bob@example.com"> <IM:sendmsg> Hi, please call me back. I am in office </IM:sendmsg> </location> ……………. WISE'05

30. Automatic Call Back (ACB) <less xmlns="urn:ietf:params:xml:ns:less“ xmlns:Event="urn:ietf:params:xml:ns:less:event“ xmlns:Queue="urn:ietf:params:xml:ns:less:queue“ xmlns:xsi=“….“ xsi:schemaLocation=“……"> <incoming> <status-switch status-name=“activity”> <status is=“on-the-phone"> <reject reason=“busy”> <next> <Queue:enqueue queue="callback"/> </next> </reject> </status> </status-switch> </incoming> Use Event and Queue extension In ITU Q.1211 “This feature allows the called party to automatically call back the calling party of the last call directed to the called party.” Check my activity for an incoming call If I am on-the-phone Reject and enqueue WISE'05

31. Automatic Call Back (ACB) (cont.) A event notification for myself <Event:notification> <address-switch field="origin"> <address uri="{agent.uri}"> <Event:event-switch> <Event:event package=“presence" name=“activity" is=“normal"> <Queue:dequeue queue="callback"> <Queue:success> <call/> </Queue:success> </Queue:dequeue> </Event:event> </Event:event-switch> </address> </address-switch> </Event:notification> </less> I am available Dequeue and make a call WISE'05

32. Easy creation WISE'05

33. Smart – learning and automation • Users may not know what they can do • Users may not know what they want to do • Spam filtering, calendar-based services, activities-based services, location-based services, address-based services • Help users, not bypass users • Risk management WISE'05

34. Incremental Tree Induction • CPL/LESS tree-like structure • Decision tree learning • Input: trigger, conditions, and actions • Output: a decision tree best partition actions • Incremental Tree Induction (ITI) algorithm • Incremental • Tree quality measurement • Virtual prune WISE'05

35. Simulation WISE'05

36. Mapping Services WISE'05

37. The service URN • Currently: very specific URLs • http://www.example.com/service/parameter • or UDDI queries • Want to identify generic, well-known services instead • Old analog phone solved this: • old “9-1-1” for emergency, “4-1-1” for directory • newer “3-1-1” for government services • 1-800-LAWYER for “you can make one call” • Service is context-dependent: • location of user • service provider (Verizon vs. SBC vs. Nextel) • Solution: A service URN • urn:service:sos.fire • urn:service:repair • Need service routing to actual service provider WISE'05

38. SIP request 9-1-1 INVITE sip:fire@paris.ia.state.us To: urn:service:sos 123 Main, Paris, IA INVITE urn:service:sos To: urn:service:sos 123 Main, Paris, IA WISE'05

39. Components of emergency calling now transition all IP dial 112, 911 signal sos@ Contact well-known number or identifier 112 911 112 911 Route call to location-appropriate PSAP selective router VPC DNS phone number  location (ALI lookup) Deliver precise location to call taker to dispatch emergency help in-band in-band  key  location WISE'05

40. Location-based call routing – UA knows its location GPS INVITE sips:sos@ 48° 49' N 2° 29' E outbound proxy server DHCP 48° 49' N 2° 29' E  Paris fire department WISE'05

41. LUMP: Mapping service URNs + locations to URLs • Common problem: • {geo or civic location, service}  set of URLs • e.g., {Broadway/NY, “911”}  fire@psap.nyc.gov • also applies to anything from AAA to pizza delivery • Service providers don’t trust each other (fully) • e.g., who gets to include Jerusalem in its map • service may depend which warlord you belong to  • can’t wait for UN (or ICANN) to create global emergency services database • Suggested approach: new distributed mapping protocol • LUMP: location-to-URL mapping protocol • uses SOAP, but special service URLs WISE'05

42. Aside: using DNS for reliability and indirection • HTTP mistake: DNS entry refers to single server • DNS round robin doesn’t work well  can’t predict division of labor • e.g., single resolver for all of AOL • load balancers intercept requests (bad) • break TLS encryption chain • hard to spread over a wide area • Alternative: DNS SRV and NAPTR records • SRV: map service (_sip._tcp.columbia.edu) to one or more host names • can be prioritized (backup) and randomly load-balanced (with weights) – at client side • NAPTR: + URN rewriting service for strings • allows human-friendly service names that get mapped to HTTP URLs WISE'05

43. LUMP architecture broadcast (gossip) G G G G T1: .us T2: .de G resolver T2 (.de) seeker 313 Westview Leonia, NJ US T3 (.dk) T1 (.us) Leonia, NJ  sip:psap@leonianj.gov WISE'05

44. Event services WISE'05

45. Event services: the missing function • Current RPC is mostly request-response (or just request) • Doesn’t work well: • response can occur after seconds or days • often multiple updates on progress • many systems generate asynchronous events • bad protocol design: RSS  poll periodically – “yup, still nothing new” • Common system abstraction: publish, subscribe, notify • allow notification of events and delivery of notifications • more than just a protocol • Can build custom pub/sub systems • or extend SOAP • Alternative: • SIP as notification mechanism • events are just a special case of presence • can refer to transactions WISE'05

46. Presence (+ event) data architecture presence (event) 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 WISE'05

47. Presence (event) 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 WISE'05

48. XCAP: Manipulating XML document WISE'05

49. XCAP: manipulating XML documents • Work by J. Rosenberg in IETF SIMPLE WG • Problem: • each application has its own configuration format • cannot be shared and managed remotely • e.g., presence “watcher” list or SIP configuration • now, typically XML formats, but different scheme • too large to manipulate • Use HTTP + subset of XPath to manipulate XML documents WISE'05

50. XCAP: Insert an Element adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> PUT http://xcap.example.com/address-book/users/petri/adbook1/ address-book/entry/phone HTTP/1.1Content-Type: application/xml-fragment-body <phone>+19739525000</phone> <?xml version="1.0" encoding="UTF-8"?> <address-book> <entry> <name>Jonathan Rosenberg</name> <phone>+19739525000</phone> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> HTTP/1.1 200 OK WISE'05