Most functions on calls only make sense while the call is in one of certain call states. This call state is checked, and the function returns an error if the call is not in one these states. The effect of the successful execution of a request may be some typical call state transitions. The service provider notifies TAPI about call state changes using call state messages. These messages report the state the call has just entered to TAPI and to applications. Because unsolicited events may occur to calls (as when the other party disconnects), tapi32.dll cannot assume that requests it issues always result in certain fixed call state transitions.
This model gives the service provider designer maximum flexibility across different telephony environments. For example, it allows designs in which requests propagate through a network to a Telelphony server, such as a PBX, while call state change reports propagate back to the local client at some later time. Such a design need not try to maintain a lock-step "view" of the current state of the call in both client and server that is always identical between the two sites.