INDICE

Nella seguente guida, verranno spiegati in maniera approfondita tutti i requisiti per il corretto funzionamento e verranno anche illustrate le anomalie dovute a errori di configurazione più frequenti e come risolverle.



Modalità funzionamento

Il procedimento corretto e standard per configurare la app è il seguente:

  1. entrare nel cti
  2. da impostazioni generare il qrcode per la mobile app
  3. inquadrarlo dalla app e loggarsi. 

Se questa procedura non funziona vuol dire che ci sono problemi di configurazione. Verificare la sezione apposita. In alternativa se per qualche motivo il cti non fosse disponibile è possibile autenticarsi inserendo manualmente i parametri (username password e indirizzo del server).

La app è progettata per essere usata su un solo dispositivo, attivarla su vari dispositivi senza fare logout può portare a comportamenti non desiderati come mancata notifica delle chiamate in arrivo o chiamate che a volte arrivano su un dispositivo a volte su un altro. Le notifiche delle chiamate in arrivo vengono inviate solo all'ultimo dispositivo che si è loggato, cliccare su qrcode per generarne uno nuovo (e poi non utilizzarlo) invalida comunque il login precedente.

In caso di app chiusa vengono inviate delle notifiche push per "svegliare" la app e farla suonare, queste notifiche NON vengono inviate se il sistema su MY ha gli aggiornamenti bloccati, perchè con questo "blocco" anche tutti i servizi cloud vengono fermati e l'invio delle notifiche è uno di questi.



Test di corretto funzionamento

Il modo migliore per testare che tutto sia configurato correttamente, senza andare in conflitto con altri componenti è il test dell'echo che si può attivare chiamando il numero *43 

In questa modalità prima il pbx riproduce un messaggio e poi fa sentire la voce che riceve.

Una chiamata della durata superiore a 60 secondi nella quale la voce dell'interlocutore viene riprodotta indica che l'infrastruttura dell'app funziona correttamente.



