After the NDISTAPI driver has initialized a miniport as a provider, the miniport can expect a request to open a line device at its MiniportQueryInformation function specifying OID_TAPI_OPEN and the appropriate parameters. Upon receiving an open request the miniport would typically do the following:
·Mark the line device as open in the miniport’s internal data structures.
·Save the NDISTAPI driver’s handle to the line device (passed in the htLine member), which is to be used in subsequent event notifications.
·Return its own handle to the line device (passed back in the hdLine member).
Once again, the impetus for this request would be a client process calling lineOpen.
After a client process has successfully opened a line, it can place a call on that line by calling lineMakeCall. This will result in the NDISTAPI driver’s calling NdisRequest with an OID_TAPI_MAKE_CALL, specifying the NDISTAPI-supplied handle to the line in the htLine member, and the NDISTAPI-supplied handle to the call in the htCall member. This request is passed to the miniport’s MiniportQueryInformation function, specifying OID_LINE_MAKE_CALL. If the NIC driver can successfully create the call, it passes back its own handle to the call in the hdCall member.
The two-stage htXxx/hdXxx (“handle of TAPI object Xxx/handle of Driver object Xxx”) handle scheme provides both the NDISTAPI driver and the WAN miniport NIC driver the flexibility of defining their own means of reference for the same logical object. Requests made to NIC drivers specify driver handles (hdLines and hdCalls), while notifications made to the NDISTAPI driver contain TAPI handles (htLines and htCalls). In the already mentioned cases where the miniport NIC driver is defining its driver handle to some object (for example, hdLine, hdCall), it is typically to the advantage of the NIC driver to specify a pointer to the appropriate driver-internal data structure that represents the object.
When the client process has finished with the call it will call lineDrop to drop the call, and then lineDeallocateCall to free the call instance. This will result in the NDISTAPI driver sending two more requests, OID_TAPI_DROP and OID_TAPI_CLOSE_CALL, respectively, through NDISWAN to the miniport NIC driver to drop the call and deallocate the call instance. It is also possible that the miniport will get an OID_TAPI_CLOSE_CALL request without a preceding OID_TAPI_DROP, in which case the miniport should drop the call and deallocate the call instance as if it had received both OIDs.
Finally, when the last TAPI client has called lineClose, the NDISTAPI driver will call NdisRequest to send the miniport an OID_TAPI_CLOSE request at its MiniportSetInformation function. An OID_TAPI_CLOSE can also be received on an active line. In this case, the miniport must complete or abort all outstanding calls and asynchronous requests on the device and close the line. An OID_TAPI_CLOSE request with a valid hdLine cannot be failed.