SLIDE 1
PART FIVE: SOME VERIFICATION CHALLENGES
a DFC case study with several verification problems, all concerning signaling properties and event-based feature interactions
SLIDE 2 SIGNALING INTERACTIONS
transparency: a box behaves transparently when its functions are not needed autonomy: each box has the power it needs to perform its functions independently RVM RVM RVM context independence: by its behavior and its place in the precedence order, a feature box can trigger, delay, or cancel other features without knowing whether they are present or what they are PR target zone IVR dialogue with caller; caller chooses whether to interrupt targeted subscriber IVR dialogue with caller; caller records voice mail in subscriber's mailbox if no, QT sends unavail upstream if yes, QT continues the chain and becomes transparent RVM PR if single branch succeeds, send avail upstream if whole attempt times out, send unavail upstream absorb failures
single branches QT QT QT
SLIDE 3 BOXTALK EXAMPLE: CALL FORWARDING ON BUSY
uncertain: (i,o), (i[v],o[v]) transparent: (i,o), (i[v],o[v]) rcv(i) / ctu(i,o)
- ?avail,
- ?unknown
- ?unavail /
end(o); ctu(i,o){trg=fwd_addr} continuation without address translation continuation with address translation this is a Boxtalk program, in graphical syntax Boxtalk implementation sets up and tears down calls, so the programmer only works directly with status signals uncertainty is resolved by the first outcome signal each active call must be referred to by a call variable; each responsive state lists the variables of all active calls
SLIDE 4 a feature box should be INPUT-ENABLED, i.e., guaranteed to read every input signal in a prompt fashion
BOXTALK EXAMPLE: CALL LOGGER
rcv(i) / ctu(i,o) i:setup.regn=="trg" / direc="incoming" i:setup.regn=="src" / direc="outgoing"
"success"; log_call
- ?unavail,
- ?unknown /
- utcome=
"failure"; log_call uncertain: (i,o), (i[v],o[v]) transparent: (i,o) (i[v],o[v]) in a transient state, the box is not responsive to inputs in a stable state, a response to every received signal is defined: if there is an explicit transition execute it 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 this box can be used in a source or target zone
SLIDE 5 A CASE STUDY
HISTORY BOUNDARIES these features are the relevant part
- f a feature set that was deployed
by AT&T in a consumer trial of VoIP October 2003 to March 2004 most of them are now in CallVantage, which is AT&T's VoIP service when the feature set was designed, the feature interactions were analyzed manually and heuristically the only devices are "black phones" no source feature boxes no bound feature boxes a feature box can only use the new method to place a call to a resource a feature box cannot use the rev method WHAT CAN HAPPEN THAT IS INTERESTING? a target region can contain several target zones a usage can reach an interface box,
- r stop at some feature box
a usage can fork a usage can have multiple, sequential extensions downstream
SLIDE 6 BOUND BOX: BLACK PHONE INTERFACE (SIMPLIFIED)
rcv( c ) dialing: ringing: c, ( c[v], phone ) talking: c, ( c[v], phone ) silent: c busytone: c ringback: c disconnected:
c!avail dialed / new(c) { dld=dialed_string }
waiting(c[v]) accepted(c[v]) c?unavail gone(c)
* * * * * *
from (almost) any state
SLIDE 7 FREE BOX: PARALLEL FIND ME
( i, o1 ) ( i[v], o1[v] ) tworings: i, o1, o2 ( i[v], waiting ) rcv( i ) box generates unavail under many different circumstances no_loc_exists / i!unavail database _query exist_2_locs / ctu( i, o1 ){ trg=loc1 }; ctu( i, o2 ){ trg=loc2 }; t!tset{ duration="40" } exists_1_loc / ctu( i, o1){ trg=loc1 }; t!tset{ duration="40" }
t?tout / i!unavail t?tout / i!unavail
end( o1); o1,o2 = o2,- gone( o1 ) / o1,o2 = o2,-
- 1?avail / i!avail; end( o2 )
- 2?unknown, o2?unavail / end( o2 )
gone( o2 )
- 2?avail / i!avail; end(o1); o1,o2 = o2,-
SLIDE 8
FREE BOX: QUIET TIME
transparent: ( i, o ) ( i, r ) ( i[v], o[v] ) ( i[v], r[v] ) dialogue: r?response { choice="ctu" } / end( r ); ctu( i, o ) r?response{ choice="quit" }, t?tout / i!unavail rcv( i ) ! / ctu( i, o ) enabled / t!tset{ duration="30" }; new( r ) { dld="voicexml_server", script="quiet_time" } dialogue says that the subscriber wishes not to be disturbed, prompts caller to leave a message (choice "quit") or interrupt the subscriber (choice "ctu") box generates unavail
SLIDE 9 FREE BOX: RECEIVE VOICE MAIL
rcv( i ) / ctu( i, o )
i!avail; end( o ); new( r ){ dld="voicexml_server", script="voice_mail" } r?response{ choice="end" } transparent: ( i, o ) ( i, r ) ( i[v], o[v] ) ( i[v], r[v] ) dialogue: dialogue offers caller the
voice mail box converts unavail from downstream to avail going upstream
SLIDE 10 PFM the primary purpose is to prevent this:
FREE BOX: ANSWER CONFIRM
transparent: ( i, o ) i, ( o, r ) ( i[v], o[v] ) (o[v], r[v] ) confirming: trying: ( i, o ) rcv( i ) / ctu( i, o )
- ?avail, accepted( o[v] ) /
new( r ) {dld="voicexml_server", script="answer_confirm"} r?response { choice="confirmed" } / i!avail; end( r ) the dialogue prompts the callee to enter a digit confirming presence and identity R V M cellphone is unavailable; cellphone voice mail answers the call, preempting the possibility that a person could answer the other phone Answer Confirm goes here; it will convert success to failure if no digit is entered
SLIDE 11 FREE BOX: SEQUENTIAL FIND ME
firsttry: ( i, o ) ( i, o ) ( i[v], o[v] ) ( i[v], o[v] ) nexttry: ( i, r ), o ( i[v]<r[v] ) rcv( i ) no_loc_exists / i!unavail database _query transparent: ! / ctu( i, o ){trg=head_loc_list }; dehead_loc_list; t!tset{ duration="40" } ! / ctu( i, o ) {trg=head_loc_list }; dehead_loc_list; t!tset { duration="40" } ! / ctu( i, o ) {trg=head_loc_list }; dehead_loc_list; t!tset{ duration="40" }; new(r) { dld="voicexml_server", script="sequ_findme" }
t?tout / end( o )
t?tout / end( o ) gone( o ) gone( o )
- ?avail / i!avail
- ?avail / i!avail; end( r )
loc_list_empty / i!unavail
SLIDE 12
VERIFICATION CHALLENGES
A COMPLETE SPECIFICATION OF A FEATURE SET BASED ON THESE PROGRAMS MUST ALSO INCLUDE: a precedence partial order on the feature box types AC, PFM, QT, RVM, SFM constraints on which addresses can subscribe to which features constraints on the addresses used by Find Me features WE CONSIDER THE INTERACTIONS AMONG THESE FEATURES THAT ARE GOVERNED BY GENERAL PRINCIPLES, NOT PERSONAL CHOICE CHALLENGES Within the boundaries of this study, what are the correctness criteria for feature sets? Complete the specification of a feature set based on these programs, and prove that it satisfies the correctness criteria. Devise constraints on box behavior, precedence, subscriptions, and operational data that guarantee the correctness criteria. Prove that the design constraints guarantee correctness. Show that the design constraints allow reasonable features to do their jobs. I DO NOT KNOW THE ANSWERS!