Verifica configurazioni di base

  1. Protocollo https su porta 443 TCP esposto con un certificato valido, di una certification authority riconosciuta e fullchain (ossia che nel certificato siano inclusi anche tutti i certificati intermediate necessari). Il certificato Lets Encrypt generato tramite Nethserver è pienamente sufficiente.
  2. Porte esterne aperte e correttamente inoltrate 5061 6061 TCP e il range 10000-20000 UDP.
  3. Indirizzo ip pubblico correttamente impostato nella sezione Amministrazione->Impostazioni del Nethvoice (è sempre meglio specificare l'indirizzo ip direttamente e non il nome) e opzione SIPS abilitata
  4. Il nethvoice deve SEMPRE uscire con lo stesso ip pubblico impostato, quindi in caso di multiwan è necessario configurare opportunamente il Nethsecurity o il firewall per rispettare questo criterio.
  5. Per far funzionare la app dalla stessa rete locale del Nethvoice è necessario che sul firewall (più precisamente sull'apparato che gestisce il nat dell'ip pubblico associato al Nethvoice) sia abilita la funzione "hairpin NAT" se si usa un NethSecurity (abilitabile dalle impostazioni del firewall), oppure sugli altri apparati è conosciuta anche come NAT reflection / NAT hairpining / NAT on a stick / loopback NAT.
    NOTA nel caso in cui non si abbia il controllo sul dispositivo che gestisce l'ip pubblico (es router del carrier) e se e solo se il gateway di rete è un nethsecurityè possibile eseguire una configurazione ad hoc per avere l'audio funzionante anche dall'interno in questo modo:
    1. Creare un alias sulla red con l'indirizzo ip pubblico della connettività usato dal nethvoice (il valore impostato su external address)
    2. Configurare port forward delle porte 5061 e 6061 TCP e del range 10000-20000 UDP dell'alias creato verso l'ip del nethvoice se su macchina separata, l'ip della red se tutto sulla stessa macchina.
    3. Abilitare l'hairpin NAT nelle impostazioni del modulo firewall
  6. Se il nome pubblico di accesso del centralino es nethvoice.miaazienda.it non è uguale al nome della macchina (per esempio per generare il certificato avete dovuto configurare un alias), allora impostare l'alias corretto nel netCTI-server tramite la procedura spiegata nel manuale alla prima nota https://nethvoice.docs.nethesis.it/it/v14/app_mobile.html#product-cti. NOTA BENE il nome pubblico deve essere anche un alias della macchina stessa. E' possibile aggiungerlo dal Nuovo Server Manager dalla Dashboard cliccando su "nome host/alias".
  7. SOLO per sistemi nei quali nella stessa macchina c'è sia Nethvoice che Nethsecurity e viene usato per il Nethvoice un ip pubblico configurato come alias, per il corretto funzionamento è necessario configurare un port forward del range 10000-20000 UDP dall'ip pubblico alias verso l'indirizzo reale della red sulla quale questo alias è configurato



Verifiche avanzate

Di seguito vengono elencate un elenco di verifiche avanzate da eseguire nel caso in cui nonostante i prerequisiti di base risultino corretti, ancora si verifichino delle anomalie, spesso sono refusi/modifiche non standard di vecchie configurazioni che in fase di aggiornamento non sono state aggiornate (cercando di preservare le funzionalità già preesistenti).


  1. Verificare che il transport TCP del pjsip (Avanzate-> Impostazioni -> Asterisk sip settings tab Pjsip e scorrere in basso) sia in ascolto sulla porta 5062 e che ci sia il valore "none" su "local network". In caso di modifiche ricordarsi che dopo la modifica è necessario riavviare asterisk manualmente. E' possibile verificare che asterisk abbia recepito le modifiche con il comando 'asterisk -rx "pjsip show transport 0.0.0.0-tcp"'
  2. Verificare che la macchina stia uscendo con l'ip corretto, con il comando 'curl ifconfig.co' da riga di comando è possibile verificarlo (anche se potrebbe non essere sempre corretto in caso di configurazioni particolari)
  3. Verificare che l'inoltro della porta 6061 sia corretto (a volte capita che per sbaglio la 6061 venga inoltrata sulla 5061). Per verificarlo, dalla shell del Nethvoice lanciare il comando 'tcpdump -nni any port 6061' da un altro host esterno lanciare il comando 'telnet IPPUBBLICONETHVOICE 6061' a questo punto sulla shell del Nethvoice si dovrà vedere una schermata tipo quella riportata, dove ip sorgente deve essere l'ip pubblico del chiamante e ip Nethvoice potrà essere l'ip pubblico o privato del Nethvoice in base al tipo di infrastruttura. Nota bene che la porta di destinazione DEVE essere 6061. Se è un'altra vuol dire che il nat in ingresso è errato. 
  4. Verificare che il range udp sia aperto, per fare ciò è possibile usare l'utility netcat. Sul Nethvoice lanciare il comando 'nc -u -l 15002', dal client esterno lanciare il comando 'nc [IPPUBBLICONETHVOICE] -u 15002' ora sul client se scriviamo qualsiasi cosa deve venire scritta sul server. Ecco un esempio di come deve essere:

  



Problemi comuni


Fallito login da qrcode


Descrizione anomalia riscontrata

Si inquadra il qrcode e la app non si logga, da un errore o connessione difettosa.


Soluzione

Verificare che il qrcode sia corretto inquadrandolo con un'applicazione che legge i qrcode (Su iphone basta la fotocamera, su Android si può usare Qrdroid). Il qrcode DEVE presentare una stringa con 3 parametri dinamici in base all'utente loggato USERNAME;TOKEN_DI_AUTENTICAZIONE;FQDN_SERVER in questo caso verificare che FQDN_NETHVOICE sia quello corretto e pubblico. Altrimenti configurarlo prontamente (punto 6 dei prerequisiti di base).


Verificare che il certificato https sia valido e fullchain tramite il sito https://www.ssllabs.com/ssltest/ inserire l'url pubblico del nethvoice ottenuto nella verifica precedente, selezionare 'Do not show the results on the boards' e aspettare. Alla fine del test (4/5 minuti) non devono esserci problemi della chain, ecco un esempio di un certificato corretto:


Verificare i punti 2 e 3 dei prerequisiti e i punti 1 e 3 delle verifiche avanzate.



Audio assente o monodirezionale


Descrizione anomalia riscontrata

Anche durante il test dell'echo l'audio è monodirezionale o del tutto assente.


Soluzione

Come prima cosa verificare il funzionamento utilizzando una connessione 4g, in modo da essere sicuri di essere dall'esterno.

Se i problemi persistono verificare i punti 2 e 3 dei prerequisiti e i punti 2 e 4 del delle verifiche avanzate.

Se il problema si verifica solo dalla rete locale al nethvoice verificare il punto 5 dei prerequisiti di base.



Caduta chiamata dopo 30/60 secondi


Descrizione anomalia riscontrata

Anche durante il test dell'echo la chiamata anche se funziona (la chiamata viene stabilita e l'audio si sente in entrambi i versi) cade dopo un periodo di massimo 60 secondi. Questo problema si dovrebbe verificare solo per sistemi dove avevano in uso la versione precedente dell'app o l'estensione app è attiva da prima del nuovo proxy (febbraio 2021) anche se non usata.


Soluzione

Verificare i punti 2 e 4 dei prerequisiti e i punti 1 e 2 delle verifiche avanzate. Se tutto corretto va capito se lo fa a tutti o solo ad alcuni interni, il modo migliore è creare un nuovo utente con un nuovo interno, associandogli webphone e app e fare la prova, se il nuovo utente non lo fa provare la seguente procedura:

  1. far sloggare gli utenti che riscontrano il problema dalla app
  2. dal nethvoice disabilitare la app per ogni utente e dopo 30 secondi riabilitarla (possono anche essere disabilitate tutte insieme e dopo 30 secondi riabilitate tutte insieme)
  3. far entrare nuovamente nel cti gli utenti (login tramite username e non con l'interno) e scansionare un nuovo qrcode.
  4. fare ora la verifica con il test echo, la chiamata non dovrebbe più cadere.



Mancato risveglio dell'app su chiamata in ingresso/ mancata ricezione delle chiamate


Descrizione anomalia riscontrata

Se chiamo un interno che ha anche la app configurata su un dispositivo collegato ad internet questa non si sveglia e/o suona anche se aperta in primo piano.


Soluzione

Come prima cosa andrebbe identificato se succede su tutti i telefoni, solo su ios, solo su android, solo su qualche dispositivo.


Su tutti i telefoni


Solo su Android:


Solo su IOS: