Ubiquitous Programmable Internet Telephony Services

1. Ubiquitous Programmable Internet Telephony Services Thesis defense Xiaotao Wu Internet Real Time Laboratory

2. Overview • Where to put services • Services • Ubiquitous – SIP-based ubiquitous computing • Programmable – CPL, LESS and FI handling • Rich – existing services and new services • Smart – Feature learning • Implementations • Other works

3. Where to put services • Services • Ubiquitous • Programmable • Rich • Smart • Implementations • Other works

4. Services can be everywhere End users’ server End devices Proxy server B2BUA User agents in the network

5. Where to put services

6. D1 D2 D1 D2 C C D3 D3 Peer-to-peer v.s. master/slave • Pickup call MGCP Megaco notification triggered INVITE MGC

7. Where to put services • Services • Ubiquitous • Programmable • Rich • Smart • Implementations • Other works

8. 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? NOSSDAV03 IEEE Communications Service location server

9. 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 DHCP Call Control Resource Control SLP SA INVITE

10. 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 Tracking Location-basedServices in our lab IEEE CCNC’05

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

12. Location in Emergency Services Envinsa Server sip : psap @ domain with location location sip : sos @ domain without location 911 GeoLynx IP Gateway Display DHCP Server ALI Server verified TCP Socket civil DHCP Inform Telephone location MAC Address DNS Server Number DNS Query Location HTTP SOAP SIP Proxy civil location Info geo location PSAP PSAP Info Info civil location ** geo location sip : sos @ domain 911 w / location or 112 w / out location IP Network Internet SIP Proxy POTS / Wireless Network Emergency Call Center Prototype Architecture Call Flow IEEE ICCCN’05

13. Program location-based services <incoming> <LOC:where-switch type="civil"> <LOC:where country="USA" A1="New York" A3="New York" A6="West 120th" HNO="450" LOC="Room 563"> <location url="sip:bob-office@example.com"> <redirect/> </location> </LOC:where> <otherwise> <location url="sip:bob-mobile@example.com"> <redirect/> </location> </otherwise> </LOC:where-switch> </incoming>

14. Where to put services • Services • Ubiquitous • Programmable • Rich • Smart • Implementations • Other works

15. Easy service creation • Using a tree-like structure to represent communication services Natural thinking of call decision making – a rule set For an incoming call, if I am in a conference, I will reject all the calls that are not from my boss. Vibrate my device A decision tree to represent a rule set If the call is from my boss YES YES If I am in a conference For an incoming call NO Reject the call CPL and LESS

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

17. CPL and LESS • 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, location IEEE ICC’03 RFC3880

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

19. LESS elements

20. LESS elements • 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

21. LESS elements (cont.) • 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

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

23. LESS elements (Cont.) • 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

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

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

27. <?xml version="1.0"?> <less> <incoming> <address-switch field="origin"> <address is="sip:hgs@cs.columbia.edu"> <accept/> </address> <otherwise> <location url="sip:foo@example.com"> <redirect/> </location> </otherwise> </address-switch> </incoming> </less>

29. LESS script customization LESS editor less.xsl service.less (template) xsl:if address is=$var XSLT configuration editor service.html translate.cgi service_foo.less

30. Open issues • Can we use LESS for B2BUA? • ‘lookup’ from database • coordinate multiple sessions • multi-user feature interaction handling • Loop and user-defined variables needed? • Based on our exercises, no • But, what about unknown new services? • Convert loop to a high-level abstraction? • What’s the impact on feature interaction handling

31. Easy feature interaction analysis • 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 = + accept accept accept reject Forward to conf Forward to conf reject Take actions from both scripts. Simply setting precedence rules cannot work. ICFI’05 (FIW)

32. Easy feature interaction analysis • FI handling between multiple CPL/LESS scripts • Action conflict tables • Tree merging algorithm • Multi-component feature interactions • e.g., parallel forking with all end systems automatically accept an incoming call

33. Pre-condition and expected results

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

35. Tree merging 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

36. Tree merging (cont.) 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 }

37. Where to put services • Services • Ubiquitous • Programmable • Rich • Smart • Implementations • Other works

38. Rich signaling information • Rich signaling information • SIP headers • Caller preference and callee capabilities • MIME contents • Event notification • Other means • Web calendar, Directory services

39. Rich services • Be able to handle services in PSTN networks • ITU Q.1211 • ABD, ACB, CFC, CHA, QUE, CRG, OCS, … • Services in 5ESS switches • Attendant camp-on, Automatic recall, … • Services in CSTA Phase III • defined as signaling actions in LESS, e.g., mediaupdate • Emergency • provide location information • New services • Interact with existing Internet services • web, email, SLP, SAP, IM, presence, location, networked appliance control, directory service, calendar service, conferencing • Not named services, but programmable services • Programmable conferencing services

40. Where to put services • Services • Ubiquitous • Programmable • Rich • Smart • Implementations • Other works

41. Definition • What is service learning • Automatically generate user desired services • Help users, not bypass users • Services on both proxy servers and end systems • What is service risk management • Risk caused by automation • How to reduce the overall risks IEEE ICC’05

42. Motivation • Causal relationship between call information and call decisions • SIP headers • Other Internet services • Learning burden caused by new services • Not named services, but programmable services • What and how • Examples • Spam filtering, calendar-based services • Service risks • Lose connectivity, lose privacy, …

43. Design • Using decision tree induction for learning • In CPL/LESS terms: find switches that can best partition actions • What algorithm • Incremental • Prune • Quality measurement 30*3+10*2+7=117 30*2+3*2+10*3+4*3=108

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

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

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

47. Performance IBM ThinkPad, Linux 1GHz PIII Mobile 256MB memory 20 vs. 250 incremental samples

48. Integration • Gather information • Transaction history • Calendar • Location sensing • Idle time • Communication activities • Timestamp • Alert users • Service risk management

49. Service risk management • 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, switch attributes • Impact: (connection, privacy) > money > attention, customizable • Overall risk: avoiding high impact risks, though may cause low impact risks • Resolve • Change communication methods • Transfer • Reduce overall risk • Contingency plan • Backup

50. Where to put services • Services • Ubiquitous • Programmable • Rich • Smart • Implementations • Other works