Ubiquitous Programmable Internet Telephony End System Services

1. Ubiquitous Programmable Internet Telephony End System Services Thesis defense 02/06/2007 Xiaotao Wu Internet Real Time Laboratory

2. Overview • Communication services and where to run the services • End system services • Programmable – Service creation • Analyzable – Feature interaction handling • Intelligent – Feature learning • Ubiquitous – Context-based services • Implementations • Other work

3. Services and where to run services • I analyzed the difference between end system services and services in the network (IPTS’00) • End system services • Programmable • Analyzable • Intelligent • Ubiquitous • Implementations • Other work

4. Internet Where to run services?

5. Run services on end systems IPTS ‘00

6. Services and where to run services • End system services • Programmable • I defined a language for end system service creation. (ICC’03, RFC3880) • Analyzable • Intelligent • Ubiquitous • Implementations • Other work

7. End system service programming • What do we need? • A language and a tool • End system service creation language • Easy to understand • Automatic service creation • Portable • Create once, run on different devices • Easy to manage • Facilitate feature interaction handling • CPL, CCXML, APPEL, SPL…

8. Vibrate my device If the call is from my boss YES YES If I am in a conference For an incoming call NO Reject the call How to represent services? • ECA (event – condition – action) Natural thinking of a decision making – a policy/rule set Using decision trees to represent policy/rule sets (O(logN) execution time) When I am in a conference, I will vibrate my device for my boss’s calls and reject all the other calls.

9. Use LESS effort to create more services • LESS: Language for End System Services • CPL: Call Processing Language (Jonathan, Henning, and myself) • Simplicity • Four kinds of elements: trigger, switch, action, modifier • Tree-like structure, easy for feature interaction analysis • Safety • 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 • Extensibility • not just new elements, but can apply existing algorithms IEEE ICC’03 RFC3880

10. check the caller switch = ≠ check priority check time switch switch to Bob = ≠ ≠ modifier action action action redirect accept reject LESS elements trigger an incoming call

11. CUTE (Columbia University Telecommunication service Editor)

12. Survey on end user service creation Group1: IRT members, Group2: CS undergraduates, Group3: Other people 85% would like to create their own services, 90% like to use CUTE to create services 90% can correctly create service-1, 65% srv-2, 80% srv-3, 65% easy to understand LESS code

13. Services and where to run services • End system services • Programmable • Analyzable • I defined an algorithm handling feature interactions (FI) for LESS. ICFI’05, JCN) • Intelligent • Ubiquitous • Implementations • Other work

14. What is FI and how to handle it? • Tree merging Incoming call Incoming call Incoming call If time is between 10:00AM and 11:00AM If address is hgs If address is hgs If time is between 10:00AM and 11:00AM = + ring accept ring reject Forward to conf Forward to conf reject Take actions from both scripts. Simply setting precedence rules cannot work.

15. FI handling for LESS • Action conflict tables • Services conflict only if their actions conflict • Tree merging algorithm • Detect and help to resolve • Resolve conflicts ICFI’05 (FIW) JCN

16. Pre-condition and expected results

17. Action conflict table -: no interaction, A: attribute conflict, C: action conflict, E: enabling, R: resource competition

18. Tree merging (overall) conflicting-free rule set set base-rule-set empty foreach LESS-tree { convert the LESS-tree into a rule set foreach rule in the rule set { normalize the rule } merge the normalized rule set into base-rule-set } convert base-rule-set into a decision tree

19. Tree merging (merging) if (two rules have different triggers) { no rule conflict except timer trigger } else if actions in two rules do not conflict { no rule conflict } else if no overlap between rule path in two rules { no rule conflict } else { two rules conflict with each other, return the rule path overlap and action conflict information prompt to the script owner to judge } Ahmed Layouni from Univ. of Ottwa verified my work by using a model-checking tool

20. Resolving interactions condition decision options with lower risks

21. Services and where to run services • End system services • Programmable • Analyzable • Intelligent • I proposed a method for automatic service creation.(ICC’05) • Ubiquitous • Implementations • Other work

22. No idea about services? • Learning burden caused by new services • What and how • Help, not bypass • Causal relationship between call information and call decisions • SIP headers • Different information sources • Examples • Spam filtering, calendar-based services

23. 30*3+10*2+7=117 30*2+3*2+10*3+4*3=108 What (learn from), what (generate), how • Users’ communication history – LESS decision trees – decision tree induction • find switches that can best partition actions • Algorithm • Incremental • Prune • Quality measurement

24. Incremental Tree Induction • Incremental • Incorporating • Transposition • Virtual prune • Direct metrics • Expected number of tests • Leaf counts • Minimum description length • Expected misclassication cost

25. 40 services Each for 300 calls 80% match 10% different way 10% mismatch Simulation

26. Performance IBM ThinkPad, Linux 1GHz PIII Mobile 256MB memory Fast vs. incremental (20 samples) training

27. How to handle service risks? • Identify • Lose connection: reject, redirect, transfer, accept on wrong branch • Lose privacy: accept, call, notify • Lose money: accept, transfer to higher rate endpoint • Lose attention: alert, accept, appliance control • Analyze • Possibility: number of occurrence in the decision tree • Impact: (connection, privacy) > money > attention, customizable • Resolve • Change communication methods • Change communication targets • Reduce overall risk: avoiding high impact risks, though may cause low impact risks • Contingency plan • Backup

28. Services and where to run services • End system services • Programmable • Analyzable • Intelligent • Ubiquitous • Joint work on several related projects – a ubiquitous computing architecture, location-based services, SIP 911(Nossdav’03, IEEE Communications, CCNC’05, ICCCN’05) • Implementations • Other work

