Making a Call (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.
The following figure shows a client making an outgoing call through a call manager..png)
The following figure shows a client making an outgoing call through an MCM driver.
.png)
Before making an outgoing call, a connection-oriented client must do the following:
Initialize call parameters in a structure of type CO_CALL_PARAMETERS. The call manager or MCM driver typically uses the call parameters specified by the client to set up the call and to derive media parameters for use by the miniport driver.
Initiate the creation of a VC with NdisCoCreateVc(see Creating a VC).
On the successful return of NdisCoCreateVc, the client calls NdisClMakeCall to initiate the call (see the two figures in this section).
In its call to NdisClMakeCall, the client passes a pointer to the CO_CALL_PARAMETERS structure initialized previously. The client also passes an NdisVcHandle (returned by NdisCoCreateVc) that identifies the VC on which the client will transmit (and perhaps receive) data for the call. If the client is making a multipoint call (a call to more than one remote party), it also passes a ProtocolPartyContext that specifies a handle to a client-allocated resident context area in which the client will maintain per-party state for the initial party on the multipoint VC.
The call to NdisClMakeCall causes NDIS to forward this request to the ProtocolCmMakeCall function of the call manager or MCM driver with which the client shares the given NdisVcHandle. ProtocolCmMakeCall must validate the input call parameters that were set up by the client.
ProtocolCmMakeCall communicates (exchanges signaling messages) with network control devices to make a connection. A call manager calls NdisCoSendPackets to initiate such an exchange (see Sending Packets on a VC). An MCM driver never calls NdisCoSendPackets. Instead, it transmits the data directly across the network.
The call manager or MCM driver can modify the client-supplied call parameters while negotiating with relevant network components and can return different traffic parameters than the client originally gave to NdisClMakeCall(see Incoming Request to Change Call Parameters).
An explicit NdisPartyHandlepassed to ProtocolCmMakeCall indicates that the VC created by the client will be used for a multipoint call. The call manager or MCM driver must allocate and initialize any necessary resources required to maintain per-party state information and control the multipoint call.
After a call manager has done all the necessary communication with its networking hardware as required by its medium, it must call NdisCmActivateVc to initiate the activation of the VC on which call data will be sent and perhaps received (see Activating a VC). An MCM driver must call NdisMCmActivateVc.
When the underlying miniport driver is ready to make data transfers on the VC (that is, after the VC has been activated), a call manager calls NdisCmMakeCallComplete, and an MCM driver calls NdisMCmMakeCallComplete. At this point, the call manager or MCM driver should have negotiated with the network to establish call parameters for the VC, and the underlying miniport driver should have completed activation of the VC.
In the call to NdisMCmMakeCallComplete, the call manager or MCM driver passes the call parameters for the VC as a pointer to a structure of type CO_CALL_PARAMETERS. If the call manager has modified the call parameters as originally specified by the client, it can notify the client by setting the CALL_PARAMETERS_CHANGED flag in the CO_CALL_PARAMETERS structure.
A call to NdisMCmMakeCallComplete causes NDIS to call the ProtocolClMakeCallComplete function of the client that originated the outgoing call. A call to ProtocolClMakeCallComplete indicates that the call manager has completed processing the client's request to establish a virtual connection with NdisClMakeCall.
If the client's attempt to establish an outgoing call was successful, ProtocolClMakeCallComplete should check the CALL_PARAMETERS_CHANGED flag to determine whether the call parameters originally specified by the client were modified. If the flag is set, indicating that the call parameters were changed, ProtocolClMakeCallComplete should examine the returned call parameters to determine whether they are acceptable for this connection.
If the call parameters are acceptable, ProtocolClMakeCallComplete simply returns control. If the call parameters are not acceptable and if the signaling protocol allows renegotiation at this point, the client can call NdisClModifyCallQoSto request a change in call parameters (see Client-Initiated Request to Close a Call). If the signaling protocol does not allow renegotiation of unacceptable call parameters, ProtocolClMakeCallComplete must tear down the call with NdisClCloseCall(see Client-Initiated Request to Close a Call).