#10 Odd state behavior in emulator
in the emulator. When I take a phone off-hook and dial another, once I dial the number and click the button to make the call, the legend reverts from "Off Hook" to "On Hook". When I click to pick up the called phone's "handset", the status indicator on the first phone still shows as "Dialing...", even though the called phone shows "Active".
None of this prevents ending the calls, though, so at first it appeared that it was operationally relatively benign. However, I started examining the event stream and I get no call event when the second phone picks up. The following sequence surprised me.
23 [off hook] - callActive (23<Idle>)
23 [dial 22] - callActive From 23 (22<Idle>, 23<Connected>)
22 [off hook] - No event delivered!
23 [on hook] - four events in rapid succession
callEventTransmissionEnded From 23 To 22 (22<Connected>)
callActive (No connections - my test rig doesn't show if list is empty or null)
callActive (22<Idle>,23<Idle>)
callEventTransmissionEnded <Invalid> From 23 To 22 (connection list null)
22 [on hook] - callEventTransmissionEnded <Invalid> (connection list null)
Snapshot of logging
Silly me - of course the other phone picking up doesn't change the _call_ state, only the _connection_ state. I'll recheck the underlying behavior with a proper listener and respond if there's still a problem. This is probably purely a cosmetic thing in the GUI rather than a state thing in the connections as the emulator is otherwise _behaving_ correctly. (Expect a richer sample from me for testing this stuff, too, Richard.)
So with connection and terminal connection events, it looks more like this.
When 22 connects, there is no connection or terminal connection event on 23 to suggest that it is no longer dialing.
"Dialing" isn't properly a state at the core Connection level, but is at the CallControlConnection level.
The connections used in the emulator apparently don't inherit from CallControlConnection,
The calls and terminal connections do inherit from the CallControl layer interfaces. The discrepency is odd.
It appears that there is a new call that first appears when the originator hangs up. I'm not sure if this is expected.
The @ gives hash of object to distinguish them.
A * indicates that the object in question inherits the interface for call control.
The [brackets] contain the list of connections for a call, with states
callActive: @11024915 * [23@12518719(Idle)]
connectionCreated: 23@12518719(Idle)
connectionCreated: 23@12518719(Idle)
terminalConnectionCreated: 23@13301441 * (Idle)
connectionConnected: 23@12518719(Connected)<23>
terminalConnectionActive: 23@13301441 * (Active)
callActive: @11024915 * [22@13594894(Idle), 23@12518719(Connected)<23>]
connectionConnected: 23@12518719(Connected)<23>
terminalConnectionActive: 23@13301441 * (Active)
connectionCreated: 22@13594894(Idle)
connectionCreated: 22@13594894(Alerting)
connectionCreated: 22@13594894(Alerting)
connectionAlerting: 22@13594894(Alerting)
connectionAlerting: 22@13594894(Alerting)
terminalConnectionCreated: 22@32816375 * (Ringing)
terminalConnectionCreated: 22@32816375 * (Ringing)
terminalConnectionRinging: 22@32816375 * (Ringing)
terminalConnectionRinging: 22@32816375 * (Ringing)
connectionConnected: 22@13594894(Connected)<22>
connectionConnected: 22@13594894(Connected)<22>
terminalConnectionActive: 22@32816375 * (Active)
terminalConnectionActive: 22@32816375 * (Active)
terminalConnectionDropped: 23@13301441 * (Dropped)
terminalConnectionDropped: 23@13301441 * (Dropped)
connectionDisconnected: 23@12518719(Disconnected)
connectionDisconnected: 23@12518719(Disconnected)
callEventTransmissionEnded: @11024915 * [22@13594894(Connected)<22>, 23@12518719(Disconnected)]
callActive: @27988400 * [22@1465214(Idle)]
connectionCreated: 22@1465214(Idle)
connectionCreated: 22@1465214(Idle)<22>
terminalConnectionCreated: 22@11576309 * (Idle)
terminalConnectionDropped: 22@32816375 * (Dropped)
connectionDisconnected: 22@13594894(Disconnected)
callEventTransmissionEnded: @11024915 * [Null connection list]
terminalConnectionDropped: 22@11576309 * (Dropped)
connectionDisconnected: 22@1465214(Disconnected)
callEventTransmissionEnded: @27988400 * [Null connection list]
The previous trace has a number of duplications due to using multiple copies of the listener rather than instantiating one listener and using it everywhere. Those can safely be ignored. With a correction to the test code to use a single listener instance, there are only 24 event occurrences logged.