29. Ubiquitous computing using SIP • What is ubiquitous computing • Enhance computer use by making many computers available throughout the physical environment, but making them effectively invisible to the user. -- Mark Weiser what’s available how to control automate the control where are we send media to Tom use the devices in room 123 to talk to Tom Tom Bob can use devices in 123 room 123 Bob I am in room 123 video display microphone video camera what’s available in room 123? Service location server

30. REGISTER PUBLISH REGISTER SLP query result System Architecture SIP Home domain Registrar and AAA server Location Server Wireless triangulation Local domain SIP server NOTIFY SLP DA GPS Location Sensing Resource Discovery BlueTooth Stylianos, Stefan, Henning, myself DHCP Call Control Resource Control SLP SA INVITE NOSSDAV03 IEEE Communications

31. Bob is in conf Turn on light You are In conf What’savailable Turn on conf’s light sip:conf Location NOTIFY Room conf Location agent Device GW SLinke Proxy LS Bob Trigger an action X10 sip:conf_pingtel for audio iButton reader SLP DA RFID reader SLP SA Resource discovery Ron ,Matthew, Kundan, and myself Tracking Location-basedServices in our lab IEEE CCNC’05

32. INVITE sip:anyone_roomconf Room conf Location agent Location-basedServices in our lab Device GW SLinke Bob is in conf Turn on light Proxy LS Bob X10 You are In conf sip:conf_pingtel for audio What’savailable Turn on conf’s light iButton reader SLP DA RFID reader sip:conf SLP SA Guard communication behavior ‘Talk’ to alocation Location NOTIFY IEEE CCNC’05

33. Where to put services • End system services • Programmable • Analyzable • Intelligent • Ubiquitous • Implementations • SIPc – multi-function integration (MMNS’04) • Other work

34. Implementations

36. Function overview Email clients Real time streaming Network appliance control Third party call control Web browsers Emergency handling audio SIP CGI engine SIP Multimedia call control video Instant message SAP location sensors Location sensing white board SIP for presence Floor control LESS/CPL engine Service Location Detection (SLP) desktop sharing SIP: RFC 3261 SAP: RFC 2974 CPL, SIP 3PCC, SIP Device Control GEOPRIV location format, SIP for IM RTSP: RFC 2326 SDP: RFC 2327 RTP: RFC 1889 SLP: RFC 2608 SIP Event Arch.: RFC 3265 RFC3903 MMNS’04

37. Function sharing Conferencing floor control Device control Presence notification ir/x10 xcon Location tracking SIP event notification Service detection Message waiting indication Location sensing SIP SLP Voicemail handling Call Emergency handling RTP SDP MapLynx RTSP Instant messaging Session broadcasting SAP

38. Function interaction SIP SLP DO SLP SAP 3pcc SIP DO SIP location SDP location RTP RTP SIP SIP NOTIFY SIP location MESSAGE RTP RTSP

39. Where to put services • End system services • Programmable • Analyzable • Intelligent • Ubiquitous • Implementations • Other work

40. Other work • Building Box project (AT&T Labs Research) • Conferencing floor control (RFC4376) • Networked appliance control • Shared web browsing • Distributed conferencing and MOC integration (Avaya Labs Research) • Joined several other projects (CINEMA, SIP 911, session mobility, FAA pilot training)

41. Summary • I defined LESS and built CUTE. I also conducted a survey on end system service creation. The survey shows LESS and CUTE are good for end system service creation. • I developed an algorithm to handle feature interactions in LESS. The algorithm is easy to implement and can detect and help to resolve feature interactions in LESS. • I proposed to use decision tree induction to automatically create services for end users and defined ways to handle service risks. Automatic service creation can help users to create their desired services. • I investigated how to perform ubiquitous communication and location-based services in end systems. The ubiquitous communication architecture we proposed is scalable and can use off-the-shelf hardware and software for communication. • I implemented a SIP user agent, SIPc, and integrated my research result into SIPc. Multi-function integration in SIPc shows that convergence and multi-function interaction can bring new communication services.

42. Some links • SIPc: http://www.cs.columbia.edu/IRT/sipc • CINEMA: http://www.cs.columbia.edu/IRT/cinema • LESS: http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt • CUTE: http://www.cs.columbia.edu/~xiaotaow/cute • Ubiquitous Computing: http://www1.cs.columbia.edu/~xiaotaow/ rer/Research/Paper/ieeecomm_inhome.pdf • Service examples: http://www.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-048-04.pdf • Feature interaction handling: http://www.cs.columbia.edu/ ~xiaotaow/rer/Research/Paper/fiw.pdf • Service learning: http://www.cs.columbia.edu/~xiaotaow/rer /Research/Paper/icc2005.pdf

43. Acknowledgements • Mentor: Dr. Henning Schulzrinne • All the thesis committee members • People in IRT and the CS Department • Colleagues in AT&T Labs Research and Avaya Labs Research • SIPQuest

45. D1 D2 D1 D2 C C D3 D3 End-to-end v.s. master/slave • Pickup call MGCP Megaco notification triggered INVITE MGC

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

47. LESS elements (triggers) • Triggers • incoming: incoming call handling • outgoing: user invoked outgoing call • timer: timer triggered actions • UI:command: user interaction commands • IM:message: incoming instant messaging • Event:subscription: incoming subscription • Event:notification: incoming notification

48. LESS elements (switches) • 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

49. LESS elements (actions) • 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

50. LESS elements (modifiers) • Two smaller concepts might be simpler and more flexible than one more powerful but complicated concept • 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