Only One Media Mode Bit Is Set
If only one media mode bit (not
the UNKNOWN bit) has been set in the dwMediaMode
field of the LINECALLINFO
data structure, TAPI distributes calls by following a consistent procedure
based on the current state of the system and on information saved by the user in
the registry. These are the steps it takes:
- The TAPI dynamic-link library is notified by the service provider that a call
- The TAPI library uses the information in the HandoffPriorities section of the
registry to know which applications have been listedpossibly through a Preferences option in the application's user interfaceas being interested in calls having the incoming call's media mode.
- The first such application listed, reading left to right, is the highest
priority application. If that application is currently running and has the arriving
call's line open for that media mode, it is given ownership of the call. If it
is not running or it does not have that line open, TAPI again uses the
information in the registry to find an interested application in the correct state, and
it gives the call to it.
- If none of the applications listed in the registry are in the proper state,
TAPI looks for other applications that are currently executing and have the line
open for that media mode (though they are not listed in the registry). The
relative priority among these unlisted applications is arbitrary and not
necessarily associated with the sequence in which they were launched or opened the line.
- Every application that has the line open for monitoring also receives a handle
to a call, and any of them could step up, claim ownership (by calling lineSetCallPrivilege), and answer the call. However, this behavior could result in race conditions and unpredictable call handling, and is therefore discouraged.
- If no application becomes an owner of the call, the call is eventually
dropped. Calls can be dropped by TAPI only if no owner is found for the call and the
call state is not idle or offering. The calling party can also drop the call. (On an ISDN network, this event
becomes known when a "call-disconnect" frame is received.) If the call is not
explicitly dropped, it can go idle after the expiration of a timeout based on the
absence of ringing. (The service provider would need to assume that the call
has been dropped by the calling party, and implement the timeout.) Because there
were no applications that could take the call successfully, this situation
usually means that the incoming call reached a wrong number.
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages