104 lines
5.1 KiB
Markdown
104 lines
5.1 KiB
Markdown
# CTI Panasonic NS1000 - Checklist Operativa
|
|
|
|
## 1) Endpoint NetGescon da usare
|
|
|
|
- `POST /api/v1/cti/panasonic/incoming`
|
|
- `POST /api/v1/cti/panasonic/call-ended`
|
|
- `GET /api/v1/cti/panasonic/lookup?phone=...`
|
|
- `GET /api/v1/cti/panasonic/click-to-call/pending?extension=101`
|
|
- `POST /api/v1/cti/panasonic/click-to-call/{id}/claim`
|
|
- `POST /api/v1/cti/panasonic/click-to-call/{id}/status`
|
|
|
|
Esempio base:
|
|
|
|
- `https://staging.netgescon.it/api/v1/cti/panasonic/incoming`
|
|
|
|
## 2) Cosa controllare quando non arrivano chiamate
|
|
|
|
- Rete: il centralino deve raggiungere HTTPS 443 del server NetGescon.
|
|
- DNS: host configurato nel PBX deve risolvere l'IP corretto.
|
|
- Certificato TLS: il PBX non deve rifiutare il certificato del dominio.
|
|
- Token CTI: deve combaciare con il token lato NetGescon.
|
|
- Clock/NTP: orario PBX corretto (evita problemi firma/token e log).
|
|
- Firewall: apertura uscita dal PBX verso internet/DMZ su 443.
|
|
|
|
## 3) Porta 33333 / servizi monitoraggio
|
|
|
|
- La porta `33333` su NS1000 viene spesso usata per stream eventi/integrazioni CTI legacy.
|
|
- Se usata, configurare IP sorgente autorizzati e ACL precise (mai aperta pubblicamente).
|
|
- Preferire webhook HTTPS verso NetGescon come canale primario e 33333/syslog come canale diagnostico.
|
|
|
|
## 3-bis) Serve hardware dedicato?
|
|
|
|
- No, non e necessario un hardware aggiuntivo dedicato se il PBX espone gia CSTA o un flusso eventi raggiungibile in rete.
|
|
- Il bridge/adapter puo girare internamente su Linux come servizio applicativo o daemon dedicato.
|
|
- L'hardware aggiuntivo avrebbe senso solo se il centralino imponesse un gateway proprietario esterno o una licenza/modulo fisico non gia presente.
|
|
- Per NetGescon la strada consigliata resta: `PBX Panasonic -> servizio Linux adapter CSTA -> API HTTPS NetGescon`.
|
|
|
|
## 4) Syslog NS1000 (consigliato)
|
|
|
|
- Abilitare invio syslog remoto dal PBX verso un collector interno.
|
|
- Livello consigliato: eventi chiamata + errori integrazione.
|
|
- Conservare almeno 7-14 giorni per analisi incidenti.
|
|
- Correlare timestamp syslog con log applicativi NetGescon.
|
|
|
|
## 5) Configurazione web NS1000 (traccia operativa)
|
|
|
|
1. Accedi alla Web Maintenance Console.
|
|
2. Vai su sezione integrazioni CTI/CSTA e abilita notifica eventi chiamata.
|
|
3. Imposta URL callback HTTPS di NetGescon per eventi incoming/call-ended.
|
|
4. Inserisci token condiviso (stesso valore lato NetGescon).
|
|
5. In sezione sicurezza/rete limita destinazioni consentite al solo host NetGescon.
|
|
6. In sezione log abilita syslog remoto (se disponibile) verso collector interno.
|
|
7. Salva e riavvia il servizio CTI (o applica configurazione runtime).
|
|
|
|
## 6) Test rapido post-configurazione
|
|
|
|
1. Effettua una chiamata di test entrante sul centralino.
|
|
2. Verifica che sia creato/aggiornato il Post-it chiamata in NetGescon.
|
|
3. Chiudi la chiamata e verifica aggiornamento su endpoint `call-ended`.
|
|
4. Controlla log applicativi e, se attivo, log syslog del PBX.
|
|
|
|
## 7) Mapping operativo CSTA -> NetGescon
|
|
|
|
- `Delivered` o evento ring inbound verso interno/studio:
|
|
- adapter -> `POST /api/v1/cti/panasonic/incoming`
|
|
- campi minimi: `phone`, `event_id`, `called_extension`
|
|
- campi consigliati: `event_type=Delivered`, `direction=inbound`, `name`, `note`, `called_at`
|
|
- effetto: crea/aggiorna Post-it e scrive anche `communication_messages.channel=panasonic_csta`
|
|
- `ConnectionCleared` o fine chiamata:
|
|
- adapter -> `POST /api/v1/cti/panasonic/call-ended`
|
|
- campi minimi: `event_id` oppure `phone`
|
|
- campi consigliati: `event_type=ConnectionCleared`, `duration_seconds`, `outcome`, `ended_at`
|
|
- effetto: chiude Post-it e chiude il messaggio CTI corrispondente
|
|
- lookup rubrica prima del popup PBX/desktop:
|
|
- adapter -> `GET /api/v1/cti/panasonic/lookup?phone=...`
|
|
- click-to-call outbound da un interno:
|
|
- NetGescon UI registra richiesta in `pbx_click_to_call_requests`
|
|
- adapter legge `GET /api/v1/cti/panasonic/click-to-call/pending`
|
|
- adapter prende possesso con `POST /claim`
|
|
- adapter esegue `MakeCall` lato PBX/CSTA Phase III
|
|
- adapter aggiorna esito con `POST /status`
|
|
|
|
## 8) Note su routing interno e intercettazione
|
|
|
|
- Il routing operatore avviene tramite `users.pbx_extension`.
|
|
- Gli eventi inbound Panasonic vengono normalizzati con `target_extension`, `assigned_user_id` e `stabile_id` quando l'interno e associato a un utente NetGescon.
|
|
- Il banner operatore mobile legge sia eventi `smdr` sia eventi `panasonic_csta`, quindi l'intercettazione di una chiamata verso un numero/interno del centralino passa dallo stesso flusso applicativo.
|
|
- Se SMDR e CSTA sono entrambi attivi, CSTA resta il canale piu ricco per popup e correlate; SMDR resta utile come traccia passiva e fallback.
|
|
|
|
Esempio studio corrente:
|
|
|
|
- `201` = centralino con segreteria
|
|
- `205` = operatore studio
|
|
- `206` = amministratore
|
|
- `601` = gruppo/modalita giorno
|
|
- `603` = gruppo/modalita notte
|
|
|
|
Questi valori vanno salvati in `Scheda amministratore -> Centralino studio e interni collaboratori` cosi il layer CTI puo riconoscere sia gli interni personali sia gli alias condivisi del centralino.
|
|
|
|
## 7) Opzione interno VOIP monitor
|
|
|
|
- Si puo configurare un interno tecnico di monitoraggio per ascolto/diagnostica, rispettando policy privacy.
|
|
- Usarlo solo per troubleshooting, con accesso limitato e audit.
|