SIPPING - IETF 62 - Minneapolis (March 2005) LESS effort, more services Xiaotao Wu Henning Schulzrinne Dept. of Computer Science Columbia University

SIPPING - IETF 62 - Minneapolis (March 2005) The Language for End System Services (LESS) Simple –Based on CPL: enhancement and extension –Four kinds of elements: trigger, switch, action, modifier –Tree-like structure simplifies 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 Handle user interactions and media operations Beyond call control –presence, IM, Web, mid-call handling, location

SIPPING - IETF 62 - Minneapolis (March 2005) Supported services Services in 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 Location-based services –location-switch Event-based services –approve, deny, subscribe, notify Mid-call handling –transfer, update media attributes Call queuing Other Internet services - mail, send IM

SIPPING - IETF 62 - Minneapolis (March 2005) LESS 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

SIPPING - IETF 62 - Minneapolis (March 2005) LESS 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

SIPPING - IETF 62 - Minneapolis (March 2005) LESS 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

SIPPING - IETF 62 - Minneapolis (March 2005) LESS actions 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

SIPPING - IETF 62 - Minneapolis (March 2005) LESS 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

SIPPING - IETF 62 - Minneapolis (March 2005) 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 …………….

SIPPING - IETF 62 - Minneapolis (March 2005) 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

SIPPING - IETF 62 - Minneapolis (March 2005) <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.)

SIPPING - IETF 62 - Minneapolis (March 2005) Feature Interaction handling Syntax correct, semantic warnings –e.g., parent switch and child switch mutually exclusive By-product of modularity –Focusing on current needs when creating services 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 – need to check presence Translate to formal languages (e.g., LOTOS) to check FI with other complex services

SIPPING - IETF 62 - Minneapolis (March 2005) Open issues Can we use LESS for B2BUA? –lookup from database –coordinate multiple sessions –multi-user feature interaction handling No loop and no user-defined variables is sufficient for commonly used services? –Based on our exercises, yes –But, what about unknown new services? –What’s the impact on feature interaction handling

SIPPING - IETF 62 - Minneapolis (March 2005) Some links Spec: less-00.txthttp:// less-00.txt Service examples: repository/reports/reports-2004/cucs pdf repository/reports/reports-2004/cucs pdf Feature interaction handling: – Paper/fiw.pdfhttp:// Paper/fiw.pdf –Computer Networks (Elsevier), Volume 45, Issue 5Computer Networks (Elsevier), Volume 45, Issue 5

SIPPING - IETF 62 - Minneapolis (March 2005) Service partition Available anytime, anywhere More bandwidth More computation power If possible, put services in the network BUT How about P2P? Hey, buddy, why bother, Bob doesn’t like you. He will reject all your calls! privacy Switches control everything accept calls make outgoing calls change media interact with users ? Use B2BUA, H248 to control all the end systems ? ???

SIPPING - IETF 62 - Minneapolis (March 2005) Service creation

SIPPING - IETF 62 - Minneapolis (March 2005) Help users to find out services Service learning –Users do not know what they can do –Users not aware of available services –Help users, not bypass users CPL/LESS tree-like structure –Decision tree learning –Incremental Tree Induction (ITI) algorithm Service risk management (beyond LESS) –connection, privacy, money, attention –possibility and impact –risk avoidance, transfer, reduction, and contingency plan