NdisMCmMakeCallComplete returns the final status of a client's request, for which the MCM driver previously returned NDIS_STATUS_PENDING, to make an outgoing call.
VOID NdisMCmMakeCallComplete( [in] NDIS_STATUS Status, [in] NDIS_HANDLE NdisVcHandle, [in, optional] NDIS_HANDLE NdisPartyHandle, [in, optional] NDIS_HANDLE CallMgrPartyContext, [in] PCO_CALL_PARAMETERS CallParameters );
An MCM driver should call NdisMCmMakeCallComplete with NDIS_STATUS_SUCCESS only if it is ready to make data transfers on the VC. That is, the MCM driver has negotiated with the network to establish the call parameters for the VC, set up a NIC for those call parameters, and called NdisMCmActivateVc to notify NDIS of the VC activation.
An MCM driver must call NdisMCmMakeCallComplete if its ProtocolCmMakeCall function previously returned NDIS_STATUS_PENDING for the given NdisVcHandle .The client, which initiated the pending outgoing call, cannot use the VC to make transfers until the miniport driver calls NdisMCmMakeCallComplete with NDIS_STATUS_SUCCESS.
Even if the attempted connection failed, neither NDIS nor the client can release the resources they allocated to maintain state until the MCM driver's call to NdisMCmMakeCallComplete causes a call to that client's ProtocolClMakeCallComplete function. In fact, neglecting to call NdisMCmMakeCallComplete for a failed attempt to set up such a connection causes a memory leak in the MCM driver as well; it prevents the client from tearing down the VC it created for its failed outgoing call, so the MCM driver's ProtocolCoDeleteVc function is not called to release the resources the miniport driver allocated for that VC.
If the MCM driver passes an error, such as NDIS_STATUS_FAILURE, for the Status, it must consider the NdisPartyHandle, if any, invalid when NdisMCmMakeCallComplete returns control. The CM can release (or reinitialize for reuse) any resources that it allocated to maintain state for the given party after NdisMCmMakeCallComplete returns control. The MCM driver's ProtocolCoDeleteVc function will subsequently be called to release any resources that the miniport driver allocated for tracking the state of the client-created VC whenever the MCM driver passes an error status to NdisMCmMakeCallComplete.
In the course of setting up a client-initiated outgoing call, the MCM driver can modify the client-supplied call parameters originally passed in to its ProtocolCmMakeCall function. If it does, the MCM driver must pass its modifications in the buffer at CallParameters when it calls NdisMCmMakeCallComplete. If the client finds these modified call parameters unacceptable, it will then tear down the call, which also causes a call to the MCM driver's ProtocolCoDeleteVc function.
Only connection-oriented miniport drivers that provide integrated call-management support can call NdisMCmMakeCallComplete. Stand-alone call managers, which register themselves with NDIS as protocol drivers, call NdisCmMakeCallComplete instead.
|Windows version||Supported for NDIS 6.0 and NDIS 5.1 drivers (see NdisMCmMakeCallComplete (NDIS 5.1)) in Windows Vista. Supported for NDIS 5.1 drivers (see NdisMCmMakeCallComplete (NDIS 5.1)) in Windows XP. Supported for NDIS 6.0 and NDIS 5.1 drivers (see NdisMCmMakeCallComplete (NDIS 5.1)) in Windows Vista. Supported for NDIS 5.1 drivers (see NdisMCmMakeCallComplete (NDIS 5.1)) in Windows XP.|
|Header||ndis.h (include Ndis.h)|
|DDI compliance rules||Irql_MCM_Function|