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

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

3. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 3 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.

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

5. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 5 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.

6. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 6 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.

7. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 7 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

8. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 8 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

9. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 9 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

10. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 10 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 … …

11. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 11 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 http://phoenix.labri.fr/processings

12. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 12 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.

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

14. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 14 Compilation: From CPL to SPL service example { processing { dialog { INVITE() response incoming INVITE() { response r = forward 'sip:bob@phone.example.com'; if (r == /ERROR/CLIENT/BUSY_HERE) { return forward 'sip:bob@voicemail.example.com'; } else if (r == /ERROR) { if (FROM == 'sip:boss@example.com') { return forward 'tel:+19175554242'; } return r; } SPL CPL

15. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 15 Compilation: From CPL to SPL service example { processing { dialog { INVITE() response incoming INVITE() { response r = forward 'sip:bob@phone.example.com'; if (r == /ERROR/CLIENT/BUSY_HERE) { return forward 'sip:bob@voicemail.example.com'; } else if (r == /ERROR) { if (FROM == 'sip:boss@example.com') { return forward 'tel:+19175554242'; } 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* } ]|

16. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 16 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 {})

17. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 17 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 1 2 3 5 67 4 CPL

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

19. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 19 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

20. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 20 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

21. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 21 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.

22. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 22 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.

23. Phoenix Group - INRIA / LaBRI IPTComm - July 2007 23 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.