Parameters

_S_

TBD

_VH_

TBD

_PH_

TBD

_CC_

TBD

_CP_

TBD

Return Value

None

Remarks

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.

See Also

The feedback system for this content will be changing soon. Old comments will not be carried over. If content within a comment thread is important to you, please save a copy. For more information on the upcoming change, we invite you to read our blog post.