charles consel 1, fabien latry 1, and julien mercadal 1 iptcomm – july 2007 1 phoenix research...

Charles Consel1, Fabien Latry1, and Julien Mercadal1

IPTComm – July 2007

1Phoenix Research GroupINRIA / LaBRI

http://phoenix.labri.fr

Staging Telephony Service Creation:Staging Telephony Service Creation:A Language ApproachA Language Approach

Phoenix Group - INRIA / LaBRIIPTComm - July 2007 2

ContextContext

Why ?– Expectations among users to create telephony services.

What ?– Call routing services,– Signaling-related operations.

Where ?– Located on network servers.


Challenges in Call Routing ServicesChallenges 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 GapBridging The Gap

Gap between business IT

Telephony expert

service logic

Implementation expert

technologies



public class Example { [...] private AddressFactory factory = getAddressFactory();

public void processRequest (Request rq){ ... }}



DomainKnowledge

DomainKnowledge

What

How

GA

P

Call routing domain – Telephony experts,– High level (e.g., modeling) – Code generation difficult.

Call routing implementation – Implementation experts,– Technology dependant,– Code verification difficult.


Our ApproachOur 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 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 Domain-Specific Languages







DomainKnowledge

DomainKnowledge

What

How

GA

PDSML

Implementation

Modeling

Implementation


A Layered ApproachA Layered Approach

DSML– Targets the DSPL– Verification of domain

properties

DSPL – Interface between the domain

and the implementation– Generates implementation

DSML

Implementation

Modeling

Implementation

ProgrammingDSPL


A DSPL as a Pivotal LayerA 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

…

…


Staging ProcessingsStaging 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


Processing DSMLs: Processing DSMLs: Case StudyCase Study

DSMLs– CCall PProcessing LLanguage (CPL)

» XML-based scripting language,» Domain experts, non-programmers.

– VisuCom» Graphical language,» Domain experts, non-programmers

DSPL– SSession PProcessing LLanguage (SPL)

» Abstracts over underlying protocols, platform,» Programmers.

High-level tools– Program generation,– Program verification.


Processing DSMLs: Processing DSMLs: Case StudyCase Study

Compilation

Verification

Stratego/XT

TLC Model Checker

Stratego/XT

ErrorReport

SPL Program

CPL or VisuComProgram

TLA+ Specification


Compilation: From CPL to SPLCompilation: From CPL to SPL

<?xml version="1.0" encoding="UTF-8"?><cpl> <subaction id="voicemail"> <location url="sip:[email protected]"> <redirect/> </location> </subaction> <incoming> <location url="sip:[email protected]"> <proxy> <busy> <sub ref="voicemail"/> </busy> <otherwise> <address-switch field="origin"> <address is="sip:[email protected]"> <location url="tel:+19175554242"> <proxy /> </location> </address> </address-switch> </otherwise> </proxy> </location> </incoming></cpl>

service example { processing { dialog { response incoming INVITE()INVITE() { response r = forward 'sip:[email protected]'; if (r == /ERROR/CLIENT/BUSY_HERE) { return forward 'sip:[email protected]'; } else if (r == /ERROR) { if (FROM == 'sip:[email protected]') { return forward 'tel:+19175554242'; } } return r; } } } }

SPL

CPL


Compilation: From CPL to SPLCompilation: From CPL to SPL

service example { processing { dialog { response incoming INVITE()INVITE() { response r = forward 'sip:[email protected]'; if (r == /ERROR/CLIENT/BUSY_HERE) { return forward 'sip:[email protected]'; } else if (r == /ERROR) { if (FROM == 'sip:[email protected]') { return forward 'tel:+19175554242'; } else { return r; } } return r; } } } }

<?xml version="1.0" encoding="UTF-8"?><cpl> <incoming> <location url="sip:[email protected]"> <proxy> <busy> <location url="sip:[email protected]"> <proxy /> </busy> <otherwise> <address-switch field="origin"> <address is="sip:[email protected]"> <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* } ]|


Verification of Call Routing PropertiesVerification 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 ≠ {})



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 Bob’s phone

...

yes

Redirect call to Bob’s voice mail

Is the date of the call between 07/12and 07/17 ?

no

Redirect call to Bob’s cell phone

yes

Weekly meeting

Annual holidays

1

2

3

5

6 7

4

CPL


VisuComVisuCom

Graphical environment Tightly coupled with information systems


VisuCom Service ModelVisuCom 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



Properties– No redirect to the caller,– No duplicate redirect,– No infeasible path,– Service interaction.

VisuCom

Data model:Group customer: Alice, Bob, DanielGroup VIP: Frank

No intersection


TLC Error ReportTLC Error Report

TLC Version 2.0 of January 16, 2006Model-checkingImplied-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.


AssessmentAssessment

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.


ConclusionConclusion

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.

charles consel 1, fabien latry 1, and julien mercadal 1 iptcomm – july 2007 1 phoenix research...

Documents

domain verification

domain experts

domain expertise

spl cpl slide

language approach slide

specification slide

frprocessings slide

gap gap