140 likes | 220 Vues
LESS effort, more services. Xiaotao Wu Henning Schulzrinne Dept. of Computer Science Columbia University. The Language for End System Services (LESS). Simple Based on CPL: enhancement and extension Four kinds of elements: trigger, switch, action, modifier
E N D
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 email • 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 <?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> ……………. 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 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: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)