PART FIVE: SOME VERIFICATION CHALLENGES a DFC case study with - PowerPoint PPT Presentation

PART FIVE: SOME VERIFICATION CHALLENGES a DFC case study with several verification problems, all concerning signaling properties and event-based feature interactions

SIGNALING INTERACTIONS transparency: a box behaves transparently autonomy: each box has the power when its functions are not needed it needs to perform its functions independently IVR dialogue with caller; target caller chooses whether QT RVM zone to interrupt targeted subscriber if no, QT sends unavail upstream if yes, QT continues the chain and becomes transparent IVR dialogue with caller; caller records voice absorb RVM mail in subscriber's failures mailbox of QT PR RVM single branches if whole attempt times out, send unavail upstream context independence: by its behavior and its place in the if single branch succeeds, precedence order, a feature send avail upstream box can trigger, delay, or cancel other features without knowing whether they are QT PR RVM present or what they are

BOXTALK EXAMPLE: CALL FORWARDING ON BUSY continuation without address translation uncertainty is resolved by the first outcome rcv(i) / ctu(i,o) signal uncertain: (i,o), (i[v],o[v]) this is a Boxtalk program, in graphical syntax o?unavail / o?avail, end(o); o?unknown ctu(i,o){trg=fwd_addr} Boxtalk implementation sets up and tears down calls, so the programmer only works continuation with directly with status signals transparent: address translation (i,o), (i[v],o[v]) each active call must be referred to by a call variable; each responsive state lists the variables of all active calls

a feature box should be INPUT-ENABLED, i.e., guaranteed to read every input signal in a prompt fashion BOXTALK EXAMPLE: CALL LOGGER this box can be used in a source or target zone i:setup.regn=="src" / direc="outgoing" rcv(i) / ctu(i,o) uncertain: (i,o), (i[v],o[v]) i:setup.regn=="trg" / direc="incoming" in a transient state, the box is not responsive to inputs o?avail / outcome= o?unavail, "success"; o?unknown / in a stable state, a response log_call outcome= to every received signal "failure"; is defined: log_call transparent: if there is an explicit transition (i,o) execute it (i[v],o[v]) else if the signal is a teardown tear down all calls and quit else if the source of the signal is linked send signal to all linked calls else discard the signal

A CASE STUDY HISTORY BOUNDARIES these features are the relevant part the only devices are "black phones" of a feature set that was deployed by AT&T in a consumer trial of VoIP no source feature boxes October 2003 to March 2004 no bound feature boxes most of them are now in CallVantage, which is AT&T's VoIP a feature box can only use the new service method to place a call to a resource when the feature set was designed, the feature interactions were a feature box cannot use the rev analyzed manually and heuristically method WHAT CAN HAPPEN THAT IS INTERESTING? a target region can contain several target zones a usage can reach an interface box, or stop at some feature box a usage can fork a usage can have multiple, sequential extensions downstream of a feature box

BOUND BOX: BLACK PHONE INTERFACE (SIMPLIFIED) rcv( c ) offhook ringing: c, dialing: ( c[v], phone ) dialed / new(c) { dld=dialed_string } busytone: * silent: c offhook / c c?unavail c!avail * * waiting(c[v]) talking: accepted(c[v]) c, ( c[v], phone ) ringback: c * gone(c) * * onhook disconnected: from (almost) any state

FREE BOX: PARALLEL FIND ME box generates unavail under many different rcv( i ) no_loc_exists / i!unavail circumstances database _query exist_2_locs / exists_1_loc / ctu( i, o1 ){ trg=loc1 }; ctu( i, o1){ trg=loc1 }; ctu( i, o2 ){ trg=loc2 }; t!tset{ duration="40" } t!tset{ duration="40" } o1?unknown, onering: tworings: o1?unavail / end( o1); o1,o2 = o2,- ( i, o1 ) i, o1, o2 ( i[v], o1[v] ) ( i[v], waiting ) t?tout / o1?unknown, gone( o1 ) / o1,o2 = o2,- i!unavail o1?unavail, t?tout / o1?avail / i!avail; end( o2 ) i!unavail o2?unknown, o2?unavail / end( o2 ) gone( o2 ) o2?avail / i!avail; end(o1); o1,o2 = o2,-

