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

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 devices End users’ server User agents in the network Proxy server B2BUA

5 Where to put services End devicesEnd serversNet UAsProxyB2BUA Number of users SingleSingle/trust ed users Multiple Call/dialog states Yes NoYes MediaYesYes/noYesNoYes/no Number of entities SingleMultipleSingleMultiple Direct interaction YesNo/yesNo Admin.End user Admin. Store services in the network, though they may get executed in end systems Keep the peer-to-peer architecture, avoid the master/slave architecture

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

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

8 -- Mark Weiser 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. where are we what’s available how to control automate the control Service location server room 123 what’s available in room 123? video display microphone video camera Bob I am in room 123 Bob can use devices in 123 use the devices in room 123 to talk to Tom Tom send media to Tom NOSSDAV03 IEEE Communications

9 System Architecture Location Sensing Resource Discovery Resource Control Call Control GPS BlueTooth DHCP Wireless triangulation NOTIFY PUBLISH REGISTER SIP Home domain Registrar and AAA server Location Server Local domain SIP server SLP DA INVITE SLP SA SLP query result

10 Room conf Location agent Bob RFID reader iButton reader Proxy LS Bob is in conf NOTIFY Location You are In conf SLP DA SLP SA Device GW SLinke X10 Turn on conf’s light Turn on light What’s available sip:conf_pingtel for audio sip:conf Tracking Trigger an action Resource discovery IEEE CCNC’05 Location-based Services in our lab

11 Location-based Services in our lab Location agent Bob RFID reader iButton reader Proxy LS Bob is in conf NOTIFY Location You are In conf SLP DA SLP SA Device GW SLinke X10 Turn on conf’s light Turn on light What’s available sip:conf_pingtel for audio sip:conf INVITE sip:anyone_roomconf Guard communicatio n behavior ‘Talk’ to a location Room conf IEEE CCNC’05

12 Location in Emergency Services Emergency Call Center Call Flow Prototype Architecture SIP Proxy Internet ALI ServerDHCP Server DNS Server w/location or w/out location geo location POTS/Wireless Network IP Network DHCP Inform MAC Address Location Info TCP Socket Telephone Number PSAP Info HTTP SOAP geo location verified civil location civil location** PSAP Info DNS Query civil location IEEE ICCCN’05

13 Program location-based services <LOC:where country="USA" A1="New York" A3="New York" A6="West 120th" HNO="450" LOC="Room 563">

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. A decision tree to represent a rule set CPL and LESS For an incoming call If I am in a conference Vibrate my device Reject the call YES NO If the call is from my boss

16 Timer triggered outgoing call <less xmlns="urn:ietf:params:xml:ns:less “ xmlns:IM="urn:ietf:params:xml:ns:less:im “ xmlns:xsi= “… " xsi:schemaLocation= “… "> <status-switch status-name="presence"> Hi, please call me back. I am in office …………….

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 LESS elements trigger an incoming call switch check the caller switch check time switch check priority action redirect action accept action reject modifier to Bob = ≠ = ≠ ≠

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 an incoming request call: make an outgoing call terminate: disconnect a call wait: wait for a certain time before next action mail: send 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=“……"> <status-switch status-name=“activity”> <Queue:enqueue queue="callback"/> 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 Use Event and Queue extension If I am on-the-phone Reject and enqueue

25 <Event:event package=“presence" name=“activity" is=“normal"> <Queue:dequeue queue="callback"> A event notification for myself I am available Dequeue and make a call Automatic Call Back (ACB) (cont.)

26

27

28

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

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 accept Easy feature interaction analysis Tree merging + = If time is between 10:00AM and 11:00AM If address is hgs Forward to conf Incoming call If time is between 10:00AM and 11:00AM If address is hgs reject Forward to conf reject accept 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 Related work of CPL FI handling Related work Syntax correct, semantic warnings e.g., parent switch and child switch mutually exclusive Translate to formal languages to check FI with other complex services

34 Pre-condition and expected results pre-conditionexpected results accept The call setup is pending. The audio device is available. The call setup is finalize. The communication session is setup. The audio device is occupied. reject The call setup is pending.The call setup is finalized. redirect The call setup is pending.The call setup is finalized on the current end system. call The audio device is available.If the callee side accepts the call, a communication session is setup and audio device is occupied.

35 Action conflict table acceptrejectredirectcall accept A(media)CCR reject CA(reason)C- redirect CCA(target)- call R--A(target) -: no interaction, A: attribute conflict, C: action conflict, E: enabling, R: resource competition

36 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

37 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 }

38 Where to put services Services Ubiquitous Programmable Rich Smart Implementations Other works

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

40 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, , SLP, SAP, IM, presence, location, networked appliance control, directory service, calendar service, conferencing Not named services, but programmable services Programmable conferencing services

41 Where to put services Services Ubiquitous Programmable Rich Smart Implementations Other works

42 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

43 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, …

44 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

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

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

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

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

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

50 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

51 Where to put services Services Ubiquitous Programmable Rich Smart Implementations Other works

52 Implementations

53

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

55 Call SIP SDPRTP Session broadcasting SAP RTSP SIP event notification Location sensing Emergency handling Location tracking Device control ir/x10 MapLynx Message waiting indication Voic handling Presence notification Conferencing floor control Service detection SLP Instant messaging xcon Function reuse

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

57 Other work Building Box project (AT&T Labs Research) Conferencing floor control Networked appliance control Shared web browsing Joined some other projects (CINEMA, SIP 911, session mobility, project for FAA, …)

58 Conclusion Services are more distributed in Internet telephony. We need techniques specifically for end system service creation LESS is designed for end system services Easy to build SCE Easy to analyze Enable feature learning Different information and different functions converged at end systems and will introduce many new services, e.g., location-based services.

59 Some links SIPc: CINEMA: LESS: Ubiquitous Computing: rer/Research/Paper/ieeecomm_inhome.pdfhttp://www1.cs.columbia.edu/~xiaotaow/ rer/Research/Paper/ieeecomm_inhome.pdf Service examples: repository/reports/reports-2004/cucs pdfhttp:// repository/reports/reports-2004/cucs pdf Feature interaction handling: ~xiaotaow/rer/Research/Paper/fiw.pdfhttp:// ~xiaotaow/rer/Research/Paper/fiw.pdf Service learning: /Research/Paper/icc2005.pdfhttp:// /Research/Paper/icc2005.pdf

60 Acknowledgements Dr. Henning Schulzrinne SIPQuest Colleagues in IRT lab Colleagues in AT&T Labs Research Thank you!

61 Decision tree induction Entropy: -Σ P log2P 30 rejects, 17 accepts -30/47*log2(30/47) -17/47*log2(17/47) = Split on caller=Bob -30/33*log2(30/33) -3/33*log2(3/33) -14/14*log2(14/14) = Information gain: entropy change after splitting Information gain on the splitting is

62 Decision tree induction Find the splitting that can get the largest information gain Repeat for all sub-trees until no more information gain Noisy data and prune Splitting causes higher error