768 lines
26 KiB
Markdown
768 lines
26 KiB
Markdown
# CTI Windows TAPI - Guida Semplice
|
|
|
|
Questa guida serve a fare il primo passo sulla macchina Windows dove hai installato il driver Panasonic TAPI/TSP.
|
|
|
|
L'obiettivo non e ancora fare il bridge completo.
|
|
|
|
L'obiettivo adesso e capire tre cose, con calma:
|
|
|
|
1. il driver TAPI e davvero visibile a Windows
|
|
2. quali linee o indirizzi espone
|
|
3. la macchina Windows riesce a parlare con NetGescon con il token corretto
|
|
|
|
## File da usare
|
|
|
|
- `scripts/ops/windows/get-netgescon-panasonic-tapi-info.ps1`
|
|
- `scripts/ops/windows/test-netgescon-panasonic-api.ps1`
|
|
|
|
## Passo 1: apri PowerShell come amministratore
|
|
|
|
Sulla macchina Windows:
|
|
|
|
1. apri il menu Start
|
|
2. cerca `PowerShell`
|
|
3. fai click destro
|
|
4. scegli `Esegui come amministratore`
|
|
|
|
## Passo 2: spostati nella cartella dove hai copiato il repo
|
|
|
|
Esempio:
|
|
|
|
```powershell
|
|
cd C:\netgescon\netgescon-day0
|
|
```
|
|
|
|
## Passo 3: permetti l'esecuzione dello script nella sessione corrente
|
|
|
|
```powershell
|
|
Set-ExecutionPolicy -Scope Process Bypass
|
|
```
|
|
|
|
Questo non cambia in modo permanente la politica della macchina. Vale solo per quella finestra.
|
|
|
|
## Passo 4: estrai le informazioni dal driver TAPI
|
|
|
|
Prima prova senza filtro:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\get-netgescon-panasonic-tapi-info.ps1 -IncludeMembers
|
|
```
|
|
|
|
Se il risultato e troppo lungo, prova filtrando gli interni che ci interessano:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\get-netgescon-panasonic-tapi-info.ps1 -Filter 205
|
|
.\scripts\ops\windows\get-netgescon-panasonic-tapi-info.ps1 -Filter 206
|
|
.\scripts\ops\windows\get-netgescon-panasonic-tapi-info.ps1 -Filter 201
|
|
```
|
|
|
|
Lo script crea un file JSON, di default:
|
|
|
|
```text
|
|
netgescon-tapi-info.json
|
|
```
|
|
|
|
### Cosa mi devi mandare dopo questo passo
|
|
|
|
Mandami una di queste cose:
|
|
|
|
1. le righe del riepilogo rapido finali
|
|
2. il contenuto del file JSON
|
|
3. uno screenshot del riepilogo se ti viene piu comodo
|
|
|
|
## Passo 5: verifica che Windows riesca a parlare con NetGescon
|
|
|
|
Sostituisci:
|
|
|
|
- `https://staging.netgescon.it` con il tuo URL reale, se diverso
|
|
- `IL_TUO_TOKEN` con il token CTI reale
|
|
|
|
E lancia:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\test-netgescon-panasonic-api.ps1 -BaseUrl "https://staging.netgescon.it" -Token "IL_TUO_TOKEN" -Extension "205"
|
|
```
|
|
|
|
### Cosa deve succedere nel watcher
|
|
|
|
Devi vedere tre blocchi:
|
|
|
|
1. `Lookup rubrica`
|
|
2. `Simulazione incoming`
|
|
3. `Simulazione call-ended`
|
|
|
|
Se dentro i JSON compare `ok: true`, allora:
|
|
|
|
- il token e giusto
|
|
- la macchina Windows raggiunge NetGescon
|
|
- gli endpoint sono pronti
|
|
|
|
## Se qualcosa fallisce
|
|
|
|
### Caso A: errore creando `TAPI.TAPI`
|
|
|
|
Significa che il provider COM TAPI non e registrato bene o il driver Panasonic non e installato correttamente.
|
|
|
|
### Caso B: trovi TAPI ma zero indirizzi
|
|
|
|
Significa che il driver c'e, ma non sta esponendo ancora linee utilizzabili.
|
|
|
|
In quel caso di solito bisogna controllare:
|
|
|
|
1. configurazione del TSP Panasonic
|
|
2. `Check Location`
|
|
3. IP PBX e porta `33333`
|
|
4. licenza CTI lato centralino
|
|
|
|
### Caso B2: Panasonic esiste nel registry ma `Telephony Providers` e zero
|
|
|
|
Se il report di diagnostica mostra contemporaneamente:
|
|
|
|
- chiavi Panasonic presenti sotto `HKLM\SOFTWARE\Panasonic\KX_TDA_TSP`
|
|
- `Telephony providers x64: 0`
|
|
- `Telephony providers wow64: 0`
|
|
- nessun provider Panasonic tra i provider TAPI registrati
|
|
|
|
allora il problema non e il bridge NetGescon.
|
|
|
|
Il problema e che il TSP Panasonic e installato o configurato nei suoi dati locali, ma non e registrato correttamente dentro il sottosistema Telephony di Windows.
|
|
|
|
In pratica Windows vede TAPI, ma non vede il provider Panasonic come provider utilizzabile.
|
|
|
|
In questo stato:
|
|
|
|
1. gli script NetGescon possono partire
|
|
2. il bridge HTTP puo funzionare
|
|
3. ma TAPI continuera a esporre zero linee reali o un solo address vuoto
|
|
|
|
La correzione va fatta su Windows:
|
|
|
|
1. aprire `telephon.cpl`
|
|
2. verificare nella sezione provider che Panasonic sia realmente presente
|
|
3. se assente, reinstallare o registrare di nuovo il `KX-TDA TSP`
|
|
4. verificare compatibilita 32 bit / 64 bit del TSP sulla macchina
|
|
5. solo dopo ripetere `get-netgescon-panasonic-tapi-info.ps1`
|
|
|
|
## Checklist operativa rapida
|
|
|
|
Usa questa checklist quando il bridge NetGescon parte ma il provider TAPI non espone linee reali.
|
|
|
|
### Stato gia confermato su questa macchina
|
|
|
|
1. il task `NetGescon Panasonic Live Bridge` parte ed e in stato `Running`
|
|
2. il watcher .NET TAPI carica l'assembly e si sottoscrive agli eventi
|
|
3. il bridge HTTP NetGescon non e il blocco principale
|
|
4. TAPI vede solo `1` address vuoto
|
|
5. `Telephony providers x64 = 0`
|
|
6. `Telephony providers wow64 = 0`
|
|
7. il registry Panasonic esiste sotto `HKLM\SOFTWARE\Panasonic\KX_TDA_TSP`
|
|
|
|
### Cosa manca davvero
|
|
|
|
1. il provider Panasonic deve comparire dentro `telephon.cpl`
|
|
2. il provider Panasonic deve essere registrato nei `Telephony Providers` di Windows
|
|
3. il TSP deve essere coerente con l'architettura della macchina `32/64 bit`
|
|
4. la connessione del TSP deve puntare al PBX corretto e non restare su profilo `USB:PC`
|
|
5. dopo la correzione, `get-netgescon-panasonic-tapi-info.ps1` deve mostrare address reali con `AddressName` o `DialableAddress`
|
|
|
|
### Sequenza pratica consigliata
|
|
|
|
1. apri `telephon.cpl`
|
|
2. se Panasonic non compare tra i provider, reinstalla `KX-TDA TSP` come amministratore
|
|
3. se Panasonic compare, apri la configurazione del provider e verifica:
|
|
|
|
- IP PBX `192.168.0.101`
|
|
- porta `33333`
|
|
- nessun trasporto bloccato su `USB:PC` se il collegamento e IP
|
|
|
|
4. verifica che il centralino abbia licenza CTI attiva lato TSP/CSTA
|
|
2. salva la configurazione e riavvia il tool Panasonic se richiesto
|
|
3. rilancia `get-netgescon-panasonic-tapi-info.ps1`
|
|
4. conferma che compaiano interni reali come `201`, `205`, `206`
|
|
|
|
### Solo se Panasonic non compare ancora
|
|
|
|
1. controlla in `Program Files` se i file `.tsp` Panasonic sono presenti
|
|
2. controlla se l'installer Panasonic usato e la versione giusta per il sistema operativo
|
|
3. esegui reinstallazione pulita del TSP
|
|
4. riapri `telephon.cpl` e verifica di nuovo i provider
|
|
|
|
### Caso C: gli script API falliscono con `401 Unauthorized`
|
|
|
|
Significa che il token non coincide con quello configurato in NetGescon.
|
|
|
|
Importante: il watcher Windows non e bloccato. Continua a ricevere eventi TAPI, ma gli invii `incoming` e `call-ended` verso staging vengono rifiutati, quindi su NetGescon non compare nulla.
|
|
|
|
### Caso D: gli script API falliscono con timeout o errore TLS
|
|
|
|
Significa che la macchina Windows non riesce a raggiungere NetGescon su HTTPS.
|
|
|
|
## Cosa faremo subito dopo
|
|
|
|
Quando mi mandi l'output del primo script, io ti guidero al passo successivo:
|
|
|
|
1. capire quali linee TAPI sono quelle giuste
|
|
2. decidere se monitorare `201`, `205`, `206`
|
|
3. scrivere il probe successivo che ascolta davvero gli eventi chiamata
|
|
|
|
Il primo obiettivo adesso non e fare tutto.
|
|
|
|
Il primo obiettivo e vedere nero su bianco che il driver Panasonic espone qualcosa che possiamo usare.
|
|
|
|
## Risultato atteso corretto
|
|
|
|
Se nel JSON o nel riepilogo trovi linee simili a queste, significa che il provider Panasonic sta esponendo davvero gli interni giusti:
|
|
|
|
- `EXT00201`
|
|
- `EXT00205`
|
|
- `EXT00206`
|
|
- `GRP00601`
|
|
- `GRP00603`
|
|
|
|
Se li vedi, il passo successivo e ascoltare gli eventi di chiamata reali.
|
|
|
|
## Passo 6: watcher TAPI via polling
|
|
|
|
Lo script VBScript di event sink puo fallire con questo errore:
|
|
|
|
```text
|
|
WScript.CreateObject: Impossibile connettere l'oggetto.
|
|
```
|
|
|
|
Questo non significa che Panasonic TAPI non funziona.
|
|
|
|
Significa solo che quell'oggetto COM non si lascia agganciare bene da VBScript come sorgente eventi.
|
|
|
|
Per questo motivo il passo consigliato diventa il polling PowerShell, che e piu robusto.
|
|
|
|
Usa questi script Windows:
|
|
|
|
- `scripts/ops/windows/inspect-netgescon-panasonic-address.ps1`
|
|
- `scripts/ops/windows/poll-netgescon-panasonic-active-calls.ps1`
|
|
|
|
### 6.1 Ispezione veloce dell'interno 205
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\inspect-netgescon-panasonic-address.ps1 -Extension 205 -OutFile .\inspect-205.json
|
|
```
|
|
|
|
Se vuoi fare anche 201 e 206:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\inspect-netgescon-panasonic-address.ps1 -Extension 201 -OutFile .\inspect-201.json
|
|
.\scripts\ops\windows\inspect-netgescon-panasonic-address.ps1 -Extension 206 -OutFile .\inspect-206.json
|
|
```
|
|
|
|
### 6.2 Polling chiamate attive
|
|
|
|
Lancialo cosi da PowerShell:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\poll-netgescon-panasonic-active-calls.ps1 -Extensions "201,205,206" -LogFile .\netgescon-tapi-poll.log
|
|
```
|
|
|
|
Se vuoi includere anche i gruppi studio:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\poll-netgescon-panasonic-active-calls.ps1 -Extensions "201,205,206,601,603" -LogFile .\netgescon-tapi-poll.log
|
|
```
|
|
|
|
### Cosa deve succedere nel polling
|
|
|
|
All'avvio lo script deve stampare righe tipo:
|
|
|
|
```text
|
|
ADDRESS READY name=EXT00205 dial=205 provider=CTSP0000.tsp
|
|
```
|
|
|
|
Poi resta in ascolto e interroga periodicamente il provider.
|
|
|
|
Adesso fai una chiamata reale verso uno degli interni monitorati.
|
|
|
|
Se tutto va bene compariranno righe tipo:
|
|
|
|
```text
|
|
CALL address=EXT00205 dial=205 idx=1 state=... caller=... called=... connected=...
|
|
```
|
|
|
|
e lo stesso contenuto verra scritto nel file:
|
|
|
|
```text
|
|
.\netgescon-tapi-poll.log
|
|
```
|
|
|
|
### Cosa mi devi mandare dopo il polling
|
|
|
|
Mi serve una di queste due cose:
|
|
|
|
1. l'output console del polling
|
|
2. il contenuto del file `netgescon-tapi-poll.log`
|
|
|
|
## Nota importante sui valori `State=0` e `TerminalCount=0`
|
|
|
|
Nel dump iniziale non e un problema grave.
|
|
|
|
Quel dump fotografava solo l'elenco indirizzi esposto dal provider.
|
|
|
|
Il test decisivo adesso non e il numero di terminali, ma se il polling vede comparire una chiamata attiva durante una chiamata vera.
|
|
|
|
## Passo 7: ascolto eventi COM reali
|
|
|
|
Se il polling resta fermo su `IDLE` anche dopo le chiamate, ma `RegisterCallNotifications` e tutto verde, allora il passo corretto e ascoltare gli eventi COM veri del provider.
|
|
|
|
Usa questo script:
|
|
|
|
- `scripts/ops/windows/watch-netgescon-panasonic-tapi-com-events.ps1`
|
|
|
|
Lancialo cosi:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\watch-netgescon-panasonic-tapi-com-events.ps1 -Extensions "201,205,206" -LogFile .\netgescon-tapi-com-events.log
|
|
```
|
|
|
|
## Ripartenza domani mattina
|
|
|
|
Questa e la situazione gia confermata e non va rimessa in discussione salvo nuovi errori evidenti.
|
|
|
|
### Stato validato
|
|
|
|
1. Panasonic TAPI espone linee reali.
|
|
2. Il watcher .NET registra correttamente `GRP00603`.
|
|
3. `RegisterCallNotifications` funziona su `603`.
|
|
4. Il bridge `incoming` in modalita `live` arriva a staging e crea Post-it e Communication Message.
|
|
5. Il bug residuo e solo `call-ended` verso staging.
|
|
|
|
### Comando rapido di test live
|
|
|
|
Da Windows, nel repo:
|
|
|
|
```powershell
|
|
cd C:\NetGescon\netgescon-day0\scripts\ops\windows
|
|
.\bootstrap-netgescon-panasonic-live.cmd -Action live-run -Extensions "603"
|
|
```
|
|
|
|
In un'altra finestra:
|
|
|
|
```powershell
|
|
Get-Content "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log" -Tail 120 -Wait
|
|
```
|
|
|
|
### Cosa deve essere considerato corretto
|
|
|
|
Se compaiono righe come queste, la parte Windows e ok:
|
|
|
|
1. `REGISTER OK mode=monitor+owner`
|
|
2. `BRIDGE LIVE OK endpoint=incoming`
|
|
3. `BRIDGE MARK answered`
|
|
|
|
### Bug residuo da chiudere
|
|
|
|
Se compare ancora:
|
|
|
|
```text
|
|
BRIDGE LIVE KO endpoint=call-ended error=Richiesta annullata: Chiusura imprevista della connessione.
|
|
```
|
|
|
|
allora il problema non e piu Panasonic Windows.
|
|
|
|
Il problema e sul lato staging, in uno di questi livelli:
|
|
|
|
1. codice Laravel deployato non allineato
|
|
2. PHP-FPM / web server che chiude la richiesta `call-ended`
|
|
3. eccezione backend prima della risposta JSON
|
|
|
|
### Verifica server minima
|
|
|
|
Sul server staging:
|
|
|
|
```bash
|
|
grep -n "call-ended\|CTI Panasonic call-ended failed" storage/logs/laravel.log | tail -n 50
|
|
```
|
|
|
|
Se non esce nulla di nuovo mentre `incoming` continua a funzionare, controlla anche i log del web server o di PHP-FPM all'orario della chiamata.
|
|
|
|
### Strategia pratica consigliata
|
|
|
|
Per non bloccare il lavoro:
|
|
|
|
1. usa TAPI live per `incoming`
|
|
2. usa SMDR per la conferma durata / chiusura chiamata finche `call-ended` non e chiuso lato staging
|
|
3. affronta il bug `call-ended` come task separato lato server
|
|
|
|
## Stato applicativo da portare su staging
|
|
|
|
Questo e il pacchetto minimo gia pronto lato applicazione e documentazione.
|
|
|
|
### Ticket Mobile
|
|
|
|
1. il contesto chiamata viene mostrato sopra il titolo ticket
|
|
2. numero chiamante, interno o gruppo chiamato, riferimenti stabile/unita e nota operativa non vengono piu mischiati nel testo libero del problema
|
|
3. il titolo precompilato resta operativo e la descrizione non viene appesantita da dettagli tecnici PBX
|
|
|
|
### Post-it Gestione
|
|
|
|
1. prima della conversione in ticket c'e una nota libera operatore
|
|
2. le chiamate tecniche SMDR e CSTA usano etichette piu chiare come `Chiamata ricevuta`, `Chiamata effettuata`, `Chiamata interna`
|
|
3. il filtro tecnico permette di cercare per linea o gruppo, per esempio `0003`, `603`, `GRP00603`
|
|
|
|
### Watchlist pratica corrente
|
|
|
|
Per il preset Day0 la watchlist operativa da considerare e questa:
|
|
|
|
1. `0001`
|
|
2. `0003`
|
|
3. `201`
|
|
4. `206`
|
|
5. `601`
|
|
6. `603`
|
|
|
|
Lato applicazione, la risoluzione estensioni osservate e gia compatibile con:
|
|
|
|
1. `watch_extensions`
|
|
2. `response_groups`
|
|
3. `incoming_lines`
|
|
|
|
### Punto aperto che non deve bloccare il deploy
|
|
|
|
Se `incoming` continua a funzionare ma `call-ended` continua a chiudere la connessione, il deploy staging va comunque avanti per validare:
|
|
|
|
1. banner live operatore
|
|
2. Ticket Mobile aggiornato
|
|
3. Post-it Gestione aggiornato
|
|
4. filtri linea e conversione con nota operatore
|
|
|
|
In questo scenario la chiusura chiamata resta temporaneamente coperta da SMDR.
|
|
|
|
### Cosa deve succedere nell'ispezione interop
|
|
|
|
All'avvio vedrai le righe di setup e `REGISTER OK`.
|
|
|
|
Poi, quando fai una chiamata reale verso `201`, `205` o `206`, devono comparire righe tipo:
|
|
|
|
```text
|
|
COM EVENT type=...
|
|
```
|
|
|
|
Se compaiono, abbiamo finalmente il canale giusto da usare per il bridge verso NetGescon.
|
|
|
|
## Passo 8: ispezione interop .NET di TAPI 3
|
|
|
|
L'output che hai raccolto conferma che l'interop espone davvero i due canali evento utili:
|
|
|
|
- `ITTAPIEventNotification`
|
|
- `ITTAPIDispatchEventNotification`
|
|
|
|
In pratica non dobbiamo piu indovinare il nome dell'evento COM. Dobbiamo agganciarci ai wrapper .NET generati dall'interop.
|
|
|
|
## Passo 9: watcher .NET basato sui wrapper evento interop
|
|
|
|
Usa questo script:
|
|
|
|
- `scripts/ops/windows/watch-netgescon-panasonic-tapi-dotnet-events.ps1`
|
|
|
|
Lancialo cosi:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\watch-netgescon-panasonic-tapi-dotnet-events.ps1 -Extensions "201-208,601,603,0001,0003" -LogFile .\netgescon-tapi-dotnet-events.log
|
|
```
|
|
|
|
Il watcher ora accetta anche range di interni, quindi `201-208` equivale a `201,202,203,204,205,206,207,208`.
|
|
|
|
Se vuoi una prova limitata di 90 secondi:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\watch-netgescon-panasonic-tapi-dotnet-events.ps1 -Extensions "201-208,601,603,0001,0003" -LogFile .\netgescon-tapi-dotnet-events.log -Seconds 90
|
|
```
|
|
|
|
### Prova bridge dry-run
|
|
|
|
Quando il watcher eventi e stabile, puoi chiedergli di costruire anche i payload candidati per gli endpoint Laravel senza ancora inviarli.
|
|
|
|
Comando:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\watch-netgescon-panasonic-tapi-dotnet-events.ps1 -Extensions "201-208,601,603,0001,0003" -LogFile .\netgescon-tapi-dotnet-events.log -Seconds 90 -BridgeMode dry-run
|
|
```
|
|
|
|
In questa modalita vedrai righe aggiuntive tipo:
|
|
|
|
```text
|
|
BRIDGE DRYRUN endpoint=incoming payload=...
|
|
BRIDGE MARK answered event_id=...
|
|
BRIDGE DRYRUN endpoint=call-ended payload=...
|
|
```
|
|
|
|
Se il provider non espone ancora il numero esterno della chiamata, vedrai invece:
|
|
|
|
```text
|
|
BRIDGE SKIP endpoint=incoming reason=phone-missing ...
|
|
```
|
|
|
|
Questo non e un errore del watcher. Significa solo che per quella chiamata Panasonic non ha ancora reso disponibile il numero nel punto del flusso che stiamo leggendo.
|
|
|
|
Attenzione: `-BridgeMode dry-run` non invia nulla a NetGescon. Se su staging i Post-it restano fermi, la prima cosa da controllare e che il watcher Windows non sia partito in dry-run ma in `live`.
|
|
|
|
### Cosa deve succedere nel watcher .NET
|
|
|
|
All'avvio vedrai prima:
|
|
|
|
- `REGISTER OK` sugli interni monitorati
|
|
- `DOTNET CHECK` per i wrapper provati
|
|
- `DOTNET SUBSCRIBE OK` oppure `DOTNET SUBSCRIBE KO`
|
|
|
|
Se almeno uno dei wrapper va in `DOTNET SUBSCRIBE OK`, fai subito una chiamata reale su `201`, `205` o `206`.
|
|
|
|
Quando l'aggancio funziona, nel log devono comparire righe tipo:
|
|
|
|
```text
|
|
DOTNET EVENT source=... eventType=... payloadType=... state=... cause=... address=... dial=...
|
|
```
|
|
|
|
### Cosa mi devi mandare dal watcher .NET
|
|
|
|
Mandami il contenuto completo di:
|
|
|
|
- console PowerShell
|
|
- oppure file `netgescon-tapi-dotnet-events.log`
|
|
|
|
Con quel log possiamo decidere subito una delle due strade:
|
|
|
|
1. il watcher PowerShell/.NET basta e lo estendiamo per chiamare gli endpoint NetGescon
|
|
2. i wrapper non si agganciano e allora scriviamo il sink COM compilato con la firma esatta appena confermata
|
|
|
|
Se il dry-run produce payload corretti, il passo successivo e passare a:
|
|
|
|
```powershell
|
|
-BridgeMode live -BaseUrl "https://staging.netgescon.it" -Token "IL_TUO_TOKEN"
|
|
```
|
|
|
|
## Passo 10: tenere il bridge sempre acceso su Windows
|
|
|
|
Per evitare che tutto dipenda da una finestra PowerShell aperta, usa questi script:
|
|
|
|
- `scripts/ops/windows/start-netgescon-panasonic-live.ps1`
|
|
- `scripts/ops/windows/install-netgescon-panasonic-live-task.ps1`
|
|
|
|
### 10.1 Avvio live manuale
|
|
|
|
Prima imposta il token come variabile ambiente persistente Windows.
|
|
|
|
In PowerShell amministratore:
|
|
|
|
```powershell
|
|
Set-ExecutionPolicy -Scope Process Bypass -Force
|
|
[Environment]::SetEnvironmentVariable("NETGESCON_CTI_SHARED_TOKEN", "IL_TUO_TOKEN_REALE", "Machine")
|
|
```
|
|
|
|
Poi avvia il bridge live:
|
|
|
|
```powershell
|
|
cd C:\netgescon\netgescon-day0
|
|
.\scripts\ops\windows\start-netgescon-panasonic-live.ps1 -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "C:\ProgramData\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log"
|
|
```
|
|
|
|
Se PowerShell blocca gli script con `ExecutionPolicy`, usa il wrapper `.cmd` oppure lancia esplicitamente PowerShell in bypass solo per il processo corrente:
|
|
|
|
```powershell
|
|
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\ops\windows\start-netgescon-panasonic-live.ps1 -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log"
|
|
```
|
|
|
|
oppure:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\start-netgescon-panasonic-live.cmd -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log"
|
|
```
|
|
|
|
### 10.2 Installazione come task automatico all'avvio macchina con account SYSTEM
|
|
|
|
In PowerShell amministratore:
|
|
|
|
```powershell
|
|
Set-ExecutionPolicy -Scope Process Bypass -Force
|
|
[Environment]::SetEnvironmentVariable("NETGESCON_CTI_SHARED_TOKEN", "IL_TUO_TOKEN_REALE", "Machine")
|
|
cd C:\netgescon\netgescon-day0
|
|
.\scripts\ops\windows\install-netgescon-panasonic-live-task.ps1 -Mode system-startup -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "C:\ProgramData\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log"
|
|
```
|
|
|
|
Nota importante: quando il task gira come `SYSTEM`, i drive mappati come `S:` in genere non esistono. Usa quindi percorsi locali tipo `C:\ProgramData\...` oppure percorsi UNC.
|
|
|
|
### 10.3 Installazione come task al logon utente corrente
|
|
|
|
Se non hai privilegi amministrativi, usa la modalita legata all'utente corrente.
|
|
|
|
```powershell
|
|
Set-ExecutionPolicy -Scope Process Bypass -Force
|
|
[Environment]::SetEnvironmentVariable("NETGESCON_CTI_SHARED_TOKEN", "IL_TUO_TOKEN_REALE", "User")
|
|
cd C:\netgescon\netgescon-day0
|
|
.\scripts\ops\windows\install-netgescon-panasonic-live-task.ps1 -Mode current-user-logon -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log" -InteropOutputDir "$env:LOCALAPPDATA\NetGescon\tapi-interop"
|
|
```
|
|
|
|
### 10.4 Sequenza rapida per il tuo caso `S:\`
|
|
|
|
Attenzione: `S:\` in Windows di solito e un drive mappato di sessione.
|
|
Questo significa che:
|
|
|
|
- puo essere visibile in Esplora file ma non in PowerShell elevata
|
|
- puo essere visibile nel tuo utente ma non nei task eseguiti come `SYSTEM`
|
|
- non va considerato affidabile per il bridge live automatico all'avvio macchina
|
|
|
|
Se `S:` non esiste nel prompt PowerShell, non usare `S:\` per installare o avviare il task.
|
|
Usa invece una di queste due strade:
|
|
|
|
1. meglio: copia il repo o almeno `scripts\ops\windows` in un percorso locale, per esempio `C:\NetGescon` oppure `C:\ProgramData\NetGescon\repo`
|
|
2. in alternativa: usa il percorso UNC reale della share invece del drive mappato, se il task gira con un utente che ha accesso alla share
|
|
|
|
Procedura piu robusta consigliata:
|
|
|
|
```powershell
|
|
Set-ExecutionPolicy -Scope Process Bypass -Force
|
|
cd C:\NetGescon\netgescon-day0\scripts\ops\windows
|
|
.\publish-netgescon-panasonic-runtime.ps1
|
|
cd C:\ProgramData\NetGescon\panasonic-live\current
|
|
.\install-netgescon-panasonic-live-task.cmd -Mode current-user-logon -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log" -InteropOutputDir "$env:LOCALAPPDATA\NetGescon\tapi-interop"
|
|
```
|
|
|
|
Con questo approccio, quando aggiorni il repo ti basta rilanciare `publish-netgescon-panasonic-runtime.ps1` e poi reinstallare il task se hai cambiato i launcher.
|
|
|
|
Solo se `S:` esiste davvero nella stessa sessione PowerShell puoi usare i comandi sotto.
|
|
|
|
```powershell
|
|
Set-ExecutionPolicy -Scope Process Bypass -Force
|
|
cd S:\
|
|
[Environment]::SetEnvironmentVariable("NETGESCON_CTI_SHARED_TOKEN", "IL_TUO_TOKEN_REALE", "User")
|
|
.\scripts\ops\windows\install-netgescon-panasonic-live-task.ps1 -Mode current-user-logon -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log" -InteropOutputDir "$env:LOCALAPPDATA\NetGescon\tapi-interop"
|
|
Start-ScheduledTask -TaskName "NetGescon Panasonic Live Bridge"
|
|
Get-ScheduledTaskInfo -TaskName "NetGescon Panasonic Live Bridge"
|
|
```
|
|
|
|
Se il quarto comando fallisce, non lanciare il quinto: significa che il task non e stato creato.
|
|
|
|
Il file di log non esiste finche il task non parte davvero almeno una volta. Dopo che il sesto comando mostra che il task esiste, puoi seguire il log con:
|
|
|
|
```powershell
|
|
Get-Content "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log" -Tail 100 -Wait
|
|
```
|
|
|
|
## Passo 11: messa in esercizio su staging
|
|
|
|
Quando il watcher e avviato e i log mostrano `DOTNET SUBSCRIBE OK`, la checklist minima per entrare davvero in live e questa.
|
|
|
|
### 11.1 Verifica token prima di fare chiamate reali
|
|
|
|
Sul PC Windows che gira il bridge:
|
|
|
|
```powershell
|
|
[Environment]::GetEnvironmentVariable("NETGESCON_CTI_SHARED_TOKEN", "User")
|
|
```
|
|
|
|
Se leggi il placeholder o una stringa vecchia, riscrivilo con quello reale e poi reinstalla/rilancia il task.
|
|
|
|
### 11.2 Smoke test HTTP verso staging
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\test-netgescon-panasonic-api.ps1 -BaseUrl "https://staging.netgescon.it" -Token "IL_TUO_TOKEN_REALE" -Extension "205"
|
|
```
|
|
|
|
Se questo test non restituisce `ok: true`, non fare ancora chiamate reali: il problema e a livello token o connettivita HTTP.
|
|
|
|
### 11.3 Come leggere il log del bridge live
|
|
|
|
Nel log live, questi casi significano cose diverse:
|
|
|
|
- `BRIDGE LIVE OK endpoint=incoming`: la chiamata e stata accettata da staging
|
|
- `BRIDGE LIVE OK endpoint=call-ended`: la chiusura chiamata e stata accettata da staging
|
|
- `BRIDGE LIVE KO endpoint=incoming error=(401) Non autorizzato`: token errato sul bridge Windows oppure token diverso su staging
|
|
- `BRIDGE IGNORE endpoint=... category=EXT mode=group-first`: evento visto ma non scelto come sorgente autorevole per il bridge
|
|
|
|
### 11.4 Dove vedere le nuove chiamate su staging
|
|
|
|
Quando l'invio live va a buon fine, le nuove chiamate Panasonic compaiono in due punti applicativi:
|
|
|
|
1. `Strumenti -> Post-it Gestione`
|
|
|
|
- legge i record `chiamate_post_it`
|
|
- e il punto principale per vedere le chiamate create dal bridge
|
|
|
|
1. flussi tecnici basati su `communication_messages`
|
|
|
|
- canale `panasonic_csta`
|
|
- utili per verifica tecnica e correlazione con routing/intercettazione operatore
|
|
|
|
In aggiunta, il banner operatore mobile usa anche `panasonic_csta`, quindi una chiamata instradata a un interno monitorato puo comparire anche lato operatore senza passare solo da SMDR.
|
|
|
|
### 11.5 Procedura rapida di ripartenza se staging smette di ricevere chiamate
|
|
|
|
Sul PC Windows:
|
|
|
|
```powershell
|
|
cd C:\ProgramData\NetGescon\panasonic-live\current
|
|
Stop-ScheduledTask -TaskName "NetGescon Panasonic Live Bridge" -ErrorAction SilentlyContinue
|
|
.\install-netgescon-panasonic-live-task.cmd -Mode current-user-logon -BaseUrl "https://staging.netgescon.it" -Extensions "201-208,601,603,0001,0003" -LogFile "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log" -InteropOutputDir "$env:LOCALAPPDATA\NetGescon\tapi-interop"
|
|
Start-ScheduledTask -TaskName "NetGescon Panasonic Live Bridge"
|
|
Get-Content "$env:LOCALAPPDATA\NetGescon\Logs\netgescon-tapi-dotnet-events-live.log" -Tail 100 -Wait
|
|
```
|
|
|
|
Se dopo una chiamata reale appare `401`, fermati subito: il bridge sta funzionando ma staging sta rifiutando il token.
|
|
|
|
Avvio immediato del task:
|
|
|
|
```powershell
|
|
Start-ScheduledTask -TaskName "NetGescon Panasonic Live Bridge"
|
|
```
|
|
|
|
Stato task:
|
|
|
|
```powershell
|
|
Get-ScheduledTask -TaskName "NetGescon Panasonic Live Bridge"
|
|
Get-ScheduledTaskInfo -TaskName "NetGescon Panasonic Live Bridge"
|
|
```
|
|
|
|
Stop task:
|
|
|
|
```powershell
|
|
Stop-ScheduledTask -TaskName "NetGescon Panasonic Live Bridge"
|
|
```
|
|
|
|
Rimozione task:
|
|
|
|
```powershell
|
|
Unregister-ScheduledTask -TaskName "NetGescon Panasonic Live Bridge" -Confirm:$false
|
|
```
|
|
|
|
ma solo dopo aver validato bene il contenuto dei payload dry-run.
|
|
|
|
Se il provider Panasonic accetta `RegisterCallNotifications`, ma:
|
|
|
|
- il polling resta sempre `IDLE`
|
|
- `CallHubs` resta `none`
|
|
- `Register-ObjectEvent` dice che non esiste l'evento `Event`
|
|
|
|
allora PowerShell in late binding non basta piu.
|
|
|
|
In quel caso il passo corretto e generare l'interop .NET della type library `tapi3.dll` e vedere i nomi reali di tipi, delegate ed eventi da usare in un watcher compilato.
|
|
|
|
Usa questo script:
|
|
|
|
- `scripts/ops/windows/inspect-netgescon-tapi-interop.ps1`
|
|
|
|
Lancialo cosi:
|
|
|
|
```powershell
|
|
.\scripts\ops\windows\inspect-netgescon-tapi-interop.ps1
|
|
```
|
|
|
|
### Cosa deve succedere
|
|
|
|
Lo script:
|
|
|
|
1. usa le classi .NET gia presenti in Windows
|
|
2. genera un assembly .NET da `C:\Windows\System32\tapi3.dll`
|
|
3. elenca i tipi che contengono `Event`
|
|
4. elenca i tipi legati a `ITTAPI`
|
|
|
|
### Cosa mi devi mandare
|
|
|
|
Mandami l'output completo dello script.
|
|
|
|
Con quello preparo il watcher compilato con i nomi esatti esposti dall'interop reale della tua macchina Windows.
|