Autenticazione dell’apparato fallita

Un terminale o un gateway ha fallito l’autenticazione.

Quando ci sono dei terminali e/o dei gateway telefonici che si registrano su UCloud, il sistema opera come server SIP. Il dispositivo invia una prima richiesta in chiaro, cioè senza credenziali di autenticazione.

REGISTER sip:acme.ucloud:5142 SIP/2.0
…
From: <sip:301@acme.ucloud:5142>;tag=3148eb62c3
To: <sip:301@acme.ucloud:5142>;

Tale richiesta viene “sfidata” con un 401 Unauthorized e l’header WWW-Authenticate con il realm “voispeed”:

SIP/2.0 401 Unauthorized
…
WWW-Authenticate: Digest realm=”voispeed”, nonce=”1730071197″
Content-Length: 0

Il dispositivo a questo punto invia una seconda richiesta con l’header Authorization, completo dei campi username, realm e response:

REGISTER sip:acme.ucloud:5142 SIP/2.0
…
From: <sip:301@acme.ucloud:5142>;tag=3148eb62c3
To: <sip:301@acme.ucloud:5142>;
Authorization: Digest username=”301″, realm=”voispeed”,nonce=”1730071197″, uri=”sip:acme.ucloud:5142″, response=”84d2ada63a07b7507f034f6481e6ca8a”

Il campo response viene calcolato in funzione di vari parametri, tra cui anche la password salvata nel dispositivo. Nel caso in cui il valore calcolato dal terminale/gateway non coincida con quello calcolato dal server UCloud, l’autenticazione del dispositivo fallisce.

Cause possibili:

L’uso del provisioning riduce sostanzialmente a zero questa problematica. Nella rara eventualità che si debbano usare dispositivi non supportati, nel seguito le cause più probabili.

1. a) La password inserita nella configurazione del dispositivo è diversa da quella inserita nella configurazione dell’utente/gateway lato UCloud
2. b) Il dispositivo prevede l’utilizzo di due username diversi, uno per l’autenticazione inserito nell’header Authorization ed un altro che precede la “@” negli header From e To (301@acme.ucloud nell’esempio). In questo caso vanno configurati correttamente i parametri lato dispositivo e UCloud.

Possibili soluzioni:

1. a) Dato che non è possibile recuperare la password, riassegnatela sia sul server, sia sul dispositivo. Usate solo ed esclusivamente password complesse con maiuscole, minuscole e numeri, di almeno 8 caratteri.
2. b) La soluzione più rapida consiste nell’assegnare allo username lo stesso valore dell’interno o del numero geografico nel caso dei gateway. Quando questo non è possibile e quindi dovete necessariamente usare un numero d’interno diverso dallo username d’autenticazione, armatevi di pazienza e controllate nei tracciati SIP dove finiscano i parametri configurati sul terminale.

Consideriamo ad esempio l’interno UCloud 300 con username mario_rossi. UCloud si aspetta di ricevere dal terminale un pacchetto simile a quello mostrato sotto, dove il valore “300” precede la “@” nei campi From e To ed il valore “mario_rossi” è nel parametro “username”.

REGISTER sip:acme.ucloud:5142 SIP/2.0
…
From: <sip:300@acme.ucloud:5142>;tag=3148eb62c3
To: <sip:301@acme.ucloud:5142>;
Authorization: Digest username=”mario_rossi“, realm=”voispeed”,nonce=”1730071197″, uri=”sip:acme.ucloud:5142″, response=”84d2ada63a07b7507f034f6481e6ca8a”

Non ci resta che inserire i valori “300” e “mario_rossi” nei rispettivi campi di configurazione del telefono IP. Purtroppo non c’è uno standard nella nomenclatura dei due campi, quindi occorrerà un po’ di lavoro di analisi e/o procedere per tentativi.

Nella tabella riportata sotto diamo un esempio di come cambi la nomenclatura dello stesso campo nella configurazione UCloud nei vari terminali e user agent.

Ad esempio per configurare l’interno di cui sopra su un telefono Yealink, dovremo inserire il valore “300” nel campo “User Name” ed il valore “mario_rossi” nel campo “Register Name”.

Su un Grandstream inseriremo “300” nel campo “SIP User ID” ed il valore “mario_rossi” nel campo “Authentication ID” e così via.