Device authentication failed

A terminal or gateway has failed authentication.

When there are terminals and / or telephone gateways that register on UCloud, the system operates as a SIP server. The device sends a first request in clear text, i.e. without authentication credentials.

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

This request is “challenged” with a 401 Unauthorized and the WWW-Authenticate header with the “voispeed” realm:

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

At this point, the device sends a second request with the Authorization header, complete with the username, realm and response fields:

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 “

The response field is calculated according to various parameters, including the password saved in the device. In the event that the value calculated by the terminal / gateway does not coincide with that calculated by the UCloud server, device authentication fails.

Possible causes:

The use of provisioning substantially reduces this problem to zero. In the rare event that you need to use unsupported devices, the most likely causes are listed below.

1. a) The password entered in the device configuration is different from the one entered in the user / gateway configuration on the UCloud side
2. b) The device requires the use of two different usernames, one for authentication inserted in the Authorization header and another that precedes the “@” in the From and To headers (301@acme.ucloud in the example). In this case, the device side and UCloud parameters must be configured correctly.

Possible solutions:

1. a) Since the password cannot be recovered, reassign it on both the server and the device. Use only and exclusively complex passwords with upper and lower case and numbers, of at least 8 characters.
2. b) The quickest solution is to assign the username the same value as the extension or the geographical number in the case of gateways. When this is not possible and therefore you must necessarily use an extension number other than the authentication username, arm yourself with patience and check the SIP traces where the parameters configured on the terminal end.

For example, consider the UCloud 300 extension with username mario_rossi. UCloud expects to receive from the terminal a packet similar to the one shown below, where the value “300” precedes the “@” in the From and To fields and the value “mario_rossi” is in the parameter “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”

We just have to enter the values ​​”300″ and “mario_rossi” in the respective configuration fields of the IP phone. Unfortunately, there is no standard in the nomenclature of the two fields, so a bit of analysis work and / or trial and error will be required.

In the table below we give an example of how you change the nomenclature of the same field in the UCloud configuration in the various terminals and user agents.

For example, to configure the above extension on a Yealink phone, we will have to enter the value “300” in the “User Name” field and the “mario_rossi” value in the “Register Name” field.

On a Grandstream we will enter “300” in the “SIP User ID” field and the value “mario_rossi” in the “Authentication ID” field and so on.