Passer un appel
La figure suivante montre un client effectuant un appel sortant via un gestionnaire d’appels.
La figure suivante montre un client effectuant un appel sortant via un pilote MCM.
Avant d’effectuer un appel sortant, un client orienté connexion doit :
Initialiser les paramètres d’appel dans une structure de type CO_CALL_PARAMETERS. Le gestionnaire d’appels ou le pilote MCM utilise généralement les paramètres d’appel spécifiés par le client pour configurer l’appel et dériver les paramètres multimédias à utiliser par le pilote miniport.
Lancez la création d’un vc avec NdisCoCreateVc.
Lors du retour réussi de NdisCoCreateVc, le client appelle NdisClMakeCall pour lancer l’appel (voir les deux figures de cette section).
Dans son appel à NdisClMakeCall, le client passe un pointeur vers la structure CO_CALL_PARAMETERS initialisée précédemment. Le client transmet également un NdisVcHandle (retourné par NdisCoCreateVc) qui identifie le vc sur lequel le client va transmettre (et peut-être recevoir) des données pour l’appel. Si le client effectue un appel multipoint (appel à plusieurs parties distantes), il transmet également un ProtocolePartyContext qui spécifie un handle à une zone de contexte résident allouée par le client dans laquelle le client maintient l’état par partie pour la partie initiale sur le vc multipoint.
L’appel à NdisClMakeCall amène NDIS à transférer cette demande à la fonction ProtocolCmMakeCall du gestionnaire d’appels ou du pilote MCM avec lequel le client partage le NdisVcHandle donné . ProtocolCmMakeCall doit valider les paramètres d’appel d’entrée qui ont été configurés par le client.
ProtocolCmMakeCall communique (échange des messages de signalisation) avec les périphériques de contrôle réseau pour établir une connexion. Un gestionnaire d’appels appelle NdisCoSendNetBufferLists pour lancer un tel échange (voir Envoi de structures NET_BUFFER à partir de pilotes CoNDIS). Un pilote MCM n’appelle jamais NdisCoSendNetBufferLists. Au lieu de cela, il transmet les données directement sur le réseau.
Le gestionnaire d’appels ou le pilote MCM peut modifier les paramètres d’appel fournis par le client lors de la négociation avec les composants réseau appropriés et peut retourner des paramètres de trafic différents de ceux du client initialement donné à NdisClMakeCall (voir Demande entrante de modification des paramètres d’appel).
Un NdisPartyHandle explicite passé à ProtocolCmMakeCall indique que le vc créé par le client sera utilisé pour un appel multipoint. Le gestionnaire d’appels ou le pilote MCM doit allouer et initialiser toutes les ressources nécessaires pour gérer les informations d’état par partie et contrôler l’appel multipoint.
Une fois qu’un gestionnaire d’appels a effectué toutes les communications nécessaires avec son matériel réseau, comme requis par son support, il doit appeler NdisCmActivateVc pour lancer l’activation du vc sur lequel les données d’appel seront envoyées et éventuellement reçues. Un pilote MCM doit appeler NdisMCmActivateVc.
Lorsque le pilote miniport sous-jacent est prêt à effectuer des transferts de données sur le vc (c’est-à-dire, une fois que le vc a été activé), un gestionnaire d’appels appelle NdisCmMakeCallComplete et un pilote MCM appelle NdisMCmMakeCallComplete. À ce stade, le gestionnaire d’appels ou le pilote MCM doivent avoir négocié avec le réseau pour établir des paramètres d’appel pour le vc, et le pilote miniport sous-jacent doit avoir terminé l’activation du vc.
Dans l’appel à Ndis(M)CmMakeCallComplete, le gestionnaire d’appels ou le pilote MCM transmet les paramètres d’appel du VC comme pointeur vers une structure de type CO_CALL_PARAMETERS. Si le gestionnaire d’appels a modifié les paramètres d’appel comme spécifié à l’origine par le client, il peut le notifier en définissant l’indicateur CALL_PARAMETERS_CHANGED dans la structure CO_CALL_PARAMETERS.
Un appel à Ndis(M)CmMakeCallComplete entraîne l’appel de la fonction ProtocolClMakeCallComplete du client à l’origine de l’appel sortant. Un appel à ProtocolClMakeCallComplete indique que le gestionnaire d’appels a terminé le traitement de la demande du client d’établir une connexion virtuelle avec NdisClMakeCall.
Si la tentative du client d’établir un appel sortant a réussi, ProtocolClMakeCallComplete doit case activée l’indicateur CALL_PARAMETERS_CHANGED pour déterminer si les paramètres d’appel initialement spécifiés par le client ont été modifiés. Si l’indicateur est défini, indiquant que les paramètres d’appel ont été modifiés, ProtocolClMakeCallComplete doit examiner les paramètres d’appel retournés pour déterminer s’ils sont acceptables pour cette connexion.
Si les paramètres d’appel sont acceptables, ProtocolClMakeCallComplete retourne simplement le contrôle. Si les paramètres d’appel ne sont pas acceptables et si le protocole de signalisation autorise la renégociation à ce stade, le client peut appeler NdisClModifyCallQoS pour demander une modification des paramètres d’appel (voir Demande lancée par le client pour fermer un appel). Si le protocole de signalisation n’autorise pas la renégociation des paramètres d’appel inacceptables, ProtocolClMakeCallComplete doit détruire l’appel avec NdisClCloseCall (voir Client-Initiated Demande de fermeture d’un appel).