Example of Controlling a Telephone

| iMatix home page
| Libero home page | Libero documentation
| << | < | > | >>

Libero
Version 2.32

Example of Controlling a Telephone

This next example is one that a correspondent at a telephone company proposed. It's a design for a simple but dedicated subprogram (we'll call it 'Rover') that hangs-around on the corner of our telephone central. Rover springs into action (presumably woofing and waggling a shaggy tail) when we pick-up the handset, or when a call comes in for us. The dialog loops around and around, each time driven by an 'incoming message'. This message is one of these events:

Offhook - we picked-up the handset. Presumably this affects the current on the line, which the central can detect.
Onhook - we put the phone down.
Request - another person is calling us from a 'remote' phone.
Digit - we pressed a digit on the touchpad.
Whole Number - we pressed enough digits to form a recognised number.
Accept - the remote phone accepted the call - ie. the remote Rover gets a Request event of its own.
Busy - the remote phone was busy.
Reject - the remote phone number was rejected - we made a mistake with the number, or (if dialing into Britain) the British changed their dialing prefixes again.
Answer - finally, contact. I hope it was worth it.
Release - the remote phone cut the Talking. At our end we hear a tone that signals this. (This is how my telephone central works.)

Here is the dialog. Rover waits for anything to happen, then leaps:

After-Init:
    (--) Ok                           -> Idle
          + Wait-For-Incoming-Message
    (--) Error                        ->
          + Terminate-The-Program

The two possible events at this stage are Offhook (coming from the local phone), and Request (from a remote phone). We call this state 'Idle'. Some people get confused at this point, and point out that Rover is exactly not idle, so why the name. Why not call the very first state 'Idle'? I answer so: the name of a state reflects the state we were in when the event happened. Thus, when Rover was idle, the only two events that could happen were Offhook and Request.

Idle:
    (--) Offhook                      -> Dialing-First
          + Start-Dial-Tone
          + Reset-Dialed-Number
          + Wait-For-Incoming-Message
    (--) Request                      -> Ringing
          + Start-Ringing-Local
          + Wait-For-Incoming-Message

The next two states show what happens when we dial the first digit. Rover stops with the dial tone, and slurps up the digits we press, one by one. I distinguish Dialing-First from Dialing-Next to ensure that Rover does a Stop-Local-Tones the first time only:

Dialing-First:
    (--) Digit                        -> Dialing-Next
          + Stop-Local-Tones
          + Have-Dialed-Digit
          + Wait-For-Incoming-Message
    (--) Whole-Number                 -> Seizing
          + Stop-Local-Tones
          + Send-Outgoing-Request
          + Wait-For-Incoming-Message
    (--) Onhook                       -> Idle
          + Stop-Local-Tones
          + Wait-For-Incoming-Message

Rover doesn't bother handling the Onhook event here, since the Defaults state handles it just fine:

Dialing-Next:
    (--) Digit                        -> Dialing-Next
          + Have-Dialed-Digit
          + Wait-For-Incoming-Message
    (--) Whole-Number                 -> Seizing
          + Stop-Local-Tones
          + Send-Outgoing-Request
          + Wait-For-Incoming-Message

Okay, we just tried to 'seize' the remote phone. This is either accepted (and the remote phone starts ringing) or rejected for various reasons:

Seizing:
    (--) Accept                       -> Ringing
          + Start-Ringing-Remote
          + Wait-For-Incoming-Message
    (--) Busy                         -> Seize-Failed
          + Start-Busy-Tone
          + Wait-For-Incoming-Message
    (--) Reject                       -> Seize-Failed
          + Start-Reject-Tone
          + Wait-For-Incoming-Message

Seize-Failed:
    (--) Onhook                       -> Idle
          + Stop-Local-Tones
          + Wait-For-Incoming-Message

The next three states show how Rover handles a ringing phone (at either end) and the eventual Talking, if any. I combined the handling for the local and remote phones into two states; I could also write this more clearly but verbosely as four states (Ringing-Local, Ringing-Remote, Talking-Local, Talking-Remote).

Ringing:
    !  Events from local phone
    (--) Offhook                      -> Talking
          + Stop-Ringing-Local
          + Wait-For-Incoming-Message
    (--) Onhook                       -> Idle
          + Stop-Ringing-Remote
          + Wait-For-Incoming-Message
    !  Event from remote phone
    (--) Answer                       -> Talking
          + Stop-Ringing-Remote
          + Wait-For-Incoming-Message

Talking:
    !  Event from local phone
    (--) Onhook                       -> Idle
          + Send-Outgoing-Release
          + Wait-For-Incoming-Message
    !  Event from remote phone
    (--) Release                      -> Released
          + Start-Released-Tone
          + Wait-For-Incoming-Message

Released:
    (--) Onhook                       -> Idle
          + Stop-Local-Tones
          + Wait-For-Incoming-Message

The Defaults state handles the Onhook event in those states where there is no local tone. In those states (like Released), Rover silences the local phone, then loops back to the Idle state:

Defaults:
    (--) Onhook                       -> Idle
          + Wait-For-Incoming-Message