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 Separate modifier from action parameters: two smaller concepts might be simpler and more flexible than one more powerful but complicated concept. SIPPING - IETF 62 - Minneapolis (March 2005)

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 Abbreviated dialing (ABD), Automatic Callback (ACB) Call forwarding on busy/don’t answer (CFC) Call hold with announcement (CHA) Call queueing (QUE) Customized ringing (CRG) Originating call screening (OCS) SIPPING - IETF 62 - Minneapolis (March 2005)

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 Pre-defined variables: System information: system.bandwidth User information: user.presence user.activity, user.mood, user.location, user.language Agent information: agent.number-of-calls agent.media-capabilities Trigger information: trigger.origin trigger.destination trigger.timestamp Action information: action.last-action-result Any action will have a ‘next’ output for sequential follow-up actions <xs:complexType name="ActionType" abstract="true" mixed="true"> <xs:all> <xs:element name="next" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> </xs:all> SIPPING - IETF 62 - Minneapolis (March 2005)

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)

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 email log: log request handling process Media:mediaupdate: update media attributes Midcall:transfer: transfer a call SIPPING - IETF 62 - Minneapolis (March 2005)

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)

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 <?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> <IM:sendmsg> Hi, please call me back. I am in office </IM:sendmsg> </location> ……………. 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=“……"> <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 SIPPING - IETF 62 - Minneapolis (March 2005)

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 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 Semantic warnings: <address-switch field=“origin”> <address subdomain-of=“cs.columbia.edu”> <address is=“foo@nyu.edu”> …… Action conflict tables: check pre-condition and expected results of all actions, with defined execution order check the interactions between action A and action B, we first check the situation where A is performed before B. The checking consists of two parts: one is to check whether action A’s result changes or conflicts with the pre-condition of action B, the other is to check whether action B’s result changes the expected result of action A. We then check the interactions with a different execution order with action B performed first and do the same checking. Tree merging algorithm: check switch overlap and merge two trees the leave nodes are actions, based on action conflict table, check feature interactions if there are feature interactions, report to users about the condition (overlap between switches) feature interactions may happen SIPPING - IETF 62 - Minneapolis (March 2005)

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)

SIPPING - IETF 62 - Minneapolis (March 2005) Some links Spec: http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt 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 Computer Networks (Elsevier), Volume 45, Issue 5 SIPPING - IETF 62 - Minneapolis (March 2005)