NdisMCmAddPartyComplete (NDIS 5.1) function

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.

NdisMCmAddPartyComplete returns the final status of a client's request, for which the MCM driver previously returned NDIS_STATUS_PENDING, to add a party on an established multipoint VC.

Syntax

VOID NdisMCmAddPartyComplete(
  _In_     NDIS_STATUS         Status,
  _In_     NDIS_HANDLE         NdisPartyHandle,
  _In_opt_ NDIS_HANDLE         CallMgrPartyContext,
  _In_     PCO_CALL_PARAMETERS CallParameters
);

Parameters

  • Status [in]
    Specifies the final status of the MCM driver's add-party operation, either NDIS_STATUS_SUCCESS or any NDIS_STATUS_XXX except NDIS_STATUS_PENDING.

  • NdisPartyHandle [in]
    Specifies the handle identifying the party. The MCM driver obtained this handle as input parameter to its ProtocolCmAddParty function.

  • CallMgrPartyContext [in, optional]
    Specifies the handle to a caller-allocated resident context area in which the MCM driver will maintain party-specific state information if the add-party operation succeeded. Otherwise, this parameter can be NULL because it is ignored by NDIS if Status is anything other than NDIS_STATUS_SUCCESS.

  • CallParameters [in]
    Pointer to a structure of type CO_CALL_PARAMETERS that contains the call parameters, originally supplied by the client, for the party to be added.

Return value

None

Remarks

If an MCM driver's ProtocolCmAddParty function returns NDIS_STATUS_PENDING, the driver must call NdisMCmAddPartyComplete subsequently to notify the client and NDIS that its attempt to add a party on the multipoint VC has completed, whether successfully or with an MCM driver-determined error status.

The underlying network medium determines whether a client can specify per-party traffic parameters on a multipoint VC. For example, traffic parameters on a multipoint VC are identical for all parties on ATM networks.

If the underlying network medium, like ATM, does not support per-party traffic parameters on multipoint VCs, an MCM driver can do one of the following whenever a client attempts to add a party with a specification at CallParameters that does not match the already established traffic parameters for that VC:

  • Reset the traffic parameters to those already established for the multipoint VC when it successfully adds the party on that VC.

  • Change the traffic parameters for every party already on the VC when it successfully adds the new party.

  • Reject the request to add a new party. (This alternative implicitly forces clients to set up their traffic parameters for a multipoint VC with NdisClMakeCall and to specify the same traffic parameters at each subsequent call to NdisClAddParty for the given multipoint VC.)

If the MCM driver sets Status to NDIS_STATUS_SUCCESS, it must supply an explicit handle, which is usually a pointer to the driver-allocated per-party state area, as CallMgrPartyContext when it calls NdisMCmAddPartyComplete.

A call to NdisMCmAddPartyComplete causes NDIS to call the client's ProtocolClAddPartyComplete function.

Only connection-oriented miniport drivers that provide integrated call-management support can call NdisMCmAddPartyComplete. Stand-alone call managers, which register themselves with NDIS as protocols, call NdisCmAddPartyComplete instead.

Requirements

Target platform

Desktop

Version

See NdisMCmAddPartyComplete.

Header

Ndis.h (include Ndis.h)

IRQL

<= DISPATCH_LEVEL

See also

CO_CALL_PARAMETERS

NdisAllocateFromNPagedLookasideList

NdisClAddParty

NdisCmAddPartyComplete

NdisMCmDropPartyComplete

ProtocolClAddPartyComplete

ProtocolCmAddParty

 

 

Send comments about this topic to Microsoft