Charles Consel 1, Fabien Latry 1, and Julien Mercadal 1 IPTComm – July Phoenix Research Group INRIA / LaBRI Staging Telephony Service Creation: A Language Approach

Phoenix Group - INRIA / LaBRI IPTComm - July Context Why ? – Expectations among users to create telephony services. What ? – Call routing services, – Signaling-related operations. Where ? – Located on network servers.

Phoenix Group - INRIA / LaBRI IPTComm - July Challenges in Call Routing Services Call routing is an intricate task, requiring expertise in a number of areas – Distributed systems, networking, telecommunications. Diversity management is very challenging – Programmers : end-user, PABX administrator, telephony carrier, – Technologies: APIs, languages, platforms. Reliability of call routing services is a strong pre-requisite – Domain properties to verify.

Phoenix Group - INRIA / LaBRI IPTComm - July Bridging The Gap Gap between business IT Telephony expert service logic Implementation expert technologies

Phoenix Group - INRIA / LaBRI IPTComm - July Bridging The Gap public class Example { [...] private AddressFactory factory = getAddressFactory(); public void processRequest (Request rq){... } public class Example { [...] private AddressFactory factory = getAddressFactory(); public void processRequest (Request rq){... } Domain Knowledge Domain Knowledge What How GAP Call routing domain – Telephony experts, – High level (e.g., modeling) – Code generation difficult. Call routing implementation – Implementation experts, – Technology dependant, – Code verification difficult.

Phoenix Group - INRIA / LaBRI IPTComm - July Our Approach Aim – Providing a language for each kind of experts, – Improving: » Accessibility of routing service programming, » Reliability of service development. Idea – Relying on programming languages, and specifically on domain- specific languages (DSLs), – Introducing a layered architecture of DSLs, – Leveraging high-level tools to compile and verify services.

Phoenix Group - INRIA / LaBRI IPTComm - July Domain-specific language » Domain-specific notations and concepts, » Abstracting implementation details, » Easing program development. Different kinds of DSLs – Modeling the domain vs. programming the domain » A DSL may or may not require programming skills. – Domain-specific modeling language (DSML) » Centered around end-user; requires domain expertise (e.g., CPL). – Domain-specific programming language (DSPL) » Centered around implementation; requires programming expertise (e.g., SPL). Domain-Specific Languages

Phoenix Group - INRIA / LaBRI IPTComm - July Bridging The Gap public class Example { [...] private AddressFactory factory = getAddressFactory(); public void processRequest (Request rq){... } public class Example { [...] private AddressFactory factory = getAddressFactory(); public void processRequest (Request rq){... } Domain Knowledge Domain Knowledge What How GAP DSML Implementation Modeling Implementation

Phoenix Group - INRIA / LaBRI IPTComm - July A Layered Approach DSML – Targets the DSPL – Verification of domain properties DSPL – Interface between the domain and the implementation – Generates implementation DSML Implementation Modeling Implementation Programming DSPL

Phoenix Group - INRIA / LaBRI IPTComm - July A DSPL as a Pivotal Layer Bridge the gap, but also – Simplify the compilation, – Enable to have a variety of DSMLs, – Target multiple implementations. DSPL Preference / Constraint / Trust level / Purpose / Abstraction level /… DSML 1 Implementation 1 DSML 2 Implementation 2 … …

Phoenix Group - INRIA / LaBRI IPTComm - July Staging Processings DSPL DSML 1 Implementation 1 DSML 2 Implementation 2 … … Verification related to the domain Verification related to the program DSML Compilation DSPL Compilation

Phoenix Group - INRIA / LaBRI IPTComm - July Processing DSMLs: Case Study DSMLs – CPL – Call Processing Language (CPL) » XML-based scripting language, » Domain experts, non-programmers. – VisuCom » Graphical language, » Domain experts, non-programmers DSPL – SPL – Session Processing Language (SPL) » Abstracts over underlying protocols, platform, » Programmers. High-level tools – Program generation, – Program verification.

Phoenix Group - INRIA / LaBRI IPTComm - July Processing DSMLs: Case Study Compilation Verification Stratego/XT TLC Model Checker Stratego/XT Error Report SPL Program CPL or VisuCom Program TLA+ Specification

Phoenix Group - INRIA / LaBRI IPTComm - July Compilation: From CPL to SPL service example { processing { dialog { INVITE() response incoming INVITE() { response r = forward if (r == /ERROR/CLIENT/BUSY_HERE) { return forward } else if (r == /ERROR) { if (FROM == { return forward 'tel: '; } return r; } SPL CPL

Phoenix Group - INRIA / LaBRI IPTComm - July Compilation: From CPL to SPL service example { processing { dialog { INVITE() response incoming INVITE() { response r = forward if (r == /ERROR/CLIENT/BUSY_HERE) { return forward } else if (r == /ERROR) { if (FROM == { return forward 'tel: '; } else { return r; } return r; } RuleRedirectNonTerminal : stat1* stat2* -> |[ response r = forward callee ; if ( r == /ERROR/CLIENT/BUSY_HERE ) { stat1* } else { stat2* } ]| where new => r RuleFROMTest : stat1* -> |[ if (FROM == caller) { stat1* } ]|

Phoenix Group - INRIA / LaBRI IPTComm - July Verification of Call Routing Properties Properties – No duplicate redirect, – No redirect to the caller, – No infeasible path, – Service interaction. NoTwiceRedirectToTheSameURI ( n 1..Len(signalingActions) : m n+1..Len(signalingActions) : signalingActions[n] "Continuation" signalingActions[n] signalingActions[m]) NoRedirectToTheCaller ( x Contacts : n 1..Len(callerTests) : x callerTests[n] m 1..Len(signalingActions) : signalingActions[m] x) Consistency ( x Contacts : n 1..Len(callerTests) : x callerTests[n]) (date {})

Phoenix Group - INRIA / LaBRI IPTComm - July Verification of Call Routing Properties Properties – No redirect to the caller, – No duplicate redirect, – No infeasible path, – Service interaction. Incoming call no Is the day of the call Tuesday ? Forward call to Bobs phone... yes Redirect call to Bobs voice mail Is the date of the call between 07/12 and 07/17 ? no Redirect call to Bobs cell phone yes Weekly meeting Annual holidays CPL

Phoenix Group - INRIA / LaBRI IPTComm - July VisuCom Graphical environment Tightly coupled with information systems

Phoenix Group - INRIA / LaBRI IPTComm - July VisuCom Service Model Call routing logic Contact database Service checking Evolution of the service logic with respect to data sources – Description of the service logic : static – Data on which the service relies on : dynamic Service : dynamic Need for consistency checking

Phoenix Group - INRIA / LaBRI IPTComm - July Verification of Call Routing Properties Properties – No redirect to the caller, – No duplicate redirect, – No infeasible path, – Service interaction. VisuCom Data model: Group customer: Alice, Bob, Daniel Group VIP: Frank No intersection

Phoenix Group - INRIA / LaBRI IPTComm - July TLC Error Report TLC Version 2.0 of January 16, 2006 Model-checking Implied-temporal checking--satisfiability problem has 2 branches. Finished computing initial states: 1 distinct state generated. Error: Invariant Consistency is violated. The behavior up to this point is: STATE 1: /\ callerTests = > /\ currentNode = "Incoming" /\ signalingActions = > STATE 2: /\ callerTests = > /\ currentNode = "CustomerGroup" /\ signalingActions = > STATE 3: /\ callerTests = > /\ currentNode = "VIPGroup" /\ signalingActions = > STATE 4: /\ callerTests = > /\ currentNode = "Forward" /\ signalingActions = > 5 states generated, 5 distinct states found, 2 states left on queue. The depth of the complete state graph search is 4.

Phoenix Group - INRIA / LaBRI IPTComm - July Assessment Benefits of the layered view of DSLs – Simplification of the DSML processings, – Specific treatment at each layer. High-level compilation approach – Compilation more amenable to existing high-level program generation tools, – A bridge between a DSML and its implementation. High-level verification approach – Verification more amenable to existing verification tools, – Verification of domain-properties.

Phoenix Group - INRIA / LaBRI IPTComm - July Conclusion An approach to improving the development and the verification of call routing services. – Accessibility of routing service programming, – Development of reliable services. Approach – Relying on a layered view of domain-specific languages, – Leveraging high-level tools to compile and verify services. Validation of the approach for a realistic case study.