Compartir a través de


Accepting an Incoming Call (NDIS 5.1)

Note   NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.

After an NDIS WAN miniport driver has successfully completed an OID_TAPI_PROVIDER_INITIALIZE request, an OID_TAPI_OPEN request, and an OID_TAPI_SET_DEFAULT_MEDIA_DETECTION, it can receive an incoming call on the previously opened line. If the media type matches one it has been set to detect, the miniport driver should call NdisMIndicateStatus to notify upper layers of the offered call, passing NDIS_STATUS_TAPI_INDICATION as the GeneralStatus, and a pointer to the NDIS_TAPI_EVENT structure as the StatusBuffer.

The ulMsgmember of NDIS_TAPI_EVENT is set to LINE_NEWCALL, and the ulParam1 is set to hdCall, the driver-assigned handle for the call. The htCall, ulParam2, and ulParam3 members are set to zero. NDISTAPI will supply an htCall in ulParam2 before returning from NdisMIndicateStatus. The miniport driver should retain this handle and use it in any subsequent indications pertaining to this call instance. For example, the miniport driver will supply this value as the ConnectionWrapperID when it indicates a line up to NDISWAN.

After the miniport driver has given a LINE_NEWCALL status indication, it should call NdisMIndicateStatus, with a LINECALLSTATE_XXX message, typically a LINECALLSTATE_OFFERING message. The ulParam3 of this message is set with the media mode of the incoming call.

If the call is accepted by an application, MiniportSetInformation will be called with an OID_TAPI_ACCEPT followed by an OID_TAPI_ANSWER request or simply with an OID_TAPI_ANSWER request.

If the miniport driver receives an OID_TAPI_ACCEPT request, it should allocate and initialize a call-state context for the call, but it should not answer the call until it receives an answer request. Later, if it receives an OID_TAPI_ANSWER request, it should do the following:

  • Answer the call.

  • Set the state of the line to connected and call NdisMIndicateStatus to report this new status if reporting of this status is enabled.

If the miniport driver receives an OID_TAPI_ANSWER request without first receiving an OID_TAPI_ACCEPT request, it should behave as if it had received both requests.

It is possible that a WAN NIC driver will never receive an OID_TAPI_ANSWER request or an OID_TAPI_ACCEPT request for an incoming call. This could occur when client applications are busy with other calls, or when clients are not interested in calls of the type indicated (for example, the media mode), and so forth. After waiting a certain amount of time for an answer or accept request or detecting that the remote party disconnected, the WAN NIC driver should notify the NDISTAPI driver that the call has transitioned to the idle state. Then, at some later time, an OID_TAPI_CLOSE_CALL request will be sent to the WAN NIC driver to free up the call instance. It is also possible that after the miniport driver offers the incoming call, it will receive an OID_TAPI_CLOSE_CALL before it can time out the new call offer.

 

 

Send comments about this topic to Microsoft