Staging Telephony Service Creation: A Language Approach

Staging Telephony Service Creation:A Language Approach

Context • Why ? • Expectations among users to create telephony services. • What ? • Call routing services, • Signaling-related operations. • Where ? • Located on network servers.

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.

Bridging The Gap • Gap between business  IT Telephony expert service logic Implementation expert technologies

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

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.

Domain-Specific Languages • 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).

Bridging The Gap DSML Modeling GAP What Domain Knowledge How Implementation Implementation public class Example { [...] private AddressFactory factory = getAddressFactory(); public void processRequest (Request rq){ ... } }

A Layered Approach • DSML • Targets the DSPL • Verification of domain properties • DSPL • Interface between the domain and the implementation • Generates implementation DSML Modeling Programming DSPL Implementation Implementation

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

Staging Processings … Verification related to the domain DSML 1 DSML 2 DSML Compilation Verification related to the program DSPL DSPL Compilation … Implementation 1 Implementation 2 http://phoenix.labri.fr/processings

Processing DSMLs: Case Study • DSMLs • Call Processing Language (CPL) • XML-based scripting language, • Domain experts, non-programmers. • VisuCom • Graphical language, • Domain experts, non-programmers • DSPL • Session Processing Language (SPL) • Abstracts over underlying protocols, platform, • Programmers. • High-level tools • Program generation, • Program verification.

Processing DSMLs: Case Study CPL or VisuCom Program Stratego/XT Stratego/XT SPL Program TLA+ Specification TLC Model Checker Compilation Error Report Verification

Compilation: From CPL to SPL <?xml version="1.0" encoding="UTF-8"?> <cpl> <subaction id="voicemail"> <location url="sip:bob@voicemail.example.com"> <redirect/> </location> </subaction> <incoming> <location url="sip:bob@phone.example.com"> <proxy> <busy> <sub ref="voicemail"/> </busy> <otherwise> <address-switch field="origin"> <address is="sip:boss@example.com"> <location url="tel:+19175554242"> <proxy /> </location> </address> </address-switch> </otherwise> </proxy> </location> </incoming> </cpl> SPL service example { processing { dialog { 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; } } } } CPL

Compilation: From CPL to SPL <?xml version="1.0" encoding="UTF-8"?> <cpl> <incoming> <location url="sip:bob@phone.example.com"> <proxy> <busy> <location url="sip:bob@voicemail.example.com"> <proxy /> </busy> <otherwise> <address-switch field="origin"> <address is="sip:boss@example.com"> <location url="tel:+19175554242"> <proxy /> </location> </address> </address-switch> </otherwise> </proxy> </location> </incoming> </cpl> • RuleRedirectNonTerminal : • <location url="callee"> <proxy> <busy> stat1* </busy> <otherwise> stat2* </otherwise> </proxy> </location> • -> • |[ response r = forward callee ; • if ( r == /ERROR/CLIENT/BUSY_HERE ) { • stat1* • } else { • stat2* • } ]| • where new => r • RuleFROMTest : • <address-switch field="origin"> <address is="caller"> stat1* </address> </address-switch> • -> • |[ if (FROM == caller) { • stat1* • } ]| service example { processing { dialog { 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; } } } }

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 ≠ {})

Verification of Call Routing Properties CPL • Properties • No redirect to the caller, • No duplicate redirect, • No infeasible path, • Service interaction. 1 Incoming call Is the day of the call Tuesday ? 2 Weekly meeting no yes 3 ... Forward call to Bob’s phone 4 Is the date of the call between 07/12 and 07/17 ? 5 Annual holidays yes no Redirect call to Bob’s voice mail Redirect call to Bob’s cell phone 6 7

Graphical environment Tightly coupled with information systems VisuCom

VisuCom Service Model checking Call routing logic Contact database Service • 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

Verification of Call Routing Properties VisuCom • Properties • No redirect to the caller, • No duplicate redirect, • No infeasible path, • Service interaction. Data model:Group customer: Alice, Bob, Daniel Group VIP: Frank  No intersection

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: <Initial predicate> /\ callerTests = << >> /\ currentNode = "Incoming" /\ signalingActions = << >> STATE 2: <Action line 32, col 9 to line 34, col 54 of module VisuCom> /\ callerTests = << >> /\ currentNode = "CustomerGroup" /\ signalingActions = << >> STATE 3: <Action line 37, col 9 to line 40, col 53 of module VisuCom> /\ callerTests = << {"Alice", "Bob", "Daniel"} >> /\ currentNode = "VIPGroup" /\ signalingActions = << >> STATE 4: <Action line 49, col 9 to line 52, col 59 of module VisuCom> /\ callerTests = << {"Alice", "Bob", "Daniel"}, {"Frank"} >> /\ 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.

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.

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.

Staging Telephony Service Creation: A Language Approach