Desligamento do TAPI do CoNDIS

Uma sessão TAPI começa depois que um driver de miniporto da WAN do CoNDIS enumerou seus recursos TAPI para um aplicativo. Em uma sessão, uma ou mais linhas podem ser abertas e uma ou mais chamadas podem ser estabelecidas. Durante o tempo em que uma linha é aberta, muitas chamadas podem ser estabelecidas e, em seguida, fechadas ou descartadas. Durante uma sessão, uma ou mais linhas podem passar por transições de aberta para fechada muitas vezes. A forma como um driver de miniporto lida com essas transições é descrita nesta seção.

Fechando uma chamada

Uma chamada em processo pode ser fechada pelo nó local ou pelo nó remoto. A chamada pode ser fechada no nó local, seja porque o último aplicativo com um identificador para a chamada fechou o identificador ou talvez porque o MiniportHaltEx ou MiniportResetEx do driver de miniport foi chamado. Se o nó remoto desligar uma chamada em processo, o driver de miniporto deverá informar camadas superiores para derrubar a chamada.

Se um aplicativo no nó local fechar a chamada, ele deverá desconectar a chamada. Uma chamada é desconectada como resultado de um aplicativo que chama a função tapi lineDrop . Essa chamada de função TAPI faz com que o driver NDPROXY chame a função NdisClCloseCall e passe um identificador que representa a VC para a chamada. O NDIS, por sua vez, chama a função ProtocolCmCloseCall do driver de miniport da WAN coNDIS. O driver de miniporte deve retornar NDIS_STATUS_PENDING para NDPROXY para que o driver de miniporte possa concluir NdisClCloseCall de forma assíncrona.

ProtocolCmCloseCall do driver de miniporte deve se comunicar com dispositivos de controle de rede para encerrar uma conexão entre o nó local e um nó remoto. Em seguida, o driver de miniporto deve chamar a função NdisMCmDeactivateVc para iniciar a desativação da VC usada para a chamada.

Depois que o driver de miniporto encerrar a conexão, seu ProtocolCmCloseCall poderá chamar a função NdisMCmCloseCallComplete para concluir o fechamento da chamada.

Se o nó remoto desligar uma chamada em processo, o driver de miniporto chamará a função NdisCmDispatchIncomingCloseCall para informar NDISWAN e NDPROXY para derrubar a chamada de entrada.

Fechando uma linha

Uma linha é fechada quando o último aplicativo com um identificador aberto para a linha fecha o identificador. Uma linha é fechada como resultado de um aplicativo que chama a função lineClose tapi. Essa chamada de função TAPI faz com que o driver NDPROXY inicie o fechamento de todas as chamadas nessa linha, conforme descrito na seção anterior. O driver de miniporte deve remover essas chamadas e limpo seu estado.

Fechando uma sessão

O encerramento da sessão pode ser iniciado pelas camadas superiores ou por um driver de miniporto da WAN do CoNDIS. Depois que o último processo de cliente for desanexado do módulo de telefonia de nível superior, o driver NDPROXY será informado de que deve encerrar sua sessão com cada um dos adaptadores registrados. Para fazer isso, o driver NDPROXY chama a função NdisClCloseAddressFamily e passa o identificador para a família de endereços TAPI. O NDIS, por sua vez, chama a função ProtocolCmCloseAf do driver de miniport. O driver de miniporte deve encerrar todas as atividades relacionadas que ele tem em andamento no adaptador especificado e liberar todos os recursos relevantes. Depois de chamar NdisClCloseAddressFamily, o cliente deve considerar o identificador para a família de endereços TAPI inválido.

O encerramento da sessão iniciada pelo driver poderá ocorrer se o driver de miniporto estiver sendo descarregado em sua função MiniportHaltEx . Normalmente, o driver de miniporto completaria quaisquer solicitações NDPROXY pendentes e notificaria o NDISWAN de que todas as chamadas estão sendo fechadas. Se o driver de miniporte fosse recarregado novamente mais tarde, ele passaria pelo mesmo processo de inicialização descrito anteriormente.

O driver de miniporto WAN do CoNDIS também poderá iniciar o encerramento da sessão se ele passou por alguma reconfiguração dinâmica que exigiu uma reinicialização completa de todos os clientes e drivers. Por exemplo, se a modelagem de dispositivo de linha de um adaptador (por exemplo, o número de dispositivos de linha com suporte) tiver sido alterada em tempo real.