Share via


Incoming Request to Change Call Parameters (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.

A call manager or MCM driver is alerted to an incoming request from a remote party to change the call parameters on an active VC by signaling messages from the network. Whether a call manager or MCM driver supports dynamic QoS changes on active calls depends on the signaling protocol. For example, ATM UNI 3.1 networks do not support dynamic QoS changes on active connections.

The following figure shows an incoming request through a call manager to change call parameters.

The following figure shows an incoming request through an MCM driver to change call parameters.

After receiving an incoming request to change call parameters, a call manager passes appropriately modified call parameters to NdisCmActivateVcto notify the underlying NIC driver of the proposed QoS change. An MCM driver passes modified call parameters to NdisMCmActivateVc(see Activating a VC). If the underlying NIC driver accepts the changed call parameters, a call manager then calls NdisCmDispatchIncomingCallQosChange(see Incoming Request Through a Call Manager to Change Call Parameters). An MCM driver calls NdisMCmDispatchIncomingCallQosChange(see Incoming Request Through an MCM Driver to Change Call Parameters). The call manager or MCM driver passes an NdisVcHandleand a buffered CO_CALL_PARAMETERSstructure to NdisMCmDispatchIncomingCallQosChange.

A call to NdisMCmDispatchIncomingCallQosChange causes NDIS to call the client's ProtocolClIncomingCallQoSChange function. NDIS passes a ProtocolVcContexthandle, that identifies the VC, and the modified call parameters in a buffered CO_CALL_PARAMETERS structure, to ProtocolClIncomingCallQoSChange.

The client accepts the proposed modifications to the call parameters for the VC by doing nothing, except possibly updating any state it maintains about the QoS for the VC, and returning control. If the proposed modifications are unacceptable, the client can attempt to renegotiate the call parameters with NdisClModifyCallQoS if allowed by the signaling protocol (see Client-Initiated Request to Change Call Parameters). Otherwise, the client rejects the proposed QoS change by tearing down the call with NdisClCloseCall (see Client-Initiated Request to Close a Call).

After ProtocolClIncomingCallQoSChange returns, the call manager or MCM driver communicates the client's acceptance or rejection of the proposed change to the remote party that originated the request.

 

 

Send comments about this topic to Microsoft