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

2. 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)

3. 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)

4. 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)

5. 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)

6. 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)

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

8. 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)

9. 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=" T110000Z">
<status-switch
status-name="presence">
<status is="open">
<location
<call>
<busy>
<IM:sendmsg>
Hi, please call me back. I am in office
</IM:sendmsg>
</location>
…………….
SIPPING - IETF 62 - Minneapolis (March 2005)

10. 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)

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

12. 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 ……
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)

13. 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)

14. SIPPING - IETF 62 - Minneapolis (March 2005)
Some links
Spec:
Service examples:
Feature interaction handling:
Computer Networks (Elsevier), Volume 45, Issue 5
SIPPING - IETF 62 - Minneapolis (March 2005)