Controllo delle versioni TSPI

Nel corso del tempo, possono essere prodotte versioni diverse di TAPI, applicazioni e provider di servizi. Queste nuove versioni possono creare nuove definizioni, ad esempio per nuove funzionalità, nuovi membri nelle strutture di dati e nuovi campi di bit. I numeri di versione sono quindi necessari per indicare come interpretare varie strutture di dati.

Per garantire un'interoperabilità ottimale di diverse versioni di applicazioni, versioni di TAPI e versioni dei provider di servizi da parte di fornitori diversi, La telefonia Microsoft offre un semplice meccanismo di negoziazione delle versioni per le applicazioni. Esistono due versioni diverse che devono essere concordate da TAPI e dal provider di servizi di telefonia per ogni dispositivo line. Il primo è il numero di versione per l'SPI di telefonia di base e supplementare, detto versione dell'interfaccia TSPI. L'altro è per le estensioni specifiche del provider, se presenti, e viene definito versione dell'estensione. Il formato delle strutture di dati e dei tipi di dati usati dalle funzionalità Basic e Supplementari di TSPI è definito dalla versione TSPI, mentre la versione dell'estensione determina il formato delle strutture di dati definite dalle estensioni specifiche del fornitore.

Questi due tipi di negoziazione della versione vengono gestiti da due procedure diverse: TSPI_lineNegotiateTSPIVersion viene usata per negoziare la versione dell'interfaccia TSPI e TSPI_lineNegotiateExtVersion viene usata per negoziare la versione dell'estensione. La negoziazione della versione dell'estensione può essere ignorata se le estensioni non sono desiderate. Se questi intervalli di input durante la negoziazione si sovrappongono, il provider di servizi deve restituire un valore all'interno della parte sovrapposta dell'intervallo come risultato della negoziazione. In genere, questo deve essere il valore più alto possibile. Se gli intervalli non si sovrappongono, le due parti non sono compatibili e la funzione restituisce un errore.

I risultati di una negoziazione indicano semplicemente che il provider di servizi è disposto a operare a un determinato numero di versione, ma non eseguire il commit del provider di servizi per eseguire questa operazione. Ad esempio, TAPI può rinegoziare per determinare una versione ideale dopo aver negoziato una versione possibile. La versione dell'interfaccia TSPI viene sottoposta a commit solo quando una riga viene aperta usando TSPI_lineOpen e sopravvive fino alla chiusura del dispositivo. La versione dell'estensione viene sottoposta a commit quando viene chiamata la funzione TSPI_lineSelectExtVersion e sopravvive fino a quando la selezione non viene annullata selezionando la versione dell'estensione zero.

La selezione della versione dell'estensione può verificarsi molte volte, tra cui mentre è attiva una versione dell'estensione. Poiché il provider di servizi viene eseguito il commit nella versione dell'estensione, l'intervallo di versioni supportate si restringe esattamente a quella versione dell'estensione. Si consideri ad esempio un provider di servizi normalmente compatibile con le versioni di estensione da 1.0 a 5.5. Se la versione 3.0 è attiva mentre un chiamante tenta di negoziare una versione compresa nell'intervallo da 1.0 a 5.5, la negoziazione restituisce 3.0.

Poiché TAPI negozia la versione, è possibile aggiornare un provider di servizi alle nuove versioni dell'interfaccia senza richiedere l'aggiornamento del TAPI. Analogamente, è possibile aggiornare TAPI, ma usare ancora il provider di servizi meno recente.