netgescon-day0/docs/CTI-NS1000-CHECKLIST.md

5.1 KiB
Executable File

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.