Partager via


NdisCmAddPartyComplete (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.

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

Syntax

VOID NdisCmAddPartyComplete(
  _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 call manager'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. This handle was input to the call manager's ProtocolCmAddParty function.

  • CallMgrPartyContext [in, optional]
    Specifies the handle to a caller-allocated resident context area in which the call manager will maintain party-specific state information if the add-party operation succeeded. Otherwise, this parameter can be NULL because it is ignored.

  • 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 a stand-alone call manager's ProtocolCmAddParty function returns NDIS_STATUS_PENDING, the CM subsequently must call NdisCmAddPartyComplete to notify the client and NDIS that its attempt to add a party on the multipoint VC has completed, whether successfully or with an error.

If the client passed in traffic parameters at CallParameters that did not match those already established for the multipoint VC, the designer of the call manager must determine how to handle this condition, subject to any constraints imposed by the network medium. Possibilities include the following:

  • Set up the per-party traffic parameters if the underlying network medium supports this feature on multipoint VCs.

  • Reset the client-supplied traffic parameters to those established for the VC when the original outgoing call was made before the CM calls NdisCmAddPartyComplete with NDIS_STATUS_SUCCESS as the Status.

  • Change the traffic parameters for the VC and, for every party currently connected on it, to the client-supplied values before the CM calls NdisCmAddPartyComplete with NDIS_STATUS_SUCCESS as the Status.

  • Fail the client's attempt to add a 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.)

For some connection-oriented media, such as ATM, traffic parameters are per-VC in nature and, consequently, identical for all parties on a multipoint VC.

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

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

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

Requirements

Target platform

Universal

Version

See NdisCmAddPartyComplete.

Header

Ndis.h (include Ndis.h)

Library

Ndis.lib

IRQL

<= DISPATCH_LEVEL

See also

CO_CALL_PARAMETERS

NdisAllocateFromNPagedLookasideList

NdisClAddParty

NdisMCmAddPartyComplete

ProtocolClAddPartyComplete

ProtocolCmAddParty

 

 

Send comments about this topic to Microsoft