Only One Media Mode Bit Is Set

If only one media mode bit (not the UNKNOWN bit) has been set in the dwMediaMode member 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 DLL is notified by the service provider that a call is arriving.
• The TAPI DLL uses the information in the HandoffPriorities subkey of the registry to know which applications are listed, possibly through a Preferences option in the application's user interface, as 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.