FREE BOX: QUIET TIME dialogue says that the subscriber wishes not to be disturbed, box generates unavail prompts caller to leave a message (choice "quit") or interrupt the subscriber (choice "ctu") r?response{ choice="quit" }, t?tout / enabled / i!unavail t!tset{ duration="30" }; new( r ) dialogue: { dld="voicexml_server", ( i, r ) script="quiet_time" } ( i[v], r[v] ) rcv( i ) r?response { choice="ctu" } / end( r ); ctu( i, o ) ! / ctu( i, o ) transparent: ( i, o ) ( i[v], o[v] )

FREE BOX: RECEIVE VOICE MAIL box converts unavail from downstream to avail going upstream transparent: rcv( i ) / ctu( i, o ) ( i, o ) ( i[v], o[v] ) o?unavail / i!avail; end( o ); new( r ){ dld="voicexml_server", script="voice_mail" } r?response{ choice="end" } dialogue: ( i, r ) ( i[v], r[v] ) dialogue offers caller the opportunity to record voice mail

FREE BOX: ANSWER CONFIRM rcv( i ) / ctu( i, o ) trying: ( i, o ) o?avail, accepted( o[v] ) / new( r ) the dialogue prompts {dld="voicexml_server", the callee to enter a script="answer_confirm"} digit confirming the primary purpose presence and identity is to prevent this: confirming: cellphone is unavailable; i, ( o, r ) cellphone voice mail answers (o[v], r[v] ) the call, preempting the possibility that a person could r?response answer the other phone { choice="confirmed" } / i!avail; end( r ) PFM transparent: R V M ( i, o ) ( i[v], o[v] ) Answer Confirm goes here; it will convert success to failure if no digit is entered

FREE BOX: SEQUENTIAL FIND ME rcv( i ) no_loc_exists / i!unavail database _query ! / ctu( i, o ){trg=head_loc_list }; loc_list_empty / dehead_loc_list; i!unavail t!tset{ duration="40" } o?unknown, o?unknown, o?unavail, o?unavail, nexttry: t?tout / t?tout / firsttry: ( i, r ), o end( o ) end( o ) ( i, o ) ( i[v]<r[v] ) gone( o ) gone( o ) ! / ctu( i, o ) ( i[v], o[v] ) {trg=head_loc_list }; dehead_loc_list; t!tset{ duration="40" }; ! / new(r) ctu( i, o ) { dld="voicexml_server", {trg=head_loc_list }; script="sequ_findme" } dehead_loc_list; o?avail / i!avail t!tset { duration="40" } transparent: ( i, o ) ( i[v], o[v] ) o?avail / i!avail; end( r )

VERIFICATION CHALLENGES A COMPLETE SPECIFICATION OF A CHALLENGES FEATURE SET BASED ON THESE PROGRAMS MUST ALSO INCLUDE: Within the boundaries of this study, what are the correctness criteria a precedence partial order on the for feature sets? feature box types AC, PFM, QT, RVM, SFM Complete the specification of a feature set based on these constraints on which addresses programs, and prove that it can subscribe to which features satisfies the correctness criteria. constraints on the addresses used Devise constraints on box by Find Me features behavior, precedence, subscriptions, and operational data that guarantee the correctness criteria. WE CONSIDER THE INTERACTIONS AMONG THESE FEATURES THAT ARE Prove that the design constraints GOVERNED BY GENERAL PRINCIPLES, guarantee correctness. NOT PERSONAL CHOICE Show that the design constraints allow reasonable features to do their jobs. I DO NOT KNOW THE ANSWERS!